dev：开发与实施
新的主入口是 开发与修复。本页保留 /workflows/dev 深链，并提供 dev 的阶段细节；完整 subtype 与 dev.plan-review 层级以分组页和工作流索引为准。
适用 / 不适用
适用：新功能、重构、按已确认需求写文档或改代码。
不适用：只想听建议（用 analyze）；已确认的缺陷修复（用 fix）。
是否改文件
会，但要经过需求确认。未确认前不应改业务源码。
阶段与检查点
- CP1 需求：确认用户结果、范围、非目标、验收和消费者。
- CP2 方案：确认模块职责、共享契约、风险、回滚和验证路线。
- 条件 CP3 计划：多文件、高风险或跨模块任务确认批次、依赖和停止条件。
- 实施与 checkpoint：按确认范围增量修改；批次间验证，不静默扩展需求。
- ECR：对照需求、diff 和测试证据，写报告与续接状态。
低风险单文件任务可以缩短产物，但不能把 CP1 与 CP2 合并成一句“我准备这样改”。
正式任务会在 source mutation 前建立 server-owned task identity 和需求概况。用户直接提供产品需求时，00-需求概况.md 记录来源与映射，01-产品需求.md 保存用户原文，AI 不得为了“整理”而改写产品真相。只有明确的小任务才能使用有次数和精确路径限制的 fast-path lease；目标扩大、重复消费或上下文漂移会立即升级到正式流程。
确认边界
范围、公共契约、唯一 project/task、是否改哪些路径、是否提交或发布，都要在相应边界获得授权。正式写入还要先取得与目标槽位、操作和当前任务一致的单次工作流授权。auto 可以自动通过 CP，但不会自行扩大到 push、tag、发布或项目外写入；文件与命令是否实际执行由宿主权限配置决定，DevCodex 只核对任务、root、slot 和保留不变量。
产物
需求确认、技术方案（如有）、代码或文档变更、验证记录、报告。
验证
根据 bug、需求和项目真实消费者选择最小充分测试，并写下命令和结果。普通实施最高走受影响的 V0～V2；只有当前明确的发布前全面审查或 release authority 才能进入 V3/full。runtime 专项不会暗跑 pack、全局安装或宿主部署；这些动作各有独立入口和授权。本产品的 README 与站点 Markdown 不做 JavaScript 正文校验。
预计超过 10 分钟或含 heavy 节点时，confirm 模式会展示并保存唯一当前预算摘要；确认当前卡即可。Auto 可直接执行同一正式任务的精确 V0～V2，并允许最多两次不扩大 dirty 路径、节点或根预算的修复续跑；第三次必须停止，不能自动换根清零。严格后继 commit 只有在验证 level、purpose、边界、节点、heavy、副作用与全部预算和父根完全一致时才能换根；当前 fresh Auto 可以在同 task/project/root/session/revocation 下重绑 context，过期入口只能沿用原绑定。已提交修复必须显式带入冻结 changed files，clean tree 不能把 affected 缩小。用户说暂停、停止或缩小范围后，旧卡和旧 lease 不会复活。
完成条件
已确认范围逐项落地，关联消费者已同步，验证按约定跑完，命令和退出码可查，剩余风险与回滚写进报告。