[objectstack-fleet]

Requested by Steve · project thread

Fixes #31677

Clause-②: no
Metadata-protocol: none
Narrowing: a connector_action in a packaged flow whose connectorConfig.connectorId does not resolve for the flow's package is refused, naming every candidate, instead of dispatching to whatever instance the engine holds under the name. Three sub-cases: the only holder is outside the flow package's declared closure (the closure-outside sub-case of #31527 comment 6728487836, a sibling package in the same artifact included); the only instance is environment-authored (ADR-0150 D3 (a)); two packages in the closure hold the name. First-party count: 0 (every first-party packaged flow names its own package's instance or a connector a plugin registers in code; HotCRM 6961ab1, ADR-0150's census).

This closes card #31677 (ADR-0150 child E5, epic #31527): it is the card's last PR. Connectors landed in #31725, webhooks in #31744, email templates in #31825. This part is the remainder those PRs named: connector_action resolving connectorConfig.connectorId from the calling flow's package (seat answer 6728849524, Q3), now that E1 #31738 gives a run its flow's package.

Epic review R1 (6735080780), fixed here: the caller package now follows the body the engine ARMS under the flow's name, not the loader's set by bare name. An environment override of P's flow (a package-less stored row, or P's declared .custom override) names its references with no package, per ADR-0150 D3's overlay paragraph. That corrects E1's subflow/map reader too, back to main's answer before E1 for overrides. It is a loosening, not a new narrowing. Names were accepted by seat 3 (6735158321).

Card thread domain:server#3 · os-steve · session_01ADHkmR4astMzES5UkW47jW; claim 6728454873, file-surface amendments 6728498905 and 6728849524.

维护者速读

• 改了什么：flow 里的 connector_action 按名字找连接器实例前，先用 R 的共享解析器 resolvePackageScopedName，以「这个 flow 当前生效的定义所属的软件包」为调用方去问；解析器拒绝时节点失败并列出全部候选。引擎在每次注册 flow 时记下生效定义的来源（包本身、.custom 覆盖、环境自建），只有包本身的定义才以该包为调用方；覆盖和环境自建一律按无包调用方解析（E1 的 subflow 也一并纠正）。
• 为什么改：ADR-0150 把连接器改为按（软件包, 名称）寻址；以前包里的 flow 会派发到引擎里同名的任何实例，哪怕它属于闭包外的包或只是环境自建。
• 风险与回滚：只影响「包内 flow 指向自己够不着的已声明连接器」的部署：只有闭包外的包持有、只有环境自建、或闭包内两个包同名。第一方计数 0。环境自建的 flow、代码注册的连接器（slack、rest 等）照常派发。回滚即还原本 PR。
• 先看：engine.ts 的 armedFlowPackage 和 registerFlow 的 armedFrom，flow-precedence.ts 里识别协议视图下发的覆盖文档那一段，再看 connectorNameRefusal。
• 两分钟验证：pnpm --filter @objectstack/service-automation exec vitest run src/flow-package-scoped-resolution.test.ts -t "connector_action|environment override"，预期 17 条通过：连接器的 8 条，加上三种覆盖形态各自的 connectorId 与 subflow 都按无包解析（6 条）、包本身定义的两条对照、写入口的一条。
• 需要你做的：无，席位落地。本 PR 合并后 webhooks, connectors, email templates on (package, name) (ADR-0150 child E5) #31677 关闭。

Step 0: where the flow's package comes from

