feat(hooks): record what this branch put on the board, and whether it was refined

[wenzowski]

Phase 1 of CLOUD-514: the sensor. It records what this branch put on the board and
whether a new row was refined when it was filed. It gates nothing yet.

Why a sensor alone, when non-negotiable 2 refuses a log without a gate

The exception is measured rather than asserted. The gate's firing rate cannot be
estimated retrospectively, because which branch put which row on the board has never
been recorded anywhere — not on the row, not in git, not on the PR. The one available
proxy (rows created between a PR opening and its merge) was measured over the last 40
merged PRs and fires on 183 of 184, since a window over a fleet captures everyone's
filings. So this record is what makes the gate specifiable at all, and phase 2's trigger
is a number this produces.

Why the lint runs in the hook rather than in a receipt

The first draft had the agent run ready-lint and mint a receipt. That is worthless:
ready-lint reads a payload the caller assembles, and during this issue's own
refinement it was run three times against text in a local file — once under the id
CLOUD-NEW, for a row that did not exist — green every time. A toll payable in text
nobody filed is not a toll. A PostToolUse body has no such problem: it fires on the
tool result, which is the tracker's own response to the create.

Three things measured, each of which would otherwise have shipped broken

The result envelope. No hook in this tree had ever read a tool result, and the
documented example is a Write with a flat object. An MCP tool returns the content-block
list, so .tool_response.id does not exist — a body written against the docs records
nothing, silently. The key is reached through .text | fromjson | .id.

Relations. ready-lint's §8 rule cross-checks prose claiming a blocker against the
payload's relations, and the create response carries none. Linting the response alone
therefore refuses exactly the rows refined most carefully. The create call's own
blockedBy argument is the entire relation set on a create, so the lint payload is
synthesised from both halves of the event — body and updatedAt from the tracker,
relations from the input. The thing being judged is still the tracker's bytes.

How ready-lint is invoked. Found by a failing test. mise run needs the project
cwd and a hook inherits the cwd of the tool call, so the obvious call fails outside the
project — and mapping any non-zero to unready records a verdict about the environment
wearing the mask of a verdict about the row. Sibling task by path, and the status read as
three answers: 0 ready, 1 unready, anything else unanswered.

Coverage

tests/board-write-record.bats at 14 rows, including the one this design turns on — a
row whose §8 claims a blocker still records green, which is red without the relations
synthesis. Two #MUTANT rows (create/update collapse, relations dropped); mutant green
at 14/14 across ten gates. Full suite 1489/1489, run with
GIT_CONFIG_GLOBAL=/dev/null GIT_CONFIG_SYSTEM=/dev/null so the CLOUD-513 class of
verify/CI disagreement is caught here rather than on a runner.

Pointer-only is load-bearing rather than decorative: the text this reads is the entire
issue body, and four fields reach the file. Asserted.

Not in this PR

filed-here-check and its land call site — phase 2, blocked on the observation window
above.

Corrections, added after merge

Three claims above are wrong, and the evidence for each arrived within the hour.

"Unwired in the session that wrote it (CLOUD-187)." It fired immediately from the
working tree, recording five rows between 06:46 and 07:10 — before this PR merged at
07:08 — and two PreToolUse guards another branch landed mid-session fired on this one.
The measurement and its limits are on CLOUD-187.

Those first rows exposed a defect this PR shipped. A comment row recorded the
comment's own uuid rather than the issue key, because a save_comment response is the
comment object and names no row at all. Sink 2's definition — a comment on the row that
already owns the finding — was therefore unobservable, while every count still looked
right. Fixed in the follow-up: the key comes from .tool_input.issueId, and a reply or a
non-issue parent records - rather than a uuid, because a uuid in an issue-key column is
a wrong answer wearing a right answer's shape.

The "1489/1489" figure was measured with BATTEN_CLAIM_GUARD_BYPASS=1 exported, so
that sweep ran against a tree with claim-guard disabled and five of its rows would have
failed. test:bats inherits ambient bypass variables the same way it inherits ambient git
config; recorded on CLOUD-513, whose [tasks."test:bats".env] block is where both belong.
The number needs re-taking in a cleaned environment.

