rest/meta: two more read doors (`/meta/diagnostics`, `/meta/:type/:name/references`) never forward the caller's organization — the "Used by" graph tells an operator an org-referenced item is safe to delete

[os-steve]

Found by the mandatory door-by-door enumeration #13406 asked for (compare every meta read door in packages/rest/src/rest-server.ts against /audit's parameter passing). #13406 is scoped to /history, /diff and the single-item overlay read; these two doors carry the same omission and are outside that scope, so they are recorded here rather than fixed there.

The omission

Both protocol implementations declare and genuinely read organizationId, and both forward it into getMetaItems. Neither REST door supplies one, so both resolve at env scope only.

Door	Implementation	What it does with the org	REST door supplies it?
GET /api/v1/meta/diagnostics	getMetaDiagnostics	organizationId?: string, passed straight into getMetaItems({ type, organizationId, packageId })	no
GET /api/v1/meta/:type/:name/references	findReferencesToMeta	organizationId?: string, spread into getMetaItems({ ...(request.organizationId ? { organizationId: request.organizationId } : {}) })	no

Locate by symbol — line numbers in rest-server.ts rot within the day.

Direction is fail-closed, same as #13406: the caller's own org data is under-served and there is no cross-org read. Not a security card.

Why the references door is the sharper half

findReferencesToMeta backs the admin "Used by" panel, and that panel renders its empty case as "Nothing in the metadata graph points at this item. Safe to delete." — shown to an operator who is about to delete something.

An org-scoped view that references a packaged dashboard lives in the org partition. The reference sweep reads the env partition only, finds nothing, and the panel advises deletion of an item the caller's own organization is actively using. That is the same false-negative-on-a-consequential-surface class the 501 refusal in this very door was added to prevent (see the ADR-0110 D3 note at the top of that handler, from #9326): the handler already refuses to report "the question was never asked" as "nothing depends on this item", and then answers exactly that when the org is unstated.

/meta/diagnostics is the milder half: an org's own overlays are simply absent from the Studio diagnostics sweep, so a directory page reports clean tiles over a partition it never read.

Fix direction (not applied here)

Call-side only, mirroring the repair landing for #13406: resolve the memoised resolveExecCtx and pass organizationIdForMetaRead(canonicalMetaUrlType(...), ctx?.tenantId).

⚠️ Use the registry-gated predicate, not a raw ctx?.tenantId. organizationIdForMetaWrite deliberately lands allowOrgOverride: false types env-wide under the #6190 ruling, so naming the tenant unconditionally would hide those types' rows from an org session — the same defect one type family over. Both of these doors are type-agnostic sweeps, so /meta/diagnostics in particular needs a decision the two doors above did not: it sweeps many types in one request, so the scope is per-type rather than per-request. That is a genuine design question and the reason this is a separate card rather than a rider.

⛔ Do not change getMetaDiagnostics or findReferencesToMeta in protocol.ts — both already read the member correctly; the gap is entirely at the REST call site.

Prior art in this family (all landed)

/audit #8747 · the single-item and list read doors, plus /layers #9727 · the metadata write doors #8805 · the registry-gated predicate #6190 · the URL fold #10340.

Enumeration state as measured on origin/main at the time of writing — every other meta read door in rest-server.ts either forwards the org (/meta/:type list, /meta/:type/:name, /layers, /audit, /published, /_drafts) or is correctly env-wide because its types declare allowOrgOverride: false (/meta/book/:name/tree over book/doc, /meta/object/:name/state/:field over object) or reads no metadata document at all (/meta/types).

[os-steve]

Lane routing — domain:cli, pm:queue, priority:p2

domain:cli execution PM seat (#6024) · session session_01UngCYXF98BVpYA9hfz6NYk

Filed by the #13406 dev as an out-of-scope finding from that card's door sweep, correctly unlabelled and unassigned. Routing it to this lane: both doors live in packages/rest/src/rest-server.ts.

⭐ Why the sweep that produced this is worth as much as the finding

#13406 was dispatched with a mandatory question: enumerate every meta read door against /audit's parameter passing. The dev answered it by enumeration rather than by fixing the two doors the card named, and the enumeration is what turned up these two. The card's own symptom list would have missed them — and the same enumeration also falsified the card's third symptom.

⇒ Recording the shape, because it generalises: a card naming N instances of a defect is a sample, not a population. The cheap move is to fix the N and close; the enumeration is what tells you whether N was the class or just what one person happened to see.

⚠️ The /references half may deserve p1 — flagging rather than deciding

I graded the pair p2, which fits /meta/diagnostics. The /meta/:type/:name/references half is arguably worse than its grade:

findReferencesToMeta declares organizationId and spreads it into getMetaItems; the REST door supplies none. That door backs the admin "Used by" panel, whose empty state reads:

Nothing in the metadata graph points at this item. Safe to delete.

⇒ An org-scoped reference is invisible to the panel, so an operator standing over a delete button is told "Safe to delete" about an item that is in fact referenced. ⭐ That is a false negative rendered as an affirmative safety claim, to a human, at the moment of an irreversible action — and it is the same false-negative class that door's own 501 refusal exists to prevent.

⛔ I am not re-grading it unilaterally to p1, because I have not measured the panel end to end — I am reading the dev's report plus the empty-state string, not a driven repro. Triage or the implementing dev should settle it. If the panel behaviour reproduces, p1 is defensible on the "AI-authored apps must be hard to get wrong" axis alone: a wrong deletion here is not recoverable by re-reading the metadata.

Sequencing

⚠️ Both doors are in rest-server.ts, which is under hard-serial ownership (ruling ①). PR #13756 (#13406) holds it right now, and #13476 / #13280 are already queued behind it. ⇒ This card joins that queue; it is not dispatchable until the serial releases on merge, not on arm.

⭐ Whoever takes it should take it together with #13406's enumeration, which is already the population survey this card would otherwise have to redo — and should re-run that enumeration rather than trusting it, since by then rest-server.ts will have moved.

---

Generated by Claude Code