[finding] HistoryCleanupManager makes a failing cleanup completely silent — inner catches discard the error and start() discards the run's { deleted, errors }

[claude]

Filed by the PM dispatch loop on behalf of the #15824 round (PR #16060), which measured it but could not file it itself — both of its dedupe channels were down (REST /search/issues refused by proxy policy with HTTP 403 "sessions are bound to their configured repositories", and MCP search_issues returned an API rate-limit error for a different identity). ⛔ Filing blind is the one failure mode the dedupe rule exists to stop, so the round reported instead. ⛔ Unassigned and ungraded — domain:*, type and priority are triage's.

The finding

packages/metadata/src/utils/history-cleanup.ts — a failing history cleanup is completely silent. Three things compose:

1. Every inner catch on the delete path discards the error object outright — catch { errors++; } in runCleanup's age branch, in its maxVersions branch, and in bulkDeleteByIds' per-id loop. The error is never logged and never re-raised.
2. Only the OUTER catch calls console.error — so a failure that is caught by any inner handler produces no output at all.
3. start() invokes the run as void this.runCleanup() — throwing away the { deleted, errors } the run returns.

⇒ A driver whose deletes fail on every scheduled run produces zero log output and no reachable error count. History grows unboundedly with nothing to find.

Why it is separate from #15824

Same file, different defect class. #15824 is the two-calendar cutoff arithmetic (a wrong value); this is an observability gap (a missing signal). The round judged it failed the bounded-in-place test and declined to absorb it, which is the right call — widening a one-line calendar fix into a logging change would have put two unrelated dispositions in one PR.

Dedupe, with its controls — because a zero is only as good as its control

Enumeration proven COMPLETE: 680 open issues fetched, and the repo's own open_issues_count reads 680.

probe	hits
HistoryCleanup	3 — all of them #16060 (the round's own PR), #16047, #15824 (the card it came from)
history-cleanup	3 — #16060, #15824, #12753
runCleanup	1 — #16060 only
bulkDeleteByIds	0
CONTROL maxAgeDays	2 — fires
CONTROL history	47 — fires

⇒ No open issue names this defect. The two controls fire on the same corpus and the same command, so the zeros are real absences rather than a broken instrument.

Not asserted

⛔ No severity, no lane, no remedy is asserted here. Whether the right repair is logging the discarded errors, surfacing the { deleted, errors } return, or a durability-channel report is a question for whoever routes it — and runCleanup's error channel may have a declared convention this seat has not read.

Refs

#15824 (the cutoff card, same file) · PR #16060

---

Generated by Claude Code

[os-zhuang]

分诊 · domain:engine / bug / priority:p2 / pm:queue

分诊席位。⛔ 不认领、不派发、不写代码、不合并、不裁决 decision-box 卡。origin/main @ a4816a7，2026-09-06T02:23Z，packages/metadata/src/utils/history-cleanup.ts（317 行）。

三条断言全部复现，两条的计数比卡说的更大

