Compare commits

...

2 Commits

Author SHA1 Message Date
dc6f25b673 feat(product): Plan-Arbeit fuer Direct-AP-Pfad (ADP P1)
All checks were successful
Deploy Development / deploy (push) Successful in 49s
Test Suite / pytest-backend (push) Successful in 3m45s
Test Suite / lint-backend (push) Successful in 2s
Test Suite / compose-smoke (push) Has been skipped
Test Suite / k6 /api/health Baseline (push) Successful in 19s
Test Suite / playwright-smoke (push) Successful in 12s
Product-Outline enthaelt work; planOutlineKeys-Reihenfolge steuert Sidebar; Product-spezifischer Lead auf Plan-Arbeit.
2026-07-26 18:25:12 +02:00
f7d65dde01 docs: Backlog-Hierarchie, Dual Commit Path und Epic-Zielbild
ADP v0.1 plus Updates in B2b-Spec, agile_iteration, Katalog und Truth Table.
2026-07-26 18:25:12 +02:00
17 changed files with 352 additions and 24 deletions

View File

@ -83,7 +83,7 @@ INITIATIVE_UI_PROFILES: dict[str, dict[str, Any]] = {
"workDefaultRoute": "/work/sprint",
"workDefaultRouteWithoutActiveWorkCycle": "/work/today",
"controlDefaultRoute": "/control/status",
"planOutlineKeys": ["profile", "inbox", "sprint", "gates"],
"planOutlineKeys": ["profile", "inbox", "work", "sprint", "gates"],
"workNavKeys": ["sprint", "today", "mine"],
"dataSlices": [
"backlog",

View File

@ -213,11 +213,13 @@ Kanoniche Typen aus OM v0.2 — **keine eigenen Tabellen** pro Typ.
**Sprint-Backlog-Semantik (B3):**
- **Product Backlog** = `BacklogItem` (+ optional Gate-Link) — Plan-Eingang
- **Product Backlog** = `BacklogItem` (+ optional Gate-Link, optional Epic-Baum) — Plan-Eingang
- **Sprint Backlog** = `Action` (Status open/ready/in_progress) mit **`work_cycle_id`** (FK auf `roadmap_items.id` wo `item_type=work_cycle`)
- Commit aus Eingang → Action **mit** aktivem Zyklus = Sprint-Commit
- Abgeschlossener Sprint: Actions done/cancelled; Zyklus `reached` oder `closed`; Review optional via `Review`-Objekt
**Dual Commit & Epic:** [`ADP_Backlog_Hierarchy_and_Dual_Commit_Path_v0.1.md`](ADP_Backlog_Hierarchy_and_Dual_Commit_Path_v0.1.md)
Migration: `actions.work_cycle_id UUID NULL REFERENCES roadmap_items(id)` (AP2.0f).
### 3.5 Agile-Begriffe — Abbildung in Kairo
@ -225,6 +227,8 @@ Migration: `actions.work_cycle_id UUID NULL REFERENCES roadmap_items(id)` (AP2.0
| Scrum/Agile-Begriff | In Kairo | Status |
|---------------------|----------|--------|
| Product Backlog | `BacklogItem`, Plan → Eingang | ✓ implementiert |
| **Epic** | `BacklogItem` `item_kind=epic` + `parent_backlog_id`-Baum | ○ ADP P2 — **nicht** RoadmapItem |
| **Story** | `BacklogItem` `item_kind=story` → Commit → `Action` | ✓ (ohne Epic-Parent) |
| Sprint | `RoadmapItem(type=work_cycle)` | ○ Katalog + AP2.0f |
| Sprint Goal | `work_cycle.title` + optional EFS `sprint_goal` | ○ |
| Sprint Backlog | `Action.work_cycle_id` | ○ AP2.0f |
@ -235,6 +239,8 @@ Migration: `actions.work_cycle_id UUID NULL REFERENCES roadmap_items(id)` (AP2.0
| Velocity / Burndown | — | **explizit post-MVP** |
| Kanban-Board | — | **explizit nicht Kern** |
| Story Points | EFS optional | post-MVP |
| **Direct AP (ohne Backlog)** | `Action` direkt — Plan → Arbeit | ○ ADP P1 (Continuous) |
| **Agent Task-Baum** | `Task` unter `Action` | ◐ ADP Recursive Containers |
### 3.6 Explizit nicht im MVP-Kern (Anti-Scope)

View File

@ -0,0 +1,202 @@
# ADP — Backlog-Hierarchie, Dual Commit Path & Agile-Vollmodell v0.1
**Status:** PO-Freigabe (Dokumentation vor Implementierung)
**Stand:** 2026-07-26
**Autor:** Product / Architecture (Session PO 2026-07-26)
**Bezug:** Canonical OM v0.2, ADP Archetype Catalog v0.2 §3.43.5, SPEC B2b, SPEC-D `agile_iteration` / `continuous_product`, ADP Recursive Containers v0.1, Steering Kernel Spine
---
## 1. Problem
Kairo muss **zwei gleichwertige Commit-Pfade** unterstützen, ohne das Operating Model zu verwässern:
1. **Agile/Scrum (Jira-Vokabular):** Eingang mit Hierarchie (Epic → Story → Bug/Issue) → Sprint-Planung → committete Actions.
2. **Continuous / Programmentwicklung:** Ad-hoc-**Arbeitspakete** aus laufender Entwicklung (Erkenntnis, Spike, Nacharbeit) **ohne** Backlog-Umweg — nicht zwingend Bug.
**Ist-Zustand (MVP):** Global hardcodiert `story` / `bug` / `issue`; kein Epic; kein `parent_backlog_id`; Product-UI ohne direktes AP-Anlegen; Epic als Gate/Meilenstein wäre semantisch falsch.
**PO-Anforderung:** Agile-Volllogik dokumentieren und implementierbar machen; Continuous-Pfad explizit; Epic **nicht** als RoadmapItem; Kairo als **Program Director** für Agent-Steuerung (Actor-first, Kernel — nicht Prompt-Drift).
---
## 2. Betroffene Regeln
| Dokument | Regel |
|----------|--------|
| Canonical OM v0.2 | Plan (Backlog) vs. Ist (Action); Gates orthogonal |
| ADP Catalog §3.4 | BacklogItem ≠ Sprint-Backlog; Action.work_cycle_id = Sprint-Ist |
| ADP Catalog §3.5 | Agile-Begriffe — Epic fehlte |
| SPEC B2b | Eingang Pflicht-Kanal **für Triage**, nicht für jeden Commit |
| SPEC-D agile_iteration | Modifier — volle Sprint-Logik, keine Vorhaben-Natur |
| ADP Recursive Containers | Task-Hierarchie unter Action für Agent-Granularität |
| Steering Kernel | Leading = committete Action; Next/Attention in `backend/steering/` |
| Plugin-Architektur AP2.3/4 | Backlog-Typen methoden-/profilgebunden, keine Page-Ifs |
---
## 3. Entscheidung — Schichtmodell
### 3.1 Zwei Commit-Pfade (Dual Commit Path)
| Pfad | Wann | Flow | Leading nach Commit |
|------|------|------|---------------------|
| **A — Intake → Commit** | Geplante/große Arbeit, Refinement, Scrum | `BacklogItem` → triage → convert → `Action` | Primary + optional Sprint |
| **B — Direct Commit** | Ad-hoc aus Ist, Erkenntnis, Spike, Agent-Auftrag | `Action` direkt anlegen (optional Gate/Project) | Primary + optional Sprint |
Beide Pfade erzeugen dasselbe Ist-Objekt: **`Action` (Arbeitspaket)**.
Backlog ist **Plan-Eingang**, kein Ersatz für committete Arbeit.
**Guardrail:** Pfad B darf Pfad A nicht ersetzen müssen — UI muss **Plan → Arbeit** (direct AP) für Continuous-Profile anbieten (Product, Programm).
### 3.2 Backlog-Hierarchie (Agile / Jira)
Epic ist **Liefercontainer im Eingang**, kein Gate:
```text
BacklogItem (Plan-Eingang)
├── item_kind = epic parent_backlog_id = NULL
│ └── Story/Bug/Issue parent_backlog_id → Epic
└── optional roadmap_item_id (Gate-Orientierung — orthogonal)
Commit (convert):
Story → Action (action_kind=delivery)
Bug/Issue → Action (action_kind=bug|issue) + optional parent_action_id → Feature-AP
Sprint (Modifier agile_iteration):
Commit mit work_cycle_id → Action im Sprint-Backlog (Ist!)
```
**Epic-Fortschritt** = Roll-up aus committeten/erledigten Stories/Actions im Epic-Subbaum — **nicht** Gate-Status.
**Anti-Pattern (verboten):** Epic als `RoadmapItem` / Meilenstein modellieren — verschleiert Ausgangslage und Ist-Fortschritt.
### 3.3 Gates vs. Epics
| Konzept | Ebene | Zweck |
|---------|-------|-------|
| **Gate / RoadmapItem** | Plan-Horizont | Orientierung, Reife, Release-Rahmen |
| **Epic / BacklogItem** | Plan-Eingang | Lieferumfang, Zerlegung, Refinement |
| **Action** | Ist | Committete Ausführungseinheit |
| **Task** | Ist (sub) | Granularität, v. a. Agent-Schritte |
Epic kann **optional** ein Orientierungs-Gate referenzieren (`roadmap_item_id`) — ohne Epic = Gate zu ersetzen.
### 3.4 Vokabular — methoden-/profilgebunden
| Kontext | Backlog-Typen (UI/API) | Labels |
|---------|------------------------|--------|
| **Continuous Product** (Default B2b) | `idea`, `bug`, `incident` (Ziel) | Kairo Product Language |
| **Agile-Profil** (`agile_iteration` aktiv / Profil) | `epic`, `story`, `bug`, `issue` | Jira-nah |
| **MVP-Ist** | `story`, `bug`, `issue` | AP2.2e — Migration geplant |
Steuerung über **Methoden-Vertrag** / `method_profile_key` — nicht hardcodiert in Pages.
### 3.5 Agent-Steuerung (Program Director)
Kairo bleibt **Steuerungskern**; Agents sind **Actors**:
| Schicht | Verantwortung |
|---------|----------------|
| Kairo (Initiative, Kernel) | Scope, Plan/Ist, Next Action, Attention, Gates, Epic-Roll-up |
| Actor (Agent/Mensch) | Ausführung am committeten AP + Task-Baum |
| Nicht im Prompt | Roadmap, Sprint-Stand, Prioritäten — kommen aus Operating Context / Snapshot |
**Leading Work** für Mensch und Agent = **`Action`** (ggf. Sprint-gefiltert).
**Tasks** = Ausführungsgranularität (ADP Recursive Tasks); Steuerung bleibt auf Action-Ebene.
Ziel: Programmentwicklung **fast autark durch Kairo** steuerbar — Agents näher am Kern, weniger Drift durch Kontextfenster.
---
## 4. Optionen (Epic-Modellierung)
| Option | Beschreibung | Pro | Contra |
|--------|--------------|-----|--------|
| A | Epic = `RoadmapItem` | Bestehende Gate-UI | Falsche Semantik; kein Story-Roll-up |
| B | Epic = `BacklogItem` + `parent_backlog_id` | Plan/Ist-trennungskonform; Jira-parallel | Migration + Baum-UI nötig |
| C | Eigene Tabelle `epics` | Klare UI | Parallel-Welt; OM-Inflation |
**Empfehlung: Option B** — gleiche Entität `backlog_items`, erweiterte `item_kind` + `parent_backlog_id`.
---
## 5. Schema-Ziel (Implementierung — noch nicht geliefert)
```sql
-- Ziel-Migration (nummeriert, kein ad-hoc DDL in Routern)
ALTER TABLE backlog_items
ADD COLUMN parent_backlog_id UUID NULL REFERENCES backlog_items(id) ON DELETE SET NULL;
ALTER TABLE backlog_items DROP CONSTRAINT ...;
ALTER TABLE backlog_items ADD CONSTRAINT backlog_items_item_kind_check
CHECK (item_kind IN ('epic', 'story', 'bug', 'issue', 'idea', 'incident'));
-- Exact set profile-filtered in service layer
```
**Convert-Regeln:**
- `epic` → nicht direkt convertierbar (Container)
- `story` / `idea``Action` delivery
- `bug` / `issue` / `incident``Action` bug/issue + optional Feature-Referenz
- Beim Convert: `source_backlog_id` / Link Epic-Kette in Action-Metadaten oder `backlog_item_id` FK beibehalten für Roll-up
---
## 6. UI / IA (Ziel)
| Fläche | Continuous Product | Agile-Profil |
|--------|-------------------|--------------|
| Plan → Eingang | Triage, optional | Epic-Baum, Story-Refinement |
| Plan → Arbeit | **Direct AP** (Pfad B) | Sichtbar; oft nach Commit |
| Plan → Sprint | optional | Sprint-Planung aus Eingang |
| Labels | Idee, Bug, Störung | Epic, Story, Bug, Issue |
Product `planOutlineKeys` (Ziel): `profile`, `inbox`, `work`, `sprint`, `gates`**work** ergänzen.
---
## 7. Implementierungsphasen (nach Doku)
| Phase | Inhalt | Abhängigkeit |
|-------|--------|--------------|
| **P0 — Doku** | ADP, Spec-Updates, Katalog §3.5 | ✓ diese ADP |
| **P1 — Direct AP** | Plan → Arbeit im Product-Profil; Product-Labels | UI only |
| **P2 — Backlog-Baum** | `parent_backlog_id`, `item_kind=epic` | Migration |
| **P3 — Profil-Vokabular** | Operating Context liefert erlaubte `backlog_item_kinds` | AP2.4 Erweiterung |
| **P4 — Epic Roll-up** | Read Model Fortschritt / Attention | Steering Kernel |
| **P5 — Agent-Tasks** | Task-Baum unter AP (ADP Recursive) | AP1.5d |
Kein Phase-Sprung ohne ADP/Spec-Referenz.
---
## 8. Risiko
| Risiko | Mitigation |
|--------|------------|
| Todo-Wand im Epic-Baum | Epic convertierbar nur als Container; Leading bleibt Action |
| Doppelte Wahrheit Backlog + Action | Convert markiert Backlog `converted`; Sprint nur auf Action |
| Jira-Kopie | Kein Story Points/Burndown im Kern; nur Steuerungs-Subset |
| Agent-Overload | Tasks unter AP; Kernel liefert ein Next pro Actor-Kontext |
---
## 9. Rückbaubarkeit
- `parent_backlog_id` nullable — flache Backlogs bleiben gültig
- `item_kind`-Erweiterung abwärtskompatibel (`story` Default)
- Direct-AP-Pfad optional pro Archetyp-UI-Profil abschaltbar
- Epic-Roll-up als Read Model — kein Pflichtfeld an Action
---
## 10. Referenzen
| Dokument | Pfad |
|----------|------|
| SPEC B2b Product | `docs/product/archetypes/SPEC_B2b_product_v0.1.md` |
| SPEC-D agile_iteration | `docs/architecture/methods/SPEC_D_agile_iteration_v0.1.md` |
| SPEC-D continuous_product | `docs/architecture/methods/SPEC_D_continuous_product_v0.1.md` |
| UI-Navigation | `docs/product/archetypes/ARCHETYPE_UI_NAVIGATION_v0.1.md` |
| Ist-Stand Backlog | Migration `026_sprint_planning_kinds.sql` |

View File

@ -16,3 +16,5 @@
| `generic_operating` | Primary (Ausführung, Fallback) | SPEC_D_generic_operating_v0.1.md | vorläufig freigegeben|
| `program_delivery` | Primary (**Meta**) | SPEC_D_program_delivery_v0.1.md | vorläufig freigegeben|
| `agile_iteration` | **Komposition** | SPEC_D_agile_iteration_v0.1.md | vorläufig freigegeben|
**Querschnitt:** [`../ADP_Backlog_Hierarchy_and_Dual_Commit_Path_v0.1.md`](../ADP_Backlog_Hierarchy_and_Dual_Commit_Path_v0.1.md) — Epic, Dual Commit, Agent-Steuerung

View File

@ -90,6 +90,44 @@ Elements: `work_cycle_scope`.
---
## D10b Backlog-Hierarchie & Jira-Abbildung (Agile-Vollmodell)
**Verbindlich:** [`ADP_Backlog_Hierarchy_and_Dual_Commit_Path_v0.1.md`](../ADP_Backlog_Hierarchy_and_Dual_Commit_Path_v0.1.md)
Diese Methode **aktiviert** das Scrum/Jira-Vokabular im Eingang — ersetzt nicht die Primary-Methode.
| Jira / Scrum | Kairo (Plan) | Kairo (Ist nach Commit) |
|--------------|--------------|---------------------------|
| Product Backlog | `BacklogItem` (Eingang) | — |
| Epic | `BacklogItem` `item_kind=epic`, Container | Roll-up über Stories/Actions |
| Story | `BacklogItem` `item_kind=story`, `parent_backlog_id` → Epic | `Action` `delivery` |
| Bug | `BacklogItem` `item_kind=bug` | `Action` `bug` (+ Feature-Ref) |
| Issue | `BacklogItem` `item_kind=issue` | `Action` `issue` (+ Feature-Ref) |
| Sprint | `RoadmapItem` `work_cycle` | Filter: `Action.work_cycle_id` |
| Sprint Backlog | — | committete Actions im Sprint (**keine** BacklogItems) |
**Regeln:**
- Epic ist **nicht** `RoadmapItem` / Meilenstein.
- Epic wird **nicht** direkt convertiert — nur Stories/Bugs/Issues darunter.
- Stories können **mehreren Epics** nicht zugeordnet sein (MVP: genau ein `parent_backlog_id`; n:m post-MVP).
- Ohne aktiven Sprint: Backlog-Hierarchie bleibt Plan; Leading = Primary Continuous/Sequential.
**MVP-Ist:** `story`/`bug`/`issue` ohne Epic/`parent_backlog_id` (AP2.2e). Volllogik = ADP Phase P2P3.
---
## D10c Dual Commit Path (Primary + Agile)
| Pfad | Agile-Profil | Primary Continuous |
|------|--------------|-------------------|
| A Intake → Commit | Epic/Story → Sprint optional | Idee → Action |
| B Direct AP | erlaubt (Spike, Agent) | **Pflicht-Option** Plan → Arbeit |
`agile_iteration` verschärft Sprint-Scope; sie **erzwingt** nicht Pfad A für jedes AP.
---
## D12
| Punkt | PO ✓ |

View File

@ -98,6 +98,17 @@ Sprint: Action ∩ `work_cycle_id` des aktiven Sprints (Primary-Ready ∩ Agile-
**Leerer Fall ohne Sprint:** keine ready Action → Attention `planning_debt` / „Eingang triagieren oder committen“ — kein Closure-Druck.
### Dual Commit Path
Verbindlich: [`ADP_Backlog_Hierarchy_and_Dual_Commit_Path_v0.1.md`](../ADP_Backlog_Hierarchy_and_Dual_Commit_Path_v0.1.md)
| Pfad | Beschreibung |
|------|--------------|
| **A** | BacklogItem → convert → Action |
| **B** | Action direkt (Plan → Arbeit) — Continuous-Pflicht für B2b |
Direct AP ist gleichwertig, kein Anti-Pattern.
**Anti:** Sprint-Backlog als BacklogItem-Liste; Product-Backlog als B1-Checklisten-Vorhaben; leere Sprint-Sackgasse ohne aktiven Sprint; Closure erzwingen.
---

View File

@ -41,6 +41,7 @@ Kairo_Implementation_Truth_Table_v0.1.md ← Was ist wirklich da?
|---------|----------|--------|
| Katalog | ADP v0.2 §3§5 | Inventar, Nutzerbild, Scope Lock |
| Plugin | ADP AP2.3 / AP2.4 | Archetyp ↔ Methode, Element-Registry, Operating Context |
| Backlog / Epic | `docs/architecture/ADP_Backlog_Hierarchy_and_Dual_Commit_Path_v0.1.md` | Dual Commit, Epic-Baum, Agile-Vollmodell, Agent-Steuerung |
| UI-Navigation | `docs/product/archetypes/ARCHETYPE_UI_NAVIGATION_v0.1.md` | Nav, Outline, Default-Routen, Slice-Gating — Spec-§6 |
| Spec | `docs/product/archetypes/` | Implementierbare Detail-Spec |
| Auftrag | Sprint Assignments | Scope + DoD für ein AP |

View File

@ -48,6 +48,10 @@ Verhindert, dass Zielbild-Dokumente als Ist-Stand gelesen werden.
| `action_kind` (planning/delivery) | ◐ | Migration 023, API AP1.16a |
| `actions.sort_order` | ◐ | Migration 023 |
| BacklogItem | ✓ | Gate-Zuordnung AP1.6, `sort_order` |
| BacklogItem kinds (MVP) | ◐ | `story`/`bug`/`issue` AP2.2e — global, nicht profilgebunden |
| Backlog Epic-Hierarchie | ✗ | ADP P2: `epic` + `parent_backlog_id` — dokumentiert 2026-07-26 |
| Dual Commit (Direct AP) | ◐ | ADP P1: Plan→Arbeit im Product-Outline (2026-07-26) |
| Profil-Vokabular Backlog | ✗ | ADP P3: Continuous vs. Agile labels via Operating Context |
| Blocker | ✓ | `action_id` optional |
| Milestone | ◐ | Legacy-Tabelle MVP-Brücke; RoadmapItem bevorzugt |
| Evidence | ✓ | `roadmap_item_id`, `action_id`; Gitea-Links in `description` (manuell) |
@ -224,6 +228,7 @@ Details: `Kairo_Status_Review_and_Next_Steps_v0.1.md` §2.1
|----|-----------|
| AP2.3/4 | ✓ Plugin-Architektur + Element-Registry (2026-07-25) |
| AP2.2a | Starter-Kits ◐→✓ |
| ADP Backlog/Epic | P1 Direct AP · P2 Epic-Baum · P3 Profil-Vokabular · P4 Roll-up (2026-07-26 Doku) |
| AP2.2be | Referenz-Archetypen End-to-End ◐→✓ |
| AP2.1 | MVP-Abnahfe ✗→✓ |
| AP1.7b | Op-API Parität |

View File

@ -120,7 +120,20 @@ In **§6 UI / IA** jeder Archetyp-Spec:
---
## 7. Abnahme-Checkliste (Archetyp-Slice)
## 9. Dual Commit Path (Plan vs. Ist)
Verbindlich: [`ADP_Backlog_Hierarchy_and_Dual_Commit_Path_v0.1.md`](../../architecture/ADP_Backlog_Hierarchy_and_Dual_Commit_Path_v0.1.md)
| Pfad | Route (typisch) | Archetyp-Spec |
|------|-----------------|---------------|
| **A — Intake → Commit** | `/plan/inbox` → convert | Eingang Pflicht oder empfohlen |
| **B — Direct AP** | `/plan/work` → create action | Continuous-Pflicht; Agile optional |
Specs müssen beide Pfade in §4 Ist-Objekte und §8 UI benennen. Agile Epic-Hierarchie nur wenn `agile_iteration` / Profil — nicht global hardcodieren.
---
## 10. Abnahme-Checkliste (Archetyp-Slice)
- [ ] Operating Context liefert `ui_profile` mit Spec-konformen Keys und Routen
- [ ] `data_slices` enthält alle für den Archetyp deklarierten Slices, die die Methode unterstützt
@ -140,4 +153,5 @@ In **§6 UI / IA** jeder Archetyp-Spec:
| FE Resolver | `frontend/src/registry/resolveOperatingProfile.js` |
| Route Gating | `frontend/src/registry/OperatingRouteGate.jsx`, `modeRouteRegistry.js` |
| Plugin-ADP | `docs/architecture/ADP_Archetype_Method_Plugin_Architecture_v0.1.md` |
| **Dual Commit / Epic / Agile** | `docs/architecture/ADP_Backlog_Hierarchy_and_Dual_Commit_Path_v0.1.md` |
| Spec-Template §6 | `docs/product/archetypes/_TEMPLATE_Archetype_Spec_v0.1.md` |

View File

@ -5,6 +5,7 @@
**Methodenkern:** [`../../architecture/Kairo_Steering_Method_Kernel_v0.1.md`](../../architecture/Kairo_Steering_Method_Kernel_v0.1.md)
**Methoden Spec-D:** [`../../architecture/methods/README.md`](../../architecture/methods/README.md)
**UI-Navigation (Archetyp):** [`ARCHETYPE_UI_NAVIGATION_v0.1.md`](ARCHETYPE_UI_NAVIGATION_v0.1.md)
**Backlog / Epic / Dual Commit:** [`../../architecture/ADP_Backlog_Hierarchy_and_Dual_Commit_Path_v0.1.md`](../../architecture/ADP_Backlog_Hierarchy_and_Dual_Commit_Path_v0.1.md)
**PO 2026-07-26:** Specs **vorläufig freigegeben** — Implementierungsausreichendheit noch nicht abschließend bewertet.

View File

@ -84,12 +84,31 @@ evidence, decisions, reviews, work_cycles, steering_methods
| Objekt | Rolle | Commit-Regel |
|--------|-------|--------------|
| Action | Leading nach Commit | aus Backlog oder direkt; Assignment |
| Task | unter Action | nicht Leading |
| Action | Leading nach Commit | **Pfad A:** aus Backlog convert · **Pfad B:** direkt anlegen (ad-hoc, Erkenntnis, Agent-Auftrag) |
| Task | unter Action | nicht Leading; Agent-Granularität (ADP Recursive Tasks) |
| Sprint-Backlog | Actions mit `work_cycle_id` | **nicht** BacklogItem-Liste |
| Evidence / Blocker / Decision | Normalbetrieb | Incident/Bug = Normalzustand |
| Review | optional (Sprint/Product-Lage) | |
**Dual Commit Path** (verbindlich): [`ADP_Backlog_Hierarchy_and_Dual_Commit_Path_v0.1.md`](../../architecture/ADP_Backlog_Hierarchy_and_Dual_Commit_Path_v0.1.md) §3.1.
| Pfad | Nutzerbild |
|------|------------|
| **A — Intake → Commit** | Eingang triagieren → „In Arbeitspaket umwandeln“ (optional in Sprint) |
| **B — Direct Commit** | Plan → Arbeit: AP direkt — z. B. Erkenntnis aus laufender Entwicklung, kein Bug, kein Backlog-Umweg |
Pfad B ist für **Continuous/Programmentwicklung** gleichwertig, nicht Ausnahme.
### 4.2b Eingang & Epic (Agile optional)
| Objekt | Continuous (Default) | Mit `agile_iteration` |
|--------|---------------------|------------------------|
| BacklogItem-Typen (Ziel) | Idee, Bug, Störung | Epic, Story, Bug, Issue (Jira-nah) |
| Hierarchie | flach oder Gate-Link | Epic → Story/Bug/Issue via `parent_backlog_id` |
| Epic | **nicht** als Gate/Meilenstein | Liefercontainer im Eingang; Fortschritt = Roll-up aus Commits |
**MVP-Ist:** nur `story`/`bug`/`issue` (AP2.2e); Epic + Direct-AP-UI = dokumentiert, Implementierung P1P3 (ADP §7).
### 4.3 Continuous vs. Sprint
| Situation | Verhalten |
@ -110,6 +129,8 @@ Kein Closure-Zwang. Archiv nur Ausnahmefall. Gates sind Orientierung, nicht „P
- Leerer Sprint-Screen ohne aktiven Sprint
- Closure erzwingen
- Product-Backlog als separates B1-Vorhaben erzwingen
- **Epic als RoadmapItem/Meilenstein** — Lieferumfang ≠ Gate-Horizont
- **Jeden AP nur über Backlog** — Direct Commit (Pfad B) für Continuous unterbinden
---
@ -165,8 +186,9 @@ Kein Closure-Zwang. Archiv nur Ausnahmefall. Gates sind Orientierung, nicht „P
| Fläche | Inhalt |
|--------|--------|
| **Plan → Profil** | Vision, Notizen, EFS |
| **Plan → Eingang / Inbox** | Backlog triage, Commit → Action (`/plan/inbox`) |
| **Plan → Gates** | optionale Orientierungs-Meilensteine |
| **Plan → Eingang / Inbox** | Backlog triage, Commit → Action (Pfad A); optional Epic-Baum bei Agile |
| **Plan → Arbeit** | **Direct AP** (Pfad B) — committete Arbeitspakete am Vorhaben |
| **Plan → Gates** | optionale Orientierungs-Meilensteine (≠ Epic) |
| **Plan → Struktur** | Projects Entwicklung/Betrieb |
| **Plan → Sprint** | anlegen, planen, aktiv, abschließen/Carryover (wenn Agile) |
| **Ausführen / Today** | Continuous Next ohne Sprint |
@ -175,19 +197,23 @@ Kein Closure-Zwang. Archiv nur Ausnahmefall. Gates sind Orientierung, nicht „P
| **Kontrolle** | Next + reason_code; Attention; Sprint-Banner wenn aktiv |
| **Journey** | Commits, Sprint-Events, Incidents, Gate-Verify |
| **Process** | Eingang → (optional Sprint) → Ausführen → Kontrolle |
| **Outline** | profile, inbox, sprint, gates |
| **Product Language** | Sprint, Arbeitspaket, Eingang = Product Backlog |
| **Outline (Ziel)** | profile, inbox, work, sprint, gates |
| **Outline (MVP)** | profile, inbox, work, sprint, gates |
| **Product Language** | Sprint, Arbeitspaket, Eingang; Continuous: Idee/Bug/Störung |
| **Agile Language** | Epic, Story, Bug, Issue (nur wenn Modifier aktiv / Profil) |
| **Nicht** | Closure-Wizard als Kern; Checklisten-Queue als Product-Backlog; leere Sprint-Sackgasse |
Agent-Steuerung: Actors führen Tasks unter AP aus; Leading Next aus Steering Kernel — siehe ADP Dual Commit §3.5.
---
## 9. Happy Path (Abnahme-Flow)
1. Product anlegen → Kit (Gate, Projects, Beispiel-BacklogItem).
2. Item committen → Action.
2. **Pfad A:** Item committen → Action **oder Pfad B:** AP direkt unter Plan → Arbeit.
3. Kontrolle: Next begründet **ohne** Sprint.
4. Kritischen Bug erfassen → Attention/Ranking Incident.
5. Optional: Sprint anlegen → planen → Work zeigt Sprint → complete/Carryover.
5. Optional (Agile): Epic anlegen → Stories → Sprint planen → Work zeigt Sprint → complete/Carryover.
6. Ohne Sprint navigieren → Continuous, kein leerer Sprint-Zwang.
7. Kein Closure nötig für „Erfolg“.
@ -206,10 +232,12 @@ Kein Closure-Zwang. Archiv nur Ausnahmefall. Gates sind Orientierung, nicht „P
| # | Kriterium | Erfüllt wenn |
|---|-----------|--------------|
| 1 | Anlegen | Kit + `continuous_product` |
| 2 | Commit | Eingang → Action |
| 2 | Commit A | Eingang → Action |
| 2b | Commit B | Direct AP unter Plan → Arbeit |
| 3 | Next ohne Sprint | begründet, Horizon ok |
| 4 | Incident | kritische Issue beeinflusst Attention/Ranking |
| 5 | Optional Agile | Sprint-Flow durchspielbar |
| 5b | Optional Agile | Epic → Stories → Commit; Epic-Fortschritt sichtbar |
| 6 | Anti Sprint-Leere | kein leerer Sprint-Screen ohne Sprint |
| 7 | Leitfrage | ≤2 Min |
| 8 | Closure | kein Zwang |
@ -224,7 +252,9 @@ Kein Closure-Zwang. Archiv nur Ausnahmefall. Gates sind Orientierung, nicht „P
|---------|------|------------|-------|
| Registry / Kit | B2b | AP2.2a/d/e/f vorhanden | EFS-Seeds |
| Methode | `continuous_product` | registriert | Strategie an Spec-D halten |
| Agile | composes_with product | vorhanden | nicht Programm-Meta |
| Agile | composes_with product | vorhanden | Epic-Hierarchie, Profil-Vokabular (ADP P2P3) |
| Dual Commit | Pfad A + B | Pfad A + B UI Plan→Arbeit | — |
| Backlog-Typen | Continuous + Agile getrennt | global story/bug/issue | Profil-gebundene kinds |
| UI Continuous/Sprint | diese Spec | weitgehend | Feinschliff leerer Sprint |
| Op-API / Vibe-Coder | Parität | später | AP1.7b |
| EFS | product_vision etc. | lückenhaft | Seed-AP |
@ -239,6 +269,8 @@ Fachmodell vollständig. Feinschliff und Seeds in APs — Spec nicht kürzen.
## 13. Nachfolger
- ADP Backlog-Hierarchie & Dual Commit — [`ADP_Backlog_Hierarchy_and_Dual_Commit_Path_v0.1.md`](../../architecture/ADP_Backlog_Hierarchy_and_Dual_Commit_Path_v0.1.md)
- EFS-Seeds
- Strategy-Parität Spec-D D6/D7
- Vibe-Coder Op-API Parität
- AP P1: Plan→Arbeit Product · P2: Epic/`parent_backlog_id` · P3: Profil-Vokabular

View File

@ -55,8 +55,8 @@
| Objekt | Rolle | Commit-Regel |
|--------|-------|--------------|
| BacklogItem | | |
| Action | | |
| BacklogItem | Eingang | triage; convert → Action (Pfad A) |
| Action | Arbeitspaket | Pfad A: aus Backlog · Pfad B: direkt — ADP Dual Commit |
| Task | | |
| RecurringElement | | |
| Evidence / Decision / Review | | |

View File

@ -54,7 +54,7 @@ const ARCHETYPE_UI = {
planDefaultRoute: '/plan/inbox',
workDefaultRoute: '/work/sprint',
controlDefaultRoute: '/control/status',
planOutlineKeys: ['profile', 'inbox', 'sprint', 'gates'],
planOutlineKeys: ['profile', 'inbox', 'work', 'sprint', 'gates'],
workNavKeys: ['sprint', 'today', 'mine'],
},
'initiative.linear_project': {
@ -130,8 +130,10 @@ export function resolveProcessSteps(input = {}) {
export function resolvePlanOutlineNodes(input = {}) {
const { planOutlineKeys } = resolveMethodUiDefaults(input)
if (!planOutlineKeys) return PLAN_OUTLINE_NODES
const allowed = new Set(planOutlineKeys)
return PLAN_OUTLINE_NODES.filter((node) => allowed.has(node.key))
const order = new Map(planOutlineKeys.map((key, index) => [key, index]))
return PLAN_OUTLINE_NODES.filter((node) => order.has(node.key)).sort(
(a, b) => (order.get(a.key) ?? 0) - (order.get(b.key) ?? 0),
)
}
/**

View File

@ -15,7 +15,7 @@ describe('methodUiDefaults', () => {
})
expect(ui.planDefaultRoute).toBe('/plan/inbox')
expect(ui.workDefaultRoute).toBe('/work/sprint')
expect(ui.planOutlineKeys).toEqual(['profile', 'inbox', 'sprint', 'gates'])
expect(ui.planOutlineKeys).toEqual(['profile', 'inbox', 'work', 'sprint', 'gates'])
expect(resolveWorkNavItems({ archetypeKey: 'initiative.product' }).map((i) => i.key)).toEqual([
'sprint',
'today',
@ -41,6 +41,12 @@ describe('methodUiDefaults', () => {
])
})
it('product plan outline includes work for direct AP path', () => {
expect(
resolvePlanOutlineNodes({ archetypeKey: 'initiative.product' }).map((n) => n.key),
).toEqual(['profile', 'inbox', 'work', 'sprint', 'gates'])
})
it('linear archetype defaults to gates and filters plan outline', () => {
const ui = resolveMethodUiDefaults({ archetypeKey: 'initiative.linear_project' })
expect(ui.planDefaultRoute).toBe('/plan/gates')

View File

@ -13,6 +13,7 @@ function PlanWorkInner() {
const { initiativeId, projectId: scopeProjectId, hrefWithScope } = useProgramScope()
const [executionGraph, setExecutionGraph] = useState(null)
const {
initiative,
actions,
projects,
roadmapItems,
@ -52,6 +53,11 @@ function PlanWorkInner() {
return <LoadingState message="Lade Arbeitspakete …" />
}
const isProduct = initiative?.archetype_key === 'initiative.product'
const sectionLead = isProduct
? 'Arbeitspakete direkt anlegen (Pfad B) oder committetes Ist — ohne Eingang-Umweg. Sprint-fokussiert unter Ausführen → Sprint.'
: 'Gesamt-Ist am Vorhaben — Sprint-fokussierte Arbeit unter Ausführen → Sprint.'
return (
<>
{error && <p className="error">{error}</p>}
@ -76,7 +82,7 @@ function PlanWorkInner() {
busy={formBusy}
executionGraph={executionGraph}
sectionTitle="Alle Arbeitspakete"
sectionLead="Gesamt-Ist am Vorhaben — Sprint-fokussierte Arbeit unter Ausführen → Sprint."
sectionLead={sectionLead}
/>
</>
)

View File

@ -145,8 +145,10 @@ export function resolveOperatingProfileFromInput(input = {}) {
export function resolvePlanOutlineNodesFromProfile(input = {}) {
const { planOutlineKeys } = resolveOperatingProfileFromInput(input)
if (!planOutlineKeys) return PLAN_OUTLINE_NODES
const allowed = new Set(planOutlineKeys)
return PLAN_OUTLINE_NODES.filter((node) => allowed.has(node.key))
const order = new Map(planOutlineKeys.map((key, index) => [key, index]))
return PLAN_OUTLINE_NODES.filter((node) => order.has(node.key)).sort(
(a, b) => (order.get(a.key) ?? 0) - (order.get(b.key) ?? 0),
)
}
/**

View File

@ -21,7 +21,7 @@ const PRODUCT_CONTEXT = {
workDefaultRoute: '/work/sprint',
workDefaultRouteWithoutActiveWorkCycle: '/work/today',
controlDefaultRoute: '/control/status',
planOutlineKeys: ['profile', 'inbox', 'sprint', 'gates'],
planOutlineKeys: ['profile', 'inbox', 'work', 'sprint', 'gates'],
workNavKeys: ['sprint', 'today', 'mine'],
},
data_slices: ['backlog', 'actions', 'roadmap', 'work_cycles', 'projects'],