Lars
0e5bf72dee
Some checks failed
Deploy Development / deploy (push) Successful in 41s
Test Suite / compose-smoke (push) Failing after 3s
Test Suite / pytest-backend (push) Has been skipped
Test Suite / lint-backend (push) Successful in 1s
Test Suite / build-frontend (push) Successful in 1m7s
Test Suite / k6 /api/health Baseline (push) Has been skipped
Test Suite / playwright-smoke (push) Has been skipped
Co-authored-by: Cursor <cursoragent@cursor.com>
121 lines
3.1 KiB
Markdown
121 lines
3.1 KiB
Markdown
# 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:
|
||
|
||
1. `docs/product/Jinkendo_Kairo_Product_Spec_v0.2.md`
|
||
2. `docs/architecture/Kairo_Sprint0_Principle_Gate_v0.1.md`
|
||
3. `docs/sprints/Jinkendo_Kairo_04_Sprint0_Foundation_v0.3.md`
|
||
4. `docs/sprints/Sprint0_Vibe_Coder_Handover_v0.1.md`
|
||
5. `docs/architecture/Kairo_Architecture_References_v0.1.md`
|
||
6. `.cursor/rules/kairo-architecture.mdc`
|
||
|
||
---
|
||
|
||
## 3. Designprinzipien als Referenz
|
||
|
||
Die Designprinzipien aus Mitai und Shinkan liegen unter:
|
||
|
||
```text
|
||
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:
|
||
|
||
1. `Kairo_Sprint0_Principle_Gate_v0.1.md`
|
||
2. `Jinkendo_Kairo_04_Sprint0_Foundation_v0.3.md`
|
||
3. `Jinkendo_Kairo_Product_Spec_v0.2.md`
|
||
4. `Jinkendo_Foundation_Minimum_Viable_Foundation_v0.2.md`
|
||
5. `DESIGN_PRINCIPLES_ALIGNMENT.md`
|
||
6. Mitai/Shinkan Einzelprinzipien
|
||
|
||
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
|
||
|
||
- 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 (Backend, Frontend minimal, Tests, Deploy).
|