Decide: shrink-only delta-ratchet for check-durability-degradation-log-level — measured at 0 net decreases/month over 3,195 commits

[claude]

Follow-on from #9747 / PR #9875, filed by the domain:devx PM seat under ruling Q1 → A. The pilot was explicitly ruled visibility-only, no new merge-blocking failure, so PR #9875 measured this and did not build it. The numbers below are the whole point: this card starts priced, not speculative.

The measurement

Method: each commit's changed files replayed through the gate's own recognizer (a copy of the gate file, proved byte-identical above its CLI epilogue at build time). Window: 3,195 first-parent commits on origin/main, 2026-07-19 → 2026-08-19.

⚠️ That window is the deepened count. Agent containers start from a 63-commit shallow clone (#9878), which is why an earlier measurement of the same window reported 269.

check-durability-degradation-log-level:

keying	commits changing the set	keys entering	keys leaving
file	9 (0.28%)	—	—
file + callee	12 (0.38%)	12	1

The single leave — packages/runtime/src/http-dispatcher.ts::saveMetaItem at 8891f9394 — is a cross-file move: the seam entered packages/runtime/src/domains/meta.ts in the same commit. Repo-wide total 1 → 1.

⇒ 0 net legitimate decreases per month. This reproduces #9680's zero on a different rule.

What that means

A shrink-only delta-ratchet on this rule is free — the population only grows, so the ratchet would have reddened CI zero times in the last month. That is the same profile that justified the ratchet in PR #9712 for check-engine-double-contract.

⛔ Why this is NOT a general "ratchet the family" card

The sibling rule in the same gate measures the opposite way, and PR #9875's central finding is that the nuisance rate is a property of the POPULATION, not of the proposal:

rule	keys enter / leave	commit-level net losses that would redden CI
durability log-level	12 / 1 (a move)	0 / month
durability read-seam	25 / 15	10 / month — one red every 2–7 working days

The read-seam losses are genuine deletions, and their commit subjects say so: "remove the unreachable legacy raw-engine save path" (−3), "retire sys_fetch_previous_delete" (−1), "four read seams that failed no longer answer from …" (−1).

⇒ Ratcheting must be decided per rule, on measurement. Do not widen this card to the read-seam rule; on today's numbers that would ship a nuisance.

The decision this card needs

Building it means adding a merge-blocking failure mode, which is why it is not a dev card yet:

• A — build the shrink-only ratchet on the log-level rule. Free on today's numbers. Cost: a new way for CI to go red, and a maintenance surface when a seam is legitimately deleted (~0×/month, but not never).
• B — do not build it. The rule's population is 29 seams, small enough to eyeball; the UNRECOGNISED line PR feat(gate): give the three pilot gates an UNRECOGNISED verdict distinct from clean #9875 shipped already makes drift visible without blocking anything.
• C — re-measure in a month and decide then. The replay method is cheap and reusable, so the cost of waiting is near zero — and one month of data on a repo doing ~3,200 first-parent commits/month is a thin base for a permanent merge-blocking rule.

My read: C, then A. The measurement is real but single-window, and the visibility line shipped in #9875 covers the interim. Nothing is currently going undetected, so the urgency that would justify A-now is absent.

⚠️ If A is chosen, keying matters: file-only keying reports the cross-file move above as a false decrease. Key on file + callee or the ratchet will redden on a refactor that changed nothing.

Refs: #9747 (family) · PR #9875 (the measurement) · #9680 / PR #9712 (the same ratchet, engine doubles) · #9878 (why an earlier count said 269).

---

Ruled 2026-08-19 — option C (maintainer, via the maintainer-directed PM session; see the ruling comment for the full record). Held on the restart criterion below.

Restart-when: today >= 2026-09-19 — re-run the PR #9875 replay measurement over the fresh window; if net legitimate decreases are still 0/month, promote to pm:queue and build the shrink-only ratchet (ruling A), keyed file + callee.

[os-elon]

Maintainer ruling — recorded by the maintainer-directed PM session (session_01KspKtTajJmy3J37UhH8tcH, 2026-08-19). The full decision-inbox review (11 cards, four-axis analysis each) was presented to the maintainer in that session's chat; the maintainer's verbatim reply: 「接受你的所有建议。」. The adopted recommendation, restated in full:

Ruling: Option C — re-measure in a month, then A if still zero

• Do not build the ratchet now. One window of data (3,195 first-parent commits) is a thin base for a permanent merge-blocking rule, and nothing is currently going undetected — the UNRECOGNISED visibility line shipped in PR feat(gate): give the three pilot gates an UNRECOGNISED verdict distinct from clean #9875 covers the interim.
• Restart criterion (machine-readable line added to the body in this same pass): after 2026-09-19, re-run the PR feat(gate): give the three pilot gates an UNRECOGNISED verdict distinct from clean #9875 replay measurement over the fresh window. If net legitimate decreases are still 0/month, promote to pm:queue and build the shrink-only ratchet (option A).
• If/when A is built: key on file + callee — file-only keying reports the measured cross-file move (http-dispatcher.ts::saveMetaItem → domains/meta.ts) as a false decrease.
• The card's scope fence stands: this ruling covers the log-level rule only. The read-seam sibling measures 10 nuisance reds/month on today's numbers and is ⛔ not to be ratcheted on this card.

State: decision made, answer is "not now" ⇒ needs-user-decision → pm:on-hold with the Restart-when: line as the exit. Hold source: this maintainer ruling, 2026-08-19.

---

Generated by Claude Code