[objectstack-fleet]

domain:server#1 · os-project-manager · session_01R1q2xdtYgU6FKrZ7LgjPCC

Fixes #28858

Clause-②: no
Metadata-protocol: none

维护者速读

• 改了什么：对象扩展的 extend 写成短名，而 getObject 把它折叠到旧式 ns__name 键时，注册表把这条扩展登记到折叠后的那个键上，字段落到真正的对象，不再在旁边开一个没有所有者的第二个对象条目；同一写法每个包在日志里 warn 一次，并给出应写的键。
• 为什么改：fix(metadata-protocol)!: an object_extension item's refusals fit the item door, and its target is the key the object is registered under (#28834) #28853 让 object_extension 保存口拒绝这种写法，但清单的 objectExtensions 循环和启动时回灌存储行仍照原样登记，会多出一个幽灵条目，扩展的字段也到不了任何读取。
• 风险与回滚：低。只影响 extend 折叠到别的键的扩展；本仓库和 hotcrm 中这样的写法为 0。写对键、或对象恰好以该名字注册时行为不变。启动时不拒绝。回滚即还原本 PR。
• 先看：packages/objectql/src/registry.ts 的 registerObject 中 extend 分支新增的两行，以及 extensionTargetKey。
• 两分钟验证：pnpm --filter @objectstack/objectql exec vitest run src/registry-extension-legacy-key-fold.test.ts，预期 4/4。
• 需要你做的：无，席位落地。

What changes

registerObject's extend arm is the one place both entries reach: the manifest objectExtensions loop (engine.ts) and a stored object_extension row (registerObjectExtension). Right after the extend refusals, it now files the contribution under extensionTargetKey(extend). That is extend itself when an entry is registered under it or nothing is registered that it folds to. It is getObject's fold (resolveObjectKey) only when the fold names a different key. The folded spelling is named once at warn, keyed by spelling, resolved key and package (deduped like reportFieldPatchMisses), with the key to write. registerObjectExtension answers the resolved key, and the row delete's withdrawObjectExtension already resolves the same way.

There are no refusals at boot, no change to #28853's item gate, and computeFQN / parseFQN are untouched. There is no packages/spec/**, no new export, gate or error code.

Premise, measured (step 1). The count is 0 everywhere:

• in this repo (main 7e60dc2), the three non-test extend values are each a declared object's exact name, and no shipped object name contains __;
• in hotcrm (a598256), there are 0 extensions and 0 such names.

The case is still reachable by authoring: the spec dist's ObjectSchema accepts crm__account and survey__c, and a stored object row from the FQN era reaches it too. The seat kept the card on that ground.

Clause-② measured: no. No accept set moves and nothing is exported. For a package with the folded spelling (0 measured), the extension's fields now reach the object they name, where on main they reached no read.

Residual. A legacy owner that registers after the extension is not yet there to fold to, so that extension is filed as written, as on main.

Tests

Red first, ablation, controls

• objectql registry-extension-legacy-key-fold.test.ts (4 cases, from source):
  • manifest entry extend: 'case' beside the owner crm__case: the field lands on crm__case, no case contributors, one object listed, one warn across a re-read and a re-register;
  • registerObjectExtension answers crm__case, warns once, and withdrawing by the short name removes it;
  • controls: the registered key registers with no warn; an object registered exactly as case beside crm__case keeps its extension, with no warn.
  • Red on main 45efba2: 2 failed | 2 passed.
• runtime meta-object-extension-item-door-fit.test.ts, new case: a stored row respelled at rest to extend: 'case', then loadMetaFromDb. The field lands on crm__case, no case entry, one warn.
  • Red on main (objectql rebuilt from base with pnpm --filter, head-only string count 0 in dist): 1 failed | 5 passed, with a case contributor present. On head (rebuilt, count 2): 6/6.
  • fix(metadata-protocol)!: an object_extension item's refusals fit the item door, and its target is the key the object is registered under (#28834) #28853's item-gate pins stay green in the same file.
• Ablation: the resolution line deleted through ablation-replace.mjs gave both objectql pins red (2 failed | 2 passed). Restore: ok restored: blob == HEAD, git diff HEAD empty.

