Dwf Coding

dwf-coding

本技能用于单独执行 DWF 工作流的「编码执行」阶段。它只负责把已确认的方案和实现清单落到目标代码目录，不负责生成需求文档、设计稿、需求分析、技术方案或实现清单。

1. 只处理编码执行。 默认只读取或更新目标代码目录、目标 spec 目录下 05-实现清单/实现清单.md、必要的项目代码文件，以及工作流模式下的 .dwf/state.json。不要主动创建或重写 01-需求/、02-设计稿/、03-需求分析/、04-技术方案/ 或 05-实现清单/ 的主体内容，除非用户明确要求先回到对应阶段。

2. 目标代码目录与目标 spec 目录由运行模式决定。

   • 工作流模式：读取 .dwf/state.json，在 specs 数组中找 status: "active" 且 current_step 为 code 的 spec。目标 spec 目录为 .dwf/specs/{spec.name}/，目标代码目录为工作区根目录（dwf-orchestrator 的约定：代码不放 spec 目录内、统一放根目录）。若 shared_ref 非空，可读取 .dwf/specs/{shared_ref}/01-需求/、/02-设计稿/ 作为只读上下文。
   • 独立模式：用 question 询问用户目标 spec 目录（含实现清单与技术方案）与目标代码目录，spec 目录默认提议 .dwf/specs/{今日日期}-{seq}-feat-{描述}，其中 seq 扫描 .dwf/specs/ 现有 spec 目录名中的最大序号 +1（无则 001），代码目录默认提议工作区当前目录，由用户确认或修改。

3. 编码前必须读取依据。 执行任何代码修改前，必须先读取目标 spec 目录下 05-实现清单/实现清单.md、04-技术方案/技术方案.md（如果存在）、本技能目录下 references/coding_standards.md、项目级 .dwf/coding-specs/ 下已确认的编程规范（如果存在），并检查目标代码目录的现有结构。若缺少实现清单或技术方案不足以执行，先说明缺口并请求用户补充或回到 dwf-development。

4. 检测运行模式。 每次触发后都要检查 .dwf/state.json，找到 status: "active" 且 current_step 为 code 的 spec。

   • 找到则按工作流模式执行编码，完成后把该 spec 从 specs 队列移除、追加到 completed_specs、递增 iteration_count（由 dwf-orchestrator 收尾；本技能也可代为更新 state.json 与 _meta.json）。
   • 未找到满足条件的 active spec 时按独立模式执行，不创建 .dwf/state.json，不推进完整工作流状态。

