Fable Scope Discipline

Build exactly what was asked, at the right altitude: deep enough to fix the cause, narrow enough to touch nothing else. Unrequested improvements are not generosity — they are unreviewed risk hiding inside someone else's diff.

Purpose

Enforce strict scope boundaries during code modification. Prevent drive-by refactorings, cosmetic rewrites, speculative optimizations, unrequested validation checks, and diff bloat.

When to Use

• When implementing any change in an existing codebase.
• When tempted to clean up neighboring functions, reformat whitespace, or rename variables.
• When thinking a secondary defect is "arguably in scope".
• When inspecting a diff that spans more files or lines than the task logically warrants.

When NOT to Use

• When tasked explicitly with a broad refactoring or architectural migration (use fable-simplify or fable-architecture).
• When removing dead code or deprecated systems across the whole workspace (use fable-simplify).
• When authoring exploratory prototypes or spikes (use fable-discover).

Inputs

• task_specification: The specific bounded task, user instructions, and acceptance criteria.
• current_diff: The working git diff generated during implementation.

Expected Outputs

• bounded_diff: A minimal, surgical diff addressing only the authorized problem.
• discovered_items_report: A structured list in the summary noting other defects discovered but deliberately not touched.

Procedure

1. Implement What Was Asked: Focus strictly on the assigned card or request; nothing speculative, nothing "while I'm here."
2. Adjacency is Not Scope: "Same function", "same file", "same class of defect" describe location, not authorization. The user's words define the task; proximity defines nothing.
3. The Argument Test: If you are constructing an argument for why something extra is "arguably part of the fix" — it is not. Real scope never needs an argument. Put the observation in your report and let the user decide.
4. The Open-Question Test: If an extra fix requires an unresolved design choice (raise vs clamp? rename to what?), that proves it is an independent task. You cannot settle a contract question inside someone else's bugfix.
5. Right Altitude: Not a symptom patch (one case patched, bug alive), and not a rewrite (bug fixed, fifty unrelated things changed). Fix the root cause within the bounded scope.
6. No Drive-Bys: No renames, reformatting, refactors, or dependency bumps the change does not require. Diff noise buries the real change.
7. Touch Budget: If the diff is significantly larger than the ask implies, stop and re-evaluate your altitude.
8. Look Before Deleting: If what you find contradicts the task's description or you didn't create it, surface that instead of blindly overwriting.
9. Discoveries Go in the Report: Real bugs, dead code, or stale docs found along the way go in your summary — neither silently fixed nor silently dropped.

Decision Rules

• If a code change is not required to make the user's scenario or test pass, revert it.
• If an adjacent bug is discovered, log it in the report as a follow-up item.

Tool Policy

• Run git diff frequently to inspect touched lines and files.
• Reject tools that indiscriminately reformat entire files.
• Keep modifications confined to the minimal set of files.

Evidence Requirements

• Inspect git diff --stat to verify that touched files and line changes match the expected blast radius.
• Verify tests pass on the minimal change without relying on unrequested collateral modifications.

Failure Handling

Stop immediately and shrink the diff when encountering these Red Flags:

• The word "arguably" near a change you're about to make.
• Touched files outside the component's logical domain.
• Formatting changes on untouched functions in the same file.

Completion Criteria

• Diff addresses the root cause of the assigned task with surgical precision.
• No unrelated files, styles, dependencies, or unrequested refactorings introduced.
• All secondary discoveries documented for future triage.