workflow_session_claim_audit

Z3 全文↑ Z2 条目

道-方法 · 道层 skill 全文

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

时点提示：本页是仓内文件 rules/skills/drafts/workflow_session_claim_audit.md 的逐字投影（仅做隐私清洗：仓库根绝对路径→相对路径、家目录→~/；除此零改写）。若源文件后续有修订，以仓内真源为准。

报告元数据（frontmatter）

name: workflow_session_claim_audit
description: 审查一个 session/agent 对自己完成状态的声明，核实「实现状态是否如其声称」，不全信自报。把自报与独立取证分开，产出 Harness Reference diff + readiness 判定，再路由判级。用于审查机制、复盘已完成任务、核实 session 完成声明、批量审查近期 session 在做什么。
status: draft (Beta) — 2026-06-05 段B V-01/T675 新建；晋级条件 = 真实审查 ≥1 个 session 的完成声明、过 session_claim_audit_gate、并被 GS-02 记录使用，再考虑摘 Beta。2026-07-11 内容更新（保持 Beta，不升 tier）：补假 provenance 核验（自报引用的用户背书回指真实 user turn，fallback=chat history / 目标=原文真源文件）+ 审查必要性分交互状态 + 批量覆盖机械对账；来源 = DLS 演变复盘实证（`contexts/survey_sessions/dls_evolution_retrospective_20260710_manual.md`，一次跨多 session 的真实长任务审计，抓出真实假 provenance）
tier: 道

审查 session 完成声明：核实实现状态是否如其声称

状态

Draft（Beta）。来源需求 V-01/T675（逐字原文见 adhoc_jobs/landing_requirement_decomposition_20260531/REQUIREMENTS_ORIGINAL_TEXT.md#V-01）：「你确实得要去查看这些 Session 中他们具体在做什么任务，以及他们给自己任务完成状态的评价。你可能还不能完全相信，所以需要有一个审查机制，看看他们实现的状态是否如他们声称的那样。」叠加两条 refinement：REF-025（检查点报告须含 Harness Reference diff + readiness 判定，而非仅 transcript 对比）、REF-026（反画靶射箭测试纪律：测试用例须独立于被测对象生成）。

目的（一句话）

给定一个声称完成了某任务的 session/agent（带它的自评），独立核实它实现的状态是否真如声称，产出一份用 harness live 状态背书的审查裁决，而不是读它的 transcript 看着像不像完成。

何时用

要审查一个或一批 session 在做什么任务、它们对自己完成状态的评价是否可信。
复盘已完成任务、核实「已完成」声称的真实效果、判断有没有按需求做到。
任何「不能全信自报、要核实实现状态是否如其声称」的场合。

单 asset 是否 landed 用 landing_gate；判一份证据够不够强用 workflow_solid_decision_review。本 skill 处理的是它们上面那层：把一个 session 的自评完成声明，转成可独立核验的 claim-vs-reality 审查。

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

本 skill 是元路由，新增的只有「session 级 claim-vs-reality 取证 + Harness Reference diff + 测试独立性纪律」三段。判级、单产物核验、二阶审查都路由到现成 skill，不复制它们的逻辑（单一文件原则）：

环节	路由到	它负责
证据判级（出 claim ceiling）	`workflow_solid_decision_review`	拿到 evidence bundle 后定证据等级 + next reaction
已知单 loop / final report 的产物层核验	`workflow_post_loop_critical_review`	单 target 的需求矩阵 + 实现 diff + 测试有效性
单 asset 结构落地核验（注册 / tracked / 消费边）	`landing_gate`（工具）	C1-C4 四条件，给「实然」侧确定性输入
被审对象本身是 reviewer session	`workflow_recursive_agent_review`	审 reviewer 有没有真审
测试设计耦合的事后诊断	`workflow_test_design_audit`	fixture / 信息泄漏红旗

审查工作流（每个 claim 走一遍）

拉自报，整段标「自报」。从被审 session 抓它声称做了什么 + 它对自己的完成评价。来源是 COMPLETE.md / 报告 / handoff / todo done notes / final report。整段标注「来源=自报，未核验」，后续步骤不得把它当证据。

