← All kits

Available to paid subscribers

Proof of Done

Kit files are in English.

Check what your agent actually finished and get a receipt showing what passed, failed or could not be checked.

Python 3.9+. macOS tested; Linux expected. Bring your existing command and acceptance checks.

  • Catch a stale-data false success in an offline demo.
  • Connect your first real job with a one-file contract builder.
  • Share a receipt with observations, run identity and the next action.

Local Python kit | ZIP, guide and reports in English | Offline demo

View sample receipt

Available now to paid subscribers. One-off purchase opens later.

I'm a subscriber: claim it

Coming soon: one-off purchase.

Yearly: every kit included. Monthly: one new kit per billing cycle.

Proof of Done: Sample receipt: passed, failed and unknown checks. The run is rejected.View full-size sample ↗
Sample receipt: passed, failed and unknown checks. The run is rejected.
Access, downloads and refund policy

Yearly: every available kit and bundle, unlimited downloads.

Monthly: one new standalone kit per billing cycle, no bundles. Re-downloads are free and do not use a new claim.

Monthly subscriptions started before February 28, 2026 keep all-access, including bundles and unlimited downloads.

Monthly access currently allows three downloads per kit. Need another? Contact joozio@hey.com.

Download access while subscribed. Keep the files you download.

Limits

You define the acceptance checks.

  • This is not a sandbox: checks run with your permissions.
  • It cannot prove an email was delivered.

Tested on macOS with Python 3.9.6 and 3.14.3. Linux is expected to work, but is not claimed as tested. On Windows a timeout kills the direct child, not the whole process group.

Inside the kit

  • Run: command wrapper, checks and receipt watcher
  • Examples: three incidents, broken and repaired runs
  • Guide: acceptance contracts and independent review
How it works

Your agent says the task finished. This gives you a receipt showing whether the expected result actually exists. Wrap the unattended command you already run and it checks the outcome against a contract you wrote before the run: the file is this run's file and not yesterday's, the URL is serving the build this run produced, the change the summary described is really in the diff. Three check families, a fresh run id the job stamps into its own output, and one wrapped run that writes JSON, a standalone HTML receipt and a log. A job that exits non-zero is never accepted whatever the evidence says, evidence it could not read comes back as unknown, and unknown is never a pass. Ships with three incident projects (stale data, a deploy serving the previous build, a code change that never landed), each with a broken run, a repaired run and both receipts, a watcher for the run that never started, and the read-only second-model review pass for work no contract can specify in advance. Standard library Python, no telemetry and no account: the demos run with the network off, and the only requests it makes are the HTTP checks your own contract names.

Built after a second-model audit found 18 problems in one night of agent work that reported success, then handed back for four cold-unzip audit passes of the kit itself, five reports in all, by models that did not build it: 12 blockers in the first pass, 9 in the second, 3 in the third, 1 in the fourth. Every false-pass route those reports reproduced is closed and ships as a test you can run, 97 tests as of September 11, 2026. The reports are the author's, not an independent endorsement, and no audit can show there is nothing left to find.

Latest update: 2026-09-13

v1.0.5 (2026-09-13). Buyer experience: mobile receipts, demo-first instructions, an offline guide and a one-file contract builder.

How the checks work: detail and full file inventory

Best for

  • +Anyone with a scheduled or overnight Claude Code, Codex or plain shell job, the morning after a "done" that was not
  • +People who deploy from an agent run and want to know the URL is serving tonight's build, not last night's
  • +Agencies and freelancers who need to show a client what was checked, not just say it was

Not for

  • -Sandboxing or containment: this is acceptance evidence, not a security boundary, and checks run as your user
  • -Deciding who wrote a file: no check can know that. What the kit does instead is refuse to accept a green that rests on nothing but the job's own status word, and ask you for one condition the job cannot simply assert
  • -Proving an email or a message was delivered: there is no outbound check in v1, on purpose
  • -Anyone wanting a one-click tool that decides what "done" means for you. You write the contract; the kit runs it

What you get