Suites, typecheck, lint, gates

Head 6db3a09f, under the verify lock:

• objectql: 524 files, 10030 tests passed;
• metadata-protocol: 297 files passed, 4 skipped; 22093 tests passed, 26 skipped.

pnpm typecheck in full (tsc plus check:test-typecheck) exits 0 for objectql and runtime, and both ledgers hold. eslint --no-inline-config on the 3 touched files: exit 0.

Gates: dispatch-gates.mjs --commands derived 63, all run, every exit 0. --ran: 63 derived, 63 run, 0 NOT-MEASURED.

Dogfood battery: not owed (no !, no narrowing arm).

🤖 Generated with Claude Code

https://claude.ai/code/session_01FEkQ5oTRCUNQ4EA3YV84sZ

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/objectql, touching 4 documentable anchor(s).

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

• content/docs/concepts/metadata-lifecycle.mdx (via SchemaRegistry (symbol, a top-level class))
• content/docs/deployment/environment-variables.mdx (via SchemaRegistry (symbol, a top-level class))
• content/docs/kernel/services-checklist.mdx (via SchemaRegistry (symbol, a top-level class))
• content/docs/plugins/adding-a-metadata-type.mdx (via SchemaRegistry (symbol, a top-level class))
• content/docs/protocol/kernel/error-handling.mdx (via registerObject (symbol, a method of class SchemaRegistry))
• content/docs/protocol/kernel/plugin-spec.mdx (via SchemaRegistry (symbol, a top-level class))

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

• content/docs/releases/v17/17-4.mdx (via SchemaRegistry (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

• the SDK route bridge reached 60 of 216 client-bound route-ledger rows — the other 156 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 156: 0 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 55 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 101 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 — 20 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 7fa9873f38f7a0158e3ce17338dcc0f446b113e3 → packageMentionDocs.

Which tree this was computed on

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

node scripts/docs-audit/affected-docs.mjs --json 7fa9873f38f7a0158e3ce17338dcc0f446b113e3

⚠️ 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 7fa9873f38f7a0158e3ce17338dcc0f446b113e3 → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[objectstack-fleet]

domain:server#1 · os-project-manager · session_01R1q2xdtYgU6FKrZ7LgjPCC

席位核对 · ACCEPT · domain:server seat 1 · os-project-manager · session_01R1q2xdtYgU6FKrZ7LgjPCC · 2026-11-02T03:30Z

Head 6db3a09f, report 6568075662 (on #28858), claim 6567101514. Clause-②: no, with no arm: no contract review is owed. The seat read the diff itself.

item	reading
Shape	Draft, base main, Fixes #28858. 4 files (+211 / −1): extensionTargetKey and its one call in registerObject's extend arm (objectql/src/registry.ts), the one place the manifest objectExtensions loop and a stored row's registerObjectExtension both reach. Plus a new objectql test, a runtime hydration case, and an objectql patch changeset. Metadata-protocol: none. No export, no packages/spec/**, no gate, no new error code.
Rule	An extend that getObject folds to a different (legacy ns__name) key is filed under the resolved key, and the spelling is named once at warn. It is never refused at boot (Startup registry reads). An exact-name entry or nothing to fold to keeps the written spelling, as before. withdrawObjectExtension already resolves through resolveObjectKey, so the delete of such a row now finds the contribution it filed. The #28853 item gate, computeFQN and parseFQN are unchanged.
Premise	Count 0 in this repo and in hotcrm, but authoring reaches it: the published ObjectSchema accepts an ns__name object name (spec-dist probe). Residual: a legacy owner registering after the extension is not yet there to fold to, so the extension is filed as written, as on main.
Evidence	CI green on head 6db3a09f (filter=latest: 35 success, 13 skipped, 0 failed). The report shows red on main (objectql 2 of 4; the runtime hydration case 1 of 6, a phantom case contributor) and green on head with #28853's pins, an ablation restored clean, the objectql and metadata-protocol suites, typecheck in full and 63/63 derived gates.
Landing	「按照 pm-dispatch 规则复核过的都授权」 (Leehom, 2026-10-25T11:35Z): ready and auto-merge through the relay, with every check green or an expected skip.

---

Generated by Claude Code