Kairo-Jinkendo/docs/sprints/Sprint0_Vibe_Coder_Handover_v0.2.md
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
docs: Welle 2 — Roadmap v0.2, ADPs, AP1.2c Assignment
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.
2026-07-05 18:17:25 +02:00

120 lines
3.2 KiB
Markdown

# Jinkendo Kairo
## Vibe-Coder Handover v0.2
**Status:** Übergabedokument für Coding-Agenten & Vibe-Coder
**Stand:** 2026-07-05
**Ersetzt:** `Sprint0_Vibe_Coder_Handover_v0.1.md` (Foundation-only)
**Vision:** `Kairo_Vision_and_Product_Direction_v0.2.md`
---
## 1. Auftrag
Baue **keinen** weiteren Omnibus-CRUD-Screen.
Baue Kairo als **Program Director** mit:
1. **Workspace** — Portfolio aller Initiativen
2. **Initiative-Übersicht** — operative Steuerung (Alltag)
3. **Unterseiten** — Pflege und Anlage
4. **Operational API** (später AP1.7) — dieselbe Logik für Agent-Actors
---
## 2. Verbindliche Dokumente (Lesereihenfolge)
1. `docs/product/Kairo_Vision_and_Product_Direction_v0.2.md`
2. `docs/product/Kairo_Canonical_Operating_Model_v0.2.md`
3. `docs/product/Kairo_Implementation_Truth_Table_v0.1.md`
4. `docs/product/Kairo_Corrected_MVP_Roadmap_v0.2.md`
5. `docs/sprints/Sprint1_AP1_2c_IA_Skeleton_Assignment_v0.1.md`**nächster Code-Auftrag**
6. `docs/architecture/ADP_AP1_0_Steering_Foundation_Scope_Lock_v0.1.md`
7. `CLAUDE.md` + `.cursor/rules/kairo-architecture.mdc`
---
## 3. IA — drei Ebenen
```text
/workspace Portfolio aller Initiativen
/initiatives/:id Initiative-Übersicht (Steuerung, read-heavy)
/initiatives/:id/plan Plan (Shell → AP1.4 Daten)
/initiatives/:id/execution Ausführung / Arbeitspakete
/initiatives/:id/inbox Backlog
/initiatives/:id/journey Journey (Shell → AP1.6)
/initiatives/:id/actions/:actionId Arbeitspaket-Detail
```
**Regel:** Übersicht = navigieren + steuern. CRUD = Unterseiten oder Modal.
---
## 4. Vibe-Coder als Actor
- Agent = `actors.actor_type = 'agent'`
- Keine Sonder-Endpoints ohne `/api/operational/` (AP1.7)
- Bis AP1.7: bestehende REST-APIs mit Actor-Session **nur** wenn Capability passt — Spec in `ADP_Operational_Actor_Interface_Vibe_Coder_v0.1.md`
### Typischer Agent-Loop (Ziel)
```text
1. GET operational/context?initiative_id=
2. GET operational/next-action?initiative_id=
3. … arbeiten …
4. PATCH operational/actions/{id}/status
5. POST operational/evidence (optional)
6. POST operational/blockers (wenn nötig)
```
---
## 5. Harte Guardrails
Nicht erlaubt:
- InitiativeDetail Omnibus erweitern
- Inline-Formulare auf Workspace oder Initiative-Übersicht
- Parallele Steuerungslogik außerhalb `backend/steering/`
- Neue OM-Tabellen ohne ADP (Scope Lock)
- Gate `reached` per API ohne Verify
- Prompt/KI/MCP produktiv
---
## 6. Arbeitsweise pro Paket
1. Assignment lesen
2. Kurzplan
3. Implementieren (minimaler Diff)
4. Tests (Pi-pytest wo DB)
5. Truth Table + Gap Analysis aktualisieren
6. Version bump
7. Abweichung → ADP
---
## 7. Nächste Pakete
| Reihenfolge | Paket |
|-------------|-------|
| 1 | AP1.2c IA-Skeleton |
| 2 | AP1.2 Signals |
| 3 | AP0.10d Validation (PO) |
| 4 | AP1.4 RoadmapItem (nach ADP-Freigabe) |
| 5 | AP1.7 Operational API |
---
## 8. Erfolg
Du bist auf dem richtigen Weg wenn:
- PO auf Initiative-**Übersicht** steuern kann ohne zu pflegen
- Workspace alle Vorhaben orientiert
- Vibe-Coder wissen welche API kommt
- Docs und Code dieselbe IA zeigen
---
*v0.1 Handover bleibt historisch für Sprint-0-Foundation.*