[finding] revertCommit's restore limb hands a stored manifest-plural type ('objects') to put, so a legacy plural row's field-order restore is skipped as unchanged and still reported restored #21821

Filing gate: ① a product defect, class (b), on a legacy namespace. A restore is reported done while nothing is written.

• reach: legacy sys_metadata rows stored under a manifest-plural type (objects), written before the meta overlays: unnormalized type segment creates phantom rows that shadow the code-authored listing and cannot be deleted #4432 boundary fold, plus a commit record that names one. Every /meta door folds the spelling today, so nothing new produces such rows. No deployment holding one was measured.
• Measured by metadata: publishing a field reorder from the object designer is a silent no-op — the content hash is key-order-insensitive, so a reordered fields map hashes equal and the draft is dropped #21790's dev with a probe on the real SysMetadataRepository through revertCommit (PR fix(metadata-core): a reorder of an object's fields is a content change, so the designer's publish is no longer dropped (#21790) #21814, patch round 1). The probe was restored: blob equal before and after.

Filed by domain:engine seat 1 (seat post #6367, session_017ErfyP2Rx7XWHJA27QjyUi). Reader who acts: triage grades and routes. ⛔ Not a claim.

Measured

1. revertCommit over a commit item { type: 'objects' } calls put with ref.type: 'objects', and answers revertedCount: 1.
2. Through the same repository, a pure field reorder put under 'objects' leaves the stored order unchanged (dropped as unchanged). Under 'object' it is stored.

Seam

• revertCommit builds its ref from the commit item's stored type (protocol.ts about :23876) and calls repo.restoreVersion(ref, …) (about :24058), which calls put.
• Its guard isNonCanonicalStoredType (about :5240, from finding: revertCommit has no STORED_TYPE_NOT_CANONICAL pre-flight, so a non-canonical stored item degrades to a console.warn where the sibling doors give a wire-visible code #9174) refuses only the six spellings the manifest map omits. A manifest plural such as objects passes.
• protocol.object-registry-write-through-spelling.test.ts (about :433) pins the repository addressing the stored plural row on purpose: "Two different keys, on purpose."
• With PR fix(metadata-core): a reorder of an object's fields is a content change, so the designer's publish is no longer dropped (#21790) #21814, orderedMapKeys('objects') is []. metadata: publishing a field reorder from the object designer is a silent no-op — the content hash is key-order-insensitive, so a reordered fields map hashes equal and the draft is dropped #21790's ordered-fields rule therefore applies to the canonical spelling only, and a plural-addressed restore hashes order-blind.

Direction (triage's call)

• The dev's option B: revertCommit's restore limb refuses every non-canonical stored type, manifest plurals included, with the existing STORED_TYPE_NOT_CANONICAL code. That is finding: revertCommit has no STORED_TYPE_NOT_CANONICAL pre-flight, so a non-canonical stored item degrades to a console.warn where the sibling doors give a wire-visible code #9174's shape extended to the plurals, loud instead of silent.
• That reverses the pinned "two keys, on purpose" behaviour, so it is a ruling, not a quiet change.
• ⛔ Not a spelling-tolerant orderedMapKeys / canonicalize lookup: protocol.ts's meta overlays: unnormalized type segment creates phantom rows that shadow the code-authored listing and cannot be deleted #4432 docblock forbids plural-tolerant lookups by name.

Related

#21790 · PR #21814 · #9174 · #4432 · #8957.

Dedupe words: revertCommit manifest plural stored type, restoreVersion objects plural put, isNonCanonicalStoredType manifest plural, order-blind restore legacy row. MCP search_issues scoped to this repo gave 8 hits, all closed. #9174 is the guard for the six non-manifest spellings; #8957 is the stored-migration residue report. None names the manifest plurals on this limb.

Generated by Claude Code