TGV · Governance-Register · P3-④ Konsolidierungsplan · Stand 2026-07-18
Damit Lanes autonom arbeiten können, ohne je ein JC-Gate zu überfahren: die dokumentierten Grenzen, zusammengeführt an EINEM Ort.
Drei Ebenen (Governance-Modell: User entscheidet · Orchestrator orchestriert · Admin setzt Rahmen): LANE autonom arbeitet ohne Rückfrage · TOWER entscheidet Orchestrierung/Arbitrage zwischen Lanes · ⛔ JC-GATE wartet zwingend auf JC. Quelle je Zeile — hier wird nichts neu entschieden.
| Aktion | Wer entscheidet | Quelle / Beleg |
|---|---|---|
| Bauen im eigenen Revier (Branch, Code, Doku, Tests) | LANE autonom | Konsolidierungsplan §5 „Lanes arbeiten AUTONOM" |
| Doku-/Familien-PRs mergen (konzepte/, Register) | LANE autonom (KONZEPT#01-Revier) | Tower#24-Protokoll 18.07. „Docs-PRs erstellst du selbst … Familie ist dein Revier" |
| Normale Code-PRs mergen | TOWER (merged selbst) | feedback_tower_merge_autonomous — „nur DDL/Finanz/JC-gated fragen; NIE ‚live' ohne git-verify" |
| Merge-Prioritäten, Lane-Zuschnitt/-Namen, Arbitrage zwischen Lanen | TOWER | feedback_lane_always_ask_tower_not_jc · DOMAIN#NN-Kanon |
| Eval-/Prüf-Befunde anwenden | LANE verifiziert — Befund = Hypothese, Lane darf widersprechen | feedback_eval_findings_are_hypotheses_lane_verifies · Lernschleife ② |
| DDL / Migrationen anwenden (Supabase) | ⛔ JC-GATE (DDL-GO im SQL-Editor; STAGED-Banner bis dahin) | Konsolidierungsplan §5 · Mig-Praxis 211/212/218–220/223 · Sicherheit §5 |
| Deploys auf app.startact.ai (Serve/nginx/SSH) | ⛔ JC-GATE (JC-Hand; Tower liefert den Ein-Zeiler) | Konsolidierungsplan §5 „Deploys (JC-Hand, Ein-Zeiler von Tower)" |
| UI live stellen / Screen-Flips (z. B. #920) | ⛔ JC-GATE nach AGENT-UX#01-Gate + JC-Screen-Abnahme | feedback_ui_section_gate_before_live · feedback_agent_ux_review_gate_mandatory |
| Echtversand (Mails an echte Empfänger, z. B. Buchhalter) | ⛔ JC-GATE | FES-AP2-Praxis · Konsolidierungsplan §5 |
| Finanz-Aktionen (Buchungen final, Zahlungen) | ⛔ JC-GATE (Approval-before-Write) | R-94-Muster · Chatbot First §2 „Prüfbar & compliance-fähig" |
| Design-Entscheide (Badges, Formen, Wörter) | ⛔ JC-GATE — mit Vorschau beider Varianten + Empfehlung + Konsequenz | feedback_arbitrage_mit_vorschau_und_empfehlung · Badge-Dossier |
| Neue JC-Anforderung → Bau | TOWER-Intake ZUERST (Register-Zeile), dann Lane | Anforderungs-Mechanik §2.3 „bevor eine Lane baut" · Anforderungs-Register |
| Screen in JC-Abnahme geben | TOWER — erst wenn alle Anforderungs-Zeilen ✅ (Abnahme-Sperre) | Anforderungs-Gesetz 18.07. · UXAUDIT-Vorlauf |
| Bibel-/Prinzipien-Änderung (KONZEPT_v3 §1) | ⛔ JC-GATE (Entscheid) → Doku-Owner trägt nach | Praxis §1.5-Nachtrag (JC-Entscheid via Codex-Brief, Tower-GO, KONZEPT#01 trug nach) |
| Mandanten-Rahmen (Policy/Guards je Mandant) | ⛔ JC-GATE heute (super_admin) · Ziel: mandant_admin im Verwaltet/Souverän-Modell | Governance-Modell · Sicherheit §8 · JE-158 Admin-Rahmen |
Wie aus einem JC-Impuls (Chat/Bild/Livecheck) eine Entscheidung wird — verbindlich, damit weder gebaut wird ohne Register noch JC ohne Vorlage entscheiden muss. Keine endlos neuen Konzept-Seiten — Bestehendes nutzen (JC-Auflage).
| Schritt | Was passiert | Wer |
|---|---|---|
| ① Impuls | JC sagt/zeigt etwas (Chat · Screenshot · Livecheck) | JC |
| ② Register-Zeile | SOFORT Zeile im Anforderungs-Register (Melde-Datum + Anker) — VOR jedem Bau (Intake-Ritual) | TOWER |
| ③ Triage | a) autonom: Lane baut + aktualisiert Regel UND Komponente (kein JC-Klick nötig) · b) JC-Entscheid: JC bekommt eine GRAFISCHE Entscheidungsvorlage im badge_systematik-Muster (s.u.) | TOWER triagiert |
| ④ Nacharbeit | Entscheid/Bau wird eingetragen: delta_sweep · Register · betroffene Familien-Seiten — nichts bleibt nur im Chat | KONZEPT#01 + bauende Lane |