jw-coding-flow

识别用户目标、授权范围、已有设计及当前代码状态，从实际进度接入：

需求澄清 → jw-design → 设计确认 → jw-dev → jw-review → 交付
                                     └→ jw-testing（按需撰写转测文档）

阶段路由

• 目标、范围或关键方案未明确：使用 jw-design，形成可评审的方案。 用户只要求计划或设计时停在该阶段；进入实现必须符合用户已给出的授权。
• 已有确认方案或明确的开发任务：使用 jw-dev，执行实现、测试与开发记忆维护。 日常明确修复可以直接接入，不为齐全流程补造设计文档或批准记录。
• 进入检视：读取 jw-review。固定本地改动或已确认提交范围，核对需求与设计契约、 JiuwenSwarm 技术方向、模块 AGENTS/spec 与协议、基线到候选的行为差异、架构边界、跨端调用链、兼容性与测试证据，输出问题、覆盖范围与复查条件。
• 检视发现实现偏差回开发，发现方案缺口回设计；受影响的验证结论在修复后重新确认。
• 需要转测资料或整理测试报告时，使用 jw-testing，根据实际实现、 spec 与已有证据编写转测文档。该能力可从开发交接直接接入，文档撰写不代表实际执行测试或验收通过。
• 交付报告实际完成范围、测试结果、检视状态、遗留与后续动作；代码完成、测试通过、检视通过、 用户验收和已合并分别记录，不互相替代。

交接与持续记忆

设计交给开发：稳定设计标识、确认结论、范围、契约、验收场景、未决问题。 开发交给检视：实现范围、设计偏差、受影响 specs、测试证据与风险。 开发交给转测文档撰写：目标版本、实际范围、验证证据、执行环境、已知缺陷与待确认项。 转测文档状态由 jw-testing 独立管理，其本地输出不进入设计索引。 设计管理字段保留在设计中，评审按日期修订。设计是开发前方案资产，开发后的实际实施、 决策、偏差与验证结果归档至 features；开发计划引用设计管理字段，维护执行安排。 故障证据写入 bugfix，不向设计回填开发事实，不另造重复状态台账。 每阶段只读取所需 skill 与 reference，不把全部模板一次性载入。

决策与验证的交接规则

• 新建记录前按 决策归属与替代 查找已有维护位置，说明续写、新决策或局部/完全替代；不按提交数复制文档。
• 设计定义可观察验收条件；开发按 行为证据 核对模型/用户可见内容、真实入口和实际副作用。
• 检视与转测引用候选版本、适用范围和重验条件；候选、依赖或前提变化时只沿用已核实仍有效的证据。
• 有复用价值的修复按 防错模式提炼 更新所属模块规则/spec 并链接 bugfix，不把局部事故自动变成全仓禁令。

以上规则复用 design/spec/feature/bugfix 和已有交接记录，不新建全局状态台账或另设阶段。

上下文与影响分析按 因果流程与资料可信度 执行： 按任务选择模块、路径、关键符号和跨边界流程，核实旧资料版本并区分事实、推断与缺口。 交接分别说明已盘点、已理解、已检视、已验证的范围；验证后同步本次影响的既有资料，不要求先建库或补齐全仓。

实际文档在 .agents/agent-docs/，命名与存放遵循各阶段 skill。 提交、推送、PR、分支和 worktree 遵循仓库及用户约定；本流程不扩展授权。 不自动启动多代理，不运行格式化或静态检查。

文档元数据与索引

遵循 作者、设计关联与索引规则：受管文档以 frontmatter 标注 Git author，移除 owner；新 F 平铺在 features/，F/B 显式声明 designs。 写作/修改后自动运行文档同步工具刷新索引；检视只报告缺口，不改写待审资料。