fix(service-automation, metadata-protocol): a shipped flow name arms the loader's body at both boot steps, and a stored row of that name is reported as shadowed (#20913)

[objectstack-fleet]

Fixes #20913
Clause-②: no

What

For a flow name the loader ships from a managed package, a cold boot now arms the loader's body at both boot steps, and a stored row of that name is reported as its own shadowed contender, never armed. Triage direction 5916734614, ruling 5904938166 rule 1, ADR-0126 §2 / §3, ADR-0131 D6.

One decision, three seams:

1. One precedence for every arming step (service-automation/src/plugin.ts). The kernel:ready sync and the metadata:reloaded re-sync now resolve the protocol's flow view through resolveFlowPrecedence with the engine's own packagedFlowOwner, the same call the boot pull makes. The three callers share one private helper, resolveFlowContenders. Before, both syncs registered every listed body one after another, so the last body listed for a name was the one armed.
2. The sealed base wins a name it ships (service-automation/src/flow-precedence.ts). Within a name the loader's set holds, the loader's entry ranks before a stored row. flow is Regime C: "⛔ Never silent override, never an overlay read path". A package contender exists only inside a held name (since automation: boot-time flow precedence still classifies its contenders from body stamps, not the loader's set (the remainder of #20761's ruling rule 1) #20864), so the rank changes nothing outside one. The collision warning now says which rule armed the body and names the remedy (clone under a new name, or switch the packaged flow off).
3. A stored row of a shipped flow name is its own row (metadata-protocol/src/protocol.ts).
   • The hydration registers it without the artifact's protection envelope. Before, it carried the loader entry's package-provenance stamps, so both registry contenders read as the package's.
   • The flattened view (both faces) serves a shipped flow name from the loader's entries alone: the stored row is not merged into the package's slot, and the registry's hydrated copy of it does not stand in either.
   • The row stays at rest and is still hydrated, as the tenant row it is, so the boot pull reports it.

⛔ Not decided here: what happens to hatch-written rows themselves (keep, refuse, migrate). That is #15206's. This PR only makes them "never armed over the base".

Readings

Showcase composition on a database file, measured on a cold boot after a stored row was placed at rest under showcase_urgent_task_alert between two boots. Before = base 4d0b9cd542; after = 22d8d3593e.

reading	before	after
armed body after kernel:ready	stored body	loader's body
engine version history for the name	loader's, then stored	loader's, loader's
record-triggered run, executed steps	start, then the stored body's notify node	start, then the loader's notify node
getShadowedFlows() for the name	armed package, shadowed package (indistinguishable)	armed package, shadowed runtime-authored row
boot audit line	"package … is ARMED and package … is shadowed"	"package … is ARMED and a runtime-authored row (sys_metadata) is shadowed"
GET /api/v1/automation/NAME	200, stored body	200, loader's body
execution view and GET /api/v1/meta/flow entry	stored body, under the package's provenance	loader's body
armed body after metadata:reloaded	stored body	loader's body
GET /api/v1/meta/flow/NAME (by-name)	200, stored body under the package's provenance	unchanged; see Acceptance notes

Deviations: please confirm

1. The precedence rank flips inside a held name. The claim scoped flow-precedence.ts to exposing the existing decision, without re-shaping it. Measured on the base:
   • The existing decision armed the loader's body only because the hydration grafted the package's provenance onto the stored row. Both contenders then ranked package, and arrival order decided.
   • Once the stored row is reported with its own provenance (the direction's second bullet), the base rank (runtime before package, the ADR-0005 direction Packaged flow silently replaced by a same-named runtime flow: listItems returns both, the engine keys flows by bare name, and Map order decides the winner #11997 wrote) arms the stored row. That is the opposite of the direction's first bullet.
   • automation: boot-time flow precedence still classifies its contenders from body stamps, not the loader's set (the remainder of #20761's ruling rule 1) #20864's own pins encoded that outcome: "a held name: the shadowing receipt names the tenant row armed".
   • The rank now follows ADR-0126 §2. The Packaged flow silently replaced by a same-named runtime flow: listItems returns both, the engine keys flows by bare name, and Map order decides the winner #11997 test file's header asked for exactly this re-argument if the direction were ever revisited. It is recorded there, in the module header, and in a new ADR anchor.
2. The pending release note .changeset/20864-precedence-loader-set.md is corrected. One clause is removed: "a flow authored in the deployment wins over the packaged flow of that name (ADR-0005)". This PR makes that clause false, and the note has not shipped yet. check-empty-changeset stays red by design for a deliberate correction of somebody else's pending note. Confirmation requested here; do not restore it from the base.
3. ADR anchors, outside the claimed file list (AGENTS.md Prime Directive 13):
   • a new anchor for flow-precedence.ts (ADR-0126, ADR-0048);
   • ADR-0126 plus one invariant paragraph added to protocol.ts's anchor.

Tests at 22d8d3593e

