Work in small steps

A large request can produce a large diff whose mistakes are hard to locate. Break the work at natural behavior boundaries: inspect, implement one result, verify it, then continue.

Small does not mean one file or ten lines. A useful step is small enough that you can:

• state one expected result
• choose a check that supports it
• review the complete diff
• reverse the change without discarding unrelated progress

Split by behavior, not technical layer

Suppose the task is add profiles, avatars, display-name validation, and account deletion.

Editing every database helper first is a technical-layer split. Nothing user-visible is complete, and the diff may contain assumptions needed only by later features.

A better sequence is:

1. Trace the current profile update flow.
2. Add server-side display-name validation and its tests.
3. Show validation errors in the existing form.
4. Add avatar upload as a separate behavior.
5. Design account deletion with its own safety review.

Each checkpoint produces one coherent result. It can include a route, helper, and test if all three are required for that behavior.

Make the check fail first when possible

For a bug fix, reproduce the problem before editing. Add a focused regression test and run it. A failure for the expected reason shows that the test reaches the bug.

Then make the smallest change that fixes that case. Run the focused test and the nearby suite before expanding scope.

Record the checkpoint

At each step, note:

Changed: reject display names longer than 50 characters
Evidence: request test fails before the fix and passes after it
Uncertainty: browser error message not implemented yet

This keeps a long task honest. Passing one test does not silently become the whole feature is done.

The goal is not to supervise every keystroke. It is to keep feedback fast enough that a wrong assumption cannot spread through the project.