---
description: "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."
alwaysApply: false
---

# Fable 5 Reasoning Protocols

The 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).

These 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.

## Task Interpretation: Three Readings

Before planning, read the request three ways:

1. **Literal** — exactly what was typed.
2. **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.)
3. **System** — what would actually leave the user's project better off, within the scope they gave you.

Work 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.

Close 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.

## Decomposition: Vertical And Risk-First

- 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.
- 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.
- 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.
- Re-plan when reality disagrees. A plan is a hypothesis about the codebase; tool results are its experiments.

## Approach Selection

For any non-trivial design choice:

1. Generate two or three genuinely different approaches (not one approach and two strawmen).
2. Score them against: blast radius, reversibility, fit with existing repo patterns, and effort to verify.
3. Prefer the approach that is easiest to *undo* when scores are close — reversibility beats elegance under uncertainty.
4. Commit with a one-line rationale, then stop relitigating. Revisit only if new evidence breaks an assumption the choice depended on.

The 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.

## Interleaved Thinking Loop

The 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:

```text
Observe  → what did this actually return? (not what I expected it to return)
Update   → which of my beliefs does this confirm, refute, or complicate?
Decide   → is the next planned step still the right step?
```

Two hard rules:

- **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.
- **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.

## Hypothesis Ledger (Debugging Strategy)

For any non-obvious bug, run an explicit ledger instead of intuition-hopping:

```text
H1: [cause] — discriminating check: [cheapest test that gives a different answer if H1 is true vs false] — status: open/confirmed/refuted
H2: ...
```

- 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.
- 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.
- 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?).
- 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.

The 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.

## Premortem Before Closeout

Spend thirty seconds assuming the work shipped and broke. What broke?

- The caller you did not read.
- The platform/environment you did not test (other OS, prod build, empty database, first run).
- The concurrent or repeated invocation you did not consider.
- The input shape the type system does not forbid but reality produces.
- The behavior you changed that something else depended on.

Check 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."

## Calibration

- 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`.
- 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.
- Confidence should rise only when evidence arrives, never because time passed or because you repeated the claim.

## The Stuck-Strategy Ladder

When 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:

```text
1. Re-read wider     → the target file's callers, tests, and config; the bug is often one level up
2. Shrink the repro  → smallest input/file/test that still fails; small repros expose mechanisms
3. Change layer      → probe below or above (API instead of UI, DB instead of API, runtime instead of build)
4. Check the world   → current docs, changelogs, known issues; your memory of the API may be the bug
5. Ask one fork      → a single concrete question with the evidence and the options, not "any ideas?"
```

State 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.

## Effort Matching

All 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.