feat(planner): v1 regelbasiert — dependsOn-DAG-Ordering #483

New issue

Closed

opened 2026-06-16 06:49:14 +02:00 by pm-bot · 0 comments

pm-bot commented

2026-06-16 06:49:14 +02:00

Collaborator

Sub-Issue von #360 (Phase 7).

Problem

Der aktuelle slot-plan (v0) ignoriert das dependsOn[]-Feld der Candidates. Wenn Candidate B von A abhängt, kann B vor A einplant werden — fachlich falsch (z.B. „Postpaket abholen' braucht „Paket-Benachrichtigung gelesen' vorher).

Akzeptanzkriterien

Candidates mit dependsOn[c.id] werden nach ihrer Dependency eingeplant (innerhalb des Tages).
Transitive Deps (c→b→a) → Reihenfolge a, b, c.
Wenn ein Dep overflow wird, ist der Dependent ebenfalls overflow.
Wenn ein Dep nicht im pending-Pool ist (z.B. bereits done), wird er als „erledigt' behandelt — Dependent kann sofort starten.
Zyklen (a→b→a) → alle Beteiligten gehen in overflow (kein Crash, kein Deadlock).
Tests in slot-plan.spec.ts für alle 5 Fälle (red-green-refactor).

Out-of-Scope (für v1)

Habit-Context: braucht erst Habit-Source (Phase 4 von #360). Folge-Issue.
plannedAfter/Before: sind Planner-OUTPUTS, kein Input-Constraint.
Transit-Time zwischen Buckets: spätere Optimierung.
Time-of-Day Affinity: spätere Optimierung.

Release

rc26.

Bezug

Epic: #360
Schema-Feld: candidates.depends_on uuid[] NOT NULL DEFAULT '{}' (existiert seit Phase-1-Spike)

Sub-Issue von #360 (Phase 7). ## Problem Der aktuelle `slot-plan` (v0) ignoriert das `dependsOn[]`-Feld der Candidates. Wenn Candidate B von A abhängt, kann B vor A einplant werden — fachlich falsch (z.B. „Postpaket abholen' braucht „Paket-Benachrichtigung gelesen' vorher). ## Akzeptanzkriterien - [ ] Candidates mit `dependsOn[c.id]` werden **nach** ihrer Dependency eingeplant (innerhalb des Tages). - [ ] Transitive Deps (c→b→a) → Reihenfolge a, b, c. - [ ] Wenn ein Dep **overflow** wird, ist der Dependent ebenfalls overflow. - [ ] Wenn ein Dep nicht im pending-Pool ist (z.B. bereits `done`), wird er als „erledigt' behandelt — Dependent kann sofort starten. - [ ] Zyklen (a→b→a) → alle Beteiligten gehen in `overflow` (kein Crash, kein Deadlock). - [ ] Tests in `slot-plan.spec.ts` für alle 5 Fälle (red-green-refactor). ## Out-of-Scope (für v1) - **Habit-Context**: braucht erst Habit-Source (Phase 4 von #360). Folge-Issue. - **plannedAfter/Before**: sind Planner-OUTPUTS, kein Input-Constraint. - **Transit-Time zwischen Buckets**: spätere Optimierung. - **Time-of-Day Affinity**: spätere Optimierung. ## Release rc26. ## Bezug - Epic: #360 - Schema-Feld: `candidates.depends_on uuid[] NOT NULL DEFAULT '{}'` (existiert seit Phase-1-Spike)