• pnpm --filter @objectstack/service-automation exec vitest run: 160 files, 2002 tests passed. Full run at 97bd52e852; since then only one test title changed, and the six precedence and sync files were re-run at 22d8d3593e (43 passed).
• pnpm --filter @objectstack/metadata-protocol exec vitest run: 194 files passed and 3 skipped; 2879 tests passed and 19 skipped. protocol.ts is unchanged since that run; the new file and the tenant-authored suite were re-run at 22d8d3593e (21 passed).
• pnpm --filter @objectstack/metadata-protocol --filter @objectstack/service-automation --filter @objectstack/dogfood run typecheck: clean. Service-automation's typecheck was re-run at 22d8d3593e; its check:test-typecheck reports 0 errors.
• Dogfood, isolated project, at 22d8d3593e: flow-shipped-name-stored-row-boot (new, 6 cases), plus flow-provenance-server-held, automation-authoring-doors-durable and packaged-flow-write-door-parity. 31 passed.
• New unit pins:
  • service-automation/src/flow-sync-one-precedence.test.ts, 7 cases: both syncs, held name, two packages, unheld duplicates, tear-down.
  • metadata-protocol/src/protocol.flow-stored-row-shipped-name.test.ts, 9 cases: hydration, both faces, name-only judgement, controls for an unheld flow and an overlay-regime type.
• The Packaged flow silently replaced by a same-named runtime flow: listItems returns both, the engine keys flows by bare name, and Map order decides the winner #11997 and automation: boot-time flow precedence still classifies its contenders from body stamps, not the loader's set (the remainder of #20761's ruling rule 1) #20864 pins that encoded the runtime-first rank are updated to the sealed-base direction.
• Gates: node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands derived 77 families at 22d8d3593e, and --ran accounts for all 77 with exit codes.
  • 76 exit 0.
  • check-empty-changeset --base origin/main exits 1: deviation 2, red by design.
  • check:dual-build-cjs-loads first answered PREREQUISITE NOT MET (8 unrelated packages had no dist/). After building them it exits 0.
• pnpm lint (the whole repo, eslint . --no-inline-config) exits 0 at 22d8d3593e.

Ablations

Each ablation ran after the fix was committed. Every leg went through scripts/ablation-replace.mjs: the anchor hit exactly once, the blob changed, and the restore was proven by blob equal to HEAD and an empty git diff HEAD.

Unit legs (subjects imported from src/):

leg	what was removed	red
A1	the kernel:ready sync's precedence	3
A2	the metadata:reloaded re-sync's precedence	2
A3	the rank flip, put back to runtime-first	10
A4	the hydration graft, put back for flow	2
A5	the stored-row half of the view filter	4
A6	the registry half of the view filter	1

Dogfood legs (the dogfood suite resolves dist/, so each leg ran mutate, rebuild, ablation-dist-preflight marker present, run, restore, rebuild, --absent and tree clean):

• D1, the view's stored-row half removed. The arming and execution pins go red (2 failed, 4 passed), and the receipt pin stays green. That leg's rebuild exited 1 only at the declaration step, on the now-unused binding; the JS bundles carried the marker (preflight: present in 2 built files).
• D2, the rank put back to runtime-first. Only the receipt pin goes red (1 failed, 5 passed). The boot pull arms and records the stored row, and the sync then arms the loader's body, so the receipt no longer describes what is armed.

Acceptance notes

• By-name door. GET /api/v1/meta/flow/NAME still serves the stored body under the package's provenance for a shipped name that has a stored row (measured after: 200, the stored body). It now disagrees with the list, which serves the loader's body.
  • Not changed here: the by-name read is outside the claimed surface, and which body that door serves for a hatch-written row belongs with feat(metadata-core,metadata-protocol,objectql,plugin-security): the sys_metadata family goes tenant-less; the per-organization overlay axis retires; managed content is sealed (ADR-0131 D6/D7/D13) #15206's keep / refuse / migrate decision.
  • Reported as an out-of-scope finding for the seat.
• Other flow readers of the served list. Every getMetaItems reader of flow inherits the list change, by source reading: GET /meta/diagnostics?type=flow, findReferencesToMeta sources of type flow, and the package export sweep in runtime/src/domains/packages.ts. For a shipped name with a stored row they now see the loader's body.
  • Execution-view readers: the automation flow syncs (the subject), and the automation connector read, which is untouched because the rule is scoped to flow.
• Who writes the receipt. Only the boot pull writes the shadowing receipt. The two syncs resolve to the same winners by the same decision and log the collision warning when they meet a contested name, so a name two packages ship is warned at the pull and again at each sync. The re-sync does not refresh receipts after a runtime change; that was already so on the base.
• An unheld name listed twice by the view. Two package-bound tenant rows of one name now resolve by arrival order at the syncs, as at the boot pull; the syncs used to arm the last one listed.
• Stale ADR-0005 citations, out of surface and not changed:
  • the CLI startup banner (packages/cli/src/utils/format.ts) cites "ADR-0005 overlay precedence" for every shadowed flow; the armed and shadowed facts it prints come from the receipt and are correct;
  • [Registry] Collision in packages/objectql/src/registry.ts says every read serves the stored row; for a flow, that is now true of the by-name door only;
  • the FlowContender and FlowShadowingRecord docblocks in engine.ts, which the automation: boot-time flow precedence still classifies its contenders from body stamps, not the loader's set (the remainder of #20761's ruling rule 1) #20864 review already routed to the next PR touching that type.
  • Carrier for all three: none.
