Two 900-second agent runs and a git stash pop conflict that never resolved

Zero for four

At 11:05 that morning we asked the hub for four things. A secretary we could actually talk to. Visual triage of what we’d been sending it. Presentations instead of walls of text. Windows that stayed structured instead of scattered. By 1:50 PM, two hours and forty-five minutes later, it had shipped none of them. It said so itself in the handoff note, before we had to point it out.

What it shipped was infrastructure. The log calls it four fixes, but the handoff note only numbers three. The three it named: a browser cleanup routine that destroyed windows right after telling us to sign into them, a reply gate that duplicated every corrected message instead of replacing it, and a live session that was silently marked closed while it was still running. None of that was on our list. All of it sat underneath everything on our list.

The window lease and the conflict nobody resolved

The browser cleanup bug goes back a few hours, to the module that leases browser windows out to sessions. At 11:45 AM a different session, working an identity fix under its own tracking tag, committed its change and then ran git stash pop to bring back some work it had set aside. The pop hit a conflict in the leasing module. The session stopped there, unresolved, and said so in its output.

Our next move was to throw agents at it. Two more sessions spun up back to back, each pointed at cleaning up the mess. Both ran the full 900-second timeout and returned nothing. That is two runs of fifteen minutes each, thirty minutes of wall clock, and no resolution. This was the wrong turn. We treated a merge conflict in a window-leasing module as a black box an agent could power through if we gave it enough time. It couldn’t. The conflict needed someone to look at what that module was doing to leases, and merging the diff wasn’t going to answer that.

The session that made progress never touched the stash. It went around it and rebuilt the piece that mattered: a CLI command that shows the owning identity and session id for every window the pool has leased out, in text and in --json mode. That took seventy-three seconds and committed clean. Once you could see which identity owned which window, the destroyed-windows bug stopped being mysterious. The cleanup routine was tearing down leases it believed were orphaned because it had no reliable way to see who currently held them. That is the fix that shipped by 1:50 PM under “browser cleanup.”

Why the other asks had to wait

The other two named fixes read the same way once you see the pattern. The reply gate duplicating corrected messages meant a “secretary we could talk to” would have shown us every correction twice, which is worse than having no secretary. A session marked closed while still live meant visual triage would have been triaging ghosts. You can’t build a UI for windows on a browser layer that eats its own leases, and you can’t build presentation or conversation on a state layer that lies about what is still running.

So the 1:50 PM handoff went like this. It wrote a restart document that said so in plain terms. It put a release hold on the resume board, tagged to the ticket tracking that regression, so no downstream session would cut a release off a develop branch it knew was broken. Then it handed off to session 9 with the blocker named, instead of repeating the four original asks verbatim.

Session 9 built the real thing in twenty minutes.

That gap is the part I keep coming back to, more than the thirty minutes lost to the stash conflict or the two hours forty-five that produced no visible feature. Once the blocker was named specifically, “windows are unstructured because the lease layer can’t identify its own leases,” the work that had been unbuildable all morning took less time than either of the failed timeout runs.

Session 8 spent its whole run finding and naming the one thing in the way, and that is why session 9 could close the critical path in twenty minutes. An agent that reports it didn’t do what you asked, gives the specific reason and says what has to be true first is doing more useful work than one that ships a plausible-looking feature on infrastructure it hasn’t checked. When an agent comes back empty-handed, look for the named blocker. Treat a clear report of it as progress, and treat a feature built on unchecked infrastructure as the risk.

dxdev LESSON · paste into your AI coding agent
LESSON: When An Agent Can't Deliver, The Blocker It Names May Be the Real Deliverable
SOURCE: dxdev.com/blog/hub-shipped-infrastructure-not-features
WHAT HAPPENED: A session was asked for four user-facing features and delivered zero of them across a nearly three-hour run. In the same window it found and fixed three unrelated infrastructure defects, each one silently blocking one of the four asks: a browser cleanup routine tearing down window leases it had no reliable way to identify, a Stop hook that had been missed in an earlier log-only rollout and was still forcing a duplicate visible reply, and a session-close hook stamping a still-running session as closed. A merge conflict hit while investigating the first defect was handed to two separate agent runs at a long timeout each, and both returned nothing; the fix that actually worked came from building a small diagnostic instead of retrying the merge. The session wrote a handoff naming the one specific infrastructure blocker left, and the next session closed it in twenty minutes.
THE RULE: When an agent cannot deliver what was asked, check whether it found and fixed the actual blocker underneath the ask before treating the run as a failure. A handoff that repeats the original ask verbatim wastes the next session's time; a handoff that names the specific technical blocker in concrete terms is what makes a fast fix possible afterward. Retrying a stuck merge or stuck process with more agent timeout is not the same as diagnosing what it's actually stuck on.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any handoff or restart document written after a failed or incomplete session that repeats the original ask instead of naming the specific blocker discovered.
  2. Any case where a stuck automated process (merge conflict, timeout, retry loop) was re-run unchanged multiple times instead of being diagnosed directly.
  3. Any infrastructure defect discovered as a side effect of a feature request that was fixed without noting, in the handoff, which downstream features it was blocking.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.