Fable Context Thrift

Context is the budget everything else is paid from. Spend it on what changes your next action; nothing else.

Purpose

Prevent context bloat, token exhaustion, unnecessary whole-file reads, redundant verifications, and sequential execution latency. fable-context-thrift treats context tokens and tool calls as a scarce, valuable engineering budget.

When to Use

• At the start of any multi-step task and during exploratory codebase investigations.
• Before reading files, searching symbols, or checking repository structure.
• When tempted to read entire files rather than targeted slices, symbols, or functions.
• When executing multiple independent lookups or checks that can be batched in parallel.

When NOT to Use

• Comprehensive codebase discovery requiring structural mapping of unknown subsystems (use fable-discover).
• External API documentation and primary-source research (use fable-research).
• Deep vulnerability tracing across distributed trust boundaries (use fable-security).

Inputs

• exploration_intent: The specific load-bearing question or uncertainty to be resolved.
• workspace_state: Existing established facts, open files, and previous tool outputs.

Expected Outputs

• targeted_evidence: Minimal, high-signal code excerpts, line references, and exact facts.
• decision_readiness: Confirmation that the "enough-to-act" bar is reached with zero extraneous tokens.

Procedure

1. Targeted Read Strategy: Read only the symbol or section needed, not the file. Widen only when a specific question demands it.
2. Parallel Block Batching: Multiple greps, reads, or status checks must be dispatched in one parallel block. Sequencing independent reads adds latency, not care.
3. Delegate Sweeps vs Keep Lookups: Broad questions ("where is X handled", find-all-usages in unfamiliar territory) go to a search subagent if available — keep the conclusion, not the file dumps. Known single lookups stay direct. The subagent is for when you don't know where things live.
4. Tool Confirmation Principle: Never re-read a file to check an edit landed; the edit tool fails loudly. Verify outcomes with one cheap end-state check (a grep for the old token), not per-file re-reads.
5. Preserve Established Facts: What the conversation already verified, don't re-derive. What the user already decided, don't reopen.
6. Eliminate Narrative Overhead: Don't narrate options you won't pursue. Deliberation is for choices you might actually make.
7. The Enough-to-Act Test: If more exploration would not change your next action, exploration is over. Act.

Decision Rules

• If an additional search result would not change your next command or edit, do not make the search.
• When an edit succeeds cleanly, proceed directly to verification without viewing the modified file again.

Tool Policy

• Batch all independent read and grep tool calls into a single message/turn.
• Use line offsets and targeted slices (StartLine, EndLine) when viewing files.
• Reject whole-file reads where ripgrep already provided exact line numbers.
• Prefer targeted ripgrep queries over file-tree traversal when locating symbols.

Evidence Requirements

• Report line-level citations (path/to/file#L10-L25) rather than dumping full function bodies into conversation.
• Use single end-state checks (e.g. grep for deleted token or exit code) as proof of edit application.
• Preserve established facts without requiring repeat execution evidence in the same session.

Failure Handling

Stop spending immediately when encountering any of these Red Flags:

• A Read call for a file you edited this turn.
• The same fact verified twice in one session.
• Sequential tool calls with no data dependency between them.
• An exploration step you can't name the decision for.
• Whole-file reads where a grep already gave you the line numbers.

Completion Criteria

• The load-bearing question is answered with minimum tokens spent.
• The next engineering action is unblocked and clear.
• Context space is preserved for implementation, verification, and diff review.