Vibecoding 工作流 v3（内嵌 prd-authoring PRD 标准）
先选执行模式
开始项目或恢复项目时，先读取项目根目录的 .vibecoding/state.md；没有则创建。向用户确认执行模式：
| 模式 | 必须确认的节点 | 适用情况 |
|---|---|---|
strict |
每个阶段产物、L3、合并、发布 | 新项目、高风险项目 |
balanced（默认） |
阶段完成、L3、合并、发布 | 常规个人项目 |
fast |
L3、生产/公网、不可逆操作 | 已有成熟规范的低风险迭代 |
无论模式如何，下列操作必须取得明确确认：改变需求/权限/API 契约的 L3 变更、生产数据迁移、合并 PR、对外发布或仓库转公开。不得把“未回复”当作确认。
全局不可变规则
- 需求、设计、实现、测试和发布必须可追溯；以
FR-*/NFR-*为稳定需求 ID。 - 修改前判定 L1/L2/L3，依据
references/change-classification.md。无法判定时按 L2；涉及范围、权限、外部契约或核心流程时按 L3。 - L3 先更新文档并确认，再编码；L2 在同一 PR 内回写；L1 只需在 PR 的“文档影响”字段说明。
- 质量门禁以脚本和 CI 结果为准，不能仅凭口头声明通过。
- 任何阶段发现前提不成立、风险超出已确认范围或文档冲突，暂停并向用户说明影响与选项。
项目状态文件
.vibecoding/state.md 至少记录：当前阶段、执行模式、已确认的产物版本、未决决策、当前里程碑、已完成/阻塞 Issue、最近一次质量门禁结果。每次阶段或发布门禁结束后更新它。
阶段路由
只读取当前阶段及其下一阶段所需的参考文件，不要一次性加载所有流程细节。
| 阶段 | 入口条件 | 必读资料 | 交付与自动门禁 |
|---|---|---|---|
| 1 需求与 PRD | 有产品想法 | phase-1-4.md、prd-template.md，写作时渐进式加载 prd-authoring-standards.md |
PRD 按九段式含 FR/NFR ID，过质量门禁清单；validate_docs.py |
| 2 技术设计 | PRD 确认 | phase-1-4.md、SPEC 模板 |
OpenAPI 与 SPEC；文档校验 |
| 3 原型与 UI | SPEC 确认 | phase-1-4.md、UI 模板 |
原型、Token、状态矩阵 |
| 4 计划与拆解 | 设计确认 | phase-1-4.md、追溯模板、测试策略 |
追溯矩阵和 Issue 校验 |
| 5 开发与集成 | Issue 已计划 | phase-5-development.md、变更分级、测试策略 |
lint/type/test/文档/追溯 CI |
| 6 验收 | 迭代收口 | phase-6-8.md、测试模板 |
staging 验收报告 |
| 7 维护 | 已验收版本 | phase-6-8.md |
漂移检查、技术债计划 |
| 8 发布 | 用户要求发布 | phase-6-8.md、发布规范 |
安全、版本、回滚门禁 |
> 渐进式加载：阶段资料只在到达该阶段时才读取，不一次性载入全部流程细节。阶段一进入"编写 PRD"步骤时，除 prd-template.md 外再加载 prd-authoring-standards.md（九段式内容规范 + 质量门禁清单 + Gherkin/字典/偏差映射），写完对照其 §7 清单自检后定稿；后续阶段不再持有该文件，避免上下文膨胀。
自动质量门禁
初始化项目时复制 references/github/quality-gates.yml 为 .github/workflows/quality-gates.yml，并在仓库根目录运行：
python scripts/validate_docs.py docs
python scripts/validate_traceability.py docs
python scripts/validate_issue.py docs/issues
脚本返回非零即为阻断项。若项目未使用对应目录，CI 会跳过该项；一旦目录存在，内容必须有效。任何豁免必须写进 .vibecoding/waivers.md，注明规则、原因、负责人、到期日，并经用户确认。
任务并行规则
依赖图用于找出可并行任务。一个 Agent 默认只占用一个 Issue；多个 Agent 或开发者可并行处理满足以下全部条件的 Issue：
- 前置依赖均已完成，且不改同一文件/迁移/接口契约；
- 每个 Issue 有独立分支、验收标准、需求 ID 和测试责任；
- 共享契约先通过专门的契约 Issue 合并；
- 合并按依赖拓扑顺序，集成 Issue 负责 T2/T3，不允许各自宣称“整体已验收”。
若存在文件、数据库、OpenAPI 或 UI Token 冲突，改为串行或先拆出公共前置 Issue。详见 references/phase-5-development.md。
文档与版本规则
草稿讨论可连续修改；在一次评审确认、PR 合并、L2/L3 回写或发布时，才新增一条修订记录。版本采用 v主.次：影响范围/契约/架构为主版本，其余已确认变更为次版本。不要为拼写修正单独升版本；可和同一变更单元合并记录。详见 references/document-governance.md。
启动与恢复
- 确认项目目标、当前阶段和执行模式。
- 读取状态文件及当前阶段资料；缺失产物先补齐最小版本。
- 说明本轮输入、产出、风险和下一门禁，再开始执行。
- 通过门禁后更新状态文件；仅在所选模式要求时等待确认。
