Give an audit room to observe before repairing
Separate findings from fixes, and uncertainty from confirmed defects.
When the project growsAbout 2 min read
Looking and changing are different tasks
A broad request to “check everything and fix what you find” can mix important defects with preferred refactors. The resulting change may become too large to connect each repair with the problem it was meant to solve.
In the preparation work around My Next Step, a read-only audit offered a different starting point: inspect the system and report consequences before changing it. That gives me something to judge and prioritise while the candidate stays stable.
A useful finding needs evidence
Define the areas to inspect: permissions, persistence, service failures and the first-use journey may matter more than file aesthetics. Require a location, a reproducible sequence, the affected person or data and a clear distinction between confirmed behaviour and an untested concern.
Read-only should cover runtime effects too. A browser click, test or script can write data even when no source file changes. Use safe fixtures and agreed environments, and state which checks were not possible. Reading more files does not by itself guarantee a complete audit.
Repair in changes that can be checked
Group confirmed findings by consequence and dependency. Decide which need repair before release, which need investigation and which are acceptable for the current boundary. Then give each repair a bounded outcome and the checks that would establish it.
An audit informs that decision; it does not certify a launch. The useful result is a clearer account of what is known, what needs to change and what still has to be tried.