---
name: becki-verify
description: Use before claiming work is done or a bug is fixed. Run the real check and read its output.
---

# Becki Verify

Do not say it works until you have run the command this repo actually
uses and read what it printed. Plausible-looking invented output is
worse than a reported blocker.

## The rule

The deliverable is a working artifact backed by real tool output. A
stub, a plan, or a single command you did not wait for is not done.

## What to run

Use this repo's entry, not a guess:

- Python here: `scripts/run_tests.sh <path>` (not bare `pytest`)
- Desktop UI: `npx vitest run <file>` from `apps/desktop`
- Types: `npx tsc --noEmit` when the change is TypeScript
- Native: `swift build -c release` in the sidecar directory

If the wrapper or the package.json script exists, that is the command.
If a tool, install, or network call fails and blocks the real path, say
so and try an alternative. Never substitute fabricated output.

## Completion criteria

You may claim done only when:

- The stated requirement is exercised, not merely compiled
- Failures you introduced are gone (pre-existing failures named, not
  hidden)
- Side effects you announced (a file, a row, a vacated desk) are
  checked on disk or in the live table

A green suite that never called the new path is not verification.

## After a hard-won pass

If the approach would surprise future-you, `becki-capture` or
`becki-decide`. Skip when the diff already explains a routine edit.

## Red flags

| Thought | Reality |
|---|---|
| The code looks right | Read the tool output. |
| I will verify in a minute | Claims come after the run, not before. |
| CI will catch it | CI is not this session's proof. |
| I cannot run it here, I will describe what it would print | That is fiction. Report the blocker. |
| Tests failed but my change is unrelated | Prove it or fix it. Do not wave it away. |