# Sync: documented, not implemented

In production, a one-way sync would propagate data the new system owns back
to the legacy store, so legacy-side readers (reports, other integrations that
still query `legacy-db` directly) keep seeing current data for adopted cases.

- **Direction:** new → old only. Never the reverse — once a case is owned,
  the new domain is the sole authority on it (ADR-003), so nothing should flow
  back to overwrite the new aggregate.
- **Shrinks over time:** as more capabilities are taken into ownership (and,
  eventually, as legacy readers are themselves retired or redirected), the
  set of fields this sync needs to cover shrinks. It does not grow.

This demo deliberately does **not** implement it. Its absence has two visible
consequences, both intentional:

1. **The legacy UI shows adopted cases as stale-and-locked, not updated.**
   `/legacy` renders a `migrated=true` row greyed out with actions disabled
   and a link back to the new portal — it does not show the new system's
   edits, because nothing pushes them there. That greyed-out treatment is the
   honest substitute for a sync that does not exist.
2. **Ownership release is blocked once edits exist.** `DELETE
   /api/worklist/owned/{id}/ownership` returns `409` once `domain_writes_since
   > 0` (`ReleaseOwnershipHandler`) — releasing would silently discard those
   edits, since there is
   no sync to have propagated them back to legacy first. The `409` is the cost
   of the missing sync made visible, rather than a data-loss bug made invisible.