Prove it works before calling it done

--- name: prove-it-works-before-calling-it-done description: "Requires real evidence before a software change is reported as finished: build and tests run, the change exercised directly, at least one edge case tried, and results shown. Use when you implement, fix or verify code and can run checks." --- Apply this whenever you are about to say that a code change works, is fixed, or is ready. Reading the code and judging it correct is not verification. Running it is. Steps 1. Find how the project builds and tests itself from its own documentation or scripts. 2. Run the build, the relevant tests, and any configured linters or type checks. A failing build or test means the change is not done. 3. Exercise the change directly, in the way that fits it: - User interface: open the page, click the controls, submit the forms, reload and check state persists. - Service or API: call the endpoints with valid and invalid input; check status codes and response bodies. - Command-line tool: run it with normal, empty and very large input; check output and exit codes. - Data pipeline: run a small sample; check row counts, types, value ranges, empty and missing values. - Database migration: apply it, inspect the result, roll it back. - Bug fix: reproduce the bug first, then confirm it is gone and nearby behavior still works. 4. Try at least one adversarial check: boundary values, the same request twice, a record that does not exist, or two requests at once. 5. Do not change the project just to make a check pass while verifying. If you find a problem, report it, then fix it as a separate step. Watch for excuses: 'it looks right', 'the existing tests pass', 'this would take too long'. Tests written alongside the change may only cover the happy path; check independently. Report format For each check: what you verified, the exact command or action, the relevant output (quoted, not paraphrased), and pass or fail with expected versus actual. End with one overall result: pass, fail, or partial. Use partial only when the environment prevented a check, and name which one. If you could not run anything, say so plainly and list the checks the person should run.

Check: signup rejects a duplicate email address Action: sent the same signup request twice to the local server Output: first response 201 Created; second response 409 Conflict with message 'An account with this address already exists' Result: pass Check: password field enforces 12 characters minimum Action: submitted an 11-character password through the form Output: form accepted it and created the account Result: fail - expected a validation error; the check exists in the API but the form bypasses it by calling the older endpoint Check: build and unit tests Action: ran the project's test command Output: 214 passed, 0 failed Result: pass Overall: fail. The minimum-length rule is not enforced through the signup form.