[5PK]

PROD-3078. Follow-up to #258: page templates, URL redirections and list order now follow the same rule as content, pages, models, containers, assets and galleries, so conflict detection and --overwrite behave the same for every type.

The rule

Since the last sync	Result
Only the source changed	The target is updated
Only the target changed	The target's version is kept, with a warning ("Target changes kept", preflight, targetChangeKept in --jsonSummary)
Both changed	Conflict
--overwrite	The source wins in the last two cases

Before this, these three types couldn't tell which side changed, so any difference was settled by the source: a target-only edit was overwritten without --overwrite and without a warning.

How

These types have no version or modified date, so the mapping now records the last synced state.

• Templates and redirections: sourceHash / targetHash / fingerprintVersion on the existing mapping record. Each is a sha1 of a normalised shape: the fields the "differs" checks already compare, without per-instance IDs, in a stable order. A template's target hash comes from what the server saved.
• List order: a new listorder mapping per locale, with each list's source order and the target order the run left. A reorder is a change in the relative order of the items the record and the list both have, so adding or deleting an item isn't one.
• Reverse sync: the fields are source* / target* pairs, so they transpose with the IDs.
• Upgrading: a mapping from an older CLI has no record. The first sync lets the source win, as before (preflight labels it "no sync record yet"), and records it. Anything already in sync is recorded without a write.
• Fetch API lag: redirections and list order are pulled from the Fetch API, which shows a change a few minutes after it's made. A sync run in that window used to read the previous sync's own change as an edit: a false "kept" warning, or in a reverse sync the old state synced back. The record now also keeps what the sync replaced (targetReplacedHash, targetReplacedContentIDs). A side still showing it is skipped until the Fetch API catches up, and that pull clears it.

Behaviour changes beyond the ticket

• Kept or conflicting templates: the pages that use one are held back only when it has no section for one of their zones. Those zones would otherwise be placed by position or folded into the main zone.
• Redirection deleted on the target: a mapped one is now a conflict, like a deleted template. --overwrite recreates it. Before, it was recreated silently.

Also in this PR: preflight plans a new model's lists and items

Found testing 1.3.0-beta.1 on a clone pair. A preflight writes nothing, so a model it would create gets no mapping: the container pusher skipped the model's lists ("target model mapping not found"), and hasValidMappings dropped their new items without a preflight entry. The plan showed only the model; the real sync created all of them. Now, in preflight only, a container whose model is planned is planned (and recorded as planned), and an item whose container and model are planned is planned too. Real runs are unchanged.

On the clone pair, for a new model with a list and 3 items: beta.1 planned Models: create 1 and skipped the list; this branch plans Models: create 1, Containers: create 1, Content: create 3. Unit tests in container-pusher.test.ts and has-valid-mappings.test.ts.

CI

The live permutation test now drifts each of the three on the receiving side every round: a list reorder, a template section display-name rename, and a redirection edit (a redirection is added to A before the first sync). drift:listOrder, drift:template and drift:urlRedirection pass only when the edit is kept with a warning, or reported as a conflict.

Getting this reliable needed two harness fixes:

• The runner waits until the Fetch API shows a reordered list's new itemOrder. The order shows up later than the items' new versions.
• content.reorder uses the list item-order endpoint, the drag-and-drop path. Saving items with swapped itemOrder values can leave the list unchanged.

Testing

• Unit tests (2790 pass) cover, for each type:
  • source only, target only, target only with --overwrite;
  • both sides, both sides to the same value;
  • no record, and records from another fingerprint version;
  • a reverse sync reading transposed records;
  • stale pulls on either side.
• Quick tier permutation run 41685279004 passed 24/24 before the rebase onto main. Run 41693418332 is running on this branch as rebased.

🤖 Generated with Claude Code