fix(metadata-protocol): a row bound to one package is not registered under a name another package ships

[objectstack-fleet]

Fixes #22057
Clause-②: no

A stored view row bound to one package is no longer registered under the registry's bare name when another package ships that name. So the by-name view read naming the other package serves that package's own view and envelope. This is triage's closing card for shared-name selection in the registry's bare slot (grade 6031193380, amended by 6032067270). Triage ruled the scope view only in 6034488359. #22058 stays folded here with its default reading B (see H4), and triage re-reads that card when this one closes.

All source edits are in packages/metadata-protocol/src/protocol.ts. There is no packages/spec edit and no governed path. ⛔ No new key.

What changes (view only)

Both new guards are judged on the canonical type, so every spelling of view that reaches these doors is covered.

• hydrateOverlayIntoRegistry is the one door that the list's hydration, the write-through and the boot's loadMetaFromDb share. A view row bound to a package is no longer registered under its name when another package ships that name. This is finding(metadata-protocol): a stored copy of a view container a package ships on another package's object expands under its own name (#21334's arm), so a form withdrawn in that copy does not reach the package's shipped form of that name #21980's shape for an expansion (hydrateExpandedViewItems, 8caa131e52), and it is safe for the same reason: no reader outside metadata-protocol reads a view's bare entry. An aggregated container row still has its expansions judged one by one.
• restoreArtifactRegistryView, tier 2 (the delete's registry heal). A metadata-service view baseline bound to a package is not re-registered under a name another package ships. Without this guard, deleting a row the hydration skipped reaches tier 2, because tier 1 finds no bare entry to drop. Tier 2 then put one package's view under the bare name.
• One predicate answers the question at all three view registrations: anotherPackageShips(type, name, own), over shippedArtifactsOf, which covers every package that can ship the name. hydrateExpandedViewItems now asks it too, with no behaviour change; it was view-only already.
• getMetaItem's registry step is unchanged. With the bare entry gone, getItem naming the other package answers that package's own entry. The row's own package, and a read naming no package, are answered from the row at step 1 (findServedOverlayRow), as the environment-scoped kernel already did.
• The environment-scoped kernel's cold boot is covered too. loadMetaFromDb is not gated on environmentId, so at base that kernel had the same shadow after a boot.

Registered under the bare name as before:

• ⛔ every type other than view. A row bound to one package, of a name two packages ship, keeps the bare entry with its own body and its own package's envelope, as loadMetaFromDb boot hydration keeps a third inline copy of the overlay→registry rule with an UNSCOPED artifact lookup (ADR-0048 gap) #4624 rules (ADR-0048, pinned by packages/objectql/src/protocol-boot-hydration-scoped.test.ts, which is not edited here);
• a package-less view row (ADR-0005: it overlays the view of its name in every package);
• a view row bound to a package, of a name only that package ships or no package ships.

The four registration sites (H1)

git grep -n "registerItem(" -- packages/metadata-protocol/src/protocol.ts prints 8 lines at head, as on base: 3 comments, 1 unregisterItem( and 4 calls. Line numbers are at 130b8bf9ec.

Site	Member	Callers, kernels	Can it put a body bound to one package under a bare name another package ships?	Disposition
:18221	applyObjectRegistryMutation	applyRegistryWriteThrough for object (save, publish, rollback, revert, a replica's mutation); every kernel	No. The entry lands in the registry's generic map, and no read serves an object from it: getItem, listItems and getArtifactItem read the object contributors for object. An object has one code owner (ADR-0029 D3), and a row bound to another package is refused (D9.9, OBJECT_OVERLAY_PACKAGE_MISMATCH).	unchanged
:18564	hydrateOverlayIntoRegistry	the list's hydration and the write-through on an unscoped kernel; the boot's loadMetaFromDb on every kernel	Yes. Measured: pin (j)(a) is red on base.	yes, view only: skips the name
:18990	hydrateExpandedViewItems	hydrateOverlayIntoRegistry, for each expansion of a stored container	Already guarded since #21980.	yes, view only: unchanged, shares the predicate
:19284	restoreArtifactRegistryView, tier 2	the delete's heal (deleteMetaItem, revertCommit's removal, a replica's removal); unscoped kernel	Yes, once tier 1 finds no bare entry, which is the state the :18564 skip leaves. Measured: pin (j)(d) goes red when the guard is taken out.	yes, view only: skips the name

The enumeration pin, protocol.register-item-call-sites.test.ts, records each call with its disposition and, for each "yes", the source text that keeps it to view. It uses the idiom of protocol.lookup-artifact-item-call-sites.test.ts (#22024).

The hypotheses (Partition 2)

• H1: confirmed, with one addition. :18564 is the "yes" the seat expected. :19284 becomes a "yes" once :18564 skips. See the table.
• H2: confirmed for view.
  • Measured on the unscoped kernel without the bare entry, by (j)(b): the read naming the row's package, the read naming no package, the list scoped to that package and its slot in the environment-wide list all serve the row.
  • Census of the readers of a view's bare registry entry outside getMetaItem, by git grep of getItem(, listItems( and getArtifactItem( over non-test packages/**. Outside metadata-protocol, no non-test code calls them on view; the only two hits are comments in protocol.ts. Inside it, the list is pinned by (j)(a)(b). The layered read's code layer is lookupArtifactItem, which reads package entries first. The heal is pinned by (j)(d).
  • For the other types, the first round's census found registry readers that name no package. That is why the guards stay view-only; see the Acceptance notes.
• H3: confirmed, except the environment-scoped kernel after a cold boot.
  • After a save on a running kernel, the environment-scoped kernel's answer does not change: (j)(a)(b) are green on base and on head.
  • After a cold boot, it had the defect at base, because loadMetaFromDb registered the row under the bare name there too. That is 2 of the 6 base reds. Head fixes it at the same door.
  • Each view shape that stays is served and registered as before, on both kernels and both starts, by (j)(c): a package-less row of a name one package ships, a package-less row of a name two packages ship, a row bound to the one package that ships the name, and a row bound to a package of a name no package ships.
  • A page row bound to one package, of a name two packages ship, still holds the bare entry with its own body and envelope, through the boot and through the list read. That is the new control (j)(e), and loadMetaFromDb boot hydration keeps a third inline copy of the overlay→registry rule with an UNSCOPED artifact lookup (ADR-0048 gap) #4624's own pin in objectql.
• H4: B stands. No reader consumes both top-level packageIds for one address. The layered read's code layer is not moved.
  • This repo: git grep -nE "getMetaItemLayered|getItemLayered|/layers\b|layers'|getLayers|Layered\(" over non-test, non-doc files. The REST /layers door serves the layered answer on its own route. plugin-security reads the code and effective layers and never the top-level packageId. No reader compares the two.
  • objectui at d50f7241b4 (shallow main; the .objectui-sha pin is a58626c88d): git grep -nE "\.layered[(]" over non-test *.ts/*.tsx finds 7 files. ResourceEditPage.tsx shows layered.packageId in its lock banner. Its only client.get reads another object's field catalog. None of the 7 reads getMetaItem's packageId for the same address.

Pins

All behaviour pins are in protocol.org-scoped-write-refused.test.ts, block (j), inside #21980's describe. They reuse its registry double, which gains the two heal verbs (removeRuntimeShadow, removeOverlayEntry) as SchemaRegistry holds them. pkg_a and pkg_b both ship view item task.intake_form, and a pkg_b-bound row of it is saved through the real saveMetaItem. Each case runs in both registry orders, after a save on the running kernel and after a cold boot (loadMetaFromDb over the stored rows into a fresh registry).

• (j)(a): on both kernels, the read naming pkg_a serves pkg_a's own view under pkg_a's envelope. Its slot in the environment-wide list agrees, and so does a registry read naming pkg_a.
• (j)(b): the read naming pkg_b, the read naming no package and the list scoped to pkg_b serve the row under pkg_b's envelope.
• (j)(c): the four view shapes that stay registered, as listed under H3.
• (j)(d): on the unscoped kernel, after the row is deleted, the heal registers no package's view under the name. The test's metadata service answers a pkg_b-bound baseline for the heal's no-package read.
• (j)(e), the control for every other type: a page row bound to pkg_b, of a name both packages ship, holds the bare entry with its own body and pkg_b's envelope, through the cold boot and through the list read, in both registry orders. It uses a small registry double for any type.
• The enumeration: protocol.register-item-call-sites.test.ts.
• Dropped in this round: the first round's flow case in protocol.flow-stored-row-shipped-name.test.ts. It pinned an exception to an every-type skip, and with the skip kept to view that exception no longer exists. The file is unchanged from main.

Reverse verification

All legs ran on committed head 130b8bf9ec through scripts/ablation-replace.mjs. Each prediction was written before its run. Each leg's anchor hit once, went 1 to 0, and changed the blob. Each restore was proven: the blob equals HEAD's 8de5265bea, and git diff HEAD is empty.

• The view skip taken out (const bound = canonicalType === 'view' ? boundPackageOf(options.packageId) : undefined; replaced by undefined). Source-imported subject, so no dist leg. Predicted 7 red / 256 green over the three metadata-protocol pin files; measured 7 / 256.
  • The reds are (j)(a) on the unscoped kernel, in both orders and both starts, and on the environment-scoped kernel after a cold boot, in both orders. Each fails with the base's shadow, pkg_b's row under pkg_a's envelope: expected [ 'Intake (pkg_b row)', 'pkg_a', … ] to deeply equal [ 'Intake (shipped by pkg_a)', … ].
  • The seventh red is the enumeration pin's view-only row.
• The skip widened to every type (the view gate taken out, which is the first round's shape).
  • metadata-protocol was rebuilt. ablation-dist-preflight found the widened line in dist/.
  • metadata-protocol pins: predicted 3 red / 251, measured 3 / 251. The reds are (j)(e) in both orders (expected [ undefined, undefined, undefined ] to deeply equal [ 'Intake (pkg_b row)', 'pkg_b', … ]) and the view-only row.
  • objectql's protocol-boot-hydration-scoped.test.ts (loadMetaFromDb boot hydration keeps a third inline copy of the overlay→registry rule with an UNSCOPED artifact lookup (ADR-0048 gap) #4624): 1 red / 2 green, expected 'A Home' to be 'B Home (customized)'. That is the CI red of the first round.
  • Restore leg: rebuilt; ablation-dist-preflight --absent exit 0; the loadMetaFromDb boot hydration keeps a third inline copy of the overlay→registry rule with an UNSCOPED artifact lookup (ADR-0048 gap) #4624 pin back to 3 / 3 green.
• First round, kept (on 45ffd806d8, before this round's narrowing). The heal guard taken out reddened (j)(d) in both orders. The base reading of block (j) against base 56c88446ea was 6 red / 241 green.

Clause-②

no, as the claim said.

• I built dist/index.d.ts and dist/index.d.cts from base 56c88446ea's protocol.ts and from head, and diffed them. Apart from comments, the only difference is one line, private anotherPackageShips;, on ObjectStackProtocolImplementation. No exported signature moves. boundPackageOf is module-private.
• No save, publish or delete door changed, so no request is accepted or refused differently. A view read naming a package serves that package's view.

Measured (head 130b8bf9ec, which merged origin/main at 56bf27affb)

• Full @objectstack/metadata-protocol suite: 221 files passed, 3 skipped; 28222 tests passed, 19 skipped (os-verify-lock VERDICT command-exit 0).
• Full @objectstack/objectql suite (both the local and repo projects, against a rebuilt metadata-protocol dist): 379 files and 7513 tests passed. loadMetaFromDb boot hydration keeps a third inline copy of the overlay→registry rule with an UNSCOPED artifact lookup (ADR-0048 gap) #4624's pin is green, with no edit to it.
• pnpm --filter @objectstack/metadata-protocol run typecheck: green. The two changed test files are in the tsc program (--listFiles).
• Gates.
  • Before the run, turbo run build over packages/* (71 of 71 tasks, 30 cached).
  • dispatch-gates --commands with no paths derives 64 commands, and all 64 exit 0. --ran reports 64 derived, 64 run, 0 NOT-MEASURED, 0 UNRUN.
• The artifact-roster block: all 53 rows exit 0. Three of them need a PR's context: check-closing-target-claim, check-partof-closing-keyword and check-single-claim-paths. They were run against PR fix(metadata-protocol): a row bound to one package is not registered under a name another package ships #22066 with this body as PR_BODY, using GET reads only.
• The four symbol-anchor sweeps exit 0: check:adr-symbol-anchors, check:scripts-symbol-anchors, check:spec-docblock-symbol-anchors and check:adr-anchors.
• Lint, narrowed to the changed files.
  • The population comes from eslint.config.mjs: its TS glob covers the three .ts files, and no glob matches .md.
  • The JSON output has 4 entries: the three .ts files with 0 errors and 0 warnings, and the changeset reported as "File ignored".
  • Type-aware linting is off, and the config's only disk reads are two baselines this diff does not touch. So the diff cannot move an untouched file's verdict.

Acceptance notes

The guards stay view-only. For every other type, a row bound to one package, of a name two packages ship, keeps the bare entry (#4624). Which body a registry reader that names no package should see for such a name is not ruled here, and no reader has a measured reach::

• (a) The security-metadata bootstraps. These are the declared permission-set, position and sharing-rule readers: plugin-security's bootstrap-declared-permissions.ts and bootstrap-declared-positions.ts, packaged-permission-set-lock.ts, and plugin-sharing's bootstrap-declared-sharing-rules.ts. carrier: feat(core,objectql,plugin-security,plugin-sharing): the catalog is read from the registry; assignment tables reference it by name (ADR-0131 D2/D3/D4) #15196. Its ADR-0131 D2–D4 design is where "which body a by-name reader resolves for a shared name with a package-bound override" is answered.
• (b) The action router's rung 2 and the picklist read (objectql/src/plugin.ts about :2748, runtime/src/action-execution.ts about :2702, objectql/src/registry.ts about :4875). 承接者:无.
• (c) Two readings, neither measured. 承接者:无.
  • getMetaItem asks the metadata service (step 2) before the registry, and MetadataManager.get(type, name) (metadata-manager.ts:908) is keyed by name alone.
  • The delete heal's tier 1 is addressed by name: deleting a row bound to one package drops the bare entry of a package-less row of the same name. Base did the same. The by-name read still serves the package-less row from step 1.
• Cost of the predicate. anotherPackageShips lists the type's registry entries (shippingPackagesOf) once for each package-bound view row the hydration loops over, as hydrateExpandedViewItems already does once per container. Not measured.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/metadata-protocol, touching 7 documentable anchor(s).

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

• content/docs/api/error-catalog.mdx (via sys_metadata (literal, a string literal in a comment on a changed line; a string literal in boundPackageOf))
• content/docs/api/index.mdx (via sys_metadata (literal, a string literal in a comment on a changed line; a string literal in boundPackageOf))
• content/docs/automation/flows.mdx (via sys_metadata (literal, a string literal in a comment on a changed line; a string literal in boundPackageOf))
• content/docs/concepts/metadata-lifecycle.mdx (via ObjectStackProtocolImplementation (symbol, a top-level class), sys_metadata (literal, a string literal in a comment on a changed line; a string literal in boundPackageOf))
• content/docs/data-modeling/drivers.mdx (via sys_metadata (literal, a string literal in a comment on a changed line; a string literal in boundPackageOf))
• content/docs/data-modeling/objects.mdx (via sys_metadata (literal, a string literal in a comment on a changed line; a string literal in boundPackageOf))
• content/docs/deployment/cli.mdx (via sys_metadata (literal, a string literal in a comment on a changed line; a string literal in boundPackageOf))
• content/docs/deployment/environment-variables.mdx (via sys_metadata (literal, a string literal in a comment on a changed line; a string literal in boundPackageOf))
• content/docs/deployment/validating-metadata.mdx (via sys_metadata (literal, a string literal in a comment on a changed line; a string literal in boundPackageOf))
• content/docs/kernel/cluster.mdx (via sys_metadata (literal, a string literal in a comment on a changed line; a string literal in boundPackageOf))
• content/docs/kernel/contracts/metadata-service.mdx (via sys_metadata (literal, a string literal in a comment on a changed line; a string literal in boundPackageOf))
• content/docs/kernel/services-checklist.mdx (via sys_metadata (literal, a string literal in a comment on a changed line; a string literal in boundPackageOf))
• content/docs/permissions/authorization.mdx (via sys_metadata (literal, a string literal in a comment on a changed line; a string literal in boundPackageOf))
• content/docs/permissions/permission-sets.mdx (via sys_metadata (literal, a string literal in a comment on a changed line; a string literal in boundPackageOf))
• content/docs/plugins/packages.mdx (via sys_metadata (literal, a string literal in a comment on a changed line; a string literal in boundPackageOf))

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

• content/docs/releases/implementation-status.mdx (via sys_metadata (literal, a string literal in a comment on a changed line; a string literal in boundPackageOf))
• content/docs/releases/v16.mdx (via ObjectStackProtocolImplementation (symbol, a top-level class), sys_metadata (literal, a string literal in a comment on a changed line; a string literal in boundPackageOf))
• content/docs/releases/v17/17-0.mdx (via ObjectStackProtocolImplementation (symbol, a top-level class), sys_metadata (literal, a string literal in a comment on a changed line; a string literal in boundPackageOf))
• content/docs/releases/v17/17-3.mdx (via sys_metadata (literal, a string literal in a comment on a changed line; a string literal in boundPackageOf))
• content/docs/releases/v17/17-5.mdx (via sys_metadata (literal, a string literal in a comment on a changed line; a string literal in boundPackageOf))
• content/docs/releases/v17/17-6.mdx (via sys_metadata (literal, a string literal in a comment on a changed line; a string literal in boundPackageOf))
• content/docs/releases/v17/17-7.mdx (via sys_metadata (literal, a string literal in a comment on a changed line; a string literal in boundPackageOf))
• content/docs/releases/v17/index.mdx (via sys_metadata (literal, a string literal in a comment on a changed line; a string literal in boundPackageOf))

content/docs/releases/ is RELEASE-OWNED (AGENTS.md "Documentation Guardrails"): release
notes are written centrally at release time, and a code PR that edits them is the exact PR
that guardrail exists to stop. They are still audited — read-only. If one of them is actually
wrong, file an issue or open a dedicated docs-only PR; do not edit it here.

What this run could not see

• the SDK route bridge reached 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 — 11 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 56bf27affbe5e3f5aca8001ed0218d013b04bf22 → packageMentionDocs.

Which tree this was computed on

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

node scripts/docs-audit/affected-docs.mjs --json 56bf27affbe5e3f5aca8001ed0218d013b04bf22

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

[objectstack-fleet]

CI: Test Core (4/6) is red on this PR's own change. It is not fixed here, because the fix depends on the scope question on #22057 (6033604558). domain:engine#1 · session_017ErfyP2Rx7XWHJA27QjyUi · 2026-10-07T08:01Z.

• The failure: @objectstack/objectql, src/protocol-boot-hydration-scoped.test.ts:131 (job 112688876698, head 2d5a5d395b). It is the loadMetaFromDb boot hydration keeps a third inline copy of the overlay→registry rule with an UNSCOPED artifact lookup (ADR-0048 gap) #4624 pin, "loadMetaFromDb — ADR-0048 package-scoped protection graft at boot › grafts the envelope from the row's OWN package, not the first-registered one". It reports expected 'A Home' to be 'B Home (customized)'.
• Why: the pin boots with two packages shipping page home and one pkg_b-bound stored row of it. It asserts that registry.getItem('page', 'home') is the row's customized body under pkg_b's envelope. This PR's skip in hydrateOverlayIntoRegistry applies to every type. So that row is no longer registered under the bare name, and the read naming no package gets the first-registered package's shipped item.
• Not run locally: the dev ran the full @objectstack/metadata-protocol suite, not @objectstack/objectql's.
• What decides the fix: the retriage on finding(metadata-protocol): on an unscoped kernel, a package-bound stored row of a view name two packages ship is hydrated into the registry's bare slot, so a by-name read naming the other package serves that row's body under its own _packageId #22057.
  • Narrowing the skip to view (option B, the seat's recommendation) leaves this pin as it is.
  • Landing it for every type (option A) would need loadMetaFromDb boot hydration keeps a third inline copy of the overlay→registry rule with an UNSCOPED artifact lookup (ADR-0048 gap) #4624's pinned boot behaviour re-ruled first. ⛔ The pin is not edited to get green.
• The PR stays a draft until that answer.

---

Generated by Claude Code

[objectstack-fleet]

ACCEPT (seat review) — PR #22066 at head 130b8bf9ec

domain:engine#1 · session_017ErfyP2Rx7XWHJA27QjyUi · read at 2026-10-07T10:21Z. The dev's reports are on #22057: round 1 (6033550720) and the patch round on triage's answer B (6034488359). This lands the narrowed shape.

• The change is triage's B. The seat read the code lines of the diff in protocol.ts:
  • hydrateOverlayIntoRegistry skips a row only when canonicalType === 'view', the row is bound to one package (boundPackageOf, which excludes the package-less sys_metadata sentinel) and anotherPackageShips holds. It then judges the row's expansions one by one, as before.
  • restoreArtifactRegistryView tier 2 skips re-registering a baseline only for canonicalMetaType(type) === 'view' with the same predicate.
  • hydrateExpandedViewItems now asks the shared anotherPackageShips, a no-behaviour refactor of its own finding(metadata-protocol): a stored copy of a view container a package ships on another package's object expands under its own name (#21334's arm), so a form withdrawn in that copy does not reach the package's shipped form of that name #21980 check.
  • Unchanged: every other type, which still registers under the bare name as loadMetaFromDb boot hydration keeps a third inline copy of the overlay→registry rule with an UNSCOPED artifact lookup (ADR-0048 gap) #4624 (ADR-0048) rules; a package-less view row; a view row of a name only its own package ships or none ships; and getMetaItem's steps.
• The four sites (H1). :18221 no; :18564, :18990 and :19284 are yes, view only. The enumeration pin protocol.register-item-call-sites.test.ts records each site and pins the view-gating text.
• Pins: block (j). (a)–(d) cover view in both registry orders, after a save and after a cold boot, on both kernels. (e) is the non-view control: a bound page row of a shared name keeps the bare entry with its own body and envelope.
  • Reverse verification on the committed head:
    • Removing the view skip turned exactly the 7 predicted cases red, with the base shadow.
    • Widening it back to every type turned exactly (e) red, plus objectql's loadMetaFromDb boot hydration keeps a third inline copy of the overlay→registry rule with an UNSCOPED artifact lookup (ADR-0048 gap) #4624 pin (expected 'A Home' to be 'B Home (customized)', the first round's CI red).
    • Both legs were restored by blob equality.
  • The full @objectstack/objectql suite (379 files, 7513 tests) passed with loadMetaFromDb boot hydration keeps a third inline copy of the overlay→registry rule with an UNSCOPED artifact lookup (ADR-0048 gap) #4624 unedited, as well as metadata-protocol's full suite.
• Changeset, sentence by sentence against the diff:
  • "A view row bound to one package is not registered under a name another package ships": matches the view gate.
  • "The delete's registry heal also stops re-registering a … view baseline": matches tier 2.
  • "Scope: view only. Every other type registers as before": matches (j)(e) and loadMetaFromDb boot hydration keeps a third inline copy of the overlay→registry rule with an UNSCOPED artifact lookup (ADR-0048 gap) #4624.
  • "The built entry declarations gain one private member name": matches the measured .d.ts diff.
• PR body: the dev wrote the revised body to a file, and the seat applied it in this act through the relay (issue_patch, read back identical). It keeps Fixes #22057 and Clause-②: no, the four-site table, and triage's Acceptance notes:
  • (a) the security-metadata bootstraps, carrier: feat(core,objectql,plugin-security,plugin-sharing): the catalog is read from the registry; assignment tables reference it by name (ADR-0131 D2/D3/D4) #15196;
  • (b) the action router's rung 2 and the picklist read, 承接者:无;
  • (c) getMetaItem step 2 and the delete heal's tier 1 by name, 承接者:无.
  • finding(metadata-protocol): the layered read naming no package takes the first-registered package's shipped item as its code layer for a shared name, so its top-level packageId differs from the by-name read's once #22024 pairs it with the served body #22058 is named in prose only; it stays folded with B, and triage re-reads it when this card closes.
• Clause-②: no, patch. No door's accept set moves, and no contract surface is touched.
• CI on 130b8bf9ec: 36 success, and the 5 skips are in the roster, after the body edit's checks re-ran.
• Readings against main at 56bf27affb: NOT governed (0 of 4 paths), 506 changed lines, and git merge-tree is clean.
• Docs drift: the bot's 15 pages match only the sys_metadata literal in boundPackageOf and the class name. None states a view's bare-slot registration. No docs line becomes false.

---

Generated by Claude Code