Refs: CLOUD-514

[linear-code]

CLOUD-491 A live `plan-hold` did not stop a container restart, and nothing records that it was live — the hold ships with no sensor

Why

CLOUD-451 landed plan-hold on the premise that "the container is idle, so it is reclaimed" — so occupying the container with a backgrounded no-op defers the reclaim. Its acceptance is "a plan left open for longer than the observed reclaim window survives, with the human's typed input intact."

Measured 2026-08-12, ~22:12 UTC. A hold was armed (mise run plan-hold, backgrounded, task bfu2m1iit) and the container was restarted anyway. The harness's own restart notice named the four tracked tasks it killed:

- Wait for verify to finish (baf3psi7z)
- Wait for local CI reproduction to finish (bcbzgem2e)
- Re-commit with the message file and land (bge0bb5ib)
- Arm plan hold before exiting plan mode (bfu2m1iit)

So the container went down with four live tracked tasks, one of them a full land mid-CI-wait. The new container came up at 1 minute uptime with 14.6 GB of 16 GB free and 24 GB of disk available, and no OOM line reachable — the restart was not resource pressure on this side. The human's approval button was gone, which is the exact damage CLOUD-451 exists to prevent, and the landing work survived only because it had been committed.

Reproduced 2026-08-12, ~23:45 UTC, in the session grooming this issue: a hold was armed, and the container was restarted roughly a minute later, killing it. Two independent instances now, and the second one left artifacts the first did not — see the measurements below.

The finding is not "the hold is wrong". It is that the hold cannot be graded. A mechanism that occupies the container leaves no record of having done so, so from inside there is no way to distinguish the hold having been live and reclaimed anyway from the hold having already exited from a platform event no occupancy could defer. All of them produce the same observation — a fresh container — and the issue's acceptance is written in terms nobody can check after the fact. That is the sensor-without-a-gate shape inverted: a mechanism with no sensor. It is why an instance can be reported but not diagnosed, and why the honest first move is evidence rather than a bigger hammer.

---

Measured 2026-08-12 ~23:30–23:46, and it changes the mechanism

The first draft of this issue assumed one kind of container replacement. There are two, they are indistinguishable from inside without a sensor, and they have opposite consequences for any sensor built from a local file.

1. The 23:30 boot destroyed everything. btime was 1786577404 (23:30:04Z), and

find /home /root /tmp /var/tmp -xdev -newermt "21:00" ! -newermt "23:29"  →  0 files

A session was demonstrably alive at 23:28 — this issue's own last edit — and nothing it wrote survived anywhere writable. .git/index was dated 23:30:11, seven seconds after boot, sitting over an image base layer from 2026-08-06. A fresh container on a fresh disk: the clone is reconstructed at boot.

2. The 23:45 boot preserved the disk. btime 1786578317 (23:45:17Z), and 20,184 files from the previous container survived — target/, and .git/batten-holds/ itself. A restart of the same disk.

Same appearance from inside, opposite consequences. A heartbeat file under $GIT_DIR is readable across (2) and does not exist at all across (1) — so the three-case taxonomy this issue shipped with has no room for the second event class, and its predicate last_heartbeat > btime - poll cannot tell a fresh container from no hold was ever armed. Both present as an absent file, which the draft defined as silence. Shipped as written, the sensor would pass a bats suite that fakes boot time in a tmpdir and report nothing in the case that actually destroyed the plan.

3. The surviving hold directory was empty. .git/batten-holds/ came through the 23:45 restart present and empty, mtime 23:42:15, with a hold armed shortly before. The sentinel is gone. plan-hold-check's header asserts "a container reclaim does not run traps", and this artifact was at first read as consistent with its negation — the hold's own trap erasing the only record that a hold was live. Measurement 4 supersedes that reading: 23:42:15 is a boundary, not a trap firing. The trap remains a candidate and the heartbeat must still not be trap-removed, but it is no longer the leading explanation.

