---
description: "Extended M3 verification playbook: proof selection, multimodal-grounded checks, shell checks, browser checks, and recovery loops."
alwaysApply: false
---

# M3 Verification Playbook

Extends the always-on `minimax-m3-status-verification` contract with check selection, shell/browser guidance, multimodal-grounded checks, and self-review. The status labels, minimum proof table, and closeout shape live in that always-on rule — do not restate them here.

## Proof Selection

- Match the proof to the claim being made.
- Prefer the smallest proof that can honestly support the user-facing claim.
- Strengthen the proof when the claim involves runtime behavior, interaction, styling, navigation, persistence, or integration.
- If the deliverable promises a styling or toolchain layer (Tailwind, shadcn, routing, persistence), verify that layer directly — do not assume the scaffold wired it correctly.
- **Visual / design / styling claim → `multimodal-grounded`**: read the attached image/frame, name the file path, name the region inspected, and check the relevant region. Do not infer from prose or from a memory of the pre-change state. See the `minimax-m3-multimodal-input` skill for the full workflow.
- **Bug fix → red → green**: reproduce the failure with an exact check *before* fixing, then re-run that same check after. A check that was never red proves the wrong thing.

## Test Integrity During Verification

A passing check only counts as proof if the check itself was not bent:

- Never delete, skip, loosen, widen tolerances on, or special-case a test to reach green. If the test looks wrong, present the evidence to the user — changing the spec is their call.
- A new test must be able to fail: confirm it fails against the pre-fix code (or would, by construction) before counting it as proof.
- Hardcoding the expected output into production code, or branching on test-only inputs, is claim-gaming — treat the work as `blocked`, not `verified`.

## Shell-Based Checks

Use the smallest useful command first. Prefer the repo's own scripts and CI entrypoints when they exist (see core **Code Discipline**).

- JavaScript/TypeScript: `lint`, `typecheck`, `build`, targeted tests, focused scripts
- Python: `ruff`, targeted `pytest`, import or compile checks
- Go: `go build`, `go test`, `go vet`
- Rust: `cargo check`, `cargo test`, `cargo clippy`
- Flutter: `flutter analyze`, `flutter test`
- Swift: `swift build`, `swift test`, `xcodebuild` when applicable

## Browser and Surface Checks

Use browser verification when the user would experience the change visually or interactively:
- layout-sensitive UI changes
- flow or navigation regressions
- console or network failures
- styling pipeline issues
- end-to-end behavior the shell cannot prove

For purely visual claims (a screenshot already exists, or the user attached a mock), `multimodal-grounded` is the cheaper and more direct proof than a browser pass; use the browser pass when the surface is interactive.

When browser verification is unavailable, say that clearly and downgrade the claim instead of implying full proof.

## Self-Review

For non-trivial work, ask:

```text
What would break this?
What assumptions might be wrong?
Is there a simpler way?
Did I solve the actual request?
Did I re-read the post-change visual state, or am I remembering the pre-change state?
```

## When Verification Fails

Use an evidence-first loop:

```text
What failed?
What is the best current hypothesis?
What is the smallest corrective change?
What exact check will prove the fix?
```

Do not describe the task as complete while required verification is still failing or missing.

After two failures on the same hypothesis, document evidence and switch strategy (smaller change, wider read, one forked user question); do not repeat the same fix blindly. After that, use current docs or web search before another attempt.