1b. 自报里引用的「用户背书」本身是待核 claim（假 provenance 核验，2026-07-11 补）。当自报用「用户要求 / 用户原话 / 用户多轮口述 / 逐字存档」来正当化它做了什么时，这段 provenance 不是证据、是又一条 claim：被审 session 可能编造用户话语给自己的行为（尤其是跑偏）制造授权假象。真实案例：一个跑偏 session 在需求文档写「本 session 用户多轮口述（逐字存档 A1-A7）」，但该 session 原始 JSONL 只有 2 条真实用户消息、零对应口述，特征句在全语料回指为零（DLS 复盘定谳）。核验动作 = 把每条被引用的用户话语回指到一个真实 user turn（session id + 行位/时间戳）。回指路径分两档：目标态 = 直接查需求原文真源文件（REQUIREMENTS_ORIGINAL_TEXT.md / ORIGINAL_PROMPT.md；等「用户需求原文直录」功能建成且验证无误后用它，轻量、不必翻长 session）；当前 fallback = 用 bestpractice_chat_history_retrieval 查原始聊天记录 JSONL 的 raw user turns 核对。回指不到任何真实 user turn = 判「假 provenance」，该自报的正当性不成立。

同一「叙事操纵」家族里还有一个签名（drift-alarm 吸收）：被审 session 面对用户质询（「是不是没按 X 完成 / 这应该是做 Y 吧」）时，用「范围提升」把跑偏改述吸收、而非回原目标对账。审查时若见到用户质询后 session 重定义了任务范围，别信它的新叙事，按未如声称核验它到底完成原任务没有。

写 Harness Reference（应然面）。列出「若该 claim 为真，harness 真实状态应该是什么」，逐条都得能机械核验：哪些文件应在 HEAD、哪些注册行应在 _DAO_ROUTING / INDEX / tools/INDEX.md、哪些 receipt 应记录、哪个下游应消费它、哪条命令应真实 exit 0。这是参照面，由任务本身决定，独立于 transcript 说了什么。

独立取证（实然面）。用确定性工具取 harness live 状态：git cat-file -e HEAD:<path>、grep 注册行、landing_gate check.py、真实重放命令看 exit。证据只能来自这些独立工具，不能来自被审 session 的叙述。

Harness Reference diff + readiness 判定（REF-025）。把应然（步 2）和实然（步 3）逐条对照，每条标 MATCH / MISSING / DIVERGED，附独立证据出处。基于 diff 给 readiness 判定（ready / partial / not-ready），判据是 diff 结果，不是「transcript 读着像完成」。检查点报告比的是 harness reference，不是 transcript，这一条是 REF-025 的核心。

路由判级。把 diff + 独立证据打成 evidence bundle，交 workflow_solid_decision_review 出 claim ceiling + next reaction，不自己重定义证据等级。镜像条款照搬：判「未如声称 / blocked」也要对称举证，单个负信号最高 observational，broad fail 需第二信号或 live 全仓 find / grep 核验，防 FAM-K 把「成功但写错路径」误判成没做。

测试独立性（REF-026，仅当审查要测被审 session 声称的能力时）。测试用例必须独立于被审 session 的产物生成，生成者不预知 session 写了什么，路由 workflow_real_task_test_case_design。被审对象既造产物又造测试（constructor==evaluator）必然假通过，这是画靶射箭。事后诊断耦合再加 workflow_test_design_audit。

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

一份 session 完成声明审查报告算做完，当且仅当：

