find-refactor-candidates

To identify refactor candidates and reduce technical debt safely, generate three to five materially different options including a do-nothing baseline and a minimal surgical change. This approach keeps the decision space explicit before committing to a specific architecture plan.

To document assumptions for architecture refactor options, create a full assumption ledger for each candidate. Each ledger details scope, evidence, risks, and payoff, keeping the decision auditable and explicit within a dedicated work-item directory.

Yes, you can generate a minimal surgical change option specifically for boundary extraction. The process produces multiple diverse candidates, ensuring you evaluate a low-risk surgical alternative alongside more comprehensive architectural refactors.

To structure work-item artifacts for architecture reviews, create a dedicated directory using a slug derived from the initiative. Store a candidates.md file alongside individual assumption ledgers to keep the decision space explicit and auditable.

You need a do-nothing option in technical debt reduction planning when evaluating materially different refactor paths. Including a baseline do-nothing candidate alongside surgical changes and full refactors ensures you explicitly evaluate the cost of inaction before committing.