+Wraps your existing command: a fresh run id exported to the job, the pre-run git revision and contract hash recorded, full log, process-group timeout, JSON and HTML receipts written
+Three check families: artifact (a file exists, is readable, is fresh by modification time, has the right shape, and carries this run id, which is the condition that actually binds a file to a run: a timestamp can be touched, and one from the future is reported as unknown rather than fresh), http_json (the URL is serving this run's build id), git_tree (the named change is on an added line inside the paths you named)
+Three verdicts and three exit codes: 0 accepted, 1 rejected, 2 evidence unknown. Unknown never reaches accepted and there is no flag to change that. A job that exits non-zero is never accepted either, whatever the evidence says, and every receipt names the observation that decided its verdict
+Every run id is minted fresh (timestamp plus random) and claimed in one ledger for the whole machine, under a lock: an id used before is a failure rather than a warning, two runs started at the same instant cannot share one, and a ledger with a damaged record is a failure too. Supply your own id and it has to come from one alphabet (letters, digits, hyphen, underscore, dot), refused with a sentence otherwise, because that is the alphabet the file matcher reads a token by, so a later no-op cannot pass on yesterday's file by prefix or suffix. A short id such as a bare build number can still appear in a file by coincidence, so let the kit mint the id or prefix yours with the job name
+The contract is read, hashed and parsed once before your command starts, and those bytes are the ones executed: the hash on a receipt always names the checks that actually ran, so a job cannot be judged on a contract it shrank. The file is re-read after the checks, and a contract whose bytes differ at that second reading is a failure; the receipt reports that two point comparison rather than surveillance of the file
+A receipt is only issued for a contract that ran in full: every check is listed by id, the executed count has to equal the contract's, and a partial run is unknown and exit 2 rather than a pass over the part that finished
+Standalone HTML receipts: no scripts, no fonts, no network, safe to email or hand to a client
+Eleven Python modules, each with --help and an offline --self-test you can run before you trust it, plus three incident demos that assert their own documented exit codes
+97 tests you run yourself, under plain python3 or pytest, no third-party packages, most of them negative: every way four audit passes found to make this verifier say PASS on a failure, each shipped as the reproduction that found it (count as of September 11, 2026)
+A watcher for the run that never started, because a wrapper cannot write a receipt for a job the scheduler never fired
+The read-only second-model review pass, with an exact launch command, a JSON verdict schema, triage rules and a dispute log, for work no contract can specify in advance

Package includes

  • •START-HERE.html: the five-minute install, what to run first, and what a passing and a failing receipt look like side by side
  • •bin/run-and-verify.py: wraps an unattended command and judges it on evidence
  • •bin/verify.py: contract in, receipt out, for jobs you cannot wrap
  • •bin/render-receipt.py: receipt JSON to a standalone HTML page (--demo renders a sample)
  • •bin/watch-receipts.py: watch a receipt directory from a second schedule and catch the run that never started
  • •checks/artifact.py, checks/http_json.py, checks/git_tree.py: the three families, each self-contained with its own --self-test
  • •contracts/: first-job to start from (one check, nothing else needed beside it), then daily-data, static-build and repo-change, plus a mini schema for generated reports
  • •guide/: five chapters, from writing an observable contract to the honest limits
  • •examples/01-stale-data, 02-old-build-deployed, 03-missing-code-change: three incidents, each with a broken run, a repaired run, a contract and a demo.sh that checks the exit codes match its README
  • •templates/: acceptance brief, independent reviewer brief, dispute log, receipt HTML template
  • •tests/: test_false_completion.py, test_receipt_freshness.py, test_run_identity.py, test_unknown_is_not_pass.py, 97 tests in total as of September 11, 2026
  • •MANIFEST.txt, CHANGELOG.md, LICENSE.txt

FAQ

What does this kit not do?

It is acceptance evidence, not a sandbox: checks run as your user, and a process with write access can edit a receipt after the fact. The contract guarantee is a comparison at two points, before the job and after the checks, not surveillance of the file. If your scheduler supplies the run id, make it distinctive: the run id check looks for that id as a whole token in your artifact, so a bare build number like 42 can appear in a file by coincidence and certify a run that did nothing. Let the kit mint the id, or prefix yours with the job name. And a check that asks a file only to agree that its writer succeeded is answered with unknown on purpose, so give every contract one condition the job cannot simply assert.

What do I have to install?

Nothing. Python 3.9 or newer, standard library only. Unzip it, cd in, and run python3 checks/artifact.py --self-test. git is needed for the git checks; without it those checks return unknown rather than crashing. Tested on macOS under Python 3.9.6 and 3.14.3; Linux is expected to work but is not claimed as tested, and on Windows the timeout kills the direct child rather than the whole process group.

Does it work with agents other than Claude Code?

Yes. The runner does not care what the command is: claude -p, codex exec, a shell script, a Makefile target, a CI step. It checks the tree and the URLs afterwards, not the agent transcript.

Does anything leave my machine?

There is no telemetry, no account and no external service, and the three incident demos run with the network off. The exception is the feature: an http_json check fetches the URL you put in your own contract, because that is the only way to see what a server is actually serving. Your wrapped command, of course, does whatever it already does.

How is this different from just checking the exit code, or from running tests?

An exit code of 0 is the command reporting success, which is the thing being judged speaking about itself. Tests say the code behaves. Neither says the artifact on disk is this run's artifact, or that the URL is serving the build you made, or that the change the summary described is in the diff. The three incident projects are exactly those three gaps, each with a run that exits 0 and gets rejected anyway.

Can my agent not just satisfy the checks?

You define the checks, and a process with your permissions can still alter files or receipts.

Technical detail

A process running as your user can edit the checks or the receipts, and this is acceptance evidence rather than a sandbox. Two things are enforced rather than recorded. The contract is read, hashed and parsed once before your command runs, so the receipt names the checks that were executed and a job cannot get judged on a shrunken contract and restore the approved bytes afterwards. And a run id is claimed once per machine under a lock, so the same id cannot certify two runs. The rest is a record. The pinned flag compares the contract path against the workdir you configured, which is not the same as outside everything your user can write, and the guide says so in those words.

What happens when the check itself cannot run?

It returns unknown, which is never accepted. Incident 02 demonstrates it: the same good deploy passes with the server up and returns unknown with the server down. Evidence that exists but cannot be read is unknown too, including evidence a contract marked optional: a directory you cannot enter hides a real error log exactly as well as it hides a missing one. A verifier that treats "I could not look" as "fine" is loudest with reassurance on the worst night.

You might also like:

🩺$29

Agent Architecture Audit Kit

🍳$39

Claude API Cookbook: 12 Production Recipes

📘$39

Claude Code Workshop: Mastery Guide

Back to kit overview ↑