4. The last 182 seconds of writes did not survive, and this falsifies the predicate this issue shipped with. Every surviving pre-boot write stops at 23:42:15 — the MCP logs of four different servers, Serena's log, target/.rustc_info.json, and .git/batten-holds — while the container demonstrably kept serving tool calls until ~23:45. From the newest surviving file to btime: gap=182s. Whether the cause is a disk snapshot boundary or unflushed page cache cannot be determined from inside, and it does not need to be: either way the tail of a per-poll heartbeat is lost exactly when the sensor needs it.

So the first draft's predicate — epoch ≥ current btime − poll, a 5 s tolerance — reads the surviving last heartbeat as three minutes stale and answers "did not span" for the very event it exists to catch. Widening the tolerance to cover 182 s does not rescue it: a window that large also swallows a hold that legitimately exited minutes earlier, which collapses the already-exited case and with it the point of the sensor. The predicate has to stop being a time comparison.

The heartbeat question, stated so it can be settled rather than argued. Two different things are called a heartbeat here and only one is cheap:

• A heartbeat as EVIDENCE — the hold records its liveness to an out-of-tree file each poll. Costs one date and one append per 5 s, no model call, no tokens.
• A heartbeat as KEEP-ALIVE — something that periodically wakes the session, on the theory that the reclaim clock is driven by agent turns rather than container activity. Each wake is a model call, metered in AGENTS.md's most expensive category, and AGENTS.md separately bans timers for babysitting. It must not be adopted on a hunch.

The first is a prerequisite for deciding the second. Ship the sensor, read it, then decide. The activity-versus-existence question — every wait in this repo that survives does I/O, and this one does not — is CLOUD-500, deliberately blocked on this issue for that reason.

What the sensor must distinguish, and how

The hold records why it stopped, not merely when it last ran — absence of an intentional-exit record is the signal, and absence is the one reading robust to losing the tail. Two line kinds in one appended file: h <epoch> <btime> per poll, and x <epoch> <btime> released|capped on an intentional exit. The verdict reads the last line only.

last line	exit	case
h, recorded btime ≠ current	0	a hold was live when this container replaced the last one
x	1	the hold ended on purpose — the un-released window of CLOUD-485, or the cap
h, recorded btime = current	1	this boot's own hold; it spanned nothing
absent, a prior boot recorded	1	disk preserved, no hold was ever armed here
absent, no prior boot recorded	2	fresh container — no local evidence is possible, and saying so is the honest answer
unparseable	2	cannot look; never 0

The residual error is bounded and in the conservative direction: a hold released inside the lost-write window reads as "was live".

The residue probe of the first draft does not work either, and is replaced. It separated the last two rows by whether prior-container residue exists, naming target/ and .git/batten-contract. Measured: every batten-* directory mtime is post-boot on a demonstrably preserved disk, because a directory's mtime updates on each add or remove; and target/ is rebuilt by session-start's build:release on a fresh container too. Recursive file mtimes do stratify — 36 files dated 08-12 against 21 from the 08-06 image bake — but separating those strata needs the bake date, which is not a stable predicate. In its place, session-start appends the current btime to $GIT_DIR/batten-boots once per session. A recorded btime other than the current one proves the disk is preserved, which makes the distinction exact rather than heuristic.

Refinement — Ready

