backfill-feature

To document legacy code before refactoring, you can backfill missing architectural records and Gherkin specs by reading the current codebase, confirming the inferred baseline, and generating retroactive ADRs to capture existing design constraints.

Characterization testing for existing features involves writing tests that lock in the exact current behavior of the code, creating a verified baseline that prevents accidental regressions during future modifications or refactors.

Writing a retroactive ADR for an undocumented module requires reading the existing code to reverse-engineer the current design, inferring the original rationale, and drafting an architecture decision record that captures load-bearing constraints.

Yes, you can generate Gherkin specs for untested code paths by analyzing the implementation to capture both golden paths and handled edge cases, producing a behavior specification that reflects the actual current logic.

The best way to prevent regressions when modifying old code is to first backfill baseline documentation and write characterization tests that pass against the current implementation, ensuring future changes layer safely on top.

When code execution is unavailable, characterization tests are still generated based on the inferred behavior but are explicitly marked as unverified, ensuring the baseline is documented while signaling that execution validation is pending.