feat(ack): refine intake and validation workflow

2026-08-04 10:52:37 +08:00
parent b9c82b5520
commit 5018a1801d
32 changed files with 1602 additions and 302 deletions
@@ -135,31 +135,40 @@ description: >-
   worker 启动规则。项目覆盖层优先于通用示例命令。按 scope 推荐相关 `active`
   知识，经确认后把固定 revision 的显式 `knowledgeRefs` 写入当前任务上下文；
   不全量注入知识库。
-   `project.bugIntake.workflow` 为 `reviewed-writeback-v1` 时，按
+   `project.bugIntake.workflow` 为 `clarified-writeback-v1`（推荐）或
+   `reviewed-writeback-v1`（兼容旧项目）时，按
   `references/feishu-bug-intake.md` 把飞书作为审核前的唯一协作区：先运行 check/plan，
-   读取用户填写的 Bug；Coordinator 根据来源事实与项目上下文补全修复逻辑和可观测验收
-   标准，只通过安全适配器写回同一飞书记录并回读确认。用户反馈后继续只在飞书修订。
-   用户针对当前 `draftRevision` 明确审核通过前，不创建或刷新 `tasks.yaml` 任务、不启动
-   worker、不派发 Developer/Test，也不修改应用代码。审核通过后重新读取，要求 revision
-   与批准值完全一致，才通过 `import-approved` 生成规范 `taskDraft`，原样写入最终版本、
+   读取用户填写的 Bug。新工作流中，用户只维护标题、详细描述和附件；Coordinator 根据
+   来源事实与项目上下文整理问题说明、期望效果和可观测验收标准，不在收件箱写修复逻辑，
+   只通过安全适配器写回同一飞书记录并回读确认。用户反馈后继续只在飞书修订。
+   用户针对当前 `draftRevision` 明确审核通过并亲自在飞书把状态改为 `已确认` 前，不创建
+   或刷新 `tasks.yaml` 任务、不启动 worker、不派发 Developer/Test，也不修改应用代码。
+   Coordinator 不得自行写入 `已确认`。审核通过后重新读取，要求 revision 与批准值完全
+   一致，才通过 `import-approved` 生成规范 `taskDraft`，原样写入最终版本、
   `source.workflow`、`source.approvedRevision` 与 `source.approvedPayloadHash`；校验器重算
-   payload hash 通过后才进入三角色闭环。未声明 workflow 的旧八字段配置只按
+   payload hash 通过后，再用 `mark-imported` 把最终任务 ID 与同一 revision 写回飞书，
+   才进入三角色闭环。未声明 workflow 的旧八字段配置只按
   `read-only-v1` 兼容，不得写回；
-   标题、实际表现和预期结果不可推断；整行空白记录按批次 warning 跳过。
+   标题、详细描述和附件是来源事实，不得把 Coordinator 推断伪装成用户原文；整行空白
+   记录按批次 warning 跳过。
   按每条记录的 `sourceRef` 去重：仅 `open` 任务可刷新描述；
   `dispatched`、`fixed_by_dev`、`retesting`、`failed_retest`、`verified`、`blocked` 和
   `leftover` 只报告来源漂移，绝不覆盖；来源消失或读取失败时绝不删除已有任务。
 4. 新需求先写产品文档、任务拆分与可观测验收信号，更新 `tasks.yaml` 并校验，
-   然后交给用户确认；若启用了交付，还要把本次 profile、目标、停止点和需要审批的
-   步骤放入同一份计划。确认前不派发实现，也不执行交付。
+   然后交给用户确认；若启用了交付，必须默认把 `defaultProfile`、目标、停止点和需要
+   审批的步骤放入同一份计划，不能静默省略。用户可明确取消本轮交付；确认前不派发
+   实现，也不执行交付。
 5. 创建或更换 worker 时，只使用
   `<ack-skill-dir>/scripts/launch_worker.py plan|launch` 读取
   `tasks.yaml.project.orchestration` 的 profile。不得直接执行
   `orca terminal create --command`，不得接受或拼接自由 command、额外 argv、
   executable、env 或 cwd。必须先审阅 `plan.launchFingerprint`，再把它作为
