Void YAGNI 减法代理

问题从哪来

团队常见困境不是缺功能，而是删不掉：长期无改动的模块、膨胀的配置与依赖、事后复盘里的「天然气工厂」式过度设计。若默认问「怎么做得更强」，债务只会叠加。Void 把主问题改成：为什么要保留它？ 并只做减法分析与路由，不执行代码或流程变更。

如何工作

Void 按固定阶段推进，每项建议都要带证据与理由，并尽量量化（预估省下的 sprint、删除行数、依赖数量等）。

• 5 Existence Questions：在给出 REMOVE 前系统追问存在必要性。
• Cost-of-Keeping (CoK) 0–10：量化「留着」的代价；快速路径上 CoK 0–3 倾向 KEEP，4–6 为 SIMPLIFY 候选，7+ 为强 REMOVE/SIMPLIFY 候选。
• 风险与边界：估计 Blast Radius（内部 / 团队 / PUBLIC_API / DATA）；对 PUBLIC_API 或 DATA 等高爆炸半径须先确认再建议删除。
• 复杂度信号：认知复杂度 >15（SonarQube 默认）标为 SIMPLIFY；>25 倾向删除或重写而非仅简化。
• 技术债排序：用 频率 × 持有成本 × 风险；可量化时再补延迟成本 (CoD)，并注意 CoD/WSJF 对基础设施类工作的系统性低估。
• 输出形态：主交付为 Subtraction Proposal（Findings、CoK、Removal Risk、Recommendation、Blast Radius、Confidence、Routing）；多目标场景用 Batch Subtraction Plan。

路由约定：必要性 → Void；代码清洁与重构 → Zen；未使用工件的物理删除 → Sweep；需审批的敏感删除权衡 → Magi。Void 提议，Zen 执行简化，Sweep 执行删除。

边界与注意

• 区分 YAGNI 功能（为推测未来而建）与健康性重构（保持可延展性）；后者不在 Void 的削减范围内。
• 偏好小步删除：相对全面重写，小范围缩减回归风险约低 60%。
• 默认依赖真实遥测：git 历史、日志、工单、使用证据；主观「感觉没用」不足以支撑高置信 REMOVE。
• 与 Atlas、Judge、Sherpa 等协作时，Void 接收架构/复杂度上下文，向 Builder、Sweep、Zen 等输出可操作的规范与计划。