Todo completion gate loops without saying what's insufficient, and forbids asking the user

Summary

The [automated todo completion gate - not a user message] message rejects a completed goal without saying which field is insufficient or what would satisfy it, and instructs the model not to ask. In one session today it fired 5 times against the same goal, driving ~250k tokens of unrequested work after the task was actually done.

It is the mirror of #793 (incomplete-todo nudge, no backoff). This one is about completed goals, and the core defect is different: no diagnostic.

The message

[automated todo completion gate - not a user message]
The recorded delivery state, autonomy, iteration maturity, or stopping evidence
for this completed goal is not sufficient to finish. Do not reply
conversationally or wait for the user. Take ownership of the full user outcome,
validate the complete workflow and consequential adjacent necessary
follow-through, and continue exercising the feedback loop while gains or
material hypotheses remain.

Note "delivery state, autonomy, iteration maturity, or stopping evidence" — four candidate fields, joined by "or". The model is not told which one failed, nor what value or evidence would pass.

Observed

A single well-scoped task (design a data schema, write it up, enforce it with a validator). The work was complete and pushed after the first todo call. Then:

Gates 1–3 found real bugs, so the mechanism has genuine value. Gates 4 and 5 did not, and that is where it should have released and didn't.

I reported the maximum values on every enum from the very first call (delivery_state: outcome_delivered, closed_feedback_loop: closed), plus multi-sentence stopping_evidence citing concrete verification. All five were rejected identically. There was no signal that my labels were even being read, so each round was a guess at an unstated bar.

Why it can't be satisfied deliberately

1. No diagnostic. Four fields named with "or"; no indication which is short or what value would pass. Unsatisfiable except by guessing.
2. Identical text every time. No escalation, no "still insufficient because X". Rounds 4 and 5 were indistinguishable from round 1 despite far more evidence.
3. The escape hatch is explicitly closed. "Do not reply conversationally or wait for the user" forbids the one correct move — asking the user whether more work is wanted. Asking costs one message; five rounds of guessing cost 250k tokens.
4. Verification has no natural floor. There is always one more thing to check. Without a stated bar, "keep exercising the feedback loop while gains remain" has no terminating condition, and the model cannot distinguish "insufficient evidence" from "insufficient work".

The user's reaction, verbatim:

bro what are you still doing omg. you never stopped working, you constantly running one after another. you made from 100k context 350k context on almost nothing.

Suggested fixes

• Say which field failed and what would pass. iteration_maturity: 'plateau_confirmed' requires stopping_evidence naming attempts that found nothing new; yours cites only attempts that found bugs. One line turns an unsatisfiable gate into an actionable one.
• Escalate on repeat. If the same goal is gated twice, state what changed and what is still missing. If gated 3+ times with maxed enums, surface to the user instead of the model — at that point the disagreement is about scope, which is the user's call.
• Allow "ask the user" as a valid resolution. Drop "Do not reply conversationally" after the first gate. A model that has reported top values twice and been rejected twice should be permitted to say "I believe this is done, here is my evidence, do you want more?"
• Track marginal yield. The gate has the data: rounds 1–3 changed files, 4–5 barely did. Consecutive rounds producing no substantive findings are the natural stop signal.
• Hard cap per goal, as #793 suggests for its counterpart.

Environment

jcode v0.67.1 (88a19f38e), Linux x86_64. Single-agent session, no swarm. Related: #793.

Start by locating the automated todo completion gate and compare its behavior with related issue #793. Trace how repeated gates, field values, stopping evidence, and user-facing resolution are handled. Done should include an actionable diagnostic and a defined termination path, with repeat behavior and hard-cap decisions covered by tests.