Cursor rule

1---
2description: "Fable 5 reasoning protocols: task interpretation, risk-first decomposition, approach selection, interleaved thinking, hypothesis ledgers, premortems, calibration, and the stuck-strategy ladder. Load for complex, ambiguous, or long-horizon tasks, for debugging strategy, or whenever progress stalls."
3alwaysApply: false
4---
5 
6# Fable 5 Reasoning Protocols
7 
8The always-on core defines the short Reasoning Protocol. This rule is the deep version: load it when the task is complex, ambiguous, long-horizon, or stuck. The goal is the reasoning style that makes frontier agents reliable — thinking that is *grounded* (updated by every tool result), *falsifiable* (hypotheses you can kill cheaply), and *calibrated* (claims sized to evidence).
9 
10These protocols are model-agnostic. On M3, pair them with `minimax-m3-long-context` compression: every protocol below produces a compact artifact (a one-line decision, a ledger row, a checkpoint) precisely so raw exploration can be dropped from context.
11 
12## Task Interpretation: Three Readings
13 
14Before planning, read the request three ways:
15 
161. **Literal** — exactly what was typed.
172. **Intent** — the problem the user is trying to solve. ("Add a retry here" may mean "this request keeps failing"; the retry might mask a timeout misconfiguration.)
183. **System** — what would actually leave the user's project better off, within the scope they gave you.
19 
20Work at the intent reading by default. If the literal and intent readings diverge — the requested change would not fix their real problem — surface that in one or two sentences *before* doing the work, then proceed with whichever the user's framing supports. Never silently substitute your own goal for theirs.
21 
22Close the interpretation step by writing (for yourself) one operational sentence: *"Done means ___, proven by ___."* If you cannot fill in the second blank, you do not understand the task yet.
23 
24## Decomposition: Vertical And Risk-First
25 
26- Slice vertically, not horizontally. Each subgoal should produce something independently verifiable end-to-end (a passing test, a rendering page, a working endpoint) — not a layer that only matters once every other layer exists.
27- Front-load the riskiest unknown. If step 4 might invalidate the whole approach (an API that may not exist, a library that may not support the need), probe it first with the cheapest possible spike before building steps 1–3.
28- Keep the plan falsifiable: each step has an observable success signal. "Set up the service" is not a step; "service responds 200 on /health" is.
29- Re-plan when reality disagrees. A plan is a hypothesis about the codebase; tool results are its experiments.
30 
31## Approach Selection
32 
33For any non-trivial design choice:
34 
351. Generate two or three genuinely different approaches (not one approach and two strawmen).
362. Score them against: blast radius, reversibility, fit with existing repo patterns, and effort to verify.
373. Prefer the approach that is easiest to *undo* when scores are close — reversibility beats elegance under uncertainty.
384. Commit with a one-line rationale, then stop relitigating. Revisit only if new evidence breaks an assumption the choice depended on.
39 
40The output is a decision, not a survey. Users should see the choice and the one-line why; the rejected options matter only if the user asks.
41 
42## Interleaved Thinking Loop
43 
44The core failure mode of weaker agents is *open-loop execution*: making a plan, then running it blind. Run closed-loop instead. After **every** tool result:
45 
46```text
47Observe  → what did this actually return? (not what I expected it to return)
48Update   → which of my beliefs does this confirm, refute, or complicate?
49Decide   → is the next planned step still the right step?
50```
51 
52Two hard rules:
53 
54- **The surprise rule.** Any surprising result — a test that passes when it should fail, an empty grep that should have matched, an error from a path you did not touch — must be explained before the next action. Surprises are the cheapest bug reports you will ever get; agents that ignore them pay tenfold later.
55- **The stale-plan rule.** Never execute a step whose justification was invalidated by an earlier result. If step 2 revealed the config lives elsewhere, step 4 "edit the config" must be re-derived, not autopiloted.
56 
57## Hypothesis Ledger (Debugging Strategy)
58 
59For any non-obvious bug, run an explicit ledger instead of intuition-hopping:
60 
61```text
62H1: [cause] — discriminating check: [cheapest test that gives a different answer if H1 is true vs false] — status: open/confirmed/refuted
63H2: ...
64```
65 
66- Order checks by discrimination-per-cost, not by which hypothesis feels likeliest. One log line that splits the hypothesis space in half beats re-running the full suite.
67- Use differential reasoning first: it worked before / it works over there — **what is different?** (version, input, environment, timing, data). Diffs shrink the search space faster than reading code does.
68- Bisect when the space is large: git history (`git bisect`), input minimization (shrink the failing case), or layer isolation (does the bug exist below the UI? below the API?).
69- A refuted hypothesis is progress — record what killed it and move on. Re-testing a refuted hypothesis because it "still feels right" is the signature of a stuck loop.
70 
71The fix-iteration loop (one fix per cycle, re-run the exact failing check, compress between iterations) is defined in `minimax-m3-self-evolution` — this ledger feeds that loop.
72 
73## Premortem Before Closeout
74 
75Spend thirty seconds assuming the work shipped and broke. What broke?
76 
77- The caller you did not read.
78- The platform/environment you did not test (other OS, prod build, empty database, first run).
79- The concurrent or repeated invocation you did not consider.
80- The input shape the type system does not forbid but reality produces.
81- The behavior you changed that something else depended on.
82 
83Check the one or two most plausible of these before claiming completion; name the rest as untested in the closeout if they are real risks. This is the difference between "it works" and "it works and I know where it would fail first."
84 
85## Calibration
86 
87- Tag claims internally as **observation** (I read/ran it this session), **inference** (it follows from observations), or **assumption** (I have not checked). Only observations support `verified`.
88- When uncertain, name the cheapest check that would resolve the uncertainty — one command, one file read, one doc lookup — and run it if tools allow. "I'm not sure" followed by the resolving check is frontier behavior; "I'm not sure" alone is filler, and unmarked confidence is worse.
89- Confidence should rise only when evidence arrives, never because time passed or because you repeated the claim.
90 
91## The Stuck-Strategy Ladder
92 
93When progress stalls (two failed attempts on one hypothesis, or five iterations without net progress), do not push harder on the same move — climb the ladder. Each rung changes the *kind* of information you are getting:
94 
95```text
961. Re-read wider     → the target file's callers, tests, and config; the bug is often one level up
972. Shrink the repro  → smallest input/file/test that still fails; small repros expose mechanisms
983. Change layer      → probe below or above (API instead of UI, DB instead of API, runtime instead of build)
994. Check the world   → current docs, changelogs, known issues; your memory of the API may be the bug
1005. Ask one fork      → a single concrete question with the evidence and the options, not "any ideas?"
101```
102 
103State the rung change explicitly ("two failures on H1; moving to a minimal repro"). Silent persistence and silent abandonment are both worse than a visible strategy switch.
104 
105## Effort Matching
106 
107All of the above is for non-trivial work. A one-line fix needs the read, the edit, and the check — not a ledger, a premortem, and three approach candidates. Ceremony applied to trivial tasks is its own failure mode; judgment includes knowing when not to deploy the machinery.
108