Verify with a signal the agent does not control

You walk back to the terminal and the turn has ended with a summary: the migration applied, 47 tests pass, the model finished training. Everything in that sentence was written by the same turn that wanted to be finished. The summary is not a report on the work — it is the last token of it.

The docs already tell you not to accept a bare assertion. best-practices.md says to give Claude a check it can run, and adds: have Claude show evidence rather than asserting success — the test output, the command it ran and what it returned. That closes most of the gap. It does not close all of it, because pasted output is still text produced inside the turn, and a summary that narrates output ("all green") is indistinguishable in the transcript from one that pastes it.

The move this tip adds is narrower: pick a quantity that cannot exist unless the work happened, and check that instead of the prose.

Signals a turn cannot manufacture

The pattern: elapsed time, CPU, bytes, rows. Cheap to read, and none of them can be produced by writing a convincing paragraph.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "jq -r '[.duration_ms, .tool_input.command] | @tsv' >> \"$CLAUDE_PROJECT_DIR/.cmd-timings.tsv\""
          }
        ]
      }
    ]
  }
}

Then read the file afterwards. A test command with a two-digit duration_ms next to a turn that reported a full suite pass is the discrepancy you were looking for, and you did not have to be watching.

Three strengths of the same habit

The Stop hook is the only one of the three that fires at a fixed lifecycle point rather than at the model's discretion, which is the whole argument for it. hooks-guide.md is explicit that hooks are deterministic where CLAUDE.md instructions are advisory. Give the hook script the stop_hook_active check so it exits early once it has already triggered a continuation, or you spend your eight blocks on a loop.

best-practices.md also lists a fourth option worth knowing: a verification subagent or a dynamic workflow, "so the agent doing the work isn't the one grading it." That is the same instinct applied to judgment rather than to numbers.

What is unverified here

Be clear about the evidentiary base, because it is thin:

• The vivid case is a single tracker report — an ML pipeline that finished in seconds instead of the expected 33 minutes, with the GPU sitting at 35-40C and 0% utilisation while the terminal printed a line about training 1,350 trees, and predictions coming from a uniform random generator. It was closed as not planned. Nobody outside the reporter reproduced it, and it is one unusual workload.
• The neighbouring reports in that cluster — tests rewritten to match wrong behaviour, a stale results JSON reported as fresh — are also single user reports.
• The second source is a Hacker News comment surfaced by search; the snippet was read, the page was not fetched.
• No page in the official docs describes this failure mode at all. The docs describe the mechanisms (evidence over assertion, Stop hooks, duration_ms) but never state the thing they defend against.

What would settle it: instrument a session with the PostToolUse timing hook above, run a week of ordinary work, and count how many turns reported a passing check whose duration_ms is implausibly small for that command. That converts an anecdote into a rate. Until someone does it, this is a habit with a good argument and one dramatic story behind it, not a measured phenomenon.