# 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.*