TGV · Design-Kanon · Vollversion · Stand 2026-07-17

Regelwerk

Alle verbindlichen Design-Regeln — mit vollem Text, ehrlichem Status und Verweis auf die Bausteine, die jede Regel tragen. Zwei Quellen, hier vereint: die Bau-Checkliste (regelwerk.html, R-01–R-97) und der ausführbare Harness (engine.js assertConformance, 60 Checks bis R-148). Zusammenführung 25.07. (Register #139/#140): vollständige ID-Parität mit dem KANON-Pflegeort regelwerk.html (99 Regeln, Guard C8 wacht täglich); Text-Stil darf je Sicht abweichen (dort Harness-ROT-Kriterien, hier Konzept-Lesart) — die Regel-MENGE nicht. Ein-Quellen-Umbau (ein Pflege-Ort, zwei Ansichten) = Stufe 2 nach der Tower↔KANON-Klärung.

Die Guard-Spalte — jede Regel nennt ihren Guard oder ist ehrlich „nicht erzwungen" (Guard-First) ⚙ Harness-GateGUARD AKTIV: assertConformance prüft die Regel ausführbar — Screen wird ROT bei Verstoß. 📋 Checkliste⛔ NICHT ERZWUNGEN — steht nur auf Papier, wird manuell abgehakt. Manuelles Abhaken ist kein Guard. 🧩 Code-Kanonim Harness erzwungen, fehlt aber in der Checkliste — der Mensch sieht die Regel nicht (Nachtrags-Kandidat). ⚠ korrigiertQuelltext war veraltet — hier gegen den neuesten Kanon-Stand korrigiert (Beleg im Kasten).

⛔ GUARD-FIRST — die Regel über den Regeln (JC-Direktive 17.07.)

„Eine Arbeit gilt erst als fertig, wenn ein Guard sie dauerhaft sichert. Und ein Guard, den niemand absichtlich gebrochen hat, ist kein Guard."

Warum es entstand — drei Bugs derselben Klasse an EINEM Tag, alle im PRÜF-Pfad (17.07., DESIGN#03: „Nicht nur die Regeln lügen, auch die Prüfer"):

Werkzeug	Meldete	War tatsächlich
ssh ohne -n	exit 0 = „Erfolg"	Skript lief NIE
curl \| grep -q	„i18n-Key fehlt" (SIGPIPE + pipefail)	i18n war vollständig da — Fehlalarm
Harness-Scoping	42× grün, 0 Fails	prüfte 1 von 7 Screens

Der Meta-Fund: Der CI-Guard no-sigpipe-grep-q triggert nur auf 08_OPS/server/** — der Verstoß lag seit G1 drin und wurde nie geprüft, weil kein PR den Pfad berührte. Ein pfad-getriggerter Guard ist blind auf allem, was niemand anfasst. „Guard grün" heißt nur „Guard LIEF." Konsequenz: jeder neue Guard wird beim Bau einmal absichtlich verletzt (Negativ-Test) — sonst ist er Behauptung. Vorbild: r5_gate_proof.py (Sicherheit §9).

Der Fall, der es unausweichlich macht — Tower selbst: TOWER_REGELWERK.md (17.07.) extrahierte 80 Tower-Regeln aus ~60 Dateien — 55 wären messbar, NULL sind erzwungen. Screens haben einen Harness, Code hat CI, Tower hat nichts; Regel F1 lautet „binde strukturell, nie ans Gedächtnis" — und ist selbst nur ans Gedächtnis gebunden. 80 Regeln × Gedächtnis = Drift ist garantiert, nicht zufällig. Rolle vor Regeln: JCs Rollen-Definition steht ÜBER den Regeln (project_tower_rolle_definition) — erst Rolle, dann Regeln; ein Regelwerk aus Narben erzeugt Vermeidung, keine Führung.

⚖ Kollisionsregel (bisher undokumentiert, ab jetzt Kanon): Bei Regel-Konflikt gewinnt jüngeres Datum + „FINAL"-Markierung + Begründung. Die ältere Quelle wird sichtbar als überholt markiert — nie still weiterverwendet.

🧪 Neue Regel-Kandidaten (KANON#01, 18.07., Vorfall-belegt — werden Regeln mit Guard): ① Transport/Form-Verify hat NICHT den Inhalt geprüft — „Datei kommt an / parst" sagt nichts über „Inhalt aktuell/korrekt"; Aktualität ist eine EIGENE Prüf-Achse. ② Ein Merksatz ist kein Guard — was nur in Doku/Memory steht, ist Wunsch; erst Schema/CI/Harness macht es zur Grenze (deckungsgleich mit Guard-First-Kern + R-159).

🧪 Regel-Kandidaten aus dem Klärung-Workflow (JC 18.07., Register #15–#24 — Nummern vergibt KANON#01; Re-Bestätigungen wurden an JE-090/R-147/doc-steckbrief ANGEDOCKT statt doppelt angelegt): ① Frage-Mitnahme beim Kontextwechsel (#24 — die einzige echte Workflow-Neuerung: eine offene User-Frage reist beim Fall-/Screenwechsel mit, geht nie verloren) · ② Scrollbar-Stabilität (#16, scrollbar-gutter — kein Layout-Springen beim Auf-/Zuklappen) · ③ Composer-Hintergrund/Strich endet an der Konversationsspalte (#19) · ④ Hero-Breite (#20 — links/rechts breiter als der Inhalt) · ⑤ Panel-Rückweg mit Ziel-Nennung (#12, JC-Livecheck: jedes Panel trägt expliziten Rückweg „zurück zu X" — überall gleich; koppelt an #4 Panel-Kontext-Verlust) · ⑥ EINE einheitliche Beleg-Öffnung (#17, JC: „in 5 Minuten 4 verschiedene Darstellungen" — EIN Muster je Kontext, dokumentiert).

⚠ Bekannte Quellen-Divergenzen (Stand 17.07. — wer die ALTE Quelle liest, baut Falsches):

Drei Regel-Nummernkreise ohne Zusammenführung: regelwerk.html R-01…97 · engine.js R-104…148 · core_shell R-V4-01…21 → KANON#01 führt zusammen.
R-131 (Composer-Farblogik, JC 10.07.) steht NUR in engine.js — fehlt in regelwerk.html, der Liste, die JC zur Abnahme nutzt.
Bibel §F verlangt den „Im Kontext"-Chip — den JC selbst als Defekt hat entfernen lassen (#712). §F ist an dieser Stelle überholt.
U10 (JC FINAL 06.07.): KEIN zentrales Chat-Log, Antworten IN-PLACE — Bibel §F und das Gold-Mockup (Stand 03.07.) verlangen weiter den Chat-Strip → beide überholt (Kollisionsregel: U10 gewinnt). Wer dem Gold folgt, stellt JCs abgeschafften „zerrissenen Chat" (RKA-v3-Fehler) wieder her.
SCREEN_COMPOSER_SKILL.md nennt sich „die EINE SSOT" und kennt R-95/96/97 nicht (zählt bis R-94) — ausgerechnet R-95 löst den U-Konflikt auf.
Selbst-Widerspruch im Composer-Skill: U7 (Z. 92) sagt „keine feste ‚vor Kaï'-Ordnung mehr — Kaï ist in-place"; das ASCII-Anatomie-Diagramm im SELBEN Dokument (Z. 135–136) zeigt weiter die feste KAÏ-Zone.
R-42 ↔ R-95 widersprechen sich fail-closed (bekannt, project_regel_quellen_divergenz).

Abgrenzung: Den Maschinen-Vertrag (Nummernkreise zusammenführen, Guards bauen) macht KANON#01 — diese Seite ist die Menschen-Doku und hält die Divergenzen sichtbar, bis sie strukturell geheilt sind. Die Familie wendet Guard-First auf sich selbst an: familie_guard.py prüft Struktur (tote Links · Hub-Vollständigkeit · Shell-Register · i18n) ausführbar — inhaltliche Veraltung fängt kein Skript, dafür gilt das Pflege-Ritual + diese Divergenz-Liste.

Pflege-Disziplin (Anti-Drift): Diese Seite ist die menschliche Vollversion des Kanons. Ändert sich eine Regel, ziehen vier Orte gleich: diese Seite · die Checkliste regelwerk.html · der Harness engine.js · die Komponenten-Landkarte. Die strukturelle Bindung (Guard statt Gedächtnis) baut KANON#01 — 🧩-Regeln sind dessen Nachtrags-Liste, ⚠-Korrekturen sind die verifizierten Veraltungen.