核心概念

设计思想

先把需求理解到足以安全实施，再在正确的边界写最小而清晰的改动，用新鲜证据证明它有效，最后让文档反映事实。

要纠正的三种失败模式

通用工作流包把每个任务都塞进计划、TDD、worktree、子智能体和发布仪式。难任务只是略有改善，普通任务却更慢更脆。这里简单任务直接处理，完整工作流只在你显式请求时加载。

回答、批准、纠正和补漏都保持在同一个任务上下文里，任务做到一半不需要重新调用入口。

独立问题批量询问，依赖问题顺序追问；回答问题永远不等于授权编码。批准是一个独立、明确的动作。

把成本和控制权分开：常驻层小到几乎无成本，昂贵的那一层由你主动选择。

自动

会话启动、恢复和压缩时注入一组最小的工程、完成和安全规则。不包含计划、TDD、worktree 或发布仪式。

显式

完整工作流会改变整个会话的形态和成本，所以只有你点名才加载；一旦加载，就在任务级保持活跃直到任务结束。

Develop 是唯一在中间设置人工关卡的工作流。批准之前只对齐，批准之后才实施和验证。实质范围变化回到对齐阶段；原验收行为的遗漏则直接重新进入实施。

发现阅读规则、文档、代码、测试和调用方。

澄清只解决会改变行为的决定。

检查点记录最终实施边界。

批准要求用户给出明确行动指令。

实施完成最小且清晰的变更。

验证运行新鲜且范围匹配的验证。

完成对齐事实并报告剩余缺口。

自动触发做过、测过，然后被移除了。两个实验都记录在项目的基准日志里。

自动加载 code-design 的触发准确率是 100%，但结果没有变好：耗时 +34.6%、工具调用 +75%、输入 token +76.9%。开销是真的，收益不存在，于是改为用户显式调用。

即使收窄了描述，模型仍然会把无关的策略修改当成诊断任务。负面措辞构不成确定性边界，于是全部工作流改为显式调用，只保留极简核心自动注入。

显式调用决定整个任务的处理方式；自动的那部分只保留小而确定的规则。

目标是"必要的最低复杂度"，不是最少语法，也不是最少行数。所有涉及设计的工作流都用同一份清单。