test: pin the two keyed-path boundaries that prose got wrong

[b2m9]

Follow-on from #14. Tests only — no source, no docs.

Why these two and nothing else

Of the ten claims corrected in the doc sweep, most were already covered by tests, and the rest aren't usefully testable: the cost figures would need brittle perf assertions, and "does not validate your application schema" is a negative claim with nothing to assert.

Two were uncovered — and they are precisely the two I stated backwards while reading the source, before a probe corrected me:

I wrote	Actual
a non-array delta at a keyBy path "replaces it silently"	it merges: {items:{a:1}} + {items:{b:2}} → {items:{a:1,b:2}}
a replace: ["items[]"] value is swapped in "without inspecting it"	a missing identity, duplicate, or malformed tombstone all throw first

The argument isn't coverage for its own sake. It's that these two sentences have already demonstrated they drift, and a test is the only thing that would have caught it. Nothing else was added.

What is pinned

keyBy engages only for an array delta — a non-array bypasses reconciliation and takes ordinary merge semantics: folds onto a plain-object base (returning it by reference when nothing changes), folds against an empty object otherwise, and a scalar replaces.

items[] is verbatim only after reconciliation decides which item it applies to — missing identity, duplicate identity and malformed tombstone each throw, and a tombstone still removes its item rather than being swapped in.

Existing coverage varied the base shape at a keyed path and covered only the happy path for item replacement, so neither boundary was pinned from the delta side.

Review

GPT-5.6-sol, no blocking defects. It mutation-tested rather than eyeballing: introducing a replacement-specific bypass of identity, uniqueness and tombstone validation produced exactly the four new cases failing while the other 120 passed, confirming they protect a real boundary rather than restating existing coverage.

Its three nits are applied — the keyBy test was misfiled under "ambiguity and failure safety" and now sits in "keyed-list reconciliation" beside the wrong-shaped-base case; the table name now covers all three of its rows; and one commit-message phrase was imprecise about non-plain bases.

124 tests, vp run check green.

---

Summary by cubic

Pins two keyed-path reconciliation boundaries in tests to prevent doc drift; runtime behavior is unchanged.

• keyBy engages only when the delta at that path is an array; non-array deltas use ordinary merge semantics (merge into a plain-object base and return it by reference when unchanged, or replace otherwise).
• items[] replacement is verbatim only after reconciliation chooses the target item; missing identity, duplicate identity, and malformed tombstones throw KeyfoldMergeError, and a tombstone still removes its item rather than being inserted.

^{Written for commit 709c748. Summary will update on new commits.}

[cubic-dev-ai]

No issues found across 1 file

_{Re-trigger cubic}