201 lines
4.4 KiB
Markdown
201 lines
4.4 KiB
Markdown
|
# Jinkendo Foundation
|
||
|
|
## Minimum Viable Foundation v0.2
|
||
|
|
|
||
|
|
Status: Arbeitsfassung
|
||
|
|
Stand: 2026-07-04
|
||
|
|
Zweck: Minimale produktübergreifende Grundlage, soweit sie für Jinkendo Kairo Sprint 0 zwingend relevant ist.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## 1. Zweck
|
||
|
|
|
||
|
|
Diese Minimum Viable Foundation beschreibt nur die produktübergreifenden Prinzipien, die Kairo von Anfang an korrekt berücksichtigen muss.
|
||
|
|
|
||
|
|
Sie ist keine vollständige Zielarchitektur der Jinkendo-Produktfamilie.
|
||
|
|
|
||
|
|
Sie erzwingt keine Konvergenz von Mitai und Shinkan.
|
||
|
|
|
||
|
|
Sie verhindert nur, dass Kairo grundlegende Plattformkonzepte falsch oder isoliert implementiert.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## 2. Geltungsbereich
|
||
|
|
|
||
|
|
Gilt für Kairo Sprint 0 und spätere neue Jinkendo-Produkte, soweit dieselben Prinzipien relevant sind.
|
||
|
|
|
||
|
|
Nicht Gegenstand:
|
||
|
|
|
||
|
|
- Umbau von Mitai
|
||
|
|
- Umbau von Shinkan
|
||
|
|
- zentrale Familienarchitektur
|
||
|
|
- Billing
|
||
|
|
- SSO
|
||
|
|
- vollständige Shared Packages
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## 3. Drift-Schutz
|
||
|
|
|
||
|
|
Ein Prinzip wird nur Sprint-0-verbindlich, wenn alle drei Fragen mit „Ja“ beantwortet werden:
|
||
|
|
|
||
|
|
1. Verhindert es später teures strukturelles Refactoring in Kairo?
|
||
|
|
2. Ist es für Sprint 0 zwingend erforderlich?
|
||
|
|
3. Kann es minimal umgesetzt werden, ohne Kairo zu überladen?
|
||
|
|
|
||
|
|
Alles andere kommt ins Architektur-Backlog.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## 4. Verbindliche Foundation-Prinzipien für Kairo Sprint 0
|
||
|
|
|
||
|
|
### F-01 Tenant-first
|
||
|
|
|
||
|
|
Kairo ist mandantenfähig zu modellieren.
|
||
|
|
|
||
|
|
Alle fachlichen Objekte benötigen Tenant-Bezug oder einen expliziten globalen Scope.
|
||
|
|
|
||
|
|
### F-02 Actor-first
|
||
|
|
|
||
|
|
Operative Verantwortung wird Actors zugeordnet.
|
||
|
|
|
||
|
|
Actors können Menschen, KI-Agenten, Arbeitsgruppen oder externe Systeme sein.
|
||
|
|
|
||
|
|
### F-03 TenantContext pro Request
|
||
|
|
|
||
|
|
Jeder geschützte Request muss einen aufgelösten Kontext besitzen:
|
||
|
|
|
||
|
|
- User
|
||
|
|
- Tenant
|
||
|
|
- Actor
|
||
|
|
- Rollen
|
||
|
|
- Capabilities
|
||
|
|
|
||
|
|
### F-04 Auth, Capability, Feature und Governance trennen
|
||
|
|
|
||
|
|
Kairo vermischt nicht:
|
||
|
|
|
||
|
|
- Auth: Wer ist eingeloggt?
|
||
|
|
- Capability: Darf diese Funktion genutzt werden?
|
||
|
|
- Feature: Welche Produktfunktion ist betroffen?
|
||
|
|
- Governance: Darf dieses Objekt gesehen oder verändert werden?
|
||
|
|
|
||
|
|
Feature-Limits und Billing werden nur vorbereitet, nicht in Sprint 0 vollständig gebaut.
|
||
|
|
|
||
|
|
### F-05 Registry-first
|
||
|
|
|
||
|
|
Neue steuerungsrelevante Funktionen registrieren sich an zentralen Registries.
|
||
|
|
|
||
|
|
Mindestens:
|
||
|
|
|
||
|
|
- Rights / Capability Registry
|
||
|
|
- Feature Registry
|
||
|
|
- Prompt Registry
|
||
|
|
- Configuration Registry
|
||
|
|
|
||
|
|
### F-06 Prompts nicht hardcoden
|
||
|
|
|
||
|
|
Produktive interne Prompts liegen nicht hart im Code.
|
||
|
|
|
||
|
|
Sprint 0 benötigt:
|
||
|
|
|
||
|
|
- Prompt Template
|
||
|
|
- Prompt Version
|
||
|
|
- Placeholder
|
||
|
|
- Kontextart
|
||
|
|
- Admin-Scope
|
||
|
|
|
||
|
|
### F-07 Platzhalter kontrollieren
|
||
|
|
|
||
|
|
Platzhalter sind typisiert, dokumentiert und werden validiert.
|
||
|
|
|
||
|
|
Fehlende Pflichtplatzhalter führen zu kontrollierten Fehlern.
|
||
|
|
|
||
|
|
### F-08 Keine hardcodierte fachliche Konfiguration
|
||
|
|
|
||
|
|
Nicht hardcodieren:
|
||
|
|
|
||
|
|
- Rollen
|
||
|
|
- Rechte
|
||
|
|
- Prompts
|
||
|
|
- fachliche Statuslisten
|
||
|
|
- Feature-Flags mit fachlicher Bedeutung
|
||
|
|
- Workflowparameter
|
||
|
|
- AI-Modellzuordnung
|
||
|
|
|
||
|
|
Technische Defaults sind erlaubt, müssen aber dokumentiert und später überschreibbar sein.
|
||
|
|
|
||
|
|
### F-09 Audit für Admin- und Agentenaktionen
|
||
|
|
|
||
|
|
Administrative und agentenbezogene Aktionen müssen auditierbar sein.
|
||
|
|
|
||
|
|
Sprint 0 benötigt ein einfaches AuditLog-Modell.
|
||
|
|
|
||
|
|
### F-10 Nummerierte Migrationen und Fail-Fast-Startup
|
||
|
|
|
||
|
|
Schemaänderungen laufen über nummerierte Migrationen.
|
||
|
|
|
||
|
|
Fehlgeschlagene Migrationen dürfen den App-Start blockieren.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## 5. Bewusst nicht Sprint-0-verbindlich
|
||
|
|
|
||
|
|
Nicht in Sprint 0:
|
||
|
|
|
||
|
|
- vollständige Entitlement-/Billing-Engine
|
||
|
|
- Usage-Zähler
|
||
|
|
- Tiers
|
||
|
|
- Pläne
|
||
|
|
- Coupons
|
||
|
|
- SSO
|
||
|
|
- vollständige Mitai Prompt Engine
|
||
|
|
- Shinkan Access Layer mit Vereinslogik
|
||
|
|
- Widget Dashboard
|
||
|
|
- Data Layer nach Mitai-Vorbild
|
||
|
|
- Import-Framework
|
||
|
|
- Media Assets
|
||
|
|
- Content Reports
|
||
|
|
- Maturity Models
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## 6. Referenzprinzipien
|
||
|
|
|
||
|
|
### Aus Mitai relevant
|
||
|
|
|
||
|
|
- Prompt Templates nicht hardcoden
|
||
|
|
- zentrale Prompt-Ausführung als Zielbild
|
||
|
|
- Registry-Muster
|
||
|
|
- Feature-Registry als Konzept
|
||
|
|
- Migration/Deploy-Standard
|
||
|
|
- Auth-Session-Basis
|
||
|
|
|
||
|
|
### Aus Shinkan relevant
|
||
|
|
|
||
|
|
- TenantContext
|
||
|
|
- Trennung von Portalrolle und fachlicher Rolle
|
||
|
|
- Rights Registry
|
||
|
|
- Capabilities vs. Features
|
||
|
|
- Entitlements-Snapshot als API-Idee
|
||
|
|
- schmale AI Prompt Runtime als Sprint-0-kompatibles Vorbild
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## 7. Kairo-spezifische Entscheidung
|
||
|
|
|
||
|
|
Kairo übernimmt keine allgemeine Familienarchitektur.
|
||
|
|
|
||
|
|
Kairo übernimmt nur:
|
||
|
|
|
||
|
|
```text
|
||
|
|
Tenant + Actor + TenantContext
|
||
|
|
Capability Registry
|
||
|
|
Feature Registry minimal
|
||
|
|
Prompt Registry minimal
|
||
|
|
Placeholder validiert
|
||
|
|
Audit
|
||
|
|
Migration/Deploy
|
||
|
|
```
|
||
|
|
|
||
|
|
Alles andere ist späteres Architektur-Backlog.
|