legacy-discovery

name	legacy-discovery
description	Use at the start of a legacy renovation to build a BA-style current-state analysis — inventory every screen, feature, data flow, and system integration (DB2DB / TCP / API), and record concrete pain points before proposing any change.

Legacy Discovery

Business-Analyst-style reconnaissance of the current system. Produce a factual inventory and a ranked pain-point list. Do not propose solutions yet — that is requirements-grilling and later phases.

When to use

• First substantive phase after renovate-orchestrator.
• Whenever the current system is not yet documented.

Method

Work bottom-up from evidence (code, DB schema, configs, logs), not from memory.

1. Screen & feature inventory — every screen, its purpose, inputs, and the step-by-step flow. Flag screens reached only via scroll/popup and multi-hop flows (e.g. author → review → approve → result across separate screens).
2. Data inventory — key entities and their sources (recipient data, send reports, system-status, approval history).
3. Integration inventory — every inbound/outbound link and its style: DB2DB, TCP, API — note where styles are mixed and why.
4. Manual-work inventory — steps humans do that the system could: manual send scheduling, manual message registration for bulk sends, VM-console checks for process/session state.
5. Pain-point inventory — for each pain, record: symptom, who it hurts, frequency, and current workaround. Rank by operational cost.

Output

Write docs/renovation/01-current-state.md:

# Current State: <system>
## Screens & flows        (table: screen | purpose | inputs | flow steps)
## Data                   (table: entity | source | consumer)
## Integrations           (table: link | style DB2DB/TCP/API | direction | notes)
## Manual operations      (table: task | trigger | cost)
## Pain points (ranked)   (table: pain | who | frequency | workaround)
## Baseline metrics       (table: metric | current value | how measured | confidence)
## Open questions         (feed these into requirements-grilling)

The Baseline metrics section is required so impact-measurement has comparable before/after data. Capture measurable values now: screen transitions per task, manual send-scheduling effort, time-to-detect send failures, operator-inquiry volume, VM-console checks, statistics-only lag. Record the value and how it was measured, even if approximate — an approximate baseline is far better than none.

Staged goals (30 / 60 / 100)

• 30: full inventory + ranked pain points complete. This is the minimum bar.
• 60 / 100: same inventory; depth of integration/data tracing increases to support actual re-implementation.

Transition

Next is architecture-recovery — the technical counterpart that reverse-engineers how the system is built. Hand it this functional inventory (screens, data, integrations, pain points) and the Open questions list. requirements-grilling runs after both, challenging the target design against functional and architectural reality. Do not start design decisions until grilling closes.

Output template and helper script

• Korean template: OUTPUT_TEMPLATE.md
• Scaffold script: scripts/create-current-state.sh <repo-root> <target-name>