uverify

Negative:

• CK3 — POST /items: try {name: ""}, {name: null}, {name: " "}, missing field entirely — find one that doesn't 400
• CK4 — Dataset.load: try missing file, directory, symlink to /dev/null, file with no read perms — find one that doesn't raise cleanly

Invariants / assumptions:

• CK5 (IV1) — grep "from training" src/dataset/ and re-export chains — try to find a smuggled import
• CK6 (IV2) — find a DB write that bypasses transaction() (raw cursor, ORM escape hatch)
• CK7 (AS1) — sample upstream /users — find a non-UTF-8 email in the wild

Interfaces:

• CK8 (IF1) — grep Parser.parse callers — find one passing non-str
• CK9 (IF2) — invoke Formatter.render with malformed AST — find a return that violates -> str

</good-example>

<bad-example>
"I'll test the happy path." Confirmation, not attack. No hypothesis of how it breaks.
</bad-example>

## Phase 2 — Run each attack freshly, in this message

Evidence before claims. If you haven't run the attack in this message, you cannot claim "no break demonstrated."

- Use `/up:try`-style minimal probes — the direct command, no harness
- One-off scripts go in project-local `tmp/` (gitignored); clean up after
- Capture *actual* output. "Looks right" is not evidence; a stack trace is.
- Decide on what you saw, not what you expected. A passed attack (you tried hard and couldn't break it) is a real outcome; so is a landed attack (you broke it — record the repro).

If an attack failed to land in an earlier session — re-run it. State drifts; what couldn't be broken yesterday may break today.

## Phase 3 — Smoke the end-to-end (lowest-bar attack)

The smoke is the most basic attack hypothesis: the change is broken enough that it doesn't even run end-to-end in its real shape.

Run the shortest full path:

- CLI change → invoke the command with representative input
- API change → `curl` against a running server
- UI change → open in a browser, click through the feature
- ML change → run a tiny training step or inference call

If smoke fails, that's a demonstrated break — record it. If smoke passes, the change clears the lowest bar; the per-attack hypotheses still need to land or fail to land on their own.

If you can't run the smoke (infra unavailable), say so explicitly. Do not fabricate success. Do not substitute a unit test for the smoke.

If the smoke only exercises a proxy for the Goal — a small or local stand-in for a full-scale or real-world run (converting 10 files when the Goal is 700GB on a pod) — say so: name what the proxy covered and what real-world validation still stands between here and the Goal. That gap is what `/up:make` step 11 hands to the user.

## Phase 4 — Write the Verify summary to the task file

<required>
Append (or replace) the `## Verify` section of `docs/tasks/<slug>.md`. Keep it short — this is not a transcript, it's an audit trail of what was attacked.

Per-CK verdict vocabulary:
- `held` — attack ran, no break demonstrated.
- `broke` — attack landed; evidence required (one line, real output).
- `deferred` — attack couldn't be run (infra, scope); name what blocks it.

Overall `Result:` is `passed` only if every CK is `held` (or justifiably `deferred` with user-visible deferral). Any `broke` → `failed`.

Format:

```markdown
## Verify

**Result:** passed | failed

Happy-path:
- CK1 — <attack hypothesis> — held
- CK2 — <attack hypothesis> — broke: <evidence>

Negative:
- CK3 — <attack hypothesis> — held

Invariants / assumptions:
- CK4 (IV1) — <attack hypothesis> — held: <how attacked>
- CK5 (AS1) — <attack hypothesis> — deferred: <what blocks>

Interfaces:
- CK6 (IF1) — <attack hypothesis> — held
- CK7 (IF2) — <attack hypothesis> — broke: <evidence>

Smoke: `<command>` → <one-line result>   (omit if not run; never substitute a non-smoke)

Goal: proxy only — <what the smoke covered, what real-world validation remains>   (omit when the smoke exercised the full Goal)

Notes: <break repros, deferrals, re-runs>   (omit if none)

Write this whether verify passed or failed. On failure, Notes names the demonstrated break(s) and points to where execute should pick up.

</good-example>

<good-example>
Failing form (a break landed):
```markdown
## Verify

**Result:** failed

Negative:
- CK3 — null name on POST /items — broke: `{"name": null}` → 500 (TypeError in handler), not 400

Notes: validation layer doesn't reject `null` before the handler; should reject with 400 "name is required". Loop back to execute.

Phase 5 — Consolidate: held loops to review, broke loops to execute

• Every attack held (or justifiably deferred) → declare verify passed. Invoke up:ureview.
• Any attack broke → for each, describe how it should have worked conceptually (not "add the missing line" — the behavior it was supposed to exhibit under the attack). Loop back to up:uexecute with these notes. Do not move forward.

Future Work vs. incomplete work — the slacking-loophole rule

When a check fails or surfaces ambiguity, do not move it to ## Conclusion → Future Work unless you have justification.

Red flags — STOP, do not claim pass

If any of these was the basis of a pass verdict: back to Phase 1.

Never

• Claim a CK held without running the attack in this message
• Declare pass when any attack broke
• Build the attack list as restatements of the happy path (no adversarial angle = not an attack)
• Skip verify to get to review faster
• Trust a prior session's verdict — re-run

Hands-off mode

See up:handsoff for the full contract. Stage-specific delta: verify's behavior is unchanged — the pass → review / fail → execute loop already runs without user confirmation. Infeasible smoke tests (infra unavailable, etc.) are logged under ### Deferred (needs user input) so the user knows what wasn't verified end-to-end. Never fabricate success to skip a deferred entry.

Terminal state

Verify summary written to task file. Pass → invoke up:ureview. Fail → invoke up:uexecute with failure notes describing intended behavior.