• Organization-scoped rows stay out of reach, pinned. The boot's metadata_org_scoped_unhydrated warning names such a row. For a shipped name its "will NOT bind its triggers" clause is true of the row only; the loader's flow stays bound.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 2 package(s): @objectstack/metadata-protocol, @objectstack/service-automation, touching 11 documentable anchor(s).

2 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))
• content/docs/concepts/metadata-lifecycle.mdx (via ObjectStackProtocolImplementation (symbol, a top-level class))

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

• content/docs/releases/v16.mdx (via ObjectStackProtocolImplementation (symbol, a top-level class))
• content/docs/releases/v17/17-0.mdx (via ObjectStackProtocolImplementation (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 name(s) were too generic to anchor anything (single lowercase words)
• the SDK route bridge reached 54 of 206 client-bound route-ledger rows — the other 152 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 152: 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; 97 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 — 14 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 bee75cebe63889f93fa1e6dc358cd8c5f7b9a928 → packageMentionDocs.

Which tree this was computed on

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

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

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

[objectstack-fleet]

Contract review

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: 22d8d3593eb561c3f7e5a39bca691f2855c616e3
Local-runs: none

This is the record of record for PR #20942 at 22d8d3593e, card #20913 (the kernel:ready sync re-arming a stored row's body over the loader's for a packaged flow name), Residual 2 of the PR #20880 record (5914326577) on #20864, under the #20761 ruling (5904938166, rule 1).

Inputs:

• card automation: at kernel:ready the flow sync re-arms a stored row's body over the loader's for a packaged flow name, after the boot pull armed the loader's, so the stored body runs while the receipt says the package's is armed #20913: its body, triage's direction 5916734614, the seat's claim 5917761349 and the os-dev-report 5919683269 with its two open_questions;
• the parent ruling 5904938166 (rule 1: for flows "packaged" means "loaded by the loader from a managed package", and precedence reads that set, never a body's stamps), card automation: boot-time flow precedence still classifies its contenders from body stamps, not the loader's set (the remainder of #20761's ruling rule 1) #20864 with PR fix(service-automation): boot-time flow precedence classifies contenders by the loader's set #20880 (landed as 27bf358ec7) and its record 5914326577, and feat(metadata-core,metadata-protocol,objectql,plugin-security): the sys_metadata family goes tenant-less; the per-organization overlay axis retires; managed content is sealed (ADR-0131 D6/D7/D13) #15206 (ADR-0131 D6/D7/D13, read only);
• ADR-0126 §2 / §3 (flow is Regime C: locked base, "⛔ Never silent override, never an overlay read path"), ADR-0131 D6 (managed definitions are sealed), ADR-0005 (its whitelist and its RUNTIME READ block, as amended 2026-09-04) and ADR-0048 §1.5 / §3.4;
• PR fix(service-automation, metadata-protocol): a shipped flow name arms the loader's body at both boot steps, and a stored row of that name is reported as shadowed (#20913) #20942: its body, its file list (13 files, +946/−95, no governed path, head repo = base repo, draft) and the net diff against merge-base 4d0b9cd542 (byte-identical in stat to the file list; five linear commits, main not merged in; origin/main has since moved to bee75cebe6, so the diff reviewed is the net diff against the merge-base);
• the head's check-runs, read after they converged and collapsed latest-per-name (the paragraph below);
• source at the head and at the merge-base read through git show / git grep only: plugin.ts, flow-precedence.ts, engine.ts (reader, receipt and runtime states), protocol.ts (both faces, the merge, the hydration, the by-name read, packagedArtifactOwner), objectql's registry.ts (listItems, getArtifactItem), metadata-core's organizationIdForMetaRead, the runtime's automation domain, the CLI banner, the spec's FlowRuntimeState, both anchor files, the pending 20864 changeset at both trees, and the red job's log.

Check-runs on 22d8d3593e, read after convergence and collapsed latest-per-name (a background poll of the commit's check-runs, no local run): 35 runs, 31 success, 3 skipped (Build Docs and Console Pin Gate path-filtered, Packed-tarball smoke (opt-in) opt-in), 1 failure. All seven required contexts are success: Lint & Repo Gates (which carries check:adr-anchors over ① (f)), TypeScript Type Check (and its four sub-jobs), Test Core (and all six shards), Dogfood Regression Gate (and all three shards), Build Core, Temporal Conformance (live PG + MySQL), Governed Surface Queue Guard. Check PR Size, Spec property liveness, Dogfood Verify CLI, the claim, single-writer and part-of guards, Check Documentation Links and the labelers are success. The one red is Check Changeset, the deliberate-correction class, judged in ① (e); no other run is red.

Disclosure is kept at the card's level: doors, roles, codes and statuses. The body's package-provenance stamps, the tenant marker and the artifact's protection envelope are named abstractly here, and no seeding step is written.

① Derived judgments

(a) One precedence decision — RIGHT. No path registers a flow body at boot or on reload outside it.

• plugin.ts:2071-2077 is the one private helper, resolveFlowContenders: resolveFlowPrecedence(items, ctx.logger, reader), where reader is a closure over the engine's own packagedFlowOwner when the engine exists and undefined otherwise. Its three callers are the boot pull (:1027), the metadata:reloaded re-sync (:2116) and the kernel:ready sync (:2167), and the plugin's only three registerFlow calls (:1034, :2119, :2169) each iterate that helper's winners. The re-sync's tear-down reads the resolved names (freshNames, pinned: a name that leaves the view is still withdrawn). Repo-wide, the only other registerFlow callers are the runtime's automation authoring doors (runtime/src/domains/automation.ts:1565, :1617), which register the body the door admitted, refuse a held name as a locked base since access-security.packaged-flow-write-door-parity clauses 2 and 3 fail on main — detail withheld pending maintainer #20679 / fix(automation): which flows are packaged is the loader's fact, and every flow written through an authoring door is tenant-authored (#20761) #20853, run at request time and write no receipt: not a boot step and not a path that can arm a stored row under a shipped name.
• The reader is the same one automation: boot-time flow precedence still classifies its contenders from body stamps, not the loader's set (the remainder of #20761's ruling rule 1) #20864 routed: engine.packagedFlowOwner, fed by setPackagedFlowSource(packagedFlowReader(ctx)) at init() (plugin.ts:653, :464-473), which asks the protocol's packagedArtifactOwner({ type: 'flow', name }) (protocol.ts:14608-14613), through lookupArtifactItem to SchemaRegistry.getArtifactItem (registry.ts:3920), resolved at question time. The undefined branch (no engine) is the fail-closed answer the fix(service-automation): boot-time flow precedence classifies contenders by the loader's set #20880 record judged: nothing packaged.
• Only the boot pull writes the receipt (recordFlowShadowing, :1037); the syncs resolve the same names to the same winners by the same decision and warn on a contested name. That holds because the protocol's view no longer lists a stored row under a shipped name (c), so a held name has one contender in the view and the boot pull's receipt describes what is armed after both syncs. Measured by the dev over two cold boots (engine version history "loader's, loader's"; the record-triggered run executed the loader's step) and pinned in flow-sync-one-precedence.test.ts (held name, two packages, unheld duplicates, tear-down) and the dogfood pin. Ablations A1 / A2 red as predicted.
• One disclosed, pre-existing shape, not the card's: an unheld name two package-bound tenant rows share is listed twice by the view but once by the registry's bare slot, so the syncs arm the first listed (arrival order, the same rule the boot pull applies) with no receipt. Before, they armed the last listed. No packaged contender is involved, so no receipt can misreport a package there. Acceptance note, disclosed.

(b) The rank flip, the dev's open question 1 — EXECUTION of the direction, not a new product decision. Option A is right; confined exactly as claimed.

• What moved: flow-precedence.ts:201-202, precedenceRank returns 0 for package, 1 for runtime; on the merge-base it was the reverse. Nothing else in the comparator moved: rule 2 (lexicographic package id) still applies within package only (:286-289), and full ties keep arrival order (:291).
• Why it is confined: classifyContender (:118-127) returns package only when the loader's set holds the name AND the entry passes the registry's own per-entry artifact test; otherwise runtime. So a package contender exists only inside a held name, and the rank decides exactly one thing: inside a held name, the loader's entry beats a stored row. The two other cases are byte-identical to the merge-base by the comparator's unchanged code: two packages of one bare name are both package, tie on rank and order by id (pinned, "alpha wins over beta", both listing orders); a runtime row under a name no package ships, alone or beside a second runtime row, is all runtime, ties on rank and keeps arrival order (pinned in flow-precedence-loader-set.test.ts and the sync suite's unheld-duplicates case).
• Why the direction already decides it. Direction bullet 1: "For a name the loader's set holds, the loader's body is what is armed." Bullet 2: the stored row "appears in the shadowed list and the receipt, with its own provenance. It is not merged under the package's stamps." The dev measured (and I confirm from the merge-base's hydration) that the base rank armed the loader's body only because the stored row wore the package's envelope, so both contenders ranked package and arrival order decided. Once bullet 2 strips the envelope the stored row ranks runtime, and a runtime-first rank arms it, which is the opposite of bullet 1 (dogfood ablation D2: the receipt pin goes red because the boot pull records the stored row armed while the sync arms the loader's). The two bullets cannot both hold under runtime-first; package-first inside a held name is what they entail.
• Why ADR-0005 does not bind flows here. ADR-0005's own whitelist marks flow ❌ ("carry execution side-effects… a deployment, not an overlay"); its RUNTIME READ block ranks an overlay over the artifact default for overlays its write door admits, and for flow that door admits none (ADR-0126 §1.1 tier B, 403 NOT_OVERRIDABLE; ruling rule 2: a write to a held name is refused as a locked base). ADR-0048 §1.5 / §3.4 route "a write with no real package provenance" to ADR-0005's precedence; ADR-0126 §2 / §3 (accepted by merge, amended and re-homed by ADR-0131 D6) close that path for Regime C: "⛔ Never silent override, never an overlay read path", and ADR-0131 D6: no door edits a managed definition. So the reversal of Packaged flow silently replaced by a same-named runtime flow: listItems returns both, the engine keys flows by bare name, and Map order decides the winner #11997's reading was recorded in accepted ADRs before this PR; Prime Directive [WIP] Add Chinese version of the documentation #13 is satisfied because the ADRs carry the decision and the code now points at them (the module header at :17-45, the Packaged flow silently replaced by a same-named runtime flow: listItems returns both, the engine keys flows by bare name, and Map order decides the winner #11997 file header at flow-name-shadowing.test.ts:19-28, which itself asked for exactly this re-argument, and the new anchor). The fix(service-automation): boot-time flow precedence classifies contenders by the loader's set #20880 record already read the Regime C outcome as "the loader's body stays armed" (its ③ finding 2). Option C, a maintainer round trip, is not owed: the maintainer's ruling on automation: a flow created through the authoring door can assert package provenance, and the ADR-0126 guards and the activation ledger then treat it as package-shipped #20761 rests on the same two texts. Option B does not deliver bullet 2.
• The collision warning now says which rule armed the body and names the remedy for the sealed case ("clone under a new name, or switch the packaged flow off", :298-311), which is ADR-0126 §7.1 / §7.2's sanctioned pair. Right, and pinned.

(c) The protocol side — RIGHT, scoped to flow at every branch, and organization-scoped rows are out of its reach by construction.

• The two faces share one body: getMetaItems (protocol.ts:7875) and getMetaItemsForExecution (:7912) both call readFlattenedMetaItems (:7926), which is why the list an operator is served and the list the engine binds from cannot disagree. Two filters were added there: the registry half at :8065 (isStoredFlowEntryOfShippedName: a shipped flow name whose entry fails the artifact test, that is, the hydrated bare row) and the stored-row half at :8212-8214 (mergeable excludes a row whose name isShippedFlowName). The predicates (:14567-14584) gate on the canonical flow type first and ask packagedArtifactOwner by NAME, so a row's own bytes decide nothing (pinned: a row bound to the shipping package, or one whose body claims the package's stamps, is judged by name alone).
• The hydration (:15845): the artifact's envelope is withheld for flow only; every other type keeps it (the view overlay control keeps both its envelope and its overlay). hydrateOverlayIntoRegistry is the one mint door for all three producers of registry rows, boot loadMetaFromDb (:23328), the flattened read's own hydration (:8289) and the write-through (:16080), so no producer can graft the envelope back onto a stored flow row. The row still reaches the registry, tenant-marked, under the bare key, which is what puts it in front of the boot pull as a runtime contender and into the receipt. Ablations A4, A5, A6 and D1 red as predicted.
• Organization-scoped rows: organizationIdForMetaRead('flow', o) is undefined because flow declares no org override (metadata-core meta-write-org-scope.ts:184-190), so orgRecords is empty for flow (:8140) and no org row ever enters the overlays list or the merge; and the hydrator returns before registering any org row (:15820). The new code cannot reach one; pinned over a cold boot (dogfood: the loader's body, no receipt, the row not hydrated).
• Other readers whose behaviour moves, all served-face readers of the flow list, each now serving the loader's body for a shipped name with a stored row: the REST GET /meta/flow list door, getMetaDiagnostics (:7099, the diagnostics door), findReferencesToMeta with flow as a source type, the runtime's package export sweep (runtime/src/domains/packages.ts:2235), and every SDK, MCP or CLI client of the list door. Each is right: an export of a managed package should carry the package's definition; diagnostics and reference sites that read the sealed body agree with what dispatches; none of them is an authoring door, and ADR-0126 §2 admits no overlay read path for a flow. On the execution face the only flow reader is the automation plugin's own read (plugin.ts:2028); the connector read is untouched because every branch is type-scoped. Nothing outside flow is touched (pinned by the view controls, and by the type gate in each predicate).
• Two source readings the dev did not name, neither blocking: (i) a disabled package. listItems drops a disabled package's entries (registry.ts:4117-4130) but getArtifactItem does not consult isPackageDisabled, so for a shipped name of a disabled package that also has a stored row, isShippedFlowName still answers the package: the flattened view now omits the name entirely (before, it served the stored row), while the boot pull arms the bare stored row as a lone contender with no receipt (before, the sync armed it). The arming outcome is unchanged, the served list changes, and the fate of such a row is feat(metadata-core,metadata-protocol,objectql,plugin-security): the sys_metadata family goes tenant-less; the per-organization overlay axis retires; managed content is sealed (ADR-0131 D6/D7/D13) #15206's. Unmeasured, reach needs a disabled package plus an at-rest row under its name. Residual 1. (ii) the registry-half filter asks the registry per flow entry (a package-scoped scan per item, flow only). Cost, not correctness; not measured, not blocking.

(d) The receipt — the shape is published and unchanged; only its values move for the defective case.

• FlowShadowingRecord and FlowContender are barrel-exported types of @objectstack/service-automation (index.ts:44-45); engine.ts is not in the diff, so the shape is byte-identical. For a held name with a stored row the values now read armed package / shadowed runtime where the base read the package twice.
• Where it surfaces: the plugin's bootstrap audit line (plugin.ts:1231-1238, its parenthetical now points at the collision warning instead of citing ADR-0005); the CLI os serve startup banner (cli/src/commands/serve.ts:6972 into utils/format.ts:1303-1310), a stderr diagnostic with no JSON face, which still says "(ADR-0005 overlay precedence…)" (the dev's finding 3, judged in ③); and getFlowRuntimeStates() rows, which carry armedFrom / shadowed as engine-added fields beyond the spec's FlowRuntimeState (spec/src/contracts/automation-service.ts:564-610 declares neither; engine.ts:4482-4492 adds both), served by GET /api/v1/automation/_status. That undeclared pair predates this PR (Packaged flow silently replaced by a same-named runtime flow: listItems returns both, the engine keys flows by bare name, and Map order decides the winner #11997 / CLI startup banner does not surface flow-name shadowing, though it already reads the rows that carry it #12028) and is not widened here. So: no public-surface change in shape; the changesets state the value change. Right.

(e) The changesets and the deliberate correction, the dev's open question 2 — RIGHT; this record confirms the correction, sentence by sentence.

• The corrected note is .changeset/20864-precedence-loader-set.md (pending, @objectstack/service-automation minor, not yet shipped). The removed clause, quoted: "a flow authored in the deployment wins over the packaged flow of that name (ADR-0005)". This PR makes it false: inside a name the loader's set holds, package now ranks before runtime (flow-precedence.ts:201-202); outside one no contender is package, so the clause never described anything there. Removing it is right, and the sentence it sat in still parses.
• The remaining text, sentence by sentence, at the head: the title line (precedence takes which same-named flow is the packaged one from the loader's set, not from the bodies' own provenance): still true. "Clause-②: yes (widening)": still true of that PR (two signatures widened). "When several flow definitions share one name at startup, the automation plugin arms one of them and shadows the rest.": true. "Which contender counts as the packaged one is now the answer of the set of flows a managed package's loader registered.": true, untouched by this PR. "That is the same answer the ADR-0126 §7.3 subflow guards, the arming gate and the activation switch read since automation: a flow created through the authoring door can assert package provenance, and the ADR-0126 guards and the activation ledger then treat it as package-shipped #20761.": true. "The package provenance a flow definition carries is kept for display only.": true. Bullet 1 (the two signatures take the reader; the plugin passes the engine's own packagedFlowOwner): true, now through resolveFlowContenders, still the engine's reader. Bullet 2 (a stamped body of an unheld name ranks as the deployment's; the record no longer names that package): true, classification is untouched. Bullet 3 (no reader, nothing packaged): true. Bullet 4 (two deployment-ranked contenders keep listing order; package id orders packaged contenders only): true, the tie code is unchanged. Bullet 5 ("A startup whose registry the package loader and the stored-flow hydration filled arms the same flows as before: those entries already agree with the loader's set."): still true as that PR's own delta, which is what a changeset states (the M3 reading it was written from); it is the one sentence whose truth now depends on that frame, and the 20913 note is what states the moved case in the same release, so no further correction is owed. The migration line (pass the reader; without it no contender ranks as packaged): true.
• Check Changeset red: the job log shows exactly one refusal, the foreign-changeset rule on that file, rendered with both classes, and "No empty-frontmatter changeset introduced". Nothing else in that job is red. For the seat's landing check (SKILL.md's three conditions for a red by design): the source self-describes the DELIBERATE CORRECTION class (scripts/check-empty-changeset.mjs, FOREIGN_CORRECTION_REMEDY); the gate runs from pr-automation.yml on pull_request only, not on merge_group; the PR body's Deviation 2 names the note and the gate, and this record, once posted on the PR, names both again.
• New changeset 20913-flow-stored-row-shipped-name.md, @objectstack/metadata-protocol patch, Clause-②: no: every sentence is delivered at the head and pinned (Regime C, the two places, the hydration, the list "both faces" naming the list door and the execution view, the row neither deleted nor rewritten nor refused and reported as shadowed at startup, every other type and every unshipped name listed as before, the by-name read unchanged). It discloses finding 1 in its last sentence. Package and level right (a bug fix in a released package, no accept set moves, no public member added). Disclosure: doors only, no field spelling.
• New changeset 20913-flow-sync-one-precedence.md, @objectstack/service-automation patch, Clause-②: no: every sentence is delivered and pinned (the two startup steps and the reload through one decision with the engine's reader; the sealed base armed and the stored row shadowed, the ADR-0126 §2 customization pair named; "This replaces the earlier direction" stated plainly; the receipt naming the row as runtime-authored and the warning naming the rule; unshipped names unchanged; two packages by id). One precision point, not an error: the sentence opening "Names no managed package ships are unchanged" appends the two-packages case, which is a shipped name; the appended clause is separately true. The migration line for direct callers of resolveFlowPrecedence states the one moved outcome. Package and level right. Disclosure: API names and doors only.
• Across the PR body, both changesets, the report and every added test title: doors, roles, codes and statuses only; no request-body, header or field spelling; no seeding recipe (the body says a row "was placed at rest … between two boots"). The dogfood pin's code is the one place the placement is spelled, as any cold-boot pin must; that surface is outside the discipline as the claim words it (PR body, changeset, test title), and is left to the seat in ③. No model identifier in the five commits (model-free trailer pair on each), the PR body (session-URL footer) or the changesets. No tracker number in runtime prose.

(f) The two scripts/adr-anchors/*.json edits — RIGHT, and compelled.

• Prime Directive [WIP] Add Chinese version of the documentation #13 requires anchoring load-bearing spots of an ADR's decision, one JSON per anchored path, named for the path, no index; scripts/adr-anchors/ is not a governed surface. The new packages__services__service-automation__src__flow-precedence.ts.json lists ADR-0126 and ADR-0048, both real records, both cited in the file (:17-45); its invariant states the rank, its scope (inside a held name), the loader's-set rule, the id order for two packages and the one-function rule for all three steps, all true at the head. The protocol.ts anchor adds ADR-0126 and one invariant paragraph naming the hydration's withheld envelope and the both-faces filter with the two predicates by name; true at the head, and the id appears in the file. The deviation outside the claimed file list is the directive's own instruction, disclosed.

Surface inventory: no route, schema, query set, status code or exported signature changes; two exported types unchanged in shape; one barrel-exported function's outcome moves for exactly the held-name-with-stored-row case; two patch changesets plus one pending note corrected; no governed path.

② Semver level

The PR body's line 2 reads Clause-②: no, as the claim did, and both changesets are patch. RIGHT.

• Clause ② asks whether the card widens an accept set or expands a public surface (references/execution-duties.md): it does neither. No input is newly accepted, and no member, route, parameter or status is added.
• It is not a (narrowing) either: no accepted input is refused. A stored row under a shipped name is still accepted at rest, still hydrated and still reported; what changes is which body is armed and which body the list serves, for a state every authoring door has refused as a locked base since access-security.packaged-flow-write-door-parity clauses 2 and 3 fail on main — detail withheld pending maintainer #20679 / fix(automation): which flows are packaged is the loader's fact, and every flow written through an authoring door is tenant-authored (#20761) #20853 (only the operator's hatch or a direct store write can hold one). That is a behaviour correction under ruling rule 1 and the direction's two bullets, on a sealed definition (ADR-0126 §2, ADR-0131 D6), the negative boundary the fix(automation): which flows are packaged is the loader's fact, and every flow written through an authoring door is tenant-authored (#20761) #20853 and fix(service-automation): boot-time flow precedence classifies contenders by the loader's set #20880 records judged for this rule.
• The receipt's shape is unchanged (① d); its values move for the defective case, and both notes say so. AGENTS.md's changeset rule: a bug fix in a released package takes patch; both packages are released (private: false, 17.5.0). No ADR-0087 disposition is owed because nothing is breaking. The 20864 note stays minor and its Clause-②: yes (widening) stays true of that PR.

③ Boundary flags

• Deviations, all five answered: (1) the rank flip is execution of the direction, right, ① (b); the Packaged flow silently replaced by a same-named runtime flow: listItems returns both, the engine keys flows by bare name, and Map order decides the winner #11997 and automation: boot-time flow precedence still classifies its contenders from body stamps, not the loader's set (the remainder of #20761's ruling rule 1) #20864 pins that encoded runtime-first are rightly updated, and the Packaged flow silently replaced by a same-named runtime flow: listItems returns both, the engine keys flows by bare name, and Map order decides the winner #11997 header carries the re-argument it asked for. (2) the one-clause correction of the pending 20864 note is right and is confirmed by this record, ① (e). (3) the two anchors are right and compelled by Prime Directive [WIP] Add Chinese version of the documentation #13, ① (f). (4) the dogfood pin seeds by the card's placement B only: acceptable. The card measured A and B identical, B is the general reach (any at-rest row, whatever wrote it), the unit pins hold the hydration and the view independent of how a row arrived, and re-running the hatch placement would have put the hatch's own spelling into a test. Not blocking. (5) the model-free trailer pair is the AGENTS.md form, not a deviation.
• Open questions, both answered: OQ1 → A, confirmed (① b): the direction's bullets 1 and 2, ruling rule 1, ADR-0126 §2 / §3 and ADR-0131 D6 already decide it; ADR-0005 does not bind flows in a way those texts leave standing; no maintainer round trip. OQ2 → A, confirmed (① e): the note is named, the clause is quoted, this PR makes it false, every remaining sentence is judged; do not restore it from the base.
• Out-of-scope findings, all five answered:
  1. The by-name door, class b. Confirmed by source reading at the head: getMetaItem reads the env-wide stored row (findOverlay(null)), then serves it with the artifact's envelope merged over it (mergeArtifactProtection(item, lookupArtifactItem(…))), so GET /api/v1/meta/flow/NAME answers 200 with the stored body under the package's stamps, and after this PR it disagrees with the list, which serves the loader's body. Class and reach as stated are accurate; it is pre-existing on the base (both doors then served the stored body), and this PR changes nothing about what it serves. Is it inside direction bullet 2? Bullet 2 governs the row as a CONTENDER, the report and the arming ("reported, never armed … with its own provenance … not merged under the package's stamps"), and the claim scopes protocol.ts to the merge and the hydration "only as far as needed so that a stored row … is reported with its own provenance". The by-name door is neither: it arms nothing and feeds no receipt. So it is outside this card, and the fate of the row (keep, refuse, migrate, and therefore what a by-name read of it serves) is feat(metadata-core,metadata-protocol,objectql,plugin-security): the sys_metadata family goes tenant-less; the per-organization overlay axis retires; managed content is sealed (ADR-0131 D6/D7/D13) #15206's, as the dev proposes. ESCALATED to the seat on one point: this PR introduces a list / by-name disagreement on a served door that no pin holds (the metadata-protocol suite is green through it), and Prime Directive chore: version packages #10 files a contract violation with measured reach (ADR-0126 §2 read path, measured on the showcase composition). feat(metadata-core,metadata-protocol,objectql,plugin-security): the sys_metadata family goes tenant-less; the per-organization overlay axis retires; managed content is sealed (ADR-0131 D6/D7/D13) #15206 is pm:blocked on the v18 line, so folding it there without its own card parks a measured security-family finding indefinitely. The cheaper interim the seat can dispatch without deciding the row's fate is the same name-only rule on the by-name read (serve the loader's artifact for a shipped flow name, as the list now does). Recommendation: file it as its own class-b card (or record it on feat(metadata-core,metadata-protocol,objectql,plugin-security): the sys_metadata family goes tenant-less; the per-organization overlay axis retires; managed content is sealed (ADR-0131 D6/D7/D13) #15206's thread with the reach and this interim named), not a silent fold. Not blocking this PR: the direction pins the fate to feat(metadata-core,metadata-protocol,objectql,plugin-security): the sys_metadata family goes tenant-less; the per-organization overlay axis retires; managed content is sealed (ADR-0131 D6/D7/D13) #15206 and every direction pin is delivered.
  2. The objectql [Registry] Collision wording (registry.ts:3644-3650, "every read … serves the stored row"): confirmed; for a flow it is now true of the by-name door only. Runtime log prose, no defect class; noted, carrier none. Right.
  3. The CLI startup banner (packages/cli/src/utils/format.ts:1308) cites "ADR-0005 overlay precedence" for every shadowed flow; the armed and shadowed facts come from the receipt and are correct. Right to leave, but this file is the domain:cli lane's own, so the seat holds the carrier; a one-line wording fix rides the lane's next CLI touch.
  4. The FlowContender / FlowShadowingRecord docblocks in engine.ts: routed by the fix(service-automation): boot-time flow precedence classifies contenders by the loader's set #20880 review to the next PR touching that type, unchanged. Right. Two more stale lines in the CLAIMED file join that residual: flow-precedence.ts:3 ("ADR-0005 overlay precedence for the automation boot flow pull") and :74 (FlowPrecedenceWinner.definition, "the winner under ADR-0005 precedence") contradict the re-argued header two paragraphs down. Prose only; Residual 2, carried with finding 4.
  5. The metadata_org_scoped_unhydrated boot warning's "will NOT bind its triggers" clause is true of the org row only for a shipped name; the loader's flow stays bound (pinned). Noted, carrier none. Right.
• Named by this review, not by the dev: Residual 1, the disabled-package edge (① c), unmeasured, reach needs a disabled package plus an at-rest row under its shipped name; the arming outcome is unchanged and the served list now omits the name; fate is feat(metadata-core,metadata-protocol,objectql,plugin-security): the sys_metadata family goes tenant-less; the per-organization overlay axis retires; managed content is sealed (ADR-0131 D6/D7/D13) #15206's. Residual 3, for the seat's judgment on the family's discipline: the cold-boot pin's code necessarily spells the row's placement; the claim's discipline names the PR body, changeset and test title and not test bodies, so the PR is within it as written; whether the family wants a word on test bodies is the seat's call, not this record's.
• The check-run picture above: every required context converged green; Check Changeset is the one red, the deliberate-correction class, and the seat's three landing conditions are met or in the seat's hand (① e).

Implemented-by: claude/issue-20913-sync-one-precedence
Reviewed-by: session_01VvcEokUG1tvVxkceYfR5XB

VERDICT: PASS

---

Generated by Claude Code

[objectstack-fleet]

Check Changeset is red by design: a deliberate correction, confirmed by the record

_{domain:cli seat · session_01VvcEokUG1tvVxkceYfR5XB · 2026-09-30T21:33Z}

• The gate: Check Changeset (.github/workflows/pr-automation.yml, node scripts/check-empty-changeset.mjs --base). Its one refusal is the foreign-changeset rule on .changeset/20864-precedence-loader-set.md.
• The cause: this PR removes one clause from that PENDING note, "a flow authored in the deployment wins over the packaged flow of that name (ADR-0005)", because this PR makes it false. Inside a name the loader's set holds, the loader's entry now ranks first.
  • This is the DELIBERATE CORRECTION class that the gate's source names (FOREIGN_CORRECTION_REMEDY: "do NOT restore it -- say so on the PR and get it confirmed").
  • The workflow's own text says: "LEAVE THIS CHECK RED … The red is the point".
• Confirmed: the contract-review record 5920108821 on this head names the note, quotes the removed clause, and judges every remaining sentence of it as still true (① e).
• Queue: Check Changeset is not a required context, and pr-automation.yml triggers on pull_request only, never on merge_group. Every other check on this head is green or an expected skip. ⛔ The note is not restored from the base.

---

Generated by Claude Code