* fix(board): LEARN decisions name the item, not its per-cycle index
A cycle's reject reasons are rendered into the NEXT cycle's exploration
prompt, but the ref recorded alongside each reason was the item's stored
id (item-0/item-1) — a per-cycle index that means something different
every cycle and appears nowhere the explorer can resolve. The reason
survived the loop; what it was about did not.
Record the item's title instead, via a shared learn_ref() helper (falls
back to the id when title-less, and reads target_task_title for Scales,
whose items name the live task they mutate).
* chore(lint): satisfy ruff 0.16 — keyword-only signatures and markdown formatting
The dev toolchain resolved ruff 0.16.0, which stabilises PLR0917 (too many
positional arguments) and formats python code blocks inside markdown. Both
fired repo-wide and neither had anything to do with the code they flagged.
- 36 signatures gain a `*` so their tail arguments are keyword-only, and
the 104 call sites that passed them positionally are converted. mypy was
the safety net for the static ones; the full suite caught nine more that
only bind at runtime (the MCP tool functions, whose real callers already
pass named JSON arguments).
- 28 markdown files reformatted by 0.16's code-block formatter.
- One RUF036 (`None` mid-union) autofixed in the GitLab provider.
* fix(gateway): log the reason when a verb rejects
A rejected envelope rides an HTTP 200, its body is never logged, and there
is no trace table — so in the access log a verb an agent could not satisfy
looks identical to one that worked. On 2026-07-25 four Board Programs
(Periscope, Sentinel, Scales, Barfly) each POSTed their propose verb three
or four times, persisted nothing, and left their exploration tasks PENDING;
the reason was unrecoverable afterwards, from the logs or from the agents'
own transcripts.
Log error/message/remediate/missing plus the calling agent at
envelope_to_response — the one chokepoint every v1 flow and do route
returns through. Success envelopes stay silent.
---------
Co-authored-by: Renn F <rennf93@users.noreply.github.com>
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).
