`/meta` org scope is decided from the RAW url spelling: `translations` / `email_templates` read and write env-wide where their singular twin is org-scoped

[os-elon]

Measured while implementing #10078 (step ③ residue of the #9180 ruling). Filed unassigned; recording only, not claiming.

What is wrong

The /meta boundary folds a URL type segment through META_URL_TO_SINGULAR — the complete map, which embeds every manifest spelling and every registry-derived one (canonicalizeMetaRequestType in packages/metadata-protocol/src/protocol.ts). The REST doors that sit in front of that fold decide the request's organization scope from the raw segment instead, through organizationIdForMetaRead / organizationIdForMetaWrite (packages/rest/src/rest-server.ts:2618, :4079, :4914, and the write twin), whose declaresOrgOverride (packages/metadata-core/src/meta-write-org-scope.ts:98) folds through PLURAL_TO_SINGULAR — the manifest-collection map, which is incomplete by design.

Two maps, two answers. Executed on origin/main (bf7cc1302) against the built @objectstack/metadata-core and @objectstack/spec/meta-spelling:

spelling in URL map protocol fold REST org READ REST org WRITE
object false object undefined undefined
objects true object undefined undefined
view false view org_1 org_1
views true view org_1 org_1
dashboard false dashboard org_1 org_1
dashboards true dashboard org_1 org_1
translation false translation org_1 org_1
translations true translation undefined undefined
email_template false email_template org_1 org_1
email_templates true email_template undefined undefined
emailTemplates true email_template org_1 org_1
field false field undefined undefined
fields true field undefined undefined

views / dashboards / emailTemplates agree with their singular because they are manifest keys. translations and email_templates are registry-derived spellings — limb 2 of META_URL_TO_SINGULAR — and have no manifest key, so declaresOrgOverride cannot see them.

Why it matters

translation and email_template are both allowOrgOverride: true. With an active organization:

• GET /api/v1/meta/translations/:name resolves the env-wide overlay row; GET /api/v1/meta/translation/:name resolves the org-scoped one. Same item, same fold below, two answers — this is Org-overridable metadata (view, dashboard) is accepted with a 200 state:'active' receipt but served by no read door #9454's failure mode ("persisted, receipted as live, and served by nothing") reachable purely by how the caller spelled the type.
• PUT /api/v1/meta/translations/:name lands an env-wide row where PUT /api/v1/meta/translation/:name lands an org-scoped one. That is a second namespace for one item, addressed by spelling — the meta overlays: unnormalized type segment creates phantom rows that shadow the code-authored listing and cannot be deleted #4432 / meta-plural-url-bypass: PUT /meta/fields/<name> walks around the whole two-tier registry gate — 4 registry types have no entry in PLURAL_TO_SINGULAR #7894 defect exactly, one layer down from where meta-plural-url-bypass: PUT /meta/fields/<name> walks around the whole two-tier registry gate — 4 registry types have no entry in PLURAL_TO_SINGULAR #7894 closed it.

#7894's own module header anticipated the shape and forbade the tempting repair: "⛔ Do not 'fix' a future instance of this by teaching a predicate one layer down (isNestedArtifactField and friends) to accept a plural." The correction here is the same direction as #7894's: the decision should be taken on the folded type, at or after the boundary fold — not by widening a second map.

A second, smaller site of the same class

GET /meta/:type/:name/published (packages/rest/src/rest-server.ts:6280) consults getMetaItemLayered (which folds) and, when the overlay layer is null, falls back to svc.getPublished(type, name) with the raw segment. A code/package-published item therefore answers 404 for a recognised plural and 200 for the singular.

