Kanonisches Home für die aus Mitai übernommenen **Querschnittsmuster**: einheitliche Registrierung, Prompt- und Workflow-Engine, Konfigurierbarkeit, Modularisierung.
Quelle: `C:\dev\mitai\.claude\docs\jinkendo-foundation\design-principles/` (Dokumente 1–4, 7). Mitai-Pfade sind Beispiele, keine Kanshō-Dateinamen.
Der fachliche Dialog-/MVP-Stand bleibt **nicht final**. Datenschutz und Guardrails sind bindend: die Engine ruft Modelle nur über das Privacy Gateway auf. Dieses Kapitel legt die **Plattform** fest, auf der spätere Fachmodule registriert werden – nicht die Module selbst.
1. Neue Fähigkeiten kommen als **registrierte Komponenten** hinzu, nicht als Sonderpfade in Routern oder React.
2. KI läuft über **eine Prompt-/Workflow-Engine**, nicht über verstreute Provider-Calls.
3. Soweit fachlich sinnvoll, liegen Texte, Graphen, Sichtbarkeit und Limits in **administrierbarer Konfiguration**, nicht im Deploy-Code.
4. Berechnungen haben eine **Single Source of Truth** (Data Layer); UI und KI konsumieren dieselbe Schicht.
5. Jeder persönliche LLM-Aufruf der Engine geht durch das Privacy Gateway (`privacy_gateway.md`). Das ist fachliche Invariante, kein optionales Plugin. Konfiguration darf Prompts ändern, nicht den Egress-Pfad umgehen.
Nicht übernommen: Mitai-Domäne, parallele Legacy-Executoren, doppelte Registries, IDOR-Profilheader.
---
## 2. Registry- und Plugin-Muster
Mitai nutzt dasselbe Muster dreimal (Platzhalter, Dashboard-Widgets, CSV-Module). Kanshō übernimmt das **Meta-Muster** als einheitliches System für Modularisierung, Skalierung und Erweiterung.
1.**Ein Executor** als einziger Einstieg für modellgebundene Ausführung (`base` / `pipeline` / `workflow`). Kein zweiter Pfad wie Mitais Legacy `insights.py`.
2.**Prompts und Workflows in der DB** (Name, Slug, Kategorie, aktiv, Template, Stages, Graph, Output-Format/Schema), nicht im Anwendungscode.
Fachliche Reflexions-Workflows (Tagesreflexion, Journal-Entwurf, …) werden **später als Konfiguration** in dieser Engine registriert, nicht als fest verdrahteter Python. Solange das Fachkonzept unfertig ist, bleibt die Bibliothek leer oder enthält nur technische Test-Prompts.
### 3.3 Nicht übernehmen
- Parallele Template-Engines und direkte LLM-Calls neben dem Executor.
- Doppelte Workflow-Speicher (`graph_data` und `workflow_definitions`).
- Frontend-Workflow-Editor ohne `RequireAdmin` (Mitai-Lücke).
- Unversioniertes Overwrite ohne Reset-Pfad.
- Debug-Responses mit Klarnamen oder vollem Internal Context.
- Vermischung von `{{key}}` (Kontext) und `[[ROLE]]` (Privacy).
Modellname und Endpoint-URL liegen in Admin-Konfiguration (`provider_settings`); Secrets bleiben Env. Routing-Policy später über Konfiguration, nicht über neue Executoren.
Keine Sonderlogik „nur dieses eine Feature hardcodiert im Router“, wenn es ein Registry- oder Prompt-Fall ist. Lint/Konvention: neue KI-Aufrufe nur über den Executor.
**Nicht administrierbar:** Abschalten oder Umgehen des Privacy Gateway, Speichern voller Prompts beim Provider, Training-Freigabe für persönliche Kontexte, Fail-Open auf unsichere Endpoints.
---
## 5. Data Layer als SSoT
Mitai Layer 0 → 1 → 2a/2b. Kanshō übernimmt die **Trennung**, nicht die Körper-Metriken.
| Schicht | Kanshō-Rahmen |
|---|---|
| 0 Persistenz | PostgreSQL, profilbezogen |
| 1 Ableitung | eine Stelle für berechnete/verdichtete Werte, die mehrere Konsumenten brauchen |
| 2a KI | Platzhalter-Resolver liest Layer 1, formatiert für Templates |
| 2b UI | Chart/Listen-Payloads aus Layer 1, keine zweite Formel in React |
Router und React rechnen keine parallelen Scores. Welche Layer-1-Funktionen existieren, folgt dem späteren Fachstand (Summaries, Saturation, …) und wird dann **registriert**, nicht vorab erfunden.
---
## 6. Feature- und Entitlement-Muster
Mitai trennt Identität (Auth) von „darf Feature X wie oft?“. Kanshō übernimmt die **zentrale**`check_feature_access`-Idee an der API, nicht das Fitness-Abo als Produkt.
- Eine Feature-Registry.
- Enforcement in der API, nicht nur in der UI.
- Kataloge **referenzieren** Feature-IDs, lösen Tiers nicht selbst auf.
- Ob Tiers, Trials oder nur an/aus gebraucht werden, ist **offen** (Fach- und Produktstand). Die Erweiterungspunkte werden trotzdem so gebaut, dass Limits später ohne Router-Umbau möglich sind.
### 6.1 Verlustfreie spätere Ausprägung
Der Code enthält absichtlich **kein** fertiges Abo. Er enthält die Auflösungshierarchie, damit Tarif, Limit und Billing später Zeilen und Policies sind, keine neue Auth.
| Usage nach erfolgreichem Call | `increment_feature_usage` (bereits vorhanden, noch nicht am Erfolgspfad) | Frontend-Zähler |
| User-Overrides | `user_feature_restrictions` | Hardcode in `check_feature_access` |
| Billing / Stripe / Familienabo | eigene Billing-Schicht oder zentrales Jinkendo-Abo | Kanshō-Auth, Prompt-Engine |
| Feinere Rechte (Prompts vs. Diagnose) | Permission-Gate **über**`require_admin`, Rolle bleibt grob | Feature-IDs als Pseudo-Rollen |
| Neue limitierbare Fähigkeit | Zeile in `features` + Check an der API | neue Spalte `max_*` am Profil |
Bestehende Sessions, Profile und Prompt-Rows bleiben gültig. Ein späteres Abo ist ein Fill-in dieser Tabellen plus Enforcement, kein Schnitt durch Login oder Gateway.
Kanshō übernimmt diese **Mechanik** für spätere Oberflächenbausteine (z. B. Einstiegsimpulse, Diagnosekarten). Es werden keine Mitai-Gewichts-/Schlaf-Widgets kopiert. Solange die IA unfertig ist, kann der Katalog leer oder auf Shell-Platzhalter beschränkt sein.
---
## 8. Erweiterungs-Checkliste (neues Modul)
Analog Mitai-Übergabe, für Kanshō:
1. Registry-Kanon: ID, Metadaten, Tests auf Eindeutigkeit.
2. Implementierung registriert sich (Package-Import).
3. Validierung am Rand.
4. API-Router des Moduls; keine Business-Logik nur im Frontend.
5. Optional Prompt/Workflow in der Engine, Ausführung nur über Executor + Gateway.
6. Optional Feature-ID und Admin-Sichtbarkeit.
7.`MODULE_VERSIONS` / App-Version anpassen.
8. Kein zweiter Ausführungspfad.
---
## 9. Entscheidungsstand
| Thema | Stand | Status |
|---|---|---|
| Einheitliches Registry-Muster | ja | entschieden |
| Prompt-/Workflow-Engine mit DB-Konfiguration | ja | entschieden |
| Ein Executor, Callback = Privacy Gateway | ja | entschieden |
| Admin konfiguriert, User führt aus | ja | entschieden |
| Data Layer SSoT | ja | entschieden |
| Feature-Check an der API (Muster) | ja | entschieden |
Rahmen-Slice (User-Admin, Prompt-DB, Platzhalter-Registry, Feature-Check) ist im Code angelegt. Bleibt offen:
1. Liegen später fachliche System-Prompts zusätzlich als JSON im Git (`prompts.seed.json`) oder nur in der DB mit Export-Disziplin? Der Lade-Pfad existiert; die Datei ist bewusst leer.
2. Braucht Kanshō früh Limits ungleich unbegrenzt, oder bleibt `ai_calls` ohne Kontingent bis zur Produktentscheidung?
3. Selbst-Registrierung vs. nur Admin legt Nutzer an.
## 11. Querverweise
- Mitai: Foundation #1 Prompt Engine, #2 Data Layer, #3 Entitlements, #4 Registry, #7 Widgets
