fable-wise

Fable Wise

低层级的认知反射与架构模式，可抵御 AI 垃圾内容、复杂度膨胀和产物漂移。不要添加推测性代码和样板代码，而要强制采用简化、删减、整合并以可观察现实为决策依据的模式。

目的

通过 Depth、Breadth、Coil 和 Mesh 中的认知反射，贯彻资深架构智慧。用直接机制取代臃肿的抽象，整合单一事实来源，从干净的 v0 版本重写经过大量修补的产物，并通过反方批评对计划进行压力测试。

适用场景

• 将已发生漂移、经过大量修补的产物重写为干净的 v0（/re0）。
• 执行前检查模型对细微请求的理解（/readchk）。
• 预先划定不安全范围，让剩余安全部分全力运行（/autobahn）。
• 审核分散的事实，并将其整合为单一事实来源（/ssotize）。
• 用基础的语言机制取代偶然出现的框架／技术栈术语（/detool）。
• 反复审视新做出的技术决策，直到它足够简单，或暴露出其薄弱之处（/feynman）。
• 用一个可能致命的反对意见对工程计划进行压力测试（/hate）。
• 将产物拆分到独立的评估视角中，以暴露隐藏的冲突（/prism）。
• 用仓库中干净且可靠的检查来试验拟议的更改（/sip）。

不适用场景

• 没有结构复杂性的常规小型 Bug 修复（使用 fable-execute）。
• 自动依赖项更新或标准 CI 修复（使用仓库批准的维护工作流）。
• 高层级多主机生命周期路由（使用 get-fable）。

输入

• engineering_artifact：代码文件、架构文档、配置或计划。
• pattern_directive：选定的 Paperthin 认知反射或命令（例如 re0、detool、ssotize、hate）。

预期输出

• debloated_artifact：经过简化、无漂移，并以原生语言基元为基础的产物。
• consolidated_truth：消除重复参数的单一事实来源配置。

流程

1. 阶段 1 — 基数与时间分类：
   • Depth（一个产物，当下）：这个单一产物是否干净、精简且真实？应用 re0、readchk、detool、debloat、feynman。
   • Breadth（多个产物，当下）：所有地方的事实是否一致？应用 ssotize、reorder。
   • Coil（一个项目，跨多次迭代）：每个周期是否为下一个周期带来经验？应用 re0-loop、re0-memo、re0-work、catchup、nba。
   • Mesh（多个视角，跨多轮）：整个群体是否会收敛到事实？应用 prism。
2. 阶段 2 — 去除冗余与替换机制：
   • 去除营销流行语、宣传性形容词和 AI 样板内容。
   • 用标准语言机制取代偶然出现的第三方库术语。
   • 将臃肿的产物压缩到承载核心内容所需的密度：删减文字，绝不删减规则。
3. 阶段 3 — 反方测试与冷读：
   • 应用 Feynman 检查：用简单、不带行话的语言解释决策。
   • 应用 Hate 检查：找出唯一的致命缺陷，并设计成本最低的测试来证伪它。
   • 以置身事外的第三方视角冷读产物：没有先前对话的上下文，它是否能独立成立？
4. 阶段 4 — 单一事实来源整合（SSOT）：
   • 当多份文档或模块声明的参数互相冲突时，指定一个权威来源。
   • 更新所有关联引用，使其指向这一权威来源；消除重复造成的漂移。

决策规则

诱人的自我开脱	严格现实 / 不变量	原因
“添加更多解释能让文档更清晰。”	违规。 解释会稀释核心规则。	臃肿的文档会导致 Agent 漏掉关键指示。
“我们应该再给这个遗留文件打一个补丁。”	违规。 补丁积累到一定程度时，应重写为干净的 v0（re0）。	反复打补丁会掩盖底层设计腐化。
“所有人都觉得这个计划很好；没必要提出异议。”	禁止。 始终进行唱反调测试（hate）。	尽早发现致命缺陷只需几分钟；等到生产环境中才发现，则要花上数周。
“在两个地方重复配置也无妨。”	禁止。 立即整合为单一事实来源（SSOT）（ssotize）。	重复的配置必然会逐渐失去同步。

• 优先删除而非添加：去除冗余、消除偏差、移除未经验证的假设。
• 判断一项产物是否完成，不是看它还能不能添加内容，而是看是否能在不损失必要行为的前提下继续删减。

工具策略

• 使用标准文件查看和编辑工具，整合重复的代码和配置。
• 执行项目的代码检查工具和测试，验证精简后行为仍然保持不变。
• 原生标准库功能足以满足需求时，不要引入第三方辅助依赖。

证据要求

• 提供差异，显示代码行数或文档复杂度净减少。
• 简化前后测试套件均通过，行为完全一致。

失败处理

• 如果精简重构导致现有测试失败，应找出隐藏的不变量，明确记录，并恢复通过测试的行为。
• 如果唱反调的 hate 检查发现计划存在无法修复的缺陷，则中止计划并报告该缺陷。

完成标准

• 移除所有冗余的样板内容、不必要的层次和重复配置。
• 建立单一事实来源，并验证所有引用文件均已统一。
• 通过测试执行确认行为正确。