-   `launch --expected-launch-fingerprint` 传入。v0.10 不根据持久化 receipt 自动
-   复用旧终端；每次自动派发都创建 fresh worker，receipt 只作审计与 dispatch
-   关联。
+   `launch --expected-launch-fingerprint` 传入。派发前先寻找同一 ACK 运行内的空闲
+   worker；只有角色、profile、worktree 和启动身份仍完全匹配，且后端能清理历史消息、
+   返回可核对的新会话身份时才复用。不得复用正在工作、等待回报或状态不明的 worker；
+   任一条件不符、清理能力不存在或无法确认清理成功时创建 fresh worker。持久化
+   receipt 只作审计与 dispatch 关联，不能单独授权复用。当前 Orca 终端接口不能提供
+   可验证的历史消息清理，因此使用 Orca 时仍走 fresh worker。
 6. 用户已确认的任务按 ACK 闭环执行：Developer 实现与白盒验证，Test 独立黑盒
   复测，Coordinator 读取证据终检并唯一写入 `tasks.yaml`。Developer 回报
   `knowledgeApplied` 和 `knowledgeCandidates`，Test 回报 `knowledgeChecks`；
@@ -168,15 +177,27 @@ description: >-
   `<ack-skill-dir>/scripts/run_verification.py docs/ack/knowledge.yaml
   <verification-ref> --project-root <project-root>`。不要直接执行选择器返回的 path/args，
   也不要给 runner 注入额外命令或参数。
-8. 不把 `worker_done` 或 Test 自报成功直接当作完成。每项最多三轮，仍失败则记录
-   `leftover` 并继续其它任务。
+8. 不把 `worker_done` 或 Test 自报成功直接当作完成。三轮预算只计算 Test 已对齐正确
+   服务、数据和工具后实际执行验收所得的产品失败；环境失败不占复验轮次，不写
+   `failed_retest`，而写入 `dispatch.environmentIncidents`。Coordinator 先做一次有界、
+   安全的恢复；事件未解决、需要用户动作或会阻断本轮时，立即向用户报告原因、影响、
+   已尝试动作、下一恢复动作和明确的 `userAction`；即使已自动恢复，也要在最终报告汇总。
+   每项最多三轮有效产品复验，仍失败才记录 `leftover` 并继续其它任务。细则见
+   `references/optimization-method.md` §4。
 9. 关键的安全、正确性和兼容性约束应下沉为测试、lint、CI 或正式规范；
   `knowledge.yaml` 只保存触发条件、原因与证据引用，不能替代可执行控制。
 10. 选定任务全部进入 `verified` 后，若 `delivery.enabled: true` 且用户确认的本次计划
    包含交付，按 `references/delivery.md` 顺序执行 profile，并由 Coordinator 把证据
    写入 `tasks.yaml.deliveryRuns`。任务状态保持 `verified`；交付失败只改变 delivery
-    run，不回写成任务失败。默认 profile 最多到 `review_ready`，稳定发布和生产部署
-    必须在对应步骤再次取得明确批准。
+    run，不回写成任务失败。开发或测试环境完成构建、部署和健康检查后写
+    `validation_ready`，并把访问地址、验证范围和用户下一步交给用户；不能停在
+    `verified` 却声称整轮 ACK 已结束。默认 profile 最多到 `validation_ready` 或
+    `review_ready`，稳定发布和生产部署必须在对应步骤再次取得明确批准。
+11. Coordinator 最后标记整轮任务完成后，回收所有只属于 `verified` 任务的 worker
+    终端，并核对关闭回执；历史 receipt 和任务证据继续保留。任何还被 `open`、
+    `dispatched`、`fixed_by_dev`、`retesting`、`blocked`、`failed_retest`、`leftover`
+    或未解决环境事件引用的终端都保留，不设置 TTL，也不能因为同一终端还关联过
+    `verified` 任务而误关。若关闭结果不确定，记录并报告，不重复关闭或伪报已回收。

 ## 交付配置维护

@@ -200,7 +221,7 @@ description: >-
 - 不把 full-access、bypass、YOLO/force、关闭 sandbox 或项目内“授权”字段当成
  v0.10 自动 worker 的合法配置；当前一律 fail closed。
 - 不把无密钥 `receiptHash` 或 Orca live metadata 当作旧终端的启动 attestation；
-  v0.10 不自动复用既有 worker。
+  没有可信空闲状态、配置匹配和历史消息清理证明时不复用既有 worker。
 - launcher 返回 `indeterminate` 或 `reconcile required` 时，不直接重试；先按
  launch ID、外部 record 和 Orca live state 完成人工核对。
 - 不覆盖已有 `docs/ack` 文件；除用户确认的 ACK 任务或 delivery profile 外，不擅自