Jo-bity Entscheidungen & Anforderungen — Zusammenfassungsdokument
Erzeuge aus einer Arbeitsnotiz (Sessions, Grilling-Ergebnisse, PRDs, Meeting-Protokolle) ein eigenständig lesbares, kondensiertes Entscheidungsdokument. Referenzbeispiele im Vault: 02_Entwicklung/KYC — Entscheidungen & Anforderungen.md, 02_Entwicklung/Onboarding API — Entscheidungen & Anforderungen.md.
Ablage & Sprache
- Datei:
02_Entwicklung/<Thema> — Entscheidungen & Anforderungen.md(em-dash, kein Bindestrich). - Deutsch; Code-/API-/Zustandsbezeichner unübersetzt in Backticks.
- Wikilinks (
[[…]]) zu Quell-Arbeitsnotiz und verwandten Notizen; Schwester-Dokumente gegenseitig verlinken.
Struktur (in dieser Reihenfolge)
- Kopf: Erste Zeile = Anker ins Tracking (Jira-Epic-Link oder Feature-Commitment-Pfad). Danach Blockquote mit Zweck (ein Satz: warum dieses Dokument eigenständig lesbar sein muss — z. B. aufgelöster ADR-Kontext, revidierter Entscheidungsverlauf), Quellen (Arbeitsnotiz(en) mit Session-Daten, Specs, PDFs) und Erstellt von: Claude —
#claude-generated. - Executive Summary: 4–6 Bullets. Was ist das System / wer owned was; Scope-Grenze; neueste Entscheidungen hervorgehoben (mit Datum, nummeriert ①②③ wenn mehrere aus einer Session); wichtigste offene Punkte in einem Bullet.
- Worum es geht: Kurzer Prosa-Absatz + genau ein Mermaid-Systemkontext-Diagramm. Kernverantwortung und Abgrenzungen ("kein genereller Proxy", "System of Record") hier, nicht erst im Register.
- Entscheidungs-Register — neueste zuerst: Ein Eintrag pro Architektur-/Fachentscheidung, durchnummeriert (
E-nbzw.ADR-n, wenn die Quelle bereits ADR-Nummern vergibt — dann deren Nummerierung übernehmen, da Tickets sie referenzieren). Überschriftenformat:### E-n — <Titel> <Status>, <Datum>. Statusmarker: ✅ entschieden · ⏳ offen/vertagt · 🏷️ ADR-Kandidat · Zusatz „revidiert/amendiert " wenn zutreffend. Je Eintrag: Entscheidung (1–3 Sätze), knapper Kontext/Begründung, Verworfen: Alternativen mit Grund in einer Zeile. - Fachlicher Kernabschnitt (falls vorhanden): State Machine, Zustandsmodell, Vertragsübersicht o. ä. — als Tabelle; höchstens ein weiteres Diagramm, wenn die Tabelle nicht reicht. Danach "Kernregeln" als Bullets.
- Glossar (Kurzfassung): Tabelle Begriff | Bedeutung. Nur Begriffe mit Verwechslungsgefahr; Anti-Begriffe inline ("Nicht: …" / "Nicht zu verwechseln mit …").
- Anforderungen im Überblick: 5–8 nummerierte, prüfbare Anforderungen — Verdichtung, keine Wiederholung des Registers.
- Offene Punkte: Bullets, je Punkt der Klärungsweg/Owner ("Klärung mit X", "vertagt bis Y"). Auch bewusste Nicht-Ziele hierhin.
- Verwandte Notizen: Eine Zeile,
·-separiert, mit Rollen-Klammer je Link.
Kondensierungs-Regeln
- Low-Level ausschließen: Test-Framework/Executable-Spec-Details, Fixture-/Fake-Mechanik, Implementierungs-Checklisten, GAP-/Status-Listen, CI-Details. Stattdessen bei "Verwandte Notizen" auf die Arbeitsnotiz verweisen ("inkl. Test-Framework und GAP-Analyse"). Behalte Low-Level nur, wenn es eine Entscheidung begründet (z. B. eine Schema-Kollision als Grund für Namens-Präfixe) — dann ein Satz.
- Überholtes auflösen, nicht wiederholen: Verworfene Modelle/revidierte Ziele erscheinen nur als Kontext im ersetzenden Register-Eintrag ("revidiert das X vom "), nie als eigener Abschnitt. Das Dokument liest sich als aktueller Stand.
- Neuestes sichtbar: Register neueste zuerst; jüngste Entscheidungen zusätzlich im Executive Summary.
- Ein Fakt, ein Ort: Was im Registereintrag steht, nicht in "Weitere Entscheidungen" doppeln; ein Abschnitt "Weitere Entscheidungen" nur, wenn es entscheidungsförmige Punkte unterhalb der Register-Schwelle gibt.
- Zielgröße: deutlich kürzer als die Quelle; als Richtwert ≤ die Hälfte der Quell-Arbeitsnotiz, ~150–200 Zeilen.
Arbeitsweise
- Quell-Arbeitsnotiz vollständig lesen; Session-/Datumsschichten identifizieren und was wodurch überholt wurde.
- Existierende "… — Entscheidungen & Anforderungen"-Dokumente als Stilreferenz prüfen (mind. das KYC-Dokument).
- Dokument schreiben; Auffälligkeiten/Widersprüche in der Quelle nicht stillschweigend korrigieren, sondern als markierten Hinweis (⚠️) oder offenen Punkt ausweisen.
- Dem User kurz melden: welche Entscheidungen als Register-Einträge aufgenommen, was bewusst weggelassen, welche Widersprüche gefunden.