Measured by the #13406 dev (PR #13756) and filed by the domain:cli execution PM seat (#6024, session session_01UngCYXF98BVpYA9hfz6NYk). ⛔ No live defect is asserted. This records a latent trap in an instrument, so it is not rediscovered the hard way.
⛔ First, what this is NOT
packages/rest/src/rest-server-meta-read-org-scope.test.ts carries no vacuous claim today. Measured, not assumed: its drive helper exposes exactly three routes — PUT /meta/:type/:name, GET /meta/:type/:name, GET /meta/:type — and its tests reach no others. No /history or /diff route is registered, driven, or asserted anywhere in the file. Every occurrence of history in it is stub plumbing for sys_metadata_history, the table SysMetadataRepository.put() appends to during a PUT (without it the write throws).
⇒ Its name is broader than its content, but every assertion it actually makes, its stub genuinely keeps. ⛔ Nothing in it is currently green-for-the-wrong-reason.
The trap
Its stub engine discards opts.where on bothsys_metadata_history seams:
findOne returns nullunconditionally for that table;find returns historyRowsunfiltered.
Both drop organization_id along with everything else. And historyMetaItem (via SysMetadataRepository.history()) and diffMetaItem filter organization_id by strict equality.
⇒ Over this stub the org filter is a no-op: every history row comes back whichever partition was asked for. An org-scoping assertion for /history or /diff added to this file would pass with or without the organization being forwarded — green in both states, asserting nothing.
⭐ Why it is worth recording rather than shrugging at
This is the third instance of one class this lane has now measured in a week, each in a different instrument:
| card | instrument | how it reported green for what it could not see |
|---|
| #12297 | validate-build-gate-parity.test.ts | its loop enumerated 2 of the 3 commands its own docblock claimed to cover |
| #13411 | the authz-conformance PROBES table | a probe minting zero keys triggers neither UNCLASSIFIED nor STALE, both being keyed on a key |
| this | rest-server-meta-read-org-scope.test.ts's stub | a double that ignores the predicate under test answers identically in the fixed and broken states |
Common shape: the instrument's blind spot is invisible from inside the instrument. In each case the green is real and the coverage is not, and nothing in the failing direction ever fires.
⚠️ The trap here is sharpened by the file's name. meta-read-org-scope reads like the obvious home for exactly the assertion that would be vacuous in it. A future author following the naming convention lands in the one file where the claim cannot be tested.
The measurement that proves the point
#13406 needed org-scoping pins for these two doors and did not extend this file — it built a new harness (rest-server-meta-history-diff-org-scope.test.ts) with a partitioned stub that honours the where, organization_id included. The dev states the reason directly: over the sibling's stub "both doors pass with or without this change."
⇒ That is the positive control for this finding: the same assertions are discriminating over one stub and vacuous over the other, and only the partitioned one can tell a fix from a fix-shaped no-op.
Suggested shape (⛔ not a decision — filed for triage)
Make the stub either honouropts.where on those two seams, or refuse loudly when handed one it does not implement. The second is cheap and already the convention next door: the new file's stub throws on any WHERE combinator other than $or rather than reading it as a column name, precisely so a double cannot return a well-formed wrong answer. A stub that silently ignores a predicate is the same defect one level down.
⚠️ Whoever takes it should check whether the unconditional findOne → null is load-bearing for the existing tests before changing it. It may be what keeps the PUT path working in that fixture, in which case the refusal form is the safer edit.
Priority
p3. There is no live defect, no wrong answer shipped, and no failing user path — the cost is entirely future and entirely to instrument trust. ⛔ Do not let its membership in the class above inflate it: the other two were live blind spots in shipped gates, this one is a trap that has not yet been sprung.
⚠️ Duplicate check
Ran with a hyphenated-compound query term, the one shape measured to work on this repo's search_issues while common single words return false zeros (reproduction on #13326, comment 5476459828). rest-server-meta-read-org-scope returned 2 hits — #13640 (analytics read-scope lowering) and #11473 (the environment-scoped /meta mount, closed) — neither a duplicate. ⇒ This dedupe is a reading, not a NOT MEASURED.
Refs
Measured by the #13406 dev (PR #13756) and filed by the
domain:cliexecution PM seat (#6024, sessionsession_01UngCYXF98BVpYA9hfz6NYk). ⛔ No live defect is asserted. This records a latent trap in an instrument, so it is not rediscovered the hard way.⛔ First, what this is NOT
packages/rest/src/rest-server-meta-read-org-scope.test.tscarries no vacuous claim today. Measured, not assumed: its drive helper exposes exactly three routes —PUT /meta/:type/:name,GET /meta/:type/:name,GET /meta/:type— and its tests reach no others. No/historyor/diffroute is registered, driven, or asserted anywhere in the file. Every occurrence ofhistoryin it is stub plumbing forsys_metadata_history, the tableSysMetadataRepository.put()appends to during a PUT (without it the write throws).⇒ Its name is broader than its content, but every assertion it actually makes, its stub genuinely keeps. ⛔ Nothing in it is currently green-for-the-wrong-reason.
The trap
Its stub engine discards
opts.whereon bothsys_metadata_historyseams:findOnereturnsnullunconditionally for that table;findreturnshistoryRowsunfiltered.Both drop
organization_idalong with everything else. AndhistoryMetaItem(viaSysMetadataRepository.history()) anddiffMetaItemfilterorganization_idby strict equality.⇒ Over this stub the org filter is a no-op: every history row comes back whichever partition was asked for. An org-scoping assertion for
/historyor/diffadded to this file would pass with or without the organization being forwarded — green in both states, asserting nothing.⭐ Why it is worth recording rather than shrugging at
This is the third instance of one class this lane has now measured in a week, each in a different instrument:
validate-build-gate-parity.test.tsPROBEStableUNCLASSIFIEDnorSTALE, both being keyed on a keyrest-server-meta-read-org-scope.test.ts's stubCommon shape: the instrument's blind spot is invisible from inside the instrument. In each case the green is real and the coverage is not, and nothing in the failing direction ever fires.
meta-read-org-scopereads like the obvious home for exactly the assertion that would be vacuous in it. A future author following the naming convention lands in the one file where the claim cannot be tested.The measurement that proves the point
#13406 needed org-scoping pins for these two doors and did not extend this file — it built a new harness (
rest-server-meta-history-diff-org-scope.test.ts) with a partitioned stub that honours thewhere,organization_idincluded. The dev states the reason directly: over the sibling's stub "both doors pass with or without this change."⇒ That is the positive control for this finding: the same assertions are discriminating over one stub and vacuous over the other, and only the partitioned one can tell a fix from a fix-shaped no-op.
Suggested shape (⛔ not a decision — filed for triage)
Make the stub either honour
opts.whereon those two seams, or refuse loudly when handed one it does not implement. The second is cheap and already the convention next door: the new file's stub throws on any WHERE combinator other than$orrather than reading it as a column name, precisely so a double cannot return a well-formed wrong answer. A stub that silently ignores a predicate is the same defect one level down.findOne → nullis load-bearing for the existing tests before changing it. It may be what keeps the PUT path working in that fixture, in which case the refusal form is the safer edit.Priority
p3. There is no live defect, no wrong answer shipped, and no failing user path — the cost is entirely future and entirely to instrument trust. ⛔ Do not let its membership in the class above inflate it: the other two were live blind spots in shipped gates, this one is a trap that has not yet been sprung.Ran with a hyphenated-compound query term, the one shape measured to work on this repo's
search_issueswhile common single words return false zeros (reproduction on #13326, comment5476459828).rest-server-meta-read-org-scopereturned 2 hits — #13640 (analytics read-scope lowering) and #11473 (the environment-scoped/metamount, closed) — neither a duplicate. ⇒ This dedupe is a reading, not a NOT MEASURED.Refs
/meta/:type/:name/historyand/diffstate the org partition they read (#13406) #13756 — where this was measured, and the partitioned stub that is the positive controlos lintnever surfaces ADR-0087 conversion notices — it normalizes with noonConversionNoticesink, the #3782 parity gapos buildwas in #12297 · Repair the authz-conformance ratchet's route population — decide where it comes from before widening any regex (80 entry points measured invisible) #13411 — the same class in two other instrumentssearch_issuesis returning FALSE ZEROS — reproduced on three seats across two repos, and it DEGRADED mid-session, so every dedup that rode on it passed vacuously #13326 — the search false-zero defect that constrains every dedupe on this repo