Your move
Define the release acceptance test
Define complete as behavior a second person can observe and test.
Write a black-box acceptance test from the user's point of view: starting state, actions, expected evidence, failure behavior, recovery, and cleanup. It must fail when the product is not ready.
Do this now
Three moves, in order.
- Use the real entry point and realistic test data.
- Write the expected result as something the tester can see or retrieve.
- Add one meaningful failure and recovery path plus the evidence you will save.
Build the artifact
Release acceptance test
Copy these fields into a note, document, or sheet you already use.
Given
Starting user, state, permissions, and data
When
Actions the tester performs
Then
Observable result and saved evidence
Failure
How the product responds safely
Cleanup
How test data or effects are removed
Give AI the bounded job
Prompt from your artifact—not from vibes.
Turn this user journey into a black-box release test. Test observable behavior, not implementation details. Include one failure and recovery path, evidence to save, and cleanup. Do not mark anything passed without a receipt.
Before you use it
The work leaves your hands only when:
- A second person can run the test without the builder explaining it.
- The test can fail for a meaningful defect.
- Evidence and cleanup are part of completion.
