用途：在修改既有代码时强制执行严格的范围边界，让实现“只做被要求的事，且做到正确的深度”——足以修复根因，又窄到不触碰其它内容。资料认为未被要求的“改进”不是慷慨，而是藏在他人改动差异里的未评审风险。
主要能力：
- 防止顺手重构（drive-by refactoring）、粉饰性重写、投机优化、未被要求的校验检查以及差异膨胀。
- 提供判断规则：相邻不等于授权（同一函数、同一文件、同类缺陷只描述位置，不构成授权）；“论证测试”——若需要为额外改动构建“可以说属于本次修复”的论证，那它就不属于本次范围；“开放问题测试”——若额外修复需要尚未确定的设计选择（如钳制还是抛错、重命名成什么），说明它是独立任务。
- 要求“正确的高度”：既不是只补症状（修一处、bug 仍在），也不是整体重写（bug 修了、五十个无关处被改），而是在受限范围内修复根因。
- 触达预算：若差异明显大于任务所暗示的规模，应停下重新评估。
- 删除前先查看：若发现的内容与任务描述矛盾或并非自己创建，应先上报而非直接覆盖。
- 发现项进入报告：途中发现的真实 bug、死代码、过时文档写入总结，既不悄悄修复也不悄悄丢弃。
使用方式：在实现任何既有代码库改动时启用。输入为 task_specification（具体受限任务、用户指令与验收标准）和 current_diff（实现期间的工作区 git diff）；输出为 bounded_diff（只解决被授权问题的最小外科式差异）与 discovered_items_report（在总结中结构化列出发现但刻意未触碰的其它缺陷）。流程为：严格按分配的任务卡或请求实现；频繁运行 git diff 检查触及的行与文件；拒绝会不加区分地重排整个文件的工具；把修改限制在最小文件集合；用 git diff --stat 核对触及文件与行数是否符合预期影响范围；验证最小改动下测试通过，且不依赖未被要求的附带修改。决策规则包括：若某代码改动不是让用户场景或测试通过所必需，就还原它；发现相邻 bug 则作为后续项记入报告。
适用场景：在既有代码库中实施任何改动；当想清理邻近函数、重排空白或重命名变量时；当认为某个次要缺陷“可以说在范围内”时；当检查的差异涉及的文件或行数超过任务合理预期时。
限制：不适用于被明确指派的大范围重构或架构迁移（资料建议改用 fable-simplify 或 fable-architecture）、跨整个工作区移除死代码或废弃系统（改用 fable-simplify）、编写探索性原型或技术验证（改用 fable-discover）。遇到红旗信号应立即停止并收缩差异：改动附近出现“可以说（arguably）”一词、触及组件逻辑范围之外的文件、对同文件中未触碰函数做格式化改动。完成标准：差异以精准的外科式改动解决任务根因，不引入无关文件、样式、依赖或未被要求的重构，所有次要发现均已记录以备后续分诊。