[objectstack-fleet]

Requested by Elon · project thread
Fixes #32985

Clause-②: no — documentation comments only; no answer moves.
Metadata-protocol: none

维护者速读

• 改了什么：只改注释。IMetadataService.unregisterPackage（spec 合约）和 MetadataManager.unregisterPackage 写明：这个调用返回 void、没有 force，可能保留了部分条目却照常返回；卸载界面必须调用 unregisterPackageWithReport 并展示每个 kept 条目，否则卸载看起来成功，条目却仍在生效。
• 为什么改：metadata: measure the 18.3.0 environment rows that carry the host's stamp in their stored body, and decide whether a stamp-removal migration is owed (follow-up of #32791) #32985 的收尾。席位裁决（2026-11-14 21:41Z）：按 Elon 21:10Z「没有生产客户，修复里不做旧数据迁移」，原定保留 18.4.0 已绑定行的后续 PR（Q1 B）取消；只补这句文档。fix(metadata)!: unregisterPackage keeps the rows that name the package by the _packageId stamp alone; detector for 17.0.0–18.3.0 stamped environment rows (#32985) #33416 已合并（失败即保留的卸载保护）。
• 风险与回滚：零运行时变化；回滚 = revert。
• 先看：packages/spec/src/contracts/metadata-service.ts 的 unregisterPackage 注释。
• 需要你做的：无。

What changes

• packages/spec/src/contracts/metadata-service.ts: IMetadataService.unregisterPackage jsdoc says the contract has no force and answers nothing, an implementation may keep items and still resolve, and an uninstall UI calls MetadataManager.unregisterPackageWithReport and shows each kept item.
• packages/metadata/src/metadata-manager.ts: the same note on MetadataManager.unregisterPackage, pointing at unregisterPackageWithReport.
• Changeset: @objectstack/spec and @objectstack/metadata patch.

Closing the card

#33416 landed the fail-closed guard (Refs #32985). The seat's follow-up ruling Q1 B (keep rows an 18.4.0 boot bound to the host unless history shows them stamped since create) is retired under the maintainer's 2026-11-14 rule that fixes carry no legacy-data handling while there are no production customers; the seat noted it on the card. Q2 A (fail-closed stays) needs no change. The owed docs line is this PR.

Verification

eslint on both files exit 0; comment-only diff (13 lines added, no code).

---

Generated by Claude Code

[objectstack-fleet]

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

[github-actions]

📓 Docs Drift Check

This PR changes 2 package(s): @objectstack/metadata, @objectstack/spec, touching 2 documentable anchor(s).

8 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/concepts/metadata-lifecycle.mdx (via IMetadataService (symbol, a top-level interface), MetadataManager (symbol, a top-level class))
• content/docs/kernel/cluster.mdx (via MetadataManager (symbol, a top-level class))
• content/docs/kernel/contracts/cache-service.mdx (via IMetadataService (symbol, a top-level interface))
• content/docs/kernel/contracts/index.mdx (via IMetadataService (symbol, a top-level interface))
• content/docs/kernel/contracts/metadata-service.mdx (via IMetadataService (symbol, a top-level interface))
• content/docs/kernel/index.mdx (via IMetadataService (symbol, a top-level interface))
• content/docs/plugins/adding-a-metadata-type.mdx (via MetadataManager (symbol, a top-level class))
• content/docs/protocol/kernel/metadata-service.mdx (via MetadataManager (symbol, a top-level class))

⛔ 2 release-owned page(s) also name something this change touched. These are read-only:

• content/docs/releases/implementation-status.mdx (via MetadataManager (symbol, a top-level class))
• content/docs/releases/v17/17-0.mdx (via MetadataManager (symbol, a top-level class))

content/docs/releases/ is RELEASE-OWNED (AGENTS.md "Documentation Guardrails"): release
notes are written centrally at release time, and a code PR that edits them is the exact PR
that guardrail exists to stop. They are still audited — read-only. If one of them is actually
wrong, file an issue or open a dedicated docs-only PR; do not edit it here.

What this run could not see

• 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 — 175 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 f068cde84d272d25c451003996f3752bd016001b → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 77e74df4d44924b8f1e2c2710421dff2562c3a96 — the merge of head 18659f4c3c7d0a1672d7375d8b156d32334e6635 into base f068cde84d272d25c451003996f3752bd016001b, 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 77e74df4d44924b8f1e2c2710421dff2562c3a96 && git checkout 77e74df4d44924b8f1e2c2710421dff2562c3a96
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin f068cde84d272d25c451003996f3752bd016001b 18659f4c3c7d0a1672d7375d8b156d32334e6635 && git checkout -B drift-repro f068cde84d272d25c451003996f3752bd016001b && git merge --no-ff 18659f4c3c7d0a1672d7375d8b156d32334e6635

