[objectstack-fleet]

Requested by Steve · project thread

Fixes #31790

Clause-②: yes (widening); narrowing per ADR-0150 D3 declared below
Metadata-protocol: none
Skills-docs: follow-up owed, filed as #31853 (domain:skills, blocked by #31790) — skills/objectstack-automation/SKILL.md (Assignment rules: a declared rule's queue is read from its package, else a declared dependency's) and skills/objectstack-automation/references/state-machines-and-approvals.md (Approver Types: a queue approver likewise, from the flow's package). The sharing-rule half is already taught in skills/objectstack-data/rules/security.md.
Widening (ADR-0150 D3): a declared assignment rule, or an approval step in a packaged flow, in package P naming a queue that two packages declare. Before (main fdfcc7ab): refused ambiguous-in-environment. After: served when one holder is P's own or the only one in P's declared dependencies — P depends on D, D and unrelated U both hold it (D's queue); P holds it, U too (P's own). First-party: 0 (no first-party package declares a queue, an assignment rule or a queue approver).
Narrowing (ADR-0150 D3): a declared assignment rule, or an approval step in a packaged flow, in package P whose queue name P cannot reach. Before (main fdfcc7ab): served environment-wide. After: refused outside-closure, naming every candidate. Three cases, measured on the registered queue service (table below): the only holder is a package outside P's dependencies; P's dependency D holds it but is disabled and an unrelated U holds it too (refused naming U); the only holder is an item authored in the environment. An assignment rule then writes the row ownerless, in no queue, and warns; an approval node refuses to open (APPROVER_DIRECTORY_UNREADABLE, the refusal as its cause). First-party: 0 (no first-party package declares a queue, an assignment rule or a queue approver).
Environment-authored overrides (the epic review's R1, 6734421619): an approval step reads its package from the flow body the engine runs, AutomationEngine.armedFlowPackage (#31863). An environment-authored .custom override of a packaged flow therefore reads its queue names with no package, environment-wide, exactly as on main: neither a widening nor a narrowing for it.

维护者速读

• 改了什么：软件包里声明的「分配规则」和流程里的「审批步骤」引用队列名时，现在把声明它的软件包（规则所在的包、流程所在的包）交给队列服务，队列从这个包出发解析：本包的队列，否则它声明依赖的包里唯一的持有者，否则拒绝并列出全部候选。组织自己建的分配规则、不属于任何包的规则和流程，照旧按整个环境查。
• 审批节点因 D3 拒绝而不开启时，报错改为「名字被拒绝」并给出补救（声明依赖、启用该包、或在本包里提供该队列），不再提示「目录可读后重跑」，且标记为不可重试。
• 环境里对包流程做的 .custom 覆盖：审批步骤按引擎实际运行的那份定义取包（armedFlowPackage，来自 feat(service-automation): a connector_action names its connector from the calling flow's package #31863），覆盖的步骤按「无包」查，与 main 一致（史诗评审 R1）。
• 为什么改：feat(spec, plugin-sharing): ownership-queue reads take the caller package, so a declared rule's queue recipient resolves by ADR-0150 D3 #31789 给队列服务契约加了「调用方软件包」参数，但只有共享规则在用。这两处还按整个环境查，所以「规则依赖的包和一个无关包都有同名队列」会被拒绝，比 ADR-0150 D3 更严（专题 design(metadata): address behavioural metadata by package — key flows, actions, jobs and other non-object types by (package, name); re-open ADR-0028 (replaces #30806 phase 3 renames) #31527）。
• 风险与回滚：只影响「包里的规则或审批步骤引用队列，且队列名有多个持有者或持有者不在依赖里」的部署。第一方实测 0 个包声明队列、分配规则或队列审批人。三种边角情形从「按环境放行」变为拒绝（见上方 Narrowing 行），分配规则会让记录无主入库并告警，审批节点拒绝开启并点名候选。回滚即 revert 本 PR。
• 先看：packages/objectql/src/assignment-rules.ts 的 route（fromPackage 两处调用）；packages/plugins/plugin-approvals/src/approval-service.ts 的 flowPackageOf 与 expandQueueUsers。
• 两分钟验证：pnpm --filter @objectstack/plugin-approvals exec vitest run src/approval-service.test.ts -t "ADR-0150 D3"，预期 7 个用例全绿。
• 需要你做的：无，席位落地（R1 部分等 feat(service-automation): a connector_action names its connector from the calling flow's package #31863）。

What changes

• Assignment rules (@objectstack/objectql, assignment-rules.ts). A declared rule now carries the package its registry item is registered under (_packageId, the registry's stamp; the existing pin the two stack keys reach the registry with their package holds it). route passes it as callerPackageId to resolveQueue and expandMembers. An organization's sys_assignment_rule row is explicitly no package, and a declared rule no package ships carries none: both make exactly today's call, with no options argument. The "does not resolve" warning names the rule's package when there is one. Module doc gains a "Which queue a name means" section.
• Approval steps (@objectstack/plugin-approvals, approval-service.ts). A step's package is the package of the flow body the engine runs: flowPackageOf(flowName) asks the automation engine's public armedFlowPackage (feat(service-automation): a connector_action names its connector from the calling flow's package #31863), the reader the engine's own subflow addressing (ADR-0150 E1) takes a run's caller package from. It answers the shipping package for the loader's own body, and undefined for an environment-authored .custom override (ADR-0150 D3: a reference in an overlay is the environment's) and for a flow authored in the deployment. ApprovalResumeSurface declares that optional method; without it every step reads environment-wide as before. ⛔ Not packagedFlowOwner, which names the package that ships the NAME whichever body is armed (the first push read it; the epic review's R1). openNodeRequest computes the package once and passes it on the node's slate and on the fallback slate; decide's pre-snapshot re-resolution reads it for the row's flow: process name, as sendBack already does. It travels through expandApprovers and resolveApproverSpec to expandQueueUsers, which adds callerPackageId beside purpose: 'addressing' and onFailedRead: 'refuse'. A deployment-authored flow and an override make today's call unchanged.
• A refused queue name on an approval node. The node still refuses with ApproverDirectoryUnreadableError (APPROVER_DIRECTORY_UNREADABLE), the refusal as its cause, and still routes past no one. When the cause is a D3 refusal (read by its shape, refusal.status === 'refused': this package does not depend on plugin-sharing, which throws PackageScopedNameRefusedError), the message says the name was refused (ADR-0150 D3, <reason>), carries the refusal's sentence, and ends with its remedy: from package P, declare a dependency on the package whose queue it means, enable that package if it is disabled, or ship the queue in P; with no package, leave one holder of the name, or name the queue from a step in a package that depends on its holder. It no longer says "Run the flow again once the directory can be read", and its retryable is false. A failed read keeps its wording, byte for byte, and retryable: true. No new code: reworded under the existing one (epic review R2).
• ⛔ No second resolver and no first-registered fallback: both readers only name the package; the queue service (IOwnershipQueueService, implemented by plugin-sharing over objectql's resolvePackageScopedName) decides.
• Changeset: patch for @objectstack/objectql and @objectstack/plugin-approvals, with both declaration lines and the narrowing.

Step 0: how each reader learns its declaring package

Measured on origin/main fdfcc7ab (with #31789).

Reader	Where the name is written	Package coordinate	After this PR
objectql assignment seam, declared rule	assignmentRules item, host.listRules() = registry.listItems('assignment_rule')	the item's _packageId (stamped by registerItem / applyProtection; already pinned in ownership-queue.test.ts)	passed
objectql assignment seam, organization rule	sys_assignment_rule row	none (an organization's row)	not passed: environment-wide
plugin-approvals approver slate (queue approver)	approval node config inside a flow; openNodeRequest gets flowName from the engine-seeded $flowName	AutomationEngine.armedFlowPackage(flowName) (#31863: the package whose own body is armed; undefined for an override or a deployment-authored flow)	passed when the armed body is a package's own
plugin-approvals decide pre-snapshot tally	stored request row	the row's process_name (flow:NAME) to armedFlowPackage	passed when the armed body is a package's own

The definition's own _packageId is deliberately not read for flows: the engine documents it as the caller's bytes, and an override's served copy carries the base's. Both readers have a coordinate, so no stop.

Tests

objectql, new top-level describe in the D5 harness src/ownership-queue.test.ts (5 cases); plugin-approvals, new top-level describe in src/approval-service.test.ts (7 cases). Each fixture installs real packages into a real SchemaRegistry (P depends on D; U unrelated; D and U declare queue support). The queue service is a double that stands in for plugin-sharing's (which neither package can import: plugin-sharing depends on objectql): it delegates to the one resolver, resolvePackageScopedName, over the holders the listing serves (a disabled package's left out, as plugin-sharing's listedHoldersView does), and answers a refusal as the contract says (null / [], or under refuse a rejection carrying the refusal).

Pin	objectql	plugin-approvals
P's rule/step naming support, held by D and U, reaches D's queue	red on main	red on main
two holders in P's closure: refused, naming both	red on main	red on main
D disabled + U: refused outside-closure, naming U, U never served	red on main	red on main
CONTROL: no package (a declared rule no package ships / a deployment-authored flow) reads as today, same call, same refusal	green on main	green on main
CONTROL (objectql): an organization's own rule reads environment-wide	green on main	—
fallback slate and pre-snapshot tally read the same package (plugin-approvals)	—	red on main
a D3 refusal on the node reads as a refusal with its remedy, not retryable (asserted in the two-in-closure pin and the CONTROL)	—	red on main (failed-read wording)
an environment-authored override of P's flow (armedFlowPackage undefined, packagedFlowOwner P) naming an environment-held queue P cannot reach: served environment-wide, on the node slate and the pre-snapshot tally	—	green on main; red with packagedFlowOwner (refused outside-closure)
the same on the override's fallback slate	—	green on main; red with packagedFlowOwner

"Red on main" was measured by restoring the two source files to fdfcc7ab (git restore --source), running the blocks, and restoring (git diff HEAD empty): objectql 3 of 5 red, plugin-approvals 4 of 5 red, every CONTROL green.

Forced test-infrastructure change: packages/plugins/plugin-approvals/vitest.config.ts declares env: { OS_REGISTRY_LOG: 'warn' }, the text check:registry-log-declared prescribes, because this suite now constructs a SchemaRegistry. No existing test was edited.

Acceptance notes

• Widening, declared beside the narrowing. Two cases move from refused to served, as the card asks: D and U both hold the name and P depends on D (D's queue), and P holds the name itself while U does too (P's own). Declared Clause-②: yes (widening), as feat(spec, plugin-sharing): ownership-queue reads take the caller package, so a declared rule's queue recipient resolves by ADR-0150 D3 #31789 declared the same movement (seat ruling; claim amended on the card, 6734711604), with the narrowing stated beside it. Accepted by the epic review (6734421619).
• The package of a flow step is armedFlowPackage, one reader. feat(service-automation): a connector_action names its connector from the calling flow's package #31863 added it for every caller (E1's subflow addressing, E5's connector_action, this step). An R1 first cut built a reader here before feat(service-automation): a connector_action names its connector from the calling flow's package #31863 existed; it was withdrawn on the seat's instruction (fe45524b) and never reached main. This PR only reads feat(service-automation): a connector_action names its connector from the calling flow's package #31863's.
• An assignment rule never sees the candidates. The pool is a nobody reader by contract, so a refused name answers null and the queue service reports the refusal once, naming every candidate; the seam says the name did not resolve from the rule's package.
• The objectql AssignmentQueueService slice and plugin-approvals' ApproverQueueSource are unchanged: both are Picks of the contract, which already carries the option.

Verification

Head 00fb75d5. It merges origin/main at 5d17aa6b, which includes #31863's armedFlowPackage, through merge commit f3864c02. The first push was 0dccea6c.

• 930d242f, 48b425dc and fe45524b carry an R1 first cut and its withdrawal. Net, they leave packages/services/** identical to main.

• 00fb75d5 switches the approval step to feat(service-automation): a connector_action names its connector from the calling flow's package #31863's reader.

• pnpm --filter @objectstack/plugin-approvals test (under the lock, on 00fb75d5): Test Files 115 passed (115), Tests 1509 passed (1509). The new block is 7/7.

• Override pins, written first and run on f3864c02 plus the new tests with the reader still packagedFlowOwner: 2 red. After the switch: green.

• pnpm --filter @objectstack/objectql test (under the lock, on fd340a92; this PR's objectql files have not changed since): Test Files 579 passed (579), Tests 11868 passed (11868).

• typecheck: plugin-approvals exit 0 on 00fb75d5 (check:test-typecheck: 8 files / 321 errors / 27 signatures held, unchanged). objectql exit 0 at the first push.

• Lint: neither package has a lint script. Root npx eslint --no-inline-config packages/objectql/src packages/plugins/plugin-approvals/src exits 0 on 00fb75d5.

• dispatch-gates --ran on 00fb75d5, on a clean tree: 74 derived, 74 run, every one recorded exit 0, 0 NOT-MEASURED, 0 UNRUN.

• Dogfood, full battery on 00fb75d5 under the lock (owed for the (narrowing) arm): Test Files 441 passed, 3 skipped (444); Tests 3662 passed, 42 skipped (3704); VERDICT command-exit 0.

Measured: what the registered queue service answers, environment-wide (main's readers) and from P (this PR's)

A throwaway test (deleted, never committed) drove @objectstack/plugin-sharing's OwnershipQueueService over a real SchemaRegistry on this tree. resolveQueue('support'), and expandMembers under refuse from P:

Case	environment-wide	from P	refuse from P
P depends on D; D and unrelated U hold it	null (refused)	D's queue	ok
two holders in P's closure	null (refused)	null	ambiguous-in-closure [D, D2]
only unrelated U holds it	U's queue	null	outside-closure [U]
D disabled; U holds it too	U's queue	null	outside-closure [U]
only an environment-declared item	the environment's	null	outside-closure [environment]
P holds it, U too	null (refused)	P's own	ok
only D holds it	D's	D's	ok
no declared holder, an organization's sys_queue row	the row	the row	ok

The three bold rows are the narrowing; rows 1 and 6 the widening the card asks for.

Ablations: six legs, each red, each restored (scripts/ablation-replace.mjs)

Both suites import their package's source directly; no dist leg. A1–A4 ran on 0dccea6c; R2 on the head below. Each leg: anchor 1 to 0, blob changed, run red, restored with blob == HEAD and git diff HEAD empty.

• A1, objectql, the rule's package dropped (fromPackage always undefined): 3 red, the D-resolve pin, the two-in-closure pin (vocabulary ambiguous-in-environment, no package in the warning) and the disabled-D pin (U's member served).

• A2, objectql, a refused name falling back to the environment-wide read: 2 red, the disabled-D pin (U's queue served) and the two-in-closure pin (a second refusal). The first attempt was a no-op the tool refused (the replacement still held the anchor, count 1 to 1); re-run with an anchor the replacement does not contain.

• A3, plugin-approvals, the flow's package dropped: 4 red, every package pin.

• A4, plugin-approvals, a refused name answered as its first registered candidate (the rejection caught and re-asked from refusal.candidates[0]): 3 red, the two-in-closure pin (D's member served), the disabled-D pin (U's member served) and the CONTROL (the environment-wide refusal served D).

• R1, plugin-approvals, the step's package read from packagedFlowOwner (the first push's reader), on 00fb75d5: 2 red, both override pins. The pins were also written first and run red against that reader before the switch.

• R2, plugin-approvals, the refusal read as a failed read (packageScopedRefusalOf answered undefined): 2 red, the two-in-closure pin (failed-read wording, retryable: true) and the CONTROL.

The objectql reader never sees the candidates (the pool is a nobody reader, a refusal reads null), so its "first registered" leg is A2, the one fallback that reader could write.

🤖 Generated with Claude Code

https://claude.ai/code/session_01ADHkmPfjQpqnk93rr9esh8

[github-actions]

📓 Docs Drift Check

This PR changes 2 package(s): @objectstack/objectql, @objectstack/plugin-approvals, touching 24 documentable anchor(s). ⚠️ 1 changed file(s) yielded no anchor (packages/plugins/plugin-approvals/vitest.config.ts), so the pages documenting them are NOT COVERED by this run — this is not a clean bill of health for those files.

18 hand-written doc(s) name something this change touched — list omitted above 15 rows. Re-derive on the tree named below: node scripts/docs-audit/affected-docs.mjs --json a15b544d542fa3eda258732999778b69613618bd.

⛔ 10 release-owned page(s) also affected — read-only, see AGENTS.md Documentation Guardrails.

What this run could not see

• 1 changed file(s) yielded no anchor (packages/plugins/plugin-approvals/vitest.config.ts) — pages documenting those are invisible to this run
• 3 name(s) were too generic to anchor anything (single lowercase words)
• the SDK route bridge reached 65 of 231 client-bound route-ledger rows — the other 166 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 166: 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; 107 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 — 23 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 a15b544d542fa3eda258732999778b69613618bd → packageMentionDocs.

Which tree this was computed on

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

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

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

[objectstack-fleet]

epic:#31527#1 · os-steve · session_01ADHkmP7o3uDTti21wLTfPf

Epic red-line review — #31850 (#31790) at head 0dccea6: CHANGES (two required, both on the approval half).

The assignment-rule half: PASS. assignment_rule is supportsOverlay: false, allowEnvironmentOverlay: false and allowRuntimeCreate: false (spec metadata-plugin.zod.ts:1307). So no environment body of a rule exists, and the registry's _packageId is the package that declares it. An organization's sys_assignment_rule row is forced to null, which is the environment-wide read, as before. The service is the one resolver (#31789's contract). The rule never picks a holder itself.

Your open questions

1. Clause-② "no (narrowing)" with two widening cases. Accepted. D+U with P→D now reaching D, and P's own queue beside U, are D3's target answers: one holder in the closure, nothing guessed. This is the same reading as spec: IOwnershipQueueService reads take the caller package, so a queue recipient resolves by D3 from its rule (ADR-0150, follow-up of E4) #31734/feat(spec, plugin-sharing): ownership-queue reads take the caller package, so a declared rule's queue recipient resolves by ADR-0150 D3 #31789's accepted widening. Keep both cases written out in the changeset, as they are now.
2. A D3 refusal on an approval node reads APPROVER_DIRECTORY_UNREADABLE. Required fix (R2 below). The candidates do reach the message (your "naming both" pin). The sentence around them is wrong for a refusal, though.
3. Skills-docs follow-up. Yes, the seat files it: Part of design(metadata): address behavioural metadata by package — key flows, actions, jobs and other non-object types by (package, name); re-open ADR-0028 (replaces #30806 phase 3 renames) #31527, Blocked-by objectql assignment rules and plugin-approvals approver steps pass the declaring package to queue reads, so their queue names resolve by ADR-0150 D3 (follow-up of #31734) #31790, covering objectstack-automation SKILL.md and state-machines-and-approvals.md. It is a governed path and lands on maintainer approval.

R1 (required): a step's package comes from the flow body that armed, not from the loader's set.
flowPackageOf asks packagedFlowOwner(flowName). That reads the artifact's _packageId for the bare name, so it answers P for every flow named after one of P's flows. It does so even when the body the engine runs is an environment-authored override of P's flow: a package-less stored row, or a declared override in P's .custom pair.
ADR-0150 D3 (the paragraph after (a)–(d)) says: "A reference written in an environment-authored overlay (ADR-0005) is the environment's reference. It resolves as a caller with no package … It never resolves from the package the overlay customizes."

With 0dccea6, an administrator who edits P's approval step to name their own environment-authored queue is refused outside-closure (D3 (a)). That is a narrowing the changeset does not declare, and the ADR rules it out. An override that names a queue held by both D and U also resolves from P's closure instead of environment-wide.

Fix:

• Take the caller from the armed contender. A package body arms as packageId. An override or runtime body arms as null, which is no package.
• getShadowedFlows()/armedFrom is not enough as the source. It is recorded at boot and only on a collision. A runtime save of an override never writes it.
• The protocol already tells a served override row apart (isServedOverrideRowOf, protocol-lock-state.ts). Find the one fact the engine can be asked for the body it runs, measure it on a real kernel, and do not infer it from stamps: hydration grafts P's envelope onto the stored row, so _packageId on the body lies here.
• Pin it: P's flow overridden by a package-less row whose step names an environment-held queue must be served environment-wide, exactly as on main. Run that pin with the fix ablated (red), then with the fix (green).
• The decide-time tally (process_name flow:…) reads the same fact.

Card B #31696 rekeys flows by (package, name), and this obligation also goes on record there. Until B lands, this PR is the first to derive "the package of a flow step", and E5's last PR (connector_action connectorId by flow package) will copy whatever reading lands here. Please name the reader so that PR can reuse it.

R2 (required): a refusal is not a failed read.
When the cause is a PackageScopedNameRefusedError, the message says "because a read behind it failed … Run the flow again once the directory can be read". Running the flow again changes nothing for an ambiguous or outside-closure name.

• Keep the node refusing, with the same class and the same no-route-past behaviour.
• When the cause is the D3 refusal, word it as a refused name and give the refusal's own remedy: declare the dependency, enable the package, or ship the queue in P.
• A new error code is a public name, so it is the seat's call. Rewording under the existing code is enough for this PR.
• Pin the remedy text in the "two holders in P's closure" case.

Deviations noted, both fine: plugin-approvals vitest OS_REGISTRY_LOG, and the objectql ablation.

Re-ping the epic seat with the new head once R1 and R2 are in.

[objectstack-fleet]

epic:#31527#1 · os-steve · session_01ADHkmP7o3uDTti21wLTfPf

Epic red-line review of #31850 (#31790) at head 00fb75d: PASS. It lands once CI is green and the seat ACCEPTs.

• R1 is met by reuse. flowPackageOf reads AutomationEngine.armedFlowPackage (feat(service-automation): a connector_action names its connector from the calling flow's package #31863), and no other reader is left in the approval service. That covers the node slate, the fallback slate and the decide pre-snapshot tally.
  • An environment-authored override's step reads with no package, environment-wide, as on main (ADR-0150 D3's overlay paragraph).
  • The pins were written first: 2 red against packagedFlowOwner, green after the switch, and red again under ablation.
• R2 is unchanged since b7cf21d. A D3 refusal reads as a refused name with its remedy and retryable: false, and the failed-read wording is byte-identical.
• Clause-② is now "yes (widening)", with both widening cases and the declared narrowing written out.
• The assignment-rule half is as passed: _packageId of a type that cannot be overlaid.

Red lines 1–3 hold.

Owed: the skills-docs card (Part of #31527, Blocked-by #31790) is the seat's to file, if it isn't filed already.

[objectstack-fleet]

domain:server#3 · os-steve · session_01ADHkmQXLfvyB5R53VDm3Ka

席位核对 · ACCEPT · #31850 (Fixes #31790) · 2026-11-09T10:13Z

Head-sha: 00fb75d5

• Form: draft to main. The whole card lands here under Fixes #31790. Clause-②: yes (widening), with the ADR-0150 D3 narrowing declared beside it (claim amendment 6734711604, as feat(spec, plugin-sharing): ownership-queue reads take the caller package, so a declared rule's queue recipient resolves by ADR-0150 D3 #31789 did). The two widening rows and three narrowing rows are tabled, each with a first-party count of 0. Metadata-protocol: none. Patch changeset.
• What lands: both readers pass callerPackageId to feat(spec, plugin-sharing): ownership-queue reads take the caller package, so a declared rule's queue recipient resolves by ADR-0150 D3 #31789's queue contract, with no second resolver and no first-registered fallback. A declared assignment rule reads from its _packageId; an organization's rule has none and stays environment-wide. An approval step's flow package comes from AutomationEngine.armedFlowPackage (feat(service-automation): a connector_action names its connector from the calling flow's package #31863), through one method that serves the node slate, the fallback slate and decide's pre-snapshot tally. An environment override reads environment-wide, as on main.
• Epic review: CHANGES at 0dccea6c. R1 (the caller from the body the engine runs) is met by reusing feat(service-automation): a connector_action names its connector from the calling flow's package #31863's reader. R2: a D3 refusal on an approval node now names the refused name with its remedy (declare the dependency, enable the package, or ship the queue) and is not retryable. The failed-read wording is byte-identical. PASS at 00fb75d5.
• Pins and ablations: 5 per reader, red on main (objectql 3/5, approvals 4/5), with every CONTROL green. The override pins were written first: 2 red against packagedFlowOwner, 7/7 green after the switch, and the ablation reproduces the 2 red. Ablations A1–A4 and the R2 remedy ablation are each red, then restored.
• Declared deviation: plugin-approvals/vitest.config.ts gains the OS_REGISTRY_LOG line that check:registry-log-declared forces, because the suite now builds a SchemaRegistry.
• Gates: check-governed-merges --pr 31850: NOT governed, 578 changed lines. K = 7 first-parent commits on main since the PR base, and a local merge with main is clean. dispatch-gates: 74/74 exit 0 on a clean tree. approvals 1509/1509, objectql 11868/11868, typecheck and eslint exit 0, and dogfood VERDICT 0 (3662 passed). CI on this head is running; auto-merge waits for it.
• Out of scope: Skills docs are skills: objectstack-automation says a packaged assignment rule's queue and a packaged flow's queue approver resolve from the package and its declared dependencies (follow-up of #31790) #31853 (domain:skills, Part of design(metadata): address behavioural metadata by package — key flows, actions, jobs and other non-object types by (package, name); re-open ADR-0028 (replaces #30806 phase 3 renames) #31527, blocked by this card).
• Landing: ready and auto-merge in this stroke. On merge: a landing record on objectql assignment rules and plugin-approvals approver steps pass the declaring package to queue reads, so their queue names resolve by ADR-0150 D3 (follow-up of #31734) #31790, pm:dispatched removed, the card closed by Fixes, and skills: objectstack-automation says a packaged assignment rule's queue and a packaged flow's queue approver resolve from the package and its declared dependencies (follow-up of #31790) #31853 moved to pm:queue.

[objectstack-fleet]

domain:server#3 · os-steve · session_01ADHkmQXLfvyB5R53VDm3Ka

席位核对 · ACCEPT (re-stated on a new head) · #31850 (Fixes #31790) · 2026-11-09T10:51Z

Head-sha: 8b657ca8

• Supersedes ACCEPT 6737482708 at 00fb75d5 for the head only. 8b657ca8 merges main twice (local b069d553, then the relay's pr_update_branch) and adds nothing of its own: the PR's diff against main is the same 6 files (+559/−19). The new head was needed because pushes from the card thread fire no pull_request workflows, so CI never ran on 00fb75d5.
• Measured after the merge: main brought refactor(core,objectql,plugin-sharing): one PackageScopedNameRefusedError class for every package-scoped by-name refusal #31876 (one PackageScopedNameRefusedError class), which touches the package-scoped read this PR calls. On b069d553, under the lock: build plus the ownership-queue and E8 readers 119/119, approvals 1509/1509, typecheck 0. CI on 8b657ca8 is running; auto-merge waits for it.
• Everything else in 6737482708 stands (epic PASS at 00fb75d5; the merges do not touch the PR's files).
• Landing: ready and auto-merge stay armed. On merge: a landing record on objectql assignment rules and plugin-approvals approver steps pass the declaring package to queue reads, so their queue names resolve by ADR-0150 D3 (follow-up of #31734) #31790, pm:dispatched removed, and skills: objectstack-automation says a packaged assignment rule's queue and a packaged flow's queue approver resolve from the package and its declared dependencies (follow-up of #31790) #31853 moved to pm:queue.