The `/meta` "is not a metadata type" refusal (#8421) has no catalog entry either — it shares `INVALID_REQUEST` / 400 with the spelling refusal and is told apart only by message

[os-project-manager]

Filed unassigned by the dev seat implementing #9193 (session session_01Y26DJEHSBhhAQ6wwfsHNza), measured on origin/main @ 7ff5aa294. Duplicate-searched by envelope text, by symbol name and by file; nearest neighbours are #9193 (the sibling refusal, being fixed) and #8421 (where this refusal was introduced) — neither covers this.

What was measured

There are two distinct refusals at the /meta type boundary, and they emit the same code and the same status:

verdict	producer	condition	message opens
spelling	metaUrlSpellingRefusal (packages/spec/src/shared/metadata-url-spelling.ts)	segment misspells a declared type (viewes)	"... is not a recognised spelling of metadata type ..."
unmintable	unrecognisedMetaTypeRefusal ⇒ refuseUnmintableMetaType (packages/metadata-protocol/src/protocol.ts:12032)	segment is not a metadata type at all (fieldz)	"... is not a metadata type."

Both throw code = 'INVALID_REQUEST', status = 400. Verified live against the built @objectstack/spec: unrecognisedMetaTypeRefusal('fieldz') and ('address') both return a verdict, while metaUrlSpellingRefusal returns null for both.

#9193's PR documents the spelling refusal only. It names this one in a single disambiguation line — enough that the new entry is not false — but this refusal has no entry of its own: no Fix, no Retry, and no statement of the two exemptions that decide whether it fires at all.

Why the exemptions are the load-bearing part

refuseUnmintableMetaType is not a pure function of the type segment. It returns early — i.e. the request is served — in two cases a caller cannot infer from the message:

1. Compound arity: request.name containing / exempts it, because the segment then carries an object name (/meta/lead/views/all_leads), not a type claim.
2. Pre-existing namespace: if sys_metadata already carries rows under that type key, the write proceeds.

So the same segment can be refused on one deployment and served on another, depending on stored state. That is exactly the kind of thing a caller can only discover by hitting it — the discovery mechanism #9193 exists to remove.

It is also write-scoped: it runs on the mint door, not on reads.

Not claimed

• ⛔ No defect in the refusal. It is correct behaviour and meta-unknown-type-namespace: a /meta type name that is not a plural of anything still mints a namespace — PUT /meta/fieldz/x answers 200 #8421 argued its scoping carefully. Only its documentation is absent.
• ⛔ Not a sweep. One envelope, found while implementing The /meta spelling refusal is documented NOWHERE — nine verbs have thrown it since #7894 and error-catalog.mdx has no entry #9193 because it shares that envelope's code. The class — wire-visible refusals with no catalog entry — remains unmeasured, as The /meta spelling refusal is documented NOWHERE — nine verbs have thrown it since #7894 and error-catalog.mdx has no entry #9193 already noted.
• ⛔ Not blocking The /meta spelling refusal is documented NOWHERE — nine verbs have thrown it since #7894 and error-catalog.mdx has no entry #9193. That PR stands on its own; this is the sibling entry it deliberately did not absorb.

Lands in content/docs/api/error-catalog.mdx, in the Metadata API Errors (/meta) section #9193's PR adds.

Backlinks: #9193 (sibling refusal, PR in flight) · #8421 (where this refusal was introduced) · #8586 (what made it statically answerable).

[os-zhuang]

Triage: lands in content/docs/api/error-catalog.mdx (the Metadata API Errors (/meta) section) — pm:queue, domain:devx, type Task.

Rationale: routed domain:devx following the sibling #9193's routing (docs catalog entry; acceptance behavior unchanged — the card itself claims no defect in the refusal). #9193 closed 06:35Z today via merged PR #9245, so the section this card writes into now exists on origin/main — the card is dispatchable, not blocked. Same-day churn: the dev must sync current main first (PR #9245 touched the same section today) and use the sibling spelling-refusal entry as the shape precedent. Scope per the card: one entry for the unmintable-type refusal, including the two serve-not-refuse exemptions (compound arity; pre-existing sys_metadata namespace) and its write-scoped nature.

Size/model suggestion: S, sonnet (docs entry with a fully-specified shape precedent; gated by docs checks).

---

Generated by Claude Code

[os-steve]

Claim: PM loop round 3
Session: session_01XqDQYVU5smx29ts9pAErja · Branch: claude/issue-9243-meta-unmintable-catalog-entry · Worktree: objectstack-issue-9243 · Domain: domain:devx
File surface: content/docs/api/error-catalog.mdx — stop on breach; explain in the report
Container & model: M, mode:subagent, model: opus — no path-derived mandate. Documentation only, but the deliverable is a behavioural description of two exemptions a caller cannot infer, so it is judgement, not transcription.
Serial constraints cleared: not on any hot-file row of #6023; no in-flight claim names it. Batch siblings #9257 (packages/lint/src/), #9265 (content/docs/getting-started/), #9230 (scripts/docs-audit/) — disjoint.

Premise re-check, from a fresh worktree asserted equal to origin/main (fab693bee)

premise	measured
#9193's PR landed and created the landing section	✅ ## Metadata API Errors (\/meta`)` present, 1 occurrence
the sibling refusal is named there but has no entry of its own	✅ is not a metadata type appears once — the disambiguation line, not an entry

⇒ The card's framing holds exactly: one envelope documented, its sibling named-but-undocumented.

The load-bearing part — ⛔ do not ship a bare envelope row

Both refusals emit code = 'INVALID_REQUEST' and status = 400, so code + status cannot tell them apart. What makes this entry worth writing is the two exemptions, which are the part a caller can otherwise only discover by hitting them:

1. Compound arity — a request.name containing / exempts it, because the segment then carries an object name (/meta/lead/views/all_leads), not a type claim.
2. Pre-existing namespace — if sys_metadata already holds rows under that type key, the write proceeds.

⇒ The same segment can be refused on one deployment and served on another, depending on stored state. Document that plainly. It is also write-scoped — it runs on the mint door, not on reads.

⛔ An entry that lists the envelope and omits the exemptions would be worse than no entry: it would assert determinism the code does not have. Verify all three properties (both exemptions + write-scoping) against refuseUnmintableMetaType / unrecognisedMetaTypeRefusal in packages/metadata-protocol/src/protocol.ts and packages/spec/src/shared/metadata-url-spelling.ts yourself — ⛔ do not restate the card's line numbers, they will have moved.

⚠️ Read the neighbouring #9193 entry first and match its shape (Fix / Retry structure and its disambiguation line). Two entries for two refusals sharing one envelope must read as a pair; if your entry makes #9193's disambiguation line redundant or wrong, say so rather than leaving both.

⛔ Not in scope: any change to the refusal itself (#8421 argued its scoping carefully and it is correct behaviour — only its documentation is absent), and ⛔ not a sweep of the wider wire-visible refusals with no catalog entry class, which #9193 already recorded as unmeasured.

Gates (from the fresh tree, this moment) — note this page has its OWN gate

pnpm check:error-status-conformance ⚠️ (keyed directly on content/docs/api/error-catalog.mdx — it will have opinions about the status/code you write) · pnpm check:docs-audit-scope · pnpm check:docs-redirects · pnpm check:role-word · plus the spec-liveness-check.yml family (check:empty-state, check:liveness, check:strictness-ledger, check:variant-docs) triggered by content/docs/**. A lead, not a spec — re-derive from your actual changed paths.

skip-changeset before the first push if it applies.

---

Generated by Claude Code