Jinkendo Kairo

Operativer Program Director der Jinkendo-Produktfamilie.

Kairo steuert Vorhaben, Programme, Projekte, Meilensteine, Maßnahmen, Backlogs, Reviews, Nachweise und die Zusammenarbeit von Menschen, Arbeitsgruppen und KI-Agenten.

Leitfrage

Welcher nächste Schritt bringt ein Vorhaben aktuell am wirkungsvollsten voran?

Product Direction Reset

Kairo wurde nach AP0.7 produktstrategisch neu ausgerichtet.

Die führenden Dokumente sind:

• docs/product/Kairo_Product_Definition_and_MVP_Reset_v0.1.md
• docs/product/Kairo_Canonical_Operating_Model_v0.1.md
• docs/product/Kairo_Corrected_MVP_Roadmap_v0.1.md

Kairo ist nicht als einfache Aufgabenliste zu verstehen, sondern als operativer Program Director.

Der aktuelle technische Slice Initiative → Action bleibt gültig, ist aber nicht das Zielmodell.

Siehe auch CLAUDE.md für die verbindliche Dokumentenreihenfolge.

Abschlussbericht: docs/sprints/Sprint0_AP0_R1_Completion_Report_v0.1.md

Nächster geplanter Auftrag (Entwurf): docs/sprints/Sprint0_AP0_8_Assignment_v0.1.md

Startzustand

Dieses Repository startet mit einem reinen Spezifikations- und Sprint-0-Handover-Paket.

Noch nicht enthalten:

• produktiver Anwendungscode
• endgültiger Technologie-Stack
• vollständige Jinkendo-Foundation
• Mitai- oder Shinkan-Code
• Billing / SSO / zentrale Produktfamilien-Konvergenz

Verbindliche Dokumente für Sprint 0

Product Reset (führend ab AP0.R1):

1. docs/product/Kairo_Product_Definition_and_MVP_Reset_v0.1.md
2. docs/product/Kairo_Canonical_Operating_Model_v0.1.md
3. docs/product/Kairo_Corrected_MVP_Roadmap_v0.1.md

Foundation & Steuerung:

4. docs/product/Jinkendo_Kairo_Product_Spec_v0.2.md
5. docs/architecture/Kairo_Current_State_Gap_Analysis_AP0.1_AP0.6b_v0.1.md
6. docs/architecture/Kairo_Tenant_Invariants_v0.1.md
7. docs/architecture/Kairo_Sprint0_Principle_Gate_v0.1.md
8. docs/sprints/Jinkendo_Kairo_04_Sprint0_Foundation_v0.3.md
9. docs/sprints/Sprint0_Vibe_Coder_Handover_v0.1.md
10. CLAUDE.md
11. .cursor/rules/kairo-architecture.mdc

Arbeitsmodus

Kairo wird iterativ entwickelt.

Sprint 0 baut nur das Fundament:

• Tenant
• User
• Actor
• TenantContext
• Auth-Gates
• Capability/Rights Registry
• minimale Feature Registry
• minimale Prompt Registry
• Platzhaltermodell
• Audit
• Migration/Deploy-Grundlage

Vorhaben, Projekte, Meilensteine und Maßnahmen kommen erst nach Sprint 0.

Designprinzipien-Referenzen

Die extrahierten Designprinzipien aus Mitai und Shinkan liegen im Repository unter:

docs/reference/design-principles/

Diese Dokumente sind Referenzen, kein direkter Sprint-Scope.

Verbindlich ist nur, was über das Kairo Sprint-0 Principle Gate oder eine Architecture Decision übernommen wurde.

Deployment & CI

Zwei getrennte Gitea-Workflows (wie Shinkan):

Workflow	Branch
Deploy Development	develop
Deploy Production	main
Test Suite	nach Deploy + bei Push/PR develop

Details: docs/DEPLOYMENT.md

Local Development

Voraussetzungen: Docker + Docker Compose.

git clone http://192.168.2.144:3000/Lars/Kairo-Jinkendo.git
cd Kairo-Jinkendo
git checkout develop

# Dev-Stack (PostgreSQL + Backend + Frontend)
docker compose -f docker-compose.dev-env.yml up --build

# Health prüfen
curl http://localhost:8097/api/health
curl http://localhost:3097/api/health