5. 编码前必须完成编程范式约定。 进入「执行编码」前，必须先就编程范式与用户达成一致，并把结果落到项目级 .dwf/coding-specs/（与所有 spec/迭代共享，不放 spec 目录内）：

   • 检查 .dwf/coding-specs/ 下是否已有覆盖当前技术栈的 *.md（如 前端编程规范.md、后端编程规范.md、移动端编程规范.md）。
   • 已存在 → 用 question 向用户确认是否沿用；用户可能要修改，修改时按"不存在"流程协商修订并更新该文件。沿用则跳过生成。
   • 不存在 → 从 04-技术方案/技术方案.md 探测本次涉及的端（前端/后端/移动端等），用 question 与用户确认要生成哪几份规范；逐份协商（第三方库选型、组件/模块拆分、是否使用 TypeScript、状态管理、样式体系、目录结构、命名约定、接口封装、测试方式等），写入 .dwf/coding-specs/{端}编程规范.md，并用 question 逐份确认。
   • .dwf/coding-specs/*.md 补充本技能目录下 references/coding_standards.md 的通用基线，冲突时以项目级规范为准；两者都读。
   • 未获得用户确认前，不进入「执行编码」，不修改任何项目代码。

6. 不绕过确认边界。 如果实现清单仍未确认、spec 的 current_step 不是 code、编程范式约定未完成、或发现需求/方案/清单互相冲突，必须暂停并说明原因，不要擅自编码。

7. 逐项执行与逐项标记。 严格按实现清单顺序执行任务。每完成一项，依据该任务的"编码规范检查"和"验证标准"核对结果，再把对应任务从 [ ] 标记为 [x]（写入目标 spec 目录下 05-实现清单/实现清单.md）。不要一次性把未验证的任务全部标记完成。

8. 变更范围受控。 只修改完成当前任务所必需的文件。工作流模式下，只实施本次确认的受影响范围；不要顺手重构无关模块、替换架构或扩大需求。

9. 全程使用中文。 除非用户明确要求使用其他语言，所有与用户的交互、技能说明、生成的文档、测试记录、审计结论和产物说明都必须使用中文。代码、文件路径、命令、API 名、技术术语、第三方库名和用户提供的原文内容可以保留英文。

触发后流程

1. 探查上下文

• 检查 .dwf/state.json 是否存在，读取 specs 数组与每项的 current_step/selected_plan/shared_ref/updated_at。
• 找到 status: "active" 且 current_step: "code" 的 spec 后，目标 spec 目录为 .dwf/specs/{spec.name}/，目标代码目录默认为工作区根目录。若 shared_ref 非空，可读取其 01-需求/、02-设计稿/ 作为只读上下文。
• 读取目标 spec 目录下 05-实现清单/实现清单.md，识别未完成任务、任务顺序、验证标准和阻塞项。
• 读取目标 spec 目录下 04-技术方案/技术方案.md；如果 selected_plan 有值，以选定方案为主。
• 读取本技能目录下 references/coding_standards.md；若该文件缺失，则遵循现有项目规范和用户提供的编码约束。
• 检查项目级 .dwf/coding-specs/ 下是否已有已确认的编程规范（如 前端编程规范.md、后端编程规范.md、移动端编程规范.md）；若有，作为本次编码的项目级约定。
• 检查目标代码目录是否已有项目代码，并分析框架、目录结构、命名、样式、测试和构建方式。

2. 判断运行模式

独立模式

满足任一条件即为独立模式：

• .dwf/state.json 不存在。
• .dwf/state.json 存在，但 specs 中不存在 status: "active" 且 current_step: "code" 的 spec。
• 用户明确要求“只执行编码，不推进工作流状态”。

独立模式下：

• 用 question 询问用户目标 spec 目录（含实现清单与技术方案）与目标代码目录，给出默认提议（spec 目录默认 .dwf/specs/{今日日期}-{seq}-feat-{描述}，seq 扫描 .dwf/specs/ 现有 spec 目录名中的最大序号 +1，无则 001；代码目录默认工作区当前目录），由用户确认或修改。
• 只在目标代码目录和目标 spec 目录下的实现清单中执行编码与任务标记。
• 不创建 .dwf/state.json。
• 完成后总结改动、验证结果和剩余任务。

工作流模式

满足以下条件时进入工作流模式：

• .dwf/state.json 存在，specs 中存在 status: "active" 且 current_step: "code" 的 spec，且 confirmed_stages 含所有受影响文档阶段。

工作流模式下：

• 按 dwf-orchestrator 的 code 阶段执行。目标代码目录为工作区根目录。
• 每完成任务都更新目标 spec 目录下 05-实现清单/实现清单.md 的任务勾选。
• 所有任务完成后更新 .dwf/state.json：把该 spec 从 specs 移除、追加到 completed_specs（含 completed_at），递增 iteration_count，更新 updated_at；同步该 spec 的 _meta.json 为 status: "done"、completed_at。然后由 dwf-orchestrator 用 question 询问下一个 spec 是否继续。

3. 编程范式约定

进入编码前，先与用户确认本次编程范式，并把结果落到项目级 .dwf/coding-specs/。该目录与所有 spec/迭代共享，编程规范不随迭代重复协商。

1. 检查 .dwf/coding-specs/ 下已有的 *.md（如 前端编程规范.md、后端编程规范.md、移动端编程规范.md）。
2. 读取 04-技术方案/技术方案.md，探测本次涉及的端（前端/后端/移动端等）和技术栈。
3. 已有覆盖当前技术栈的规范：
   • 用 question 向用户确认是否沿用现有规范（用户可能要修改）。
   • 沿用 → 跳过生成，直接进入「执行编码」。
   • 要修改 → 按下列"无规范"流程协商修订，并更新对应文件。
4. 不存在或需要新建：
   • 用 question 与用户确认要生成哪几份规范（按涉及的端，通常 前端编程规范.md、后端编程规范.md 等）。
   • 逐份协商关键范式：第三方库选型、组件/模块拆分方式、是否使用 TypeScript、状态管理方案、样式体系、目录结构、命名约定、接口封装、测试方式等。
   • 把协商结果写入 .dwf/coding-specs/{端}编程规范.md，并用 question 逐份请用户确认。
5. .dwf/coding-specs/*.md 补充 references/coding_standards.md 的通用基线；冲突时以项目级规范为准。
6. 全部规范确认后，才进入「执行编码」。用户未确认前，不修改任何项目代码。

4. 执行编码

1. 从实现清单中选择第一个未完成且未阻塞的任务。
2. 读取任务涉及的文件（位于目标代码目录）；如果文件不存在，先确认它是否应按技术方案创建。
3. 按项目现有模式实施最小必要改动。
4. 对照任务中的编码规范检查和验证标准进行自检。
5. 运行相关验证命令，例如 lint、typecheck、test、build；若无法运行，说明原因并记录替代检查。
6. 将已验证完成的任务标记为 [x]（写入目标 spec 目录下 05-实现清单/实现清单.md）。
7. 继续下一个任务，直到清单完成或遇到阻塞。

5. 处理模板和新项目

如果目标代码目录为空，并且技术方案明确选择基于本技能 assets/ 中的 React 模板：

• PC 端优先使用本技能目录下 assets/react-pc/。
• 移动端优先使用本技能目录下 assets/react-mobile/。
• 通用配置、hooks、utils、请求封装等可参考或合并本技能目录下 assets/shared/。
• 只复制与目标端和选定方案匹配的内容，不复制无关端模板，不把 dist/ 当作源代码继续开发。

如果模板、技术方案和需求存在冲突，暂停并向用户说明冲突点。

6. 阻塞处理

出现以下情况时必须暂停：

• 缺少目标 spec 目录下 05-实现清单/实现清单.md。
• 实现清单没有明确任务、验证标准或依赖顺序。
• 技术方案缺失且无法判断架构或选型。
• spec 的 current_step 显示仍处于 requirements、design、breakdown、plans 或 todos。
• 编程范式约定未完成（.dwf/coding-specs/ 下覆盖当前技术栈的规范缺失或未经用户确认）。
• 编码过程中发现需求、方案或实现清单已经失效。

暂停时说明：缺少什么、为什么不能继续、建议用户进入哪个技能或阶段补齐。

完成前检查

结束前确认：

• 已读取实现清单、技术方案、编码规范（references/coding_standards.md 与 .dwf/coding-specs/*.md）和现有代码结构。
• 编程范式约定已完成：.dwf/coding-specs/ 下覆盖当前技术栈的规范已存在并经用户确认，或本次已协商生成并确认。
• 已按任务顺序执行，且只标记已验证完成的任务（勾选写入目标 spec 目录下实现清单）。
• 已运行可用的验证命令，或说明无法运行的原因。
• 独立模式下没有创建或推进 .dwf/state.json。
• 工作流模式下只在任务全部完成后更新 state.json（spec 移入 completed_specs、递增 iteration_count）与该 spec 的 _meta.json（status=done）。
• 总结中列出完成任务、主要修改文件、验证结果、未完成事项或阻塞点。