Watch the explanation. Practice the skill.
Claimed completion versus tested completion
Verify actual artifacts and requirements before reporting success.
Captions appear here during playback.
Claimed completion versus tested completion
Verify actual artifacts and requirements before reporting success.
Video playback is unavailable. Read the descriptive transcript below, go directly to practice, or open the video file.
Illustrated teaching example • Fictional data · Reviewed 2026-10-03. Microsoft Mark · locally synthesized. On a small screen, use fullscreen for diagram details or read the transcript.
Read the descriptive transcript
0:00 · “Done” needs evidence.
A coding assistant can report completion without satisfying the actual task. Inspect changes, tests, and the artifact before accepting that claim. We will use an illustrated application change with a missing error state. This is a fictional demonstration, not a recording of a deployed application.
What appears on screen
Requirement → Diff → Tests → Artifact
0:22 · Make acceptance observable.
The task requires a report view that displays valid data, handles a timeout, and avoids revealing sensitive content in logs. Write those checks before reviewing the implementation. A requirement that cannot be observed or tested makes completion harder to judge.
What appears on screen
Success: Display the expected report Timeout: Show a recoverable error Privacy: No sensitive payload in logs Evidence: Diff, tests and observed view
0:42 · The happy path is only one path.
The illustrated implementation displays the report after a successful response. It lacks a timeout handler. A happy path test passes, but that does not prove the timeout requirement. Review the actual diff and identify what has changed and what remains uncovered.
What appears on screen
result = await fetch_report() show_report(result) # Missing: timeout recovery Illustrative pseudocode · not a complete application
1:02 · A targeted failure test reveals the gap.
Run the case that matters: simulate a timeout and inspect the resulting interface. In our illustrated trace, the successful case passes while timeout recovery fails. Preserve that failure in the completion status. Do not rewrite a failed check as a minor caveat after claiming everything is finished.
What appears on screen
CHECK: valid report → PASS CHECK: timeout recovery → FAIL CHECK: safe logging → PASS STATUS: NOT COMPLETE Constructed test results · not repository test output
1:25 · Repair, then verify independently.
Add the missing recovery behavior, rerun the targeted check, and inspect the actual artifact. Confirm that the change did not introduce unrelated problems. Keep the scope narrow and review authorization, dependencies, and rollback when relevant. A generated explanation of a fix is not execution evidence.
What appears on screen
Identify failed requirement Repair scoped change Rerun check Inspect artifact Report the observed result and remaining limits.
1:49 · Report completion with its limits.
A defensible report names the changed behavior, relevant passing checks, artifact location, and unverified conditions. If external integration was not exercised, say so. Distinguish simulated or isolated testing from production observations. Evidence makes the status useful to the next person.
What appears on screen
Report and timeout paths checked in an isolated fixture. Sensitive payload absent from test logs. Artifact inspected. External service behavior and production operation remain unverified.
2:12 · Review a completion claim.
Use the capstone or builder exercise to define acceptance checks, inspect a diff, run relevant tests, and review the artifact. Record one limitation. Passing requires evidence for the stated result, not just an assistant’s completion message or a screenshot of the happy path.
What appears on screen
What evidence supports “finished”? Requirements covered. Relevant checks actually run. Artifact inspected; limits stated. Your evidence: an honest completion record.
Watching explains the example. Complete the lesson practice to check what you can do. Explore all visual lessons →