Meine Session planen

# Session Brief: Architecture Decision Record

## Ziel
Artefakt: ADR File

## Arbeitsfrage
Welche Architekturentscheidung trifft das Team jetzt, vor welchen Alternativen, und welche Konsequenzen akzeptiert es dafür?

## Kontext
Issue-ID oder Trigger; Nummer des nächsten freien ADR im Repo; relevante frühere ADRs zur Verknüpfung; mindestens zwei identifizierte Optionen inklusive Status quo.

## Setup
- Format: Async-Arbeitslauf
- Dauer: 24 bis 72 h
- Modus: asynchron
- Teilnehmende: Ein Decider mit Vor- und Nachname (kein „Team“, keine Gilde); ein bis zwei Reviewer aus den betroffenen Teams; Verfasser optional dieselbe Person wie der Decider.
- Owner: Ein Decider mit Vor- und Nachname (kein „Team“, keine Gilde)
- Beteiligungsmodus: Teamrunde, gemeinsames Arbeiten und Alignment
- Ergebnislogik: Artefakt fertigstellen

## Beteiligungslogik
Nutze die Session für gemeinsames Verständnis. Beiträge werden sichtbar gesammelt, Annahmen werden abgeglichen und offene Unterschiede bleiben im Artefakt nachvollziehbar.

## Ergebnislogik
Die Session arbeitet direkt auf ADR File hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.

## Input
ADR-Template (MADR oder Nygard-Stil) im Repo unter `docs/adr/`; Markdown- oder Wiki-Editor; Link auf den Issue-Tracker (Linear, Jira, GitHub Issues).

## Vorbereitung
Nächste freie Nummer im Verzeichnis prüfen; Branch nach Muster `adr/NNNN-kurztitel` anlegen; Reviewer im Pull Request oder Linear-Ticket taggen; Reviewfrist als Datum im PR-Beschreibungsfeld benennen.

## Agenda
1. Brief vorbereiten (15-30 min)
   Owner: Owner
   Aktion: Arbeitsfrage, Input, Zielartefakt und Reviewfrist für Architecture Decision Record vorbereiten. Verlinke relevante Daten, Quellen und bestehende Artefakte. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Session Brief

2. Asynchron bearbeiten (24 bis 72 h)
   Owner: Teilnehmende
   Aktion: Teilnehmende arbeiten die Methode entlang der Vorlage durch. Fokus: Beiträge direkt am Artefakt ergänzen, Annahmen markieren und Belege verlinken. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: ADR File

3. Review bündeln (20-30 min)
   Owner: Facilitator
   Aktion: Kommentare, Widersprüche und offene Fragen clustern. Unklare Punkte als Entscheidungen, Risiken oder Follow-ups einsortieren. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Review Notes

4. Artefakt finalisieren (15-30 min)
   Owner: Owner
   Aktion: Eingearbeitete Version erstellen, Status setzen und nächsten Review oder Entscheidungspunkt terminieren. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Decision Log

5. Artefakt veröffentlichen (10 min)
   Owner: Owner
   Aktion: Artefakt auf Vollständigkeit prüfen, Ablageort festlegen, Version oder Status setzen und Review-Empfänger benennen.
   Output: ADR File

## Abschluss
- Ergebnisartefakt aktualisieren: ADR File
- Ablageort, Version und Review-Empfänger festlegen.
- Owner, nächster Schritt und Reviewtermin festlegen.

# ADR File: Architecture Decision Record

## Arbeitsfrage
Welche Architekturentscheidung trifft das Team jetzt, vor welchen Alternativen, und welche Konsequenzen akzeptiert es dafür?

## Kontext
Issue-ID oder Trigger; Nummer des nächsten freien ADR im Repo; relevante frühere ADRs zur Verknüpfung; mindestens zwei identifizierte Optionen inklusive Status quo.

## Beteiligte
- Owner: Ein Decider mit Vor- und Nachname (kein „Team“, keine Gilde)
- Teilnehmende: Ein Decider mit Vor- und Nachname (kein „Team“, keine Gilde); ein bis zwei Reviewer aus den betroffenen Teams; Verfasser optional dieselbe Person wie der Decider.

## Input
ADR-Template (MADR oder Nygard-Stil) im Repo unter `docs/adr/`; Markdown- oder Wiki-Editor; Link auf den Issue-Tracker (Linear, Jira, GitHub Issues).

## Vorlage
# ADR-0001: Titel der Entscheidung

**Status:** proposed
**Datum:** YYYY-MM-DD
**Decider:** Vorname Nachname
**Trigger:** Ticket, Incident oder RFC

## Kontext

Welche Situation macht die Entscheidung nötig? Welche Constraints, Quality Attributes oder früheren Entscheidungen sind relevant?

## Optionen

### Option 1: ...
- Pro:
- Contra:

### Option 2: ...
- Pro:
- Contra:

## Entscheidung

Wir entscheiden uns für ...

## Konsequenzen

Positive Folgen:
- ...

Negative Folgen und Risiken:
- ...

Folge-ADRs oder Tickets:
- ...

## Fertigstellungscheck
- ADR File ist vollständig genug für Review:
- Ablageort:
- Version / Status:
- Review durch:
- Nächster Schritt:

## Nächster Schritt
- Ergebnis prüfen
- offene Fragen markieren
- Review oder Entscheidung terminieren