How to Accept Work When Claude Code Says It's Done

Suppose Claude Code tells you: "The bug where old refresh tokens still work after logout is fixed." What would you need to see before you accept that?

Most people check whether the typecheck passed and the tests are green. But a passing typecheck only answers "are the types right?" And a green test suite may simply have no test covering "an old token should stop working after logout." The hard part of a complex task is that if all you said at the start was "fix the logout feature," you have no standard to judge by at the end, and accepting or rejecting the work comes down to gut feeling.

A better order runs backward: before any work starts, decide which kinds of evidence you'll look at when it's done. For this token bug, four kinds make a good start:

• Behavioral evidence: after logout, the old refresh token can't get a new token.
• Compatibility evidence: normal login, normal refresh, and the multi-device policy still behave as agreed.
• Automated evidence: the relevant tests, typecheck, and build all pass.
• Review evidence: the scope of changes, remaining risks, and uncovered environments are spelled out.

With the evidence decided, research knows what to look for, verification knows what to run, and review knows which edges to check. The rest of this post works backward from those four kinds of evidence through the whole task.

01 What "Just Fix It" Leaves Out

A complex workflow has to connect each stage's inputs, outputs, and entry conditions. Take "an old refresh token still works after logout": first find out how tokens are stored and validated, then decide how to revoke them while keeping normal refresh and multi-device behavior intact. Each step needs evidence from the one before.

"Fix the logout feature" gives none of those grounds for judgment, and piling on documents and agents won't fill them in automatically. Settle acceptance first, then plan research, planning, implementation, verification, and review.

The Claude Code best practices put the problem sharply: Claude stops when the work looks done, and if it has nothing to run that tells it whether the work actually is done, "looks done" is all it has to go on. In practice, that makes you the test suite, and every mistake sits there until you happen to notice it. The guide's advice is to give Claude a check that comes back pass or fail, such as a test file, a build's exit code, a linter, or a script that diffs output against a fixture.

02 Work Backward from What You'll Check at the End

Jump ahead to the end of the task for a moment. If Claude says it's fixed, what will you look at before accepting? Answer that, then plan research, implementation, and verification working forward, and the evidence you need has a direction.

A refresh-token fix can start with four kinds of evidence:

Working back from "reject the old token after logout," research has to find the storage, test fixtures that keep old tokens, and the refresh validation path. From "normal refresh still works," it has to check existing tests, the multi-device agreement, and how old data is handled. That keeps research centered on the checks that come later. With those answers in hand, implementation can be planned; further investigation should focus on questions that could change a decision, and how long it takes still depends on the code and environment.

Material from this stage has to be usable in the next one. A well-formatted document isn't a substitute for that evidence. How research, planning, and implementation connect is covered in building big features with Claude Code, step by step.

03 Verification: Bring Back the Original Evidence Requirements

Verification signals should be repeatable: test exit codes and failure details, build and type results, API responses, visual comparisons, data-state changes, or log events.

When you reach verification, bring out the evidence requirements you set at the start. Whether the bug can be reproduced, and whether normal refresh, post-logout rejection, multi-device behavior, and concurrency match the agreement, each needs a corresponding result. Even if pnpm typecheck has passed, it only answers the typecheck question; the auth behavior needs checks of its own.

Reports should include the actual commands and a summary you can check. High-output tests can go to a subagent that returns only failing cases, key errors, and log locations. The best practices guide is direct about this too: whichever kind of check you use, ask Claude for evidence, meaning the command it ran and its output, or the screenshot. "All tests pass" on its own tells you very little, and reading the output is faster than rerunning the check yourself.

04 Review: A Fresh Perspective That Isn't Anchored

Whoever implemented the change tends to carry its assumptions forward. Have a read-only subagent in a fresh context actively look for missed call paths, concurrency conditions, security boundaries, and test blind spots. The subagents documentation explains that each subagent starts with a fresh, isolated context and can't see your conversation history or the files Claude has already read, which is exactly the starting point an independent review needs.

An independent review needs a new context, a review task, and evidence requirements. Even with a different model, check these conditions:

• the reviewing agent isn't anchored by failed attempts during implementation;
• it receives a clear change scope and acceptance criteria;
• it must provide files, line numbers, and triggers as evidence;
• the main session checks the findings before adopting them.

Hand the original acceptance criteria to the reviewer. Even when the old token is rejected after logout, concurrency and multi-device agreements still need checking; a style-only review would miss those edges.

The official recommendation lines up: have a fresh subagent that never saw the conversation review the diff, since it isn't swayed by the reasoning that produced the code. To have the review check the work against your plan rather than hunt for bugs in general, write the review prompt yourself, for example asking a subagent to review the diff against a spec, check that every requirement is implemented and the listed edge cases have tests, report gaps that affect correctness, and skip style. The guide specifically warns against dropping the "skip style" part: a reviewer asked to find problems will always find something, and fixing every finding leaves you with extra abstraction layers and tests for cases that can't happen.

A fresh context helps reexamine assumptions, but it doesn't guarantee an unbiased reviewer. Choose review depth by task risk and size. How to define that reviewer as a read-only role is covered in a read-only code review subagent for Claude Code.

Back to "it's fixed." With these four kinds of evidence, what you look at is no longer a one-line summary. It's the actual response rejecting the old token after logout, tests showing normal refresh still passes, the commands that ran and their output, and a review that states the remaining risks. Settle acceptance up front, and every step after it has a direction. If a fix keeps failing its checks, knowing when to stop is covered in when to stop Claude from retrying a failing fix.