Implementation sessions lack workitem.write, so a finished WI cannot advance its own phase and is re-dispatched forever — six sessions burned re-verifying one completed fix #500

Merged

toasterson merged 2 commits from claude/wi-019fcce5-implementation-sessions-lack-workitem-wr into main

2026-08-06 16:34:46 +00:00

toasterson commented

2026-08-05 03:15:06 +00:00

Owner

Anima work item 019fcce5-432c-7c11-8b07-549b655bde31.

What happened

akh-medu WI-274 (019fba6a-dba7-7d01-bd43-fc51a62587b9) was fully implemented and CI-green.
Its sixth session posted this:

"The WI was already fully implemented across prior commits (ca25b4e select! on
done_rx, 8d59fb8 Weak sink in tracker, 0b7125e oneshot result capture). I
re-verified: 63/63 ACP tests pass, CI green at head 0b7125e on PR #283. Both halves
of the required fix are landed and verified against all four acceptance criteria.

I cannot advance the phase myself — this session token lacks workitem.write scope
(same blocker as the five prior sessions on this WI). I posted the verification summary
to the thread; a PAT-authorized caller needs to advance current_phase to testing and
call approve_and_merge."

So: the work finished, the session could not record that it finished, the WI stayed in
working, and the scheduler re-dispatched it. Six times. Each session re-cloned,
re-read, re-verified and re-pushed the same completed change — five full model-token turns
spent producing nothing new, plus five CI runs on an already-green head.

An operator (me) merged it by hand; without that it would still be looping.

Why it is invisible

Nothing distinguishes this from a WI legitimately still in progress. current_phase stays
working, sessions keep completing, PRs keep updating. The only trace is the agent saying
so in prose in the thread — which no dispatch logic reads. From metrics, six productive
sessions.

Required

Give implementation sessions the scope to close their own work, or provide a narrow
session-scoped verb that does it (mark_implementation_complete bound to the session's
own WI) rather than broad workitem.write. The narrow verb is preferable: a session
should be able to advance its own item and nothing else.
Detect the loop. If N consecutive sessions on one WI end with no new commits on the
branch head, stop dispatching and park with a reason that names it. Re-running an
identical turn is never the answer.
Surface scope failures as a session outcome, not prose. A session that ends because
it could not call a required tool must terminate with a distinct state naming the missing
scope — not completed. Compare 019fc9a5-1ff7 (failed push also reported as
completed): the same class of silent-failure-looks-like-success.
Audit which scopes implementation sessions actually get versus which the workflow
requires end-to-end. If closing the loop needs workitem.write and sessions never have
it, no WI can ever self-complete — meaning every completed WI to date was closed by a
human or left looping.

Acceptance

A session that finishes its work can advance its own WI without operator intervention.
Repeated no-new-commit sessions on one WI stop and park with a naming reason.
A session blocked on a missing scope ends in a state that says so, visible from
get_wi_loop_state.

Cost of the current behaviour

Six sessions on one WI, at least five of them pure waste, on a lane that is already the
throughput bottleneck — plus the CI runs. This is likely not confined to WI-274; any WI
whose final session cannot self-advance will show the same pattern.

