PABCD 工作流 默认启用

P — 计划 需要用户批准

计划阶段读取项目文档和开发技能，然后生成包含两部分的计划：

• 第一部分 — 通俗解释： 将要构建什么，用非开发人员的语言描述。任何人都应该能理解。
• 第二部分 — Diff 级精度： 精确的文件路径（NEW / MODIFY / DELETE），MODIFY 的前后对比差异，NEW 的完整内容。

范围澄清

如果请求的范围不明确或技术方案未指定，计划阶段会先进行澄清：

• 以 <TechName> -- <通俗解释> 的格式提供 2-3 个选项
• 根据项目具体情况推荐其中一个
• 确认一次后继续执行

仓库扫描（大范围变更）

对于大范围变更或不熟悉的仓库，P 阶段必须包含：

• 当前仓库结构的紧凑树形图
• 检测到的仓库约定：文档、计划、架构说明、真实来源日志、命名规范、测试
• 是否已读取现有的 structure/、devlog/、docs/、plans/ 或等效日志，以及是否会复用
• 是否建议创建 structure/ 或 devlog/

开发日志命名约定

如果 PABCD 工作创建或更新了 devlog/ 计划产物，计划中必须列出精确的 Jawdev 编号文件名：

00_overview.md
01_phase1_<slug>.md
02_phase2_<slug>.md

裸文件名如 PLAN.md、DIFF_PLAN.md、PHASES.md、RCA.md 或 plan.md 不允许作为新的开发日志阶段文件。

关卡问题

在展示计划之前，计划阶段会询问：

1. "有没有我不应该独自决定的业务逻辑？"
2. "第一部分是否符合您的意图？"

计划会被展示，并根据反馈进行修改。当用户批准后，使用 cli-jaw orchestrate A 进行状态转换。

A — 计划审计 需要用户批准

系统会生成一个 Worker 来审计计划（不是代码）。Worker 验证以下内容：

• 计划中的所有文件路径和导入是否实际存在
• 函数签名是否与实际代码匹配
• 是否存在集成风险
• 现有的真实来源文档/日志是否已被读取
• 未经用户批准不得引入新的 structure/、devlog/、文档或 AGENTS 文件
• 新的 JS/TS 文件遵循 TypeScript 优先规则，除非计划中说明了为什么需要使用 JS
• 新的 TypeScript 代码兼容严格模式，或已说明限制
• 新的开发日志阶段文档使用编号的 Jawdev 文件名约定

Worker 输出审计的 JSON 结果。审查结果：

• FAIL → 修复计划，重新审计
• PASS → 向用户报告结果

当用户批准后，使用 cli-jaw orchestrate B 进行状态转换。

B — 构建 需要用户批准

实现阶段。Boss 直接编写所有代码。Worker 仅作为只读验证者。

实现完成后，会派遣一个 Worker 进行验证 — 检查代码是否存在以及是否能顺利集成：

• NEEDS_FIX → Boss 修复问题，重新验证
• DONE → 向用户报告结果

除非在 P 阶段已批准或用户明确要求，否则不创建 structure/ 或 devlog/。

当用户批准后，使用 cli-jaw orchestrate C 进行状态转换。

C — 检查 自动推进

自动运行的最终完整性检查：

1. 验证所有文件已保存且一致
2. 运行 npx tsc --noEmit（如果是 TypeScript 项目）
3. 如适用，更新项目结构文档
4. 报告完成摘要

完成后，通过 cli-jaw orchestrate D 自动转换到 D 阶段。

D — 完成 自动推进

总结整个 PABCD 流程：

• 计划了什么（P）、审计了什么（A）、构建了什么（B）、检查了什么（C）
• 变更文件列表
• 后续待办事项

状态自动返回 IDLE。