Wu5 Dev Flow
开始工作
- 从项目根目录运行
python <本 Skill 目录>/scripts/wu5_flow.py status。 - 如果尚未初始化，运行
init；初始化后先阅读spec/index.md、spec/status.md与相关规格。 - 遵守
spec/state.json的当前阶段。不得依赖聊天记忆代替项目状态。 - 在任何写操作前读取 SDD 工作流。涉及 Python 代码时再读取 Python TDD 与 禁止 Hardcode；涉及提交、push 或 PR 时读取 Git 规范；进入审查时读取 审查规范。
核心约束
- 先对齐规格，再批准计划，最后实施。只有用户明确说“批准基线”“批准规格”“批准计划”“批准依赖”或“批准紧急修复”时才能记录对应批准。
- 完整变更严格执行两次人工门禁；轻量变更仅限无行为变化的低风险文档、注释、格式与配置调整；范围扩大时立即升级。
- 对可测试代码执行 RED-GREEN-REFACTOR。未观察到预期失败，不得编写业务实现；没有新鲜验证证据，不得提交或宣称完成。
- 同一仓库只允许一个实施中的变更。检测到脏工作区时只分析，不自动 stash、reset、覆盖或删除。
- 数据库结构或不可逆数据迁移不在本 Skill 的实施范围内；发现后暂停并向用户说明。
- 不读取、记录或提交
.env、密钥、令牌、凭据和真实敏感数据。 - 禁止不当 hardcode。不得把密钥、环境差异、路径、URL、业务阈值或可变策略直接写死在实现中；按 Hardcode 规范改用配置、命名常量或依赖注入。
- 可自动创建已授权的本地原子提交。push、创建 PR、merge、删除分支和任何强制推送必须分别获得明确授权。
状态机
按以下顺序推进：
uninitialized → baseline-review|ready → drafting-spec → drafting-plan → implementing → verifying → ready-to-archive → ready-to-push
- 老项目必须在
baseline-review获得“批准基线”。 approve spec对proposal.md、spec.md、design.md建立内容哈希。approve plan对plan.md、test-plan.md建立内容哈希。- 获批文件变化时，使该批准及下游批准失效并停止实施。
- 把任务进度写入
state.json/status.md，不要修改已获批的计划文档。
使用门禁脚本
wu5_flow.py init
wu5_flow.py new <slug> --type <type> --mode <full|light|hotfix>
wu5_flow.py status
wu5_flow.py approve <baseline|spec|plan|dependency|hotfix>
wu5_flow.py check <implement|commit|push|archive>
wu5_flow.py verify <targeted|affected|full>
wu5_flow.py archive <slug>
wu5_flow.py doctor
先暂存准备提交的文件，再运行 check commit。脚本只创建模板、维护公开状态、执行项目配置的质量命令并验证门禁；规格、设计、测试和审查结论必须由人和 AI 共同维护。
完成标准
- 当前需求均映射到测试，pytest 与 pyright 通过；项目已启用 ruff 时也必须通过。
- 完整变更完成规格符合性与代码质量两轮审查；高风险变更按审查规范调用独立代理。
- 已审查并确认没有引入不当 hardcode；合理的协议固有常量已命名、说明并测试。
verification.md包含命令、退出码、时间、内容指纹、两轮审查和遗留债务。features/已更新为当前有效行为，变更已归档，最终文档提交已创建。- PR 摘要链接规格、列出需求—测试映射、验证证据、风险与债务。