# Tests im Backend-Container
docker compose -f docker-compose.dev-env.yml exec backend pip install -r requirements-dev.txt
docker compose -f docker-compose.dev-env.yml exec backend python -m pytest tests -ra -vv

UI: http://localhost:3097 · API: http://localhost:8097

Interaktive API-Doku (Dev): http://localhost:8097/api/docs

Auth (AP0.2)

Ersteinrichtung Dev (automatisch per Seed nach jedem Backend-Start):

Feld	Wert
E-Mail	lars@stommer.com
Passwort	12345678

Alternativ: UI-Registrierung (nur wenn DB leer und Dev-Seed deaktiviert) oder Bootstrap per .env:

KAIRO_BOOTSTRAP_ADMIN_EMAIL=admin@kairo.local
KAIRO_BOOTSTRAP_ADMIN_PASSWORD=…
KAIRO_BOOTSTRAP_TENANT_SLUG=default

Migrationen & idempotente Data-Seeds: docs/MIGRATIONS.md

Endpoint	Methode	Auth	Beschreibung
/api/auth/setup-status	GET	—	Ob Erstregistrierung offen ist
/api/auth/register	POST	—	Erster User → Portal-Admin + Tenant (nur wenn noch kein User)
/api/auth/login	POST	—	E-Mail + Passwort → Session-Token
/api/auth/logout	POST	X-Auth-Token	Session löschen
/api/me	GET	X-Auth-Token	Aktueller User + Tenant-Liste
/api/me/context	GET	X-Auth-Token	TenantContext (Tenant + Human Actor + Capabilities)
/api/me/entitlements	GET	X-Auth-Token	Entitlements-Snapshot (Rollen, Capabilities, Features-Platzhalter)
/api/me/admin/demo	GET	X-Auth-Token + kairo.admin.access	Beispiel-Endpoint mit require_capability
/api/me/tenant	POST	X-Auth-Token	Aktiven Tenant wechseln (nur Memberships)

Vorhaben und Maßnahmen (AP0.5 minimaler Slice):

Endpoint	Methode	Capability	Beschreibung
/api/initiatives	GET	kairo.initiative.read	Vorhaben im aktiven Tenant
/api/initiatives	POST	kairo.initiative.manage	Vorhaben anlegen
/api/initiatives/{id}	GET	kairo.initiative.read	Einzelnes Vorhaben
/api/initiatives/{id}	PATCH	kairo.initiative.manage	Vorhaben bearbeiten
/api/initiatives/{id}	DELETE	kairo.initiative.manage	Vorhaben löschen
/api/initiatives/{id}/actions	GET	kairo.action.read	Maßnahmen eines Vorhabens
/api/initiatives/{id}/actions	POST	kairo.action.manage	Maßnahme anlegen
/api/actions/{id}	GET	kairo.action.read	Einzelne Maßnahme
/api/actions/{id}	PATCH	kairo.action.manage	Maßnahme bearbeiten / Status
/api/actions/{id}/assignments	PUT	kairo.action.manage	Actors zuweisen (ersetzt Liste)
/api/actions/{id}	DELETE	kairo.action.manage	Maßnahme löschen
/api/actions/me/open	GET	kairo.action.read	Offene Maßnahmen des aktuellen Actors (via Data Layer)

Actor Directory und Workspace Data Layer (AP0.7):

Endpoint	Methode	Capability	Beschreibung
/api/actors	GET	kairo.actor.read	Actors des aktiven Tenants (Filter: actor_type, q, include_inactive)
/api/actors/{id}	GET	kairo.actor.read	Einzelner Actor (404 cross-tenant)
/api/workspace/summary	GET	kairo.workspace.read	Workspace-Kennzahlen
/api/workspace/actions/open	GET	kairo.workspace.read	Meine offenen Maßnahmen (open/in_progress)
/api/workspace/actions/blocked	GET	kairo.workspace.read	Meine blockierten Maßnahmen
/api/workspace/initiatives/active	GET	kairo.workspace.read	Aktive/pausierte Vorhaben (?limit=)
/api/workspace/actors/workload	GET	kairo.workspace.read	Actor-Workload (Basic)

Operating Model Extension I (AP0.8, Schema 007):

