RFC-0045: a person's write drops entry_refs rows of an unconvertible old-shape value under a reference <-> repeater marker #215

Found in the final check of #214 (RFC-0045 step 4). The finding is contested: one of two verifiers upheld it. It cannot happen today, because the reference and repeater types stay refused on every write path until step 7. It should still be fixed before step 7.

Path: packages/core-ts/src/store/entry-fields.ts, normalizeWrite → onUnconvertible. That function returns early when convertingPath(def) is undefined, which is the case for every top-level reference <-> repeater reshape marker. So held stays empty for an old-shape value that does not convert. entryRefStatements then rewrites the node's rows under the new definition, and the old-shape ids lose their rows.

Effect:

• While such an operation runs, a person's unrelated write (a title edit, for example) can drop the rows of a published entry's old-shape references.
• The target's delete guard then under-blocks.
• Round 6's rebuild (reshapedRows) keeps the same rows. So whether the target is locked depends on whether a write or a reimport touched the node last.

Reachability: narrow. A repeater → reference retype is always multiple (retype.ts ownProperties), so the "2 entries chosen" example in the review cannot occur. What remains is an old-shape value that fails to convert for another reason, such as a malformed list for reference → repeater.

Fix: in onUnconvertible, when convertingPath is undefined and fromType is reference or repeater, record failures with the old-type field paths, the same paths reshapedRows computes. heldRefs then keeps them, and so does entryRefStatements.

Test: an unconvertible old-shape value, then a title edit, then deleting the target must return entry_referenced.

Fold this into step 7 of RFC-0045 or an earlier step.

🤖 Generated with Claude Code