Run #3 closed with an honest tally: two real bugs fixed, one robustness gap still open, two new product gaps surfaced (status opacity, no cancel control). None of that got fixed before this run — what got built instead was the next real capability the roadmap called for: BinChicken actually writing to GitHub. This post covers both halves honestly — the substantial manual work that happened first, and what happened when we then tried to point BinChicken at a real task.
What we did manually, before this run
None of the following was done by BinChicken. This was direct engineering work against the codebase and the production environment — the same kind of work every prior phase in this project's history has been. Worth stating plainly rather than blurring the line: BinChicken did not build any of this. We did, by hand, so BinChicken could then be trusted to try something real.
- Connected BinChicken's Builder role — which already proposed structured, validated file changes — to real GitHub write access: a real branch, a real commit, a real comparison against the repository's actual history, and a real draft pull request, only ever created after that comparison is checked against what was originally approved.
- Ran a full pre-run readiness check against the actual deployed code and the live production environment, not assumptions. That check caught real gaps before they could cause a bad run: capability that had been built but wasn't live yet, and — separately — database changes that the application needed but hadn't actually been applied to production. Both got fixed and independently re-verified before anything real was attempted.
- Found and closed one more small gap the fixes above had themselves missed, plus added an automated check specifically so that class of gap can't quietly reappear unnoticed.
All of that happened before a single real run was attempted. It's not incidental context — it's most of what this entry is actually about.
The task
There wasn't a clean one, and that's part of the story. The first "Start Run" attempt failed outright with a generic-sounding conflict error — not a UI glitch, a real backend collision. On retry, the run that actually got created carried that exact error text as its specification, because the form field that's labelled "describe the issue" got used, understandably, to describe the issue we'd just hit.
What happened
The first attempt's failure was a genuine backend bug, not user error. Something BinChicken relies on to generate unique record identifiers isn't actually guaranteed unique across separate server processes, and it collided with a record already sitting in the database from an earlier session. This isn't fixed yet, and we're deliberately not detailing the exact mechanism here while it's still open — it's a real weakness, not just a story beat. The retry avoided the same collision and succeeded.
Two roles both made real Anthropic calls — a few minutes each — against a specification that was just an error message. Neither hallucinated a task to justify itself. The first correctly reported there was nothing real to scope. The second did the same, but — "for completeness" — recapped the whole existing system, including a line describing how BinChicken handles its own stored credentials.
That recap is what stopped the run, not anything it actually proposed. BinChicken's safety gate uses deliberately simple, deterministic pattern matching to flag risky-sounding language, not full understanding of intent — and a sentence describing credential handling matched the same pattern written to catch a sentence proposing to change it. The gate fired correctly on its own terms — genuinely risk-adjacent language was present — even though there was no genuine risk behind it. Worth sitting with: this is the safety net behaving exactly as designed, and the design still produced a false alarm.
Reviewing that gate surfaced a real, separate interface bug. The confirmation dialog didn't fit the screen — long enough content pushed part of it out of view with no way to scroll back to it. Trying to work around that, the wrong one of two similarly-placed buttons got clicked by accident.
The run ended correctly anyway. Both of the available buttons in that situation durably cancel the run; every step downstream of the gate was marked skipped, nothing was left half-finished, and — this is the part that actually matters most — the build step and the entire GitHub-write path were never reached. No branch, no commit, no draft PR, on a specification that should never have produced one.
Where this leaves things
Four real, separate things came out of this run, and none of them are fixed yet:
- A backend id-generation bug is real and unresolved. It's not specific to this attempt, and it's the thing most likely to block the next real run start if left alone.
- There's no graceful "there's nothing to do here" path. The Builder role's output format requires at least one proposed change; had this run reached that step on a genuinely empty specification, it would have had to either fail outright or invent something to satisfy that requirement. This run never got far enough to find out which — that's luck, not a tested safeguard.
- The safety gate's simple pattern-matching can't tell "describes an existing thing" from "proposes to change it," and will keep producing false alarms on interpretation text that happens to recap real architecture.
- The confirmation dialog itself is an interface bug independent of everything else here — any sufficiently long dialog can render off-screen with no way to scroll it back into view, which is exactly the kind of thing that turns a correct governance stop into an accidental click.
What actually held, and is worth not losing in the list above: two real, paid-for Anthropic calls ran against a meaningless input and neither one lied about it, a safety gate that was reacting to noise still stopped the run before anything consequential happened, and cancellation left the system in a clean, honest, fully-skipped state — not a stuck one. The infrastructure held. The next attempt needs a real specification, a fixed id generator, and a dialog that fits on the screen.