• Source of truth (§1). Two local readings, no network: the hold's own heartbeat file, and the container's boot time (/proc/stat's btime, with uptime -s as fallback). Both are properties of this machine, so the predicate stays a gate rather than a guess. The heartbeat lives at $GIT_DIR/batten-hold-heartbeat — outside batten-holds, because both plan-hold's incumbent-release loop and plan-hold-check live's reaping loop iterate "$dir"/* and delete every file whose first line is not numeric; the <dir>/heartbeat an earlier draft of this clause specified would be eaten on the first check. The path is spelled once, in mise-tasks/plan-hold-check beside hold_dir() — the discipline tests/plan-hold.bats already pins with its "spelled in exactly one place" case, and every other caller asks for it.
• Mechanism as a computable predicate (§2). plan-hold appends h <epoch> <btime> on every poll it already performs — no new loop, no new interval — and x <epoch> <btime> released|capped on each of its two intentional terminal paths. The x record is written only there, never in the trap … EXIT INT TERM, because that is the entire mechanism: a hold killed by the container going down leaves its last line as an h, and no time comparison is needed to see it. Pairing the boot time into each line is what tells this boot's own hold from a previous one's. The heartbeat is never trap-removed. A new plan-hold-check spanned sub-verb (so the path stays spelled once) resolves the table above from the last line. sync -d follows each append — it cannot defeat a snapshot boundary, but it closes the unflushed-cache case for one syscall per poll. Reported once, as a pointer — the verdict and the recorded epoch, never a plan or a prompt body.
• Effect (§3). read. One append per poll to a file under $GIT_DIR, which claim-guard treats as machinery rather than work. No new batten verb and no SURFACE change; the new spellings are sub-verbs of plan-hold-check, whose header usage block and dispatcher error string are the one authority for that list. Growth is bounded — 4 h ÷ 5 s ≈ 2,880 lines ≈ 58 KB — and append is chosen over rewriting a single line because a rewrite can tear at exactly the moment that matters.
• Output & exit contract (§5). The reading is 0 (a hold spanned the restart) / 1 (it did not) / 2 (cannot look), matching plan-hold-check's existing table, with the fresh-container case landing on 2 rather than a false 1. The session-start report is one line, pointer-only, and lands in .claude/hooks/session-start.sh after container-preflight, on a line that never sets fail — a restart verdict must not halt a session. plan-hold itself keeps exit 0 on both terminal paths — it is not a gate and this does not make it one.
• Commit / bump (§6). fix(plan-hold) — patch until 0.1.0.
• Test obligation (§7). Mutation-checked per CLOUD-418, which sets the file layout and not merely the rows: mutant derives its suite as tests/$gate.bats, so the predicate is only gateable once plan-hold-check has its own suite. It gets one — tests/plan-hold-check.bats — following the convention claim-check, land-lock-check and stop-posture-check already keep and this task alone breaks; the existing predicate rows migrate into it, which the bats-tests-not-deleted ratchet permits because its scope is the tree. Both plan-hold and plan-hold-check join MUTANT_GATES. A testability constraint: /proc/stat cannot be faked, so the boot-time reader must be injectable (BATTEN_BOOT_TIME, defaulted from /proc/stat) or no row can discriminate and the suite ships as coverage. Fixture rows for every line of the verdict table, plus: an empty file reads as absent; the report emits one line carrying no plan text; plan-hold-check live does not delete the heartbeat — a regression row for the siting collision above; and an unknown verb exits 2, a dispatch arm with no coverage today that this change adds to. Two rows that are not fixtures, because they are what the mechanism claims: a hold kill -9ed leaves an h as its last line even though its trap runs, and a hold released or capped leaves the matching x. The declared mutations — rewriting the x write to emit h, and collapsing the h/x discrimination in the reader — must turn those rows red.
• Blockers (§8). None. relatedTo CLOUD-500 — the activity-versus-existence hypothesis, which waits on this sensor by design. Relations: CLOUD-451 is the mechanism this grades and its acceptance is the claim in question; CLOUD-485 is the other reason a hold may not be live when it is believed to be, and the two must not be conflated when reading the evidence; CLOUD-425 is the general "a background task cannot be asked what it is doing" gap this is one instance of; CLOUD-388 is the corpus question for any transcript-side reading of the same event, and measurement 1 above is its filesystem instance — a fresh-disk replacement leaves no local corpus either.

Acceptance

• After a container restart, the session can say whether a hold was live when it happened — from a local reading, without a transcript.
• The cases are distinguishable, and the report names which. In particular a fresh container is reported as "cannot look", never as "no hold was live".
• The reading costs no model call and no network.
• The rows fail when the h/x discrimination is removed.
• The verdict does not depend on a heartbeat written inside the lost-write window — the property measurement 4 falsified in the first draft.

Measured in the session that also filed CLOUD-488; the plan whose approval button was destroyed was the one grooming CLOUD-427. The 23:30–23:46 measurements and the empty-hold-directory artifact were added in the grooming session, which was itself restarted twice while doing it.

CLOUD-514 Nothing prices filing over fixing, so spinning off a defect in the PR's own diff is arithmetically cheaper than finishing it

Why

Every gate in this repo prices failing to record something. finding-sink-check fails a turn that cites path:line evidence and makes no durable write. deferral-check fails a PR that defers a decision without naming an issue. stop-guard kicks a hedged flag. issue-guard refuses a PR that names no issue at all.

Nothing anywhere prices the opposite: recording something instead of doing it. Filing satisfies every one of those gates at once and costs a few seconds, while finishing costs a diff, a suite and a landing. For an agent under pressure that is not a temptation, it is arithmetic — and the board becomes the escape hatch every guardrail points at. AGENTS.md already names the behaviour: "A punt is any deferral you could have closed … offering an action you are already authorized to take." That rule is prose, and prose is feedforward only.

Nor is the substitution a fair trade. Across studies of admitted technical debt only 26.3–63.5% of it is ever removed, with median lifespans of 18–172 days and instances surviving more than ten years; in trackers specifically the repayment distribution is severely skewed, median 25 hours against a mean of 872 hours. A ~35× median/mean gap is the signature of a long tail never repaid at all. Filing does not defer a fix, it converts one into a weighted coin-flip.

Measured 2026-08-13, PR #390. CLOUD-513 is a defect in code written in that PR: two new fixture suites read ambient git config, passed verify locally and failed CI. The two suites were repaired in 4259045. The gate — a one-line [tasks."test:bats".env] declaration, in a file the same PR was already editing, whose cost had already been measured at zero (1475/1475 with and without ambient config) — was filed instead of applied. The PR merged green and the board gained a row a one-line edit would have made unnecessary.

No reviewer is present at the moment of the choice, so the cost has to land on the author. Landing here is trunk-based: a branch fast-forwards onto main and review happens after the merge, which is why unreviewed paths stay behind feature flags rather than behind a withheld merge. A mechanism that works by surfacing the punt to a reviewer therefore acts hours or days after the row was opened and the branch was closed. Whatever prices this has to be paid by the author, at the instant of filing, or it is not a price.

Two mechanisms are ruled out before any is proposed

1. Judging the spin-off is forbidden. "Is this issue related enough to the PR to belong in it?" and "should this have been fixed instead?" are both model verdicts, which non-negotiable 3 refuses: a gate resolves to a command and an exit code over an object it decides. CLOUD-505 hit the identical wall, and its resolution is the template — do not judge the content, price the action.

2. A time window is measured, and rejected. The obvious credential-free proxy for "issues this branch filed" is "issues created between the PR opening and its merge". Measured over the last 40 merged PRs against every CLOUD-* created in each window:

merged PRs read:            40
issues created in-window:   184
of those, absent from body: 183   (99.5%)

It fires on essentially everything, and structurally rather than tunably: this repo runs a fleet, so a window captures every session's filings. PR #373's window alone holds 20 issues, none of them its author's. A gate at 99.5% is switched off the first day.

That measurement is what makes a receipt load-bearing rather than convenient. Which branch filed which row has never been recorded anywhere — not in git, not on the PR, not on the board. Without a record the predicate is not merely noisy, it is not computable at all.

Refinement — Ready

Refinement gate: Definition of Ready & Done. This body carries only specializations.

• Source of truth (§1): one record, minted from the tracker's own bytes. .git/batten-receipts/board-writes.<branch>, written by the PostToolUse recorder, holding per board write: the id, the updatedAt the tracker returned, and the ready-lint verdict over the body the tracker returned.

  Why a local record at all, since a local record is what made the first draft forgeable. A gate running inside land is a shell task, and no task in mise-tasks/ has a tracker credential — that is claim-check's "agents fetch, gates decide" split and it is not negotiable here, because land runs unattended in the background and cannot call a connector mid-lap. So the gate can read only local state.

  But exactly one fact is genuinely unfetchable, and the first draft confused that with three. Which rows this branch put on the board is recorded nowhere — not on the row, not in git, not on the PR. Everything else about a row (is it refined, when was it last touched) is a property of the row itself. The first draft therefore specified a separate ready-lint receipt and leaned on the issue-search receipt as evidence, and both were unnecessary ceremony around the one record that is actually needed.

  And the forgeability was self-inflicted. A ready-lint receipt is worthless when the agent assembles the payload it lints. The recorder does not have that problem: it fires on the tool result, which is the tracker's own response to the create and carries the full issue JSON. Linting that body, and recording the updatedAt beside the verdict, is evidence the author never touched. No second receipt, and no dependency on making a separately-minted verdict trustworthy.

• Mechanism as a computable predicate (§2): three sinks, priced in ascending order, and chat is not one of them. A finding met mid-PR has exactly three legitimate destinations, and the gate's whole job is to make the cheapest one the one that finishes the work.

  1. Fix it in this PR. Costs a diff. Nothing to record, nothing to gate, and this is deliberately the cheapest path.
  2. A durable comment on the existing row that owns it. Recorded, and otherwise unpriced. The first draft demanded a search receipt naming the target, on the theory that the row should have been found by looking rather than recalled — which buys nothing: an unfiltered list_issues (optional query, limit up to 250) mints a receipt naming 250 rows, and no receipt can tell a right target from a wrong one anyway. Commenting on the row that already owns a finding is the honest common case and the friction belongs elsewhere. Filing remains gated by issue-search-guard, which is where duplicate-prevention lives.
  3. A new row, groomed to Ready. The recorder lints the body the tracker returned; the gate refuses at land time if that verdict was not green. Costs a search (already required by issue-search-guard) plus a complete Ready block: source of truth, computable predicate, effect, output contract, commit type, test obligation, blockers.

  Sink 3 is deliberately more expensive than most fixes, and that is the entire mechanism. A one-line [tasks."test:bats".env] declaration takes minutes; a Ready block for it takes considerably longer. So the arithmetic that currently favours filing reverses, without anything having to judge whether a given spin-off was lazy.

• Raising the filing bar is measured to work, in both directions (§2). Where a tracker imposes a structured filing template, monthly incoming volume falls while what survives gets better: median resolution time drops from 381 to 103 days, comment counts from 4.95 to 4.32, and more strongly structured templates further reduce resolution time, reopenings and discussion length. Fewer rows and faster ones is the same effect from both ends, and it is why the price is a Ready block rather than an arbitrary toll.

• The friction must sit only on the impulsive path (§2). Deliberate friction is legitimate where it prevents an impulsive choice and illegitimate where it obstructs something needed. So: sink 2 stays cheap, since commenting on the right row is the common honest case; sink 3 is expensive but never refused, since a genuinely new finding must always be recordable; and every gate here fails open on anything it cannot establish. A gate that made recording a real finding hard would cause the failure finding-sink-check exists to catch.

• The recording half must be PostToolUse, not PreToolUse (§2). At PreToolUse a created row has no id yet; the tool result carries it. Measured, because no hook in this tree had ever read a tool result and the documented example is a Write with a flat response. For an MCP tool the result is the content-block envelope, so .tool_response.id does not exist — the recorded shape is [{"type":"text","text":"<the issue JSON as a string>"}], and the key is reached with .tool_response[]? | select(.type=="text") | .text | fromjson | .id. The text carries the entire issue body, so the recorder must extract the id and nothing else (non-negotiable 4). .claude/settings.json already runs a PostToolUse entry, so the event is available and the shape is proven. The body records both a create and a comment — a comment is sink 2 and must be attributable to the branch too — appending to .git/batten-receipts/board-writes.<branch>. It reuses issue-search-guard's decided details rather than re-deriving them: the create-vs-update discriminator (.tool_input.id absent) and the suffix-anchored matcher, since CLOUD-178 measured three live spellings of the same connector and a rule naming one silently matches none of the others.

• The recorder calls ready-lint; ready-lint itself is unchanged (§2). It is already a pure function of a piped payload and already the authority on a Ready block, so the recorder pipes it the tracker's returned body and stores the verdict. A hook shelling out to a task is normally the cost this repo refuses — but that argument was measured against a PreToolUse firing on every Bash call, and this fires only when a row is created, which is rare enough that the startup cost is irrelevant.

• The gating half is filed-here-check (§2), called from land beside deferral-check and stopping the lap the same way. For every create this branch recorded, the stored ready-lint verdict must be green. Comments are recorded and not gated. It judges no content and reads no tracker.

• Do not reuse claimed-keys for any body read (§2). It narrows to closing keywords because it answers which issues does this PR claim, and claiming would demand the PR close the spun-off row — precisely wrong for a genuinely unrelated one. CLOUD-379 and CLOUD-384 record the two being conflated in the other direction.

• Ship the recorder first, then the gate (§2). The firing rate cannot be estimated retrospectively — the discriminating data has never existed, which is the finding above. The recorder lands alone and is observed for a bounded period; the gate turns on against a receipt corpus that exists. Turning on an unmeasured gate is what the 99.5% measurement argues against.

• Effect (§3). read. A PostToolUse body writing under $GIT_DIR — machinery, as claim-guard's receipt already is — plus a task reading stdin and receipts, plus one receipt write added to an existing task. No new batten verb and no SURFACE change.

• Output & exit contract (§5). deferral-check's, unchanged: non-zero stops the lap, pointer-only per non-negotiable 4 — the ids and the missing receipt, never an issue title or body. The recorder is silent on every path and fails open on an unparseable payload, a missing git dir or a detached HEAD.

• Commit / bump (§6). feat(hooks) — patch until 0.1.0 regardless of type.

• Test obligation (§7). One suite per gate, because mutant derives its suite as tests/$gate.bats; #MUTANT rows in each and every name added to MUTANT_GATES.

  Shown able to fail in both directions (CLOUD-418): a recorded create with no ready-lint receipt fails, and passes once the row is refined; a create whose recorded verdict is green passes; a recorded comment is never gated. Plus the rows that keep it from obstructing the needed path — a branch with no recorder output at all passes, an empty record passes, an update to an existing row is never recorded, and a fix-with-no-board-write passes untouched, which is the path the design wants to be cheapest.

  The regression case is this session: CLOUD-513 recorded against PR fix: the fast-forward verdict reaches land, and filing joins the gated paths #390 with no Ready receipt at filing time is refused, and passes once groomed.

• Blockers (§8). None. relatedTo CLOUD-512 — it gates the move to In Review and explicitly excludes the attachment gap this closes as a side effect; CLOUD-323 and CLOUD-338 — deferral-check, the template and the record of its exemption logic being got wrong; CLOUD-505 — the search receipt this consumes; CLOUD-475 — finding-sink-check, the gate that prices under-recording and the reason nothing prices over-recording; CLOUD-513 — the measured instance.

Chat is not a fourth sink, and that is a memory property rather than a style rule

A finding stated in prose and never written durably is context-resident state. Long-horizon agents lose exactly that: unbounded context forces truncation and summarisation, attentional dilution degrades recall of any single item as context grows, and material in the middle of a long context is recalled least reliably — which is why an external store holding raw records at full fidelity is the standing recommendation. So a finding left in an aside is not merely undocumented, it is predictably lost, and the container reclaim this session survived is only the abrupt version of the same thing. finding-sink-check already gates this and needs no change here; it is named so the three sinks above are not read as four.

How this gets satisfied without doing the work

Three, found by attacking the mechanism rather than reasoning about it, each with local evidence. Two are closed above by changing the design; the third is a residual, stated with its failure direction.

A ready-lint verdict is forgeable if the agent supplies the payload — closed by moving the lint into the recorder, which lints the tracker's response instead. The finding stands and is why §1 reads as it does; the original remedy (a second receipt, made trustworthy elsewhere) was the wrong fix for it.

The measurement that made the hole real. ready-lint reads a payload the caller assembles. Run against this very issue three times while it was being refined — twice from a local file, once under the literal id CLOUD-NEW for a row that did not exist — it was green every time. So a receipt would attest that some text linted clean under some id, while the filed row is a stub. A toll payable in text nobody filed is not a toll. The first remedy drafted for this was a second receipt made trustworthy elsewhere, which added a dependency instead of removing the hole; moving the lint into the recorder — where the input is the tracker's response rather than anything the author typed — removes it. The same forgery argument is made independently by CLOUD-431 for its own question, which is why that issue is worth reading beside this one.

An unfiltered listing launders sink 2 — closed by dropping the requirement, because it bought nothing. list_issues takes an optional query and a limit up to 250, so a receipt demanding that the comment target be named is satisfied by one no-query call. Nor could any receipt tell a right target from a wrong one. Sink 2 is now recorded and unpriced.

The record survives a branch restart — and that is fail-closed here, which is why it is a residual and not a blocker. claim.<branch> on the branch this issue was written on names CLOUD-230, a claim from an earlier incarnation of the same branch name that outlived two checkout -B … origin/main restarts. The record proposed here is keyed the same way, so it inherits the staleness — but not the failure direction, and that distinction was missed on the first pass. There the defect is a false pass: claim-guard waved through every edit all session on expired evidence. Here a stale entry can only add rows the gate insists on checking; it can never remove one, since a restart does not delete the record and the new branch's own creates are appended fresh. So the worst case is a refusal naming a row from a previous incarnation, whose remedy the refusal message already gives. A gate that fails closed on stale state is the outcome this repo prefers, so the dependency was withdrawn. CLOUD-516 fixes the underlying keying and is worth landing first for its own reasons, but nothing here waits on it.

What this cannot do

It cannot judge the reason, and a minimal-compliance path still exists — a Ready block written to satisfy ready-lint rather than to be worked. The gate cannot refuse that without scoring prose, which is the model verdict rule 3 forbids. But the floor is now a complete Ready block rather than a pasted key, so the cheapest way to satisfy it is close to the work the row actually needs. Re-open predicate: re-open if the observation window shows Ready blocks on spun-off rows systematically shorter or thinner than on rows filed outside a branch.

Gating creates pushes pressure toward commenting instead, and that is accepted rather than fixed. A comment on the row that already owns a finding is a legitimate durable home — cheaper than filing by design, since the friction is meant to sit on the impulsive path and not on honest recording. What makes it acceptable is that the pressure runs toward recording in the right place, not toward silence. It is still recorded, so the ratio is observable: CLOUD-475 records that a comment already counts as a durable home. Re-open predicate: re-open if the observation window shows spin-off comments rising while spin-off creates fall and fixes do not, which is the signature of the toll being routed around rather than paid or avoided.

Acceptance

• A row created while a branch was live is refined at creation, on the evidence of the tracker's own response, and the lap stops otherwise.
• Fixing costs less than filing, and the acceptance is arithmetic rather than opinion: the cheapest path through the gate for a defect in the branch's own diff is to fix it.
• A genuinely new finding is never refused a durable home, and a comment on the right existing row stays cheap.
• No similarity comparison and no quality score exists anywhere in the mechanism.
• The recorder ships and is observed before the gate is enabled, and four numbers are recorded here from that window rather than carried from other corpora: the firing rate, the split across the three sinks, the fraction of spun-off rows subsequently resolved, and the friction cost the gate imposed on honest recording.

Not in this issue

Deciding whether a given spin-off was legitimate — the judgement the gate must never make. The In Review transition gate, which is CLOUD-512's. And retrofitting receipts for branches predating the recorder, which is why the gate fails open on their absence.

Review in Linear

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
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