Lars
2796965aed
All checks were successful
Deploy Development / deploy (push) Successful in 44s
Test Suite / pytest-backend (push) Successful in 1m23s
Test Suite / lint-backend (push) Successful in 1s
Test Suite / compose-smoke (push) Has been skipped
Test Suite / k6 /api/health Baseline (push) Successful in 18s
Test Suite / playwright-smoke (push) Successful in 12s
Corrected MVP Roadmap v0.2, Recovery Plan v0.2, Gap Analysis v0.2, Target State Implementation Map. ADPs für RoadmapItem/Quality Gates und Operational Actor Interface (Vibe-Coder). Handover v0.2 und Sprint-Auftrag AP1.2c IA-Skeleton.
115 lines
2.1 KiB
Markdown
115 lines
2.1 KiB
Markdown
# Jinkendo Kairo
|
||
## Sprint 0 – Vibe-Coder Handover v0.1
|
||
|
||
> **⚠ Superseded (2026-07-05):** Verwende [`Sprint0_Vibe_Coder_Handover_v0.2.md`](Sprint0_Vibe_Coder_Handover_v0.2.md).
|
||
|
||
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.
|