[Registry] The overlay row's own `package_id` is erased before `registerItem`, so the registry cannot tell a customization from a name collision

[os-warren]

The observation

Found while implementing #12027 (PR #12430 — making the [Registry] Collision warning
order-symmetric). Not a defect in that card's surface; recorded here because it is the
reason that card's new diagnostic cannot be narrower than it is.

sys_metadata rows carry a package_id column, and boot hydration reads it:
loadMetaFromDb passes record.package_id into hydrateOverlayIntoRegistry
(packages/metadata-protocol/src/protocol.ts). But that value is used ONLY to scope the
artifact lookup. The registration itself is package-less:

const artifact = this.lookupArtifactItem(type, name, options.packageId ?? undefined);
registry.registerItem(type, mergeArtifactProtection(data, artifact), 'name' as any);

mergeArtifactProtection then stamps the ARTIFACT's _packageId / _provenance /
_lock envelope onto the overlay body (ADR-0010 section 3.3 — correct, and load-bearing
for lock resolution). Consequence: by the time the row reaches SchemaRegistry.registerItem,
a row that is a deliberate customization of package P's item and a row that was authored
independently and merely collides with P's name are byte-identical — both arrive under the
bare key carrying P's _packageId and _provenance: 'package'.

Why it matters

The two populations have opposite operator meanings. A customization shadowing its own
package baseline is ADR-0005 working as designed. An independently authored row shadowing a
packaged name is an accident, and the packaged definition is dead on every boot from then on.

The existing artifact-second collision guard CAN separate them, and does — its
!dbOnly._packageId test narrows to a package-LESS row. The overlay-second direction
(#12027) cannot, so its message has to state both readings instead of naming the one that
happened. Measured on a real @objectstack/example-crm boot: one customized view produced
4 registrations that are indistinguishable at this seam from 4 accidental collisions.

The shape a fix would take, if it is ever wanted

Forward the row's own binding to the registry as an overlay-binding HINT — a new options
argument, deliberately NOT registerItem's existing 4th parameter, which selects the
composite storage key and would therefore move precedence. With it the diagnostic could say
"a row bound to no package is shadowing package P's item" (accident) versus "P's own
customization is in effect" (normal), and the normal one could stop printing.

Implementation-first, and probably not now: it widens a hot signature to sharpen one log
line, and the log line is already accurate about the consequence. Filed so the constraint
is written down rather than rediscovered by the next person who tries to narrow this
warning.

Read at

origin/main cdbd9204b6. Dedup search was NOT performed through the prescribed channel:
REST list endpoints answer 403 from this seat (#12123 — measured again during this task,
GitHub access is not enabled for this session) and MCP search_issues is unreliable for
known hits (#11835). A local grep of the tree found no existing note of this constraint.
Unassigned, not claimed.

Generated by Claude Code

[os-trump]

Triage: closing not planned, on the filer's own assessment — implementation-first: the fix widens a hot registerItem signature to sharpen one log line that is already accurate about the consequence, and there is no measured consumer. The card IS the record it set out to create: the constraint (overlay rows reach registerItem package-less, so a deliberate customization and an accidental name collision are indistinguishable at that seam) is now written down and grep-able.

Reopen criteria (reopening is free; the maintainer can veto this close): (a) someone needs the collision warning narrowed — #12027's diagnostic having to print both readings becomes an operational problem; or (b) a real accidental-shadowing incident lands where a packaged definition goes dead on boot and the log could not name it.

Source for the disposition: the filer's own "implementation-first, and probably not now", and the maintainer's 2026-08-16 direction that work not planned for development is closed rather than parked (card = record, reopen free). Cross-ref: #12027 / PR #12430 (the diagnostic this constrains).

---

Generated by Claude Code