Co-authored-by: Cursor <cursoragent@cursor.com>
3.1 KiB
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.
Es geht noch nicht um die vollständige Fachanwendung, sondern um das Fundament.
Sprint 0 baut:
- Tenant
- User
- Actor
- TenantContext
- Auth-Gates
- Capability / Rights Registry
- minimale Feature Registry
- minimale Prompt Registry
- Placeholder Validation
- Configuration-Grundmodell
- Audit
- Migration/Deploy-Grundlage
2. Verbindliche Primärdokumente
Lies bei Projektstart in dieser Reihenfolge:
docs/product/Jinkendo_Kairo_Product_Spec_v0.2.mddocs/architecture/Kairo_Sprint0_Principle_Gate_v0.1.mddocs/sprints/Jinkendo_Kairo_04_Sprint0_Foundation_v0.3.mddocs/sprints/Sprint0_Vibe_Coder_Handover_v0.1.mddocs/architecture/Kairo_Architecture_References_v0.1.md.cursor/rules/kairo-architecture.mdc
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
Bei Konflikten gilt:
Kairo_Sprint0_Principle_Gate_v0.1.mdJinkendo_Kairo_04_Sprint0_Foundation_v0.3.mdJinkendo_Kairo_Product_Spec_v0.2.mdJinkendo_Foundation_Minimum_Viable_Foundation_v0.2.mdDESIGN_PRINCIPLES_ALIGNMENT.md- Mitai/Shinkan Einzelprinzipien
Mitai/Shinkan-Prinzipien dürfen Kairo nicht überstimmen.
5. Verbindliche Regeln
- Kairo ist mandantenfähig.
- Alle operativen Zuweisungen laufen über Actors.
- User und Actor sind nicht dasselbe.
- Agenten sind Actors, keine Sonderlogik.
- Jeder geschützte Request soll über TenantContext aufgelöst werden.
- Auth, Capability, Feature und Governance sind getrennte Konzepte.
- Rechte und Capabilities werden nicht verstreut hardcodiert.
- Prompts werden nicht hardcodiert.
- Platzhalter werden validiert.
- Fachliche Konfiguration wird nicht hardcodiert.
- Admin- und Agentenaktionen werden auditiert.
- Migrationen sind nummeriert und reproduzierbar.
6. Nicht tun
- keine Mitai-Domänenlogik kopieren
- keine Shinkan-Domänenlogik kopieren
- keine Trainingsplanung bauen
- keine Gesundheitslogik bauen
- keine Lebensmanager-/Seichō-Logik in Kairo einbauen
- keine Vorhaben-/Projektlogik in AP0.1 vorziehen
- 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. Aktueller erster Auftrag
AP0.1 – Projektgrundlage.