TGV · Design-Kanon · Abnahme-Kompass
Diese Seite erzeugt kein neues UI-System. Sie verdrahtet vorhandene Quellen: kai_chat.css, PLAT_06/components.css, V4_SCREEN_REGISTER.md, core_shell.html, chat_component_library.html, CHATBOT_UX_BIBEL.md, foundation.css, katalog.html und jc_entscheide.html. Sie ersetzt nur meine freie Beispielansicht aus diesem Thread, damit Claude Code/Tower nicht nach Bauchgefuehl baut.
app.startact.ai/core_shell.html#/klaerung-min zeigt teils lokale min#-Overrides. Sie sind nicht automatisch Kanon. Kanonisch ist zuerst foundation.css plus dokumentierter JC-Entscheid; Live-Abweichungen werden hier als Drift oder Uebergang markiert.foundation.css/engine.js enthalten noch alte Teile; die sichtbare Abnahme hier folgt JCs juengster Festlegung und muss als Guard in den Renderer zurueck.| Baustein | Gilt jetzt | Alternative / Drift | Quelle | Status |
|---|---|---|---|---|
| Hero-Collapse | .zone-hero__headrow: Scope-Chip und Collapse-Toggle rechts oben in einer Zeile; Toggle 30x30 mit sichtbarer Kante; Body klappt sanft. | .heroCollapse/#klHeroCollapse in min# ist groesser/ds-btn-artig und teils mit ▲/▼. Das ist Live-Drift bzw. Uebergang, nicht die finale Kanon-Quelle. | foundation.css R-126/R-02 · jc_entscheide.html JE-053 | gilt Live-Drift |
| Buttons | .ds-btn Basis; Primary/Confirm/Danger als Outline; .ds-btn--solid selten fuer Haupt-CTA; Prompt = gestrichelte Kante; UI/Panel = durchgezogene Kante. | Altes .ds-btn--ghost ohne Rahmen ist verworfen. Tertiaer/Ghost muss immer sichtbare Kante haben. | foundation.css JC 07-07, R-127/Q6 · core_shell.html Register #119c | gilt |
| Senden | Runder Paper-Plane-Button send-round/.ds-composer__send, SVG currentColor, keine Pfeil-Glyphe. | Variante A Pill+Label und Variante C inline wurden verworfen. | CHATBOT_UX_BIBEL.md §0M · jc_entscheide.html JE-070 | entschieden |
| Pillen / Badges | 3 Achsen als runde .ds-axis-Pillen. JC-Abnahme jetzt: Entitaet ohne vorgelagerten Punkt, Geheimhaltung mit EU-Flagge/Schloss, Konfidenz als gelber KI-Funke mit Abstufung und gerader linker Kante. | foundation.css/engine.js rendern noch Farbpunkt und Zauberstab/blau. Das ist kein neuer Stil, sondern Drift aus alter Quelle; Guard muss diese beiden Renderpfade nachziehen. | foundation.css R-100 · engine.js bxBadges · icons-manifest.json ai-spark JC-GO 18.07 · JC-Review 29.07 | Drift-Audit |
| Links / Quellen | .srclink fuer Quelle/Beleg/RAG: Chip mit Rahmen + Unterstreichung. Inline-IDs muessen selbst klickbar sein. | Nackte IDs wie #1005 ohne Link sind verboten; reine Textlinks nur fuer Navigation/Fliesstext. | foundation.css R-91 · Katalog Guard fuer nackte IDs | gilt |
| Composer | Ein geteilter Baustein: iaComposerBody() + wireComposerCore() bzw. .ds-composer. Enthält Feld, KAI-Persona, [+]-Menue, Mikro/Diktat je Capability und runden Send-Button. Auto-Grow bis max. 40vh ist Pflicht; Modell-Auswahl ist kein Standard-Control. | Screen-eigene Composer, eingebettete Composer auf Karten und tote Capability-Buttons sind verboten. Capability false = aktiver Button weg, im [+]-Menue nur als "bald" sichtbar. | V4_SCREEN_REGISTER.md R-V4-17/19 · core_shell.html 1694/2096 · components.css .ds-composer | SSOT |
| Composer im Kontext | Eine bestimmte Antwort/Karte verbinden = Thread/Kontext betreten: Composer unten bleibt der einzige Eingabeort, wird blau getoent, fokussiert, Placeholder wird kontextuell; Ausstieg ueber "Thread verlassen" bzw. Kontext verlassen. | Kein AN/AUS-Kontext-Toggle, kein zweiter Composer in der Karte. Alte Thread-Context-Toggle-Fassung ist laut Bibel ueberholt. | V4_SCREEN_REGISTER.md R-V4-05/R-V4-13 · CHATBOT_UX_BIBEL.md §0e/§0f · core_shell.html 7404ff | gilt |
| Conversation-Abstaende | .kai-thread: max 820px, zentriert, gap 14px. KAI links mit Avatar und blau-grauer Bubble; User/ICH rechts, weiss mit Rahmen, max 80%. KAI-Bubble max 94%, wide 100% fuer Tabellen/Frames. | App-Min setzt eigene Spaltenbreite ueber --content-col; Composer und Antwort muessen dieselbe Spalte teilen. Unterschiedliche linke Kanten sind Drift. | kai_chat.css Zeilen 8-18 · core_shell.html 7364ff | gilt |
| KAI-Antwort-Frame | Wenn KAI eine Sektion, Tabelle, Ergebnis oder Felder rendert, gehoert die ganze Antwort in den KAI-Content-Frame: Avatar links, Rahmen/Hintergrund, Intro und Inhalt zusammen. | Nicht nur Intro-Satz als Bubble und danach rahmenlose Tabelle. Reiner Chat-Modus darf normaler Thread bleiben. | CHATBOT_UX_BIBEL.md §0c · kai_chat.css .msg/.card/.longprose | gilt |
| Hintergrund / Einrahmung | R-127: App-Hintergrund, Zone, Card, Inset sind eigene Schichten; hoeheres Element braucht Kontrast durch anderen Ton, Rahmen oder Schatten. | Grau-auf-Grau ohne Kante, transparente Ghost-Buttons, lokale Card-Kopien sind Drift. | katalog.html R-127 Surface/Elevation · foundation.css | gilt |
| Motion | Motion ist Bedeutung: Button-Done, Collapse, Thread-Tint, Row-Leave 2,4s, KAI-Work-Punkte; prefers-reduced-motion schaltet ab. | Lokale schnellere Animationen wie klCardLeave 1.15s sind Screen-spezifische Drift, falls sie Erledigt-Row ersetzen. | foundation.css R-80..R-83 · jc_entscheide.html JE-100/JE-101 | gilt Min pruefen |
| Panel / Dock | Dock/Panel = Arbeitsplatz bzw. pruefbares Ergebnis. Chat bleibt Entscheidung/Erklaerung; Panel zeigt Steckbrief, Tabelle, Chart, Dossier, Vorschau. | Panel-Trigger muss als Aktion erkennbar sein, nicht als unscheinbarer Textlink. Mobile = Sheet. | foundation.css Dock · katalog.html R6 Dock/Steckbrief · KAI-Antwortvertrag | gilt |
Aktionstyp = Kante: gestrichelt fuer Chat/Prompt, durchgezogen fuer UI/Panel. Tertiaer bleibt sichtbar. Definition = SSOT K-20 (kai-action-buttons) — diese Karte referenziert, definiert nicht neu (E-2).
Nur gestrichelte Prompt-Buttons fragen KAI indirekt: sie befüllen den Composer mit Kontexttext, der User sendet bewusst ab.
Viele TGV-Icons sind selbst Button-Funktionen. Vorhandene Slugs aus der Icon-Systematik: fullscreen, expand, detail, search, download, close, collapse, attachment, attach-plus. Darstellung hier ist Funktionskatalog; echte SVGs kommen aus dem Icon-Resolver.
Der erste Button ist absichtlich falsch: keine Kante. „Detail ›“ kann in Live-Min vorkommen, muss aber in den Panel-/Quellen-Kanon eingeordnet werden.
core_shell.html, NAVIGATION_KONZEPT.md, K-01/K-06 und dem alten Katalog-Zonenbild. Shell ist die Huelle; gebaut wird nur im Main Content.Titel, Scope, KPI oder Navigation; kollabiert auf erste Zeile.
Liste, Tabelle, Karten, Dossier, Chart oder Formular.
Konversations-Hintergrund. Nur diese Fläche ist grau/blau hinter KAI/ICH.
Sticky unten, eigener Bereich; wächst nach oben bis 40vh.
Sekundärmenü filtert nur diesen Screen; es ersetzt nicht die globale Navigation.
Z1 Header, linkes Menü, rechtes Panel und Z6 Footer sind Shell. Die Screen-Factory komponiert nur innerhalb von MAIN CONTENT: Z2 bis Z5.
Stabiler Titel, Scope, KPIs oder Navigationskarten.
Fachliche Arbeit: Liste, Tabelle, Dossier, Chart, Formular, Karten.
Antworten, Rückfragen, eingebettete Tabellen/Karten/eCharts; eigener Konversations-Hintergrund.
Universal; Persona, Anhang, Diktat, Senden; sticky unten.
Vorhandenes Muster aus app.startact.ai: Gruppen sind aufklappbar, Items tragen TGV-Icon links und Statuspunkt rechts.
Regel: Das Grau ist die Hintergrundfarbe der Konversation (Zone 4), nicht der ganze Screen. Jede lange KAI/ICH-Antwort bekommt denselben Collapse-Mechanismus rechts oben.
Normalzustand, unten fest verankert
Langer Text: Feld wächst, danach Scrollbar rechts
Regel: Keine Modell-Auswahl im Standard-Composer. Links stehen Persona-Auswahl KAI, Büroklammer und Mikro. Rechts steht nur die runde Paper-Plane. Das Eingabefeld wächst nach oben bis max. 40 Prozent Viewport-Höhe; weitere Capabilities gehen in das Werkzeug-Menue oder werden per Backend-Vertrag freigeschaltet.
KAI laedt den User ein, direkt zu dieser Karte zu antworten. Antwortblock und Composer bleiben zwei Bereiche: unten an der Antwort eckig/graue Kante, oben am Composer eckig/graue Kante, dazwischen 4px Abstand. Blau zeigt nur den aktiven Bezug.
Regel: Aktiv gebundene Direktantwort = blauer Bezug, aber keine Klebung. Antwortblock und fest verankerter Composer bleiben getrennt; die Naht/Kanten sind grau und dazwischen bleibt 4px Abstand.
Wenn der User scrollt oder anders arbeitet, gibt es keinen aktiven blauen Bezug mehr. Die letzte Antwort endet unten eckig. Der Composer bleibt unten fest verankert in seinem eigenen Bereich; dazwischen bleibt ein kleiner Standardabstand.
Regel: Passiver Anschluss = grau, nicht blau. Es kleben nie zwei Blöcke; der Composer bleibt in Zone 5 als eigener, unten verankerter Bereich und behauptet keinen aktiven Kartenbezug.
Tabellen-/Listen-Auswahl erzeugt eine blaue Kontextleiste. Gestrichelte Aktionen sind KAI-Prompts in Vorbereitung, keine sofortige Ausführung.
Regel: Ein Klick auf gestrichelte Auswahl-Aktion übernimmt Kontext + vorformulierten Befehl in den Composer. Der User kann validieren, diktieren, anhängen oder ändern. Solide Buttons bleiben UI-/Panel-/echte Ausführungsaktionen.
Antwort mit eingebauten Ergebnissen
Die wichtigsten Kosten kommen aus drei Quellen. Ich zeige dir Tabelle und Chart direkt hier; die Belege und das Detail-Dossier oeffnen rechts im Panel.
| Quelle | Betrag |
|---|---|
| n8n | 86,15 |
| Hosting | 12,10 |
| Privat | 3,40 |
Regel: KAI darf Langtext liefern. Dokumentlinks, Quellen, Karten, Tabellen und eCharts duerfen innerhalb derselben Antwort erscheinen, muessen aber als Antwortgruppe erkennbar bleiben und bei groesserem Umfang kollabierbar oder ins rechte Panel fuehrbar sein.
Kurzfassung / Kontextzeile in small.
Standard-Text bleibt 16 px und copy/paste-fähig. KAI darf ausführlich antworten, wenn es dem Nutzer hilft; die Struktur macht erkennbar, was zusammengehört.
Tabellen, Karten oder Charts folgen als Bausteine innerhalb derselben Antwortgruppe, nicht als fremde zweite Antwort.
JC-Wunsch 2026-07-29: KAI-Antworten muessen so gerendert werden, dass Copy/Paste die Formatvorlagen/Markdown-Struktur erhaelt. Keine reinen Screenshot-Texte, keine verlorenen Tabellen.
core_shell.html: --content-col:1200px; Read-Views koennen --content-col-read:1000px nutzen. Hero nutzt TGV-Icons, keine freien Emoji-Fallbacks.Deine Ablage wie ein Datei-Explorer: Verzeichnis links, Vorschau je Beleg, Detail rechts.
Beim Scroll nach unten bleibt die erste Zeile greifbar; Beschreibung/KPIs/Werkzeuge kollabieren automatisch und kommen oben wieder.
Entität, Zeitraum und Projekt sitzen rechts oben direkt links vom Collapse-Button. Diese Controls bleiben in der kollabierten Hero-Zeile sichtbar.
Kanon: scope-frame/scopepop. Ein gemeinsamer Scope-Baustein, keine Light-/Full-Varianten. Rechts buendig: [Scope-Chip] [Collapse].
Dialog-Variante: gleiche Quelle, aber dreispaltig und als Klärungs-/Auswahlblock in der KAI-Antwort. Wirkung bleibt identisch: Main, KPI, Tabellen und KAI-Kontext werden gefiltert.
Funktionen dieses Bereichs. Karten sind Navigation, keine versteckten Schreibaktionen.
1 bis 8 Navigationskarten, max. 2x4. Quelle: Produkt-/Entitätskarten und Finanz-Funktionskarten aus Live-Screens; vereinheitlicht als Navigation-only.
Ein schlanker Einstieg mit Bild, kurzer Einordnung und CTA. Nicht fuer dichte Cockpits.
Zur SeiteBildquelle: Expat Coaching Corner, Live-Site. Format fuer TGV-Katalog hier bewusst 16:4; fuer Deployment als internes Asset spiegeln, damit kein externer Hotlink im geschuetzten Cockpit bleibt.
Karten sind in TGV in der Regel Navigation zu Seiten/Sektionen. Erste Zeile: Icon-Slot + optionale Pille. Zeile 2/3: Titel. Zeile 4/5: kleiner Text. Danach eine klar erkennbare Navigationsaktion im Button-Kanon.
Diese Seite zeichnet die Badges nicht frei neu. Gültige Quelle ist das Badge-Dossier plus JC-Entscheide: Entitäts-Pillen C3/C4/Privat mit Kanon-Farben; Konfidenz als KI-/Gold-Funke mit Abstufung; Sicherheit/Geheimhaltung mit eigener Pille und Schloss nur bei Schutzbedarf; EU als Symbol, nie als nackter Text.
Quellen sind echte Links. Panel-Aktionen sind Buttons/Trigger mit sichtbarer Zielrolle. Schreibaktionen niemals als Quellenlink tarnen. Definition = SSOT K-36 (source-link, GOLDENE REGEL).
Hintergrundfarbe wird immer mit Zone benannt. Z3-Tabellen/Listen liegen nicht nackt auf dem Screen-Hintergrund, sondern in weißen, gerahmten Arbeitsblöcken. Das hellblaue/graue Feld bei KAI ist Zone 4, nicht Seitenhintergrund.
Filter und Tabelle sind ein fachlicher Arbeitsblock. Sie duerfen mehrere Unterbereiche haben, aber sie wirken als eine weiße Z3-Fläche mit grauer Einrahmung.
R-108: System spricht nicht als KAI. Kein KAI-Avatar, keine Chat-Bubble. KAI kann diese Meldung danach menschlich erklären oder vorlesen, aber die technische Statuszeile bleibt als System markiert.
Scroll runter = erste Zeile bleibt; oben wieder offen.
Kurzer Ring-Puls als Quittung; reduced-motion respektieren.
Langantworten klappen mit Chevron; keine Textwand ohne Kontrolle.
Nur Status, kein Schmuck.
KAI liefert die Antwort im Chat des Ursprungsscreens. Ein Klick auf Quelle, Beleg, Chart, Vertrag, Karte oder Detail öffnet rechts das universelle Panel. Das Panel ist wie ein kleiner Screen ohne eigenen Chat: dynamische Komponenten, klar gegliedert, ausklappbar, prüfbar.
Eine Leiter, keine vier Meinungen. Jedes schwebende Element hatte sich seine Zahl selbst gesucht — 800 (#mockupRef), 850 (.ux-fb-panel), 900 (.ux-fb-toggle), 960 (#kaiFab im Fluss). Wer sich seine Zahl selbst sucht, nimmt die groessere; darum lag der Feedback-Knopf am 20.09. mitten auf der Zugriffs-Liste des Teilen-Blatts, und ein Klick auf die Liste war ein Klick auf „Feedback“.
Die Trennung, die die Leiter traegt: ein schwebender Knopf ist nicht seine Flaeche. Der Einstieg (FAB) gehoert auf die Inhalts-Seite — ueber den Text, unter jede Ueberlagerung. Die Flaeche, die er oeffnet (Panel · Dialog · Toast), gehoert auf die Ueberlagerungs-Seite. Erst damit ist „hoeher heisst wichtiger“ wieder wahr.
| Ebene | Token | z | Wer liegt dort |
|---|---|---|---|
| Inhalt | --z-inhalt | 1 | Karten 1 · Composer-/Dock-Band 5–6 · Fallleiste 19 · Hero 20 |
| Schweber (FAB) | --z-schweber | 30 | .ds-fab · #kaiFab · #mockupRef · .ux-fb-toggle (nur Rückfall ohne Kopfleiste — in der Shell steht der Feedback-Knopf seit UX#03 #3877 in der Kopfleiste) |
| Aufklapper | --z-aufklapper | 40 | .ds-dropdown__panel |
| Navigation / Scrim | --z-navigation | 45 | .ds-scrim · .ds-subnav@mobil · .ds-nav--drawer 46 · Bottom-Sheet 46 |
| Dock | --z-dock | 60 | .ds-dock--side (Arbeitsplatz, PAN-01) |
| Vollbild | --z-vollbild | 70 | .ds-datatable-full |
| Panel / Blatt | --z-panel | 80 | .doc-panel · .ux-fb-panel · #tgvSp |
| Dialog | --z-dialog | 90 | .ds-modal__overlay (seit #2192) |
| System | --z-system | 1000 | Toast / Quittung — das Einzige ueber einem Dialog. Der Toast traegt heute noch 9999, s. Kette unten. |
Regel fuer den naechsten Bau: ein neues schwebendes Element nimmt einen Token, nie eine Zahl — und ausserhalb von tokens.css immer mit Rueckfall (var(--z-panel,80)), weil ein unbekanntes var() „invalid at computed-value time“ ist und die GANZE Deklaration wegwirft (die #1923-Klasse, dort mit border-style:none bezahlt) — und die Auslieferung ist kein Vertrag: Token-Datei und Komponente liegen auf verschiedenen nginx-MOUNTS und koennen einzeln fehlen. Wer eine Zahl braucht, die es hier nicht gibt, hat eine Ebene gefunden — die kommt in die Leiter, nicht in den Screen.
⛔ Was noch ausserhalb seines Bandes liegt — und warum. Geprueft wurde (R-193): core_shell.html · components.css · ux_feedback_panel.js · engine.js; nicht geprueft: katalog.html und vertical_slice_standalone.html (eigene Inline-Kopien).
✔ .ds-modal__overlay 50 → --z-dialog: erledigt. Gemessen an showcase.html — der einzigen Flaeche, die components.css wirklich LAEDT und einen echten Overlay im Markup hat — bei 1280 hell und 375 dunkel, Dock und Vollbild mit den Kanon-Klassen eingehaengt: Overlay 90 ueber Dock 60/46 und Vollbild 70, Klick trifft den Dialog, Scrim in beiden Themen, 0 JS-Fehler, kein Ueberlauf.
✔ .dt-wrap--full 2000 → --z-vollbild: von RECHTE-UX#01 uebernommen (#2193). ⭐ Dort war meine Zuteilung falsch — und dadurch der Befund groesser: der Ausloeser ist kein Screen, sondern ein Zustand. fxDataTable geht immer an die Engine, ausser TGVEngine.dataTableMount fehlt — dann faellt jede Flaeche in diesen Notausgang. Deshalb fand ich ueber 13 Routen nichts: ich habe einen Screen gesucht, wo ein Zustand stand, und ein Zustand steht auf keiner Routenliste.
⛔ Der Toast (9999, style.cssText) → --z-system: noch nicht, und der Grund ist gemessen, nicht Vorsicht. --z-system ist 1000; darueber liegt das Shell-Slide-over #tgvOv/#tgvSp mit 1200/1201. Den Toast ALLEIN zu senken machte ihn hinter diesem Panel unsichtbar — eine Quittung, die niemand sieht, ist schlimmer als eine auf der falschen Ebene. Die Kette, in dieser Reihenfolge: erst #tgvOv/#tgvSp auf --z-panel (sie SIND Panels), dann der Toast. Der erste Schritt braucht eine Messung, die es noch nicht gibt — #tgvSp und .doc-panel laegen dann auf DERSELBEN Sprosse, und die DOM-Reihenfolge entscheidet. Heute schadet die 9999 nicht: zwischen 1201 und 9999 liegt nichts.
Für Heute, Produkte, Bereiche.
Für Dokumente, Belege, Eingänge.
Für Fälle, Freigaben, Prüfungen.
Für Vertrag, Beleg, Projektobjekt.
Für Kosten, Auswertung, Finanzstand.
Für Einstellungen, Regeln, Mandant, Skills.
| Pruefachse | Ist-Befund 29.07. | Gilt als fertig, wenn | Link / Guard |
|---|---|---|---|
| Komponenten-Katalog | check_katalog_coverage.py: 14 katalogpflichtige Engine-Bausteine, 10 sichtbar = 71 Prozent. Unsichtbar: srcBar, srcChip, tableCore, zoneMain. | Keine neue Luecke; Altlasten aktiv abbauen. Fuer TGV-Baukasten-Ziel: 95 Prozent+ sichtbar oder begruendete Ausnahme. | Katalog Vokabular-Bruecke |
| App-Klassen vs. Katalog | Vokabular-Bruecke: 123 genutzte ds-Klassen, 37 im Katalog, 106 nicht im Katalog; davon 65 ohne K-ID und 20 Karteileichen. | Jede wiederkehrende Klasse hat K-ID, Regel, Katalogkarte oder ist als ueberholt markiert. Keine 90-Prozent-Ausnahme-Zone. | Bruecke |
| Funktion -> Skill | validate_skill_registry.py: 43 Runtime-Skills in SSOT gruen; tgv-skill-request-icon ist als DOC-ONLY-Vertrag bewusst ausserhalb der Runtime-Registry bis JC-GO. | Jede sichtbare Funktion sagt: UI-Control, Capability, Skill/Endpoint, DOC-ONLY-Vertrag oder bewusst "kein Skill noetig". Neue Runtime-Skill-Ordner ohne Registry-Eintrag sind rot. | Skills-Register |
| Capability-Gating | Composer zeigt im Standard KAI-Persona, Plus, Mikro und Senden. Anhang/Diktat/TTS sind capability-gated; Modell-Auswahl ist kein Standard-Control und gehoert hoechstens in ein Admin-/Advanced-Menue. | Button sichtbar + aktiv = Capability true oder Skill vorhanden. Sonst deaktiviert/"bald" im [+]-Menue, nie totes Versprechen. | iaComposerBody() · 02_SKILLS/_registry.yaml |
Damit ist klar: Diese Seite ist nicht der ganze Katalog. Sie ist die Abnahmeflaeche fuer Controls. Der eigentliche Komponenten-Katalog lebt in ../katalog.html, die K-ID-Bruecke in vokabular_bruecke.html, die Skills in skills_register.html. Der fehlende Schritt ist der Guard, der diese drei Quellen zusammen prueft.
| Prioritaet | Verdrahtung / Drift-Fix | Warum | Guard-Idee |
|---|---|---|---|
| 1 | Live-Min-Controls gegen diese Kanon-Seite auditieren: heroCollapse, klHeroCollapse, act-prompt, chip, srclink. | Genau dort sieht man heute mehrere Varianten. | CSS-/DOM-Scan: lokale Button-Klassen nur mit Ausnahme-Liste. |
| 2 | .ds-axis Renderer nachziehen: Entitaets-Punkt entfernen, Konfidenz auf Gold-Funke nach JE-161, EU als Flaggen-Icon sichern. | Heute stehen noch Punkt/Zauberstab/Alt-Zeichen in Teilen von foundation.css/engine.js. | Icon-/Badge-Guard: keine Entity-Dots, keine 🪄-Konfidenz, kein EU-Text statt Flagge. |
| 3 | Controls, Frames, Motion und Funktion->Skill als eigene Taxonomie-/Guard-Familie formalisieren. | Damit erzeugte oder angepasste Screens nicht wieder lokal stylen und keine Funktion ohne Skill/Capability-Verdrahtung versprechen. | Screen-Factory-Guard erweitert um ui_controls, surface_layer, motion_hooks, skill_binding. |