The Hub Shipped Infrastructure, Not Features

Zero for four

At 11:05 that morning I asked the hub for four things. A secretary I could actually talk to. Visual triage of what I’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 zero of the four. It said so itself, in the handoff note, before I had to point it out.

What it shipped instead was infrastructure. The log calls it four fixes; the handoff note only names three by number, which tells you something about how tight that session was running. The three it named: a browser cleanup routine that was destroying windows right after telling me to sign into them, a reply gate that was duplicating every corrected message instead of replacing it, and a live session that was getting silently marked closed while it was still running. None of that was on my list. All of it was sitting underneath everything on my list.

The window lease and the conflict nobody resolved

The browser cleanup bug traces back a few hours earlier, 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, then ran git stash pop to bring back some work it had set aside. The pop hit a conflict in that leasing module and the session stopped there, unresolved, and said so plainly in its output.

The 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. Two agent runs, fifteen minutes each, thirty minutes of wall clock, zero resolution. That was the wrong turn: treating a merge conflict in a window-leasing module as a black box an agent could just power through if you gave it enough rope. It couldn’t. The conflict needed someone to actually look at what that module was doing to leases, not just merge the diff.

The session that actually moved didn’t touch the stash at all. It went around it and rebuilt the piece that mattered: a CLI command showing the owning identity and session id for every window the pool had leased out, in both text and --json mode. Seventy-three seconds, committed clean. Once you could see which identity actually owned which window, the destroying-windows-on-cleanup bug stopped being mysterious. The cleanup routine was tearing down leases it thought were orphaned because it had no reliable way to see who currently held them. That’s the fix that shipped by 1:50 PM under “browser cleanup.”

Why the four fixes had to come first

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

So the honest version of the 1:50 PM handoff isn’t “failed to deliver.” It’s “found out the four things asked for weren’t buildable yet, and fixed the reason.” The session wrote a restart document that said this in plain terms, put a release hold on the resume board tagged to the ticket tracking that regression so no session downstream would cut a release off a develop branch it knew was broken, and handed off to session 9 with the actual blocker named instead of the four original asks repeated verbatim.

Session 9 built the real thing in twenty minutes.

That gap is the part worth sitting with. Not the thirty minutes lost to the stash conflict, and not the two hours forty-five that produced no visible feature. The twenty minutes after. Once the blocker was named specifically, “windows are unstructured because the lease layer can’t identify its own leases,” the fix that had been sitting unbuildable all morning took less time than either of the failed timeout attempts.

An agent that reports “I didn’t do what you asked, here’s the specific reason, here’s what has to be true before it’s possible” is doing more useful work than one that ships a plausible-looking feature on top of infrastructure it hasn’t checked. The four fixes weren’t a detour from the four asks. They were the actual critical path, and the only reason session 9 could close it in twenty minutes is that session 8 spent its whole run finding and naming the one thing actually in the way, instead of spending it building a UI on sand.

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/2026-09-23_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.