fable-method

The Fable Method

A mid-tier model that follows this loop beats a stronger model that free-styles: the quality lives in the structure, the evidence, and the honesty, not in the model. The loop is self-contained. Follow it literally.

Purpose

Provide a universal, disciplined engineering loop across all problem shapes: classify the ask, define done, gather evidence, decide, act surgically, verify by observation, and report outcome-first.

When to Use

• When the user explicitly requests the Fable Method (/fable-method, "approach this like Fable").
• When starting an ambiguous multi-step engineering task with no specialized specialist pre-assigned.
• When executing structured planning (/fable-method plan <task>).
• When auditing existing conversational work against lifecycle invariants (/fable-method audit).

When NOT to Use

• Trivial one-line edits where the change is obvious and self-contained (execute directly).
• Purely autonomous background long-polling or test loops (use fable-loop).
• Multi-host installation and setup procedures (use fable-release or installer).

Inputs

• task_description: The problem prompt, specification, or bug report.
• domain_adapter: Optional sector adapter (references/domains/*) for non-code domains.

Expected Outputs

• verified_solution: Surgically implemented changes matching the specification.
• execution_evidence: Observable evidence proving the solution works as intended.

Procedure

1. Triviality Gate: If the task is one file, under ~10 lines, with no new behavior and known edit, execute directly and confirm with one check.
2. Fit Gate: Determine where the answer lives: in reachable sources (run loop), in unknown external techniques (research first), or only in inference (flag low-confidence).
3. Step 0 — Classify the Ask:
   • Question / assessment: Report findings, change nothing.
   • Task: Implement and verify.
   • Plan-first: Produce plan and wait for approval if scope is ambiguous or actions are irreversible.
4. Step 1 — Define Done: Explicitly declare what completion looks like and how it will be verified.
5. Step 2 — Gather Evidence: Open sources, read relevant code, check authoritative docs before modifying state.
6. Step 3 — Decide: Formulate the minimal viable plan.
7. Step 4 — Act Surgically: Modify only the necessary lines with zero collateral drift.
8. Step 5 — Verify by Observation: Run the code, execute the test, observe the side effect.
9. Step 6 — Report Outcome-First: State the outcome in the first sentence.

Decision Rules

• Plan-First Priority: If any irreversible action, destructive command, or ambiguous scope is present, plan-first supersedes task execution.
• Scope Gate: Do not touch files outside the bounded problem domain.
• Evidence Gate: A task is not done until fresh passing machine evidence is observed.

Tool Policy

• Execute shell commands to run compilers, linters, and test runners.
• Use targeted file reading and editing tools.
• Consult domain adapters in references/domains/ when handling non-coding tasks (marketing, ops, finance, devops).

Evidence Requirements

• Direct terminal outputs from test runners or build tools.
• Line references to source code confirming bug mechanism and repair.

Failure Handling

• If a step fails, diagnose the failure mechanism rather than blindly retrying the same operation.
• If two consecutive failures occur, immediately route to fable-recover.

Completion Criteria

• All criteria defined in Step 1 ("Define Done") are satisfied.
• Fresh passing test evidence captured.
• Final report delivered outcome-first with zero fluff.