[objectstack-fleet]

Requested by Elon · project thread
Fixes #33389

Clause-②: no
Metadata-protocol: none

维护者速读

• 改了什么:SecurityCatalogNameConflictError 的两段报错文字(热安装与冷启动)不再说「岗位、权限集、能力每个部署一个名字」,改成「岗位和能力每个部署一个名字,权限集每个命名空间一个持有者」,并列出仍只有一个持有者的情形;措辞与 docs(spec): the permission set name describe and the permission sets page say one holder per namespace #33384 落地的 describe 一致。
• 为什么改:feat(core, objectql, metadata, metadata-protocol, plugin-security): a permission-set name is held once per namespace, judged by one predicate (ADR-0150 child B) #32742 之后权限集按 (包, 名字) 识别,两个不同命名空间的包可以各持有同名权限集,旧句子从那时起就是错的;拒绝本身一直只在 permissionSetHoldersMeet 判定相遇时触发,没有错。
• 风险与回滚:只改报错文字和一段代码注释,不动规则、错误码(NAMESPACE_CONFLICT)或状态码(422);@objectstack/objectql patch changeset。回滚即 revert。
• 先看:packages/objectql/src/registry.ts 新增的 SECURITY_CATALOG_NAME_RULE 常量,以及它在 coldBootConflictMessage 与 SecurityCatalogNameConflictError 构造函数里的两处引用。
• 两分钟验证:grep -n "A permission set holds one name per" packages/objectql/src/registry.ts,预期恰命中常量一行;grep -n "Positions, permission sets and capabilities each" packages/objectql/src/registry.ts 预期零命中。
• 需要你做的:无,席位落地。

What changes

• packages/objectql/src/registry.ts:
  • New module constant SECURITY_CATALOG_NAME_RULE, the one rule sentence both wordings of SecurityCatalogNameConflictError state: "Positions and capabilities each hold one name per deployment. A permission set holds one name per namespace: packages of two namespaces may each hold a set of one name, while two packages of one namespace, a package with no namespace, a platform package (base, system, sys), the environment and the platform-requested guest_portal share one set of it." This is the holder list of the permission set name describe that docs(spec): the permission set name describe and the permission sets page say one holder per namespace #33384 landed (packages/spec/src/security/permission.zod.ts), in the same words.
  • coldBootConflictMessage (the cold-boot refusal): FROM "Positions, permission sets and capabilities each hold one name per deployment: an assignment names a position or a permission set by its bare name, so with two holders the environment's stored item would be served in place of the package's definition." TO the rule sentence, then "Under that rule the environment's item and the package's share one definition of the name, so with two holders the environment's stored item would be served in place of the package's definition."
  • The hot-install message in the SecurityCatalogNameConflictError constructor: FROM "Positions, permission sets and capabilities each hold one name per deployment: an assignment names a position or a permission set by its bare name, with no package to tell two definitions apart, so with two holders which definition grants would depend on registration order." TO the rule sentence, then "Under that rule PACKAGE and each holder named here share one definition of the name, with nothing to tell two definitions of it apart, so with two holders which definition grants would depend on registration order."
  • The comment in SchemaRegistry.registerItem that explains why the three security catalog types are refused ("an assignment names a position or a permission set with no package context") now says a position or a capability is named with no package context and a permission set's name has one holder per namespace (ADR-0150 D2/D9, permissionSetHoldersMeet).
• .changeset/33389-security-catalog-conflict-text.md: @objectstack/objectql patch.

No rule changes. The doors, permissionSetHoldersMeet and the envelope (NAMESPACE_CONFLICT, 422) are untouched; the head and the remedy of each message are unchanged.

Tests

No test pinned the old sentence: git grep on 0c2aeb9643 for "Positions, permission sets and capabilities", "assignment names a", "no package to tell" and "served in place of the package" found only registry.ts itself, a docs page, an ADR, a migration entry and comments (listed under Acceptance notes); no assertion in objectql, runtime, plugin-security, cloud-connection, metadata-protocol or dogfood reads either sentence. No new pin is added: the refusal prose has no consumer that parses it, and the existing suites already assert the envelope (code and status) and the holders. Local readings at 2a6c935f7e, under os-verify-lock:

• objectql build closure, then vitest run on registry-security-catalog-namespace, protocol-permission-set-name-registry-reading, registry-security-catalog-names-held-by, manifest-service-residual-security-seal and environment-overlay-five-types: 5 files, 103 tests passed. objectql typecheck, including check:test-typecheck: OK.
• protocol-boot-hydration-scoped, package-scoped-exact-qualifier and registry-namespace-install-gate: 3 files, 314 tests passed.
• eslint --no-inline-config on registry.ts: exit 0.

Acceptance notes