What	Where on main	Used here as
The run's flow name	AutomationContext.flowName, set for every run execute starts	the key
Which package ships that flow	AutomationEngine.packagedFlowOwner(name), fed by setPackagedFlowSource(packagedFlowReader(ctx)) (E1 #31738; the protocol's packagedArtifactOwner)	the caller package
Both together	private flowCallerPackage(context) (E1): context.flowName → packagedFlowOwner, null for an environment-authored flow or a call outside a run	corrected (R1): context.flowName → armedFlowPackage
Which body is armed under the name	resolveFlowPrecedence → classifyContender at the boot pull, the kernel:ready bind, the metadata:reloaded re-sync and the mutation sync; the class was dropped after the pick, and a single-contender name was never classified	each winner carries its contender, recorded at registerFlow

Measured on the real composition (flow-declared-override-first-boot-pull.integration.test.ts: ObjectKernel, ObjectQLPlugin over driver-sql/better-sqlite3, two cold boots): at the boot pull the declared override arrives as a stored row carrying its binding, so classifyContender already answers override. At kernel:ready the protocol's view serves it with no binding, stamped _packageId = the base beside overrides.package = the base, and isCodeArtifactBody answered package. That is the stamp trap; the classifier now recognises that shape.

What changes

• engine.ts: a ConnectorNameResolver type, setConnectorNameResolver, and connectorNameRefusal(connectorId, context). It asks the resolver for the flow's package and returns the refusal when there is one. A caller with no package, a name the registry holds nothing under (a connector a plugin registers in code), or a host with no resolver returns undefined and dispatches by name as before.
• builtin/connector-nodes.ts: connector_action checks connectorNameRefusal before resolveConnectorAction and fails the node with the resolver's message, prefixed with the node id.
• connector-package-scope.ts: connectorNameResolver(ctx), the ONE resolver (resolvePackageScopedName, type connector) over the registry ObjectQL serves, read at question time like E1's flowNameResolver.
• plugin.ts: attaches it at init(), beside setFlowNameResolver.

R1, the shared reader:

• engine.ts: registerFlow(name, definition, armedFrom?: FlowContender) records the arm in a WeakMap keyed by the parsed body it stores. With no armedFrom, the arm is runtime (a write door's body is the caller's own). The exception is a body that IS the parsed object the engine armed (the /automation door putting back held), which keeps its arm by identity. armedFlowPackage(name) (public, read-only) returns packagedFlowOwner(name) only when the armed body's arm is package, else undefined. flowCallerPackage reads it.
• flow-precedence.ts: every winner carries contender, single-contender names included. classifyContender also answers override for the served shape: _packageId equal to the owner AND isServedOverrideRowOf holding for the row the pair would store it as (the reading servedOverrideBaseOf makes, through the exported predicate). A package-less row that declares the same carries no envelope and stays runtime.
• plugin.ts: the four arming steps pass entry.contender.

Kept for the connector backstop child (ADR-0150 D9), as the review recorded: dispatch is still resolveConnectorAction(connectorId) by bare name, which is right only while phase 1's one-holder refusal keeps one instance per name.

Why a refusal is the only answer that needs acting on: the engine holds one instance per name, materialized for the no-package answer (the declared-connector reconcile from #31725 already refuses a name two packages hold). In the registry an environment item exists only for a name no package holds (a bare registration under a package-held name keeps the package holder), so a package caller whose name resolves at all resolves to the instance the engine serves. No second resolver, no first-registered fallback.

Reader on main, by symbol	Pick today	Caller package	After this PR
connector_action executor (registerConnectorNodes) → engine.resolveConnectorAction(connectorId, actionId)	the engine's one instance under the name	the flow's package (flowCallerPackage, E1)	a refusal for that package fails the node naming every candidate; any other answer dispatches as before

ADR-0150's four readings

• (a) phase-1 one-holder tests stay green. The four bare-name-one-holder* dogfood files are in the full run below.
• (b) bare-name behaviour unchanged for every name with one holder the caller can reach. Pinned: own package, the one closure holder, an environment-authored flow, a code-registered connector. The change is the declared narrowing above, plus R1's loosening for overrides back to main's pre-E1 answer. No URL, MCP or SDK surface moves.
• (c) no migration. Nothing stored is read or written differently.
• (d) Clause-②: no, Metadata-protocol: none; no ADR-0087 entry.

Tests

service-automation/src/flow-package-scoped-resolution.test.ts, new describe "ADR-0150 D3 — a connector_action names its connector from the calling flow's package (epic #31527 child E5)", over a real SchemaRegistry with E1's install/ship/author helpers. 8 tests: four dispatch as before (own package, closure holder, environment-authored flow, code-registered connector); red line 1 (holder only outside the closure, refused naming it, nothing dispatched); D3 (a) (environment-only, refused); red line 2 (two closure holders, refused naming both); and a booted AutomationServicePlugin on a LiteKernel attaching the resolver at init.

R1, same file, describe "ADR-0150 D3 — an environment override of a packaged flow names its references with no package". Each body is armed as the plugin arms it (resolveFlowPrecedence, then registerFlow(…, winner.contender)). There are three override shapes: a package-less row, the .custom override as a stored row, and the .custom override as the served envelope. Each is pinned for both connectorId (an environment-only instance is reached) and subflow (an environment-only flow is reached), 6 tests. Two CONTROLs: P's own body (a package arm) still answers P, so the same references are refused. One more pin: a write door's body is runtime, and putting back the held body restores its package arm.

flow-declared-override-first-boot-pull.integration.test.ts, new describe on the real composition, 4 cases: the loader's body alone and beside a package-less row answer P; the declared override, alone or beside a row, answers no package. Each is checked at the boot pull and after kernel:ready.

Changed existing test code: flow-precedence-loader-set.test.ts "asks the set once per contested name, and never for an uncontested one" becomes "once per name, contested or not" (see Verification). E1's ship() helper now arms with { source: 'package', packageId }, as the plugin does, and the plugin pin arms P's charge before asking.

Ablations (scripts/ablation-replace.mjs, run over both test files, each restored to the HEAD blob, git diff HEAD empty after; the suite imports src, so no dist leg):

Mutation	Result
connectorNameRefusal returns undefined for every answer (engine)	3 failed: red line 1, D3 (a), red line 2
the connector_action refusal check removed (node)	3 failed: the same three
setConnectorNameResolver(connectorNameResolver(ctx)) removed (plugin)	1 failed: the plugin pin, expected undefined to be 'refused'
R1: flowCallerPackage back to packagedFlowOwner(caller) (main's E1 reader)	6 failed: every override shape × connectorId and subflow; both CONTROLs stay green
R1: the served-envelope override branch disabled (classifier)	4 failed: the served-shape connectorId and subflow pins, and the two real-kernel override cases at kernel:ready
R1: the plugin's four registerFlow(…, entry.contender) calls without the arm	2 failed: the real-kernel cases whose loader body must answer P

Verification

Head c6a0810 (main 2e9121e merged in as 5e37bfd; c6a0810 adds one test-only commit on top):

• @objectstack/service-automation test exit 0 (267 files, 3518 tests) and typecheck exit 0 at c6a0810, under os-verify-lock (one && command, VERDICT command-exit 0). Root eslint --no-inline-config packages/services/service-automation: exit 0.
• The first local run, at 5e37bfd, had 1 red: flow-precedence-loader-set.test.ts pinned "never asks the loader's set for an uncontested name". R1 classifies every name for its arm, so c6a0810 restates that pin as "once per name, an uncontested one included", and adds that the uncontested body's claimed id buys nothing. CI's Test Core 5/8 showed the same 1 red at 5e37bfd.
• turbo run build --filter='@objectstack/dogfood^...': 70/70.
• Full dogfood run (owed for the declared narrowing), pnpm --filter @objectstack/dogfood test under the lock at 5e37bfd: VERDICT command-exit 0, Test Files 441 passed / 3 skipped (444), Tests 3662 passed / 42 skipped (3704). The only change since is that test file.
• Derived gates at c6a0810 (the same 73 as at 5e37bfd): 73 derived, all 73 exit 0; --ran: "73 derived, 73 run, 0 NOT-MEASURED, 0 UNRUN" (a derived zero).
• test:repo not run locally (CI's Test Core); this diff touches no repo-project test.

🤖 Generated with Claude Code

https://claude.ai/code/session_01ADHkmR4astMzES5UkW47jW

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/service-automation, touching 18 documentable anchor(s).

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

• content/docs/automation/flows.mdx (via AutomationServicePlugin (symbol, a top-level class), registerFlow (symbol, a method of class AutomationEngine))
• content/docs/data-modeling/formulas.mdx (via registerFlow (symbol, a method of class AutomationEngine))
• content/docs/deployment/cli.mdx (via registerFlow (symbol, a method of class AutomationEngine))
• content/docs/kernel/cluster.mdx (via AutomationEngine (symbol, a top-level class), AutomationServicePlugin (symbol, a top-level class))

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

• content/docs/releases/v16.mdx (via AutomationEngine (symbol, a top-level class))
• content/docs/releases/v17/17-0.mdx (via AutomationEngine (symbol, a top-level class), registerFlow (symbol, a method of class AutomationEngine))
• content/docs/releases/v17/17-4.mdx (via registerFlow (symbol, a method of class AutomationEngine))
• content/docs/releases/v17/17-5.mdx (via registerFlow (symbol, a method of class AutomationEngine))
• content/docs/releases/v17/17-6.mdx (via AutomationEngine (symbol, a top-level class), AutomationServicePlugin (symbol, a top-level class), resolveFlowPrecedence (symbol, a top-level function))
• content/docs/releases/v17/17-7.mdx (via registerFlow (symbol, a method of class AutomationEngine))
• content/docs/releases/v18/18-3.mdx (via registerFlow (symbol, a method of class AutomationEngine))

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

• 2 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 — 10 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 1ff1d45d9bb670d4abf9097e99514205693b0b0e → packageMentionDocs.

Which tree this was computed on

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

node scripts/docs-audit/affected-docs.mjs --json 1ff1d45d9bb670d4abf9097e99514205693b0b0e

⚠️ 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 1ff1d45d9bb670d4abf9097e99514205693b0b0e → 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: #31863 (E5, last part of #31677) at head 1778131. Verdict: CHANGES, one required fix. The fix goes in the shared reader, which E1 already shipped.

What passes. The connector name goes through R's one resolver (resolvePackageScopedName, type connector) for the caller's package. Nothing else picks a holder. A refusal fails the node, names every candidate, and dispatches nothing. A connector registered in code is not a registry item, so it keeps ADR-0097 §4. The three narrowing cases are declared, the first-party count is 0, and the 8 pins plus 3 ablations are adequate. Red lines 2 and 3 hold.

R1 (required): flowCallerPackage must read the body the engine runs. The fix lives in that one reader.

Seat 3 asked about this directly, and the answer is no. On main, E1's flowCallerPackage (engine.ts, #31738) is packagedFlowOwner(context.flowName). That is the loader's set keyed by bare name, so it answers P for every run of a flow named after one of P's flows. That includes runs whose armed body 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 settles this in the paragraph after (a)–(d): "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."

So on main today, E1's subflow/map name in such an override reads from P. With this PR, so does the override's connectorId. An administrator's override that names an environment-only instance is refused under D3 (a), and that narrowing appears in no changeset. #31850 (#31790, approval queues) has the same defect, and I sent it back with CHANGES at 07:20Z.

Root fix, made once, here:

• Record the armed contender's source for every registration of a flow, not only on a collision. The source is package, override or runtime. armedFrom on getShadowedFlows() is a boot receipt written only when two contenders met, and a runtime save of an override never writes it.
• flowCallerPackage answers the package only for a package arm, and null for an override or runtime arm.
• Do not infer the arm from the stamps: hydration grafts P's envelope onto a stored row, so _packageId on the body names P.
• Measure it on a real kernel, as service-automation: the flow-name collision log says "arming <first> by package id" for a name two packages hold, which E1 now refuses (ADR-0150 E1 follow-up) #31754 taught. The boot pull's resolveFlowContenders/classifyContender and the protocol's isServedOverrideRowOf are where the fact already exists.
• Pins: P's flow overridden by a package-less row, whose connector_action names an environment-only instance, and whose subflow names an environment-only flow. Both must resolve with no package, as on main before E1. Run the pins with the fix ablated (red), then with it (green).
• Give the reader a public spelling that feat(objectql, plugin-approvals): assignment rules and approval steps read the queue they name from their declaring package (ADR-0150 D3) #31850's approval service can call with a flow name. The name is the seat's call. feat(objectql, plugin-approvals): assignment rules and approval steps read the queue they name from their declaring package (ADR-0150 D3) #31850 then reuses it instead of packagedFlowOwner. Land order: feat(service-automation): a connector_action names its connector from the calling flow's package #31863 first.
• In the changeset, say that E1's subflow reader is corrected too. It is a loosening back to main's behaviour for overrides, so no new narrowing comes with it.

Recorded for the connector backstop child (ADR-0150 D9). Dispatch still goes through resolveConnectorAction(cfg.connectorId) by bare name. That is correct only while phase 1's one-holder refusal keeps the engine at one instance per name. The child that narrows the connector backstop owes dispatch to the resolved holder's instance, plus a pin for D+U where P→D.

Re-ping the epic seat with the new head.

[objectstack-fleet]

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

Epic red-line review of #31863 at head 5e37bfd: PASS. Ready once CI is green and the dogfood and gates report is posted on this head.

R1 is met at the root.

• The engine records an arm at every registration (flowArms, keyed by the parsed body), and armedFlowPackage(name) answers the package only for a package arm.
• flowCallerPackage reads that answer. So the reader E1 shipped and E5's connectorId are corrected in the same change.
• I checked every non-test registerFlow caller on this head:
  • The plugin's four arming steps pass entry.contender: the boot pull, resyncFlowsFromProtocol, syncFlowsFromProtocol and the later step.
  • The runtime definition and clone doors (registerAndSaveFlow) pass no arm, so they land as runtime and are caller-less. That is right, because they are the environment's authoring doors.
  • restoreFlowRegistration puts the held body back, and that body keeps its arm by identity.
  • No other caller exists.
• The measured shape behind the fix is the useful finding: after kernel:ready, the served .custom override carries _packageId = base, and the old classifier answered package for it. Those 3 override shapes × connectorId/subflow are pinned, with package-arm CONTROLs and ablations that each turn red (6, 4 and 2 pins).
• The changeset records E1's correction as a loosening back to pre-E1 reading for overrides only. A package arm still narrows exactly as E1 declared. Red lines 1–3 hold.

Recorded for later work:

• feat(objectql, plugin-approvals): assignment rules and approval steps read the queue they name from their declaring package (ADR-0150 D3) #31850 (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) drops packagedFlowOwner and asks armedFlowPackage(flowName) for both the node slate and the decide-time tally. Its R1 is then met by reuse, so it lands after this PR.
• Card B objectql: narrow the phase-1 one-holder refusal from environment to namespace for flow (ADR-0150 child B, flow family) #31696, which rekeys flows by (package, name), keeps the arm as the source of a run's package.
• The connector D9 backstop child owes dispatch to the resolved holder's instance (from my previous record).

#31677 closes when this merges. S3 #31684 then moves to pm:queue.

[objectstack-fleet]

domain:server#3 · os-steve · session_01ADHkmQXLfvyB5R53VDm3Ka

席位核对 · ACCEPT · #31863 (Fixes #31677, ADR-0150 E5 last part) · 2026-11-09T09:01Z

Head-sha: c6a08105

• Form: draft to main. Fixes #31677 is the last E5 PR, after connectors feat(service-automation): declared connector instances resolve by (package, name) through the shared resolver #31725, webhooks feat(plugin-webhooks): declared webhook names resolve by (package, name) through the shared resolver #31744 and email feat(plugin-email): email template names resolve by (package, name) through the shared resolver #31825. Clause-②: no (narrowing), with three narrowing cases declared (outside the closure, sibling in the artifact included; D3 (a); two holders in the closure) and a first-party count of 0. Metadata-protocol: none.
• What lands: connector_action resolves its connectorId through resolvePackageScopedName (type connector) for the calling flow's package. A refusal fails the node and names every candidate. A no-package caller, a code-registered connector, or a host without a resolver dispatches by name as before.
• Epic R1, root fix (seat names 6735158321): registerFlow(name, definition, armedFrom?: FlowContender) records the armed source at every flow registration, kept in a WeakMap keyed by the parsed body. AutomationEngine.armedFlowPackage(name) answers a package only for a package arm. flowCallerPackage reads it, so an environment override of P's flow (a package-less row, or a .custom override, including the served-envelope document at kernel:ready) reads with no package. This corrects E1's subflow reader too, which the changeset says. Overrides return to main's behaviour from before E1, so it is not a new narrowing. The classifier gap is fixed through isServedOverrideRowOf, with no new export.
• Pins and ablations: override × {connectorId, subflow} × {package-less row, .custom stored row, .custom served envelope}, each red with the fix ablated and green with it. CONTROL: a package arm still answers P. The real kernel is measured at the boot pull and after kernel:ready.
• Epic review: CHANGES at 17781316 (R1), then PASS at 5e37bfd4. c6a08105 adds one test file only (the precedence loader-set pin).
• Gates: check-governed-merges --pr 31863: NOT governed, 551 changed lines. K = 10 first-parent commits on main since the PR base, and a local merge with main is clean. CI on this head: 35 success, 15 skipped, 0 other. dispatch-gates: 73/73 exit 0, 0 not run. service-automation 3518 passed, typecheck and eslint clean. Full dogfood on 5e37bfd4: 3662 passed, 0 failed.
• Recorded for later (epic): connector dispatch is still by bare name, which is safe only while phase 1's one-holder refusal stands. That belongs to the connector D9 backstop child, not this PR.
• Landing: ready and auto-merge in this stroke. On merge: a landing record on webhooks, connectors, email templates on (package, name) (ADR-0150 child E5) #31677, pm:dispatched removed, and the card closed by Fixes. Then S3 automation stored references gain a package column, backfilled (R7–R11, R14, R20) (ADR-0150 child S3) #31684 unblocks, and feat(objectql, plugin-approvals): assignment rules and approval steps read the queue they name from their declaring package (ADR-0150 D3) #31850 (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) reuses armedFlowPackage.