[Planning]: Force epic candidate-lane promotion before broad implementation

[rickardvh]

Issue kind

Dogfooding follow-up / planning guardrail

Problem / intent

During the command-generation extraction work, AW ingested eight open GitHub candidates (#1201-#1208) and exposed them in roadmap.candidates, but the workflow still allowed me to continue direct implementation before a parent decomposition and lane execplans existed. The user caught the missing planning structure after code work had already landed in PR #1210.

For an epic-shaped request with multiple candidate lanes, AW should make the promotion obligation harder to miss before implementation proceeds.

Observed behavior

• roadmap.candidates contained eight related command-generation extraction items.
• The active state initially had no execplan/decomposition for the epic.
• The workflow allowed narrow direct fixes on the PR without forcing or prominently requiring candidate-lane promotion.
• The missing decomposition/execplans had to be added after user correction.

Expected behavior

When task text or ingested evidence points at a broad multi-issue epic, AW should require one of these before implementation closeout:

• a parent decomposition with candidate lanes;
• promoted execplans for selected lanes; or
• an explicit, recorded reason why the current change is a bounded slice and does not close the parent epic.

Acceptance / success signal

• start / implement surfaces show a blocking or high-prominence warning when multiple related roadmap candidates exist and no matching decomposition/execplan owns the requested task.
• The warning points to the concrete candidate ids and a promotion command or decomposition route.
• Direct implementation remains possible for a truly bounded slice, but closeout cannot imply full epic satisfaction without parent-lane planning proof.

Dogfooding source

Command-generation extraction PR #1210 and issues #1201-#1208.

[rickardvh]

Session review addendum: 019e6eaa-44a8-7b53-a06f-94568538817b

I reviewed the transcript and current routing code. The failure was broader than roadmap candidates not being promoted.

Observed sequence:

• uv run agentic-workspace start --task "Implement #1189" --format json returned choose-smallest-workflow-shape, implementation_allowed: true, no active planning, and no concrete requested outcomes.
• The start surface did not resolve the issue body for [Workspace]: Complete generated TypeScript CLI with no Python runtime dependency #1189. The issue body said completion required a fully Python-free generated TypeScript CLI and explicitly allowed partial slices only as non-closing progress.
• The agent then fetched the issue, recognized it was broad, but self-selected a small slice anyway. That is an agent judgment failure, but AW gave no strong stop signal or issue-intent guardrail.
• Current routing still has prompt/path heuristic work-shape logic: a single issue ref plus task text tends to bounded/direct unless the text literally says epic, has multiple issue refs, active planning exists, or changed paths look broad. Roadmap/decomposition candidates are exposed, but candidate count alone is not a hard/high-prominence precondition.

This is adjacent to #1211: task and issue scope should be learned from confirmed evidence, such as fetched external issue intent, Planning, Memory, or explicit user scope. Prompt keywords and issue-ref counts can propose discovery, but should not authorize bounded/direct classification for an unresolved issue reference.

Additional acceptance pressure for this issue:

• For issue-ref tasks like Implement #1189, AW should either fetch/use cached external intent evidence before classifying work shape or mark issue acceptance/scope as unknown and high-risk before edits.
• If external issue evidence contains full-intent/closure-limit markers such as partial_pr_may_close: no, AW should surface a closeout blocker: direct slices may proceed only with explicit "bounded progress, does not close parent" evidence or active planning ownership.
• Multi-candidate roadmap evidence should not remain merely informational when the user request claims parent/lane progress; it should require decomposition/execplan promotion or an explicit recorded bounded-slice exception.