Zc Sdd Tdd Workflow

SDD + TDD 开发工作流

角色定位

这是完整交付的编排 skill，不是每个阶段的详细教程。它负责把需求按阶段推进，并在进入具体阶段时再读取对应专项 skill。

渐进式披露规则：

• 当前只需要路由和门控时，只读取本文。
• 进入某个阶段时，再加载该阶段 skill。
• 不把所有阶段规则同时塞进上下文。
• 发现任务变成 bug、文档、发布或上下文问题时，切换到对应入口，不继续硬走完整流程。

快速路径

1. 判断任务是否需要完整交付；简单修复、文档或调查任务不要套完整流程。
2. 若需求模糊，先进入 brainstorming-and-design 或 spec-driven-development。
3. 若规格清楚，进入 planning-and-task-breakdown。
4. 计划可执行且实现已获授权时，进入 incremental-implementation；可测试的行为变更配合 test-driven-development。
5. 实现完成后，进入 code-review-and-quality。
6. 准备声明完成前，进入 verification-before-completion。
7. 需要提交时，进入 git-workflow-and-versioning；缺少提交授权才询问，已有授权不重复确认。
8. 周期结束或需要沉淀经验时，进入 sprint-retrospective。

阶段门控

构建模式选择

进入 Build 前先选择执行模式，而不是直接默认手动实现。复杂任务先评估 Readonly Consult，用低风险只读审查发现路线、测试、安全、性能或平台适配问题，再决定是否需要更重的写入型并行：

• Manual：简单任务、小修复或同一文件内紧耦合改动，主线程直接实现。
• Readonly Consult：复杂任务需要架构、测试、安全、性能、产品、上游吸收、Codex 适配、安装/更新或审查侧评；任务范围明确且 Codex host 可用时，通知后直接启动，不改文件。
• Serial Subagent：已有计划，任务彼此独立但有依赖顺序；使用 subagent-driven-development 串行委派。
• Context Fan-Out：任务可以按文件、模块或证据问题并行，且有清晰文件所有权和 fan-in gate；使用 parallel-agent-dispatch。低风险写入在实现已授权、所有权和验证清楚时可通知式启动；高风险缺少对应授权时才确认，边界不清时先收敛或降级串行。
• Team Orchestration：需要 tmux + git worktree 文件系统隔离、长时间多 worker 或 Codex / Qwen 多 CLI 协作；使用 team-orchestration，必须用户明确要求或确认。
• Context Steward Sidecar：长期项目事实确需更新，且写入授权与独立所有权清楚时，考虑派 agent:context-steward 维护上下文；普通实现授权不自动扩展为用户配置或跨会话记忆写入。权限遵循共享契约，fan-in 核对 context stewardship report 与写入证据；不满足条件时记录待刷新项并继续主任务。

Build 阶段消费计划中的 agent_opportunity；计划缺失时先按 parallel-agent-dispatch 的 agent opportunity contract 补判，再路由到对应执行 skill。此处只维护生命周期差异：

• 主线程负责目标、stop gate、fan-in 和最终验证，不抢占已分配任务。
• Manual 直接实现；Serial 按依赖顺序；Fan-Out 按互斥所有权执行；Team 仅在显式确认后进入。
• 执行模式不可用或边界失效时，按计划的 degraded path 缩小范围或降级串行。
• Review 和 Verify 继续消费 fan-in evidence；并行完成不能跳过集成验证。

审查与回归闭环

多 agent 任务必须遵循闭环所有权：

producer owns fix
reviewer owns regression
controller owns fan-in

• 实现方或产生方负责优先修复自己引入的问题。
• 审查方或提出方负责给出复现条件、断言、期望行为、风险等级，并在修复后复验原 finding。
• 主线程负责判断 finding 是否成立、优先级是否阻塞、是否转派、是否接受结果。
• 实现方两次修不好时，主线程可以缩小问题后转给更合适的 agent 或自己接手。
• 审查方默认不直接修；机械小修或用户明确要求时，主线程可以把 finding 转成修复任务。

审查等级：

• light review：实现方自审 + 主线程检查。
• standard review：实现方自审 + 独立 reviewer + 提出方回归。
• strict review：规格审查 + 代码质量审查 + 测试 / 安全 / 性能按风险加入。

中等以上任务默认 standard review，高风险任务默认 strict review。

阶段切换纪律

• 进入新阶段前，说明当前阶段已满足的证据。
• 阶段门控检查证据，不默认要求人工逐阶段批准；已授权工作持续到完成相关验证、修复引入的失败和交付结果。
• 用户只要求研究、方案或评审时，在该范围完成；不得自行扩大为实现或发布。
• skill 指导与用户明确要求冲突时遵循用户要求。若某条指导确实要求暂停，指出具体文件、条款和缺失决策；不要把例行步骤解释为新授权门槛。
• 阶段中发现前提失真时，回退到上游阶段，不继续堆实现。
• 长会话变慢或内容开始混乱时，切到 context-budget-audit / context-engineering。
• 变更涉及浏览器体验时，在单元/API 测试之外补 browser-qa-testing。
• 涉及高风险命令、生产数据或敏感文件时，先切到 safety-guardrails。

停线条件

立即停止当前阶段并重新定位：

• 测试、构建或 lint 失败但原因未读清。
• 用户纠正使当前步骤与最新需求或安全边界冲突时，停止受影响步骤，保留仍有效的成果，调整计划后继续授权范围内的工作；普通补充要求或状态询问不重启整条流程。
• 计划要求修改的文件和实际代码结构明显不一致。
• 出现破坏性操作、凭据、生产数据或不可逆迁移风险。
• 需要并行但没有文件所有权、隔离策略和 fan-in 验证。
• review finding 未闭环，或提出方尚未完成回归确认。

输出契约

完整交付过程中的关键结论都要使用可审查的推荐格式：

Recommendation: <下一步动作> because <具体证据、取舍和被放弃的替代方案>。

有真实方案取舍时说明原因和验证方式；例行阶段推进只需说明结果与下一步，不为填格式虚构替代方案。

验证

声明完成前至少给出：

• 实际运行的验证命令
• 退出结果
• 与本次任务相关的关键输出
• 未运行的验证及原因

不能用历史结果、主观判断或“应该没问题”替代验证证据。