feat(loop): the loop decides its own steps — one model call per step

[linhdmn]

The missing piece

The loop could not find anything, and the reason was concrete rather than vague:

• planner.Plan() emitted "Execute the next action for: <goal>" and the runner read only the step's tier from it — a plan's words never reached a tool.
• The tool picker was tools[step%4] with {step, goal}.
• onegw was called on exit paths only — never mid-loop.

It acted, but never observed → reasoned. That is the whole loop.

internal/loop/reason.go

One model call per step. The model is handed the goal, the context, the plan step if there is one, and the verbatim result of the previous step — the thing a rotation cannot use — and answers:

{"tool":"query","args":{"query":"parseConfig"},"why":"locate the symbol","done":false}

The tool contract in its system prompt is the registry's own descriptions, DO NOT USE WHEN clauses included. A name that is not in the registry is refused before the gate sees it — otherwise the gate fails closed and holds a step nobody can approve.

Answer parsing tolerates what models actually send: bare JSON, fenced JSON, and JSON prologued with a sentence. The extractor is brace-aware, so {"content":"f(x) { return 1; }"} does not truncate at the first }.

Three deliberate properties

Property	Why
a failed decision is not fatal	the run falls back to the rotation and records the reason in reason_errors and on the step's why. A silent fallback is how a run looks fine while the model is unreachable — the same class as this repo's other "green check that cannot fail" bugs
done is the goal predicate, not a bound	exits success with a new exit_reason=goal_met instead of spinning to max_steps (move 2: separate success from stopping). The one exit a model can reach on its own
a resume replays the approved decision	re-asking lets the model return a different tool, so the operator would have approved one action and a different one would run. Cost is the smaller reason

StepRecord gained Args and Why: a trace carrying only an args hash cannot answer "what did it actually try?": the first question anyone asks of a surprising step, and what a replay needs.

The production constructor was itself the bug

NewRunnerWithPlannerAndGate passed nextToolDefault as the picker — so in production the rotation always won and the reasoner was unreachable. Caught by the end-to-end test through the HTTP API (which is why that test exists): the step read why: "picker: injected" while a gateway sat idle.

Verified live, against a stub gateway

goal: "fix the off-by-one in parseConfig"

step 0  query    args={"query":"parseConfig"}   why="locate the symbol before guessing"
step 1  (none)   why="the fix is written and the tests are the verification step"
state: success   exit: goal_met   usage: 5 model calls, 210 tokens

The tool, its arguments, and the rationale are all the model's.

What is still not model-driven

The planner. The chooser carries the run; the plan is a hint — phases and instructions still come from planStepCount(goal word count). Stated in USAGE §9 rather than implied.

Tests

10 new in internal/loop — choice honoured, prompt carries the last result, fenced/prologued parsing, invented tool refused, transport failure falls back and records, no-model is byte-identical, system-prompt contract, usage counted, args recorded, resume replays — plus one end-to-end through the HTTP API in cmd/agentloop.

make check green: gofmt, vet, 14/14 packages, lint 0 issues, PRD OK, selftest 12/12.

CI shows red on this PR — the org's Actions billing limit is still unraised (#31's caveat, recorded in USAGE §2). make check runs the identical five steps.