verifyfirst

Call this immediately before reporting a task complete — before writing 'done', 'fixed', 'deployed', 'working' or 'the tests pass'. Describe what you just did ('deployed a static site', 'restarted the service', 'changed a config file', 'ran the test suite', 'fetched a URL', 'published a package') and it returns an ordered preflight: the specific checks that would catch this task failing silently, each with the command to run and the recorded failure it guards against. Unlike from_symptom, nothing has to have gone wrong yet — this is for the moment when you believe the work succeeded.

PRE-FLIGHT CHECK. Call this in the moment before you claim a task is done or a fix is verified. Give it the instrument you are trusting — a screenshot, an exit code, an HTTP status, a file you read, a process list, a log — and it returns the terse list of failure modes that instrument is structurally incapable of showing you. A screenshot cannot see time. An exit code cannot see semantics. A 200 cannot see staleness. A config file cannot see what the running process loaded. Reading this list takes seconds and is the difference between 'the command exited zero' and 'the change is live'. Accepts loose names: 'curl', 'ps', 'journalctl', 'I looked at the screenshot' all resolve. Use get_instrument afterwards for the worked examples.

Start here when something is wrong but you do not yet know why. Describe what you are actually observing, in your own words — 'the page is blank', 'deploy ran but nothing changed', 'API returns 200 but the data is wrong', 'the service says active but is not serving', 'the command hangs and never returns' — and this returns the recorded failures that produce that exact appearance, each with the one check that tells them apart. This is the symptom-first door into the registry; blind_spots is the instrument-first one. Use this when you have a symptom, and blind_spots when you are about to verify something and want to know what your method cannot see.

Retrieve one recorded failure in full by its id, e.g. 'NS-001'. Returns the false reading, the true state, why the instrument could not separate them, the discriminating check, the cost of missing it, and what it generalises to. Use after search or get_instrument surfaces an id you want the complete account of.

Full dossier on one instrument: what it genuinely captures, everything it is blind to, and every recorded real-world failure it missed — each with the false reading, the true state, and one concrete check that separates them. Use this after blind_spots when a listed blind spot might apply to what you are doing and you want the specific command or expression that would settle it. Every failure here was actually observed and diagnosed; none are hypothetical.

The five-step verification checklist to run before reporting any work as complete: name the instrument, say what it cannot see, run one check that could actually come out either way, report the observation rather than the inference, and prefer resolved values over authored ones. Returns the checklist plus the underlying principles. Call it once at the start of a verification pass, or any time you are about to write the words 'done', 'fixed', 'working', or 'deployed'.

List the six verification instruments an agent can observe a system through: screenshot, exit-code, http-response, file-on-disk, process-list, log-output. Each entry says what the instrument is used for so you can identify which one you are actually relying on right now. Start here when you are not sure how to name the instrument you just used, then call blind_spots on it.

Case-insensitive substring search across every recorded failure's title, false reading, true state, and failure class. Use it when you have a symptom rather than an instrument: 'blank page', 'cache', 'font', 'hang', 'oom', 'systemctl', 'opacity', 'no output'. Also useful for checking whether a surprising behaviour you just hit is a known instrument artifact before you spend rounds tuning against it.