Kairo-Jinkendo/docs/architecture/ADP_A1_Progression_Graph_Derived_Lanes_v0.1.md
Lars 17add13d9d
All checks were successful
Deploy Development / deploy (push) Successful in 53s
Test Suite / pytest-backend (push) Successful in 4m52s
Test Suite / lint-backend (push) Successful in 3s
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 31s
refactor(A1): Progression-Lanes aus Graph statt Strang=Project
Ersetzt strand_project_id/Stream-Projects in der A1-Steuerung durch graph-abgeleitete Lanes (requires-Ketten + Join). Recurring bindet nur noch am Gate; Re-Abnahme-Docs und ADP dokumentieren die Korrektur.

Co-authored-by: Cursor <cursoragent@cursor.com>
2026-08-03 18:51:17 +02:00

3.2 KiB

ADP — A1 Progression: Graph-abgeleitete Lanes statt Strang=Project

Status: PO/Architektur-Korrektur (2026-07-28)
Stand: 2026-07-28
Auslöser: AP2.1 — Strang=Project und strand_project_id vermischen Dimension A (Zielzustands-Graph) mit Dimension B (Project-Struktur)
Bezug: ADP_Execution_Plan_and_Work_Package_Dependencies_v0.1.md, SPEC_A1_Progression_Model_PO_Lock_v0.1.md, SPEC_D_maturity_progression_v0.1.md


Entscheidung

A1 Multi-Gate-Progression braucht kein Project pro parallelem Pfad.

Thema Lock
Ziel-Horizont (A) Gates + requires-Graph + Join — modelliert Zielzustände, nicht Pfade
Ist / Übungen RecurringElement.roadmap_item_id → aktives Gate — eine Bindung
Parallele aktive Gates Erlaubt; Horizon-Regel „max. 1 aktiv pro Lane“ aus Graph-Topologie ableiten
Lane Interner, nicht persistierter Schlüssel (compute_progression_lanes) — kein Nutzerobjekt
Project Nicht Träger paralleler Progression in A1; optional nur für echte Struktur-Hierarchie (ADP Dimension B)
strand_project_id Deprecated für Steuerlogik; Spalte bleibt nullable (Migration 032), wird nicht mehr gelesen
recurring.project_id für A1 Nicht setzen / nicht auswerten für Ready-Menge

Begründung

  1. ADP-Leitentscheidung: Gate-Designer = Zielzustände; Pfad-/Container-Semantik gehört nicht in dieselbe Pflichtmodellierung.
  2. Nutzerbild: Mehrere aktive Gates, Routinen am Gate, Join wertet Kanten aus — kein Pfad-Navigator nötig.
  3. Archetyp-Isolation: Project=Strang hätte andere Archetypen (A2, B1) semantisch verunreinigt.
  4. Kein Doppelmodell: Kanten im Designer genügen; kein Strang-Dropdown, keine Stream-Projects für A1-Kernbild.

Lane-Algorithmus (MVP)

Aus requires-Kanten zwischen Work-Gates und Joins:

  • Sequenzielle Work-Gates teilen eine Lane (Vorgänger-Kette).
  • Parallele Quellen (kein Work-Gate-Vorgänger) → getrennte Lanes.
  • Erstes Gate nach Join (requires Join) → neue Lane (post-join:{gate_id}).

Horizon: Beim Aktivieren eines Gates werden andere active/at_risk Gates derselben Lane auf planned gesetzt.


Implementierung

Modul Änderung
backend/services/progression_graph.py compute_progression_lanes, enforce_single_active_work_gate_per_lane
backend/services/maturity_practice.py Pause/Seed nur über roadmap_item_id + Lane
backend/services/archetype_starter_kit.py Demo ohne Stream-Projects / strand_project_id
frontend/.../WorkTodayPracticePanel.jsx Gruppierung nach Gate-Titel

Steuerung bleibt in maturity_progression — nicht im generischen roadmap_engine.


Spec-Nachzug

SPEC_A1_Progression_Model_PO_Lock_v0.1.md §1/§4: „Strang = Project“ → ersetzt durch „parallele Lanes = graph-abgeleitete Requires-Ketten“. Project-Spiegel project.maturity_journey optional für Struktur-IA, nicht für Horizon.


Nicht in Scope

  • Spalten-Drop in Migration ( später, wenn keine Legacy-Daten )
  • Join If/Else (Stufe B)
  • Blueprint / Starter-Kit als Produktweg