A person's Retry of a capped transcription row drops the "write as soon as you can read" cure #156

New issue

Open

opened 2026-09-26 14:26:11 +02:00 by scarlet · 0 comments

scarlet commented

2026-09-26 14:26:11 +02:00

Member

This is a follow-up to #154, raised in Jibril's 💡1 (comment 9995). It was disclosed as a known gap in that PR.

The gap

WithDistrust works out whether an earlier attempt broke off from attempt > 1 alone.
A person's Retry on a Failed row goes through Execution.Requeue, which resets Attempt to 0.
So the retried transcription runs at attempt 1. A region named in the row's ledger is often one that ran out of rounds before it wrote anything. It hears no broken-off voice and misses the cure, "write your reading with set_transcription as soon as you can read it".
If the row also carries feedback, the region hears the send-back voice, which correctly doesn't carry the cure either.

Why it isn't a bug today: step 3 of the transcription brief teaches the same rule, "As soon as you can READ the text … write it". Losing the kickoff line is drift risk, not wrong behaviour.

Shape of a fix: give the executor a fact, not a guess. For example, StageContext could say whether the previous attempt failed, or carry its error. Then the broken-off voice can fire on a row a person requeued. That touches IStageExecutor/RunEngine, which is why #154 left it alone.

When: take this with the tier-2 transcription work from the same triage, which would also end round-cap failures where the answer was already written:

the round budget stated in the kickoff, plus a last-round notice;
a region settled by its terminal write.

That batch waits on an A/B of the capped pages against the roster's default model; every debrief came from a deepseek-v4.1-flash override.

🤖 Generated with Claude Code

This is a follow-up to #154, raised in Jibril's 💡1 (comment 9995). It was disclosed as a known gap in that PR. **The gap** - `WithDistrust` works out whether an earlier attempt broke off from `attempt > 1` alone. - A person's Retry on a Failed row goes through `Execution.Requeue`, which resets `Attempt` to 0. - So the retried transcription runs at attempt 1. A region named in the row's ledger is often one that ran out of rounds before it wrote anything. It hears no broken-off voice and misses the cure, "write your reading with set_transcription as soon as you can read it". - If the row also carries feedback, the region hears the send-back voice, which correctly doesn't carry the cure either. **Why it isn't a bug today:** step 3 of the transcription brief teaches the same rule, "As soon as you can READ the text … write it". Losing the kickoff line is drift risk, not wrong behaviour. **Shape of a fix:** give the executor a fact, not a guess. For example, `StageContext` could say whether the previous attempt failed, or carry its error. Then the broken-off voice can fire on a row a person requeued. That touches `IStageExecutor`/`RunEngine`, which is why #154 left it alone. **When:** take this with the tier-2 transcription work from the same triage, which would also end round-cap failures where the answer was already written: - the round budget stated in the kickoff, plus a last-round notice; - a region settled by its terminal write. That batch waits on an A/B of the capped pages against the roster's default model; every debrief came from a deepseek-v4.1-flash override. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

scarlet referenced this issue

2026-09-26 14:26:20 +02:00

fix: the transcriber writes what it reads, and a retry is told why it is back (2/2) #154

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

TeamAI/Orihon#156

No description provided.

Rows
Columns