# 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.