| name | strangler-backend |
| description | Use to modernize a legacy backend incrementally using the strangler-fig pattern — route slices of traffic to new event-driven / cloud-native services behind stable seams while the characterization harness guards against regressions. Requires the harness gate to be green. |
Strangler Backend
Replace the legacy backend incrementally, never in a big-bang rewrite. Wrap the
legacy system, redirect one capability at a time to new services, and let the
behavior-harness guarantee parity at each step. Aligns with an in-progress engine
refactor toward event-driven architecture.
When to use
- After the harness gate passes, for backend/integration work.
- Prefer invoking through
renovate-orchestrator. If invoked directly, run the
state check below first.
First action: verify renovation state
Before any code work, read plan.md and confirm:
gates.grilling: passed.- For code mode, every seam this slice will touch is
harness: green.
azure-backend-architecture has produced Azure service choices and
Well-Architected tradeoffs for the slice.
If a gate is unmet, stop and route to behavior-harness (or renovate-orchestrator).
Design mode (target architecture, seam/adapter design, slice plan) may proceed
after grilling; code mode (implementing, cutting over, removing strangled code)
requires the harness green for the touched seams.
Method (strangler-fig)
- Erect the façade. Put a stable seam (API gateway / adapter) in front of the
capability you will replace, so callers don't care which implementation serves them.
Base the seam and slice order on the seam inventory and coupling hotspots from
architecture-recovery — strangle the highest-risk, highest-coupling areas
behind the safest seams first.
- Slice thin. Pick one capability (e.g. message registration, send-status
read-model, a single integration link). Smaller slice = safer.
- Handoff code mode to
backend-slice-implementation. That skill locates the
real facade/adapter/IaC code, writes tests first, implements the approved
Azure-backed reversible slice, and records operational evidence. Modernize mixed
DB2DB / TCP / API links toward Azure-hosted APIs/events only where the
approved design reduces coupling.
- Shadow, then cut over. Run new alongside legacy; compare outputs against the
harness golden master; flip traffic when parity holds. Keep a rollback path.
- Remove the strangled code once the new path is trusted. Repeat per slice.
Key targets for this domain
- Realtime send-status read model (event-sourced) so the UI dashboard can show
live status instead of post-hoc statistics.
- System-status signals (process / session health) exposed as events/API rather than
VM-internal checks.
- Decouple bulk-send scheduling so messages need not be manually registered per schedule.
Artifacts
docs/renovation/06-backend/ — target architecture, seam/adapter design, slice
plan & order, integration migration map (DB2DB/TCP/API → target), rollback plan.
Staged goals (30 / 60 / 100)
- 30: engine-integration review + web/engine integration structure & priority.
- 60: first slices live (e.g. single-flow registration, realtime status data-link pilot).
- 100: modernized event-driven backend for the in-scope capabilities; realtime +
system-status feeding the ops dashboard.
Gates
- Requires: harness green. Every slice cut-over must keep the harness green (or update
a pinned expectation deliberately).
- Requires:
azure-backend-architecture gate passed for the slice before backend
code mode starts.
- Produces code → invoke
backend-slice-implementation, which requires
test-authoring and strict-code-review.
Transition
Expose stable Azure-hosted events/APIs that ux-modernization and ai-augmentation
consume. For code mode, invoke backend-slice-implementation for each approved
slice. Feed actual slice outcomes back into azure-backend-architecture when Azure
service choice or Well-Architected tradeoffs change.
Output template and helper script
- Korean template: OUTPUT_TEMPLATE.md
- Scaffold script:
scripts/create-backend-doc.sh <repo-root> <target-name>
