Repository navigation
feat(hooks): price the punt — a row this branch filed must have been groomed (CLOUD-514) - #523
Conversation
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. 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 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 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 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.
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. 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. An unfiltered listing launders sink 2 — closed by dropping the requirement, because it bought nothing. The record survives a branch restart — and that is fail-closed here, which is why it is a residual and not a blocker. What this cannot do It cannot judge the reason, and a minimal-compliance path still exists — a Ready block written to satisfy 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 a branch's own record shows comments standing in for fixes to defects in that branch's own diff — readable per branch at land time, which is the only scope available, since no cross-session window exists. Acceptance
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. 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 Measured 2026-08-12, ~22:12 UTC. A hold was armed ( So the container went down with four live tracked tasks, one of them a full 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. A session was demonstrably alive at 23:28 — this issue's own last edit — and nothing it wrote survived anywhere writable. 2. The 23:45 boot preserved the disk. Same appearance from inside, opposite consequences. A heartbeat file under 3. The surviving hold directory was empty. 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, So the first draft's predicate — 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:
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:
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 Refinement — Ready
Acceptance
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. |
|
Warning Review limit reached
Next review available in: 11 minutes Limit details: You’ve used all 3 included reviews currently available. Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits within each organization. For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (6)
Comment |
9f7bb85 to
29f3e5c
Compare
…groomed `board-write-record` landed as the sensor half of CLOUD-514 and gates nothing. Shipping a sensor alone is normally the "log without a gate" non-negotiable 2 refuses; the exception was conditional on the gate following, and the issue was closed at the halfway point instead. This is the half that was owed. `filed-here-check` reads the recorder's own file under `$GIT_DIR`, keyed to the branch, and refuses when a row this branch CREATED carries a stored `ready-lint` verdict of `unready`. `land` calls it beside `deferral-check` and stops the lap the same way: that gate prices a decision left with no home, this one prices a home opened instead of a fix. Three states, not two. `ready` passes, `unready` refuses, and `-` — the recorder could not lint, because `ready-lint` exited 2 or could not run at all — passes. Reading "not answered" as "refused" would turn a verdict about the environment into a verdict about the row, the confusion the recorder's own three-way status read already exists to avoid. Comments are recorded and never gated. A comment on the row that already owns a finding is sink 2 and the honest common case; pricing it would push the pressure toward silence, which is the failure `finding-sink-check` exists to catch. It judges no content and reads no tracker: no similarity comparison, no quality score, no tracker credential — `claim-check`'s agents-fetch-gates-decide split. The verdict it compares was minted by the recorder over the tracker's own response to the create, which is what keeps it unforgeable by the author. Fails open on everything it cannot establish — outside a checkout, a detached HEAD, an absent or unreadable record. A branch predating the recorder has no file and cannot be given one: the store lives under `$GIT_DIR`, is never committed, and dies with the container. The issue's acceptance bullet 5 promised four numbers from an observation window over that store. It is unsatisfiable and was replaced rather than filled: the record is per-clone, so no fleet-wide corpus can accumulate. The gate's deployment safety is structural instead — one branch's record, read inside the session that wrote it, fail-open on absence. `tests/filed-here-check.bats` covers both directions (CLOUD-418): an unrefined create stops the lap and the same row passes once refined, a comment is never gated, `-` is not a refusal, and the fix-with-no-board-write path is untouched. Three `#MUTANT` rows, and `land.bats` gains the stop plus its counter bump. Closes CLOUD-514
…s with The rule ships with its mechanism: `filed-here-check` lands in the same change, so the guard list that already carries `deferral-check` carries its sibling — the two are one pair, one pricing a decision left with no home and the other a home opened instead of a fix. Refs: CLOUD-514
`mutant` filters bats cases by substring, so a filter that is not one selects nothing and the mutation reports names-no-case rather than a caught row — a declared mutation that proves nothing, which is the failure `mutant` exists to catch, reached through its own declaration syntax. Refs: CLOUD-514
29f3e5c to
9575991
Compare
|
|
/fast-forward |
1 participant
CLOUD-514 phase 2: the gate the sensor was shipped to make specifiable
board-write-recordlanded in #399 (corrected in #418) as the sensor half andgates nothing. Shipping a sensor alone is normally the "log without a gate"
non-negotiable 2 refuses; CLOUD-514 argued for a conditional exception — the
gate's firing rate is not computable until the record exists — and named the gate
as what follows. The issue was then closed at the halfway point, so what landed
was the exception without the condition. This is the half that was owed.
What it does
mise-tasks/filed-here-checkreads the recorder's own file under$GIT_DIR,keyed to the branch, and refuses when a row this branch created carries a
stored
ready-lintverdict ofunready.landcalls it besidedeferral-checkand stops the lap the same way: that gate prices a decision left with no home,
this one prices a home opened instead of a fix.
The arithmetic it reverses: every other gate here prices failing to record
something, so filing satisfies all of them in seconds while finishing costs a
diff, a suite and a landing. Making the new row cost a complete Ready block flips
that, without anything judging whether a given spin-off was lazy.
readypasses,unreadyrefuses, and-— therecorder could not lint, because
ready-lintexited 2 or could not run at all —passes. Reading "not answered" as "refused" would turn a verdict about the
environment into a verdict about the row.
owns a finding is sink 2 and the honest common case; pricing it pushes the
pressure toward silence, which is the failure
finding-sink-checkexists tocatch. Friction belongs on the impulsive path only.
quality score, per non-negotiable 3. The verdict it compares was minted by the
recorder over the tracker's own response to the create, which is what keeps it
unforgeable by the author —
ready-lintover a caller-assembled payload wasmeasured green three times against text in a local file, once under an id no row
carried.
unreadable record. A branch predating the recorder can never have one.
The acceptance bullet that was replaced, not filled
The issue promised four numbers from an observation window over the record. That
promise is unsatisfiable and is now removed from the body: the store lives under
$GIT_DIR, is never committed, and dies with the container, so no fleet-widecorpus can accumulate and none ever could. Measured on this clone: one file, nine
rows, all from the session that wrote the recorder — zero creates, nine comments.
What replaces it is a structural bound rather than a number: the gate reads one
branch's record inside the session that wrote it, judges only creates, and fails
open on absence, so a wrong verdict costs one lap on one branch and its remedy is
in the refusal message.
Tests
tests/filed-here-check.bats— 16 rows, both directions per CLOUD-418: anunrefined create stops the lap and the same row passes once refined; a comment is
never gated;
-is not a refusal; the fix-with-no-board-write path is untouched;slash-bearing branch names resolve to the recorder's spelling.
#MUTANTrows, andfiled-here-checkadded toMUTANT_GATES.tests/land.batsgains the stop and its counter bump (28 → 29); 127/127.Dependency, named rather than fixed here
CLOUD-513 is still Todo and its fix is still absent from
main— no[tasks."test:bats".env]block, zeroBATTEN_*_BYPASSreferences. That is thereason a suite can go green with its guard disabled, which is how an earlier run
of this work was mis-measured. It is out of scope for this branch and enters
through its own plan.
Closes CLOUD-514