Lars/Kairo-Jinkendo
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
0e5bf72dee
Kairo-Jinkendo/docs/architecture/Jinkendo_Foundation_Minimum_Viable_Foundation_v0.2.md
Lars 1ce20d8bdb
Some checks failed
Test Suite / playwright-tests (push) Waiting to run
Details
Deploy Development / deploy (push) Failing after 0s
Details
Test Suite / pytest-backend (push) Failing after 5m1s
Details
Test Suite / lint-backend (push) Failing after 0s
Details
Test Suite / build-frontend (push) Successful in 0s
Details
Test Suite / k6 /api/health Baseline (push) Has been cancelled
Details
Sprint-0-Spezifikationen ergaenzen, AP0.1-Setup-Luecken schliessen (Health, CI, ADR-Vorlage). 
Co-authored-by: Cursor <cursoragent@cursor.com>
2026-07-04 19:08:55 +02:00

4.4 KiB
Raw Blame History

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:

Tenant + Actor + TenantContext
Capability Registry
Feature Registry minimal
Prompt Registry minimal
Placeholder validiert
Audit
Migration/Deploy

Alles andere ist späteres Architektur-Backlog.