采用事实与决策分离、一次一个问题、每个问题提供推荐答案：事实由 agent 查询，用户逐项确认设计决定；在答复前不推进依赖决定。用户看到的是领域标题、为什么现在要决定、推荐优先的方案、真实备选及其后果和一个直接问题。避免把用户当作代码搜索接口，也避免一次抛出大量互相依赖的问题。不要把 Decision Map 或讨论轨迹写入最终 Design。
采用明确的阶段输入输出、成功标准追踪和完成后记忆沉淀。没有保留独立 Plan 阶段或常驻执行账本：完整 Design 已确定实现机制，Act 根据真实代码动态安排机械执行顺序，Review 则从 Design 和真实调用链独立反查。只有工具运行所需的临时状态保持本地，避免让每个项目的过程文档污染共享 kit。
采用先探索项目、在确有多个有效方向时先比较 2-3 个整体方案，再按依赖关系讨论真正受影响的架构、接入、接口、数据、失败行为和验证。只有受影响的领域才出现，但一旦受影响就必须向用户展示并确认或由用户明确委托；仓库证据可以消除伪备选，不能让受影响的设计静默通过。架构、数据结构和数据流使用紧凑树与示意代码，接口使用示意签名或 schema。Design 落盘后先自检实际写入的文件，再由用户审阅，避免对话结论在文档中走样。保留 Design Ready gate 和 Visual Companion 的 just-in-time 原则。没有采用“所有微小改动都必须完整 Design”、机械 TDD 或自动提交 Design 文档。
Design 的“实现方案”指 Act 前必须确定的机制、所有权、状态转换、依赖和生产集成点；文件级顺序由 Act 从真实依赖动态选择，不预写成计划。这样既不让 Act 重新发明架构，也避免维护容易过时的重复 Plan。
Visual Companion 保留上游已加固的 session key、同源 WebSocket、路径 containment、token fallback、断线恢复、空闲退出和 PID 所有权语义，并采用上游的逐题判断：只有必须观察视觉关系或视觉差异才能明显改善理解或回答的问题才进入浏览器。API、数据模型、架构方案选择、文字型 A/B/C、trade-off、公式、代码和流程默认留在终端；把同一内容排成网页不构成视觉价值。离开视觉问题时推送 waiting 页面，终端对话始终是最终反馈和授权通道。
采用其在理解真实调用链之后才执行的 solution-reduction ladder：先判断是否需要新增机制，再依次检查项目既有代码或共享根因 seam、标准库、引擎/平台能力、已有依赖，最后才编写最小项目内实现。Design 要求每个新增抽象、接口、配置、状态、依赖、兼容路径或 fallback 都有已确认需求或项目证据，并说明为何更早的复用层级不足；讨论受影响的架构、接口和数据不等于必须发明新的层。Act 追踪相关调用者并在不改变批准范围时修复共享根因；Review 反向审计每个新增概念的必要性。
不采用其 always-on 模式、先交付默认简化版再询问、强制为每段非平凡逻辑新增检查、追求最少行数/文件数或在生产代码中维护专用债务注释。Agent Workflow Kit 继续显式启动 Design、实施疑问先停问、服从项目测试和代码组织规则，并以“最小完整改动”而非“最短 diff”为目标。Ponytail 的复杂度 review 只作为完整性 Review 的一个维度，不能替代正确性、生产接线、失败行为、安全、性能或验证检查。
- Review 必须读取共享工作区，不能因隔离而错过未提交实现。
- 验证按任务类型选择，尤其不能用普通单元测试替代 GPU/视觉证据。
- Design 在选择各受影响部分时同步检查基于项目证据的失败机制、技术债、稳定契约、可替换内部和诱人捷径；只把会约束实现的预防措施写回相关设计，不再增加一轮独立风险仪式或通用清单。
- 通用工作流应提供门禁和模板，但项目自己的领域规则、资源版本控制和用户明确要求始终优先。