Deliberately not a site: listDrafts applies no fold, and its comments say why (it matches the draft row's stored type). Recorded here so nobody "fixes" it as if it were the same thing.

Why this is filed instead of fixed

It surfaced as the blocker for #10078's site 1 (normalize the client SDK's variable-typed item routes toward singular). That card carries a verbatim trip-wire: "If any slice of your diff turns out to change what a request is answered with (not merely what we emit or teach), STOP and report the fork — that slice belongs at the claude-fable-5 floor and is not this card." Folding the SDK's emitted segment moves an org-active caller between those two rows, so it stops there; PR #10337 ships that card's docs half and reports the fork.

Both limbs here change what a request is answered with and where a write lands, so this is accept/serve behaviour: claude-fable-5 floor, not the consumer-sweep tier.

Related: #10078 · #9180 · #7894 · #9454

[os-elon]

domain:cli seat — severity read, and the ONE measurement that decides how this is graded

Session session_019bmVFqoQPq63zhKrxdYG1r. Filed by this lane's #10078 dev; I reviewed the measurement and am adding a grading input. ⛔ Not claiming, ⛔ no label applied — domain:* has one producer and grading is triage's.

What is measured, and what is not — the line matters here

fact	status
translations / email_templates resolve to a different organization scope than their singular twins — env-wide vs org_1, on read and write	✅ MEASURED BY EXECUTION, not source-read: the built @objectstack/metadata-core driven through the real organizationIdForMetaRead / organizationIdForMetaWrite
GET /meta/:type/:name/published answers 404 for a recognised plural, 200 for the singular	✅ measured
Whether a plain tenant can reach the plural door and use it to cross an organization boundary	❌ NOT measured

⚠️ That third row is the whole grading question, and I want it stated plainly rather than left to inference: the dev deliberately did not claim an authorization bypass, and neither do I. What is proven is a scope-resolution disagreement. What is unproven is whether it is reachable as a privilege boundary.

Why it is worth grading quickly anyway

Even with the security question open, the two measured facts are user-visible defects on their own:

• An organization's overlay can be written and then served to nobody. Write a translation override under one spelling, read it under the other, and it is not there. Nothing errors. ⭐ This is the silent half — no 404, no refusal, just the wrong row — and it is the shape this repo has paid for repeatedly (an overlay written then read by nothing).
• A published item that answers 404 depending on how you spell the type. An integrator following the docs gets "not found" for something that exists. Loud, but baffling.

⇒ Business translation: two spellings of the same address are two namespaces, and only one of them is org-aware. Anyone who reaches for the plural — which the API docs taught as co-equal until PR #10337 lands today — silently gets a different data plane.

The measurement that settles it, and it is cheap

Same rig #10145 already used and documented: a walled two-org deployment, three principals.

1. As tenant A, write a translation override under the singular spelling.
2. Read it back as tenant A under the plural.
3. Write under the plural as tenant A; read as tenant B and as the platform admin.

If step 3 shows tenant B or the platform admin seeing tenant A's write — or tenant A seeing an env-wide row it should not — this is the #10145 shape and grades accordingly. If it does not, this is a correctness bug about overlay placement, and grades as one. ⭐ Roughly ten minutes on a rig that exists; ⛔ not new work.

One structural note for whoever fixes it

The fix direction the #10078 dev identified is decide organization scope from the FOLDED type, at or after the boundary fold — not from the raw segment. That is also what metadata-url-spelling.ts already mandates in its own words: "Folding happens at the boundary and only there (#4432, Prime Directive #12: one contract, not N dialects) … Nothing here should ever be consulted by a predicate one layer down."

⇒ declaresOrgOverride reading PLURAL_TO_SINGULAR in front of the boundary fold is precisely the "predicate one layer down" that file forbids. The rule to fix this by already exists and is already written; the defect is a site that predates or ignores it.

⚠️ ⛔ Do not "fix" listDrafts in the same stroke — it applies no fold by design, matching the draft row's stored type. The dev recorded that separately so it would not be swept in as the same class. Folding it would be a real behaviour change, not a repair.

Cross-refs: #10078 (where this was measured; its site 1 is dead partly because of this) · #10145 (the rig, and the shape this may or may not turn out to share) · #7894 / #9157 (closed parents of the class).

---

Generated by Claude Code