2026-07-04 19:08:55 +02:00
|
|
|
|
# Jinkendo Kairo
|
|
|
|
|
|
## Sprint 0 – Vibe-Coder Handover v0.1
|
|
|
|
|
|
|
2026-07-05 18:17:25 +02:00
|
|
|
|
> **⚠ Superseded (2026-07-05):** Verwende [`Sprint0_Vibe_Coder_Handover_v0.2.md`](Sprint0_Vibe_Coder_Handover_v0.2.md).
|
|
|
|
|
|
|
2026-07-04 19:08:55 +02:00
|
|
|
|
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.
|
