Lars
1ce20d8bdb
Some checks failed
Test Suite / playwright-tests (push) Waiting to run
Deploy Development / deploy (push) Failing after 0s
Test Suite / pytest-backend (push) Failing after 5m1s
Test Suite / lint-backend (push) Failing after 0s
Test Suite / build-frontend (push) Successful in 0s
Test Suite / k6 /api/health Baseline (push) Has been cancelled
Co-authored-by: Cursor <cursoragent@cursor.com>
113 lines
2.0 KiB
Markdown
113 lines
2.0 KiB
Markdown
# Jinkendo Kairo
|
||
## Sprint 0 – Vibe-Coder Handover v0.1
|
||
|
||
Status: Übergabedokument
|
||
Stand: 2026-07-04
|
||
|
||
---
|
||
|
||
## 1. Auftrag
|
||
|
||
Baue nicht sofort den Program Director.
|
||
|
||
Baue zuerst das Fundament, damit der Program Director später sauber entstehen kann.
|
||
|
||
Sprint 0 ist erfolgreich, wenn Kairo technisch und fachlich vorbereitet ist für:
|
||
|
||
- Mandanten
|
||
- Actors
|
||
- Rechte/Capabilities
|
||
- Prompts
|
||
- Platzhalter
|
||
- Konfiguration
|
||
- Audit
|
||
- spätere KI-Agenten
|
||
|
||
---
|
||
|
||
## 2. Verbindliche Dokumente
|
||
|
||
Lies in dieser Reihenfolge:
|
||
|
||
1. `README.md`
|
||
2. `docs/product/Jinkendo_Kairo_Product_Spec_v0.2.md`
|
||
3. `docs/architecture/Kairo_Sprint0_Principle_Gate_v0.1.md`
|
||
4. `docs/sprints/Jinkendo_Kairo_04_Sprint0_Foundation_v0.3.md`
|
||
5. `CLAUDE.md`
|
||
6. `.cursor/rules/kairo-architecture.mdc`
|
||
|
||
---
|
||
|
||
## 3. Arbeitsprinzip
|
||
|
||
Du darfst technische Details ausarbeiten.
|
||
|
||
Du darfst keine fachlichen Architekturprinzipien ändern.
|
||
|
||
Wenn eine Änderung notwendig erscheint, erstelle ein Architecture Decision Proposal.
|
||
|
||
---
|
||
|
||
## 4. Harte Guardrails
|
||
|
||
Nicht erlaubt:
|
||
|
||
- Kairo als Single-User-App bauen
|
||
- Tenant weglassen
|
||
- Actor durch User ersetzen
|
||
- Agenten als Sonderlogik außerhalb Actor-Modell behandeln
|
||
- Rollen/Rechte hardcoden
|
||
- Prompts hardcoden
|
||
- Feature Registry weglassen
|
||
- Prompt Registry weglassen
|
||
- Placeholder-Validation weglassen
|
||
- Audit weglassen
|
||
- Vorhaben/Projektlogik vor Sprint-0-Abschluss implementieren
|
||
- Billing/Usage-Limits vorziehen
|
||
- Mitai- oder Shinkan-Domänenlogik kopieren
|
||
|
||
---
|
||
|
||
## 5. Erwartete Arbeitsweise
|
||
|
||
Für jedes Arbeitspaket:
|
||
|
||
1. Kurzplan erstellen
|
||
2. Implementieren
|
||
3. Tests ergänzen
|
||
4. README oder relevante Doku aktualisieren
|
||
5. Abweichungen dokumentieren
|
||
6. Offene Fragen klar markieren
|
||
|
||
---
|
||
|
||
## 6. Architecture Decision Proposal Format
|
||
|
||
```markdown
|
||
# Architecture Decision Proposal
|
||
|
||
## Problem
|
||
|
||
## Betroffene Regel
|
||
|
||
## Optionen
|
||
|
||
## Empfehlung
|
||
|
||
## Risiko
|
||
|
||
## Rückbaubarkeit
|
||
|
||
## Auswirkung auf Sprint 0
|
||
```
|
||
|
||
---
|
||
|
||
## 7. AP0.1 zuerst
|
||
|
||
Der erste Auftrag ist ausschließlich AP0.1 – Projektgrundlage.
|
||
|
||
Kein Sprint-0-Gesamtbau.
|
||
|
||
Kein Vorziehen von AP0.2–AP0.5 ohne Review.
|