fable-context-thrift

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

Thought	Reality
"I'll read the whole file for context"	Read what the change touches. The question you're answering defines the lines you need.
"Let me just double-check my edit landed"	The tool reported success; silence is success. One end-state grep beats N re-reads.
"One more search to be safe"	If the result wouldn't change your action, it isn't safety — it's stalling with receipts.
"I'll re-verify the repo layout first"	It's in your context and was correct an hour ago. Directory trees don't rot mid-session.
"Careful means one call at a time"	Careful means right calls. Independent lookups in sequence is the same work, slower.
"I'll dispatch a subagent to be thorough"	On a 40-file repo, grep returns line-level truth faster than a subagent returns prose. Match the tool to the territory.

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