Kairo-Jinkendo/CLAUDE.md

CLAUDE.md – Jinkendo Kairo

Du arbeitest im Projekt Jinkendo Kairo.

Kairo ist der operative Program Director der Jinkendo-Produktfamilie.

Leitfrage

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

---

1. Aktueller Entwicklungsstand

Foundation AP0.1–AP0.7 abgeschlossen. Operating Model AP0.8–AP0.10, Steering AP1.0–AP1.1b technisch geliefert.

Technisch vorhanden:

• Tenant, User, Actor, TenantContext, Auth, Capabilities
• OM-Entitäten (Backlog, Blocker, Milestone-Brücke, Evidence, Decision, Review, Recurring)
• backend/steering/ (Lifecycle, Snapshot, Method Registry, Plugin-Architektur AP2.3/AP2.4)
• Operating Context API + slice-bewusstes Frontend-Laden (AP2.3)
• Steuerungselement-Registry + Methoden-Vertrag (AP2.4)
• Workspace-GUI, Data Layer, Actor Directory

Produktlich fehlt (Vision):

• Getrennte IA (Ausführung / Plan / Eingang / Journey) — nicht Omnibus-InitiativeDetail
• RoadmapItem / Quality Gates — Milestone heute nur CRUD
• Plan vs. Ist, Abhängigkeiten, Task-Hierarchie
• Modal/Detail-Bearbeitung statt Inline-CRUD

Ist-Stand: docs/product/Kairo_Implementation_Truth_Table_v0.1.md

Nächster Fokus: Specs Welle 1 finalisieren, dann Stufe-A End-to-End (AP2.2b/c/e, AP1.9d) und AP2.1 Validation — auf Plugin-Architektur AP2.3/4 aufsetzen, kein Layout-Patching auf InitiativeDetail.

---

2. Verbindliche Primärdokumente

Lies bei Projektstart in dieser Reihenfolge:

1. docs/product/Kairo_Vision_and_Product_Direction_v0.2.md
2. docs/product/Kairo_Canonical_Operating_Model_v0.2.md
3. docs/product/Kairo_Implementation_Truth_Table_v0.1.md
4. docs/product/DOCUMENTATION_REVISION_PROGRAM_v0.2.md
5. docs/product/Kairo_Corrected_MVP_Roadmap_v0.2.md
6. docs/architecture/Kairo_System_Target_State_v0.1.md
7. docs/architecture/ADP_AP1_0_Steering_Foundation_Scope_Lock_v0.1.md
8. docs/architecture/Kairo_Tenant_Invariants_v0.1.md
9. docs/architecture/Kairo_Sprint0_Principle_Gate_v0.1.md
10. .cursor/rules/kairo-architecture.mdc
11. docs/architecture/ADP_Archetype_Method_Plugin_Architecture_v0.1.md (AP2.3 — geliefert)
12. docs/architecture/ADP_AP2_4_Steering_Elements_and_Method_Contract_v0.1.md (AP2.4 — geliefert)
13. .cursor/rules/kairo-plugin-architecture.mdc

Historisch / Referenz (nicht führend bei Konflikt):

• docs/product/Kairo_Product_Definition_and_MVP_Reset_v0.1.md → superseded by Vision v0.2
• docs/product/Kairo_Canonical_Operating_Model_v0.1.md → superseded by v0.2
• docs/product/Jinkendo_Kairo_Product_Spec_v0.2.md — Referenz
• Sprint Completion Reports — historisch

Bei Konflikten gilt folgende Auslegungsreihenfolge:

1. Vision & Product Direction v0.2
2. Canonical Operating Model v0.2
3. Implementation Truth Table
4. System Target State / ADPs
5. Tenant Invariants, Principle Gate
6. Product Spec v0.2 (Referenz)
7. Sprint History
8. Mitai/Shinkan Designprinzipien (Referenz, kein Scope)

---

Aktuelle Produktleitlinie

Kairo darf nicht auf Initiative → Action reduziert werden.

Der aktuelle Vorhaben-/Maßnahmen-Slice ist nur ein technischer Startpunkt.

Kairo ist ein operativer Program Director.

Das kanonische Operating Model umfasst (Zielbild):

• Initiative / Programm, Project optional
• Roadmap / RoadmapItem (Gates, Meilensteine, Reifegrade) — Plan-Struktur
• BacklogItem (Eingang) → Action (Arbeitspaket) → Task (später) — Ist-Struktur
• Assignment, Blocker, Evidence, Decision, Review, RecurringElement
• AttentionItem, NextActionCandidate (Read Models via backend/steering/)

UI-Regel: Workspace = Portfolio aller Initiativen. Initiative-Übersicht = operative Steuerung (Alltag). Pflege/Anlage auf Unterseiten. Vibe-Coder über Operational Actor Interface (API).

