fix(native): pass recovery context to verifier

Author: benym

assets/skills-zh/comet-native/SKILL.md

@@ -79,7 +79,7 @@ Build 和 Verify 组成一个有界验收循环（Loop）：Builder 提交候选
 
 ## Verify
 
-Runtime 要求启动 Verifier（`dispatch-verifier`）时，先把当前候选需要运行的测试和检查命令填入 `inputOptions.template`，由 Runtime 统一执行。Runtime 会复用已经完成的检查；是否重试或补充检查，以最新 `continuation` 为准。`verifierDispatch` 携带工作区与证据位置、`scopeIds`、数量、brief/Spec 引用、详情分页参数、复核摘要和检查结果，不直接携带全部验收文字。按详情分页参数读取覆盖 `scopeIds` 的验收场景后，立即启动一个新的只读 Verifier subagent，并原样传递工作区与证据定位信息。subagent 不可用时，只有选择多会话协作且平台可以管理独立会话，才启动与 Builder 分开的独立 Agent 会话；其他情况按命令参考报告 Verifier 不可用，并执行最新 `continuation`。
+Runtime 要求启动 Verifier（`dispatch-verifier`）时，先把当前候选需要运行的测试和检查命令填入 `inputOptions.template`，由 Runtime 统一执行。Runtime 会复用已经完成的检查；是否重试或补充检查，以最新 `continuation` 为准。`verifierDispatch` 携带工作区与证据位置、`scopeIds`、数量、brief/Spec 引用、详情分页参数、复核摘要和检查结果，不直接携带全部验收文字；如果存在 `recoveryContext`，也要原样传给 Verifier，作为最近一次恢复或用户补充的上下文。按详情分页参数读取覆盖 `scopeIds` 的验收场景后，立即启动一个新的只读 Verifier subagent，并原样传递工作区与证据定位信息。subagent 不可用时，只有选择多会话协作且平台可以管理独立会话，才启动与 Builder 分开的独立 Agent 会话；其他情况按命令参考报告 Verifier 不可用，并执行最新 `continuation`。
 Verifier 先读取当前 `scopeIds` 对应的验收场景、brief、完整目标 Spec、实际实现和 Runtime 检查结果，最后再把 Builder 交接摘要当作调查线索，保持验收判断独立。Verifier 保持只读。如果现有检查不足，就在 Runtime 返回的 `inputOptions.template` 中列出还需要运行哪些检查，由 Runtime 执行并把结果返回给 Verifier。
 Verifier 必须把当前 `scopeIds` 中的每个场景恰好标记一次为通过（`passed`）、未通过（`failed`）或暂时无法验证（`blocked`）。修复范围通过后，Runtime 保留已完成检查并准备一次覆盖全部验收场景的新 Verifier；只有这次最终全量验证通过，才允许进入 Archive。未通过或无法验证时，写出下一轮 Build 可直接处理的原因。无法启动 Verifier、Verifier 执行出错或缺少外部信息时，按命令参考和最新 `continuation` 处理。由 Skill 启动的最终 Verifier 通过且 Runtime 等待用户决策时，只有用户接受当前结果才用 `--accept-result` 进入 Archive；如果用户要求修改实现或验收标准，分别使用 `--revise-implementation` 或 `--revise-requirements`。
 完成标准：Runtime 已接受完整的 Verifier 结果，并明确进入 Build、Archive、等待用户（`await-user`）、阻塞（`blocked`）或完成（`done`）中的一种状态。

assets/skills-zh/comet-native/reference/commands.md

@@ -18,12 +18,12 @@ comet native <group> <command> --help
 - `workspace` / `preparation`：实际工作目录和 change 创建结果；
 - `stateVersion` / `loop`：当前状态版本和验收循环进度；
 - `acceptance` / `childSummary` / `readyChildren` / `supervisor` / `details.nextPageArgs`：验收计数、Supervisor Change 的子任务计数、当前可执行子任务、集成分支与当前任务包摘要，以及详情下一页命令；
