[objectstack-fleet]

domain:server#3 · os-bill · session_01Utp6CXTiQqG1Y4zdXMck85

Requested by Bill · project thread

Fixes #30542

Clause-②: yes (narrowing)
Metadata-protocol: none
Skills-docs: follow-up #30505

维护者速读

1. 改了什么：PR feat(metadata-protocol,objectql): open the declared override for a package's action (ADR-0146 D9) #30497 留下的四处收口。安装门按基包的代码原件判断动作覆盖；保存门把动作覆盖的基包按 OBJECT:NAME 认，和 os validate、安装门一致；只有覆盖声明的那个基包的 handler 才垫在覆盖下面，别的注册（包括不带包名的）照常替换并告警。
2. 为什么改：objectql: a declared .custom action override has four door and boot-order loose ends left by PR #30497 #30542。四处都是保存门、安装门、读和运行之间的分歧：安装门会误拒一个把收紧放回基包原样的 v2；保存门会放行一个把动作挪到别的对象上的覆盖；另一个基包的 .custom 行在真基包注册前绑上后会一直跑，而读已经不认它；不带包名的注册垫到覆盖下面时文档说告警、实际没有。
3. 风险与回滚：BREAKING 只有一条，保存门现在拒绝把动作挪到别的对象上的声明覆盖（403 NOT_OVERRIDABLE，规则 declared_package_ships_no_such_item），这条形状 os validate 和安装门本来就拒。其余三处只改判断依据或日志。单一提供方的正常部署不受影响。回滚即 revert。
4. 先看：engine-actions.ts 的 arrivesAsDeclaredBase（运行时谁能垫在覆盖下面）；protocol-packaged-base-refusal.ts 的 onItsObject；marketplace-install-local-plugin.ts 的 artifactOf。
5. 两分钟验证：pnpm --filter @objectstack/objectql exec vitest run src/plugin-authored-actions.test.ts src/protocol-flow-custom-override.test.ts，全绿（24 + 14）。
6. 需要你做的：无，席位落地。

What changes

Four loose ends PR #30497 left in the declared .custom action override (ADR-0146 D9), from its contract reviews (round 0 ③-2, ③-3; delta ③-7, ③-8). Each was measured on main (db04e5ce5) first, on the real engine, protocol and install door; all four reproduced.

1. Install-door ratchet (packages/cloud-connection/src/marketplace-install-local-plugin.ts)

