Claimed completion versus tested completion
Verify actual artifacts and requirements before reporting success.
Reviewed: 2026-10-03
Illustrated teaching example • Fictional data
Narration: Microsoft Mark · locally synthesized

00:00:00.000 — “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.

Visual description:
Requirement → Diff → Tests → Artifact

00:00:22.583 — 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.

Visual description:
Success: Display the expected report
Timeout: Show a recoverable error
Privacy: No sensitive payload in logs
Evidence: Diff, tests and observed view

00:00:42.458 — 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.

Visual description:
result = await fetch_report()
show_report(result)

# Missing: timeout recovery
Illustrative pseudocode · not a complete application

00:01:02.750 — 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.

Visual description:
CHECK: valid report → PASS
CHECK: timeout recovery → FAIL
CHECK: safe logging → PASS
STATUS: NOT COMPLETE
Constructed test results · not repository test output

00:01:25.667 — 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.

Visual description:
Identify failed requirement
Repair scoped change
Rerun check
Inspect artifact
Report the observed result and remaining limits.

00:01:49.208 — 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.

Visual description:
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.

00:02:12.833 — 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.

Visual description:
What evidence supports “finished”?
Requirements covered.
Relevant checks actually run.
Artifact inspected; limits stated.
Your evidence: an honest completion record.