verify-work

# verify-work Writing a file is not evidence. Running it is. The failure this skill exists to prevent: a turn writes source files and a test file, replies "done, tests included", and never executes a single one of them. The operator finds out later that nothing ran. If you wrote it, run it — and if you cannot run it, say so plainly instead of implying you did. ## The rule **Never report code as working, done, or fixed unless a command you ran in this turn proves it.** Quote the command and the part of its output that carries the verdict — an exit code, a passing count, a rendered element. "Should work" is not a verdict. If verification is impossible here (no runtime installed, needs a device, needs a credential you must not use), say which check you could not run and why, in one sentence. That is an honest result. Silence is not. ## Pick the smallest command that could fail Verify in this order and stop at the first that applies. 1. **The project's own test command.** Read `package.json` / `Makefile` / `pyproject.toml` first — do not guess a runner. `npm test` · `npm run <script>` · `pytest -q` · `cargo test` · `go test ./...` 2. **The file you just wrote.** `node path/to/file.mjs` · `python3 path/to/file.py` · `bash path/to/script.sh` 3. **The entry point, once.** A CLI: `--help` plus one real invocation with real arguments. A server: start it, hit one endpoint, stop it. 4. **A syntax floor**, only when nothing above can run: `node --check file.js` · `python3 -m py_compile file.py` · `tsc --noEmit` Run it from the directory the project expects. Capture stderr, not just stdout — a script that prints nothing and exits 1 has failed. ## Web pages and anything visual A page that loads is not a page that works. Use the browser tools: 1. Open the file or serve it, then `browser.*` to navigate to it. 2. **Read the console.** An uncaught exception on load is a failure even when the page looks fine. Report it and fix it. 3. Screenshot and actually look: is the thing the operator asked for on screen, or is the canvas blank, the layout collapsed, the sprite absent? 4. Exercise one interaction — a click, a key, a submit — and confirm the state changed. For a canvas or game, a blank frame is the usual failure and it is invisible from the source alone. Check a second frame after input, not just the first paint. ## When it fails Fix and re-run, up to **three** attempts on the same defect. Each attempt must change something you can name. If the third fails, stop and report: the command, the error, what you tried, and what you believe is wrong. Three failed attempts on one error means the diagnosis is wrong, and a fourth guess is a worse use of the operator's time than a clear question. Never delete or weaken a test to make a run pass, never comment out the failing assertion, and never lower a check to reach green. If a test is genuinely wrong, say so explicitly and explain why before touching it. ## What to report Two or three lines: - the command you ran, verbatim; - its verdict — exit code, `12 passed`, `no console errors`, the screenshot; - anything you could not verify, named. Do not paste whole logs. Paste the failing lines when it failed.