workflow_deferred_verification

道-方法 · 道层 skill 全文

本页是 <code>rules/skills/drafts/workflow_deferred_verification.md</code> 的逐字投影（仅隐私清洗，零改写）。

name: workflow_deferred_verification
description: 给一个交给正在运行的 session 异步执行、完成状态没法当场核验的任务，先标记「运行中、待核验」，归类与时序当场决定、完成裁决延后；运行结束后用独立的额外检查机制（路由 session 审计）回填核验，核验通过才进 done。用于：有 session 任务正在跑、状态要等跑完再更新、需要一个「未跑完」标记 + 后续核验的场合。
status: draft (Beta) — 2026-06-05 段B V-07/T681 新建；晋级条件 = 对 ≥1 个真实运行 session 的任务实际走通「标记 awaiting_verify → 运行结束 → 回填核验」状态机、过 deferred_verification_gate、并被 GS-02 记录使用，再考虑摘 Beta
tier: 道

运行中任务的延后核验：先标记未跑完，跑完再回填核验

状态

Draft（Beta）。来源需求 V-07/T681（逐字原文见 adhoc_jobs/landing_requirement_decomposition_20260531/REQUIREMENTS_ORIGINAL_TEXT.md#V-07）：「现在有一些任务正在进行，我觉得还是需要一套机制。如果这些 session 任务正在运行，它们的状态需要在运行结束后再更新。你可以先做一定的标记，表示任务还没跑完，后续还需要进行检查。关于这类任务的归类、时序判断等部分，可以先做决定；而具体的运行情况，则通过后续的额外检查机制来确定。」

目的（一句话）

一个任务交给正在运行的 session 异步做，完成与否没法在当下核实，就先把它标成「运行中、待核验」，归类和时序当场定下，完成裁决留到运行结束后由独立的检查机制回填，核验通过才进 done。

何时用

• 一个任务已经派给在跑的 session（背景 Codex run、并发 worker、远端任务），它的完成状态没法在本回合内核实。
• 想知道「现在哪些任务在跑、我还没核验过它们跑完没有」，要一个可查询的待核验清单。
• 任何「状态得等运行结束再更新、先标一个未跑完的记号、跑完再补检查」的场合。

这是任务生命周期里 in_progress 和 done 之间的一段。判一份完成声明可不可信、实现是否如其声称，是运行结束后那一步的事，路由 workflow_session_claim_audit；本 skill 管的是它前面那段状态机：先标记、归类时序先定、裁决延后。

与已有审查 skill 的关系（组合，不重复）

延后核验的「后续额外检查机制」不自己重造，运行结束后那一步路由到现成 skill。本 skill 新增的只有「运行中→标记待核验→结束后回填」这段状态机和它的纪律：

归类与时序怎么定本身不在这里：domain / 道术簇 / phase / 依赖在 intake 就定（workflow_requirement_intake），本 skill 只要求「标待核验时它们已经定下了」。

状态机与工作流

确定层落点是 todo（路径查 tools/INDEX.md）的两个子命令，外加共生检测器 deferred_verification_gate。一个任务走一遍：

1. 派给运行中 session 后，标待核验。todo start <id>（进 in_progress）→ todo dispatch <id> 取 prompt 交给在跑的 session → todo defer-verify <id>（进 awaiting_verify）。这一步等于「先做一定的标记，表示任务还没跑完」。标的时候归类（domain / 道术簇 / phase）和时序（依赖 / ordering）必须已经定下，它们是任务固有属性、当场可决；延后的只有完成裁决这一项，不在此刻填。

1. 运行中，状态不动。session 在跑期间任务停在 awaiting_verify，不因为 session 自己说「我做完了」就进 done。todo list --status awaiting_verify 随时列出所有在跑待核验的任务，这就是「哪些还没核验过」的清单。

1. 运行结束，跑后续额外检查机制。session 结束后，对它的完成声明做独立核验：路由 workflow_session_claim_audit 拉自报、写 Harness Reference、用确定性工具（git cat-file -e HEAD、grep 注册、landing_gate、真实重放看 exit）取实然、出 diff + readiness。核验的判据是 harness live 状态，不是 session 自己的叙述。

