Run #2 ended with two open problems: an approval nobody could click, and a step that silently ran against a fake provider instead of a real one. Both of those got fixed before this run started — real fixes, merged and deployed with time to spare. Run #3 never got far enough to test either of them.
The task
"Improve BinChicken's public demo experience. Make it immediately clear what BinChicken does and guide a new visitor through the simulated SDLC workflow from starting a task through agent handoffs, approvals, and completion. Use the existing demo architecture. Identify and fix UX issues you find, add appropriate tests, and prepare the changes for review. Do not redesign the architecture or add unrelated features."
What happened
scope picked up the task and made a real call to Anthropic. That call ran for just over four minutes and came
back with something that parsed as valid JSON this time — and still failed, because the parsed object didn't
match the shape every role's response is required to have. Same failure category as run #1's bug
(invalid_model_output), a different specific cause: not malformed JSON this time, a malformed result. The
provider-output-robustness gap flagged in the first two posts is still real, and now confirmed to have more than
one way of showing up.
That part is disappointing but unsurprising. What happened next is the part worth a whole post on its own.
The run said "running" for ten minutes after it wasn't
The failed call finished at 22:54:34. The run's own status stayed "running" — not stalled-looking, not showing an error, just quietly still saying "running" — until we went and checked the underlying records directly and found the execution had already concluded and failed nearly ten minutes earlier. The step that should have recorded that failure never got the chance to: something between the model call failing and BinChicken writing that outcome down didn't complete. Server logs show exactly one request to advance this run, and it returned a conflict response almost immediately — before the four-minute call even started — which doesn't line up cleanly with anything else we can see. We don't have a clean explanation for that gap, and we're not going to invent one to make this post read more resolved than it is.
What we do know for certain: once that happened, nothing was ever going to move this run forward again on its own. The page driving progress only retries automatically while requests keep succeeding; the moment one doesn't, it just stops, silently, and "running" is the last thing anyone sees — indistinguishable from a slow real model call actually in progress.
And there was nothing to do about it
No button anywhere would have told us this had already failed. No button would have let us cancel it, retry it, or otherwise move on. The only way to end it was the same thing we did for run #2: reach directly into the database and mark it failed by hand.
This is worth stating plainly rather than filing away: "running" is not currently a status that means anything by itself. It's the same word whether a real four-minute model call is genuinely in flight or a run died silently ten minutes ago. And there is currently no way, from BinChicken's own interface, for a human to say "stop this" — for a run that's genuinely stuck, or one that's simply no longer wanted. Both of those are real product gaps, not aesthetic ones, and neither is fixed by this post. They're being written down so they don't quietly stay invisible next to the more code-shaped bugs that are easier to point at.
Where this leaves things
Three runs in, the honest tally: two real infrastructure defects found and fixed (approval persistence, silent mock fallback), one real robustness gap identified but still open (structured-output parsing, now confirmed to have at least two distinct failure shapes), and two real product gaps newly surfaced by this run specifically — status opacity and the absence of a cancel control. None of the last three are being fixed today. They're on the list, in the open, the same way everything else in this log has been.