Endpoint	Methode	Capability	Beschreibung
/api/workspace/attention	GET	kairo.attention.read	Regelbasierte Attention-Items
/api/workspace/next-actions	GET	kairo.attention.read	NextActionCandidates (?limit=)
/api/initiatives/{id}/blockers	GET/POST	kairo.blocker.read/manage	Blocker eines Vorhabens
/api/blockers/{id}	GET/PATCH/DELETE	kairo.blocker.read/manage	Einzelner Blocker
/api/initiatives/{id}/backlog	GET/POST	kairo.backlog.read/manage	Backlog-Items
/api/backlog/{id}	GET/PATCH/DELETE	kairo.backlog.read/manage	Einzelnes Backlog-Item
/api/backlog/{id}/convert-to-action	POST	kairo.backlog.manage	Backlog → Maßnahme
/api/initiatives/{id}/milestones	GET/POST	kairo.milestone.read/manage	Meilensteine
/api/milestones/{id}	GET/PATCH/DELETE	kairo.milestone.read/manage	Einzelner Meilenstein

Status Blocker: open, in_progress, resolved, accepted_risk, dismissed

Status Backlog: new, triaged, accepted, rejected, converted

Status Meilenstein: planned, active, at_risk, reached, moved, discarded

Capabilities gesamt nach AP0.8: 25 (inkl. kairo.attention.read und Blocker/Backlog/Milestone read/manage).

Operating Model Extension II (AP0.9, Schema 008):

Endpoint	Methode	Capability	Beschreibung
/api/initiatives/{id}/evidence	GET/POST	kairo.evidence.read/manage	Evidence eines Vorhabens
/api/evidence/{id}	GET/PATCH/DELETE	kairo.evidence.read/manage	Einzelnes Evidence
/api/initiatives/{id}/decisions	GET/POST	kairo.decision.read/manage	Entscheidungen
/api/decisions/{id}	GET/PATCH/DELETE	kairo.decision.read/manage	Einzelne Entscheidung
/api/initiatives/{id}/reviews	GET/POST	kairo.review.read/manage	Reviews
/api/reviews/{id}	GET/PATCH/DELETE	kairo.review.read/manage	Einzelnes Review
/api/initiatives/{id}/recurring	GET/POST	kairo.recurring.read/manage	Recurring-Elemente
/api/recurring/{id}	GET/PATCH/DELETE	kairo.recurring.read/manage	Einzelnes Recurring-Element

Action-Status (erweitert): open, ready, in_progress, blocked, review_required, done, discarded — optional due_at

Attention-Regeln 7–9: overdue_action, review_due, recurring_due

Capabilities gesamt nach AP0.9: 33.

Operating Model Integration (AP0.10, Schema weiter 008):

Endpoint	Methode	Capability	Beschreibung
/api/initiatives/{id}/steering-snapshot	GET	kairo.initiative.read	Verknüpfter Graph + Lifecycle + Operating Phase (deprecated)
/api/initiatives/{id}/steering-context	GET	kairo.initiative.read	SteeringContext (Lifecycle, Methode)

Steering Core (AP1.0, Schema 009): backend/steering/ — Standard Lifecycle, Hook/Method Registry, Signal Engine. Scope Lock: siehe docs/architecture/ADP_AP1_0_Steering_Foundation_Scope_Lock_v0.1.md.

Version nach AP1.0: 0.11.0-ap1.0

AP1.1 — Method Registry:

Endpoint	Methode	Capability	Beschreibung
/api/steering/methods	GET	kairo.initiative.read	Built-in Steuerungsmethoden
/api/steering/initiatives/{id}/context	PATCH	kairo.initiative.manage	Methode pro Vorhaben setzen

Version nach AP1.1: 0.11.1-ap1.1

Operating-Transitions: Blocker gelöst → Maßnahme entblocken; Review abgeschlossen → Maßnahme review_required → done

Attention Regel 10: action_review_required — Maßnahme ohne geplantes Review

Version nach AP0.10: 0.10.0-ap0.10. Brücke zum Steering Core: docs/architecture/Kairo_Operating_Model_Steering_Bridge_v0.1.md

Operating Model Integration UI (AP0.10b, Schema weiter 008):

Endpoint	Methode	Capability	Beschreibung
/api/workspace/actions/today	GET	kairo.workspace.read	Meine Maßnahmen heute (überfällig zuerst)

