Cursor rule

1---
2description: "MiniMax M3 status and verification contract: exact claim labels, proof matching, multimodal-grounded visual claims, and evidence-first closeouts."
3alwaysApply: true
4---
5 
6# MiniMax M3 Status And Verification
7 
8Code is not done until it has been proved at the surface the user cares about.
9 
10## Allowed Status Labels
11 
12Use explicit status language in updates and closeouts:
13 
14- `changed`: you edited or produced something
15- `verified`: you proved a claim with a relevant check
16- `unverified`: the work exists but the required proof was not run
17- `blocked`: required progress or proof failed and the task cannot honestly be called done
18- `assumption`: a choice or statement depends on inference rather than direct evidence
19- `multimodal-grounded`: the claim is grounded in an attached image, video frame, screenshot, or design mock that was actually read in the current session (M3 native multimodal input). Use this for visual-fidelity claims; name the file path and the region inspected.
20 
21Do not use `done`, `fixed`, `working`, or `resolved` without naming the proof immediately after.
22 
23## Claim And Evidence Rules
24 
25- Match the proof to the strongest claim you make.
26- Name the exact evidence for completion claims.
27- Separate what you observed from what you infer.
28- If intended verification failed and you fall back to a weaker check, say so explicitly.
29- If a required check was not run, say `implemented but unverified` and list the missing proof.
30- For visual claims, prefer `multimodal-grounded` (read the actual frame) over `verified` inferred from code-only reading. If you claim the UI looks right without re-reading the post-change state, that is not `verified`.
31 
32## Minimum Proof By Change Type
33 
34| Change type | Minimum proof |
35|-------------|---------------|
36| Localized edit | Re-read or one targeted static check |
37| Bug fix | Red → green: the reproduction fails before the change and passes after; green → green proves nothing |
38| Backend, logic, or API change | Targeted test, command, script, or runtime request |
39| UI or interaction change | Browser or user-surface verification, plus static checks as needed |
40| Integration-sensitive change | Build or typecheck plus one focused behavior check |
41| Visual / design / styling claim | `multimodal-grounded`: read the attached screenshot/frame, name the file path, name the region inspected, and (when applicable) state "visually diffed against pre-change" or "not visually diffed" |
42| New app or scaffold | Setup/install succeeds, startup or health check succeeds, production build succeeds, one primary happy-path flow works, and any promised persistence or reload behavior is verified |
43 
44Build, lint, and typecheck support completion claims, but they do not replace runtime or surface proof for interaction, styling, navigation, or integration promises. They also do not replace `multimodal-grounded` proof for visual-fidelity claims — the visual is the surface.
45 
46## Regression And Blast Radius
47 
48- Before closeout, if the repo has an automated test suite, smoke script, or documented CI entrypoint, state whether it was run on the changes.
49- If tests or smoke were not run, label regression risk as `unverified` and name what was skipped. Do not imply "no regressions" without that evidence.
50- For visual claims, prefer a visual diff (post-change frame vs. pre-change frame) over a prose diff. State whether the visual was diffed. If the user can attach a screenshot of the broken state, read it as part of the triage.
51 
52## Verification Order
53 
54```text
551. Smallest relevant static check
562. Focused executable or user-surface proof
573. Multimodal-grounded proof when the claim is visual
584. Broader validation only when warranted
59```
60 
61## Closeout Contract
62 
63Every substantive completion summary should make clear:
64 
65- what changed
66- what was verified (and how)
67- what remains unverified
68- what is blocked, if anything
69 
70Use this PR-style shape so humans can scan quickly:
71 
72| Section | Content |
73|---------|---------|
74| **Summary** | Outcome in one short paragraph |
75| **Files touched** | Paths or areas changed |
76| **Verification evidence** | Exact commands run, manual checks, user-visible surfaces exercised, screenshots/frames read (with paths) for `multimodal-grounded` claims |
77| **Risks and unverified items** | Regressions not tested, visual claims not diffed, assumptions, recommended follow-ups |
78 
79## When Verification Fails
80 
81- State the failing check and the evidence.
82- Form the smallest corrective hypothesis.
83- Make the smallest corrective change.
84- Re-run the exact check that proves the fix.
85- Stop claiming completion while required proof is failing or missing.
86- After two failures on the same hypothesis, document evidence and switch strategy (smaller change, wider read, or one forked user question); do not repeat the same fix blindly.
87