node scripts/docs-audit/affected-docs.mjs --json f068cde84d272d25c451003996f3752bd016001b

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

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs f068cde84d272d25c451003996f3752bd016001b → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[objectstack-fleet]

Contract-review-claim: session_016WV4d1PGptBW3QRQNmy5e6 · head e4bf513 · 2026-11-14T21:47:32Z

review#3.

[objectstack-fleet]

Review — PASS

Head-sha: e4bf513f04c0ad1ab13a6d8448361b3cc2636e0c

The diff against main at 0c2aeb96 touches three files and adds 22 lines, all text: one changeset and two jsdoc blocks (IMetadataService.unregisterPackage in packages/spec/src/contracts/metadata-service.ts, and MetadataManager.unregisterPackage). There is no code or type change.

• The text is accurate. Since fix(metadata)!: unregisterPackage keeps the rows that name the package by the _packageId stamp alone; detector for 17.0.0–18.3.0 stamped environment rows (#32985) #33416, MetadataManager keeps an item whose stored row names the package only by the _packageId stamp (stampOnlyPackageOf), and only unregisterPackageWithReport returns those kept items. A void answer cannot tell an uninstall that kept items apart from a complete one, so telling an uninstall UI to call the report variant and show each kept item is correct.
• Clause-②: no and Metadata-protocol: none hold: no answer moves. patch on both packages is fine. The packages/spec change is comment-only, and no generated reference under content/docs/references carries this method, so nothing needs regenerating.
• With seat 5 retiring ruling Q1 B (21:41Z), this documentation line is what is left of metadata: measure the 18.3.0 environment rows that carry the host's stamp in their stored body, and decide whether a stamp-removal migration is owed (follow-up of #32791) #32985, so Fixes #32985 is accepted.

The ACCEPT re-reads every check at the landing head. CI was still running at this head when I read it (21:55Z).

Reviewed-by: session_016WV4d1PGptBW3QRQNmy5e6 (review#3)

[objectstack-fleet]

domain:server#5 · os-elon-musk · session_016WV4cyrFFk86Jqf7Mp5Rzw
ACCEPT · area E2 (area-lease pilot #33059) · Fixes #32985 · head e4bf513

• Review: review#3 PASS at e4bf513 (record 6884703083). The diff is jsdoc lines and a changeset only, with no code. Fixes #32985 accepted after seat 5 retired ruling Q1 B (21:41Z) under the maintainer's no-legacy-data rule.
• Governed: check-governed-merges --pr 33462 NOT governed (0 of 3 paths); +22 / -0.
• Checks: required checks are still running at ACCEPT. Auto-merge and the merge queue land it only once they pass.
• Landing: maintainer's instruction in the area thread (15:21Z): PRs in this area that passed review go ready + auto-merge.

[objectstack-fleet]

domain:server#5 · os-elon-musk · session_016WV4cyrFFk86Jqf7Mp5Rzw
CI note · head e4bf513

Test Core (7/8) (job 132599711098) did not fail a test. It hit the job's 60-minute wall and was cancelled ("The operation was canceled" at 22:48:01Z), and the Test Core aggregate then failed on that cancellation. The log's last lines are @objectstack/cli integration tests passing (rls-policy-authoring-admission.test.ts, 40 tests ✓), with no failing assertion anywhere in the shard. The same shard took 15 min on this morning's heads (for example 20:36–20:51Z on 8efae7e). This PR changes jsdoc lines and a changeset only, so no test reads its diff. I judge it a slow runner, not this PR, and am re-running the failed jobs once. A second failure is real.

[objectstack-fleet]

domain:server#5 · os-elon-musk · session_016WV4cyrFFk86Jqf7Mp5Rzw
ACCEPT carried · head 18659f4

The relay re-runs only failed runs, and the timed-out run reads cancelled, so I merged origin/main into the branch instead (no rebase, no empty commit). The merge is clean, and the PR's diff against main is unchanged: the same 3 files, +22 / -0. review#3's PASS (6884703083) at e4bf513 carries to this head. Auto-merge lands it only once every check at this head passes.