Workspace-Widgets: Nächste sinnvolle Schritte, Heute, Aufmerksamkeit (erweitert)

Steuerungszustand v2: Meilenstein-Horizont, Next Actions pro Vorhaben, Phase-Klartext

Version nach AP0.10b: 0.10.1-ap0.10b

Operating Model Integration UI (AP0.10b, Schema weiter 008):

Tenant-Invarianten: docs/architecture/Kairo_Tenant_Invariants_v0.1.md docs/architecture/Kairo_Tenant_Invariants_v0.1.md

Status Vorhaben: active, paused, completed, archived

Status Maßnahme: open, in_progress, blocked, done, discarded

Priorität: low, normal, high

# Vorhaben anlegen
curl -s -X POST http://localhost:8097/api/initiatives \
  -H "X-Auth-Token: TOKEN" -H "Content-Type: application/json" \
  -d '{"title":"Erstes Vorhaben","goal":"MVP validieren","priority":"high"}'

# Maßnahme mit Zuweisung
curl -s -X POST http://localhost:8097/api/initiatives/INITIATIVE_ID/actions \
  -H "X-Auth-Token: TOKEN" -H "Content-Type: application/json" \
  -d '{"title":"API testen","assigned_actor_ids":["ACTOR_ID"]}'

# Meine offenen Maßnahmen
curl -s http://localhost:8097/api/actions/me/open -H "X-Auth-Token: TOKEN"

Workspace UI (AP0.6 / AP0.6b)

Nach Login leitet Kairo auf den Workspace weiter.

Route	Beschreibung
/workspace	Karten: Kontext, Überblick, Aufmerksamkeit, offene/blockierte Maßnahmen, aktive Vorhaben
/initiatives	Vorhabenliste mit offenen Maßnahmen-Zähler
/initiatives/:id	Vorhaben-Detail: Maßnahmen, Meilensteine, Backlog, Blocker
/my-actions	Alle offenen Maßnahmen des aktuellen Actors

App Shell (AP0.6b): Desktop-Sidebar (≥1024px), Mobile-Header + Bottom-Navigation (<1024px), Tenant-/Actor-Kontext, Jinkendo-Family-Design-Tokens (--jk-*).

Frontend-Struktur: frontend/src/api/, registry/, widgets/, pages/, components/, styles/, config/appNav.js

Widget Registry (frontend-only): Widgets in registry/widgetRegistry.js — Capability-Filter, keine Backend-Persistenz.

PWA: frontend/public/manifest.webmanifest, Icon unter public/icons/. Kein Service Worker (bewusst — Installierbarkeit über Manifest; kein Offline-Caching in Sprint 0).

Tests (Frontend):

cd frontend && npm install && npm run test && npm run build

Manueller Smoke-Test (Desktop + Mobile):

1. Login → Workspace lädt mit Karten
2. Navigation: Workspace / Vorhaben / Meine Maßnahmen
3. Vorhaben anlegen → Detail → Maßnahme anlegen → Status Erledigt
4. Prüfen: Maßnahme verschwindet aus „Meine offenen Maßnahmen“
5. Responsive: DevTools Viewports 1440px, 1024px, 390px — keine horizontale Scrollbar, Bottom-Nav sichtbar unter 1024px
6. PWA: Manifest unter /manifest.webmanifest erreichbar; „App installieren“ im Browser prüfbar
7. AP0.7: ActorSelect lädt /api/actors; Maßnahme einem Agent zuweisen; Workspace-Überblick sichtbar
8. AP0.8: Attention-Widget auf Workspace; Vorhaben-Detail mit Blocker/Backlog/Meilenstein; Backlog → Maßnahme konvertieren

Abschlussberichte: docs/sprints/Sprint0_AP0_6_Completion_Report_v0.1.md, docs/sprints/Sprint0_AP0_6b_Completion_Report_v0.2.md, docs/sprints/Sprint0_AP0_7_Completion_Report_v0.2.md, docs/sprints/Sprint0_AP0_8_Completion_Report_v0.1.md

Registries (AP0.4)

Feature-, Prompt-, Placeholder- und Config-Registry analog zur Rights Registry: Code-Registrierung → Startup-Sync → DB.