-- `verifierDispatch`：启动独立 Verifier 所需的工作区与证据位置、当前 `scopeIds`、数量、正文引用、详情分页参数、复核摘要和检查结果；
+- `verifierDispatch`：启动独立 Verifier 所需的工作区与证据位置、当前 `scopeIds`、数量、正文引用、详情分页参数、复核摘要和检查结果；如果存在 `recoveryContext`，也要把它作为最近一次恢复或用户补充的信息直接传给 Verifier；
 - `workspaceFinishResult` / `recoveryArgs`：归档后的工作区收尾结果和恢复命令。
 
 模板中的尖括号表示需要填写的值。`await-user` 表示先等待用户决定，此时不执行推进命令。若 `commandArgs` 为 `null` 且返回了 `commandAlternatives`，先确认用户决定，再执行对应备选操作的完整 `commandArgs`，保留其中的 `--expected-state-version` 和 `--expected-action`。命令因状态过期或动作不匹配失败时，重新读取最新 `continuation`，按当前状态继续；不要自行拼接不带 guard 的命令。`localExecution: absent` 只表示这台机器当前没有正在运行的执行任务，不代表 change 已损坏。
 
-启动 Verifier 时原样传递 `verifierDispatch` 的定位信息：`projectRoot` 是运行 Native 命令的控制目录；`verificationRoot` 是验收实现的工作区，Supervisor 父级使用集成工作区；`changeDir` 是 `briefRef` 和 `specRefs[].ref` 的相对路径基准；`supervisorStateRef` 指向包含子任务验收与集成证据的本机状态，普通 change 为 `null`。`detailsPageArgs` 已包含 `--project-root`，从任何工作目录查询都应保留它。追加检查后，把返回的检查结果和交接信息交回当前 Verifier，继续等待最终结果。
+启动 Verifier 时原样传递 `verifierDispatch` 的定位信息：`projectRoot` 是运行 Native 命令的控制目录；`verificationRoot` 是验收实现的工作区，Supervisor 父级使用集成工作区；`changeDir` 是 `briefRef` 和 `specRefs[].ref` 的相对路径基准；`supervisorStateRef` 指向包含子任务验收与集成证据的本机状态，普通 change 为 `null`。如果存在 `recoveryContext`，也要原样交给 Verifier，作为最近一次恢复或用户补充的上下文。`detailsPageArgs` 已包含 `--project-root`，从任何工作目录查询都应保留它。追加检查后，把返回的检查结果和交接信息交回当前 Verifier，继续等待最终结果。
 
 ## 填写命令输入
 

assets/skills/comet-native/SKILL.md

@@ -79,7 +79,7 @@ Completion criterion: the implementation and relevant checks are ready for verif
 
 ## Verify
 
-When Runtime requests `dispatch-verifier`, fill `inputOptions.template` with the tests and check commands needed for the current candidate, then let Runtime execute them. Runtime reuses completed checks; follow the latest `continuation` for retries or additions. `verifierDispatch` carries workspace and evidence locations, `scopeIds`, counts, brief/Spec refs, detail-page args, the review summary, and check results instead of all acceptance text. Read detail pages covering `scopeIds`, then immediately start a fresh read-only Verifier subagent and pass the workspace and evidence locations through unchanged. If subagents are unavailable, start an independent Agent session separate from the Builder only when multi-session coordination was selected and the platform can manage independent sessions; otherwise report the Verifier as unavailable through the command reference and follow the latest `continuation`.
+When Runtime requests `dispatch-verifier`, fill `inputOptions.template` with the tests and check commands needed for the current candidate, then let Runtime execute them. Runtime reuses completed checks; follow the latest `continuation` for retries or additions. `verifierDispatch` carries workspace and evidence locations, `scopeIds`, counts, brief/Spec refs, detail-page args, the review summary, and check results instead of all acceptance text. When present, pass `recoveryContext` unchanged to the Verifier as the latest recovery or user-provided context. Read detail pages covering `scopeIds`, then immediately start a fresh read-only Verifier subagent and pass the workspace and evidence locations through unchanged. If subagents are unavailable, start an independent Agent session separate from the Builder only when multi-session coordination was selected and the platform can manage independent sessions; otherwise report the Verifier as unavailable through the command reference and follow the latest `continuation`.
 The Verifier first reads acceptance scenarios for the current `scopeIds`, the brief, complete target Specs, actual implementation, and Runtime check results. It reads the Builder handoff last as an investigation lead so the judgment remains independent. The Verifier remains read-only. If existing checks are insufficient, list additional checks in Runtime `inputOptions.template`; Runtime executes them and returns the results.
 The Verifier must mark every scenario in the current `scopeIds` exactly once as `passed`, `failed`, or `blocked`. After a repair scope passes, Runtime retains completed checks and prepares a fresh Verifier covering every acceptance scenario; Archive is allowed only after this final full verification passes. For a failed or blocked item, provide a reason the next Build round can act on directly. If the Verifier cannot start, execution fails, or external information is missing, follow the command reference and latest `continuation`. When the final Skill-started Verifier passes and Runtime waits for the user, use `--accept-result` to enter Archive only after the user accepts; otherwise use `--revise-implementation` or `--revise-requirements`.
 Completion criterion: Runtime has accepted the complete Verifier result and explicitly entered Build, Archive, `await-user`, `blocked`, or `done`.