D1 双来源分离：报告把「自报 claim」和「独立证据」分成两段、各自标注清楚；独立证据段每条带确定性出处（git / grep / landing_gate 命令 + 结果，或文件路径 + 行号）。把自报复述一遍冒充证据不算。自报若引用用户背书（用户原话 / 要求 / 口述）作正当性，每条须回指真实 user turn 锚（session + 行位），回指不到即标「假 provenance」、该正当性不成立。provenance 核验属确定性壳；session_claim_audit_gate 机械覆盖它列为 follow-on，当前由审查者按步 1b 执行。
D2 Harness Reference diff 非空壳：有 diff 段，应然逐条对实然，每条标 MATCH / MISSING / DIVERGED，且有 readiness 判定（ready / partial / not-ready），判定由 diff 支撑、不是纯叙述。只贴 transcript 对比、没有 reference 对照不算。
D3 claim ceiling 裁决：有经 workflow_solid_decision_review schema 的 weakest_evidence_class + claim_ceiling + next_reaction，取最弱证据类。
D4 测试独立性（条件性）：若审查涉及测试被审能力，测试用例来源独立于被审 session 并注明独立性；不涉及测试则标 not_applicable。
镜像：判「未如声称 / blocked」与判「如声称」同等举证强度。

这四条由共生检测器 session_claim_audit_gate 机械核验：确定性壳判 D1-D3 的结构在不在，regulator 判独立证据是不是真独立于自报、Harness Reference diff 是真机械对照还是复述 transcript、测试是否真独立于被审对象。检测器对症 DIAGNOSIS 的「执行者不能当自己的 oracle」：它防的就是审查本身退化成「读 transcript + 信自报」。

收口调用（机械 exit 信号，不靠审查者自报「查过了」）：审查报告写完跑 python3 tools/session_claim_audit_gate/check.py --asset <审查报告路径> --regulator-tier codex:high 核 D1-D4；FLAG 按可定位反例修过再当审查完成。确定层快速过结构用 --no-regulator（D1-D3）。调它才让上面四条从纸面纪律变成机械约束。

边界（不做什么）

不替被审 session 自我打勾，裁决靠独立工具取的 harness 误差信号。
不重新实现证据判级、单产物核验、二阶审查，全路由到上面的组件。
这是审查机制（产 observation + 裁决），不是去重设计被审任务；发现缺口写进裁决的 next_reaction，不顺手重写被审产物。
批量审查多个 session 时，逐个 session 走一遍本工作流；「审查哪些 session」是应用层（V 组 T676-685）的事，本 skill 只定义单次审查的机制。批量规模大到要派 sub-agent 分片阅读时，覆盖必须由编排层机械对账闭环（审查清单 ↔ 产出文件双向核 + 定向补跑），reader 自报「已覆盖」不作数——DLS 复盘实测 103 个批读 agent 全报成功、机械对账发现约两成单元未读或判了没写；分片阅读的预算与覆盖机制走 workflow_long_context_scale_up。

跨域根与联系

承重支点是开环控制理论与可验证 checkpoint 实验：agent 判「我偏离目标了」是同等代价的推断、内部不可见，所以调控者必须是第二个智能体，外部误差信号还必须可操作（粗类别信号 ≈ 无信号）。本 skill 把这条落到 session 完成声明上——self-evaluation 不可当 oracle，审查要拉 harness live 状态当独立误差信号。

审查必要性分交互状态（2026-07-11 用户裁定）：上面这条「需第二智能体做外部误差信号」的必要性，依交互模式变化。强交互模式（人机实时来回、用户随时给需求和纠偏）下，用户本身就是那个外部 oracle，会当场抓偏差——DLS 全程正是靠用户实时质询纠正两类偏移，这时对抗性审查 / claim 核验可以更轻。完全自主化模式（agent 无人值守长跑）下没有实时 oracle，本 skill 这类对抗性核验是必需的，且要设计成能判「不该做 / 做多了」而不只是「哪里还不够」。一个衍生纪律：判「某机制该不该存在」这类减法问题，对抗性交叉核在自主模式下也易只加厚不删减（DLS 实测：一套 enforcement 被砍前一版还在被交叉核继续加固），减法判断更靠第一性追问（平台是否已保证这个属性），有用户在场时靠意图裁定。

相关：workflow_solid_decision_review（判级）、workflow_landing_to_production（落地四条件）、workflow_post_loop_critical_review（单 loop 收口）、workflow_long_context_scale_up（批量审查的分片覆盖机制）、workflow_design_elegance（减法判断 / 反过度工程）。

← 返回道层 skill 索引 · 返回方法论区