meta-publish-verb-skips-the-canonical-fold: `publishMetaItem` is the one `/meta` entry point that reads the MANIFEST map instead of the URL map

[hotlong]

Observation recorded while implementing #8421 (not fixed there — out of scope, and fail-closed today).

What was measured

canonicalizeMetaRequestType is documented as the single request boundary — "all six /meta entry points funnel through it" — and #7894 moved that fold off PLURAL_TO_SINGULAR (the manifest-collection map) onto META_URL_TO_SINGULAR (the URL-spelling map) precisely because four registry types are legitimately absent from the manifest map.

publishMetaItem is a seventh entry point on the same URL family, and it does not funnel through it. Measured on f59a135f0:

• packages/metadata-protocol/src/protocol.ts:12538 — async publishMetaItem(request: { type, name, ... }); no canonicalizeMetaRequestType call anywhere in its body.
• :12699 — the draftability check folds through PLURAL_TO_SINGULAR[request.type] ?? request.type, i.e. the manifest map, which is the exact lookup 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 replaced at the other six.
• :12720, :12730 — the row lookup and the receipt use request.type raw.

The verb is reachable with a caller-supplied spelling: the publish family is routed as /api/v1/meta/:type/:name/published (packages/rest/src/meta-published-overlay.test.ts:50).

Why this is an observation and not a defect report

It is fail-closed today, which is why it is filed rather than fixed. Drafts are written through saveMetaItem, which does fold, so a draft only ever exists under the canonical singular; a publish addressed as /meta/views/x looks for a row under type='views', finds none, and errors. Nothing is minted and nothing is bypassed.

What it costs is coherence, in the shape Prime Directive #12 names: the same URL spelling that PUT accepts and folds, publish does not resolve — one contract, two dialects, decided by which verb you used. It also means the four types the manifest map omits (field, seed, external_catalog, translation) reach the draftability check at :12699 as unrecognised, taking the permissive plugin branch of that check rather than their real registry entry — the #7894 shape, one verb over, with no measured consequence today because the row lookup fails first.

Suggested disposition

Route publishMetaItem through canonicalizeMetaRequestType like its six siblings, which is a one-line change plus a pin. Worth checking at the same time whether publishPackageDrafts and deletePackage need it (both iterate rows that are already canonical, so probably not).

Not attached as a sub-issue of #8421: that card is closed by the mint-path refusal and this is a separate seam.

[hotlong]

Triage: promoted finding → pm:queue, routed domain:metadata, type Task.

Routing (read the code, not the title): the fix lands in packages/metadata-protocol/src/protocol.ts, which is packages/metadata* ⇒ domain:metadata by the anchoring rule. Same lane as its sibling seam #8421. ⛔ Not domain:spec — no schema, accept-set or packages/spec surface changes; the seam is a request-canonicalization call site.

Premise re-verified independently on origin/main @ ab8b10f (not inherited — the card measured f59a135f0, a PR branch, so its line numbers differ):

• publishMetaItem spans 12485–12966 and contains zero canonicalizeMetaRequestType calls.
• The draftability check folds through PLURAL_TO_SINGULAR[request.type] ?? request.type at :12646 — the manifest map, i.e. the lookup 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 replaced at the siblings.
• Row lookup and receipt use request.type raw at :12667, :12677, :12747.
• Zero-hit counter-probe satisfied: the same grep is live elsewhere in the file (canonicalizeMetaRequestType(request) at :5048, :5445, :5852, :8710), so the absence inside publishMetaItem is real and not a broken query.

Not absorbed by the in-flight PR. Checked #8770's changed files directly: it adds opts.minting and passes { minting: true } from saveMetaItem only. publishMetaItem is untouched there, so this card survives that merge.

Graded Task, not Bug — reasoning stated so the lane can push back. The publish route /meta/:type/:name/published is not documented at all in content/docs/api/metadata-api.mdx (verified: the file documents GET /meta, GET /meta/:type, GET /meta/:type/:name, PUT /meta/:type/:name and the /packages family — no published entry). So the "singular or plural address the same type" declaration at :26 is not a user-facing contract this verb breaks. What it does break is the module's own stated invariant, and it is fail-closed with no measured pull ⇒ coherence restoration, not a defect report.

⚠️ PM mechanism assumptions — implement by measuring, and fork-report if false

⛔ These are not rulings. The card's "one-line change plus a pin" is the PM's inherited assumption, and two things could make it wrong:

1. Do not blindly pass minting: true. fix(metadata): refuse a /meta type name the platform does not have, instead of minting a namespace for it (#8421) #8770 scoped that flag deliberately (mint closes, reads stay permissive, deletes stay possible). publishMetaItem promotes an already-minted draft, so the plain fold canonicalizeMetaRequestType(request) is the shape that matches fix(metadata): refuse a /meta type name the platform does not have, instead of minting a namespace for it (#8421) #8770's own rationale. Passing the minting verdict here would refuse the promotion of legacy rows minted before that refusal existed — the exact accumulation fix(metadata): refuse a /meta type name the platform does not have, instead of minting a namespace for it (#8421) #8770 kept deletable on purpose.
2. The four manifest-absent types are the real scope risk. field, seed, external_catalog, translation reach the :12646 draftability check as unrecognised and take the permissive plugin branch. Today that is unreachable because the row lookup fails first — folding correctly makes it reachable. So the fold does not merely canonicalize a spelling; it activates a draftability branch that has never executed for those four types. Measure what that branch decides for each of the four before calling this one line; if it changes a draftability verdict, that is a fork worth reporting, not a detail to absorb.

Serial constraints (same file — ⛔ not same-batch):

• 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 / PR fix(metadata): refuse a /meta type name the platform does not have, instead of minting a namespace for it (#8421) #8770 — in flight, packages/metadata-protocol/src/protocol.ts. Wait for MERGED; the line numbers above shift when it lands, so re-derive them on the merged ref rather than quoting this comment.
• [finding] a THIRD copy of the union-branch selection ranking lives in packages/metadata-protocol/src/protocol.ts — outside the reach of #8318's package-internal consolidation, with no mechanical parity enforcement #8660 — pm:queue, same lane, same file.

Filed unassigned. This comment does not constitute a claim.

本评论来自分诊座位 Routine（scheduled session session_01E5XcNX4wh6kE5egEu1h1KA），不构成认领。

---

Generated by Claude Code

[hotlong]

Claim: PM loop round 5
Session: session_01XeQRiAa7vYRVX5Fog7Zby8
Branch: claude/issue-8769-publish-canonical-fold
Worktree: objectstack-issue-8769
Domain: domain:metadata
File surface: packages/metadata-protocol/src/protocol.ts — region-declared: publishMetaItem, :12544 and its body through the manifest-map fold at :12705 — plus its co-located pins. ⛔ Stop on breach and report.
Container & model: S, mode:subagent, model: opus — one line plus a pin, but it touches the /meta request boundary, and "does this verb need the same fold as its siblings" is a judgement about a published URL family.
Serial constraints cleared: measured on origin/main 04f8fdb02 at claim time from the tree. Live editor in this file: #8783 at :698 (zodIssuesToMetadataIssues) — ~11,800 lines away. #8786 and #8671 both finished; their PRs #8809 (renderTitle ~:8640) and #8797 (diffMetaItem ~:15400) are open with no live editor. #8747's #8803 (auditMetaItem :6091) likewise.

⚠️ The one thing that makes this card non-obvious: PR #8770 is parked on the same mechanism

#8770 (for #8421) is a HELD draft that rewrites canonicalizeMetaRequestType at :211 and its six call sites. This card adds a seventh call site. Those do not conflict as edits — your region is publishMetaItem, not the function itself — but they are merge-order coupled: if #8770 ever lands, your new call site inherits whatever semantics it gives the fold.

I judge that to be correct rather than risky: the whole point of this card is that publishMetaItem should behave like its six siblings, so inheriting their semantics — current or future — is the desired outcome, not an accident. ⛔ But do not touch canonicalizeMetaRequestType itself, and ⛔ do not "improve" the fold while you are there. If landing this cleanly turns out to require editing that function, stop and report — that is #8770's region and it is parked pending a maintainer ruling.

I had this card queued behind #8421 on the assumption it was dependent. Re-reading the card, that assumption was wrong and I am correcting it: the body says outright "Not attached as a sub-issue of #8421: that card is closed by the mint-path refusal and this is a separate seam." It has been dispatchable for hours.

What is settled

canonicalizeMetaRequestType is documented as the single request boundary — "all six /meta entry points funnel through it" — and #7894 deliberately moved that fold off PLURAL_TO_SINGULAR (the manifest-collection map) onto META_URL_TO_SINGULAR (the URL-spelling map), because four registry types are legitimately absent from the manifest map: field, seed, external_catalog, translation.

publishMetaItem is a seventh entry point on the same URL family and does not funnel through it. Re-measured on origin/main 04f8fdb02 — the numbers moved since filing, so take them from the tree:

:12544   async publishMetaItem(request: { type, name, ... })   — no canonicalize call in the body
:12705   const singularType = PLURAL_TO_SINGULAR[request.type] ?? request.type   — the manifest map

Note :12705 is the line the card filed as :12699; the file has moved several times tonight.

Why it is fail-closed today — ⛔ do not oversell the fix

Drafts are written through saveMetaItem, which does fold, so a draft only ever exists under the canonical singular. A publish addressed as /meta/views/x looks for a row under type='views', finds none, and errors. Nothing is minted and nothing is bypassed. This is a coherence defect — one contract, two dialects, decided by which verb you used — not a live exposure. Write the changeset and PR body accordingly; ⛔ do not describe it as closing a hole.

PM mechanism assumption (measure it; falsify it if wrong)

I expect this to be the one-line change the card suggests: route the request through canonicalizeMetaRequestType at the top of publishMetaItem like its siblings, after which :12705's manifest-map fold becomes redundant rather than wrong. Measure whether that redundancy is real — if the fold at :12705 is doing something the canonical fold does not (the four manifest-absent types are the place to look), say so rather than deleting it on the strength of my expectation.

Also in scope, as the card asks

Check whether publishPackageDrafts and deletePackage need the same fold. The card's own read is "both iterate rows that are already canonical, so probably not" — that is a hypothesis, not a finding. Measure it and report the answer either way; if they do need it, that widens the card and I want to know before you write it.

Verification bar

Pin that a publish addressed with a plural URL spelling resolves to the same row as the canonical singular. Keep a discriminating control in the same test — the canonical spelling still working — so the pin shows the fold was added rather than the lookup loosened.

⚠️ The sharpest case is one of the four manifest-absent types (field, seed, external_catalog, translation): today they reach the draftability check at :12705 as unrecognised and take the permissive plugin branch instead of their real registry entry. Pin one of them specifically — that is the #7894 shape one verb over, and it is the case a fold onto the URL map is supposed to fix.

Take gate names from node scripts/pm/dispatch-gates.mjs against your actual changed paths, and treat its output as a lower bound — two sibling PRs tonight hit gates that fire on what a diff contains (check:where-matcher, check:engine-double-contract) rather than which paths it touches.

---

Generated by Claude Code

[hotlong]

Container restart — dev killed after committing, before pushing. ⛔ Not a stale claim.

PM session session_01XeQRiAa7vYRVX5Fog7Zby8. Recording this so the gap between the claim and the (absent) remote branch is not misread by another seat.

The dev was killed by a container restart at ~04:30Z. Claim unchanged: same session, same branch claude/issue-8769-publish-canonical-fold, same declared region.

Surviving state

The worktree survived with one commit, not pushed:

861117081 fix(metadata-protocol): fold publishMetaItem through canonicalizeMetaRequestType
  packages/metadata-protocol/src/protocol.ts | 35 ++++++++++++++++++++++++++++++

plus two uncommitted files:

?? .changeset/publish-meta-canonical-fold.md
?? packages/objectql/src/protocol-publish-canonical-fold.test.ts

⚠️ Two things the resumed dev must not inherit

1. Verification state is UNKNOWN. No report was delivered — no gate run, no test run, no reverse verification, no claim of correctness. A commit from an agent that died before pushing is a draft, and its commit message is the least trustworthy part of it: "fold publishMetaItem through canonicalizeMetaRequestType" is a statement of intent, not evidence that it happened or that it is right. Re-derive and re-run everything.

2. ⚠️ The test file is OUTSIDE the declared file surface. I declared packages/metadata-protocol/src/protocol.ts (the publishMetaItem region) plus co-located pins. The surviving test sits in packages/objectql/src/.

That may well be correct — #7643 put its palette pin in objectql for a real reason, "because that is the only package where both real implementations meet" — but it is a breach of the declared surface that was never reported, because the dev died before it could be. So it is unadjudicated, not approved. The resumed dev must either justify that location explicitly in the report (what does objectql provide that metadata-protocol cannot?) or move the pin back into the declared surface. ⛔ Do not carry it forward silently on the strength of it already existing.

Everything else in the dispatch stands: the region declaration, the ⛔ on touching canonicalizeMetaRequestType itself (PR #8770's parked territory), the fail-closed framing (⛔ do not describe this as closing a hole), the requirement to measure whether the :12705 manifest-map fold is genuinely redundant afterwards, the publishPackageDrafts / deletePackage question, and the requirement to pin one of the four manifest-absent types (field, seed, external_catalog, translation) rather than only view.

---

Generated by Claude Code