Lars/Kairo-Jinkendo
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
a520d54bcf
Kairo-Jinkendo/CLAUDE.md
Lars 95feba6204
All checks were successful
Deploy Development / deploy (push) Successful in 44s
Details
Test Suite / pytest-backend (push) Successful in 1m19s
Details
Test Suite / lint-backend (push) Successful in 2s
Details
Test Suite / compose-smoke (push) Has been skipped
Details
Test Suite / k6 /api/health Baseline (push) Successful in 18s
Details
Test Suite / playwright-smoke (push) Successful in 11s
Details
AP1.0: Steering Foundation — Lifecycle, Context, Signal Engine 
Persistierter Standard Lifecycle pro Initiative, backend/steering/ Skeleton, Attention-Refactor und Hook-Dispatch als Basis für Method Registry.

Co-authored-by: Cursor <cursoragent@cursor.com>
2026-07-05 17:09:20 +02:00

5.1 KiB
Raw Blame History

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

Sprint 0 — Foundation und erster technischer Slice abgeschlossen (AP0.1–AP0.7, AP0.6b).

Bereits vorhanden:

  • Tenant, User, Actor, TenantContext, Auth, Capabilities
  • Feature / Prompt / Config Registry
  • Vorhaben / Maßnahmen (technischer Startpunkt, nicht Zielmodell)
  • Workspace-GUI, Data Layer Minimum, Actor Directory
  • Tenant-Invarianten, Product Reset (AP0.R1)

Nächster Fokus: MVP-Fachkern entlang des Canonical Operating Models — nicht weitere Foundation ohne Produktbezug.

2. Verbindliche Primärdokumente

Lies bei Projektstart in dieser Reihenfolge:

  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
  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/CLAUDE_Product_Direction_Addendum_v0.1.md
  7. docs/architecture/Kairo_Tenant_Invariants_v0.1.md
  8. docs/architecture/Kairo_Sprint0_Principle_Gate_v0.1.md
  9. docs/sprints/Jinkendo_Kairo_04_Sprint0_Foundation_v0.3.md
  10. docs/sprints/Sprint0_Vibe_Coder_Handover_v0.1.md
  11. docs/architecture/Kairo_Architecture_References_v0.1.md
  12. .cursor/rules/kairo-architecture.mdc

Bei Konflikten gilt folgende Auslegungsreihenfolge:

  1. Product & MVP Reset
  2. Canonical Operating Model
  3. Corrected MVP Roadmap
  4. ursprüngliche Product Spec
  5. Current State & Gap Analysis
  6. Product Direction Addendum
  7. Tenant Invariants
  8. Sprint-0 Principle Gate
  9. Sprint-0 Foundation
  10. Architecture References
  11. Mitai/Shinkan Designprinzipien und Referenzcode

Die frühere Product Spec bleibt gültige Grundlage, wird aber durch Reset und Operating Model konkretisiert.

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:

  • Initiative / Vorhaben
  • Project optional
  • Milestone
  • BacklogItem
  • Action
  • Assignment to Actor
  • Blocker
  • Decision
  • Evidence
  • Review
  • RecurringElement
  • AttentionItem
  • NextActionCandidate

Neue Implementierungsaufträge müssen die Program-Director-Vision stützen oder eine konkret dokumentierte Umbaufalle verhindern.

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.

6. Nicht tun

  • Kairo auf Initiative → Action reduzieren oder als To-do-Tool 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

7. Abweichungen

Bei notwendiger Abweichung erstelle ein Architecture Decision Proposal.

8. Nächste Entwicklungsschritte

Siehe docs/product/Kairo_Corrected_MVP_Roadmap_v0.1.md und Abschlussberichte AP0.7 / AP0.R1.

Foundation AP0.1–AP0.7 ist abgeschlossen. Strategiewechsel (2026-07-05): AP1.0 Steering Foundation als nächstes Code-Paket — siehe docs/architecture/ADP_AP1_0_Steering_Foundation_Scope_Lock_v0.1.md. AP0.10c eingefroren. Keine parallele Steuerungslogik außerhalb backend/steering/.