[Juliusolsson05]

Fixes #690 · Refs #681

Two fixes, both reported from real use of the merged Grid Dispatch.

1. Prompt delivery to a hibernated agent (critical)

Typing into an agent shown in a lane could fail with Cannot deliver prompt: <id> is not a live agent session.

This was diagnosed from the live lifecycle journal, not from guesswork. App run 2026-08-30T20-05-09-879Z:

20:07:20.238  delivery.reject  sessionId c0f448e4-…
              code=not-ready  stage=before-write
              registryHit=false  reason="never-owned"

reason: "never-owned" is sessionManager's own discriminator for "main has never held this id this run" — the event exists precisely to separate this from entry-lost-after-owned. And c0f448e4-… is in the persisted workspace under both sessions and detachedSessions: a hibernated detached agent.

Root cause

rehydrate.ts:325 deliberately does not respawn detached sessions, so something must wake them before use. Exactly one path did, and its comment describes this bug precisely:

"Wake under the SAME SessionId before exposing one in a lane/grid slot; otherwise the navigation appears to work but the first keystroke lands on a dead backend."

But the four gestures that actually put a session into a lane all wrote straight through setTiledLaneSession with no wake: the row index click, a lane strip, ⌥↑/↓, and ⌘N.

They now route through one action that awaits ensureSessionLive for a detached target, and refuses to place an agent it could not wake — leaving the lane on its previous occupant is honest; showing a pane whose backend refused to return reproduces the same failure one keystroke later.

The wake completes before the lane is written. Writing first exposes a pane the user can type into during the gap, which is the state being fixed. Grid-placed sessions skip the check entirely — owned by a tile tree, respawned at rehydrate — so the common gesture pays nothing.

Is this new?

The gap is pre-existing. setTiledLaneSession has never woken, including in single-row Tiled Dispatch — git show 18160020^1 shows the same non-waking focusSessionInTab.

#687 made it far more reachable, and both halves contributed:

• Binding a row to a project promotes scope to global, surfacing other projects' detached agents — the ones most likely to be hibernated after a restart.
• Removing auto-fill means every lane is now filled by a deliberate pick through one of those four non-waking paths.

I'm not claiming this as "not ours". It is a latent bug our feature walked directly into, and the reachability change is the reason it surfaced now.

2. The first lane of each row belongs to its index list

Reported directly: "why does the leftmost agent have the mini list? the leftmost agent of course belongs with the large list on the side, that is kind of the whole point."

Correct, and it's a design call I got wrong in #687. I removed lane 0's special case on the grounds that "the index belongs to the row, not to its first lane" — but the row's index sits directly beside its first lane and is that lane's selector. A strip there was a second selector for the same lane, inches from the first, costing 46px of the widest lane in the row.

Every other lane still needs its own strip, because the index is already spoken for.

Verification

typecheck, check:keybindings, test:contract, and the full deterministic suite (2184 passing) all green. Only #684 fails locally — unrelated, pre-existing.

New tests assert the order, not merely that a wake happened, because writing the lane first is the actual defect:

• wakes a hibernated agent before writing the lane
• does not place an agent it could not wake
• does not wake a grid-placed session
• every selection gesture routes through the waking path
• each row's first lane has no strip; the others do

Note for review

The lifecycle journal also showed never-owned rejects for 1f95ed49-…, which is my own orchestration parent session from the review agents I ran earlier — prompts sent to children after I closed the run. Unrelated to this bug; flagging it so nobody chases it as evidence.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VLvdUFXQ7rjUVchjwEPfNf

[Juliusolsson05]

Review round — one blocking finding, fixed

An adversarial review caught a real bug in my own race fix, and it's worth recording how.

Blocking: the re-derivation wrote to the wrong row

My previous commit captured (row, column) and re-derived the flat lane index after the wake. The comment claimed a row removed above the target would drop the write. It didn't. A row index is positional — stable against changes to row lengths, never to row membership. Checking only that the index is still in range drops correctly in a two-row grid because the stale index falls off the end, and silently writes into a different row from three rows up.

The reviewer simulated the real helpers:

reshape during wake	expected	before fix
earlier row grows [1,2]→[2,2]	follow → flat 3	✅ flat 3
row 0 removed, 2 rows	drop	✅ drop
row 0 removed, 3 rows [1,2,2]	drop	❌ wrote flat 3 — old row 2's lane
row inserted above	drop	❌ wrote into the new empty row
target row itself removed	drop	❌ wrote a surviving row's first lane

Concretely: rows [2,1,2], click a hibernated agent in row 1, then run Remove Row while the wake is in flight. A cold wake allows up to 30s, and Remove Row / Close Agent sit on a confirmation dialog inside that window — New Row needs no dialog at all. The agent lands in row 2, evicting what the user was watching in a row they never touched. Precisely the outcome this branch exists to prevent.

Fixed by gating the follow on the row descriptor surviving by reference. Every grid mutation preserves untouched row objects, so identity follows exactly the grow/shrink cases and drops every membership change.

Why it shipped green — the part worth learning from

My test used a two-row fixture. The drop came from the index falling off the end, not from anything about row identity. It encoded the guarantee I wanted rather than the behaviour I had. Rewritten with three rows, and the insert-above case widened to [2,2] so the inserted row is wide enough that the column bound can't mask the identity check.

Both drop-tests were then verified to fail with the guard removed — I didn't just assert they pass.

The reshapes now call the real grid mutations rather than hand-built next-shapes, since the fix depends on those functions preserving row references. A hand-written reshape tests the test's idea of the reducers, not the reducers.

Non-blocking, also fixed

• The empty-lane hint said "pick an agent from the strip" in a row's first lane, which no longer has one.
• Three comments still named the removed setTiledLaneSession workspace method.
• The wake ran before a coordinate check that already knew the write couldn't land — a discarded provider spawn.
• Two comments overstated their guarantees: grid-placed does not mean live (a leaf whose respawn failed is selectable and skips the wake — a gap shared verbatim with agentIndexNavigation, pre-existing), and a detached wake is one adopt round-trip, not "almost nothing".
• gridDispatchLayout clicked row 0's index with focus already in row 0, so it couldn't distinguish focusedLaneInRow from start. Now clicks row 1's index with focus in row 0.

Confirmed fine by review

The unbypassable claim holds structurally — Workspace is ReturnType<typeof useWorkspace>, so a missed call site is a compile error, not a convention. Fire-and-forget is safe. Reachability after the strip removal is intact.

Deferred

⌥↑/↓ coalesces while a wake is in flight — the next-row probe reads the committed lane, so repeats during a cold spawn target the same session with no pending affordance. Real, but it needs a lane-level pending indicator or an optimistic write, which is its own change.

2188 tests passing. Only #684 fails locally, pre-existing and unrelated.