• The managed install's override gate now hands the judge the installed base's code artifact (registry.getArtifactItem(type, name, base), kept only when it is that base's, at the same OBJECT:NAME identity) as baseItemOf, the item the protocol door's overrideWriteVerdict judges against. A registry that answers no artifact leaves the listed item, as before. A base delivered in the same install is still read off its body.
• Before, it handed the judge the item the protocol's per-package listing served. Once the pair's override is armed, that listing serves the override under the base's envelope, so a re-install of the pair was judged against its own previous version.

2. objectName pinned at the protocol door (packages/metadata-protocol/src/protocol-packaged-base-refusal.ts)

• overrideWriteVerdict keeps, for a declared action override, only the shipped artifacts on the override's own objectName (as shippers and as baseItemOf). An override that moves the base's action to another object therefore finds no shipper and is refused declared_package_ships_no_such_item: the rule os validate and the install door already gave it, since both key an action OBJECT:NAME (overrideWriteItemsOf). One private helper, overrideWriteActionObjectOf, now spells that object for both.
• Chosen over an action row in ITEM_KEY_DISCRIMINATORS: that table also keys the registry's item collections and the protocol's list merge, so a row there would re-key every action read, far wider than this door. An undeclared item is judged exactly as before.

3. Only the declared base's handler slots beneath an override (packages/objectql/src/engine-actions.ts, engine.ts, plugin.ts)

• ObjectQL#registerActionOverride takes an optional fifth argument, base: the package the override declares (overrides.package). The authored-action resync passes it, and the entry records it.
• registerAction under a key such an override holds slots the arriving handler beneath it only when the registry's code artifact of the action (getArtifactItem('action', name)) is that package's, on this object. That is the judgement the resync itself binds the override by once the artifact is registered, and every path registers a package's items before it binds its handlers (AppPlugin.start, the marketplace rehydrate, the install). Any other registration replaces the override and is warned like every other handler collision.
• So a row of another base's pair that ships the same OBJECT:NAME, bound on its own declaration before the real base registered, is replaced by the real base's handler when it arrives: the run now agrees with the reads, which decline that row for the real base. The next resync judges the row against the registered artifact and does not bind it. Chosen over rehydrate announcing metadata:reloaded: that signal re-runs every consumer's kernel:ready sweep (flows, security, translations) from inside the install plugin's own kernel:ready, which is neither cheap nor safe at boot.
• An override bound with no base keeps taking any package's handler beneath it.

4. Log level: warn (engine-actions.ts, engine.ts docblock)

• A registration with no package under an armed override is no package's, so it is not the declared base's: it now takes the replace-and-warn path, the one registerAction's docblock promises for an unpackaged registration displacing a package's handler. Before, it slotted beneath at debug. The docblock now names the exception precisely (the declared base's handler only).

Declarations. Clause-②: yes (narrowing), BREAKING: item 2 refuses at the save and publish doors a declared override the save door admitted before. Item 1 admits at the install door what the save door already admitted (a widening arm, outranked by the narrowing). Metadata-protocol: none: what an author can write did not narrow, because os validate (findOverrideDeclarationRefusals) and the managed install already keyed an action OBJECT:NAME on main and refused a moved-object override; the save door caught up with them (the #30095 precedent). The changeset carries the ADR-0087 disposition (not-required (no-migration-prescription): no schema key moves; nothing at rest is rewritten). Items 3 and 4 change which handler runs and a log level, not what an author can write. patch on the three packages the diff moves.

Tests

• packages/cloud-connection/src/marketplace-install-local-override-gate.test.ts, new describe "[objectql: a declared .custom action override has four door and boot-order loose ends left by PR #30497 #30542] the install door judges a declared action override against the base's code artifact": with the armed v1 served by the listing and the base's own action in the registry, a v2 back at the base's gates installs (200, saved), and a v2 that drops a gate the base carries is still refused 403 declared_action_widens_access, nothing written. The harness's registry gains an optional getArtifactItem; the existing cases pass none and read as before.
• packages/objectql/src/protocol-flow-custom-override.test.ts, new case in the [#30065] describe (real protocol over a real engine): a moved-object override is refused at the save door (code + status), overrideWriteVerdict answers rule declared_package_ships_no_such_item, nothing is stored and every read still serves the base; control: the same declaration on the base's object is admitted.
• packages/objectql/src/plugin-authored-actions.test.ts, two new cases on a real engine: the other-base row bound before the base registers runs until the real base binds, then the real base's body runs, one collision warning names both owners, isServedOverrideRowOf declines the row for the real base (and admits it for its own), and the next resync leaves the base bound; an unpackaged registration under an armed override replaces it with one warning naming both owners.

Measurement on main (db04e5c), then on the fix

Throwaway probes (deleted) on the real engine, protocol and install door, the same harness the #30497 tests use:

Item	Door	main	fix
1	protocol listing of the base after v1 is armed	serves V1 under com.example.showcase	same (unchanged)
1	protocol door, v2 back at the base's gates	ADMITTED	ADMITTED
1	install door gate (evaluateOverrideWriteGate), same v2	refused declared_action_widens_access	no refusal
2	protocol door, override with objectName moved	ADMITTED	REFUSED 403 NOT_OVERRIDABLE
2	install door, same body	refused declared_package_ships_no_such_item	same
2	os validate (findOverrideDeclarationRefusals)	refused declared_package_ships_no_such_item	same
3	other-base row resynced before the real base binds, then run	ran:OTHER BASE	ran:BASE BODY
3	isServedOverrideRowOf(row, realBase) (the reads' predicate)	false	false
4	unpackaged registerAction under an armed override	slotted beneath, 0 warnings	replaces, 1 warning

Ablations, one per fix

Each through scripts/ablation-replace.mjs (literal anchor, on-disk count, restore by trap), the pin run under the mutation:

• Item 1: artifactOf(...) ?? held → held: exactly "a v2 that relaxes the v1 tightening back to the base's own gates installs" fails (1 failed, 11 passed). A first attempt with the bare replacement held was refused by the tool as a no-op (the count did not move), so it did not run; the second used a marked replacement.
• Item 2 (metadata-protocol, read from dist/): the object comparison → !== 'ablate-30542-a2', rebuilt, ablation-dist-preflight found the marker in 2 built files; exactly "an override that moves the action to another object is refused…" fails (1 failed, 13 passed). Restore leg: rebuilt, --absent exit 0, tree clean, suite 14/14. A first attempt (true ||) was folded away by the build (marker absent from dist/), so its suite never ran.
• Item 3: the declared-base check → return true: exactly "another base's declared override of the same key is replaced…" fails (1 failed, 23 passed).
• Item 4: packageName === undefined → slot beneath: exactly "a registration with no package under an armed override replaces it…" fails (1 failed, 23 passed).

Acceptance notes

• The warning a replaced override logs is the generic collision sentence ("Two owners share one handler key only when both declare action …, rename one of them"), which fits the same-key misconfiguration the review names.
• The pair's undeclared same-named action on another object is still refused undeclared_same_name at the protocol door while os validate and the install door admit it (they key it OBJECT:NAME and find no collision). That is the pre-existing, stricter direction and outside this card; it narrows nothing new.

Verification

All readings on head 76e59ff17 (the fix merged with origin/main at 739c97273) unless a line says otherwise. Head accb62409 changes only the changeset's declaration line and levels (no source), so the readings below cover its source; on it check-changeset-no-major.mjs --base origin/main exit 0 and check-adr-0087-registration.mjs --base origin/main exit 0.

• Targeted pins after the merge and rebuild: objectql plugin-authored-actions + protocol-flow-custom-override 38/38, cloud-connection marketplace-install-local-override-gate 12/12, cli override-declarations 11/11, metadata-protocol protocol.packaged-base-refusal 91/91.
• Full suites on the fix before the merge (da065aea3): metadata-protocol 22447 passed, objectql 11023 passed, cloud-connection 880 passed; typecheck clean on all three. The merge brought in no change to the files this PR touches.
• Dogfood battery (title carries !): pnpm --filter @objectstack/dogfood test after the @objectstack/dogfood^... build, lock VERDICT command-exit 0, Test Files 420 passed | 3 skipped (423), Tests 3496 passed | 36 skipped (3532), no failure.

dispatch-gates on this head: 62 derived, 62 run, 0 NOT-MEASURED

node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack over the PR's change set, each family run and recorded COMMAND :: exit N; --ran reconciliation: 62 derived, 62 run, 0 NOT-MEASURED, 0 UNRUN, every exit 0. Also pnpm --filter @objectstack/spec check:liveness exit 0. On the first run (before the merge) two families did not measure and were re-run green: check-plugin-teardown-shape --self-test needed its pinned fixture commit in this shallow clone (fetched), and check:dual-build-cjs-loads needed every package built (PREREQUISITE NOT MET until the full build).

Human Minimum

• 1. Schemas start as Zod; packages/spec holds no runtime logic. (packages/spec not touched.)
• 2. Every name I added uses the casing for its kind.
• 3. No formatter ran; pnpm lint is CI's.
• 4. One issue, one branch off an up-to-date main, one pull request.
• 5. A change that publishes carries a changeset, and both declaration lines are filled in here and in the changeset.
• 6. packages/spec touched: not touched.
• 7. No hand edits to content/docs/references/, packages/*/CHANGELOG.md or content/docs/releases/.
• 8. Title, body and comments are in English.
• The Before Submitting list in CONTRIBUTING.md is done.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 3 package(s): @objectstack/cloud-connection, @objectstack/metadata-protocol, @objectstack/objectql, touching 10 documentable anchor(s).

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

• content/docs/data-modeling/objects.mdx (via ObjectQLPlugin (symbol, a top-level class))
• content/docs/kernel/services-checklist.mdx (via ObjectQLPlugin (symbol, a top-level class))
• content/docs/kernel/services.mdx (via ObjectQLPlugin (symbol, a top-level class))
• content/docs/permissions/authentication.mdx (via ObjectQLPlugin (symbol, a top-level class))
• content/docs/plugins/packages.mdx (via ObjectQLPlugin (symbol, a top-level class))
• content/docs/protocol/kernel/index.mdx (via ObjectQLPlugin (symbol, a top-level class))
• content/docs/ui/actions.mdx (via registerAction (symbol, a method of class ActionsFacet))

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

• content/docs/releases/v17/17-0.mdx (via ObjectQLPlugin (symbol, a top-level class))
• content/docs/releases/v17/17-1.mdx (via ObjectQLPlugin (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

• 1 anchor(s) matched too much of the corpus to be a work list: ObjectQL (symbol, 80 pages)
• 2 name(s) were too generic to anchor anything (single lowercase words)
• the SDK route bridge reached 61 of 219 client-bound route-ledger rows — the other 158 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 158: 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; 103 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 — 30 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 135c2fb82fcd2aeee208b6a8a372209c80655489 → packageMentionDocs.

Which tree this was computed on

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

node scripts/docs-audit/affected-docs.mjs --json 135c2fb82fcd2aeee208b6a8a372209c80655489

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

[objectstack-fleet]

domain:server#3 · os-bill · session_01Utp6CbPxYq1wQmUNWvMZkC

Contract review

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: 76e59ff173db77342e707ce7607ac5a2ec3a45af
Local-runs: probe — in a throwaway worktree at the head (pnpm install --frozen-lockfile, OS_SKIP_DTS=1 turbo run build over the objectql, cloud-connection, cli and metadata-protocol closures, 63 tasks): the PR's pins vitest run src/plugin-authored-actions.test.ts src/protocol-flow-custom-override.test.ts in objectql (38/38), src/marketplace-install-local-override-gate.test.ts in cloud-connection (12/12), src/utils/override-declarations.test.ts in cli (11/11), src/protocol.packaged-base-refusal.test.ts in metadata-protocol (91/91); full pnpm test of cloud-connection, objectql and metadata-protocol (cloud-connection 70 files, 880/880; objectql 552 files, 11027/11027; metadata-protocol 317 files passed, 4 skipped, 22450 passed / 26 skipped; each exit 0); check-changeset-no-major.mjs --base origin/main exit 0 (its level axis reports NOT APPLICABLE with no PR payload, so it graded no declaration locally) and check-adr-0087-registration.mjs --base origin/main exit 0; one reviewer probe, a throwaway cli test calling findOverrideDeclarationRefusals (the os validate walk) on a declared action override whose objectName is another object's, run twice (see ①.6); one ablation, git restore --source=origin/main of protocol-packaged-base-refusal.ts (the whole of fix 2 removed), metadata-protocol rebuilt with the fix's marker overrideWriteActionObjectOf counted 0 in dist/*.js: protocol-flow-custom-override.test.ts 1 failed / 13 passed, exactly the moved-object pin (expected undefined to match object { code, status }, the save admitted it); restore leg git checkout HEAD -- path, rebuilt, marker 3 in dist/index.js, 14/14, probe file deleted, git status --porcelain empty; worktree removed afterwards.
Scope: packages/metadata-protocol/src/protocol-packaged-base-refusal.ts, packages/cloud-connection/src/marketplace-install-local-plugin.ts, packages/objectql/src/engine-actions.ts, packages/objectql/src/engine.ts, packages/objectql/src/plugin.ts, packages/cloud-connection/src/marketplace-install-local-override-gate.test.ts, packages/objectql/src/plugin-authored-actions.test.ts, packages/objectql/src/protocol-flow-custom-override.test.ts + packages/metadata-protocol/src/protocol-artifact-lookup.ts (shippedArtifactsOf), packages/objectql/src/registry.ts (SchemaRegistry#getArtifactItem, the prefer-local and composite-scan tiers), packages/objectql/src/action-governance.ts (standaloneActionOwnerKey), packages/cli/src/utils/override-declarations.ts (findOverrideDeclarationRefusals, the os validate walk) and its test on origin/main, packages/runtime/src/app-artifact-handlers.ts (the registerAction binder, owner), packages/runtime/src/domains/actions.ts (resolveRouteActionDeclaration, the ADR-0066 D4 gate), packages/cloud-connection/src/marketplace-install-local-plugin.ts rehydrate and handleInstall (register before bindArtifactHandlers), docs/adr/0146 D9, .changeset/30542-action-override-doors-and-boot-order.md (prose face, read for its declaration lines, levels and marker), content/docs/concepts/metadata-lifecycle.mdx and skills/objectstack-platform/SKILL.md (read for the Skills-docs line)

Face: narrowing (Clause-②: yes (narrowing) line-initial on the PR body and the changeset). record-recognisers.mjs --paths on the nine changed paths decides no schema or governed face and defers to the changeset's Clause-②: line, which carries the (narrowing) arm, so --face narrowing sets the tier; the Scope floor is every path of the diff outside the prose face. Review by an isolated reader of PR #30612 (card #30542, which names four items from the contract reviews of PR #30497 / #30065). Reads: the card body, the PR body, the dev report (comment 6665387535, read for its claims only), git diff 739c9727...76e59ff1 (9 files, +222 −28; the head is the fix merged with origin/main at 739c9727; origin/main has since moved to 55d9dd44), the files in Scope at this head and on origin/main where named, the head's check-runs via REST (two readings, see ③). No reading below is taken from the dev's self-report; where the report's number appears it is beside my own.

① Derived judgments

1. Fix 1, the install-door ratchet (marketplace-install-local-plugin.ts, evaluateOverrideWriteGate). The gate's shippers are still read off the protocol's per-package listing keyed by listedIdentity (OBJECT:NAME for an action), unchanged. What moves is the item handed to judgeOverrideWrite as baseItemOf(base): for an installed (not delivered) base it is now registry.getArtifactItem(type, name, base) kept only when it is a plain object stamped _packageId === base whose listedIdentity equals the incoming item's identity (so the same object), else the listed item as before. SchemaRegistry#getArtifactItem with a currentPackageId resolves prefer-local (base:name) and returns only a code artifact, so the judge now sees the base's own action, not the armed override the listing serves under the base's envelope. A delivered base is still read off its body; a registry without getArtifactItem (the older harness cases) answers as before. This widens the install door's accept set to the save door's (overrideWriteVerdict already judged against the shipping artifact): the card's pin, a v2 back at the base's gates, is admitted, and the CONTROL (v2 dropping ai.requiresConfirmation) stays refused 403 NOT_OVERRIDABLE / declared_action_widens_access with nothing saved. The pin runs the real install route (plugin.start registers it on the raw app, the case posts to it). Right and complete against item 1.
2. Fix 2, objectName pinned at the protocol door (protocol-packaged-base-refusal.ts). A private overrideWriteActionObjectOf reads item.objectName (string, else ''), and overrideWriteItemsOf is refactored onto it with identical semantics (I compared the two expressions: a non-empty string objectName gives OBJECT:NAME, anything else the bare name). overrideWriteVerdict gains onItsObject, applied to the shippers set and to baseItemOf only when the request carries a declaration and the type folds to action: a shipping artifact on another object is no shipper, so the declared moved-object override is refused declared_package_ships_no_such_item, the rule os validate and the install door give it. An undeclared item, and every non-action type, is judged exactly as before (the onItsObject short-circuits are the first two disjuncts). judgeOverrideWrite itself is untouched. The pin goes through the real protocol.saveMetaItem on a real engine and asserts code: NOT_OVERRIDABLE, status: 403 (ADR-0112 envelope), the rule, no stored row, every read still serving SHIPPED, and a CONTROL on the base's own object admitted. The dev's choice not to add an action row to ITEM_KEY_DISCRIMINATORS is right: that table keys SchemaRegistry bundle collections and the protocol list merge, so a row would re-key every action read. Right and complete against item 2.
3. Fix 3, only the declared base slots beneath (engine-actions.ts, engine.ts, plugin.ts). registerActionOverride gains an optional fifth argument base, recorded on the entry; the resync (plugin.ts 4208, the only caller in packages/*/src) passes action.overrides?.package. registerAction under a key an override holds slots beneath only when arrivesAsDeclaredBase holds: the arriving registration names a package, and either the override recorded no base (legacy behaviour kept) or registry.getArtifactItem('action', actionName) is stamped _packageId === override.base with standaloneActionOwnerKey(artifact) === objectName. That is the same lookup isDeclaredArtifactActionOverride binds the override by once the artifact is registered (both pass no package to getArtifactItem), so the run and the resync judge by one predicate; in the two-shipper misconfiguration both decline the row, consistently. The ordering premise holds on every path I read: AppPlugin.start binds through bindAppArtifactHandlers after registerApp; the install (handleInstall step 4c) and the kernel:ready rehydrate both call bindArtifactHandlers after manifestService.register. ActionsHost gains registry through the actionsHost getter in engine.ts; the read is optional-chained, so a test double without a registry still works. The pin (real ObjectQL, real ObjectQLPlugin resync, a spied getArtifactItem) shows the other-base row running until the real base binds, then ran:BASE BODY, one collision warning naming both owners, isServedOverrideRowOf(row, BASE) === false and (row, OTHER) === true, and the next resync leaving the base bound. Right and complete against item 3; the dev's reason for not choosing the metadata:reloaded broadcast (it re-runs every consumer's kernel:ready sweep from inside the install plugin's own kernel:ready) is sound, and the card offered either tightening.
4. Fix 3 does not widen who may run an action. Who may run is decided at the route by resolveRouteActionDeclaration (runtime/src/domains/actions.ts, ADR-0066 D4) from the served declaration (the registry artifact or the authored row), never from the handler entry; the handler stack decides only which body runs. The new replace-and-warn branch is the pre-existing collision branch that registerAction already took on main for any two packages without an override in play. What changes is one case: another package's handler no longer slots beneath an override it is not the declared base of, so the body that runs for the key becomes the arriving package's instead of the override's, with the same warning any collision prints. No gate is dropped; the gates come from the declaration the reads serve, which already declined that row. No widening.
5. Fix 4, log level. packageName === undefined returns false from arrivesAsDeclaredBase, so an unpackaged registration under an armed override replaces it through the warning branch (replacedPackage: 'metadata-service', package: undefined) — the behaviour the registerAction docblock promised; the docblock in engine.ts is re-spelled to name the declared base's handler as the one exception. The card asked warn or docblock and the dev did warn, with the pin asserting one warning and the unpackaged body running. Right.
6. os validate on main already refused the moved-object declared override — my own reading, not the dev's table. A throwaway cli test calling findOverrideDeclarationRefusals with a base shipping log_call on crm_account and its .custom pair declaring overrides on log_call with objectName: 'partner_lead': refused [PAIR, 'declared_package_ships_no_such_item']; CONTROL on crm_account admitted. Run against the head's build (2/2) and again with protocol-packaged-base-refusal.ts restored from origin/main and metadata-protocol rebuilt, fix 2 absent from dist (2/2, same two verdicts). The cli walk keys an action OBJECT:NAME through overrideWriteItemsOf on main already (origin/main:packages/cli/src/utils/override-declarations.ts lines 109–128, and its committed control at line 65, "an action on another object"), and the install door keys the same way through listedIdentity. So two of the three doors, the CLI included, refused this shape before this PR; the save door alone admitted it. Ruling in ③.
7. Public surface. @objectstack/objectql: ObjectQL#registerActionOverride gains an optional trailing parameter and ActionHandlerEntry an optional base — a widening of a public signature, nothing removed or retyped. @objectstack/metadata-protocol: one private helper, no export change. @objectstack/cloud-connection: a private type widened. All three packages publish (private unset), so a changeset on each is owed and present. packages/spec untouched, no generated artifact owed.
8. Card closure. Fixes #30542 is right: items 1–3 fixed with the three pins the card asked for, item 4 answered with a named choice, one ablation per fix recorded by the dev and one reproduced here. First body line references the card; target main; draft; head repo = base repo; author objectstack-fleet[bot].
9. Acceptance note read. The dev's note that the pair's undeclared same-named action on another object is still refused undeclared_same_name at the protocol door while os validate and the install door admit it is a true, pre-existing disagreement in the stricter direction, outside this card and not widened here; a card for it is the lane seat's, not this PR's.

② Semver level

Inconsistent with the ruling — must-fix M1. The dev declares Metadata-protocol: narrowed and grades minor on all three packages. Under AGENTS.md Post-Task Checklist step 3 the line is "the change to what a metadata author can write", and check-changeset-no-major.mjs ruling A grades the level from that line alone (none takes patch; "none beside a minor is the half of the ruling with teeth"). What an author can write is the verdict table os validate gives, and ①.6 measures that os validate refused this exact shape on main: the protocol did not narrow, one door caught up to the verdict the other two already gave (Prime Directive #10, declared vs enforced). That is the precedent of record 6663292380 on PR #30564 (#30095), where the object publish door caught up to a CLI verdict and the line was ruled none with patch; the counter-precedent (PR #30270, narrowed) was the case where the CLI verdict itself moved. Nothing in packages/spec/authorable-surface/ moves, no key or value an author writes is added or refused by the rule table. The right declaration is Metadata-protocol: none, patch on @objectstack/metadata-protocol, @objectstack/objectql and @objectstack/cloud-connection, on the PR body and in the changeset. Clause-②: yes (narrowing) stays right (yes: the install door's accept set and a public signature widen; the arm: the save door's accept set narrows), the ! title, the BREAKING banner and the one ADR-0087 marker stay — "a non-protocol change, widening or breaking, ships patch and keeps its BREAKING banner and ADR-0087 disposition". Both local changeset gates exit 0 on the head as declared; they would exit 0 on the corrected declaration too (the gate's two contradictions are added under no and narrowed without an arm). The ADR-0087 marker not-required (no-migration-prescription) is right at this head: no schema key moves, nothing at rest is rewritten, and a moved-object override never ran there (its handler was never rebound), so there is no FROM to TO to prescribe.

③ Boundary flags

• Metadata-protocol narrowed vs none: none, with the reasoning and the measurement in ①.6 and ②. The dev's argument ("a declared override shape the save door accepted is now refused") describes an accept-set narrowing at one door, which the (narrowing) arm already carries; it is not a change to the protocol's own verdict. Must-fix M1.
• Skills-docs: follow-up #30505. No sentence in skills/** or content/docs/** becomes false with this PR. skills/objectstack-platform/SKILL.md line 128 lists the overridable types without action and says nothing about an action's object; skills/objectstack-automation/SKILL.md line 52 shows the overrides shape only. content/docs/concepts/metadata-lifecycle.mdx lines 132–134 say an action override "waits for ADR-0146 D9's conditions and is not served yet": that sentence is false on main already, made false by PR feat(metadata-protocol,objectql): open the declared override for a package's action (ADR-0146 D9) #30497 (bcdf8d34), not by this PR, and the doc was last touched by fix(metadata-protocol,cli): os migrate packageless-overlays lists a package-less view container cannot_declare, and --apply never attempts it #30380 — it belongs to the skills: teach the declared action override (an installed package's action renamed, hidden or adjusted through its .custom pair) and its access-widening refusal #30505 docs card, which today names only the skill file. No doc states that an action override may change the action's object, so nothing here turns false; follow-up #30505 is the right spelling and no edit is owed in this PR. The sentence the seat should add to skills: teach the declared action override (an installed package's action renamed, hidden or adjusted through its .custom pair) and its access-widening refusal #30505 is in the hand-back and repeated here: "A declared action override keeps the base action's objectName: every door (the save and publish doors, os validate, the managed install) matches the base's action by OBJECT:NAME, and an override that moves the action to another object is refused 403 NOT_OVERRIDABLE with rule declared_package_ships_no_such_item; and content/docs/concepts/metadata-lifecycle.mdx lines 132–134 still say an action override is not served yet, false since PR feat(metadata-protocol,objectql): open the declared override for a package's action (ADR-0146 D9) #30497 — correct it in the same docs change." Should-fix S2 for that card, not this PR.
• Should-fix S1 (not blocking; pre-existing text, same at all three doors): the refusal declared_package_ships_no_such_item reads "ships no action named 'X'" and offers "correct the name", which for the moved-object case names neither the object nor the fix (keep the base's objectName); the changeset body carries that remedy but the runtime message does not. The message is judgeOverrideWrite's on main and os validate prints the same, so it is a prescription-quality card for the lane, not a change this PR must make.
• Observation, no action: overrideWriteActionObjectOf, listedIdentity and the old overrideWriteItemsOf read objectName only, while the runtime key standaloneActionOwnerKey also reads object; the three doors agree with each other, and the spec's ActionSchema declares objectName, so no door disagrees on an authorable shape. Pre-existing and outside this card.
• Pins go through the real doors with CONTROLs — ①.1 (install route, 200 saved vs 403 nothing written), ①.2 (protocol.saveMetaItem, overrideWriteVerdict refuse vs admit), ①.3 (resync and run on a real engine, isServedOverrideRowOf both ways). Ablation reproduced here with its own numbers (Local-runs); the dev's four ablations are recorded in the PR body and the report.
• Dogfood battery. The Dogfood Regression Gate (n/3) shards are skipped on pull_request and the aggregate check is success with shards skipped, so CI carries no dogfood reading for this PR; the dev's reading names this head (76e59ff17, 420 files passed / 3 skipped, 3496 tests passed / 36 skipped, VERDICT exit 0 under the verify lock), full, no red. NOT MEASURED locally; the ! / (narrowing) entry requirement is met on the dev's pinned reading. The diff moves no send or write after an answer.
• Check-runs on 76e59ff17 (REST, three readings, last at 2026-11-05T18:25Z): 33 success, 13 skipped (opt-in and non-PR jobs), 1 in_progress (Test Core (4/8)), 0 failures. Lint · repo & tooling gates, Lint · ESLint, Lint · CI, release & engine gates, Lint · docs & code guards, Type Check · source gates, Type Check · workspace, Type Check · consumer gates, Type Check · debt ledger, Build Core, Test Core 1–3 and 5–8, Check Changeset, Governed Surface Queue Guard, PR-body guards are all success. Check Changeset passed on the head as declared and reads the declaration lines as carriers, so it does not decide ②; after M1 it passes on none + patch by the gate's own text. Not governed (check-governed-merges exit 0 per the dispatch); enqueue waits on M1 and on the last shard.
• Author: objectstack-fleet[bot] (relay) — no external login to name. security_findings: none, open_questions: [], premise_still_valid: true; nothing security-shaped beyond the PR's own stated rule was seen.

④ Design judgment (narrowing face)

Judged against the published spec on main: does the narrowing take a declared capability away at the consumer, or make the spec's own refusal real? It makes the spec's refusal real. ADR-0146 D2 and D9 admit a declared override only of an item the base ships, and the one identity every door names an action by is OBJECT:NAME (overrideWriteItemsOf, the walk os validate and the install door already took on main); the save door matched by name alone, so it admitted a declaration the protocol's own rule refused, and the admitted row never ran anywhere (its handler was keyed on the other object and never rebound). No author loses an override that worked. The three doors now give one answer from one helper, and the narrowing is scoped by two guards (a declaration present, type action) so nothing else moves. Fix 1 is the mirror in the widening direction: the install door judged against the listing's envelope, which after arming is the override itself, so a ratchet the protocol never declared is removed and the install door judges against the same artifact the save door does. Fix 3 closes the one case where the run and the reads disagreed, by the predicate the reads already use, and keeps the legacy behaviour for an override bound without a base, so no caller of the public method is broken. The cited code is read, not reviewed. Holds, with the level and line corrected per M1.

Must-fix: M1 (②). Should-fix: S1, S2 (③), both cards for the lane seat, not changes to this PR. Observations: ③ object-key spelling.

Implemented-by: claude/project-thread-izhot2
Reviewed-by: session_01Utp6CbPxYq1wQmUNWvMZkC

VERDICT: FAIL

Must-fixes:

• M1 — Metadata-protocol: none (not narrowed) on the PR body and the changeset, and patch (not minor) on @objectstack/metadata-protocol, @objectstack/objectql and @objectstack/cloud-connection in .changeset/30542-action-override-doors-and-boot-order.md; keep Clause-②: yes (narrowing), the !, the BREAKING banner, the ADR-0087 marker and the Skills-docs: follow-up #30505 line. Measured in ①.6; ruling in ②. A declaration-only head: the same reviewer's delta review suffices.

[objectstack-fleet]

domain:server#3 · os-bill · session_01Utp6CbPxYq1wQmUNWvMZkC

Contract review (delta)

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: accb6240985b185dd97422ccb4504f535631aded
Local-runs: none
Scope: .changeset/30542-action-override-doors-and-boot-order.md (declaration lines and package levels), the PR body (declaration lines and the Declarations paragraph). Round 0 record 6665887696 at 76e59ff173db77342e707ce7607ac5a2ec3a45af is the baseline; nothing it judged is re-stated.
Face: declaration-only delta. git diff 76e59ff17..accb62409 is one file, the changeset, +4 −4: the three package levels and the Metadata-protocol line. No source, test or docs path moved, so the round-0 code verdicts and the dev's battery reading at 76e59ff still cover this head's source.

① Derived judgments

1. M1 — FIXED. The changeset now reads '@objectstack/metadata-protocol': patch, '@objectstack/objectql': patch, '@objectstack/cloud-connection': patch and Metadata-protocol: none. Clause-②: yes (narrowing), the ! title, the BREAKING banner, the ADR-0087 not-required (no-migration-prescription) marker and Skills-docs: follow-up #30505 are unchanged, as round 0 required.
2. PR body. It now carries Metadata-protocol: none. The Declarations paragraph gives the round-0 reason (os validate and the managed install already keyed an action OBJECT:NAME on main; the save door caught up, the lint: the object publish door does not run validateSortableFields, so an object whose listViews sort a sortable:false field saves #30095 precedent) and says patch on the three packages. Fixes #30542 is right: all four card items are in the diff.
3. Gates. The dev reports check-changeset-no-major.mjs --base origin/main and check-adr-0087-registration.mjs --base origin/main both exit 0 at this head. The CI check-runs on this head are read by the seat record before landing.

② Semver level

patch on the three packages under Metadata-protocol: none, with the BREAKING banner kept for the (narrowing) arm. This is consistent with AGENTS.md step 3 and ruling A.

③ Boundary flags

None new. The scope sentence for #30505 is on that card (seat note). The should-fix about the refusal message is filed as #30623.

Implemented-by: claude/project-thread-izhot2
Reviewed-by: session_01Utp6CbPxYq1wQmUNWvMZkC

VERDICT: PASS

[objectstack-fleet]

domain:server#3 · os-bill · session_01Utp6CbPxYq1wQmUNWvMZkC

维护者速读（席位终稿）

• 改了什么：收掉 PR feat(metadata-protocol,objectql): open the declared override for a package's action (ADR-0146 D9) #30497 留下的四处不一致。安装门按基包的代码原件判断动作覆盖。保存门按 OBJECT:NAME 认动作覆盖的基包，和 os validate、安装门一致。只有覆盖声明的那个基包，它的 handler 才垫在覆盖下面；别的注册（包括不带包名的）照常替换，并告警。
• 为什么改：保存门、安装门、读和运行四处给出的答案不一样（objectql: a declared .custom action override has four door and boot-order loose ends left by PR #30497 #30542）。安装门误拒把收紧放回基包原样的 v2。保存门放行把动作挪到别的对象上的覆盖。另一个基包的行会在真基包之上一直运行，而读已经不认它。不带包名的注册垫到覆盖下面时没有告警。
• 风险与回滚：BREAKING 只有一条：保存门现在拒绝把动作挪到别的对象上的声明覆盖（403 NOT_OVERRIDABLE）。os validate 和安装门本来就拒绝这种写法，所以协议没变，三个包都走 patch。其余三处只改判断依据或日志级别，谁能运行动作仍由下发的声明决定，不放宽权限。回滚即 revert。
• 先看：packages/objectql/src/engine-actions.ts 的 arrivesAsDeclaredBase；packages/metadata-protocol/src/protocol-packaged-base-refusal.ts 的 onItsObject；packages/cloud-connection/src/marketplace-install-local-plugin.ts 的 baseItemOf。
• 两分钟验证：pnpm --filter @objectstack/objectql exec vitest run src/plugin-authored-actions.test.ts src/protocol-flow-custom-override.test.ts，全过（24 + 14）。
• 需要你做的：无。技能定档：非受管面、250 行，不需人审；契约复核 6665887696（round 0，只有声明一处要改）与 6665961225（Head-sha accb6240985b185dd97422ccb4504f535631aded，PASS），席位落地。

席位意见：同意落地。三道门从此给出同一个答案；唯一的收窄是保存门补上另两道门早有的拒绝。

席位核对

ACCEPT · head accb6240985b185dd97422ccb4504f535631aded · card #30542 · 2026-11-05T18:51Z.

• Shape: draft PR to main, relay author, Fixes #30542 only. 9 files, +222 −28. check-governed-merges.mjs --pr 30612 → exit 0, NOT governed, 250 ≤ 3000. No merge=os-regen path.
• Premise measured: the reviewer reproduced all four through the real doors. The os validate walk refuses a moved-object override both on main and at the head, which is the measurement behind Metadata-protocol: none. Ablating fix 2 reddened exactly the moved-object pin. Full suites: objectql 11027, metadata-protocol 22450, cloud-connection 880, all exit 0.
• Gates (check-runs on this head): 52 runs, 36 success, 15 path-gated skipped, 0 in progress (read 2026-11-05T18:51Z). One Check Changeset failure (127446088920) read the PR body before the r1 patch, which still said narrowed; the edited re-run on this same head (127447189007) is success, so it is superseded.
• Dogfood battery (! + narrowing): 76e59ff17 · os-verify-lock VERDICT command-exit 0 · Test Files 420 passed, 3 skipped (423) · Tests 3496 passed, 36 skipped (3532) · no failure (dev report 6665387535).
• Accepted deviation: the battery was read one head back, at 76e59ff17. accb62409 changes only the changeset's declaration and levels, so the source is identical (delta review 6665961225).
• Out of scope: declared_package_ships_no_such_item: the refusal names neither the object nor the remedy when an action override moves the action to another object #30623 (the declared_package_ships_no_such_item message for a moved object). The objectName sentence and the stale metadata-lifecycle.mdx sentence are added to skills: teach the declared action override (an installed package's action renamed, hidden or adjusted through its .custom pair) and its access-widening refusal #30505's scope (Skills-docs: follow-up #30505).
• Landing: BREAKING (!, Clause-②: yes (narrowing)), not governed, ≤ 3000 ⇒ the skill requires no human merge. Maintainer 13:47Z: 「技能不需要我审核的不应该等我」 ⇒ the seat lands it now.