| name | architecture-recovery |
| description | Use after legacy-discovery and before requirements-grilling to reverse-engineer the existing codebase and application architecture — recover the as-is tech stack, module structure, dependency graph, runtime topology, integration mechanics (DB2DB/TCP/API), coupling hotspots, and refactoring seams. Produces the technical baseline that grilling challenges the target (to-be) architecture against. |
Architecture Recovery
Reverse-engineer how the system is actually built from the code itself.
legacy-discovery captures the functional current state (what the system does for
users); this skill captures the technical current state (how the code and app are
structured). You cannot responsibly grill a target architecture without knowing the
real constraints of the as-is one — that is the entire point of this phase.
When to use
- After
legacy-discovery, before requirements-grilling.
- Whenever the codebase's architecture is not yet documented from evidence.
Method (evidence-first — read the code, not the wiki)
- Tech-stack inventory. Languages, frameworks, runtimes, build tooling, package
managers, deployment/hosting (here: Azure). Read manifests, build files, CI, IaC.
- Module / component structure. How the code is organized into modules,
services, layers. Map the real package/dependency graph — including cyclic and
god-module smells. Note where the web portal ends and the send-engine begins.
- Runtime topology. Processes, services, data stores, queues, sessions, schedulers.
How it runs in production (VMs, containers, functions). This grounds the ops
dashboard and system-status work in
ux-modernization / strangler-backend.
- Integration mechanics at code level. For every link
legacy-discovery listed
(DB2DB / TCP / API), find how it is implemented in code: shared tables, socket
protocols, endpoints, auth, error/retry handling. Flag brittle/mixed styles.
- Coupling & hotspots. Where is change risky? Use dependency direction, fan-in/
fan-out, file churn/size, and duplicated logic to rank the riskiest areas.
- Seam inventory. Identify the stable boundaries you can safely refactor behind
(API edges, engine hand-off, integration points, key UI flows). These seams feed
two downstream skills directly: the per-seam
harness map in
behavior-harness, and the slice plan in strangler-backend.
- Target-architecture constraints & options. From the above, state what the
to-be architecture must respect (data ownership, protocol migrations, the
in-progress event-driven engine refactor) and 2-3 candidate directions with
trade-offs. Do not decide here — this is the raw material
requirements-grilling
interrogates.
Output
Write docs/renovation/02-architecture.md:
# As-Is Architecture: <system>
## Tech stack (table: layer | tech | version | notes)
## Module structure (dependency map / diagram; god-modules & cycles flagged)
## Runtime topology (container/context diagram: processes, stores, queues, sessions)
## Integration mechanics (table: link | style | code mechanism | error/retry | risk)
## Coupling & hotspots (ranked: area | risk driver | change impact)
## Seams (table: seam | boundary type | downstream use: harness/strangler)
## Target constraints (must-respect rules for the to-be architecture)
## Target options (2-3 candidate directions + trade-offs, for grilling)
## Open questions (architecture-level, feed requirements-grilling)
Prefer diagrams as committed text (Mermaid / Graphviz) so they live in git and diff.
Staged goals (30 / 60 / 100)
- 30: full as-is architecture recovered + seam inventory + target constraints and
candidate directions documented (this is what grilling needs).
- 60 / 100: depth increases where slices are actually implemented; the seam map
and integration mechanics are kept in sync as
strangler-backend migrates links.
Transition
Hand the Target constraints / options and Open questions to
requirements-grilling, which challenges the to-be architecture requirements against
this as-is reality. Hand the Seams to behavior-harness (per-seam pinning) and
strangler-backend (slice order). Do not start design decisions until grilling closes.
Output template and helper script
- Korean template: OUTPUT_TEMPLATE.md
- Scaffold script:
scripts/create-architecture.sh <repo-root> <target-name>
