用途：Spec-Driven Development v2 面向“代理将连续工作数小时或数天、跨多个文件与多个垂直切片”的场景。v1 假设一个代理在一个会话内交付一个功能；v2 假设由编排器或人跨多个会话驱动代理，并全程保持正确。
主要能力：三层层级 Project→Sprint→Task；每个任务有 JSON 状态文件，编排器可读取以冷启动续跑；评审轮循环（评审→反馈→修改→再评审直到通过）；worktree 隔离，每个任务在干净检出中运行、可单独回滚；Context Pack 为“推理盲”子代理评审者提供简报；机械式任务门禁，用脚本强制检查规模、验收与回滚；治理即代码，边界规则放在 lint/CI 而非 markdown；产物登记表，把评审中发现的新规则升级为 lint。
使用方式：目录结构为 context/dev/projects-001-<slug>/ 下含 RFC.md、PLAN.md、STATE.json 与 sprints-001-<slug>/，sprint 内含 SPRINT.md、TASKS.md、REVIEWS.md、STATE.json、tasks/ 与 reviews/；另有 context/artifact-registry/rules/ 与 scripts/governance-check.sh、scripts/task-lint.sh。角色分为 Planner、Builder、Reviewer（子代理，推理盲）、Orchestrator。阶段为 Phase 0 PROJECT、Phase 1 SPRINT、Phase 2 BUILD（每任务用 git worktree add ../wt-TK-NNN -b tk-NNN-<slug>）、Phase 3 REVIEW（轮次循环，超过 5 轮升级给人）、Phase 4 SHIP。编排器每轮读取 STATE.json 决定下一步。
适用场景：预计代理时间超过 4 小时、任务超过约 8 个或不止一个垂直切片、由子代理评审每个任务、由编排器驱动迭代、架构边界需机械保证时使用 v2。单会话功能应使用 v1。
限制：v2 对单会话功能是额外开销；评审者必须是无 Builder 对话访问的全新子代理；任务文件需含验收标准、可执行 verify 命令、文件数≤5、rollback 行、标题不含 and；XL 任务禁止；不得同时打开两个 sprint；已合并任务必须有 approve 评审文件。资料未提供具体安装命令、收费或平台信息。