Endpoint	Methode	Capability	Beschreibung
/api/features	GET	kairo.feature.registry.read	Feature-Katalog
/api/prompts	GET	kairo.prompt.registry.read	Prompt-Definitionen
/api/prompts/{key}	GET	kairo.prompt.registry.read	Definition + aktive Version
/api/prompts/{key}/render	POST	kairo.prompt.render	Single-Mode Rendering (ohne LLM)
/api/config	GET	kairo.config.registry.read	Konfiguration (global/tenant)
/api/config	POST	kairo.config.registry.manage	Konfiguration setzen

Startup: sync_prompt_feature_config.py nach Rights-Sync (SKIP_REGISTRY_SYNC=1 zum Überspringen).

Abschlussbericht: docs/sprints/Sprint0_AP0_4_Completion_Report_v0.2.md

Prompt-Modell: PromptDefinition → PromptVersion → optional PromptStep (workflow-/pipeline-fähig; AP0.4 führt nur execution_mode=single aus).

Beispiel-Prompts: kairo.system.health_summary, kairo.context.debug_summary

Features im Entitlements-Snapshot: kairo.prompt.registry, kairo.config.registry, kairo.feature.registry

Capability	Modul	Kurzbeschreibung
kairo.feature.registry.read	feature	Feature-Katalog lesen
kairo.feature.registry.manage	feature	Feature-Metadaten verwalten
kairo.prompt.registry.read	prompt	Prompt Registry lesen
kairo.prompt.registry.manage	prompt	Prompt Registry verwalten
kairo.config.registry.read	config	Config lesen
kairo.config.registry.manage	config	Config schreiben
kairo.prompt.render	prompt	Prompt rendern (Test/Preview)

Zusätzlich AP0.3-Capabilities (siehe oben).

Enforcement: CAPABILITY_ENFORCE=probe (Default) oder enforce.

curl -s http://localhost:8097/api/me/entitlements -H "X-Auth-Token: TOKEN"
curl -s -X POST http://localhost:8097/api/prompts/kairo.system.health_summary/render \
  -H "X-Auth-Token: TOKEN" -H "Content-Type: application/json" \
  -d '{"values":{"debug_message":"OK","debug_level":"info"},"use_context":false}'

Capabilities (AP0.3)

Registry-first: Capabilities werden in backend/rights_registrations/ registriert und beim Start via sync_rights_registry.py in die DB synchronisiert.

Capability	Modul	Kurzbeschreibung
kairo.admin.access	platform	Portal-Administration
kairo.tenant.manage	tenant	Tenant-Verwaltung
kairo.actor.read	tenant	Actors im Tenant lesen (Directory)
kairo.actor.manage	tenant	Actors verwalten
kairo.workspace.read	workspace	Workspace Read-Models / Data Layer
kairo.initiative.read	initiative	Vorhaben lesen
kairo.initiative.manage	initiative	Vorhaben verwalten
kairo.action.read	action	Maßnahmen lesen
kairo.action.manage	action	Maßnahmen verwalten / zuweisen
kairo.context.read	platform	TenantContext lesen
kairo.entitlements.read	platform	Entitlements lesen

Enforcement: CAPABILITY_ENFORCE=probe (Default, loggt Verweigerungen) oder enforce (HTTP 403).

curl -s http://localhost:8097/api/me/entitlements -H "X-Auth-Token: TOKEN"

# Login
curl -s -X POST http://localhost:8097/api/auth/login \
  -H "Content-Type: application/json" \
  -d '{"email":"admin@kairo.local","password":"…"}'

# Geschützter Endpoint
curl -s http://localhost:8097/api/me -H "X-Auth-Token: TOKEN"

Regeln: user_id kommt aus der Session, nicht aus Client-Headern. Portalrolle (portal_role) und Tenantrolle (tenant_role) sind getrennt.

AP0.1 – Stand Projektgrundlage

Bereich	Status
Git + Gitea (develop / main)	erledigt
Docker Compose (Prod + Dev)	erledigt
Backend (FastAPI, Migrationen, /api/health)	erledigt
Frontend minimal (React + nginx Proxy)	erledigt
pytest (Health + Migrationen + Auth/Tenant/Actor)	erledigt (AP0.2)
Gitea Actions (Deploy + Test)	erledigt