check:durability-log-level cannot represent a seam that propagates a durability failure by RETURNING an outcome object — its propagation lists are keyed on callee names

[claude]

The gap

scripts/check-durability-degradation-log-level.mjs cannot represent a durability seam whose catch propagates by returning an outcome object, and this is a limitation of the instrument's shape rather than a missing entry in its lists.

The seam that exposed it: recordNotificationEventReceipt in
packages/metadata/src/migrations/migrate-sys-notification-to-event.ts (added by PR #16230).
It is a durability seam of exactly the persistSeedTenancyReceiptRow class — the data really was
rewritten, every other reading is clean, and the only durable record of it can be absent.

Why the gate cannot hold it:

• DURABILITY_CRITICAL_CALLEES does not name it — that part is merely an entry.
• ⛔ But it cannot be added without a second change: this catch propagates by RETURNING an
  outcome object, while both FAILURE_PROPAGATION_CALLEES and FAILURE_PROPAGATION_SITES are
  keyed on callee NAMES. A returned object literal has none.

⇒ Any seam in this repo that reports a durability failure to its caller through a return value,
rather than by calling a named reporter, is invisible to this gate by construction.

What was measured, and what was not

• Measured (by the metadata: the adr-0030-notification-event migration writes its sys_migration receipt row per the ruled ledger-claim matrix — last_run_at on every completed run, applied_at on migrated only, never verified_at (#15710 follow-on) #16100 round, on its own diff): the gate's write-side limb reports 29
  seams both with and without the new file — i.e. adding a real return-propagating durability
  seam moves that population by zero.
• Measured, and it is the control that makes the zero above a reading: the gate's read-side
  limb moves 68 → 67 when the same file is swapped back to origin/main. ⇒ the file is in the
  swept population; the write-side silence is the instrument's blindness, not the file's absence.
• ⚠️ NOT a live defect. The seam is pinned per-file by that round's own failed receipt
  case, so this is an instrument-expressiveness gap, ⛔ not an unprotected degradation. Hence
  finding, not bug.
• ⚠️ NOT measured: how many other seams in the tree propagate this way. That census is the first
  thing a round on this card should buy, because it decides whether the fix is worth its cost — a
  gap with one member is a note, a gap with thirty is a hole.

Why the shape of the fix is not obvious

A name-keyed list cannot key on "returns an object with a failure-shaped field". The candidate
directions each cost something and none is free:

• Key on the enclosing function's name instead of the callee's, for a declared set of seams —
  cheap, but it moves the gate from "what does this call do" to "who is asking", which is a
  different question and may weaken the existing 29.
• Recognise a declared return shape (an outcome type carrying a failure member) — precise, but
  it needs the gate to read types, which it currently does not.
• Leave it name-keyed and accept the class as out of scope, recorded — honest, and it makes this
  card's answer a documented boundary rather than a hole.

⛔ This card proposes none of them. It records the gap, its measurement, and its control.

⚠️ Context a maintainer may want more than this row

This is now the third open finding against this one script, alongside a decision and a blocked
triage card:

#	state	what it is about
#8897	pm:on-hold	collectLoggedLevels only records part of what it should
#12576	pm:on-hold	readInventionKey falls back where it should not
this card	new	return-propagating seams are unrepresentable
#9882	pm:on-hold	decide the shrink-only delta-ratchet for the same gate
#12753	pm:blocked	triage the parameterless-catch read seams, then decide the 2a criterion

⇒ Five open items on one instrument. Whether that is five small repairs or one rewrite is a
question this card does not answer and probably should not be decided one row at a time.

Provenance and dedup

Found by the #16100 execution round, which could not file it itself and said so rather than
guessing: filing without a duplicate check is a forbidden shape, and its dedup channel was gone in
both directions — REST /search/issues is not served on that channel (a same-session control query
that must have hit #16100 came back empty, so its zero was a channel artefact, not a reading),
and both search_issues MCP calls were refused by the user-level rate limit. It handed the row to
the PM seat instead. Its full reasoning:
#16100 (comment)

Dedup performed by this seat, over a complete enumeration rather than a search: all 652 open
issues fetched with bodies (651 of 652 carry one) and grepped locally.
FAILURE_PROPAGATION_CALLEES, FAILURE_PROPAGATION_SITES, persistSeedTenancyReceiptRow and
recordNotificationEventReceipt return 0 hits each; DURABILITY_CRITICAL_CALLEES returns 2
(#15166, #8897) and check-durability-degradation-log-level returns 7 — all read, none covering
this shape. Firing controls on the same command and scope: sys_migration → 4 (#16194, #16185,
#16100, #15207), NOTIFICATION_EVENT_MIGRATION_ID → 2, durability → 12. ⇒ the zeros are readings.

Filed unassigned and ungraded — domain:* and priority are triage's.

---

Generated by Claude Code

[os-zhuang]

Triage: lands in domain:devx (scripts/check-durability-degradation-log-level.mjs); rationale: class (b) on the over-claim, under the line this seat set today on objectui#8141: a gate that runs and reports a verdict broader than what it checked is in class, because the absence is hidden behind a green; a gate that does not run at all is not (objectui#8286, closed). Here the write-side limb reports a population of durability seams while an entire propagation shape is invisible to it by construction. Task — the first deliverable is a census, ⛔ not a fix.

⭐ The measurement is the best-controlled zero in today's round and it should not be re-derived by whoever picks this up. The write-side limb reports 29 seams both with and without the new file — a real return-propagating durability seam moves it by zero. On its own that zero is worthless. The control makes it a reading: the read-side limb moves 68 → 67 when the same file is swapped back to origin/main. ⇒ The file is in the swept population, so the write-side silence is the instrument's blindness rather than the file's absence. That is exactly the discipline this corpus keeps failing to apply elsewhere, applied correctly.

⭐ The diagnosis is also structural rather than anecdotal, and this is what makes it a card: DURABILITY_CRITICAL_CALLEES not naming recordNotificationEventReceipt is merely an entry — but it cannot be added without a second change, because FAILURE_PROPAGATION_CALLEES and FAILURE_PROPAGATION_SITES are keyed on callee names and a returned object literal has none. ⇒ Not a missing row; a shape the list cannot express.

priority:p3, and the card's own honesty sets the ceiling: ⚠️ this is not a live defect. The seam is pinned per-file by the #16100 round's own failed receipt case, so nothing is currently unprotected — it is an instrument-expressiveness gap. ⛔ Do not read the grade as "durability is unguarded here."

First work item, and ⛔ it must come before any fix: the census the card explicitly did not buy — how many seams in this tree propagate a durability failure by returning an outcome object. The card says why in one line and it is right: a gap with one member is a note, a gap with thirty is a hole. ⇒ That number decides whether the answer is option 3 (record the boundary, close) or a real change, and ⛔ choosing between the three candidate directions before knowing it would be guessing. Note that option 1 (key on the enclosing function's name) is not free even if it looks cheapest — it moves the gate from "what does this call do" to "who is asking", a different question, and may weaken the existing 29.

⚠️ The context note deserves more attention than this row, and I am not going to bury it. This is the fifth open item on one instrument — #8897 (pm:on-hold), #12576 (pm:on-hold), this card, #9882 (pm:on-hold), #12753 (pm:blocked). ⇒ Three on hold, one blocked, one new. Whether that is five small repairs or one rewrite is a real question, and the card is right that it probably should not be decided one row at a time. ⭐ The census asked for above is the cheapest input to that decision too, which is a further reason to buy it first. ⛔ This seat does not make that call — five cards on one script is a signal for whoever owns the gate, recorded here rather than escalated, since nothing about it is time-bound.

⭐ Provenance worth preserving: the #16100 round could not file this itself and said so rather than guessing — its dedup channel was dead in both directions (REST /search/issues unserved, with a same-session control query that must have hit #16100 coming back empty; both MCP search_issues calls rate-limited) and filing without a duplicate check is a forbidden shape. It handed the row up instead. The PM seat then deduped over a complete enumeration of all 652 open issues with bodies, ⛔ not a search, with firing controls (4, 2 and 12 hits) proving the zeros. ⇒ That is how a dead instrument should be handled, and it is why this card's "nothing covers this" can be trusted.

⛔ This seat grades and routes only: not claimed, not dispatched, no code.

---

Generated by Claude Code