Lars/Kairo-Jinkendo
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
1ce20d8bdb
Kairo-Jinkendo/CLAUDE.md
Lars 0e2b938fbd
Some checks failed
Test Suite / lint-backend (push) Waiting to run
Details
Test Suite / build-frontend (push) Waiting to run
Details
Test Suite / k6 /health Baseline (push) Waiting to run
Details
Test Suite / playwright-tests (push) Waiting to run
Details
Deploy Development / deploy (push) Failing after 0s
Details
Test Suite / pytest-backend (push) Has been cancelled
Details
Sprint-0-Grundlagen: Spec-Handover, Designprinzipien-Referenz, Medien optional. 
Co-authored-by: Cursor <cursoragent@cursor.com>
2026-07-04 19:03:57 +02:00

3.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.

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:

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.