[Juliusolsson05]

Refs #943.

The gap

createControlHost.dispose() retired waits, window registrations and IPC handlers synchronously and returned. None of that is evidence that anything stopped: an admitted operation was still running, and its durable result was still queued behind FileControlHistory's append tail. So applicationShutdown's control stage completed instantly and the exit — and the state-process lock — were released while the effect was in flight.

That is the one state a restart cannot answer for: the mutation may or may not have happened, and the journal that exists to say which is missing the record.

What dispose does now

The order is a contract:

1. Close admission. No new effect is admitted. Reads still answer — they change nothing, and refusing them would blind the tooling used to diagnose a stuck quit. An unknown capability id counts as effectful, so a call nothing knows anything about is refused rather than waved through.
2. Retire the renderer-facing surface.
3. Await every admitted operation, then the history tail. That order is real: an operation finishing appends its own result, so draining the file first would leave the very last one behind — and the tail covers what the executor cannot, since recordTransport appends straight to the history outside any call.

IPC handlers come off last. operations.start / operations.finish travel the private main port rather than IPC, so the main process records its own receipts throughout, and leaving control:invoke registered until the end means a renderer gets a structured refusal instead of a dead channel.

Two details the issue called out

In-flight is counted from the top of invoke, not from active. The active map is populated only after the serialized received-intent append succeeds, so draining it alone would miss every operation still inside admission — which is where the serialized, slow part is.

Nested calls are never refused, and say so explicitly. Batch members, a wait's inner read and the main port's own operation receipts all reach the executor after their parent was admitted; refusing them half-finishes work already underway. inFlight > 0 cannot tell a batch member from a fresh external request arriving at the same moment, so the three internal call sites pass { nested: true } and every external entry point (control:invoke, forCaller(...).invoke) does not.

disposeControlHost is typed () => Promise<void> deliberately: a () => void still compiles when assigned an async function, and the shutdown stage would then resolve immediately and release the lock mid-drain.

Tests

Two composed regressions, driving the real executor, the real registry and the real FileControlHistory against a real directory. Electron is stubbed only where ipcMain is touched; the dispatch target is a stand-in because a controllable effect is the point.

• controlDrain.system.test.ts — an intent still inside admission at commit, a dispatched effect awaiting completion, a refused mutation carrying not_started, reads still answering, nested calls admitted, and a timed-out transport retry joining the in-flight call instead of dispatching twice.
• controlHostDispose.system.test.ts — the real dispose(): it does not resolve while the effect is dispatched, it refuses a new mutation the moment shutdown begins, it retires IPC only after the drain, and it flushes a queued recordTransport append.

mutation	result
settled() resolves immediately (the bug)	2 failed
inFlight counted from the active map	3 failed
admission never closes	1 failed
mutations admitted after close	1 failed
reads refused too	1 failed
unknown capability treated as a read	1 failed
nested calls refused	1 failed
refusal reports an unknown outcome	1 failed
history drain is a no-op	1 failed
dispose skips the executor drain	2 failed
dispose skips the history drain	1 failed
IPC retired before the drain	1 failed
restored	40 passed

npx tsc -b clean. Wider src/main/ run: 1662 passed, with one failure — src/main/workflows/control.system.test.ts — that I verified fails identically on clean origin/main (stashed this branch's changes and re-ran). Not caused here.

Why Refs and not Fixes

The issue's B02 acceptance is broader than this. What is not here:

• The "required failures hold the exit/lock boundary" assertion is inherited from applicationShutdown's existing join/onShutdownError path rather than newly proven for the control stage specifically.
• No application crash or OS-exit reproduction has been run, which bug(control): drain admitted operations and result receipts before exit #943 already notes as outstanding.
• The revision-bound editor preparation and B05 mutation-uncertainty coordination the issue mentions are untouched.

🤖 Generated with Claude Code

[Juliusolsson05]

Review round addressed. Finding 1 is the one that stings: the composition falsified three claims in my own comment, and the probe output is unarguable.

1 — retirement now happens AFTER the drain. unregisterMain() and the window retirements empty the catalog, the gate resolves declared effects against it, and an unknown id is treated as effectful — so during the drain everything was refused, reads included, and operations.* failed with "No owner" because their owner had just been unregistered. Waits are still cancelled first: that is not a registry change, and a wait would otherwise sit in the drain for its full deadline waiting for something being torn down.

2 — accepted tasks are drained now, and your probe is what made it undeniable: task.started with no task.finished is verbatim the state the commit message claims to prevent. The executor already computes status: 'pending' for exactly these and sees the matching operations.finish carrying the same callId, so it accounts for them without knowing what a task does.

3 — receipts are exempt outright. operations.start/operations.finish do not cause effects, they record them, and telling a caller not_started about an effect that already happened is worse than the dead channel it replaced. This also turned out to be load-bearing for 2: refusing them would make the drain wait for a completion that can never arrive.

4 — 10 s deadline, and an incident. You are right that hanging buys nothing: the user force-quits, which loses the record and strands the lock. stopPerformance's 2 s race three stages later is the precedent, and I have cited it. An incomplete drain now journals control.drain_incomplete with the outstanding counts, so a restart that finds an operation with no result has somewhere to look.

5 — the type claim was false and is corrected. Promise.resolve(action()) adopts the promise regardless of the declared type, and types are erased. The annotation is documentation that would catch a call site dropping the promise; it is not a safety mechanism, and the comment says so.

6 — ten of your eleven caught. The remaining three are equivalent mutants today, and I have written that into the code rather than inventing coverage: removing {nested:true} from any internal call site is unobservable, because the main task port carries only receipt capabilities, agents.batchRead and its members are reads, agents.batchPrompt is refused at the gate before any member runs, and a wait's inner request is hardcoded to reads. Your own smuggling analysis is what establishes that, and it is quoted in the comment. The flags stay as the standing answer for the first non-read batch member.

49 tests in src/main/control/ + src/control-sdk/; npx tsc -b clean; wider src/main/ 1682 passed with the one pre-existing workflows/control.system.test.ts failure you independently confirmed.