Out-of-scope finding recorded by the dev of #6808 / PR #6818 in its scope notes; filed by the engine-core PM on its behalf. Recorded, not claimed. Pre-existing — not introduced by #6818.
Fact
restoreArtifactRegistryView (the #6687 three-tier heal, packages/metadata-protocol/src/protocol.ts) restores the metadata-map view of an artifact-backed item in tiers 1/2. But an overlay save of an object went through registerObject, which replaced the packaged contributor definition in objectContributors. Nothing in the heal re-registers that packaged definition once the overlay is removed.
#6818 closed the removal half of the same map-vs-contributors split (the new name-addressed SchemaRegistry.unregisterObject, used by the heal's tier-3 object limb for names that are not artifact-backed). This is the restoration half: after an overlay that shadowed a packaged object is deleted, the map view is healed while the contributor list may still hold the overlay-era definition rather than the package's.
Why it was not fixed there
Stated by the dev and endorsed at acceptance: it is undecidable at that seam with the information the walk has — the heal knows the item is artifact-backed, but not which package's definition (and at what priority/ownership) should be re-contributed, nor whether a sibling contributor has since changed the effective shape. Guessing would produce a silently wrong registered schema, which is worse than the current gap.
Related
Grading and routing to triage. If promoted, note that the three cards form one family and the API question ("what re-contributes a packaged definition, and with whose priority?") is the shared unknown.
Out-of-scope finding recorded by the dev of #6808 / PR #6818 in its scope notes; filed by the engine-core PM on its behalf. Recorded, not claimed. Pre-existing — not introduced by #6818.
Fact
restoreArtifactRegistryView(the #6687 three-tier heal,packages/metadata-protocol/src/protocol.ts) restores the metadata-map view of an artifact-backed item in tiers 1/2. But an overlay save of anobjectwent throughregisterObject, which replaced the packaged contributor definition inobjectContributors. Nothing in the heal re-registers that packaged definition once the overlay is removed.#6818 closed the removal half of the same map-vs-contributors split (the new name-addressed
SchemaRegistry.unregisterObject, used by the heal's tier-3 object limb for names that are not artifact-backed). This is the restoration half: after an overlay that shadowed a packaged object is deleted, the map view is healed while the contributor list may still hold the overlay-era definition rather than the package's.Why it was not fixed there
Stated by the dev and endorsed at acceptance: it is undecidable at that seam with the information the walk has — the heal knows the item is artifact-backed, but not which package's definition (and at what priority/ownership) should be re-contributed, nor whether a sibling contributor has since changed the effective shape. Guessing would produce a silently wrong registered schema, which is worse than the current gap.
Related
objectis still served bySchemaRegistry.getObject— the registry heal reaches themetadatamap but neverobjectContributors#6808 / PR fix(objectql): deleting anobjectreally unregisters it — a name-addressedSchemaRegistry.unregisterObject(#6808) #6818 (removal half — introduces the verb this would likely reuse)MetadataFacade.register('object', …)writes where neither of its own object reads look #6725 (the write side of the same split:MetadataFacade.register('object', …)writing where its own reads do not look; dormant in-tree)Grading and routing to triage. If promoted, note that the three cards form one family and the API question ("what re-contributes a packaged definition, and with whose priority?") is the shared unknown.