TGV · Governance · Stand 29.09.2026 · Stufe 2

🏗 Die Gesamt-Arbeitsweise — wie wir TGV konzipieren und erstellen

Das Szenario, für das diese Seite existiert (JC): „Stell dir vor, ich muss TGV von scratch neu aufbauen — wir wären froh, lesen zu können, wie wir mit Claude Code zusammenarbeiten und was wir in 8 Wochen gelernt haben." Hier steht das Betriebsmodell, der Weg jeder Anforderung, die Werkzeuge in Klartext, die destillierten Lektionen und die Konversations-Konventionen.

§0 · VIBE CODING FIRST — das Prinzip, unter dem alles andere steht

JC beschreibt was und wofür. Nie wie. Alles darunter — Architektur, Code, Prüfung, Auslieferung — ist Sache der KI-Organisation. Der Mensch ist nicht der Klebstoff zwischen Maschinen, und seit es mehrere Agenten sind, auch nicht der Klebstoff zwischen ihnen.

Daraus folgen vier Sätze, die den Rest dieser Seite erklären:

1. Was nur im Gespräch steht, existiert nicht. Jede Anforderung UND jede Zusage wird im selben Zug eine Registerzeile. Ein Versprechen, das nirgends steht, ist von einem vergessenen nicht zu unterscheiden (JC, 29.09.2026).
2. Was Handarbeit ist, veraltet. Was erzeugt wird, nicht. Deshalb baut master die Sammeldateien, und deshalb soll das Roadmap-Board erzeugt statt gepflegt werden.
3. Fertig ist, was ein Wächter dauerhaft sichert — und der Wächter gilt erst, wenn er einmal absichtlich gebrochen wurde. Ein grüner Selbsttest beweist nicht, dass seine Proben laufen.
4. Die Prüfung gehört an den billigsten Ort. Lokal kostet sie Sekunden, in der CI dreissig Minuten, auf master verdeckt sie jedes neue Rot.

§1 · Das Betriebsmodell — fünf Akteure, klare Rollen

Die Grundidee: ein Mensch, der entscheidet — eine KI-Organisation, die baut und sich selbst prüft. Niemand hat zwei Hüte gleichzeitig auf.

§2 · Der Weg einer Anforderung — vom Chat-Satz zum verifizierten Feature

Jede Anforderung geht denselben Weg; nichts wird „einfach mal gebaut". Die Triage-Mechanik im Detail steht im Entscheidungs-Workflow (Register #30) — hier nur die Kette:

1. Impuls: JC sagt oder zeigt etwas (Chat, Screenshot, Livecheck) — im Guten wie im Befund.
2. Arbeitsboden am Brett anmelden (seit 29.09. scharf, #2417): jede Bahn trägt Zweig und Verzeichnis in AUFTRAEGE_BRETT.md ein. ⛔ git führt jeden Pfad genau EINMAL — zwei Bahnen auf einem Boden sind für git EIN Eintrag, die Doppelbelegung ist strukturell unsichtbar. Erst die Deklaration macht sie messbar.
3. Eine Scherbe, nicht die Sammeldatei (seit 29.09., #2673): die Bahn legt EINE Datei unter CONTROL_TOWER_HANDOFF/register/ ab und fässt sonst nichts an. master baut daraus sieben Sammeldateien. Vorher kollidierten alle Bahnen an derselben Registerdatei — danach keine mehr.
4. Register-Zeile SOFORT: der Tower trägt es ins Anforderungs-Register ein (Melde-Datum + Quelle), BEVOR irgendwer baut. Chat-Sätze stranden — Register-Zeilen nicht.
5. Tower-Triage a/b: a) gebaut/entschieden → Lane setzt autonom um (+ Regel + Komponente nachziehen) · b) echter JC-Entscheid → grafische Vorlage im badge_systematik-Muster (≥2 gerenderte Varianten · Lage · Empfehlung · Entscheid-Feld).
6. Bau mit Guard-first: die Lane baut gegen den VERTRAG der Anforderung (nicht bloß Existenz); fertig heißt: ein Guard sichert es, und der Guard wurde einmal absichtlich gebrochen (JE-156).
7. Maschinelle Prüfer: Harness (Screens), familie_guard (Doku), UXAUDIT/Gate-Checks — auf echter Staging-Breite (375/880/1280 × hell/dunkel), nie localhost.
8. Deploy: PR → Self-/Tower-Merge (Doku) bzw. gated Merge (DDL/Finanz/Live) → Auto-Deploy (PLAT#02) bzw. Serve-Skript; „gemergt" ≠ „live" — die Status-Legende sagt es ehrlich.
9. JC-Blick zuletzt: Geschmack + Geschäft auf der echten URL. Was JC findet, ist eine Drift-KLASSE → zurück zu Schritt 2 (Voll-Audit, nicht Einzel-Fix).

§2b · Was eine Bahn hinterlässt — sieben Spuren, sieben Leser

§2 beschreibt den Weg. Dieser Abschnitt beschreibt, was auf dem Weg liegen bleibt — und wer es liest. ⭐ Der Satz, der alles trägt: Scherbe = Quelle, Sammeldatei = Ansicht. AUFTRAEGE_BRETT.md, ANFORDERUNGS_REGISTER_TIER_A.md, ROADMAP.md sind Ansichten, die master aus den Scherben baut — eine Bahn schreibt nie in eine Ansicht.

⛔ Jede Störung in diesem Haus ist eine von zwei Klassen — nicht sieben Probleme, sondern zwei:
⒜ Zwei Bahnen schreiben in dieselbe Spur ⇒ Konflikt. Am 09.10. kollidierten acht PRs plus #3249 an einer Datei: dem erzeugten AUFTRAEGE_BRETT.md. n Bahnen an einer Tabelle sind n² Nähte. Die Scherben-Form macht den Konflikt unmöglich, nicht unwahrscheinlich — zwei Bahnen können dieselbe Datei nicht berühren, weil jede ihre eigene hat (#2673 · #3772 · #3264).
⒝ Eine Spur hat keinen Leser ⇒ Arbeit umsonst. Gemessen 09.10.: 517 Zweige tragen Arbeit ohne offenen PR; neun Briefe an einen Tower lagen darauf, einer davon am selben Tag an den amtierenden adressiert — er wäre nie gelesen worden. Die Spur war da. Es gab keinen Leser.

⛔⛔ Und die beiden letzten Spuren hat bis zum 09.10.2026 niemand gelesen. Der Beweis steht im Haus selbst: die letzten vier Dienst-Fassungen auf master enden jede mit „LIVE NICHT GEMESSEN (Deploy = JCs Wort)" — 1.12.310 · .306 · .305 · .304. Vier Bahnen hintereinander haben ihre Wirkung nie gesehen.
⭐ Und das Deploy-Tor liegt nicht, wo man es vermutet: deploy.yml und deploy-service.yml sind push: branches:[master] plus Pfadfilter. Ein Merge, der core_shell.html oder app.py berührt, deployt automatisch ohne JCs Wort; einer, der sie nicht berührt, deployt nicht — auch mit GO.

Der Lane-Abschluss — fünf Zeilen, nicht drei (JC 09.10.2026)

1. PR + Merge-Commit (volle 40 Zeichen) → gemergt?
2. Registernummer #nnnn → für Roadmap und Ballzählung sichtbar? ⛔ Ohne Nummer ist die Bahn unsichtbar, egal wie fertig sie ist.
3. Was kann TGV jetzt, MIT Ort → gebaut? ⛔ „Konzept erstellt" ist keine Antwort.
4. Hat der Merge einen DEPLOY ausgelöst? → run-ID + der Pfad, der den Filter traf. ⛔ „kein Deploy" ist gültig — dann sag WARUM.
5. Woran sieht JC es? → Screen, Zahl, Ereignis — oder „nicht sichtbar, und das ist Absicht".

⭐ ①–③ beweisen, dass gebaut wurde. Erst ④ und ⑤ beweisen, dass es wirkt. Erst danach gilt: „Kann zu. Abgestimmt mit Tower." ⛔ Dieser Abschlusssatz stand zwei Monate nur im Chat — ein grep über den ganzen Projektspeicher am 09.10. ergab null Fundstellen. Eine Anweisung, die nur im Fenster steht, hat der nächste Tower nicht.

Die Rückkopplung — Roadmap, Monitoring, Routine

Die sieben Spuren sagen, was eine Bahn hinterlässt. Drei Einrichtungen lesen sie über alle Bahnen hinweg — sie sind der Grund, warum eine steckengebliebene Bahn überhaupt auffällt:

⛔ Die Lücke, benannt statt verschwiegen: keine der drei Einrichtungen verbindet die sieben Spuren je Bahn zu einer Zeile. Die Roadmap zeigt Spur 3 und 4, das Monitoring Spur 5 und 6, der Nachzug Spur 1 bis 3 — und niemand zieht sie zusammen. Deshalb kann eine Bahn fertig sein, ohne dass es jemand sieht. ⭐ Das ist kein neuer Wächter: alle sieben Spuren sind einzeln lesbar. Es fehlt ein Leser, der sie verbindet — und sein Ort ist gen_roadmap_board.py, weil der schon live misst und im Nachzug läuft.

§3 · Die Werkzeuge — in Klartext

§4 · Die Lektionen — destilliert, mit Narben-Beleg (1–7 aus den ersten acht Wochen, 8–12 vom 29.09.2026)

Nicht erfunden, sondern destilliert aus TOWER_REGELWERK.md (80 Narben), dem Konsolidierungsplan und den Feedback-Memories. Jede Lektion hat uns mindestens einen Vorfall gekostet.

§5 · Konversations-Konventionen — wie wir miteinander schreiben

Startbestand = Tower-Zulieferung 19.07. (wörtlich übernommen). Diese Zeichen bedeuten in JEDEM Chat dasselbe — 1 Symbol = 1 Bedeutung, wie im UI.

Asynchron lesen ohne Verlust — die Anti-„sequentielles-Lesen"-Konventionen (Tower-Zulieferung 19.07., ab sofort gelebt)

JCs Problem: die Chats laufen asynchron weiter, während er liest — Älteres zu beantworten ist verschwendete Zeit. Diese fünf Konventionen machen den Verlauf ignorierbar:

§6 · Wo das Gedächtnis gepflegt wird — neun Orte, gemessen

JC, 06.10.2026: „stelle mir diese als Tabelle, jetzt wo unser gesamtes Gehirn gepflegt wird“. Alle Zahlen sind gemessen, nicht geschätzt — und sie verändern sich. Wer sie liest, prüft das Datum. ⭐⭐ Und dieser Satz hat sich binnen 24 Stunden selbst bewiesen: Zeile 1 stand am 06.10. auf 98,7 % — fast voll, am 07.10. auf 81 % — Luft, weil eine Aufräum-Bahn in derselben Nacht lief. ⇒ Eine Zahl mit einer Bewertung daneben altert anders als eine nackte: ihre Aussage ist nicht die Zahl, sondern das Urteil — und ein falsches Urteil fordert Handlung, die nicht nötig ist. Deshalb trägt jede nachgemessene Zelle hier ihr eigenes Datum, nicht nur die Überschrift.