Ticket-Docs — eine Bau-Doku pro Plane-Ticket
Eine self-contained Datei pro Ticket: <TICKET-ID>.md (Working-ID, z.B. R-P6.md, D-P2.md, EXT-07.md).
Jedes Plane-Ticket verlinkt diese Datei als ersten, granularen Doku-Link (statt auf einen langen Sammel-Brief zu zeigen).
Quelle der Wahrheit bleiben .planning/ENTITY-MODEL.md (Datenmodell, AD-20), REQUIREMENTS.md, ROADMAP.md, PHASE-SOURCES.md und die designer-briefs/PXX.md — die Ticket-Docs destillieren daraus genau den für dieses Ticket relevanten Teil. Bei Widerspruch gilt für P6–P9 das ENTITY-MODEL (Pivot-Vorrang).
Aufbau je Doc
Header-Tabelle (Typ/Owner/Phase/Cycle/Status) · Abhängigkeiten & Parallelität · Was wir bauen · Benötigte Screens · Definition of Done · Technische Bausteine (Dev) bzw. UI-Elemente (Screen) · Quellen (granular) · Davids Delta (Screen) / Dev-Nachzug (Dev).
Ticket-Typen: Dev (R-/AK-/VR-/VA- — Code) · Screen (D-/VD- — Design) · Setup (EXT-) · Vertrieb (H-) · Website (J-) · Noah-Zulieferung (N-). Setup/Vertrieb/Website/Noah nutzen ein schlankeres Schema (Was zu tun · Warum · Abhängigkeiten · DoD).
Einem Coding-Agent ein Ticket geben
Du nennst dem Agent nur die Ticket-ID. Damit er korrekt loslegt, gib ihm diesen Standard-Einstiegs-Prompt (Ticket-ID einsetzen):
Arbeite Ticket <TICKET-ID> ab.
1. Lies .planning/ticket-docs/<TICKET-ID>.md (Spec) UND AGENTS.md (verbindliche Bau-Regeln).
2. Prüfe "Abhängigkeiten & Parallelität": Sind alle blocked-by-Tickets erledigt? Wenn ein Blocker
(z.B. R-P5/AK-P4b/R-REFIT) noch offen ist, STOP und sag mir, was fehlt.
3. Folge den granularen Quellen der Doc (ENTITY-MODEL §Domäne, REQ-Namen, Brief, Spec).
WICHTIG: Bei P6–P9 / Deal-Auftrag hat .planning/ENTITY-MODEL.md Vorrang vor den
_bmad-output/specs/M0x (die sind teils pre-pivot — der 🔴 Pivot-Block oben in der Spec gilt).
4. Halte die Definition of Done Punkt für Punkt ein. Schema: eigene prisma/schema/<modul>.prisma
(AD-21), RLS + Konnektor tenantHasModule(), is_demo_data — wie in "Technische Bausteine".
5. Erzeuge KEINE Migration auf dem Branch (prisma db push); Migration entsteht erst beim Merge (AD-21).
Benutzung:
- Backend-/Logik-Tickets (P1, P2, P5, P6-Kern, Automation, KI …): Agent kann mit der Doc sofort loslegen, sobald die blocked-by stehen.
- UI-/Screen-lastige Tickets: Erst designt David (Screen-Ticket
D-*/VD-*), trägt sein „Davids Delta" in die Screen-Doc ein → dann zieht der Dev nach. Solange das Delta leer ist, baut der Agent das Backend/Datenmodell; die finale UI folgt nach Davids Delta. - Reihenfolge =
SPRINT-DAYPLAN.md(jedes Ticket an seinem Start-Tag) bzw. die Plane-Cycles (Sprint-Wochen). - Das Plane-Ticket selbst verlinkt diese Doc als ersten Doku-Link — Ticket in Plane öffnen → Doc-Link klicken → an den Agent geben.
- Nach Davids Delta: „Dev-Nachzug"-Checkliste am Doc-Ende abarbeiten (Spec/REQUIREMENTS/Plane-Ticket aktualisieren).