Review, undo, and commit your first change

This lesson reviews an existing, uncommitted patch: the one the previous lesson asked Claude to make in the course’s payments service, an Express and TypeScript app whose routes begin in src/index.ts, with Vitest tests in tests/ run by npm test. Expect edits to src/index.ts, a new tests/health.test.ts, and possibly an extracted src/app.ts. If you are reviewing an agent’s patch in your own repository, substitute its files; the questions are the same.

The agent has added the endpoint and reported its checks. Before reading that report again, try explaining the change from the files alone. The ticket gives you three things to look for: GET /healthz returns HTTP 200 with the JSON body {"status":"ok"}, GET /health still returns that same status and body, and payment behavior is unchanged.

In a separate terminal at the project root, start with the commands below. They need a Git repository with a baseline commit; if your copy has no history, the install lesson shows how to create one.

git status --short
git diff --stat
git diff

Compare the status with the Git status and npm test result recorded before the change. If you did not record one, establish first which changes belong to this task, from the status and the diff, before you stage anything. git diff shows unstaged changes to tracked files. A newly created, untracked test will appear in git status but not in that diff; open it in your editor. If the agent staged files, inspect those separately with git diff --cached.

Follow the request through the patch

Find where /healthz is registered, then find /health. If the second route disappeared, the new code has met only half the requirement. If both exist, trace them to the response they send.

Next inspect tests/health.test.ts. Does it make requests to the application, or does it build a local object and assert that the object equals itself? A test can be green while proving nothing about the route. Check that it asserts the status and parsed JSON body for both addresses, and that it closes any server it starts.

If the agent extracted src/app.ts, follow the old routes into the new file. A moved block should not quietly change payment calculations or middleware order. This is why the ticket’s boundaries were useful: you have a concrete reason to question edits outside the health routes and the small refactor needed to test them.

Before accepting the test, try a prediction. If /healthz returned {"status":"up"} instead of the required {"status":"ok"}, which assertion would fail? If you cannot point to one, the test does not yet establish the promised body. Correct that gap, then run the focused test and full suite again with the test commands from the lesson that made the change.

Repair a mistake at its actual size

A wrong expected string usually needs a small correction. Ask for that correction and rerun the check. If the agent has misunderstood the task and spread the mistake across several files, returning to an earlier checkpoint may be easier to review than another layer of edits.

Claude Code’s /rewind menu lets you choose a checkpoint and what to restore. With an empty prompt, pressing Esc twice also opens it. Read the selected restoration before confirming; this is a choice about state, not a universal undo key. Checkpointing tracks edits made through Claude’s file-editing tools. It does not undo arbitrary shell commands or changes to external systems.

After a restoration, inspect Git status and rerun the relevant checks. The useful question is what is on disk now. A remembered good state is not a substitute for looking.

Decide whether there is a commit to make

The course payments project’s instructions require passing tests before a commit. Its shipped baseline is six passing tests, so any full-suite failure after this change is a regression unless your own recorded baseline says otherwise. Stop and investigate it. Do not expand the health ticket into an unrelated payment repair just to reach a satisfying ending.

When the required checks pass and the diff is right, stage only the reviewed files. For the app-extraction approach discussed above, the commands would be:

git add src/index.ts src/app.ts tests/health.test.ts
git diff --cached
git diff --cached --check
git commit -m "Add healthz endpoint while preserving health"

Adjust the file list to the implementation you actually reviewed. git diff --cached --check flags whitespace errors and leftover conflict markers before they enter history. If other changes are already staged, separate them first. The commit includes everything in the index, not just the paths from your latest git add.

Explicit staging also catches an easy mistake in agent-generated commit commands: git commit -am does not add new files. It could commit the endpoint and omit its new test. Reading the staged diff lets you inspect what will actually enter history.

The result you want is explainable without the agent’s summary: this route changed, these tests exercise it, these checks passed, and these limitations remain. Put that review loop beside your editor so it is easy to repeat on the next ticket.