Wie es gebaut ist — die fünf Schichten, der Datenvertrag, Kernel und Shell, und der Weg vom Template zum fertigen Cockpit. Eine tragende Unterscheidung: Kernel und Shell werden gepinnt (nie im Konsumenten editiert), das Template wird kopiert und gefüllt.
Jedes Cockpit besteht aus denselben fünf Schichten. Die mittlere Spalte — gepinnt oder kopiert — ist die wichtigste Unterscheidung: Sie entscheidet, was Sie anfassen und was Sie unverändert übernehmen.
| Schicht | Was | Wo | Lebenszyklus |
|---|---|---|---|
| Contract | Das 4-Achsen-Modell + JSON-Schema — die Form-Wahrheit. | contract/ + references/ | versioniert |
| Kernel | Der reine Rechenkern — Gate·Fit·Cost·Risk-Scoring + Fork-Narrowing. | engine/kernel.js | gepinnt |
| Shell | Der Mechanismus — Boot/Render/URL-Loop, View-Registry, Fork-Renderer. | shell/shell.js | gepinnt |
| Template | Das Copy-me-Gerüst — Spec über mount() + Station-Renderer + Stub-Daten. | template/ | kopiert |
| Instance | Das gefüllte Template — das Cockpit einer Engagement. | customers/*/site/ | gefüllt |
Gepinnt vs. kopiert — Kernel und Shell werden über das _methodology-Submodul gepinnt und nie im Konsumenten editiert (wie brand → website/_brand); Verbesserungen fließen zurück, dann re-pinnt der Konsument. Das Template wird kopiert und gefüllt.
Der Datenvertrag war Prosa-Dokumentation, der man von Hand folgte. Plan 15 hat ihn invertiert: das JSON-Schema (contract/schema/) ist jetzt die maschinell prüfbare Quelle der Form-Wahrheit, contract.md die Doktrin darüber.
→ Die generierte Feld-Referenz · → Der Datenvertrag im Detail
Ein neues Lösungs-Cockpit entsteht, indem man template/ kopiert — niemals, indem man eine andere Engagement forkt.
kopieren
Template → site/
Das Copy-me-Gerüst template/ in <engagement>/site/ kopieren.
füllen
data/ befüllen
Die JSON-Dateien (config · requirements · decisions · solutions …) mit den echten Daten füllen.
prüfen
Validieren
node contract/validate.mjs <engagement>/data — Form, Semantik, Doku.
live
Deployen
Die CI baut die statische Seite und liefert sie auf die Caddy-VM aus.
Beide Cockpits konsumieren Kernel + Shell über ein gepinntes _methodology-Submodul — wie die Website den Brand über _brand zieht. Die Instanz liefert nur eine dünne Spec.
Die Shell besitzt den Mechanismus (Boot → Load → Render-Loop, View-Registry, Fork-Renderer, Keyboard-Nav); die Instanz liefert den Inhalt (das Daten-Manifest, die render(ctx)-Callbacks pro View, die Cost-Hooks). app.js ist eine dünne Instanz-Spec über DecisionShell.mount(spec).
<!-- Ladereihenfolge: Brand-Tokens → Brand-CSS → Shell-CSS → App-CSS,
dann Kernel → Shell → App -->
<link rel="stylesheet" href="styles/tokens.css">
<link rel="stylesheet" href="shell.css">
<script defer src="engine/kernel.js"></script>
<script defer src="shell.js"></script>
<script defer src="app.js"></script>engine//shell/, dann re-pinnt der Konsument.Was eine Engagement zusätzlich braucht, kommt in eine Erweiterung — nicht in einen Fork des Kerns. Ein Extension-Schema komponiert die Basis (allOf + $ref) und fügt eigene Felder hinzu; unevaluatedProperties: false weist alles zurück, was weder Basis noch Erweiterung dokumentiert.
Eine typisierte Kostenmodellierung (Saison-Seats, Jahresrabatt, Peak-Wochen) als per-Projekt-Erweiterung des Basis-solutions-Schemas.
Eine 6. Facette (integration) neben den fünf generischen Wissens-Facetten — wie das Kern-Tool die KI-Schicht andockt.
Das Frontend — die fünf Schichten, das Template, die zwei Register und der Explorer.
references/cockpit.md
Der Datenvertrag als Doktrin — Namensgrammatik und durchdeklinierte Feld-Shapes (das Schema ist die Form-Wahrheit).
references/contract.md
Zwischen Engagements übertragen — die Rule-of-Three: wann harvesten, wann kopieren.
references/transferring-between-engagements.md