Prompt-/KI-/Workflow-/MCP-Themen bleiben eingefroren, bis der MVP-Fachkern entlang des Operating Models trägt.

---

3. Designprinzipien als Referenz

Die Designprinzipien aus Mitai und Shinkan liegen unter:

docs/reference/design-principles/
  mitai/
  shinkan/
  alignment/

Diese Dokumente sind Referenzmaterial, nicht direkter Arbeitsauftrag.

Sie dienen dazu, Entscheidungen zu begründen und bekannte Anti-Patterns zu vermeiden.

Sie dürfen nicht dazu verwendet werden, Kairo mit Mitai- oder Shinkan-Domänenlogik zu überladen.

---

4. Auslegungsreihenfolge bei Konflikten

Siehe Abschnitt 2 — die Product-Reset-Reihenfolge ist verbindlich.

Bei technischen Foundation-Konflikten zusätzlich:

• Kairo_Sprint0_Principle_Gate_v0.1.md
• Jinkendo_Foundation_Minimum_Viable_Foundation_v0.2.md

Mitai/Shinkan-Prinzipien dürfen Kairo nicht überstimmen.

---

5. Verbindliche Regeln

1. Kairo ist mandantenfähig.
2. Alle operativen Zuweisungen laufen über Actors.
3. User und Actor sind nicht dasselbe.
4. Agenten sind Actors, keine Sonderlogik.
5. Jeder geschützte Request soll über TenantContext aufgelöst werden.
6. Auth, Capability, Feature und Governance sind getrennte Konzepte.
7. Rechte und Capabilities werden nicht verstreut hardcodiert.
8. Prompts werden nicht hardcodiert.
9. Platzhalter werden validiert.
10. Fachliche Konfiguration wird nicht hardcodiert.
11. Admin- und Agentenaktionen werden auditiert.
12. Migrationen sind nummeriert und reproduzierbar.

Plugin-Architektur (AP2.3 / AP2.4 — verbindlich)

13. Archetyp ≠ Methode: Archetyp = IA-Hülle + om_capabilities; Methode = Steuerungsmotor (steering_elements, ui_features, Strategie).
14. Runtime-Auflösung über GET …/operating-context — kein hardcodiertes Methoden-/Archetyp-UI in React-Pages.
15. Neue Archetypen/Methoden nur über Registrierungsmodule (entity_archetypes/, steering/methods/registrations/) — Open/Closed.
16. Control-/Work-UI aus steering_elements + steeringElementRegistry.js, nicht aus Archetyp-Ifs.
17. Siehe .cursor/rules/kairo-plugin-architecture.mdc und ADP AP2.3 / AP2.4.

---

6. Nicht tun

• Kairo auf Initiative → Action reduzieren oder als To-do-Tool behandeln
• InitiativeDetail weiter als Omnibus-CRUD-Seite ausbauen (Layout-Patches)
• Inline-Listenformulare als Haupt-Bearbeitungs-Pattern einführen
• Meilensteine als Status-Dropdown ohne Gate-Verifikation behandeln
• Prompt-/KI-/Workflow-/MCP-Arbeit vor Operating-Model-MVP
• keine Mitai-Domänenlogik kopieren
• keine Shinkan-Domänenlogik kopieren
• keine Trainingsplanung bauen
• keine Gesundheitslogik bauen
• keine Lebensmanager-/Seichō-Logik in Kairo einbauen
• kein Billing oder SSO bauen
• keine strategischen Produktentscheidungen eigenmächtig ändern
• keine Designprinzipien aus docs/reference/ ohne Principle-Gate oder Architecture Decision in Scope ziehen
• keine Archetyp-Ifs in Pages für Steuerungs-UI (initiative.product === …) — AP2.4 steering_elements
• methodUiDefaults.js nicht für neue Archetypen erweitern — Operating Context + Resolver
• kein Full-load() nach OM-Mutationen — refreshOm([sliceKeys])

---

7. Abweichungen

Bei notwendiger Abweichung erstelle ein Architecture Decision Proposal.

---

8. Nächste Entwicklungsschritte

Siehe docs/product/Kairo_Corrected_MVP_Roadmap_v0.2.md und Sprint1_AP1_2c_IA_Skeleton_Assignment_v0.1.md.

Foundation AP0.1–AP2.4 Plugin-Architektur geliefert. Produkt: Specs Welle 1 → AP2.2b/c/e + AP1.9d → AP2.1 Validation. Scope Lock: ADP_AP1_0_Steering_Foundation_Scope_Lock_v0.1.md; Plugin: ADP AP2.3/AP2.4.