assets/skills/comet-native/reference/commands.md

@@ -18,12 +18,12 @@ comet native <group> <command> --help
 - `workspace` / `preparation`: the actual working directory and change-creation result.
 - `stateVersion` / `loop`: the current state version and acceptance Loop progress.
 - `acceptance` / `childSummary` / `readyChildren` / `supervisor` / `details.nextPageArgs`: acceptance counts, Supervisor Change child counts, currently ready children, the integration branch and current task-package summary, and the next detail-page command.
-- `verifierDispatch`: workspace and evidence locations, current `scopeIds`, counts, content refs, detail-page args, review summary, and check results needed to start an independent Verifier.
+- `verifierDispatch`: workspace and evidence locations, current `scopeIds`, counts, content refs, detail-page args, review summary, and check results needed to start an independent Verifier; when present, `recoveryContext` is the latest recovery or user-provided context and must be passed directly to the Verifier.
 - `workspaceFinishResult` / `recoveryArgs`: the post-Archive workspace result and recovery command.
 
 Angle brackets in a template mark values to fill in. `await-user` means wait for the user's decision before running an advancing command. If `commandArgs` is `null` and `commandAlternatives` is present, confirm the user's decision, then execute the selected alternative's complete `commandArgs` while preserving `--expected-state-version` and `--expected-action`. If the command fails because the state or action binding is stale, reread the latest `continuation` and continue from the current state; do not construct an unguarded replacement command. `localExecution: absent` means only that this machine has no currently running local task; it does not mean the change is damaged.
 
-When starting a Verifier, pass the location fields in `verifierDispatch` unchanged: `projectRoot` is the control directory used to run Native commands; `verificationRoot` is the workspace containing the implementation under verification, and a Supervisor parent uses the integration worktree; `changeDir` is the relative-path base for `briefRef` and `specRefs[].ref`; `supervisorStateRef` points to local state containing child verification and integration evidence, and is `null` for an ordinary change. `detailsPageArgs` already includes `--project-root`; preserve it when querying from any working directory. After requesting additional checks, return their results and the handoff information to the same Verifier and continue waiting for its final result.
+When starting a Verifier, pass the location fields in `verifierDispatch` unchanged: `projectRoot` is the control directory used to run Native commands; `verificationRoot` is the workspace containing the implementation under verification, and a Supervisor parent uses the integration worktree; `changeDir` is the relative-path base for `briefRef` and `specRefs[].ref`; `supervisorStateRef` points to local state containing child verification and integration evidence, and is `null` for an ordinary change. When present, pass `recoveryContext` unchanged as the latest recovery or user-provided context. `detailsPageArgs` already includes `--project-root`; preserve it when querying from any working directory. After requesting additional checks, return their results and the handoff information to the same Verifier and continue waiting for its final result.
 
 ## Fill command input