A dev's i_will_work_on stored a flat {text} plan and routed steps to
progress, so the dev leaf's Plan tab rendered empty (no approach,
sub_tasks, technical_considerations, risks) — zero audit/tracing on the
task that does the actual work.
i_will_work_on now captures the same rich plan a PM authors via
i_will_plan: plan(>=150) doubles as approach, steps become sub_tasks,
plus technical_considerations + risks (open_questions optional). A new
_dev_plan_gate enforces them on FRESH claims only (re-entry/recovery
short-circuit before it). set_plan gains a no-downgrade guard so a
flaked-then-recovered dev can't clobber its rich plan back to flat (the
actual mechanism behind the empty leaf).
The dev plan was a free string with only a presence gate, so the
executing dev had no checklist for plan-driven progress (#173).
- IWillWorkOnRequest gains `steps` (same SubTask shape as a PM's
sub_tasks); flow_dev route threads it through.
- i_will_work_on layers steps onto the narrative plan via the same
panel-shaped path PMs use, so task.plan.sub_tasks is populated
(panel render + #173 progress).
- New _dev_steps_gate (mirrors _pm_sub_tasks_gate, runs after the spec
gate): a developer FRESH claim must supply a non-empty steps list
with every description >= _PM_SUBTASK_DESC_MIN_LEN. Re-entry/recovery
short-circuit before the gate (extracted _dev_reentry +
_fresh_dev_claim keep i_will_work_on within the
return-count + cyclomatic gates).
- developer role prompt: steps template + "thin steps rejected" + the
progress(plan_step=...) handoff.
- Updated every dev-fresh-claim test fixture across the suite to pass
substantive steps; added dedicated _dev_steps_gate coverage.
Commit 2 of 3 for the plan/progress quality work (#171/#172/#173).
Renn F