✅ Faithful verification and reporting
The last module of Practice, and what separates those who “think it worked” from those who knows it worked. An edit is just a hypothesis; a real check is proof. Here you build the reflex to run the real test, confirm before doing anything irreversible, recover from errors methodically, and report what happened plainly. It’s the piece that makes an AI trustworthy.
Detailed content
An edit is a hypothesis
You just changed one line of the prompt, or asked for a correction, and it seems right. Stop there: seeming right isn't evidence of anything. An edit is just a guess dressed up as a solution — a hypothesis. The question that matters isn’t "does it look good?" but "how do I know it’s good?" The answer is always the same: because a real check passed.
🔬 The idea in one sentence
Every change you make is a hypothesis — a bet that the problem will go away. It becomes knowledge only when you run the verification and see the result. Before that, you haven’t fixed anything; you proposed a correction.
This is the thought that changes everything: separate the act of changing (cheap, fast, uncertain) from the act of proving (what actually gives you confidence). Whoever confuses the two delivers "it probably works" thinking "it's done."
"An edit is a hypothesis. A passing check is the evidence."
Two sentences. The first dispels the false sense that you're done; the second tells you where confidence really belongs—in the check, not in your optimism.
Why this matters to you
Because AI is optimistic by default: it tends to report success it hasn’t verified. If you don’t require proof—in the prompt and in your own habits—you inherit that optimism. Treating each change as a hypothesis is the antidote: it forces the question "what check would prove this?" before any "done."
Run the REAL check, not a charade
Here’s the most common and most invisible mistake: running a check that seems verification, but it doesn’t verify anything. A ls that confirms the file exists. A echo that prints “ok.” Any old command that exited with code zero. None of that proves your change worked. The real check is the test, build, lint, or typecheck the project actually uses — and run the real thing, not a comforting substitute.
✓ Real check (the evidence)
- ✓Run the project test and read what passed/failed
- ✓Run the build the whole thing and see if it actually compiles
- ✓Give the real task to the AI and check the output against the criterion
- ✓Open the thing and observe the behavior, not just the exit code
✗ Verification theater (proves nothing)
- ✗A ls that only shows the file is there
- ✗A echo "funcionou" that you wrote yourself
- ✗A command unrelated that exited with code 0
- ✗"I looked and seems right" — reading instead of execution
🎯 If the project calls for the full suite, run the full suite
The temptation is to run only the test for the small piece you changed. But your change may have broken something far away — and a handpicked subset won't catch that. Narrowly scoped verification is the easiest way to declare “passed” while something is broken outside your field of view.
This is, according to the collection itself, the discipline more neglected — running the actual check after editing happens only a minority of the time. That's why it's non-negotiable: this is exactly where you can do better than average.
In the prompt: name the check; don't let the AI make one up
In the block <loop>, the VERIFY step has to say which is the real check for your case: "run npm test", "run the build", "do task X and check the output". If you don't name it, the AI chooses the cheapest path — and the cheapest path is usually theater.
Confirm before the irreversible
Verification is about what has already happened. Confirmation is about what’s going to happen — and it’s especially important when the action is hard to undo or goes outside. Deleting, overwriting, publishing, sending an email, calling an external service: in these cases, the right thing is to check first. A quick “can I?” costs a second; an email sent by mistake costs a relationship.
<seguranca> Para ações difíceis de reverter ou voltadas para fora (deletar, sobrescrever, publicar, enviar a serviço externo): confirme antes, a menos que duravelmente autorizado ou mandado prosseguir. Aprovação num contexto não se estende ao próximo. Antes de deletar/sobrescrever, olhe o alvo: se o que achar contradiz como foi descrito, ou você não o criou, levante isso em vez de prosseguir. </seguranca>
! Stop and confirm first
- ⚠Delete files, records, branches
- ⚠Overwrite something you didn’t create
- ⚠Publish / submit to an external destination (email, post, deploy)
- ⚠Anything looks like undo or that affects other people
✓ You can proceed without asking
- ✓Read, list, search, inspect (reversible)
- ✓Edit a draft that you yourself is assembling
- ✓When the user already authorized that dur action, or told it to proceed
- ✓Internal steps with no effect outside your workspace
"Approval in one context doesn't extend to the next"
You enabled sending one email? That doesn’t give you blanket permission to send everything. Each irreversible action needs its own green light—unless you’ve authorized durably ("you can always send it without showing me"). That detail prevents an "okay" from turning into an "okay for everything."
Faithful reporting, no hedging
Verified? Now tell the truth about what happened. If the test failed, say it failed and show the output. If you skipped a step, say you skipped it. If it’s done and verified, state that plainly, without "I think" or "probably." Confidence is built through precise reporting — not optimistic reporting. An AI that dresses up an unverified result as ready is eroding the one thing that makes it useful: your ability to believe what it says.
"Report outcomes faithfully: if tests fail, say so with the output; if a step was skipped, say that; when something is done and verified, state it plainly without hedging."
✓ Faithful reporting
- ✓"The tests pass — here’s the output: 14 passed, 0 failures."
- ✓"Failed in 2 cases; the error was X. Here’s the log."
- ✓"I skipped it the build because the environment was missing the dependency."
- ✓"Done and verified." — said without beating around the bush, because the check passed
✗ Optimistic reporting (hedging)
- ✗"It should be working now!" — without having run anything
- ✗"Done!" when the test failed and it didn’t count
- ✗Skip the skipped step and let you think it ran
- ✗"It’ll probably fix it" disguised as "it’s resolved"
"It probably works" isn’t done
There is a one-sentence test to tell whether an account is faithful: it distinguishes "it probably works" of "the tests pass, here's the output"? The first is a guess dressed up as a conclusion. The second is actually done. Hold the AI—and yourself—to that.
Recover from errors without flailing
Errors are normal — what separates discipline from luck is the answer to the error. The bad reflex is to run the same command again, exactly as before, hoping for a different result. That’s fumbling in the dark. The good reflex is a short loop: diagnose → fix → verify again. You read the error, understand the state, form an informed fix, and only then try again. Look at the diagram above: that’s exactly the path along the bottom.
0. The failure happens
The check failed. A starting point—not a reason to panic.
The red test, the build that broke, the wrong output. This is information, not failure. The failure is telling you where to look. The worst thing you can do now is ignore it or blindly repeat the command.
1. Diagnose—read the error, inspect the state
The step almost everyone skips. This is where the fix is born.
Read the entire error message. Run it again with more visibility if needed. Open the file or state that matters. You’re looking for the cause, not by covering up the symptom. Without a diagnosis, any fix is a guess.
2. Correct — one informed change
Now you actually change something—but guided by what the error revealed.
Form the correction from the diagnosis and apply it. Note that this correction is, once again, a hypothesis — closes the loop on topic 1. You still don’t know whether it worked; you’ll only know in the next step.
3. Re-verify — run the check again
Without this step, you didn’t correct it—you only changed it.
Run the same real check. Did it pass? The error is gone — move on and report it. Did it fail again? Go back to step 1 with the new information, don’t blindly repeat. And if you can't solve it after trying, go to topic 6: state it clearly, with the evidence.
<recuperacao> Quando um comando falha: não repita igual esperando resultado diferente. Leia o erro → inspecione o arquivo/estado → forme a correção → corrija → re-verifique. Nunca largue um turno que falhou em silêncio. Se não resolver, diga claramente, com a evidência. </recuperacao>
Repeating the same command is antipattern #1
If the command failed and you run it again without changing anything, it will fail again—the state didn’t change on its own. Each new attempt needs to include a new piece of information: either you changed the thing, or you changed what you're looking at. An attempt without anything new is just noise.
Never leave a turn in silence
The last rule, and the easiest to follow: don’t disappear. If a task gets stuck and you can’t resolve it, that’s no excuse to end the turn pretending it worked, or to leave without saying anything. Say clearly what happened, show the evidence, and be honest about where you stopped. "I couldn’t do it, and here’s why" is infinitely better than silence that leaves you to discover the damage later.
📣 What “not to drop it silently” means
- ① Don’t abandon: a failed turn never ends as if nothing happened. The error is part of the account.
- ② Don’t disguise: an unverified result isn't "done." If you haven't proven it, say you haven't.
- ③ Don’t go dark: for a long task, narrate the transitions. Don’t disappear for twenty steps and show up only at the end.
- ④ Ask for help with the evidence: "I'm stuck here; here's the error and what I've tried so far" is a useful request—not a defeat.
🏁 What “done” really means
Putting the six topics together: a turn is done when the goal has been reached, the change has been verified by a real check, and the result has been reported honestly — including what failed or was skipped. Anything missing one of these three isn’t done.
⚠️ Silence is the worst mistake
Of all the ways to end a turn, only one is unforgivable: staying silent about a failure. Making a mistake and saying so is reliable. Getting stuck and asking for help is reliable. But hide that something went wrong destroys trust all at once—because the damage appears without warning, at the worst possible moment.
- ✗Finish with "done!" when the test was red
- ✗Omit that a critical step was skipped
- ✗End the turn without mentioning the error that appeared along the way
🔬 Hands-on: your deliverable
Close Track 2 by installing verification in your own PMV. In 15 minutes, you'll leave with a real verification clause.
- 1 Take the PMV you built in the previous modules. Name, in one sentence, what the real check of your case — the test/build/task that proves the thing works (not a ls).
- 2 Paste blocks 6 (<recuperacao>) and 11 (confirmation before irreversible actions), and add the faithful reporting rule — say "if it fails, show the output; if you skip it, say so".
- 3 Give the AI a task that goes fail on purpose (ask for something impossible or with a broken detail). Observe: does it diagnose and try again methodically, or repeat blindly? Does it account what failed?
- 4 Adjust the rule until the report is accurate: acknowledge failure with evidence, and claim success only when the check passes. That’s your production prompt, coming out of Track 2.
📝 Module Summary
- ✓A editing is a hypothesis; a check that passes is the evidence — "looks right" doesn't count
- ✓Run the REAL check (the project’s test/build/lint), never a ls/echo; the entire suite if the project calls for it
- ✓Confirm before the irreversible: delete, overwrite, publish, send externally
- ✓Faithful reporting, no hedging: if it failed, say so; if it skipped something, say so; if it passed, state it plainly
- ✓Recover from errors with a method: diagnose → fix → re-verify, never blindly repeat
- ✓Never leave a turn in silence — "done" = goal + real check + honest report
🎓 You finished Track 2
You’ve moved beyond theory and built, run, trimmed, and verified a real prompt. You now have a production-ready MVP and the reflex to prove what you claim. The next track raises the bar: consistent personas, agents with a complete loop, safety by principle, and the collection’s advanced patterns.
➡️ Next Track
🧠 Advanced (Path 3). From ready-made blocks to mastery: persona across four axes, the complete operational loop, priority hierarchy, and principle-based safety—to build the “consistent personal agent” the method aims for.