TGV · Design-Kanon
Neun Bau-Phasen, je ein verantwortliches Werkzeug — und der eine Kanon-Katalog, an den alles gebunden wird, damit nichts doppelt gebaut und jede Verbesserung maschinell gesichert wird. Neu verdrahtet: Screen-Factory-Vertrag, Propagation-Pfad sowie Icon- und Chart-Status als Taxonomie-Anschluss.
Von Sinn bis Deploy. Die orangen Phasen sind die Nahtstellen zum Kanon — genau dort fehlt heute die Bindung (Funktionen & Icons).
Dialog statt Ansage: KAI schlägt Zweck + Zeitgewinn vor → du validierst/korrigierst. Das Ergebnis ist eine Vertrags-Eigenschaft {intent · zeitgewinn} — verankert an mehreren Stellen, nicht nur im Hero.
Existiert der Baustein schon? Heute wird nur die Design-Seite durchsucht — der Funktionskatalog fehlt, also können Funktionen doch neu programmiert werden.
Kernfragen klären und einen echten Daten-Snapshot ziehen — nie Fantasiezahlen.
Inbox · Pipeline · Dossier · Übersicht · Klärung — je Typ fest: Sortierung, Datums-Achse, Pflicht-Bausteine, Kern-Aktion.
Die 5-Zonen-Anatomie (Header · Hero · Main · Kai · Composer) und die R-V4-Regeln legen den Rahmen fest.
Der kanonische Renderer setzt die Seite aus Bausteinen zusammen — nie handgeschriebenes Markup. Heute drei Engine-Stände, nicht vereint (darum rendern die Icons nicht).
Der Harness prüft bei jedem Laden jede Regel als echte Assertion (heute 20 Checks, „KONFORM") — aber er prüft weder Icons noch Funktions-Reuse, darum das falsche Grün.
Ehrlich sichtbar: Mockup · Staging · Live — pro Baustein. Du gibst frei.
Ein Merge auf master liefert core_shell + CSS über den SSH-Wrapper an app.startact.ai.
Sinn & Zeitgewinn ist eine Vertrags-Eigenschaft, nicht nur Hero-Text. Aus EINEM Feld {intent · zeitgewinn} gespeist und verankert an: Hero-Intro · Prompt-Chips (die Wege zum Zeitgewinn) · KAI-Initiative (proaktive Meldung mit konkreten Fällen) · Empty/Loading-States · und dem Harness-Check „liefert der Screen den erklärten Zeitgewinn?". So ist der Zweck prüfbar, nicht Dekoration. Und Phase 0 ist ein Dialog: KAI schlägt vor, du validierst — das ist zugleich der Einstieg in den in-app super_admin-Composer.
Tower-Strukturierung 13.07. (JC: „wir gewinnen an Strukturierung"): Jede Seite entsteht generativ durch die 5 Gates A–E des SCREEN-COMPOSER — und zwar in Serie über alle 26 Screens (Gesamt-Mapping). Phase 0 dieses Dokuments IST Gate A: die INTENTION (Muster: KAI_INTENTION_SSOT — eine Quelle speist System-Prompt · Hero · i18n). Fortschreibung 28.07. (JC-GO via Tower#28 — Namens-Kanon zwei Schichten): SCREEN-COMPOSER = der Skill/die Hand (die Methode: 5 Gates A–E + U0–U10 + 9-Phasen-Kanon — existiert als SSOT SCREEN_COMPOSER_SKILL.md, dort jetzt mit Intention-Prompt §🎯) · AGENT-ARCHITEKT#01 = das Gehirn (entscheidet die Komposition aus dem Intent; Name JC-bestätigt; heute KAI-Dirigent + UX-Agent, Vision = in-app via ADMIN#01). Zwei Modi KI/Manuell durch dieselben Gates; Gate-Output = Screen-DEFINITION, nie Markup (React-agnostisch); Bindung auf 4 Ebenen PROMPT·SCHEMA·GUARD·STADIUM. Ziel-Bild: die self-extending App.
| Gate | Frage | Werkzeug / Quelle |
|---|---|---|
| A · Intention | WOZU die Seite? Zweck + Zeitgewinn als Vertrag {intent, zeitgewinn} — KAI schlägt vor, JC validiert (Dialog, nie Ansage) | KAI_INTENTION_SSOT.md (Muster) · User-Stories A–U |
| B · Reuse-Check | Was EXISTIERT? ✅/⚠️/❌ mit Datei:Zeile — „NIX bauen was wir haben" (R-V4-19) | V3_INTENTION_AGENT_MAPPING.md · Katalog · Skills-Registry |
| C · Daten & Agent | Welcher Agent + welche Skills liefern? (KAI = Konversation · ORCH = Router · RAG = Wissen · Skills = Hände) | Agenten-Landschaft (Mapping §3) · MCP-Toolbelt |
| D · Screen-Typ | Welche Anatomie/Bausteine? (5 Zonen, Katalog-Komposition, nie frei). Screen-Template-Bindung (JC 28.07.): SCREEN_KANON trägt je Screen typ+bausteine aus der Screen-Typen-Taxonomie — Composer = EINE SSOT-Implementierung, Scope = Hero (K-11), Work-Mode-Bank = K-17. So bauen Screen-Composer + Architekt aus der INTENTION — der Weg RAUS aus dem Flicken. | Komponenten-Landkarte · engine.js · Screen-Typen |
| E · U-Regeln | Verhalten geprüft (U0–U10 + Harness KONFORM) — dann Stadium-Gate + JC-Abnahme | SCREEN_COMPOSER_SKILL.md · assertConformance |
Erster kompletter A–E-Durchlauf: die Seite „Frage KAI" (Gate-Report liegt vor) — sie ist der Beweis, dass der Prozess trägt. Gesamt-Programm: das V3-Mapping ordnet ALLE 26 Screens (3 Ebenen: Nav-Gruppen · 12 native Sektionen · 26 Pipeline-Karten in den 5 Finanzen-Stufen) je mit Intention + Agent + Reuse-Stand + US-Thema — und empfiehlt die A–E-Reihenfolge nach Reuse-Clustern. Warum das nötig wurde: die Prozess-Wurzel-Analyse (SEITENBAU_PROZESS_WURZEL_UND_GARANTIE.md) zeigt, warum früher am Kanon vorbei gebaut wurde — die Staging-Garantie schließt das. Quellen: 01_ITERATIONS/CONTROL_TOWER_HANDOFF/V3_INTENTION_AGENT_MAPPING.md · GATE_REPORT_FRAGE_KAI.md · SEITENBAU_PROZESS_WURZEL_UND_GARANTIE.md · Anschluss: Chatbot First §4 (Intention-SSOT) · KI-First §4 (Agenten).
Das ist der fehlende Baukasten-Vertrag zwischen deiner User-Intention und einer echten Seite. Eine Änderung ist erst sauber vorbereitet, wenn diese Felder ausgefüllt sind — sonst propagiert sie zufällig statt systematisch.
| Feld | Pflicht | Status | SSOT / Anwendung |
|---|---|---|---|
| intent | Zweck + Zeitgewinn in einem Satz; muss Hero, Empty-State und KAI-Initiative speisen. | 🟡 | KAI_INTENTION_SSOT.md · Gate A |
| screen_type | Genau ein Typ: dialog · inbox · klaerung · pipeline · uebersicht · dossier · formular · admin · system. | 🟡 | Taxonomie screen-typen · V3-Mapping §2 |
| data_sources | Welche MCP-/Skill-/View-Daten liefern Wahrheit; keine Fantasiezahlen, keine Frontend-Keys. | ✅ | Gate C · Skills-Register · RLS-Regeln |
| k_ids | Pflicht-Bausteine aus Komponenten-Katalog; neue Komponente nur mit K-ID und Regeln. | ✅ | komponenten_data.js · konzept_komponenten.html |
| fx_or_skills | Funktion nur aus FX/Skill-Katalog oder als neuer registrierter Vertrag; kein Screen-lokaler Sonderbau. | 🟡 | TGV_FX · 02_SKILLS/_registry.yaml · Funktionskatalog noch zu vereinen |
| icon_slugs | Nur Slugs aus dem Icon-Manifest; Emoji/SVG lokal nur begruendeter Fallback. | ✅ | Icon-Systematik · icons-global.json · Guard gegen unbekannte Slugs |
| chart_specs | Charts nur über TGVRenderers.chart(spec, ctx); erlaubte Typen: line, area, bar, stacked-bar, pie. | 🟡 | tgv_renderers_chart.js · costs.html |
| workbench_zone | Wo lebt das Ergebnis: sidebar, header, context, composer oder result_panel? | 🟡 | konzept_chatbot_first.html#workbench |
| module_package | Welches Produkt-/JC-Modul nutzt oder erzeugt der Screen: Dokumente, Buchhalterpaket, Reconciliation, RKA, Verträge, Projekt A/B? | 🟡 | screen_factory_contracts.json |
| menu_scope | Wo erscheint der Screen im linken Menü/Rail, und für wen: User, Mandant, super_admin? | 🟡 | screen_factory_contracts.json |
| abnahme | Gate A–E + Harness + Live-Link; Tower#29 nimmt zuerst den Vertrag, dann den Screen ab. | 📝 | Roadmap · Gate-Report · Guard noch zu formalisieren |
Taxonomie-Anschluss: screen-typen · screen-template-vertraege · propagation-pfade · icons · chart-typen in taxonomie_data.js. Maschinenlesbarer Vertrag: screen_factory_contracts.json; Guard: 08_OPS/check_screen_factory_contracts.py. Damit ist der Vertrag nicht nur sichtbar, sondern erstmals pruefbar; Code-Enum und breitere Screen-Abdeckung sind die naechsten Root-Fixes.
Der Screen-Vertrag oben ist der bewährte Fall — 12 Verträge, 22 Pflichtfelder, Guard grün seit 29.07. ⛔ Er wird nicht kopiert, er wird erweitert. Dieselbe Datei-Idee, dieselben Kernfelder, derselbe Prüfer-Ansatz.
| Gegenstand | Kernfelder | Stand |
|---|---|---|
| Screen | 22 Felder, intent zuerst · abnahme · next_guard | ✅ 12 Verträge · Guard grün |
| Skill / Agent | intent · Zusagen (was ist danach immer wahr, inkl. Fehlverhalten) · Anschluss (rein/raus + was er anfassen darf) · next_guard | 🟡 Registry vorhanden, Zusagen fehlen |
| Prompt | wie Skill — ⛔ plus Abnahmetest: Fragen mit erwartetem Verhalten | 📝 nichts — siehe Kasten unten |
| Absicht | Nummer · Zustand · Ergebnis · Spur · gedeckte Zusagen · Fertigungsgrad | 📝 Konzept §6 (E-67) |
next_guard ist „geschrieben", nicht „fertig" — und eine, die nicht deployt ist, existiert für den Menschen nicht. Owner der Lücke: der VERDRAHTER.localStorage des jeweiligen Browsers — 06_DASHBOARD/core_shell.html:4779 (VKEY="tgv-conf-verdict") · :4780 (verdicts()) · geschrieben nur vom eigenen Rundgang (:4789).
agent_events), der lokale Rundgang ÜBERLAGERT sie nur, wenn er frischer ist; Tooltip nennt Messzeit und Messenden. Bis dahin die ehrliche Zeile: „Punkt = dein Rundgang in diesem Browser". Owner: CANON-GARANTIE#01 (Welle E4/E5).
next_guard fast aller Aussagen zeigt auf 08_OPS/check_konzept_master_contract.py — eine Datei, die nicht existiert (im Verzeichnis-Listing von 08_OPS/ geprüft, 16.08.).
next_guard-Einträge sind Wunsch-Namen („Datenfluss-Master-Guard", „Rollenmatrix-Guard"). Eine Aussage, deren Prüfer ein Name ist, ist nicht geprüft — sie ist geplant.
next_guard ist ein PFAD auf eine existierende Datei, nicht ein Name ④ „geschrieben" ⇒ gesucht_in ist gefüllt — R-193 in Feldform: Abwesenheit gilt nur so weit, wie die Liste reicht, die sie geprüft hat.
Der frühere Bruch war nicht die Idee, sondern die Weiterleitung: Festlegung im Chat → irgendwo dokumentiert → nicht zuverlässig im Screen. Der neue Pfad macht aus jeder Festlegung eine abnehmbare Kette.
| Schritt | Was passiert | Owner | Beweis |
|---|---|---|---|
| 1 · JC-Intention | Änderung als Nutzermehrwert formulieren, nicht als isoliertes UI-Wort. | JC + Tower | Roadmap-Zeile / Gate-A-Notiz |
| 2 · Taxonomie | Neue Achse oder neuer Wert wird in der passenden Taxonomie sichtbar. | TAXO#01 | taxonomie_data.js |
| 3 · Katalog | Komponente/Funktion/Icon/Chart erhält genau eine autoritative Quelle. | DESIGN#01 / DATAVIZ#01 / PLAT#05 | K-ID · Skill · Icon-Slug · Chart-Whitelist |
| 4 · Renderer/Skill | Die Anwendung konsumiert den Katalog statt lokaler Kopie. | Implementierungs-Lane | Code-Call, z.B. safeIco oder TGVRenderers.chart |
| 5 · Screen | Screen-Vertrag nennt Typ, Daten, Bausteine, Funktionen und Link. | SCREEN#01 | Gate-Report / Screen-Kommentar |
| 6 · Harness | Rückfall wird rot: lokales Icon, direkter ECharts-Aufruf oder fehlender Vertrag darf nicht grün bleiben. | AGENT-UX#01 / Tower#29 | Negativ-Test + CI/Guard |
Beides existiert im Repo. Der Unterschied ist wichtig: vorhanden ist nicht automatisch angewandt und geprüft.
| Baustein | Vorhanden | Anwendung | Status bis Freitag |
|---|---|---|---|
| Icon-Generator | 96 Slugs, Manifest, Sprite, PNG/SVG, Contact-Sheet, Generator-Spec und Guard. | Icon-Systematik zeigt Bedeutung, Kontext, Ersatzsymbol und Erweiterungsweg. | ✅ Menschlich sichtbar + Screen-Factory prueft unbekannte Slugs; flächiger Runtime-Emoji-Scan bleibt naechster Ausbau. |
| eCharts | Vendored /vendor/echarts.min.js plus TGVRenderers.chart(). | costs.html nutzt stacked-bar über Renderer; keine direkten ECharts-Calls im Screen. | 🟡 Repo-seitig verdrahtet; Live-Link/DNS hier nicht verifizierbar. |
| Chart-Typen | Whitelist: line · area · bar · stacked-bar · pie. | Spec muss Daten vom Aufrufer bekommen; Renderer holt nie selbst Daten. | ✅ Taxonomie aktualisiert; Guard blockt direkte ECharts-Nutzung ausserhalb Renderer. |
Sichtbar verdrahtet: Icon-Systematik mit Katalog, Generator-Vertrag, Einsatzregeln und Projekt-Typ-B-Erweiterung; speziell: Serien / Projekt Typ B.
Zwei Regale, eine Quelle der Wahrheit. Der Composer wird gezwungen, hier zuerst zu suchen; der Harness sichert, dass alle es anwenden.
iaComposerBody · fragekai2 · rka2 · abgleich2 · inbox2 · verlauf2 · versand2 · projekt2 · rka_chat · dokumente2 mit eigenem .composer-Vokabular.
composerHtml(cfg) · :2690 mountComposer(host,cfg) · :3323 Export als K-16-Heimat; die Flächen deklarieren nur noch ihren Slot ([data-composer-mount], :2731). Der Renderer selbst wurde Konsument seiner eigenen Heimat (:961-962) — kein Sonderweg für den Erfinder.
Multimandant · Multilingua · Produkt/Version · Datenschutz sitzen NICHT in einer Phase — sie ziehen sich quer durch. Der saubere Weg: jede wird eine Vertrags-Achse im Katalog — jeder Baustein deklariert sie, der Composer (Gate B) prüft sie, der Harness sichert sie.
| Anforderung | Greift in Phase | Baustein · Regel | SSOT |
|---|---|---|---|
| Multimandant | 2 · 4/5 · 6 | RLS-scoped Reads (mandant_id) · Scope-Frame-Komponente (R-88/90, „Wir schauen auf: {Mandant}") · Regel „jeder Read mandant-scoped, default-deny" | Identity/RLS-SSOT · super_admin / mandant_admin / viewer |
| Multilingua | 4/5 · 6 | Kein hardcoded Text → t() / i18n-Keys · i18n-Katalog (7 Sprachen) · Regel „keine nackten Strings im DOM" | DESIGN#04 · i18n/*.json |
| Produkt / Version | 0/3 · 7 | PRODUCTS-Registry (core · gabriel · klassik) · Stadium Mockup/Staging/Live — ehrlich pro Baustein | V4-Cockpit · PRODUCTS |
| Datenschutz | 2 · 4/5 · 6 | Conf-Filter + Owner-Bypass (Rolle→conf_max) · 3-Achsen-Badge (Geheimhaltung 🔒) · Regel „Conf-Badge Pflicht + kein Scope-Leak" · Beleg-ID immer mit Drive-Link (R-91) | KONZEPT_VERTRAULICHKEIT v1.1 |
Der Clou: Diese vier werden nicht „drangeklebt" — sie sind Spalten im Katalog-Vertrag. Jeder Skill/FX-Baustein deklariert seinen Scope, seine i18n-Keys, sein Produkt und seine Vertraulichkeit. So prüft der Composer sie automatisch mit und der Harness wird ROT, wenn eine fehlt — dieselbe Mechanik wie bei Komponenten & Funktionen.
Wo du im Bau siehst und wie dein Feedback zurückfließt — gebaut, nicht angekündigt: der Feedback-Panel geht an die Lane, nicht in den Chat.
KAI schlägt Zweck + Zeitgewinn vor → du validierst/korrigierst, BEVOR gebaut wird.
Im Katalog: Freigeben · ✋ Änderung anfordern · „Senden" → 🟡-Eintrag mit Historie · Feedback exportieren.
Du siehst KONFORM / ROT — die maschinelle Prüfung statt Augenmaß.
Stadium sehen (Mockup · Staging · Live) + Freigeben, pro Baustein.
Auf jedem live/staging-Screen: Feedback anklicken → direkt an die Lane (audit_events-Roundtrip, #921), nicht in den Chat.
Der Loop: sehen → Feedback-Panel / *-Präfix → LANE → Freigabe → Deploy.
Der Abschnitt darüber sagt, was fehlt. Dieser sagt, wie es aussieht, wenn es kommt — und er ist hier eingefaltet, nicht danebengelegt: derselbe Vertrag, dieselben Gates, dasselbe Kanon-Vokabular. ⛔ Der Agent wird hier nicht gebaut. Was hier steht, ist die Grenze, an der er später gebaut werden darf.
| Stufe | Was entsteht | Wer darf | Modus im chat_engine | Wirkung |
|---|---|---|---|---|
| screen_composer.propose | EINE Screen-Definition nach den 22 Pflichtfeldern von screen_factory_contracts.json plus Gate-A–E-Report. Nie Markup, nie CSS, nie eine neue Fachaktion. | Nutzer in seinem lesbaren Scope | read — muss ausdrücklich in tool_modes.read stehen | keine Änderung, kein Code |
| screen_composer.preview | isolierte Vorschau aus einer freigegebenen Definition — Worktree/Preview, nie eine Produktivseite. | super_admin, ausdrückliche Freigabe je Vorgang | action → Freigabekarte → Vollzug | Vorschau; kein Merge, kein Deploy |
| screen_composer.uebergabe | vollständiges Tower-Paket (Definition · Gate-Report · Guards · Retests). | super_admin | action | Tower entscheidet Bau, Merge und Release |
Warum das keine freie Markup-Frage ist: das Modell liefert Intent, der Renderer macht daraus TGV-Komponenten. Die Grenze steht bereits maschinenlesbar — detail_view_contract.agent_entscheidet in screen_factory_contracts.json: der Agent wählt, ordnet und lässt weg, und er darf nicht neue Block-Typen oder CSS erfinden, den Rahmen ändern, Vokabeln erfinden, Aktionen ohne Skill-Naht scharf schalten oder Scope/RLS anfassen. ⇒ Der Werkzeug-Vertrag erfindet diese Grenze nicht neu — er macht sie zum Ausgabeformat.
| Zusicherung | Wer sie hält (Fundstelle) | Gegenprobe |
|---|---|---|
| „ändert nie selbst" | descriptor.ChatInstance.is_action_tool — ein Werkzeug ist nur read, wenn es ausdrücklich in tool_modes.read steht; alles andere → Freigabekarte. Default-Deny am Griff. | erklärtes read-Werkzeug fällt gegenteilig aus |
| „der Loop kann es nicht fahren" | tools.build_tool_defs hängt einem action-Werkzeug keinen Executor an. | read-Werkzeug bekommt seinen Executor |
| „nichts ohne Klick" | tools.make_approval_card — state=pending, approval_tier=jc_direct, reversible kommt aus dem Vollzug, nicht aus einer Behauptung. | freigabe-erteilen meldet reversible=true |
| „merged und deployt nie" | vollzug.VOLLZUG_REGISTER kennt kein Composer-Werkzeug ⇒ kein_weg_satz, ohne Zustandswechsel. Ein Werkzeug kommt dort erst hinein, wenn Schema und Endpunkt-Body gemessen zueinander passen und der Endpunkt die Rechte des Aufrufers prüft. | das Register ist nicht leer |
| Scope & Default-Deny | Der Scope kommt aus der Mitgliedschaft des Aufrufers (user_mandant_roles → _user_scope → apply_scope_to_tool_args), serverseitig nach der Werkzeugwahl injiziert; das entity-Enum im Schema trägt nur die erlaubten Entitäten (tools._scoped_parameters, #150). Eine fehlende Sichtbarkeitsdeklaration bleibt deny. | leere Menge ⇒ entity entfällt, Executor filtert __scope_none__ |
| screen_request_id | Kein neues Register. Der Vorgang ist bereits identifiziert: gespeicherter Envelope chat_messages.envelope_json + block_index — genau das Paar, mit dem vollzug heute eine bestätigte Karte wiederfindet, und die Werkzeug-Argumente des Turns fahren seit #1905 mit. | Vollzug liest die Karte vom Server, nie vom Browser |
⭐ Der Ertrag dieser Messung: die härteste Zusage des Vorhabens — der Agent ändert, merged und deployt nie selbst — ist keine neue Sicherung, sondern das vorhandene Default-Deny. ⛔ Und ihre Kehrseite steht im selben Satz: vergisst jemand die Zeile tool_modes.read für propose, wird aus dem Vorschlag eine Freigabekarte für einen Entwurf — die Stufe, die wirklich Freigabe braucht, verschwindet dann hinter einer, die keine braucht.
08_OPS/check_composer_vorschlag_trennt_die_stufen.py, eingehängt in .github/workflows/konformitaets-guards.yml (Schritt ㊽, Selbsttest + Lauf) — in beiden Pfad-Blöcken, push und pull_request. Ausgelöst wird er von 08_OPS/** und von staged/chat_instances.json: ohne die zweite Zeile wäre er blind für genau die Änderung, die er fangen soll. Netzfrei.
| Frage | Angriffspunkt heute | Mutation, die ihn rot macht (Selbsttest) |
|---|---|---|
| Default-Deny steht | ja | M6 — is_action_tool liefert immer False |
| kein Executor für action | ja | M7 — Executor an ein action-Werkzeug gehängt |
| kein Vollzug ohne Register | ja | M5 — Composer-Werkzeug ins VOLLZUG_REGISTER eingetragen |
| Composer-Werkzeug trägt seinen Vertrag | ⛔ nein — heute ist keins deklariert. Der Guard meldet das als NOTIZ „ohne Angriffspunkt", nicht als Grün. | M1 propose als action · M2 preview im Loop · M3 propose ohne eigenes Schema · M4 leerer Suchraum |
Lauf am 25.09.2026: Guard grün (Fragen 1–3 gemessen, Frage 4 als ungeprüft ausgewiesen), Selbsttest 8/8 — M8 ist die Negativkontrolle: der unveränderte Bestand muss sauber sein, sonst wäre ein dauerrotes Werkzeug von einem scharfen nicht zu unterscheiden. ⛔ Was dieser Guard NICHT misst: die super_admin-Wand der Vorschau — sie sitzt an einem Dienst-Endpunkt, den es noch nicht gibt, und ist nur am angemeldeten Dienst mit getrennten Testidentitäten messbar. Kein Urteil, nicht grün. Retest, sobald die Vorschau-Stufe existiert: dieselbe Definition unter super_admin, mandant-admin und viewer, mit Positivkontrolle (super_admin bekommt die Vorschau) und Gegenbeweis (die beiden anderen bekommen sie nicht, und der Grund heißt Berechtigung, nicht „keine Daten").
Die 9 Phasen bauen EINE Seite (innerer Kreis). Die Lernschleife macht den KATALOG selbst besser — aus jedem Vorfall, Feedback, Muster. So wächst der Kanon aus Erfahrung und vergisst nie („war vergessen" ist strukturell ausgeschlossen).
Vorfall · Feedback-Panel · Eval-Befund · Muster (pattern-engine) · Telemetrie
Befund = Hypothese, nie auto-angewandt — die Lane prüft & darf widersprechen
Der Baustein/Skill trägt den Guard selbst — kein Merksatz im Handbuch
Prompt · Schema · Guard · Stadium → neuer Katalog-Eintrag / R-V4-Regel
Harness wird ROT bei Rückfall — Anti-Amnesie, kein Reinvent
„KAI hat X gelernt · eure Klärung leert sich schneller" — DSGVO-Transparenz + Nutzen
↺ zurück in den Katalog — die nächste Seite baut schon mit der Lehre.