feat(sensor): record what a container replacement interrupted (CLOUD-451)

[wenzowski]

Collects the evidence that decides whether CLOUD-451 is fixable in this repository at all. A sensor and nothing else — no deny, no gate, no occupancy, nothing on the path to a human.

Why

CLOUD-515 removed plan-hold because nobody could say whether occupancy defers the reclaim that destroys a human's typed approval. Four issues and ~17 hours went into maintaining a mechanism whose premise was never once observed. This is the ordering that should have come first: instrument, read, then decide.

Two events are on record and they point opposite ways:

event	what was running	outcome
2026-08-13 06:18:54	nothing — zero tracked tasks, ~14 min idle	replaced, disk preserved
2026-08-12 ~22:12 (CLOUD-491)	four live tracked tasks, incl. a land doing network I/O every 10 s	replaced anyway

If reclaims only ever hit idle containers, occupancy is the right lever and CLOUD-451 earns a mechanism. If they kill active work too, occupancy cannot help and the issue belongs upstream. Each is attested exactly once, which settles nothing.

How, at close to zero cost

mise-tasks/reclaim-census rides land-lock hold's existing 30 s beat, which ticks for exactly as long as a land holds the lease — the window "active work is in flight". One append and one sync -d per beat, against a loop already doing a network push per beat. No new process, no new poll.

That is the difference from what was deleted: plan-hold was a process whose only purpose was to be occupancy; this is a record on work that happens anyway.

The record is structural, not temporal, reusing CLOUD-491's finding rather than re-deriving it: the last 182 s of writes before a replacement were measured not to survive, so any clock-based reading is minutes stale exactly when asked. h per beat, x only where something chose to stop, verdict from the last line's kind. A loop the container killed cannot write an x, so a trailing h is the evidence.

The fifth stop path, which the plan missed

Four x sites are the obvious ones inside the hold loop (holder gone, stalled, lease lost, lease lapsed). The fifth is land's drop_lease, which kills the heartbeat on a normal finish — the loop never runs another statement, so its last record stays an h. Without a record there, every successful landing would afterwards read as "the container died under active work": the exact false positive that would wrongly license the mechanism just removed.

Written from land rather than the heartbeat's own trap, per CLOUD-491 — a trap runs on the container kill too, and an x from one would erase the only distinction the census draws.

Verification

• tests/reclaim-census.bats, 20 cases: every verdict row, the fail-open rows, and two that are not fixtures because they are the claim — a kill -9ed loop leaves an h even though its trap runs, and a loop that stops on purpose leaves the matching x.
• Two call-site rows assert the wiring counts, so an exit added later without a record is caught rather than silently dropping evidence.
• mise run mutant — 17 mutations across 11 gates, every one caught, including both new ones.
• mise run verify running; result reported here before this is readied.

Worth flagging for whoever writes the next sensor: mutant stages the tree with git ls-files, so a brand-new untracked suite is invisible to it and every mutation reports case-already-red. git add first. The task's header says it works "while a gate and its suite are being written", which is true for modified tracked files and not for new ones.

What this does not claim

Nothing about whether occupancy works. That is the question, not the answer.

Decide at 10 recorded replacements — a count, not a date. Idle-only → occupancy is the lever, and enforcement is worth reopening, cheapest form first. Any that kill active work → occupancy cannot prevent those; report the split and escalate with this census as the evidence.

A boundary worth stating, since three attempts have hit it: the user's typed-but-unsent approval text is client state and no repo mechanism can save it. At best this repo reduces how often a reclaim happens.

Refs: CLOUD-451

---

Generated by Claude Code

[linear-code]

CLOUD-451 A turn that hands control to a human ends idle, so the VM is reclaimed while the human is still typing — and their input is destroyed

Waiting on a human is the one legitimate idle turn end, and it is the only one with no mechanism.

What happens

A session calls ExitPlanMode (or AskUserQuestion) and ends its turn with nothing backgrounded. The container is idle, so it is reclaimed — reported as roughly every 2 minutes. The damage lands entirely on the human: text already typed into the approval box is discarded, or the plan is closed and a fresh one reopened. Reported verbatim by the repo owner: "Every time you throw out my valuable in progress work (you delete what I typed) or you close the plan and reopen a fresh one. This makes it impossible to carefully approve your work."

