The first real run ended with a real Anthropic call that succeeded and a response that couldn't be parsed. This one was aimed straight at that bug — and turned up two more things worth being just as honest about.
The task
Same repository, same real GitHub connection, same real BYOK Anthropic credential as run #1. This time the request was self-directed:
"Fix Maiden Run #001's
invalid_model_outputfailure. Inspect Anthropic SDK response/stop_reasonhandling and harden structured-output parsing against truncation, malformed JSON, fenced JSON and schema-invalid output. Record token usage on failures where available. Preserve the no-raw-output logging/storage boundary. Add regression tests for valid and invalid responses. Do not add automatic retries or change workflow architecture."
What happened
Four steps actually ran before this one stopped too, though not the way the first one did.
scope and architecture each made a real call to Anthropic — about a minute each, tens of thousands of real
input tokens against the repository, both parsed cleanly this time. security did the same a little later,
also clean. Three for three on the exact failure mode the last post was about — good evidence, though not proof,
that run #1's failure really was closer to a one-off than a pattern.
The ux step is the interesting one. It finished in about two seconds — far faster than any of the real calls —
and its result never showed up anywhere token usage or real-provider dispatch gets recorded. That's because
the UX Reviewer role's provider preference isn't Anthropic; it's a provider BinChicken doesn't have a real
adapter wired up for yet, and when that happens the step quietly runs against a simulated stand-in instead. It
still "succeeded," in the sense that the workflow got a validly-shaped response back and moved on — but nothing
about that step in the run's own UI would have told us it wasn't real. Three genuinely real steps and one
simulated one, sitting side by side, indistinguishable at a glance.
After security finished, the run correctly stopped and asked for a human decision — the same "waiting on
approval" state run #1 never got far enough to reach. This is exactly what's supposed to happen: a governed step
produced its artifact and BinChicken paused for a real sign-off before going further.
Except there was nowhere to give it. The approval request existed — a real, valid record of it was sitting in the database — but the run page had no control to act on it. Not a permissions problem, not something we missed: the record connecting "this step" to "the approval it's waiting on" never got written down. The gate was real. The step didn't know about it.
What we did about it
There's currently no way for BinChicken to cancel a run of its own — that's a gap, not a design decision we're defending. So this run was ended by hand, directly, outside the product, rather than left sitting in a state nothing could resolve or show accurately. Three real Anthropic calls happened first, real tokens were spent on the account's own key, nothing was written back to the repository, and the run's own record now honestly reflects that it was stopped rather than pretending it finished or silently vanishing.
Where this leaves things
Two real, separate problems came out of this run, and neither is fixed yet:
- A step can finish, generate a real approval request, and still leave the UI with no way to act on it — a sequencing bug in when that connection gets saved, not a missing feature.
- A step can run against a simulated response instead of a real model call, inside what otherwise looks like an all-real run, with nothing in the interface marking the difference.
Both are queued up. The next entry in this log will be about actually fixing one of them, one way or another — and it'll say plainly whether that fix worked the first time.