fable-scope-discipline

Fable 范围约束

严格按照要求构建，并把握好改动尺度：深入到足以解决根因，同时缩小范围，不触及其他内容。未经要求的改进并非慷慨之举，而是藏在他人差异中的未经审查的风险。

目的

在修改代码时严格遵守范围边界。防止顺手重构、外观调整、推测性优化、未经要求的验证检查，以及差异膨胀。

适用场景

• 在现有代码库中实施任何改动时。
• 想要顺手清理相邻函数、重新排版空白字符或重命名变量时。
• 认为某个次要缺陷“可以说也在范围内”时。
• 检查的差异涉及的文件或行数超出任务合理所需时。

不适用场景

• 明确要求进行大规模重构或架构迁移时（使用 fable-simplify 或 fable-architecture）。
• 要在整个工作区中移除无用代码或弃用系统时（使用 fable-simplify）。
• 编写探索性原型或试验性实现时（使用 fable-discover）。

输入

• task_specification：具体且有明确边界的任务、用户指示和验收标准。
• current_diff：实施过程中生成的 Git 工作差异。

预期输出

• bounded_diff：仅解决获准问题的最小化、精准差异。
• discovered_items_report：摘要中列出其他已发现但刻意未处理的问题的结构化清单。

流程

1. 只实现要求的内容：严格聚焦于分配的任务或请求；不做推测，不做“顺便”改动。
2. 相邻不代表在范围内：“同一个函数”“同一个文件”“同一类缺陷”描述的是位置，不是授权范围。任务范围由用户的措辞决定；位置上的接近不能决定任何事。
3. 论证测试：如果你正在为某项额外改动构造理由，声称它“可以说属于修复范围”，那它就不属于范围。真正属于范围的改动不需要论证。把发现写进报告，让用户决定。
4. 开放问题测试：如果额外修复需要尚未解决的设计选择（报错还是钳制？重命名为什么？），这就证明它是独立任务。不能在替别人修复 Bug 时擅自决定契约问题。
5. 把握好改动尺度：既不能只修补症状（只修一个情形，Bug 仍然存在），也不能重写一通（Bug 修好了，却改了 50 项无关内容）。应在明确的范围内修复根因。
6. 不顺手改动：不做改动不需要的重命名、重新排版、重构或依赖升级。差异中的噪声会掩盖真正的改动。
7. 控制触及范围：如果差异明显大于任务暗示的范围，请停下来重新评估改动尺度。
8. 删除前先检查：如果发现的内容与任务描述相矛盾，或并非你创建，应先指出，而不是盲目覆盖。
9. 将发现写入报告：过程中发现的真实 Bug、无用代码或过时文档，应写入摘要；既不要悄悄修复，也不要悄悄忽略。

决策规则

想法	实际情况
“这和交给我处理的那个 bug 属于同一类缺陷”	分类属于问题分类体系，而非授权范围。用户只指定了一个缺陷。
“它属于同一个函数契约的范畴”	这又是在按位置划定范围。契约会根据决策而变化，而不是取决于光标附近的代码。
“只修一个不修另一个，就只解决了一个完整正确性问题的一半”	问题边界由用户定义。将其写入报告，让用户重新划定边界。
“这样它就是修复的合理组成部分，而不是范围蔓延”	一旦你开始争论这是否属于范围蔓延，它就是了。
“这些改进都毫无争议”	毫无争议不是标准；用户要求才是。改进应单独提交差异，供审查。
“用户说他们重视代码质量”	这是一种价值表态，而不是工作指令。质量也包括原子化、可回退、可审查的差异。

• 如果某项代码更改并非用户场景或测试通过所必需，就撤销它。
• 如果发现相邻 bug，将其记录在报告中，作为后续事项。

工具策略

• 经常运行 git diff，检查已修改的行和文件。
• 拒绝会不加区分地重新格式化整个文件的工具。
• 将修改限制在最少的文件范围内。

证据要求

• 检查 git diff --stat，确认已修改的文件和行数符合预期影响范围。
• 验证最小改动能够通过测试，不依赖未要求的附带修改。

失败处理

遇到以下危险信号时，立即停止并缩小差异：

• 即将进行的更改附近出现“可能有争议”之类的措辞。
• 修改了超出组件逻辑范围的文件。
• 同一文件中未触及的函数也发生了格式变化。

完成标准

• 差异以精准、克制的方式解决了指定任务的根本原因。
• 没有引入无关文件、样式、依赖项或未要求的重构。
• 将所有次要发现记录下来，以便后续分流处理。