Lars/Kairo-Jinkendo
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
0addcfb382
Kairo-Jinkendo/docs/sprints/Sprint0_Vibe_Coder_Handover_v0.2.md
Lars 2796965aed
All checks were successful
Deploy Development / deploy (push) Successful in 44s
Details
Test Suite / pytest-backend (push) Successful in 1m23s
Details
Test Suite / lint-backend (push) Successful in 1s
Details
Test Suite / compose-smoke (push) Has been skipped
Details
Test Suite / k6 /api/health Baseline (push) Successful in 18s
Details
Test Suite / playwright-smoke (push) Successful in 12s
Details
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

3.2 KiB
Raw Blame History

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

/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)

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.