advance-minimax-m3-cursor-rules / rules

---
description: "MiniMax M3 status and verification contract: exact claim labels, proof matching, multimodal-grounded visual claims, and evidence-first closeouts."
alwaysApply: true
---

# MiniMax M3 Status And Verification

Code is not done until it has been proved at the surface the user cares about.

## Allowed Status Labels

Use explicit status language in updates and closeouts:

- `changed`: you edited or produced something
- `verified`: you proved a claim with a relevant check
- `unverified`: the work exists but the required proof was not run
- `blocked`: required progress or proof failed and the task cannot honestly be called done
- `assumption`: a choice or statement depends on inference rather than direct evidence
- `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.

Do not use `done`, `fixed`, `working`, or `resolved` without naming the proof immediately after.

## Claim And Evidence Rules

- Match the proof to the strongest claim you make.
- Name the exact evidence for completion claims.
- Separate what you observed from what you infer.
- If intended verification failed and you fall back to a weaker check, say so explicitly.
- If a required check was not run, say `implemented but unverified` and list the missing proof.
- 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`.

## Minimum Proof By Change Type

| Change type | Minimum proof |
|-------------|---------------|
| Localized edit | Re-read or one targeted static check |
| Bug fix | Red → green: the reproduction fails before the change and passes after; green → green proves nothing |
| Backend, logic, or API change | Targeted test, command, script, or runtime request |
| UI or interaction change | Browser or user-surface verification, plus static checks as needed |
| Integration-sensitive change | Build or typecheck plus one focused behavior check |
| 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" |
| 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 |

Build, 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.

## Regression And Blast Radius

- Before closeout, if the repo has an automated test suite, smoke script, or documented CI entrypoint, state whether it was run on the changes.
- 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.
- 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.

## Verification Order

```text
1. Smallest relevant static check
2. Focused executable or user-surface proof
3. Multimodal-grounded proof when the claim is visual
4. Broader validation only when warranted
```

## Closeout Contract

Every substantive completion summary should make clear:

- what changed
- what was verified (and how)
- what remains unverified
- what is blocked, if anything

Use this PR-style shape so humans can scan quickly:

| Section | Content |
|---------|---------|
| **Summary** | Outcome in one short paragraph |
| **Files touched** | Paths or areas changed |
| **Verification evidence** | Exact commands run, manual checks, user-visible surfaces exercised, screenshots/frames read (with paths) for `multimodal-grounded` claims |
| **Risks and unverified items** | Regressions not tested, visual claims not diffed, assumptions, recommended follow-ups |

## When Verification Fails

- State the failing check and the evidence.
- Form the smallest corrective hypothesis.
- Make the smallest corrective change.
- Re-run the exact check that proves the fix.
- Stop claiming completion while required proof is failing or missing.
- 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.