ForgeLoopAcceptance criteria are a contract between an issue author, an implementation, and a reviewer. For coding agents, they are also a way to stop a persuasive explanation from being mistaken for completion.
Describe behavior a test can observe
“Make errors better” leaves room for almost any change. “When saving fails, preserve the entered values, display an error associated with the form, and allow another attempt” can be checked. Good criteria specify the starting state, the action, and the expected result without unnecessarily prescribing the internal design.
Avoid treating one implementation detail as the entire requirement. A toast can exist while the form still loses data. A retry button can exist while the second request is never sent. Verify the behavior that matters to the person using the application.
Include boundaries and negative cases
Permission behavior is often more important than the happy path. A user from another organization should not be able to read or modify the record. A repeated submission should not create duplicate work. An unavailable dependency should produce a recoverable result rather than a false success message.
Write these cases into the issue before implementation. Tests created afterward can accidentally encode the implementation's assumptions instead of challenging them. Independent verification does not require an entirely separate testing framework; it requires deriving checks from the requirement rather than accepting the author's claim.
Map each criterion to evidence
Use a short identifier for each criterion and name the evidence expected for it. A unit test may prove a calculation, an integration test may prove persistence, and a browser test may prove focus and recovery behavior. A screenshot demonstrates a visible state, not necessarily a successful database update.
For example, assignment recovery might require a failing first response, unchanged UI data, a visible retry action, and a successful second response. Preserve the test output and the commit under test so reviewers can reproduce the result.
Keep “not verified” available
Some criteria need credentials, real infrastructure, or a funded model account. Record that boundary instead of replacing it with a mock and calling the original requirement complete. Offline tests are valuable precisely when their scope is clear. Read testing without API spending for a layered approach.