decomplex

Decomplex

硬性规则

• 仅限一种模式：
  • 预防 — 尚未实现的计划／设计／依赖／保障措施
  • 审计 — 现有源代码／测试／配置／依赖／架构
  • 发现项分流 — 可能增加复杂度的已提供建议
• 审查前先确定：
  • 目标
  • 权限
  • 必需行为
  • 范围
• 仅在歧义会影响上述事项时提问。
• 目标不可更改。
• 确定契约前，先阅读 ADR 约定，了解路径和决策权限。
• 只能写入一个 adrs/work/<change>-decomplex.md 文件，除非明确指定了其他输出路径。
• 切勿编辑被审查的制品（即使被要求修复）。
• 对明确要求不写入／仅在聊天中回复的请求，应在聊天中提供发现项。如果无法写入指定文件，须说明限制；切勿声称已保存。
• 仅处理复杂度权衡。
• 将缺陷／安全／性能／计划合规性问题转交给负责的工作流（例如 code-review）。
• 简单 ≠ 更少的代码行／辅助函数／依赖。
• 保留有证据支持的：
  • 信任边界
  • 不变量
  • 兼容性
  • 生命周期清理
  • 运维需求
• 发现项仅供参考。
• 由使用方决定如何处置／实现／升级处理。
• “没有潜在复杂度发现项”也是有效结论。
• 使用方必须：
  • 处置每一项
  • 切勿自动实现
  • 有疑虑时询问用户

准入门槛（必须全部满足）

1. 存在具体的概念、维护或运维负担
2. 对当前需求缺乏充分的合理性说明
3. 存在现实且可触及的实际成本
4. 有具体且改动最小的简化方案
5. 保留必需行为
6. 简化后的收益与回归成本相称
7. 明确检查例外／边界

证据：

• 仅使用 Confirmed 或 Supported

未通过门槛时：

• 进行有限验证
• 询问用户
• 或省略

切勿仅根据以下因素提出发现项：

• 辅助函数数量
• 单纯的重复
• 新颖性
• 假设的规模增长
• 单纯的风格问题

优先顺序：

1. 删除
2. 直接使用
3. 局部逻辑／辅助函数
4. 现有共享抽象
5. 新抽象

流程

1. 契约
   • 阅读 ADR 约定和相关已接受决策
   • 模式
   • 目标
   • 权限
   • 范围
   • 行为
   • 报告路径
   • 约束
   • 仅在准入门槛需要时检查调用方／测试／配置／历史记录
2. 提出候选项之前
   • 完整阅读 references/complexity-gates.md
   • 将上下文信号作为参考，而非配额清单
3. 评估
   • 对每个候选项完整应用准入门槛
   • 按预期简化价值排序
4. 建议
   • 仅限：Act | Validate | Ask user
   • 不要执行相关操作
   • 分流模式：保留所有已提供的 ID
   • 分流处置方式：Act | Validate | Ask user | No action
5. 写入之前
   • 完整阅读 assets/decomplex-review-template.md
   • 恰好写入一份报告，或在不写入的约束下于聊天中返回报告
   • 删除模板说明／空白章节
   • 保留已检查／跳过内容的覆盖范围及限制
6. 验证
   • 指定的报告已存在，或已明确说明仅在聊天中交付／写入受限
   • 所有纳入项均通过准入门槛
   • 已处理所有分流 ID
   • 未更改任何目标文件