Cursor rule

1---
2description: "Extended M3 verification playbook: proof selection, multimodal-grounded checks, shell checks, browser checks, and recovery loops."
3alwaysApply: false
4---
5 
6# M3 Verification Playbook
7 
8Extends 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.
9 
10## Proof Selection
11 
12- Match the proof to the claim being made.
13- Prefer the smallest proof that can honestly support the user-facing claim.
14- Strengthen the proof when the claim involves runtime behavior, interaction, styling, navigation, persistence, or integration.
15- 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.
16- **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.
17- **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.
18 
19## Test Integrity During Verification
20 
21A passing check only counts as proof if the check itself was not bent:
22 
23- 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.
24- 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.
25- Hardcoding the expected output into production code, or branching on test-only inputs, is claim-gaming — treat the work as `blocked`, not `verified`.
26 
27## Shell-Based Checks
28 
29Use the smallest useful command first. Prefer the repo's own scripts and CI entrypoints when they exist (see core **Code Discipline**).
30 
31- JavaScript/TypeScript: `lint`, `typecheck`, `build`, targeted tests, focused scripts
32- Python: `ruff`, targeted `pytest`, import or compile checks
33- Go: `go build`, `go test`, `go vet`
34- Rust: `cargo check`, `cargo test`, `cargo clippy`
35- Flutter: `flutter analyze`, `flutter test`
36- Swift: `swift build`, `swift test`, `xcodebuild` when applicable
37 
38## Browser and Surface Checks
39 
40Use browser verification when the user would experience the change visually or interactively:
41- layout-sensitive UI changes
42- flow or navigation regressions
43- console or network failures
44- styling pipeline issues
45- end-to-end behavior the shell cannot prove
46 
47For 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.
48 
49When browser verification is unavailable, say that clearly and downgrade the claim instead of implying full proof.
50 
51## Self-Review
52 
53For non-trivial work, ask:
54 
55```text
56What would break this?
57What assumptions might be wrong?
58Is there a simpler way?
59Did I solve the actual request?
60Did I re-read the post-change visual state, or am I remembering the pre-change state?
61```
62 
63## When Verification Fails
64 
65Use an evidence-first loop:
66 
67```text
68What failed?
69What is the best current hypothesis?
70What is the smallest corrective change?
71What exact check will prove the fix?
72```
73 
74Do not describe the task as complete while required verification is still failing or missing.
75 
76After 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.
77