ehoandClaude Haiku 4.5
ddec15ccb2
Added three new documents with nine Mermaid diagrams to make the strangler fig strategy visible: - README: container topology diagram at the start, with the proxy entry point and three seams labelled - docs/architecture.md: five diagrams tracing the exact implementation: - The four seams and who holds authority at each boundary - How by-id read goes through the resolver, but list-read bypasses it - Case lifecycle state machine (the strategy in one picture) - Take-ownership sequence with failure windows annotated - Write-through error round-trip showing zero validation logic crossed - docs/playbook.md: how to apply this to a production system: - Write-path decision tree (five read/write patterns) - Cutover ordering diagram (side-effects-free first, least recoverable last) - Seven transferable rules with pointers to the files that demonstrate them - Scope diagram of what's proven vs. left as your decisions Resolved all 13 dangling § citations (to an absent spec doc) by linking to the actual files or dropping them. Replaced portal-frontend/README.md boilerplate with accurate content. All diagrams parse and link-check clean. Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
28 lines
1.5 KiB
Markdown
28 lines
1.5 KiB
Markdown
# 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.
|