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`

[huangyiirene]

Summary

canonicalMetaType — the ONE canonical spelling of a metadata type at the /meta read/write/delete boundary (#4432) — folds plural→singular through PLURAL_TO_SINGULAR. That map is a manifest collection map (objects: [...], apps: [...]), and it is missing entries for four registry types. For those, the plural URL spelling is not folded: it is treated as an unregistered plugin type, which every authorization gate treats as permissive by construction.

Result: the plural URL is a door around the singular URL's lock.

Measured, live (booted showcase, admin bearer, on top of #7743's fix)

PUT /api/v1/meta/field/showcase_task.title → 403 NOT_OVERRIDABLE ← #7743's fix, correct
PUT /api/v1/meta/fields/showcase_task.title → 200 {"success":true,"state":"active",
 "message":"Saved fields 'showcase_task.title' …"}

Note the receipt: Saved fields. The row is persisted with type='fields' — a second namespace for the same item, which is precisely the defect class #4432 was filed about ("one plural-spelled read minted a plural registry entry … one overlay row shadowed an entire code-authored listing, and survived the DELETE that was supposed to lift it").

Why the gates let it through

For an unmapped spelling 'fields':

• isOverlayAllowed('fields') → false
• isRuntimeCreateAllowed('fields') → true — no static registry entry, so getMetaTypes() synthesises allowRuntimeCreate: true
• the metadata: allowRuntimeCreate:false is not enforced — PUT /meta creates job and agent items the registry declares code-only #5086 code-only refusal needs BOTH false → does not fire
• orgScopedWriteRefusal → returns null, explicitly: "Statically-declared types only… a type with no entry in DEFAULT_METADATA_TYPE_REGISTRY is plugin-registered at runtime"
• SysMetadataRepository.assertAllowed('fields', 'runtime-only') → !STATIC_REGISTRY_TYPES.has('fields') → returns, allowed

Every one of those is correct behaviour for a genuinely plugin-registered type. The bug is that 'fields' is not one — it is a registry type wearing a spelling the boundary map does not know.

Blast radius (measured against DEFAULT_METADATA_TYPE_REGISTRY at bcea363)

Registry types with no singular target anywhere in PLURAL_TO_SINGULAR:

type	allowOrgOverride	allowRuntimeCreate	exploitable today
field	false	true	yes — proven above; artifacts exist (inside objects)
seed	false	true	structurally, if a package ships one
external_catalog	false	true	structurally, if a package ships one
translation	true	true	no — the singular route allows it anyway

Plus email_template, reachable only as camelCase emailTemplates; the REST-shaped /meta/email_templates is unmapped. (allowOrgOverride: true, so no lock to bypass.)

So the one type where this is a live authorization hole today is field, which is why it surfaced under #7743.

Why #7743 did not fix it

It is a different defect with a wider remedy, and the narrow patch is the wrong shape. Two candidate fixes, both needing a decision:

1. Add the missing keys to PLURAL_TO_SINGULAR. ⚠️ Careful: that map is also iterated by metadata-authoring-lint.ts to emit "did you mean" hints for stack-level manifest collections. Adding fields: there would advertise a top-level fields: [...] collection that does not exist and collides conceptually with ObjectSchema.fields.
2. Split the two roles — a manifest-collection map and a URL-spelling map are two different contracts that happen to overlap. canonicalMetaType would read the URL one, derived from DEFAULT_METADATA_TYPE_REGISTRY so a new type cannot arrive unmapped (Prime Directive Convert to monorepo with scoped packages #8: registry-derived, never a hand-written list).

A third option worth pricing: refuse an unknown plural at the boundary rather than silently treating it as a plugin type — an unmapped spelling of a declared type is a caller error, and answering 200 to it is how the second namespace gets minted.

⛔ Do not fix this by teaching isNestedArtifactField (or any other predicate) to accept 'fields' — that is a spelling-tolerant lookup one layer below the boundary, which is the exact pattern #4432's doc comment rejects, and it would still persist the row under type='fields'.

Repro

1. Boot the showcase with writable runtime packages; obtain an admin bearer.
2. PUT /api/v1/meta/field/showcase_task.title {name:'title', label:'X', type:'text'} → 403 (with org-override-registry-gate: the field overlay lock is not enforced — an artifact-backed field PUT is accepted 200 (and is inert) #7743's fix).
3. PUT /api/v1/meta/fields/showcase_task.title with the same body → 200.
4. SELECT type, name FROM sys_metadata → a row with type='fields'.

Source

Found while writing #7743's route-level pin: the plural case was written expecting a 403 and measured 200, then confirmed against the live showcase. Not present in #7743's original report.

[os-zhuang]

Claiming this issue.

• session: session_012WMpuAfA2KSdDjGF6tm1bH
• branch: claude/issue-7894-meta-plural-url-bypass

Starting with a read-only derivation of the current unmapped set against DEFAULT_METADATA_TYPE_REGISTRY, plus a check of which module actually owns canonicalMetaType, before any edit.

---

Generated by Claude Code

[os-zhuang]

Stopped before editing, per the dispatch instruction: the fix cannot avoid packages/metadata-protocol/src/protocol.ts, which is at its concurrent-editor cap. No code written, no branch created. Claim held pending sequencing.

{
 "issue": 7894,
 "status": "blocked",
 "branch": "claude/issue-7894-meta-plural-url-bypass (reserved, not created)",
 "pr": null,
 "premise_still_valid": true,
 "summary": "Held at the gate the dispatch prompt set. PM mechanism assumption 1 is HALF WRONG: PLURAL_TO_SINGULAR does live in packages/spec/src/shared/metadata-collection.zod.ts (line 111), but canonicalMetaType is defined in packages/metadata-protocol/src/protocol.ts at line 151, and its body is exactly the line the fix must change. No transport-independent close of the bypass exists outside that file: all six /meta entry points fold through canonicalizeMetaRequestType (protocol.ts lines 4339, 4720, 5127, 7813, 10176, 13583), and packages/rest/src/rest-server.ts only carries a duplicate of the same fold (RestServer.metaTypeSingular, line 2938) — patching REST alone leaves the MCP and in-process callers open. Good news for sequencing: the required diff is confined to protocol.ts lines 63 (import) and 124-159 (the canonicalMetaType doc comment plus body); putting the refusal inside canonicalMetaType means all six entry points inherit it with zero edits at those sites. That range is textually DISJOINT from all three in-flight branches (issue 8268 hunks span 4264-4400, issue 8296 spans 5869-5990, issue 7748 spans 9545-14240), so a fourth editor confined to lines 63 and 124-159 would merge clean. Assumptions 2 and 3 both confirmed — details in open_questions.",
 "tests": "No build or test run — no code was written. Static derivation only, run against packages/spec/src/kernel/metadata-plugin.zod.ts and metadata-collection.zod.ts, which are BYTE-IDENTICAL between the local checkout (ecb39ea22) and origin/main (a8940e401); only protocol.ts moved between them (324 insertions, 46 deletions). Derived output: 26 registry entries, 29 PLURAL_TO_SINGULAR keys; registry types with no singular target in the map = field (allowOrgOverride=false, allowRuntimeCreate=true), seed (false/true), external_catalog (false/true), translation (true/true) — the card's table reproduces EXACTLY, unchanged since bcea363. email_template confirmed reachable only as camelCase emailTemplates; the REST spelling email_templates is unmapped, also as the card states.",
 "open_questions": [
 {
 "question": "Under options 2 AND 3 together, measurement 1 does NOT produce a refusal naming the spelling 'fields'. A URL map derived from DEFAULT_METADATA_TYPE_REGISTRY necessarily CONTAINS field -> fields, so PUT /meta/fields/showcase_task.title folds to 'field' and answers 403 NOT_OVERRIDABLE — converging on measurement 2's answer. The bypass is closed and no type='fields' row is minted, but the observable is identical to the singular route rather than a distinct spelling-named refusal. Option 3's refusal then only covers spellings still unknown after derivation (e.g. /meta/fieldz/), which answer 200 today. Is the converged 403 the intended shape for measurement 1?",
 "options": [
 "A — accept the converged 403 NOT_OVERRIDABLE for /meta/fields/ (fold is the fix; refusal covers only genuinely-unknown spellings)",
 "B — additionally refuse plural spellings for nested-artifact types like field, so /meta/fields/ answers a distinct refusal naming the spelling"
 ],
 "recommendation": "A. Plural REST paths are the documented spelling (/meta/actions is legitimate and folds), so singling out /meta/fields/ for refusal would make field's URL contract differ from every other type's for no stated reason. A closes the authorization hole and the second-namespace defect, which is what the card is about. I will report the measured shape either way."
 },
 {
 "question": "A URL map derived PURELY from DEFAULT_METADATA_TYPE_REGISTRY drops seven spellings that fold today and whose singular has NO static registry entry: themes -> theme, sharingRules -> sharing_rule, webhooks -> webhook, skills -> skill, ragPipelines -> rag_pipeline, analyticsCubes -> analytics_cube, connectors -> connector. These are plugin-registered kinds carried only by the manifest map (confirmed: protocol.code-only-types.test.ts line 465 marks 'theme' as 'no static registry entry (plugin-registered)'). A pure derivation regresses /meta/themes and breaks the mandated positive control.",
 "options": [
 "A — URL map = union of registry-derived spellings, explicitly declared irregular/camelCase spellings, and runtime-registered plugin kinds",
 "B — pure registry derivation, accepting the seven regressions"
 ],
 "recommendation": "A, and it is a substantive refinement of ruling 2 that I want confirmed before coding. The Prime Directive 8 goal — a newly DECLARED type cannot arrive unmapped — is fully served by the registry-derived half; the union's other limbs exist because plugin kinds legitimately have no registry entry. Related: to keep the refusal from misfiring on plugin types I would make it a purely STATIC rule (refuse only a spelling that singularizes to a type declared in DEFAULT_METADATA_TYPE_REGISTRY), rather than threading the live registered-type set into what is today a pure module-level function."
 },
 {
 "question": "Assumption 3 verified and CONFIRMED — recording it here since it also confirms ruling 1's derivation is sound, not merely asserted.",
 "options": [
 "metadata-authoring-lint.ts imports PLURAL_TO_SINGULAR at line 60 and iterates Object.entries(PLURAL_TO_SINGULAR) at lines 171 and 340 to enumerate the stack collections it walks"
 ],
 "recommendation": "Keep the manifest map unchanged, exactly as ruled. Adding a fields key would enter the lint walker's collection set at both sites and advertise a top-level fields collection. Ruling 1 (reject option 1) is correctly applied; I am not contesting it."
 }
 ],
 "out_of_scope_findings": []
}

---

Generated by Claude Code

[os-zhuang]

PM sequencing + two rulings, before any code

Recording these so the shape is auditable and the protocol.ts region is declared publicly.

Region declaration — 4th concurrent editor, bounded

canonicalMetaType is defined in packages/metadata-protocol/src/protocol.ts:151, so this fix cannot avoid the hot file. (PLURAL_TO_SINGULAR itself lives outside it, at packages/spec/src/shared/metadata-collection.zod.ts:111.) Fixing packages/rest/src/rest-server.ts:2938 instead is not an option: all six /meta entry points fold through canonicalizeMetaRequestType in protocol.ts, and REST merely duplicates the fold off the same map — a REST-only fix leaves the MCP bridge and every in-process caller open, and the sys_metadata row assertion is a protocol-level fact.

Declared region: line 63 (import) + lines 124–159 (canonicalMetaType doc comment and body). Disjoint from all three in-flight holders — #8268 (4264–4400), #8296 (5869–5990), #7748 (9545–14240) — and at the opposite end of the file from every one of them. Because the refusal goes inside canonicalMetaType, all six entry points inherit it with zero edits at those sites, and the ~60 inline PLURAL_TO_SINGULAR lookups never see an unfolded spelling.

This lane caps protocol.ts at 3 concurrent editors. I am authorising a 4th here, deliberately and on the record: the cap bounds merge thrash and semantic collision on a hot file, and an import line plus one function at the top incurs neither, while #7894 is an authorization hole with a working exploit. The pin is the condition of the exception — if the diff must reach outside 63 / 124–159, work stops and I re-sequence.

Ruling 1 — the plural URL folds; it does not get its own refusal

My dispatch asked for PUT /meta/fields/… to become "a refusal that names the offending spelling". That was my error. Once the URL map is derived from DEFAULT_METADATA_TYPE_REGISTRY it necessarily contains field -> fields, so the plural folds to field and answers 403 NOT_OVERRIDABLE — converging on the singular route's answer rather than producing a distinct refusal. Both defects this card names are closed by that: 200 becomes 403, and no row is minted under type='fields'.

Adopting the dev's reasoning: plural REST paths are the documented legitimate spelling (/meta/actions folds and must keep folding), so singling out /meta/fields/ for a spelling-refusal would give field a URL contract unlike every other type's, for no reason this card states — a special case in the spelling layer, which is the pattern #4432 exists to prevent. The card's third option keeps its job, scoped to spellings still unknown after derivation (e.g. /meta/fieldz/), which answer 200 today.

Corroboration worth keeping: STATIC_REGISTRY_TYPES' guard at sys-metadata-repository.ts:1151 already tests both the folded singular and the raw type, so it fires correctly with no edit of its own once fields folds.

Ruling 2 — the URL map is a UNION, not a pure derivation

A pure registry derivation silently drops seven spellings that fold correctly today and whose singular has no static registry entry — themes, sharingRules, webhooks, skills, ragPipelines, analyticsCubes, connectors (plus emailTemplates). These are plugin-registered kinds carried only by the manifest map; protocol.code-only-types.test.ts:465 annotates theme verbatim as "no static registry entry (plugin-registered)". A pure derivation would therefore regress /meta/themes and break this card's mandatory positive control rather than satisfy it.

So: URL map = registry-derived spellings ∪ declared irregular/camelCase spellings ∪ runtime-registered plugin kinds. Prime Directive #8's goal — a newly declared type cannot arrive unmapped — is fully served by the derived limb alone; the other limbs keep it from overreaching into a population it was never about.

The refusal is additionally to be a purely static rule rather than threading the live registered-type set into a module-level function, so the positive control holds by construction rather than by coverage. Acceptance is the invariant, not a particular predicate: (1) no spelling that works today may stop working, and (2) no unmapped spelling of a declared type may answer 200.

Verified before any edit

The card's blast-radius table is unchanged since bcea363 — re-derived against origin/main: 26 registry entries, 29 map keys, and exactly four registry types with no singular target (field, seed, external_catalog, translation, same flags). email_template confirmed mapped only as camelCase emailTemplates, with /meta/email_templates unmapped. metadata-authoring-lint.ts imports the manifest map at line 60 and iterates it at 171 and 340, so a fields: key would enter the walker's collection set at both — which is why option 1 stays rejected and the manifest map stays untouched.

---

Generated by Claude Code