So the review step this repo depends on — a human reading a plan before an autonomous agent executes it — is not merely inconvenient, it is anti-correlated with care: the longer the human reads, the likelier their input is destroyed.

Why nothing catches it

mise-tasks/run-shape-guard already names the failure — "leaving only polling or an idle turn, both forbidden, and an idle turn gets the VM reclaimed" — and AGENTS.md carries the same rule as prose. Both address the agent's own idleness. Neither has a mechanism at the boundary where ending the turn idle is correct, because control has been handed to a human on purpose. That is non-negotiable rule 2's shape exactly: a rule with no runnable gate is half a change.

A hook cannot fix it alone. The hold has to be a real backgrounded tool call the harness knows about; a nohup-detached process is the orphaned-run shape run-shape-guard refuses, and a hook has no way to create a harness-tracked background task. What a hook can do is refuse to let the handoff happen until one exists.

Mechanism

1. mise run plan-hold, launched with run_in_background — a no-op that writes a pid sentinel and sleeps until the sentinel is removed or a hard cap elapses. Zero output until exit, so it costs no tokens while the human reads; its exit is the wake-up.
2. plan-hold-release on UserPromptSubmit (already-wired event) removes the sentinel, so the hold exits within one poll of the human's reply rather than being killed by it.
3. plan-hold-guard on PreToolUse, matched to ExitPlanMode|AskUserQuestion only, denies the handoff while no hold is live, naming the exact command.

Refinement — Ready

Specializations only; the shared clauses live in Definition of Ready & Done.

• Source of truth (§1). One sentinel file under the git dir, written by plan-hold and read by plan-hold-check. The path is spelled in plan-hold-check and every other file calls that task rather than re-deriving it — the same single-spelling discipline claim-guard keeps with claim-check's receipt.
• Mechanism as a computable predicate (§2). "A hold is live" = the sentinel exists and its recorded pid answers kill -0. A stale sentinel whose pid is gone is not-live, the same corpse-versus-free-lock distinction alive and target-ensure already draw. Pure filesystem state, no network, no board read.
• Effect (§3). read. The hold writes only its own sentinel under $GIT_DIR, which claim-guard already treats as machinery rather than work.
• Generated artifacts + drift gate (§4). None.
• Output & exit contract (§5). plan-hold-check: 0 live / 1 not live / 2 cannot look. The guard uses Claude Code's permissionDecision: "deny" JSON channel, as memory-guard and claim-guard do. Pointer-only: a pid, a path, and the command to run — never a plan or a prompt body.
• Commit / bump (§6). fix(hooks); patch until 0.1.0.
• Test obligation (§7). tests/plan-hold.bats and tests/plan-hold-guard.bats: live pid → allow; missing sentinel → deny naming the command; stale pid → deny; unrelated tool name → allow; unparseable stdin → allow; bypass env → allow. Plus the hold's own timing properties — releases on sentinel removal, honours its cap, and a second launch while one is live is a no-op.
• Blockers (§8). None. Related: CLOUD-435 — it deleted every PreToolUse entry on a per-tool-call cost argument, and this adds one back under that same argument's own criterion: ExitPlanMode and AskUserQuestion fire at most once per turn, the frequency class of Stop and UserPromptSubmit, which it kept. Phase 2 should port this predicate alongside the rest, and it is a capability gap for batten hook today — no rule kind expresses "a named background process is live".

Acceptance

• A plan left open for longer than the observed reclaim window survives, with the human's typed input intact.
• ExitPlanMode with no hold running is refused, and the refusal names the command that fixes it.
• The hold exits by release, not by kill, when the human answers — so answering wakes the session rather than orphaning a sleeper.
• No interactive approval is introduced anywhere before the plan: the launch runs under the existing Bash(mise:*) allowance.

Not in this issue

Whether every other idle turn end should arm the same hold. The predicate would be broader and the enforcement point different (Stop, at the cost of a model turn per end), and it is a separate decision from the human-handoff case measured here.

Review in Linear

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[wenzowski]

/fast-forward