Legacy testing

Legacy code is code without tests. The job is a net under the behaviour that carries the business, built before anyone refactors. Assess first, propose, wait for approval, then execute.

Steps

1. Assess. Run scripts/assess.sh [path] from the repo root; the path is a file or a folder. It lists the tests anywhere in the repo that import the target, and the files no test imports. Read those tests and the three biggest untested areas, and name, for each, the load-bearing behaviour (money, permissions, data that must not be lost). Then list the target's entry points: every place outside input reaches it (an HTTP route, a CLI command, a message handler, a parser, an exported function called with user data); grep for the target's imports outside the tests and follow them to the edge. Done when you can state, per area: what it does, what it depends on, which tests already touch it, its entry points, and how a mistake there would hurt.
2. Propose. Write the plan with the template below: which steps this repo needs, in which order, and why each one. Choose from the menu; skip what the assessment says is not needed. The refactor is the plan's last step by default, with its target and why; leave it out only when the user said so. Done when every chosen step names its target (files or functions) and its why.
3. Stop for approval, once. Show the plan and wait. The user judges two things: is it aimed at the load-bearing behaviour, and do the tests check behaviour rather than today's implementation? Approving the plan approves its refactor step too. Done when the user approves or edits the plan.
4. Execute the approved plan without stopping. Do the steps in order: open the step's playbook, do it, run the suite, start the next step. Do not ask "shall I go ahead?" between steps; approving the plan approved every step in it. Stop and ask only to: mark a mutant equivalent, change CI or config the plan did not list, or fix a suspected bug instead of pinning it. Start the refactor only after the measure step meets the target, and commit it separately from the tests, in commits that change no behaviour. Done when every step's own completion check passes and the suite is green.
5. Report once, at the end: the score before and after, the tests added, the suspected bugs (the crashes the crash-hunt properties found included), what the refactor changed, the open decisions. Delete every TEMPORARY file first.

The menu