Ban `/` in metadata item names — retire compound-name addressing (maintainer-ruled direction): census, migration surface, staged plan

[os-trump]

Filed by the PM session on the maintainer's direct-dispatch instruction (2026-08-25, PM chat, verbatim and untranslated: 「我认为斜杠不该存在」 · 「斜杠不该存在，现在就立卡，你负责派发，然后给我结果」). PM session session_01H9StxQgG2DPA26XzZZqnJB. Suggested lane for triage: domain:spec (name grammar is contract surface); filed and dispatched under the maintainer direct-dispatch channel.

The ruling (direction — not re-adjudicable on this card)

Metadata item names must not contain /. The compound-name addressing convention (views/all_leads, crm/task — "sub-resources spelled as a slash inside the name string") is to be retired: item names converge on the platform's standard identifier grammar (/^[a-z][a-z0-9_]*$/, the same class every other identifier on the platform already uses), and the sub-resource relationship, where real, is expressed by structure (separate section/parent parameter or containment), never by a separator inside the identity string.

Why (maintainer-endorsed reasoning, recorded for the implementer): identity-with-separator is the measured root cause of an entire defect family — URL arity mismatches (#12106: four SDK methods 404), dual-arity route mounting obligations (#7526, #11712, #11932/PR #12105), route-shadowing hazards (measured in PR #12105), and a two-rule URL-spelling split inside one SDK file. Every platform identifier except item names is already slash-free by declared grammar.

This card = phase 1 only: census + migration surface + staged plan. ⛔ Report-only

Named, falsifiable premise (per the third-tier ruling form): the slash lives at the addressing boundary (REST/dispatcher fold :section/:name back into ${section}/${name}; SDK docblocks/tests; a handful of store keys), not deep in engine identity. Early readings supporting it, to be verified rather than inherited: literal slash-names grep to SDK docs/tests + protocol docs only — zero hits in packages/platform-objects, engine packages, or examples/** authoring sources; the folds are at packages/rest/src/rest-server.ts:6552-6555 and packages/runtime/src/domains/meta.ts:336.

⛔ If the census falsifies the premise (slash-names are load-bearing engine identity, or the migration surface is explosive), report the fork with the evidence — do not soften the census to fit the ruling, and do not start implementing.

What to measure (each with commands the next reader can re-run; every zero beside a positive control)

1. Producers. Every code path that can create a slash-name: metadata-protocol store keying (publishMetaItem et al.), sys_metadata rows written on publish, draft ledger keys, CLI build/extract outputs, engine registries/loaders, Studio/metadata-admin save paths, examples corpus. Who writes views/all_leads-shaped names, and is the section half ever semantic (a real namespace) vs redundant with type?
2. Grammar status. Does spec/protocol constrain item names at all? Accept-probe the real protocol: a snake_case name (control, accepted), a one-slash name, a two-slash name, empty section. Believed unconstrained — measure, don't assume.
3. Consumers of compound addressing. Full inventory: SDK methods (the 6 unencoded + 4 encoded per Four SDK metadata methods build compound-name URLs against routes mounted in one arity only — measured 404, and getHistory/deleteItem encode while getAudit/getReferences/diffItem/rollbackItem do not #12106), REST single-arity slash-through + the mounted compound arities (getItem/saveItem twins, /published Three ledgered /meta routes are never mounted and die in the /meta/:type catch-all — the route audit can't see this class because it treats the ledger as ground truth for what's mounted #7526, ?mode=draft PUT The compound-name PUT /meta/:type/:section/:name never threads ?mode=draft, while its single-segment twin does — the fourth divergence closed, a fifth left open #11712, /publish A compound-name draft has no REST promotion door — POST /meta/:type/:name/publish is mounted in one arity while its read twin /published is mounted in both #11932/PR feat(rest): mount the compound-name per-item promotion door POST /meta/:type/:section/:name/publish (#11932) #12105 — merged today), docs pages (client-sdk.mdx:213, error-catalog.mdx:599), tests pinning unencoded URLs (client.test.ts:325-334, meta-automation-descriptors.test.ts:30, protocol.unrecognised-meta-type.test.ts:297-311).
4. Stored-data exposure. In a seeded/booted store (example apps): how many live rows/draft keys actually carry /? (A compound-name draft has no REST promotion door — POST /meta/:type/:name/publish is mounted in one arity while its read twin /published is mounted in both #11932's measurement seeded crm/task — is that shape test-only or does real authoring produce it?)

Deliverable

An os-dev-report (issue comment + JSON) carrying: the four census tables · the complete migration-surface inventory · a staged plan proposal with one card draft per stage (suggested shape, adjust to the evidence: D1 declare the name grammar in spec + loud publish-time refusal of NEW slash-names (Clause-② yes, contract tier) → D2 migrate existing stored slash-keys → D3 re-address REST/SDK (compound arities retired or re-keyed to explicit section params; the #12106 four-method defect dissolves here) → D4 docs/tests/changelog sweep) · per-stage Clause-② flags and blast radius · the premise verdict. Also state what phase 1 cannot see (cross-repo consumers in objectui/cloud; out-of-repo customer data).

⛔ No production code changes on this card. Out-of-scope findings filed as unassigned cards with back-links. ⛔ Do not revert or modify anything #11932/PR #12105 landed — supersession is D3's job, ruled separately.

Dispositions this card supersedes or blocks

• Four SDK metadata methods build compound-name URLs against routes mounted in one arity only — measured 404, and getHistory/deleteItem encode while getAudit/getReferences/diffItem/rollbackItem do not #12106 is pm:blocked on this card: its option-1/option-2 fork is superseded by this ruling (the defect dissolves at D3; no interim SDK/route work is dispatched while the surface is being retired).
• A compound-name draft has no REST promotion door — POST /meta/:type/:name/publish is mounted in one arity while its read twin /published is mounted in both #11932 / PR feat(rest): mount the compound-name per-item promotion door POST /meta/:type/:section/:name/publish (#11932) #12105 (landed) stay as-is until D3.

Refs: #12106 · #11932 / PR #12105 · #11712 · #7526 · content/docs/api/client-sdk.mdx:213 · content/docs/api/error-catalog.mdx:599.

[os-trump]

Claim: maintainer direct-dispatch (2026-08-25 PM chat session)
Session: session_01H9StxQgG2DPA26XzZZqnJB
Branch: claude/issue-12176-name-slash-ban-census
Worktree: objectstack-issue-12176
Domain: direct-dispatch (suggested domain:spec for triage; this claim rides the maintainer direct-dispatch channel — authorization verbatim in the card body)
File surface: report-only — no production code; a throwaway probe harness at most, restored under trap (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: opus — measurement + design-plan card; the eventual D1 spec-grammar implementation is a separate card at the contract-review tier, not this one
Clause-②: no — this card changes no contract accept/reject behavior and widens no public surface (it measures and plans; D1 will carry the Clause-② yes)
Serial constraints cleared: none — report-only, no file surface to collide; the mounted compound doors (#11932 / PR #12105, merged today) are read, never edited

Direct-dispatch audit (who / verbatim / where): the maintainer, PM chat session 2026-08-25: 「我认为斜杠不该存在」 · 「斜杠不该存在，现在就立卡，你负责派发，然后给我结果」.

---

Generated by Claude Code

[os-trump]

Phase 1 census — ban / in metadata item names

Measured on origin/main at 22c42c9b21a479b502583ae74ac588232564a6a8 (2026-08-25 19:50:12 +0800), in a dedicated worktree at that exact SHA. Report-only: final git status --porcelain empty, git diff origin/main empty.

PREMISE VERDICT: HOLDS — with one real coupling that must be designed for

The slash lives at the addressing boundary. Nothing in engine identity depends on it, no producer constructs one, and the migration surface is small and fully enumerable: 5 non-test source files, 3 mounted routes, 26 test files, 2 docs pages, 0 stored rows.

The premise is not falsified. Two measurements qualify it — design inputs for D1/D3, not reasons to stop:

1. The slash is currently load-bearing as a capability discriminator. protocol.ts refuseUnmintableMetaType contains if (request.name.includes('/')) return; — a slash in the name disables the unrecognised-metadata-type refusal. Measured (P9/P10): type fieldz + name a is refused 400; type fieldz + name a/b is accepted and stored. Banning slashes does not merely remove a spelling — it makes that refusal apply universally. That is a stricter, better platform, and it closes the residue the code itself documents, but it is a behaviour change D1 owns explicitly.
2. At the compound arity the :type segment carries an OBJECT name, not a metadata type. /metadata/lead/views/all_leads is type='lead', name='views/all_leads' — lead is runtime data. D3 must state how that addressing is expressed afterwards; it cannot simply drop a segment.

Census 1 — Producers: who can create a slash-name?

Nothing constructs one. The only entry path is the wire.

producer surface	constructs a slash-name?	positive control
examples/** authoring corpus	0	416 snake_case name: declarations reachable
packages/platform-objects	0	113 .ts files present
packages/objectql	0	280 .ts files
packages/metadata	0	64 .ts files
packages/core	0	96 .ts files
packages/cli build/extract	0	198 .ts files
JSON seeds / fixtures	0	460 JSON files carrying a "name" key
REST + dispatcher compound arity	YES — the sole producer	folds section + name into one string

grep -rn --include='*.ts' --include='*.mdx' -E "['\"\`](crm/task|views/all_leads)['\"\`]" . \
  --exclude-dir=node_modules --exclude-dir=dist
grep -rn --include='*.ts' -E "name: '[a-z][a-z0-9_]*'" examples/ --exclude-dir=node_modules | wc -l   # 416
grep -rn --include='*.ts' -E '\$\{[a-zA-Z_.?]+\}/\$\{[a-zA-Z_.?]+\}' packages/ examples/ \
  --exclude-dir=node_modules --exclude-dir=dist | grep -vE '\.test\.ts'

The last command's hits are all display/log/path composition — memory://type/name, datasource://…, error text, the metadata:reloaded event payload — never a stored item name. Worth flagging for D1: those composed keys are themselves ambiguous when a name contains a slash (view/views/all_leads), the same defect family the ruling targets.

Census 2 — Grammar status: UNCONSTRAINED, and far wider than slashes

packages/spec/src/kernel/metadata-plugin.zod.ts declares the item name as a bare name: z.string().describe('Item name') (two sites). Positive control: the snake_case grammar /^[a-z][a-z0-9_]*$/ is declared for other identifiers (shared/identifiers.zod.ts, kernel/plugin-structure.zod.ts, system/book.zod.ts, system/doc.zod.ts).

Accept-probe driven through the real saveMetaItem write path over a stub engine (the harness protocol.unrecognised-meta-type.test.ts uses — a gate inside saveMetaItem cannot be measured against a harness that mocks it). Variant A varies the addressing key holding the body's own name legal; variant B mirrors the key into the body. Predictions fixed before running; all confirmed.

#	addressing name	variant A	variant B	stored key
P1	all_leads (control)	ACCEPTED	ACCEPTED	name="all_leads"
P2	views/all_leads	ACCEPTED	ACCEPTED	name="views/all_leads"
P3	a/b/c	ACCEPTED	ACCEPTED	name="a/b/c"
P4	/all_leads (empty section)	ACCEPTED	ACCEPTED	name="/all_leads"
P5	views/ (empty leaf)	ACCEPTED	ACCEPTED	name="views/"
P6	//	ACCEPTED	ACCEPTED	name="//"
P7	"" (empty name)	ACCEPTED	ACCEPTED	name=""
P8	Views/All Leads	ACCEPTED	ACCEPTED	name="Views/All Leads"

#	type	name	verdict
P9	fieldz (unrecognised)	a	REFUSED INVALID_REQUEST 400
P10	fieldz (unrecognised)	a/b	ACCEPTED, stored type=fieldz name="a/b"

The control is load-bearing here. The first corrected run used an invalid body and refused all ten cases at 422 INVALID_METADATA; the control failing is what caught it. The table above is the run where P1 is ACCEPTED.

Two readings beyond the card's question:

• An empty string and // are accepted metadata item names. D1 is properly "declare a grammar", not "ban one character".
• A grammared sub-resource convention already exists in spec, and it uses a DOT. ViewItemNameSchema is /^[a-z][a-z0-9_]*(\.[a-z][a-z0-9_]*)+$/ — "Qualified view-item identity: object.viewKey — dotted snake_case segments, e.g. crm_lead.pipeline. Globally unique, and the object can be recovered from the prefix." The /meta write door does not apply it (variant B accepted Views/All Leads as a view body name), so the platform declares a strict dotted identity and enforces nothing. A declared-not-enforced gap sitting exactly where D1 must act — and it hands D1 a target spelling that is already contract.

Census 3 — Consumers of compound addressing

Compound arities actually mounted on this main: 3.

route	method	ledger row
/meta/:type/:section/:name	GET	disposition: sdk, client: meta.getItem
/meta/:type/:section/:name	PUT	disposition: sdk, client: meta.saveItem
/meta/:type/:section/:name/published	GET	disposition: sdk, client: meta.getPublished

PR #12105 has NOT landed. It is state: open, draft: false, merged: false, base e25403c. The card body and the dispatch both describe it as merged today; it is not. Verified twice: the GitHub API, and grep -c ':type/:section/:name/publish' rest-server.ts = 0 against a control of 3 for the /published door. (History greps could not settle this — the container's clone is shallow, 86 commits.)

Consequence the earlier measurement could not see: #12106 measured "on origin/main plus PR #12105" and therefore lists publishItem as working. On today's main it is not — its compound arity is unmounted, so it 404s like the other four. Today's main has five broken SDK methods, not four.

SDK, both clients (packages/client/src/index.ts — the scoped /environments/:environmentId client carries its own full meta namespace, easy to miss):

method	client	spelling	compound arity mounted?	result today
getItem	unscoped + scoped	unencoded	yes	works
saveItem	unscoped + scoped	unencoded	yes	works
getPublished	unscoped	unencoded	yes	works
publishItem	unscoped	unencoded	no (PR #12105 pending)	404
getReferences	unscoped	unencoded	no	404
getAudit	unscoped	unencoded	no	404
diffItem	unscoped	unencoded	no	404
rollbackItem	unscoped	unencoded	no	404
getHistory	unscoped + scoped	encodeURIComponent	n/a — one segment	works
deleteItem	unscoped + scoped	encodeURIComponent	n/a — one segment	works

Docs pages: content/docs/api/client-sdk.mdx, content/docs/api/error-catalog.mdx (2). Non-test source files carrying the convention: packages/client/src/index.ts, packages/metadata-protocol/src/protocol.ts, packages/rest/src/rest-server.ts, packages/rest/src/rest-route-ledger.ts, packages/runtime/src/domains/meta.ts (5). Test files: 26 genuine (8 further files match only on the unrelated page:section component type and are not part of this surface).

Fold sites are more numerous than hypothesised: three in rest-server.ts (the /published read fold, the GET compound assembly, the PUT compound assembly) and two in runtime/src/domains/meta.ts (parts.slice(1, -1).join('/') for the /published branch, parts.slice(1).join('/') for the item branch) — not two and one.

Census 4 — Stored-data exposure: ZERO

No seed, fixture, example, or JSON corpus in this repo stores a slash-bearing metadata name (controls above). Every literal crm/task / views/all_leads occurrence is a test input or a docblock. The crm/task shape #11932 measured is test-only: real authoring cannot produce it, because authoring goes through *.view.ts / *.object.ts sources whose names are snake_case, and no loader joins a slash into a name.

So D2's in-repo migration set is empty. Its real target is out-of-repo deployment data, which phase 1 cannot see.

The explicit question: is section ever a REAL namespace?

No — and this is the fact that decides D3.

• Mechanically: section is read at exactly 3 sites, all in rest-server.ts, and every one immediately re-folds it into a single string (${section}/${name}). Never stored separately, never filtered on, never enumerated, never compared. The protocol layer's own comment: "The protocol layer treats section/name as a single opaque key." The store keys on type|name|organization|state with name as one opaque string.
• Semantically it is not even consistent: in views/all_leads the section half is a kind; in crm/task it is a package/module. Two meanings, neither enforced, neither read.
• In data: zero stored compound names, so no pair of items shares a leaf name under different sections.

Therefore D3 does not need a section parameter — names flatten. One constraint: the flattening must transliterate (/ becomes _, giving views_all_leads), not drop the section half, because dropping it would collide two compound names sharing a leaf. Nothing in-repo would collide today, but the transliterating rule is the one that stays correct against out-of-repo data.

Migration surface, grouped by stage

D1 — Declare the item-name grammar in spec + loud publish-time refusal

Scope: packages/spec/src/kernel/metadata-plugin.zod.ts (the two z.string() name sites); the refusal in metadata-protocol's saveMetaItem path; reconcile refuseUnmintableMetaType's slash exemption; decide the relationship to the existing dotted ViewItemNameSchema. Clause ②: YES — narrows an accept set that today admits "", // and Views/All Leads. Blast radius: every metadata write door; the P9/P10 refusal changes direction (strictly more refusals). Size/tier: L, contract-review tier — the card that carries the ruling.
Note for the drafter: the grammar decision is wider than the slash. Recommend declaring /^[a-z][a-z0-9_]*$/ for the addressing key and stating explicitly whether the dotted qualified form remains legal, since ViewItemNameSchema already declares it and nothing enforces it.

D2 — Migrate existing stored slash-keys

Scope: an ADR-0087 conversion entry plus the existing migrateStoredMetadata vehicle (POST /meta/_migrate-stored, source: 'migrate-stored') — the machinery exists and already replays conversions on rehydration. Clause ②: no (data at rest). Blast radius: in-repo zero rows; out-of-repo deployments unknown from here. Size/tier: M. Ordering: must ship before D1's refusal reaches deployments, or a stored slash-name becomes unrewritable through the very door that would fix it.

D3 — Re-address REST + SDK

Scope: retire the 3 mounted compound arities and their ledger rows; flatten the 5 unencoded-but-unmounted SDK methods; resolve the encode/unencode split so one spelling is correct everywhere. #12106 dissolves here. Clause ②: YES — removes public routes. Blast radius: 5 source files, 26 test files, the route ledger, the #7526 live-mount parity gate, plus objectui/cloud consumers this phase cannot see. Size/tier: L, contract-review tier.

D4 — Docs, tests, changelog sweep

Scope: 2 docs pages, 26 test files, the changeset prose in .changeset/compound-meta-door-mode-draft.md. Clause ②: no. Blast radius: documentation and pins only. Size/tier: M.

Scheduling fork the PM should resolve first

PR #12105 is open and adds a FOURTH compound arity — it moves opposite to this ruling. Landing it means D3 retires four doors instead of three and D4's sweep grows by roughly four test files; closing it means the publishItem 404 stays open until D3. Per this card's instruction I have not touched it. A scheduling decision, not a technical one.

What phase 1 cannot see

• objectui / cloud consumers. The metadata-admin UI may build compound URLs; out of repo scope, deliberately not crossed. Unknown, not zero.
• Out-of-repo customer deployment data — the only place D2 can have real work.
• Whether any customer authoring tool emits slash names. In-repo authoring cannot.
• Live runtime behaviour of the unmounted SDK methods against a deployed cloud — measured statically here, live in Four SDK metadata methods build compound-name URLs against routes mounted in one arity only — measured 404, and getHistory/deleteItem encode while getAudit/getReferences/diffItem/rollbackItem do not #12106.

Verification

Report-only card; no production diff, so most gate families are NOT APPLICABLE and were not run rather than run-and-reported:

• check:nul-bytes — not owed: nothing committed; the throwaway probe never entered the index and is deleted.
• check:authorable-surface, check:api-surface, check:docs, changeset gates, check:engine-double-contract, check:error-code-casing, check:agent-model-declared — NOT APPLICABLE: no spec change, no export change, no new engine double, no new error code, no .claude/** edit, no user-visible change.
• Dependency-closure build under the shared verify lock: os-verify-lock: VERDICT command-exit 0 · held the lock 227s (3m47s) · waited 0s.
• Probe runs under the lock: VERDICT command-exit 0 · held the lock 10s. Harness carried trap restore EXIT INT TERM; restoration confirmed on disk each leg (TRAP: probe removed; present-after-restore=NO).
• Final tree: git status --porcelain empty; git diff origin/main empty; HEAD = 22c42c9b21a479b502583ae74ac588232564a6a8.

Branch claude/issue-12176-name-slash-ban-census was pushed as the standing write-route probe and is this claim's landing marker. It carries 0 commits ahead of main and no artifact; no PR is opened, per the card's report-only shape.

{
  "issue": 12176,
  "status": "done",
  "branch": "claude/issue-12176-name-slash-ban-census",
  "pr": null,
  "premise_still_valid": true,
  "summary": "Phase-1 census complete on origin/main@22c42c9b. PREMISE HOLDS: the slash lives at the addressing boundary — zero producers construct a slash-name (examples/platform-objects/objectql/metadata/core/cli/JSON seeds all zero, each beside a firing positive control), zero stored rows carry one, and the whole surface is 5 non-test source files, 3 mounted compound routes, 26 test files, 2 docs pages. Two qualifications reported rather than smoothed: (1) the slash is TODAY a capability discriminator — refuseUnmintableMetaType skips the unrecognised-type refusal when the name contains a slash, measured as type=fieldz+name='a' REFUSED 400 vs type=fieldz+name='a/b' ACCEPTED and stored, so D1 makes that refusal strictly wider; (2) at the compound arity the :type segment carries an OBJECT name, not a metadata type, so D3 cannot just drop a segment. Grammar is unconstrained far beyond slashes: empty string, double-slash and 'Views/All Leads' are all accepted and stored as item names. A grammared sub-resource convention already exists in spec and uses a DOT (ViewItemNameSchema, dotted snake_case, 'crm_lead.pipeline') but the /meta door does not enforce it — a declared-not-enforced gap D1 should absorb. The section half is NOT a real namespace: read at 3 sites, all of which immediately re-fold it into one opaque string; never stored, filtered or enumerated; its meaning is not even consistent (kind in 'views/all_leads', package in 'crm/task'). So D3 flattens names and needs no section parameter, provided it transliterates slash to underscore rather than dropping the section half. TWO CORRECTIONS TO THE DISPATCH'S PREMISES: PR #12105 is NOT merged (state open, merged:false; compound POST publish route absent from rest-server.ts, control /published present 3x) — so today's main has FIVE broken SDK methods, not #12106's four, publishItem included; and the folds are more numerous than hypothesised (three in rest-server.ts, two in runtime/domains/meta.ts, not two and one).",
  "tests": "Report-only: no production diff, so no gate family applies and none was run under a false claim. Dependency closure built under the shared lock: 'os-verify-lock: VERDICT command-exit 0 · held the lock 227s (3m47s) · waited 0s'. Accept-probe (throwaway, deleted) run under the lock: 'VERDICT command-exit 0 · held the lock 10s', vitest 'Test Files 1 passed (1)'. THE FIRST PROBE RUN WAS VACUOUS AND IS REPORTED AS SUCH: it asserted only toBeDefined() and this package's vitest reporter suppresses console.log, so ten green tests carried zero measurement; rewritten to write results to a file, and the control then FAILED (422 INVALID_METADATA on a snake_case name) because the body fixture was invalid, confounding all ten rows. Only the third run — control ACCEPTED — is reported. Probe harness carried trap restore EXIT INT TERM; restoration confirmed on disk after every leg ('TRAP: probe removed; present-after-restore=NO'), and the probe was a NEW file so restoration is deletion, verified by ls and by git status. Every zero in the census sits beside a positive control that fired (examples/ 416 snake_case name declarations; platform-objects 113 .ts; objectql 280; metadata 64; core 96; cli 198; 460 JSON files with a name key; and for the producer sweep the known section/name fold itself). Two zeros were rejected mid-census rather than reported: an initial driver-sql control returned 0 .ts files (wrong path), and an initial producer-grep zero was debugged rather than accepted because it failed to find a fold I knew existed. Final state: git status --porcelain empty, git diff origin/main empty, HEAD=22c42c9b21a479b502583ae74ac588232564a6a8.",
  "open_questions": [
    {
      "question": "PR #12105 is OPEN, not merged as this card's body and the dispatch both state, and it mounts a FOURTH compound arity — moving opposite to the ruling. Land it or close it?",
      "options": [
        "A — land it: the publishItem 404 closes now; D3 later retires four doors instead of three and D4's sweep grows by ~4 test files",
        "B — close it: no new surface is added in the direction being retired; publishItem stays 404 until D3",
        "C — leave it open and undecided until D1 lands"
      ],
      "recommendation": "B, on the four axes. Real business need: zero — no in-repo producer emits a compound name and no stored row carries one, so the door serves test traffic only. Long-term soundness: mounting a door in the same week its convention is ruled retired is the workaround shape Prime Directive #5 rejects. AI-authored-metadata safety: a newly mounted compound door is a fresh, documented invitation to author the exact shape D1 will refuse. Startup scope discipline: capability expansion with no measured pull. The cost of B — publishItem keeps 404ing — is real but is already the status quo and is one of five such methods, all of which D3 fixes at once. A scheduling call for the maintainer, not mine to make."
    },
    {
      "question": "D1's grammar decision is wider than the slash: empty string and double-slash are accepted item names today, and spec already declares a stricter DOTTED convention (ViewItemNameSchema) that the /meta door never applies. Does the dotted qualified form stay legal?",
      "options": [
        "A — addressing key becomes strictly lowercase snake_case; the dotted form is retired with the slash",
        "B — addressing key allows the dotted qualified form, so ViewItemNameSchema becomes enforced rather than decorative",
        "C — declare the flat grammar now and defer the dotted question to its own card"
      ],
      "recommendation": "B. Real business need: the dotted form is the one sub-resource spelling with a real consumer story — already declared, already globally unique, already recovers the owning object from its prefix, which is exactly the capability the compound arity was faking with a slash. Long-term soundness: converts a declared-not-enforced gap into enforcement instead of leaving a second dialect. AI-authored-metadata safety: a single declared-and-enforced grammar at the publish door is precisely the structural prevention the axis asks for, whereas retiring the dot too would leave sub-resource identity with no expressible form and invite a new ad-hoc separator. Startup scope discipline: B adds no new surface — it enforces one that already exists. The maintainer's ruling is specifically about the slash, so this needs confirming rather than assuming."
    }
  ],
  "out_of_scope_findings": []
}

---

Generated by Claude Code

[os-trump]

os-dev-report

Machine-readable payload for the PM scan. The HTML-comment marker on the full census comment above (#issuecomment-5410233954) was stripped by the body sanitizer — confirmed by reading the comment back, its stored body begins directly with the heading. No comment-edit tool is reachable from this seat (MCP exposes no update-comment method and direct REST returns "GitHub access is not enabled for this session"), so the marker is restored here as literal text instead of by editing that comment. The full four census tables, the migration-surface inventory and the staged D1–D4 plan are in that comment; this one carries only the JSON.

{
  "issue": 12176,
  "status": "done",
  "branch": "claude/issue-12176-name-slash-ban-census",
  "pr": null,
  "premise_still_valid": true,
  "summary": "Phase-1 census complete on origin/main@22c42c9b. PREMISE HOLDS: the slash lives at the addressing boundary — zero producers construct a slash-name (examples/platform-objects/objectql/metadata/core/cli/JSON seeds all zero, each beside a firing positive control), zero stored rows carry one, and the whole surface is 5 non-test source files, 3 mounted compound routes, 26 test files, 2 docs pages. Two qualifications reported rather than smoothed: (1) the slash is TODAY a capability discriminator — refuseUnmintableMetaType skips the unrecognised-type refusal when the name contains a slash, measured as type=fieldz+name='a' REFUSED 400 vs type=fieldz+name='a/b' ACCEPTED and stored, so D1 makes that refusal strictly wider; (2) at the compound arity the :type segment carries an OBJECT name, not a metadata type, so D3 cannot just drop a segment. Grammar is unconstrained far beyond slashes: empty string, double-slash and 'Views/All Leads' are all accepted and stored as item names. A grammared sub-resource convention already exists in spec and uses a DOT (ViewItemNameSchema, dotted snake_case, 'crm_lead.pipeline') but the /meta door does not enforce it — a declared-not-enforced gap D1 should absorb. The section half is NOT a real namespace: read at 3 sites, all of which immediately re-fold it into one opaque string; never stored, filtered or enumerated; its meaning is not even consistent (kind in 'views/all_leads', package in 'crm/task'). So D3 flattens names and needs no section parameter, provided it transliterates slash to underscore rather than dropping the section half. TWO CORRECTIONS TO THE DISPATCH'S PREMISES: PR #12105 is NOT merged (state open, merged:false; compound POST publish route absent from rest-server.ts, control /published present 3x) — so today's main has FIVE broken SDK methods, not #12106's four, publishItem included; and the folds are more numerous than hypothesised (three in rest-server.ts, two in runtime/domains/meta.ts, not two and one).",
  "tests": "Report-only: no production diff, so no gate family applies and none was run under a false claim. Dependency closure built under the shared lock: 'os-verify-lock: VERDICT command-exit 0 · held the lock 227s (3m47s) · waited 0s'. Accept-probe (throwaway, deleted) run under the lock: 'VERDICT command-exit 0 · held the lock 10s', vitest 'Test Files 1 passed (1)'. THE FIRST PROBE RUN WAS VACUOUS AND IS REPORTED AS SUCH: it asserted only toBeDefined() and this package's vitest reporter suppresses console.log, so ten green tests carried zero measurement; rewritten to write results to a file, and the control then FAILED (422 INVALID_METADATA on a snake_case name) because the body fixture was invalid, confounding all ten rows. Only the third run — control ACCEPTED — is reported. Probe harness carried trap restore EXIT INT TERM; restoration confirmed on disk after every leg ('TRAP: probe removed; present-after-restore=NO'), and the probe was a NEW file so restoration is deletion, verified by ls and by git status. Every zero in the census sits beside a positive control that fired (examples/ 416 snake_case name declarations; platform-objects 113 .ts; objectql 280; metadata 64; core 96; cli 198; 460 JSON files with a name key; and for the producer sweep the known section/name fold itself). Two zeros were rejected mid-census rather than reported: an initial driver-sql control returned 0 .ts files (wrong path), and an initial producer-grep zero was debugged rather than accepted because it failed to find a fold I knew existed. Final state: git status --porcelain empty, git diff origin/main empty, HEAD=22c42c9b21a479b502583ae74ac588232564a6a8.",
  "open_questions": [
    {
      "question": "PR #12105 is OPEN, not merged as this card's body and the dispatch both state, and it mounts a FOURTH compound arity — moving opposite to the ruling. Land it or close it?",
      "options": [
        "A — land it: the publishItem 404 closes now; D3 later retires four doors instead of three and D4's sweep grows by ~4 test files",
        "B — close it: no new surface is added in the direction being retired; publishItem stays 404 until D3",
        "C — leave it open and undecided until D1 lands"
      ],
      "recommendation": "B, on the four axes. Real business need: zero — no in-repo producer emits a compound name and no stored row carries one, so the door serves test traffic only. Long-term soundness: mounting a door in the same week its convention is ruled retired is the workaround shape Prime Directive #5 rejects. AI-authored-metadata safety: a newly mounted compound door is a fresh, documented invitation to author the exact shape D1 will refuse. Startup scope discipline: capability expansion with no measured pull. The cost of B — publishItem keeps 404ing — is real but is already the status quo and is one of five such methods, all of which D3 fixes at once. A scheduling call for the maintainer, not mine to make."
    },
    {
      "question": "D1's grammar decision is wider than the slash: empty string and double-slash are accepted item names today, and spec already declares a stricter DOTTED convention (ViewItemNameSchema) that the /meta door never applies. Does the dotted qualified form stay legal?",
      "options": [
        "A — addressing key becomes strictly lowercase snake_case; the dotted form is retired with the slash",
        "B — addressing key allows the dotted qualified form, so ViewItemNameSchema becomes enforced rather than decorative",
        "C — declare the flat grammar now and defer the dotted question to its own card"
      ],
      "recommendation": "B. Real business need: the dotted form is the one sub-resource spelling with a real consumer story — already declared, already globally unique, already recovers the owning object from its prefix, which is exactly the capability the compound arity was faking with a slash. Long-term soundness: converts a declared-not-enforced gap into enforcement instead of leaving a second dialect. AI-authored-metadata safety: a single declared-and-enforced grammar at the publish door is precisely the structural prevention the axis asks for, whereas retiring the dot too would leave sub-resource identity with no expressible form and invite a new ad-hoc separator. Startup scope discipline: B adds no new surface — it enforces one that already exists. The maintainer's ruling is specifically about the slash, so this needs confirming rather than assuming."
    }
  ],
  "out_of_scope_findings": []
}

---

Generated by Claude Code

[os-zhuang]

State correction from the domain:cli seat — PR #12105 did NOT land. ⛔ Not a comment on the ruling; a correction to a fact this card's census starts from.

⛔ To be clear about scope first: the direction on this card is ruled and ⛔ this seat does not re-adjudicate it. What follows corrects a state fact about a PR in this seat's lane, because phase 1's census is built on it.

What this card says

Three places state the compound /publish door is already on main:

• §3 Consumers of compound addressing — "/publish A compound-name draft has no REST promotion door — POST /meta/:type/:name/publish is mounted in one arity while its read twin /published is mounted in both #11932/PR feat(rest): mount the compound-name per-item promotion door POST /meta/:type/:section/:name/publish (#11932) #12105 — merged today", listed among "the mounted compound arities" to inventory;
• §Dispositions — "A compound-name draft has no REST promotion door — POST /meta/:type/:name/publish is mounted in one arity while its read twin /published is mounted in both #11932 / PR feat(rest): mount the compound-name per-item promotion door POST /meta/:type/:section/:name/publish (#11932) #12105 (landed) stay as-is until D3";
• §Deliverable — "⛔ Do not revert or modify anything A compound-name draft has no REST promotion door — POST /meta/:type/:name/publish is mounted in one arity while its read twin /published is mounted in both #11932/PR feat(rest): mount the compound-name per-item promotion door POST /meta/:type/:section/:name/publish (#11932) #12105 landed".

What is actually on main

PR #12105 was closed without merging at 12:24Z. The door was never mounted. Three independent readings, each with its control:

$ git fetch origin main && git log origin/main --oneline --grep='(#12105)' -1
(no output)
    reverse-check, a PR known merged:
$ git log origin/main --oneline --grep='(#12079)' -1
d114d5e14 feat(cli): carry the computed advisory lists on every `os build --json` failure exit (#12079)

$ git grep -c 'publishPath' origin/main -- packages/rest/src/rest-server.ts
(zero hits)
    reverse-check, a term known present in the same file:
$ git grep -c 'publishedPath' origin/main -- packages/rest/src/rest-server.ts
2

Plus the PR's own state: state: open → closed, merged: false, and a pull_request.closed event carrying outcome: "closed without merging".

publishPath is the loop variable the PR introduced; publishedPath is the pre-existing /published read twin. The zero is a real absence, not a broken pattern.

Why it matters to phase 1, concretely

§3 asks for a full inventory of compound-addressing consumers to retire. POST /meta/:type/:section/:name/publish is not one — it does not exist on main. A census that counts it will overstate the migration surface by a door, and D3's plan would carry a retirement step for something there is nothing to retire.

⭐ The related asymmetry is still real and still worth the census's attention, just the other way round: PUT and GET …/published are mounted in both arities; POST …/publish is mounted in one (single-segment only). That asymmetry was measured in the closed PR's own body against the live mount table, and it survives the closure.

What this seat is and is not doing

• ⛔ Not reopening feat(rest): mount the compound-name per-item promotion door POST /meta/:type/:section/:name/publish (#11932) #12105, ⛔ not re-dispatching A compound-name draft has no REST promotion door — POST /meta/:type/:name/publish is mounted in one arity while its read twin /published is mounted in both #11932, ⛔ not touching the direction.
• Card A compound-name draft has no REST promotion door — POST /meta/:type/:name/publish is mounted in one arity while its read twin /published is mounted in both #11932 is being moved to pm:blocked with Blocked-by: objectstack-ai/objectstack#12176, so it stops claiming to be in flight and its disposition rides with D3 rather than being pre-empted here.
• ⚠️ One process reading, stated factually and ⛔ without attribution, since the actor field is a shared identity across all agents: the HOLD comment on PR feat(rest): mount the compound-name per-item promotion door POST /meta/:type/:section/:name/publish (#11932) #12105 (12:19Z) said the PR should hold un-queued as the objection window and that "landing or closing follows the ruling". It was closed at 12:24Z, five minutes later, while this card describes the same PR as landed. Whether that was the fork being answered or a state mix-up is not something this seat can read; recording it so the next person does not have to reconstruct it.

---

Generated by Claude Code