1. 回填核验，状态才更新。todo verify <id> --result pass --evidence <核验报告/RUN_EVIDENCE 路径>：核验通过 → 进 completed，证据引用落进任务记录。核验不过 → todo verify <id> --result fail --note <原因> 退回 in_progress 或 blocked，失败原因记下，不静默标 done。--evidence 必须指向真实存在的核验产物，没有核验产物就关不掉这一步。

要点：状态从 awaiting_verify 到 completed 的唯一通路是带证据的 verify。绕过它直接 done 等于「跑完前就把状态更新了」，正是本机制要拦的。

1. 收口核验，跑检测器。关一个延后核验 episode 后（即一个任务走完 verify），跑 python3 tools/deferred_verification_gate/check.py --task <id> 让共生检测器机械核 D1-D4：DV3 强制 completed ⇒ 证据文件存在、DV4 regulator 判回填证据是不是真独立于被核验 session 的自报。FLAG 按可定位反例修。这一步是本 skill 完成判据的执行件，调它才让「无证据不进 done」从纪律变成机械约束。

完成判据（无上下文 agent 可自判 done / not-done）

一个任务的延后核验算走对了，当且仅当：

• D1 标记完整：标 awaiting_verify 时归类（domain / 道术簇 / phase）和时序（依赖 / ordering）字段已填——「先做决定」的部分齐了；完成裁决此刻未填。归类时序缺失就标待核验不算。
• D2 延后核验已闭：任务进 completed 必须有一条 verify 回填记录，带独立证据引用，且引用的路径真实存在。没有 verify 记录就 completed、或证据引用为空 / 指向不存在的文件，都不算闭。
• D3 证据独立：回填引的证据来自独立 harness 取证或路由 workflow_session_claim_audit 的审计产物，不是被核验 session 自报的复述。把 session 的「我做完了」抄一遍当证据不算。
• D4 失败对称：核验判 fail 时任务退回 in_progress / blocked 并记失败原因，与判 pass 同等举证；不把没核过或核失败的任务静默标 completed。

这四条由共生检测器 deferred_verification_gate 机械核验：确定性壳判 D1（标记字段）/ D2（completed ⇒ 有 verify 记录 + 证据路径存在）/ D4（无静默完成）的结构在不在，regulator 判 D3——回填证据是不是真独立于被核验 session 的自报、是机械取证还是复述 transcript。检测器对症 DIAGNOSIS 的「执行者不能当自己的 oracle」：它防的就是 session 跑完自己说「done」、状态就跟着进 done 这条捷径。

边界（不做什么）

• 不替运行中的 session 自我打勾，awaiting_verify 是「未核验」不是「快好了」；状态更新只发生在带证据的 verify。
• 不重造核验逻辑，运行结束后的「实现是否如其声称」整段路由 workflow_session_claim_audit，证据判级路由 workflow_solid_decision_review。
• 不决定归类和时序怎么分，那是 intake 的事；只要求标待核验时它们已定。
• 不做运行时的动态 phase 重排或非线性转向（那是 P-03 / Phase 5），本 skill 只管「标记 + 延后 + 回填」这一段状态机。

跨域根与联系

承重支点同 workflow_session_claim_audit：开环控制下，执行 agent 判「我做完了」是同等代价的推断、内部不可见，所以完成裁决不能由它自己当场给，要等一个外部的、可操作的误差信号。延后核验把这条落到时间轴上——session 在跑时它的自评还没有独立误差信号背书，状态就先挂在 awaiting_verify，等运行结束后由第二方（审计机制）取 harness live 状态当误差信号，再回填。相关：workflow_session_claim_audit（回填那步的审计）、workflow_solid_decision_review（证据定级）、workflow_requirement_intake（归类时序在此定）、workflow_manage_unexpected（核验判 fail 退回后的遇阻处理）。