Anima work item `019fcce5-432c-7c11-8b07-549b655bde31`. ## What happened akh-medu WI-274 (`019fba6a-dba7-7d01-bd43-fc51a62587b9`) was fully implemented and CI-green. Its sixth session posted this: > "The WI was already fully implemented across prior commits (`ca25b4e` select! on > `done_rx`, `8d59fb8` Weak sink in tracker, `0b7125e` oneshot result capture). I > re-verified: **63/63 ACP tests pass**, CI green at head `0b7125e` on PR #283. Both halves > of the required fix are landed and verified against all four acceptance criteria. > > **I cannot advance the phase myself — this session token lacks `workitem.write` scope > (same blocker as the five prior sessions on this WI).** I posted the verification summary > to the thread; a PAT-authorized caller needs to advance `current_phase` to `testing` and > call `approve_and_merge`." So: the work finished, the session could not record that it finished, the WI stayed in `working`, and the scheduler re-dispatched it. **Six times.** Each session re-cloned, re-read, re-verified and re-pushed the same completed change — five full model-token turns spent producing nothing new, plus five CI runs on an already-green head. An operator (me) merged it by hand; without that it would still be looping. ## Why it is invisible Nothing distinguishes this from a WI legitimately still in progress. `current_phase` stays `working`, sessions keep completing, PRs keep updating. The only trace is the agent saying so in prose in the thread — which no dispatch logic reads. From metrics, six productive sessions. ## Required 1. **Give implementation sessions the scope to close their own work**, or provide a narrow session-scoped verb that does it (`mark_implementation_complete` bound to the session's own WI) rather than broad `workitem.write`. The narrow verb is preferable: a session should be able to advance *its own* item and nothing else. 2. **Detect the loop.** If N consecutive sessions on one WI end with no new commits on the branch head, stop dispatching and park with a reason that names it. Re-running an identical turn is never the answer. 3. **Surface scope failures as a session outcome, not prose.** A session that ends because it could not call a required tool must terminate with a distinct state naming the missing scope — not `completed`. Compare `019fc9a5-1ff7` (failed push also reported as `completed`): the same class of silent-failure-looks-like-success. 4. **Audit which scopes implementation sessions actually get** versus which the workflow requires end-to-end. If closing the loop needs `workitem.write` and sessions never have it, no WI can ever self-complete — meaning every completed WI to date was closed by a human or left looping. ## Acceptance - A session that finishes its work can advance its own WI without operator intervention. - Repeated no-new-commit sessions on one WI stop and park with a naming reason. - A session blocked on a missing scope ends in a state that says so, visible from `get_wi_loop_state`. ## Cost of the current behaviour Six sessions on one WI, at least five of them pure waste, on a lane that is already the throughput bottleneck — plus the CI runs. This is likely not confined to WI-274; any WI whose final session cannot self-advance will show the same pattern.

toasterson added 1 commit

2026-08-05 03:15:06 +00:00

Implementation sessions lack workitem.write, so a finished WI cannot advance its own phase and is re-dispatched forever — six sessions burned re-verifying one completed fix 099c8dbc64

Anima implementation session.

toasterson force-pushed claude/wi-019fcce5-implementation-sessions-lack-workitem-wr from 099c8dbc64 to 36fa2b5162

2026-08-05 20:51:57 +00:00

Compare

toasterson added 1 commit

2026-08-05 23:11:05 +00:00

Implementation sessions lack workitem.write, so a finished WI cannot advance its own phase and is re-dispatched forever — six sessions burned re-verifying one completed fix 1d40354a4e

Anima implementation session.

toasterson changed title from ~~WIP: Implementation sessions lack workitem.write, so a finished WI cannot advance its own phase and is re-dispatched forever — six sessions burned re-verifying one completed fix~~ to Implementation sessions lack workitem.write, so a finished WI cannot advance its own phase and is re-dispatched forever — six sessions burned re-verifying one completed fix

2026-08-05 23:51:01 +00:00

toasterson merged commit 601ff051e9 into main

2026-08-06 16:34:46 +00:00

toasterson referenced this pull request from a commit

2026-08-06 16:34:47 +00:00

Merge pull request 'Implementation sessions lack workitem.write, so a finished WI cannot advance its own phase and is re-dispatched forever — six sessions burned re-verifying one completed fix' (#500) from claude/wi-019fcce5-implementation-sessions-lack-workitem-wr into main

toasterson referenced this pull request

2026-08-06 16:45:40 +00:00

MCP surface wedges permanently while gRPC stays healthy — suspected unbounded outbound Forgejo call under MCP handler serialization (resync_pr_state) #504

toasterson referenced this pull request

2026-08-08 12:43:55 +00:00

A fully-cleared exit bar does not advance the work item: the scheduler keeps re-dispatching implementation sessions until the item parks #523