Split out of #17041 as its only dispatchable half. #17041's real fix is blocked on an architecture decision (the dispatcher registry exposes domains, never routes); this half is nearly free, needs no architecture change, and stops the exact misreading that produced #17041 in the first place.
What is measured, and not in dispute
packages/runtime/src/route-ledger.conformance.test.ts makes six assertions. Every one is domain-granular or about a row's internal shape:
every registered dispatcher domain has AT LEAST ONE ledger entry
every ledger domain is a live registry prefix / pinned legacy branch / pinned non-dispatch mount
every pinned non-dispatch mount has a ledger row
the /apps carve-out is owned by nothing else
every `sdk` entry names its client method; every non-sdk entry carries a rationale
gap count only shrinks
Not one asserts that a particular route has a row. Confirmed by ablation on PR #17038: deleting the whole cancel ROUTE_LEDGER entry left the suite 6/6 green — automation still satisfied "at least one" through its 16 siblings.
⭐ And the exposure is real, not theoretical: of the 21 domains carrying 82 rows, 11 are single-row, where the domain check equals route-granularity by accident. The other 10 domains carry 71 rows — packages 17, automation 17, meta 9, data 6, share-links 5, actions 5, security 3, notifications 3, i18n 3, analytics 3 — and there, any non-last row can vanish or never land with nothing red.
The ask
One block of prose in the file's own header stating what the suite does and does not check: it holds the ledger's domains against the registry and each present row's shape; it does not assert that every route a domain serves has a row of its own, and cannot, because the dispatcher registry exposes domains only. Point at #17041 for the reason and the decision.
⛔ No behaviour change. No assertion added, weakened or removed. The six are correct at their own granularity — this card only stops the file's name and shape from implying a seventh.
Why it is worth a card rather than a rider
Because the inference is load-bearing and has already been made: someone adding a route reads the suite's name, sees green, and concludes the ledger is covered. That is what #17041 was filed about. ⇒ The comment is the cheap half of the fix and it does not need to wait for the expensive half.
⚠️ What the wording must not do: state or imply that per-route coverage is coming, or name a route table as the fix. #17041's option A vs B is an open maintainer decision — ⛔ the comment describes today's truth and points at the card; it does not pre-empt the ruling.
Related
#17041 (the parent; its real fix is needs-user-decision) · #17038 (where the null result was measured) · #17062 (service-settings' ledger has no guard at all) · #16828 · #17032 — the family of "what a check is named or shaped like versus what it actually reads".
Split out of #17041 as its only dispatchable half. #17041's real fix is blocked on an architecture decision (the dispatcher registry exposes domains, never routes); this half is nearly free, needs no architecture change, and stops the exact misreading that produced #17041 in the first place.
What is measured, and not in dispute
packages/runtime/src/route-ledger.conformance.test.tsmakes six assertions. Every one is domain-granular or about a row's internal shape:Not one asserts that a particular route has a row. Confirmed by ablation on PR #17038: deleting the whole
cancelROUTE_LEDGERentry left the suite 6/6 green —automationstill satisfied "at least one" through its 16 siblings.⭐ And the exposure is real, not theoretical: of the 21 domains carrying 82 rows, 11 are single-row, where the domain check equals route-granularity by accident. The other 10 domains carry 71 rows —
packages17,automation17,meta9,data6,share-links5,actions5,security3,notifications3,i18n3,analytics3 — and there, any non-last row can vanish or never land with nothing red.The ask
One block of prose in the file's own header stating what the suite does and does not check: it holds the ledger's domains against the registry and each present row's shape; it does not assert that every route a domain serves has a row of its own, and cannot, because the dispatcher registry exposes domains only. Point at #17041 for the reason and the decision.
⛔ No behaviour change. No assertion added, weakened or removed. The six are correct at their own granularity — this card only stops the file's name and shape from implying a seventh.
Why it is worth a card rather than a rider
Because the inference is load-bearing and has already been made: someone adding a route reads the suite's name, sees green, and concludes the ledger is covered. That is what #17041 was filed about. ⇒ The comment is the cheap half of the fix and it does not need to wait for the expensive half.
Related
#17041 (the parent; its real fix is
needs-user-decision) · #17038 (where the null result was measured) · #17062 (service-settings' ledger has no guard at all) · #16828 · #17032 — the family of "what a check is named or shaped like versus what it actually reads".