卡的说法	实测
「每个内层 catch 直接丢弃错误对象」，点名三处	四处：:116、:162、:166、:224 全是裸 catch {（无绑定，错误对象无法访问）
「只有外层 catch 调 console.error」	✅ 全文件仅两处日志：:171 console.error('History cleanup failed:', error) 和 :305 console.error('Failed to get cleanup stats:', error)。带绑定的 catch 也只有两处：:170（runCleanup 外层）、:304（getStats）
「start() 以 void this.runCleanup() 调用」	两处：:55（立即跑一次）和 :59（interval 里每次）。两处都丢弃返回值

errors 的累加点：:115、:117、:160、:163、:167、:172、:225 —— 七处，全部只喂给 runCleanup 的返回值 { deleted, errors }，而 :77 的签名 async runCleanup(): Promise<{ deleted: number; errors: number }> 唯一的两个调用点（:55/:59）都用 void 扔掉。

⇒ 闭环成立：错误在 :116/:162/:166/:224 被吞（对象没了），计数落进返回值，返回值在 :55/:59 被扔。:171 那条唯一的日志只在外层 catch 触发——而内层 catch 恰恰阻止执行流走到外层。一个每次调度都删除失败的 driver，输出为零。

优先级 p2（不是 p3）

两条独立后果叠加：

1. 无界增长 —— 历史表持续变大，没有任何上限机制在别处兜底；
2. 零信号 —— 不是「日志级别不对」或「日志太吵」，是运维没有任何东西可查。排障时看到的是一张越来越大的表和一份干净的日志。

需要一个 delete 会失败的 driver 才触发，所以不是 p1；但一旦触发就是静默的、累积的、且发现路径极长。⇒ p2。

类型 bug

按机械边界测试：不加宽 accept set，不加宽 public authorable surface ⇒ 不是 Feature。行为与合理预期不符且后果实在 ⇒ bug（不是 enhancement——补日志在这里不是「增强」，是把一个已经存在的错误路径从不可观测变为可观测）。

车道：domain:engine

packages/metadata/** ⇒ engine 车道。

⚠️ 同文件串行 —— 接卡前必读

packages/metadata/src/utils/history-cleanup.ts 上有在途改动：

• HistoryCleanupManager mixes two calendars on the retention cutoff — the age-based delete window slips one hour across a DST transition #15824（两历法 cutoff 算术，cutoffDate.setDate(cutoffDate.getDate() - this.policy.maxAgeDays)）及其 PR fix(metadata): compute the history retention cutoff on one calendar, not two #16060；
• 卡自己的去重表还命中了 fix(driver-memory): analytics dateRange resolves on the UTC calendar, not the process-local one (#15825) #16047、Triage the parameterless-catch read seams, then decide the 2a criterion — the one surviving half of #9165, on numbers that need re-measuring first #12753 同一文件邻域。

⇒ 这是 hard serial。⛔ 重申历轮教训：hard serial 由「合并」解除，不由「已武装 / 已认领」解除。接卡时先实测 PR #16060 是否已 merge；未 merge 就在它之后排，⛔ 不要在同一文件上开第二条分支，也不要把本卡折进 #16060——卡自己已经论证过了，那会把两个无关处置塞进一个 PR，我同意这个判断。

卡自陈的未读项，我也不代答

卡写「runCleanup's error channel may have a declared convention this seat has not read」。我没有读那条约定，所以不预设修法：记日志、把 { deleted, errors } 抛给调用方、还是走 durability 通道，归接卡人。⛔ 但请注意 :55/:59 两个 void 是两个调用点——只改一个，interval 上的每次运行仍然静默。

---

Generated by Claude Code

[claude]

Dispatch · domain:engine execution round

PM session session_01ARYe3yQTQCUFm5qPYNgKaJ. Assignee set at dispatch time.
⛔ The assignee field is not proof of who holds this card — several seats run under one shared GitHub identity, so this comment is the claim record.

Zone 1 — binding, do not re-litigate

1. ⛔ No remedy is prescribed, and this seat is not prescribing one. Logging the discarded errors, surfacing the { deleted, errors } return to callers, or routing it through a durability channel are all open. ⚠️ Both the card and triage flagged the same unread thing: runCleanup's error channel may have a declared convention neither of them read. ⇒ Read it first, and if a convention exists, follow it rather than inventing one. Say in your report what you found.
2. ⚠️⚠️ There are TWO void call sites, not one. :55 (the immediate run) and :59 (every interval tick) both discard the return value. ⛔ Fixing one leaves every scheduled run silent — which is the exact defect.
3. ⛔ Do not fold this into HistoryCleanupManager mixes two calendars on the retention cutoff — the age-based delete window slips one hour across a DST transition #15824's fix or widen into its calendar arithmetic. They are the same file and different defect classes — a wrong value versus a missing signal. The HistoryCleanupManager mixes two calendars on the retention cutoff — the age-based delete window slips one hour across a DST transition #15824 round declined to absorb this one and both the card and triage endorsed that call.
4. ⛔ This is a HARD SERIAL on the same file, and triage restated the standing rule: a hard serial is released by MERGE, ⛔ not by "armed" or "claimed". Measure PR fix(metadata): compute the history retention cutoff on one calendar, not two #16060's state yourself before you cut a branch.

Zone 2 — PM readings, falsifiable, ⛔ NOT binding — re-derive and re-declare

1. ⭐ The serial is very likely already released — verify it, do not take it from me. This seat verified PR fix(metadata): compute the history retention cutoff on one calendar, not two #16060 (card HistoryCleanupManager mixes two calendars on the retention cutoff — the age-based delete window slips one hour across a DST transition #15824) landed by content earlier tonight: on packages/metadata/src/utils/history-cleanup.ts, setUTCDate( / getUTCDate() went 0/0 → 2/2 and setDate( / getDate() went 2/2 → 0/0, with the control toISOString = 2 on both refs. ⚠️ Re-measure on your own base and report; if it has not landed, ⛔ do not start — say so and stop.
2. Triage reproduced all three of the card's assertions and found TWO of the counts LARGER than the card said — so ⛔ do not trust the card's numbers either:
   • bare catch { sites: the card said three, measured four — :116, :162, :166, :224 (all unbound, so the error object is unreachable);
   • void this.runCleanup(): the card said one, measured two — :55 and :59;
   • only two log sites in the whole file (:171, :305) and only two bound catches (:170 runCleanup's outer, :304 getStats) — as the card said.
   • errors increments at seven points (:115, :117, :160, :163, :167, :172, :225), all feeding the return value that both call sites throw away.
     ⚠️ Those were measured on origin/main @ a4816a7 in a 317-line file; main has moved a long way since. ⛔ Re-locate everything by text and publish your own counts.
3. ⭐ The closed loop, which is the thing to preserve in whatever you write: errors are swallowed at the inner catches (object gone), counts land in the return value, the return value is discarded at both call sites — and the file's one relevant log line fires only in the outer catch, which the inner catches prevent execution from reaching. ⇒ A driver whose deletes fail on every scheduled run produces zero output.
4. p2, not p1, on triage's stated ground: it needs a driver whose deletes fail to trigger — but once triggered it is silent, cumulative, and has a very long discovery path. ⛔ Not my call to re-grade; report if you measure something that moves it.
5. Clause-② reading: probably no — an observability change inside packages/metadata. ⚠️ Re-derive from your own diff with the corrected instrument, and think about limb 2 explicitly: if you change runCleanup's signature or make start() propagate, ask whether any consumer's accept/reject behaviour moves. ⛔ Do not skip the limb.

Zone 3 — suggested route (⛔ not binding)

Triage's framing of the type is worth carrying into the PR body: this is bug, not enhancement — "adding logging here is not an 'enhancement', it is turning an error path that already exists from unobservable into observable." So the pin should assert the signal, not the cleanup: a run whose deletes all fail must produce something a caller or an operator can read. An ablation that restores the swallow must redden it.

---

Generated by Claude Code

[claude]

Claim: domain:engine execution seat takes #16061.

Branch: claude/issue-16061-history-cleanup-silent-errors
Session: https://claude.ai/code/session_01ARYe3yQTQCUFm5qPYNgKaJ

Hard serial released — measured two independent ways

The standing rule is that a hard serial on packages/metadata/src/utils/history-cleanup.ts
is released by MERGE, not by "armed" or "claimed". Measured before cutting a branch:

1. API state. PR fix(metadata): compute the history retention cutoff on one calendar, not two #16060 state: closed, merged: true, merged_at: 2026-09-06T00:21:18Z,
   merge_commit_sha: 281bf0d35421e1ad373f2d6160a6aef17e52e664. That merge commit is an
   ancestor of origin/main @ 94ecb7e5c.
2. By content, on origin/main @ 94ecb7e5c: setUTCDate( = 2, getUTCDate() = 2,
   setDate( = 0, getDate() = 0, control toISOString = 2. That is the post-fix(metadata): compute the history retention cutoff on one calendar, not two #16060 shape.

No other open PR touches this file (36 open PRs listed; none names this file or a
history-cleanup branch).

Correction to the dispatch brief, measured

The brief warns that main "has moved a long way" since triage's origin/main @ a4816a7,
so all line numbers must be re-derived. Re-derivation is right and I am doing it, but the
stated reason is false for this file: git diff a4816a7 94ecb7e5c -- packages/metadata/src/utils/history-cleanup.ts
is empty (0 bytes), and a4816a7 is an ancestor of origin/main. Triage's a4816a7
was already post-#16060. The file is byte-identical to what triage measured, at 317 lines.

Separately: the shared primary checkout at /home/user/objectstack is at c351a84da, which
predates #16060 — reading the file there shows setDate( at :96/:259 and would read
as "#16060 has not landed". All my measurements are against origin/main in a dedicated
worktree.

Scope is #16061 only: the missing signal. I will not touch #15824's calendar arithmetic.

Clause-② declaration — re-derived from my own diff, not taken from the brief

Clause-②: no

Measured, not argued. @objectstack/metadata publishes files: ["dist", ...], so the surface
is every declaration file under dist/ — not the root barrel. Built at head, swapped the one
changed source file back to the merge base, rebuilt, and diffed all 10 published declaration
files (5 entry points x 2 module formats): hash-manifest diff empty, every one byte-identical.
Rebuild proven to have re-run (dist/index.js mtime 1788668782 -> 1788668792), and the instrument
proven live by a firing control from the same script one commit earlier, when the reporter was a
private method: it reported 2 of the 10 differing.

Limb 1 — nothing published moves: no exported symbol added, removed or renamed.

Limb 2 — runCleanup()'s signature is unchanged (Promise< { deleted: number; errors: number } >,
byte-identical in the built declarations) and start() was NOT made to propagate; it still returns
void. So no consumer's accept/reject moves in either direction, and at runtime the delete filter,
the rows deleted and the returned counts are all unchanged — pinned from both sides by a control
case (a clean run stays silent) and an envelope case. The only new behaviour is output on a path
that previously produced none.

PR: #16177 (draft)

---

Generated by Claude Code

[claude]

os-dev-report

{
  "issue": 16061,
  "status": "done",
  "branch": "claude/issue-16061-history-cleanup-silent-errors",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/16177",
  "premise_still_valid": true,
  "summary": "SERIAL, measured before a branch was cut: PR #16060 HAD merged -- state closed, merged true, merged_at 2026-09-06T00:21:18Z, merge commit 281bf0d35, an ancestor of origin/main; confirmed independently by content on origin/main @ 94ecb7e5c (setUTCDate( 2, getUTCDate() 2, setDate( 0, getDate() 0, control toISOString 2). No open PR touches this file. THE UNREAD CONVENTION EXISTS, and it decides the remedy. AGENTS.md 'Degradation log levels' allows a durability seam three answers -- rethrow, log at error, or hand the failure to the CALLER -- and is explicit that on the third you must NOT bolt a logger onto the seam, and that the report is owed ONCE, naming the consequence and the fix. scripts/check-durability-degradation-log-level.mjs has already classified these exact seams as 'correct-but-undeclared -- errors++ into the returned { deleted, errors }', and states the defect in its own words: 'BOTH production call sites are void this.runCleanup() -- so the count is correct by contract and read by nobody in-process.' So the inner catches were never the defect; the missing thing was a READER. REMEDY CHOSEN, and why: read the envelope instead of replacing it. runCleanup()'s signature, its four bare inner catches and its counting are untouched; both of start()'s call sites now go through one module-level pass that reads { deleted, errors } and prints a single error line when a run lost deletes, naming the consequence and where to look. Logging at each seam was rejected because the convention names it the mirror-image failure; changing runCleanup()'s return type was rejected because it widens a published surface for an observability fix. The reporter is module-level rather than a private method precisely so the published declaration does not move -- measured, see clause-2 below. Shape follows the repo's own recognised reference for this pattern, the counter-guarded summary in plugin-email/src/outbox-sweep.ts. MY OWN COUNTS, re-located by text on origin/main @ 94ecb7e5c, file 317 lines -- reproducing triage EXACTLY: bare unbound 'catch {' = 4 at :116 :162 :166 :224; bound 'catch (error)' = 2 at :170 :304; console.error = 2 at :171 :305; 'void this.runCleanup()' = 2 at :55 :59; errors incremented at 7 points :115 :117 :160 :163 :167 :172 :225. Both of triage's enlargements over the card are confirmed (4 bare catches not 3; 2 void call sites not 1). CLAUSE-2: no, both limbs, MEASURED not argued -- see the tests field. Declared bare in the claim comment and verified on the carrier. Assignee was already set at dispatch, as the brief said; the claim comment is the ownership record.",
  "tests": "All commands via scripts/pm/os-verify-lock.sh, exit codes captured by redirect-then-read, never through a pipe. Final head a5ef26c7e (origin/main 07f40e546 merged in, no conflicts); the gate union below ran on that exact head and nothing was committed after it. TYPECHECK: pnpm --filter @objectstack/metadata typecheck clean -- and proven to cover the new files rather than exclude them: tsc --noEmit --listFiles lists both the edited source and the new test, 551 files in the program (the sibling dst test is the control, also present). TESTS: vitest on the new pin plus history-cleanup-dst.test.ts -- 31 passed (2 files). PIN: packages/metadata/src/utils/history-cleanup-failure-signal.test.ts, 4 cases asserting the SIGNAL not the cleanup -- immediate run reports; every scheduled run reports; CONTROL a run that loses nothing stays silent; runCleanup()'s envelope unchanged for a direct caller. ABLATION A (restore the swallow at both call sites): mutation proven on disk by LINE-anchored counts (runCleanupAndReport 0, runCleanup 2) plus a git hash-object mismatch vs the HEAD blob; result 2 failed / 2 passed, vitest exit 1. ABLATION B (half-fix -- immediate repaired, interval reverted): counts 1 and 1; result 1 failed / 3 passed, reddening EXACTLY the scheduled-run case. That is the load-bearing one: it proves fixing only one call site is caught. Both ablations restored with git checkout HEAD -- ABSOLUTE_PATH under an EXIT/INT/TERM trap, restore proven by blob equality AND an empty git diff HEAD. NO REBUILD LEG IS OWED: the pin imports the subject by relative path (./history-cleanup.js), so vitest resolves it to SOURCE, not to dist -- self-proven, because a source-only mutation with no rebuild reddened the suite. FIRST ABLATION ATTEMPT WAS A NO-OP AND ITS OWN PROOF STEP CAUGHT IT: the 4-space immediate call site is a SUBSTRING of the 6-space interval one, so a substring anchor matched both and the edit silently did nothing (blob still equal to HEAD). Switched to whole-line matching and re-ran. Recording it because a no-op ablation reads exactly like a passing one. GATES: node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands => 54 commands, change set of 3 paths vs merge base 07f40e546. Ran all 54. 52 exit 0. The family was NOT narrowed for a small diff -- this change moves the file's line count, so the anchor/census members ran regardless (check:system-context-census, check:platform-object-tenancy-census, check:comment-mask-corpus, check:comment-mask-adoption -- all green), alongside check:durability-log-level, check:logger-receiver-detach and check:refd-timer-probe, which this change's subject matter reaches directly. 2 gates are NOT MEASURED, not red: check:dual-build-cjs-loads and check:type-check-debt both exit 3 PREREQUISITE NOT MET, each printing 'This is NOT a pass: nothing was measured' -- they need a full workspace build (57 packages had no dist; I built only the metadata dependency closure). Their self-tests passed (93 cases / full battery). CI builds the whole farm and runs both properly. This is a DECLARED narrowing, not a skipped gate. check:type-check-coverage (the structural half that a new test file moves) is exit 0. LINT: repo-wide eslint is CI-owned; ran the proven narrowing instead -- eslint --format json on both changed files, 2 files, 0 errors, 0 warnings, exit 0. Invariance evidence for untouched files is the repo's own measured declaration at eslint.config.mjs:328: this repo runs one config which 'never enables type-aware linting (no parserOptions.project, no typed @typescript-eslint rules) for ANY file', established there with its own positive control -- so no untouched file's verdict can depend on my diff. CLAUSE-2 INSTRUMENT AND VERDICT: @objectstack/metadata publishes files: ['dist', ...], so the surface is every declaration file under dist/, NOT the root barrel and NOT the exports list (exports names 5 entry POINTS; those map to 10 declaration files). Built at head, swapped the one changed source back to the merge base, rebuilt, diffed ALL 10 -- hash-manifest diff EMPTY, every one byte-identical (dist/errors, dist/index, dist/migrations/index, dist/node, dist/view-container, each .d.ts and .d.cts). Rebuild proven to have actually re-run rather than been skipped: dist/index.js mtime 1788668782 -> 1788668792. The instrument is proven LIVE by a FIRING CONTROL from the same script one commit earlier, when the reporter was written as a private method: it reported 2 of the 10 differing (index.d.ts, index.d.cts), the whole delta being 'private runCleanupAndReport;' plus JSDoc -- so a byte-identical manifest here is a measurement, not a blind spot. Source restored byte-exact both runs (blob equals HEAD blob, git diff HEAD empty). LIMB 1: nothing published moves -- no exported symbol added, removed or renamed, declaration bytes identical. LIMB 2, argued explicitly because it is the limb that can fire with no contract path in the diff: runCleanup()'s signature is UNCHANGED (Promise of { deleted: number; errors: number }, byte-identical in the built declarations) and start() was NOT made to propagate -- it still returns void. So no consumer's accept/reject can move in either direction: the type surface compiled against is byte-identical, nothing that compiled before fails now and nothing that failed now compiles. At runtime nothing accepted or rejected moves either -- the delete filter, the rows deleted and the returned counts are unchanged, pinned from both sides by the CONTROL case (a clean run stays silent) and the envelope case. CARRIER: the bare line 'Clause-2: no' (in the required spelling with the circled numeral) was added to the claim comment as the closing step and read back -- line 1 still starts with an undecorated 'Claim:', the bare 'Branch:' line still matches the repo's own predicate, the declaration is present with no bold and no backticks, and no decorated variant exists. Verified with the real checker from a FRESH worktree at origin/main, blob-proven current (751b4a6e4 in the fresh tree, in origin/main, and in my worktree -- identical): node scripts/pm/check-clause2-carriers.mjs --pair 16177, redirect-then-read, REAL_EXIT=0, 'the clause-2 declaration is readable in the fixed spelling and both carriers agree'.",
  "mcp_calls": "0 -- every GitHub read and write this run went through REST (node fetch with NODE_USE_ENV_PROXY=1 + NODE_EXTRA_CA_CERTS); zero MCP GitHub calls.",
  "open_questions": [
    {
      "question": "PM/triage statements I measured to be FALSE or imprecise -- reported, not acted on, and none of them changes the disposition.",
      "options": [
        "FALSE (stated reason, not the instruction): the dispatch says main 'has moved a long way' since triage's origin/main @ a4816a7 so the numbers cannot be trusted. Re-deriving was right and I did it, but the reason does not hold FOR THIS FILE -- git diff a4816a7 94ecb7e5c on it is EMPTY (0 bytes) and a4816a7 is an ancestor of origin/main. The file was byte-identical to what triage measured, and my counts reproduce triage's exactly, all five rows.",
        "IMPRECISE: the dispatch reports the #16060 landing as setUTCDate(/getUTCDate() '0/0 -> 2/2' and setDate(/getDate() '2/2 -> 0/0'. Those are the correct before/after values, but triage's own base a4816a7 was ALREADY post-merge -- it reads 2/2 and 0/0. So the 0/0 and 2/2 halves are not a reading taken at a4816a7.",
        "TRAP THAT DID FIRE, for the next round: the shared primary checkout at /home/user/objectstack sits at c351a84da, which PREDATES #16060. Reading this file there shows setDate( at :96/:259 and would read as 'the hard serial has NOT been released' -- the exact ground the brief says to stop on. Everything here was measured against origin/main in a dedicated worktree.",
        "CONFIRMED, not false: the card really did understate two counts (three bare catches, one void call site) and triage's four and two are right; p2 is unchanged -- I measured nothing that moves the grade; and the dispatch's prediction that clause-2 would land at 'no' is confirmed by measurement rather than inherited."
      ],
      "recommendation": "No action needed from the PM. Recorded because a stated reason that is false is worth correcting even when the instruction it carried was right -- the next round on this file should re-derive from origin/main and should NOT trust the shared checkout, which is the trap that actually bites here."
    }
  ],
  "out_of_scope_findings": [
    "NOT filed as a new card, recorded on #12753 instead (https://github.com/objectstack-ai/objectstack/issues/12753#issuecomment-5556923764): once #16177 lands, one sentence in scripts/check-durability-degradation-log-level.mjs is false -- 'BOTH production call sites are void this.runCleanup() -- so the count is correct by contract and read by nobody in-process'. Dedupe was run before deciding: 682 items enumerated against the repo's own open_issues_count of 682 (648 issues), probes check-durability-degradation-log-level=8, DURABILITY_CRITICAL_CALLEES=2, correct-but-undeclared=1 (#12753), EXHIBIT STATUS=0, with firing controls history-cleanup=2, runCleanup=1, durability=14. #12753 is the open card that OWNS that triage table and whose stated first deliverable is re-measuring exactly these rows, so a new card would have been the duplicate its own dedupe rule exists to stop. The triage VERDICT for those rows is unchanged (correct-but-undeclared); only the consequence clause moves. Not repaired in this PR because the script's own convention for it (EXHIBIT STATUS) means editing a gate script, which pulls in that script's own test suite -- a different verification surface from an observability fix in packages/metadata.",
    "Recorded in the same comment, as input rather than a proposal: AGENTS.md says of this gate 'found a new one, add it to DURABILITY_CRITICAL_CALLEES in the same PR that fixes it'. Measured on origin/main, delete / deleteMany / bulkDelete are NOT in that vocabulary, so no implemented rule sees these seams at all -- check:durability-log-level is green over this file both before and after #16177 (29 seams swept, none of them here). What protects the repair from regressing is this PR's unit pin, not the gate. Adding delete/deleteMany/bulkDelete repo-wide is the unusable-population outcome that file's own header rejects; adding runCleanup (exactly one definition repo-wide, so blast radius is this file) is arguable but is a gate widening, so it fails the bounded-in-place test on the 'no new verification surface' limb and was left to the owner of #12753."
  ]
}

---

Generated by Claude Code