[nikolasd]

A parked run used to be settled to lost by the inactivity sweep once it went quiet, conflating a worker gone quiet while its leader was still connected with a leader that had itself vanished. Only the second is actually abandoned; silence alone is never evidence a leader gave up, only its connection actually being gone is.

Mechanism

ipc::leader_registry::LeaderRegistry: a refcounted registry keyed by leader instance id, in ipc::server::Shared beside active_connections, populated from inside ipc::connection::handle (the negotiated instance id doesn't exist until the initialize handshake completes). Refcounted rather than a set or a flag, because more than one physical connection can share one instance id (the crew-extension fallback), and plain addition resolves both connect/disconnect race orderings correctly.

Each entry is {count, zero_since}, not a bare count. zero_since records the instant of the entry's most recent 1→0 transition and is cleared on any 0→1, closing a bug in the simpler design: a leader that disconnects, reconnects, and disconnects again within one grace window could otherwise leave a stale timer reading count == 0 correctly, but for the wrong disconnect.

The registry's decrement is a drop guard, not a statement paired by hand at each exit from the dispatch loop: a future early return would otherwise leak the registration silently, failing the feature closed with nothing to notice. The guard's on_gone callback fires exactly on the drop that causes the true 1→0 transition, arming the grace-window timer from inside Drop::drop itself.

The grace window is 60 seconds. Teardown reuses run_cancel's own mechanical shape via a shared cancel_and_settle_run helper parameterized on the target state: run_cancel asks for the literal "cancelled", checked against the requesting principal; the new path asks for RunState::unrendered_verdict() and bypasses the ownership check the same way the removed backstop did. A WorkerTimeout { kind: LeaderGone } fact is journaled first, before the state changes because of it.

Daemon restart: at startup nothing has connected to the fresh registry yet, so every leader owning a non-terminal run is, from this process's own perspective, disconnected as of right now. Each such owner is seeded with zero_since set to the daemon's own startup instant and the same grace-window timer armed. The clock starts at the daemon's own startup instant, never at a run's last-seen activity: a leader cannot reconnect to a daemon that is not running, so downtime is the daemon's own absence, not the leader's, and must never be charged against the window. The disconnect grace window is a ServerConfig field now, defaulting to the production constant, so tests can shrink it instead of waiting out the real window.

Removes the inactivity sweep's settle_abandoned_turn path entirely, along with its three dedicated tests. A parked run whose leader is still connected is never settled by the runtime now, however long it stays silent — the inactivity fact is still journaled, but it no longer drives a state change. lost returns to its original, narrower meaning: the evidence itself is missing or ambiguous, never "the leader went quiet."

Review response

A leader that reconnects while settle_leader_gone is still working through its owned runs (a query plus two DB round trips per run — not instantaneous for a leader with several parked runs) previously had every one of those runs settled anyway, after it was demonstrably back. settle_leader_gone now re-checks gone_for_at_least immediately before each run's own settle, not only once via the caller's check before the loop starts. The caller's check stays as the cheap early-out; the new one is what actually protects a leader that comes back mid-loop. Proven with a driver whose first cancel_run call blocks until released, landing the reconnect deterministically between two runs' settles rather than racing a guessed sleep.

Two hardening changes from the same review: gone_for_at_least on an instance id with no registry entry at all now answers false, not true — both real callers always create the entry first, so the branch is a guard against future misuse, never a path either takes today, but the destructive answer must never be the default for an unestablished question. And the LeaderGone arm in the inactivity sweep and ActivityClock::mark_journaled, both invariants that should hold but run inside a long-lived background task, now log an error and continue instead of panicking.

Docs

Adds ADR-0036, amending ADR-0027 (the backstop-settles-on-silence half of its Decision point 3 is superseded; the "never succeeded" half is inherited unamended) and noting the crew-extension shared-instance-id hazard the refcounting has to be safe under without resolving the pre-existing ownership ambiguity that id already carries elsewhere. Updates docs/architecture.md and docs/future-features.md, which described the now-removed backstop as current behavior.

Tests

9 unit tests on LeaderRegistry covering the refcount/zero_since mechanics directly, including the reconnect-within-window stale-zero case. 4 unit tests on OrchestrationService's restart-seeding and settle paths against a real database — unit rather than integration because the mechanism under test is deliberately internal, never a surface a leader talks to. 6 integration tests against the real IPC server covering a live disconnect's teardown, the shared settle helper, an in-window reconnect, cross-leader isolation, and the inactivity fact's continued journaling without settlement.

bun run generate re-run for the new TimeoutKind::LeaderGone variant.