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>
1.5 KiB
1.5 KiB
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:
- The legacy UI shows adopted cases as stale-and-locked, not updated.
/legacyrenders amigrated=truerow 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. - Ownership release is blocked once edits exist.
DELETE /api/worklist/owned/{id}/ownershipreturns409once `domain_writes_since0
(ReleaseOwnershipHandler) — releasing would silently discard those edits, since there is no sync to have propagated them back to legacy first. The409` is the cost of the missing sync made visible, rather than a data-loss bug made invisible.