Other places that say a permission set holds one name per deployment, read on 0c2aeb9643 and left alone, each for the reason given:

• packages/metadata-protocol/src/protocol-save-door-refusals.ts (the save door's Security catalog name conflict refusal): already says "A permission set holds one name per namespace" with the same holder list. Nothing to change.
• packages/spec/src/migrations/entries/semantic/18.security-catalog-environment-overlay-refused.ts (reason: "Positions, permission sets and capabilities hold one name per deployment"): an ADR-0087 migration entry describing a v18 change, in packages/spec, outside this lane. docs(spec): the permission set name describe and the permission sets page say one holder per namespace #33384 raised it as an open question.
• packages/spec/src/kernel/customization-package.ts:252 (the adr_0146_d6_security_catalog basis): describes ADR-0146 D6 as written.
• packages/objectql/src/security-catalog-namespace.ts module header: its first section states the original rule and its own "The narrowing: a permission set is one name per namespace" section already states the ADR-0150 narrowing.
• Test comments, not assertions: packages/objectql/src/protocol-boot-hydration-scoped.test.ts:217, packages/qa/dogfood/test/showcase-security.ts:32, packages/qa/dogfood/test/showcase-d7-default-profile.dogfood.test.ts:65.
• content/docs/permissions/delegated-administration.mdx:69 ("an assignment names a position or set, and the gate resolves the name in the security catalog"): a description of the delegated-admin gate, not of the holder rule.
• Decision records (ADR-0048 addendum, ADR-0131, ADR-0146 D6): not touched.

Verification

Derived gates at 2a6c935f7e: dispatch-gates --commands gave 65 families. 64 exited 0. check:dual-build-cjs-loads exited 3, a prerequisite not met because only the objectql closure was built, so it is NOT MEASURED; CI Build Core covers it. dispatch-gates --ran reconciles 65 of 65. The CI check-runs on this pull are the authority for every gate family.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

3 anchor(s) derived from 1 changed package(s); no hand-written page names any of them, so this run has nothing to list — not a clean bill of health. This check sees only pages that NAME a derived anchor: one that documents this change in prose, or enumerates it in an authoring dialect, names none and stays invisible to it on every run.

What this run could not see

• 1 name(s) were too generic to anchor anything (single lowercase words)
• the SDK route bridge reached 65 of 247 client-bound route-ledger rows — the other 182 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 182: 0 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 59 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 123 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.
• a key NAME is not a key, so the hand re-read the line above prescribes can land on the wrong schema. The same spelling is authorable on one governed type and a [REMOVED] tombstone on another for each of active, aria, joins, objects, template, tools and version (censused on [finding] tools is a key on BOTH AgentSchema (tombstoned, dead) and SkillSchema (live, cloud-attested), so a name-based search attributes skill examples to the agent key — it produced a false stop-the-line alarm on PR #19059 #19093 over the liveness ledger's governed types, top-level keys); nothing in a search result distinguishes the two, so a grep hit on a LIVE example reads as evidence about the DEAD key. Measured on fix(spec): the agent.tools liveness row says dead — it claimed live on a key the schema tombstoned #19059: content/docs/ai/agents.mdx was reported as contradicting the agent.tools tombstone over its tools: example at :161, which is inside the defineSkill({ block opened at :155 — the page was already correct. Settle ownership by PARSING the value against both schemas, never by the name: that literal PASSES SkillSchema, and as an AgentSchema it FAILS at tools with the tombstone prescription. ⛔ These names are not the whole class — a key retired through a .strict() guidance map leaves no tombstone in the walked shape and none of them here (tool.category, live as AIToolDefinition.category).

Coarse fallback — 21 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 0c2aeb9643b91ff7d53c6e745371cfe59a5e0a26 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 88339c9efa26f679734de0de02d41a2b7f1c90aa — the merge of head 2a6c935f7e18190b2dfadc580419952df0893af9 into base 0c2aeb9643b91ff7d53c6e745371cfe59a5e0a26, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 88339c9efa26f679734de0de02d41a2b7f1c90aa && git checkout 88339c9efa26f679734de0de02d41a2b7f1c90aa
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 0c2aeb9643b91ff7d53c6e745371cfe59a5e0a26 2a6c935f7e18190b2dfadc580419952df0893af9 && git checkout -B drift-repro 0c2aeb9643b91ff7d53c6e745371cfe59a5e0a26 && git merge --no-ff 2a6c935f7e18190b2dfadc580419952df0893af9

node scripts/docs-audit/affected-docs.mjs --json 0c2aeb9643b91ff7d53c6e745371cfe59a5e0a26

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

[objectstack-fleet]

domain:server#5 · os-elon-musk · session_016WV4cyrFFk86Jqf7Mp5Rzw
Request: review · area E2 · head 2a6c935