Dor Tools: pane take-over — dor tool typed at a prompt runs in that pane

[nedtwigg]

Stacked on #493 (Dor Tools Phase B) — review that first; this diff is only the take-over.

dor tool typed alone at a prompt now runs in that pane instead of splitting: same Surface, same id, same scrollback. Typing a command at a prompt is how a terminal works. Everything else about the invocation is unchanged — same trust gate, same dedupe, same serving trigger — and every other caller still splits.

The gate

All of these hold or it splits, and a split is never wrong, only one pane more than asked for:

• the caller's OSC 633 command line is one command and it is dor tool (an agent's invocation runs under claude / bash script.sh, so the pane reports that line instead);
• the caller is a visible pane whose leaf is a plain terminal;
• the tool's directory is that pane's own (the command is typed into the caller's shell, so it runs where that shell already is);
• no --surface and no --minimize — both name a placement;
• no pending approval and no key match — the first needs a pane that has spawned nothing, the second reveals its survivor.

The naked-line test is the human-intent signal, not a security boundary: dor send can type bytes identical to a human's. Trust is still the gate that carries the weight.

The handshake

dor is the caller's foreground process when the host answers it, so the host answers takeover first, waits for the shell to report itself back at a prompt, and types the command only then. Waiting first deadlocks — the prompt cannot return until dor exits, and dor cannot exit until it is answered. Consequences, all specced:

• the response promises the placement, not the run;
• a shell that never comes back to its prompt is left alone — nothing typed, leaf still a terminal;
• the spawn lock is held past the response until the command is live, so a same-key invocation racing it dedupes against a running tool;
• the transformation is one meta write (setMeta), so component pair and params commit together and the leaf id — the SessionId — never moves.

Changes

• lib/src/components/wall/tool-takeover.ts — the gate, as pure predicates over facts the handler already has.
• surface.tool in use-dor-control.ts — the take-over arm and the handshake.
• setMeta on the Lath wall store — the first in-place leaf-kind change; documented in tiling-engine.md alongside setTitle / updateParams.
• cwdPathsEqual lifted out of surfaceRunsCommand so the gate and dor ensure bridge the Windows/MSYS dialect split the same way.
• dor tool gains a takeover status (help text + snapshot).
• dor-tool.md: the design moves out of ## Future into ## Take-over, with rationale. Word budget raised 425 words for it.

Tests

• tool-takeover.test.ts — the naked-line test and every gate condition.
• Wall.test.tsx — take-over end to end (answered before the tool starts, nothing typed while dor owns the shell, command lands after the prompt returns, one leaf throughout, persists as a tool on the same id) and the split fallback when the caller is running something else.
• pnpm exec vitest run in lib: 2010 passed. pnpm --filter dor test: 136 passed. spec-lint: OK.

🤖 Generated with Claude Code

https://claude.ai/code/session_0166PG9g7V3kZ6Uo9EHrpoTD

[cloudflare-workers-and-pages]

Deploying mouseterm with    Cloudflare Pages

Latest commit:	bdbee6d
Status:	✅  Deploy successful!
Preview URL:	https://25249b46.mouseterm.pages.dev
Branch Preview URL:	https://tool-takeover.mouseterm.pages.dev

View logs

[dormouse-bot]

One interaction worth a look before this lands, plus a smaller note.

A taken-over pane can become its own key match, and the adopted re-run is unreachable there. The spawn-time dedupe branch in surface.tool runs before the new take-over arm and probes const idle = getTerminalPaneState(match.id).currentCommand === null;. Before this PR the matched surface was always a pane other than the caller, so that read the tool's own state. After a take-over the caller is the tool: dor tool storybook typed again in that pane — the natural "the dev server exited, restart it" gesture, and now the pane the user is sitting in — matches itself through findSurfaceByParams(matchesToolKey) (lath.listPanes() includes the caller), and currentCommand is the in-flight dor tool storybook line, so idle is false. Output is existing surface:1 "pnpm storybook" and nothing re-runs. Only a keyed tool reaches this; an unkeyed one falls through to the gate, fails component !== 'terminal', and splits, which is fine.

Two shapes of fix, both one condition. Skip the key match when match.id === detail.surfaceId and let the take-over arm handle it — it re-writes the meta and types the command, which is an in-place adopt. Or treat the caller as idle by construction, since dor running from that pane's own shell means the tool command has already exited. The first is the safer of the two: restartSurfaceInPlace opens with platform.writePty(id, '\x03'), and firing that into the pane where dor is the foreground process would interrupt dor before it is answered — which is what the second shape would do on any caller whose currentCommand happens to read null.

Happy to push either one as a commit if you want it in this PR rather than a follow-up.

Smaller: of the five handshake invariants under Take-over, "a shell that never comes back to its prompt is left alone: nothing typed, leaf still a terminal" is the only one with no test behind it — TAKEOVER_PROMPT_TIMEOUT_MS makes it awkward to pin, but it is the handshake's equivalent of the gate conditions tool-takeover.test.ts enumerates one by one.

[dormouse-bot]

The /simplify pass took two things out that were load-bearing. Both are in the new commit, both are narrow, and I'm happy to push either fix as a commit if you'd rather not hand-roll them.

[dormouse-bot]

The re-run arm closes the case it targets. Two things the new commit leaves open, both in the fall-through around it.

[dormouse-bot]

Both fixes read correctly to me — the re-run gate dropping only the placement conditions is the right cut, and snapshotting lastCommand?.id rather than matching on the command line is a better version of what I suggested. One gap in what pins the second one, plus a contract note. The Windows-path decision on the other thread is fine by me: commandArgv0 already mangles those paths for the WATCHING keys and the header, so a second parser here would be the disagreement, not the fix.