workflow_large_scale_task_audit

道-方法 · 道层 skill 全文

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

name: workflow_large_scale_task_audit
status: draft (Beta) — 2026-06-07 从 landing requirements 使用效果审查中提炼；晋级前需在至少 2 个不同大型任务审查中稳定捕获 requirement / implementation / runtime / skill-use / record completeness 缺口，并留下 task-bound skill 使用记录
description: 审查一个大型、多 session、多机制任务是否真正满足用户原始需求。用于 freeze 当前状态、从原文拆 obligation、核实实现/运行/skill 使用/hook trace/记录完整性、区分 landed 与 in-flight，并产出可复用审查报告。触发场景：全量审查、大规模任务复盘、实现效果检查、检查 skill 是否真实使用、检查 hook/trace/receipt 是否完整、不能全信 handoff/session 自报。
tier: 道

大规模任务审查：原始需求 → 实现 → 真实运行 → skill 使用 → 记录完整性

目标

给定一个已经跨多轮 session 推进的大型任务，判断它到底有没有满足用户原始需求。不要停在“报告说完成了”或“文件已经创建了”，而要把原始需求、实现状态、真实运行、skill 使用、hook/trace、过程记录放在同一个证据框架里裁决。

何时使用

• 用户要求全量审查、实现效果检查、落地审查、复盘大型任务。
• 任务跨多个 session、handoff、todo、report、tool receipt、runtime evidence。
• 用户怀疑已创建的 skill / tool / hook 没有在真实工作中被使用。
• 需要检查“完成声明是否可信”或“记录能否重建完整过程”。

单个 session 的完成声明审查路由 workflow_session_claim_audit；单个 asset 是否 landed 路由 workflow_landing_to_production / landing_gate；证据强度判级路由 workflow_solid_decision_review。本 skill 负责把这些审查单元编成一个大型任务审查。

完成判据

一份大规模任务审查算完成，当且仅当：

• Freeze 存在：记录时间、HEAD、branch、handoff、todo 状态、receipt 状态、dirty/untracked 风险；后续变化不得混入 freeze 结论。
• Obligation ledger 存在：从用户原始需求拆出可核查义务，不只复述 handoff 或执行者自报。
• Claim map 存在：列出 handoff / todo / report / session 自称完成的点，并标“自报，未核验”。
• Implementation proof 存在：对关键 claim 做 HEAD、git ancestor、文件、注册、索引、测试、gate 核查。
• Runtime proof 存在：至少检查一个真实运行 trace / events / exit 证据，区分 real、mock、self-report。
• Skill-use proof 存在：列出 required skills，检查是否有 task-bound 使用记录、artifact、downstream consumption；普通 read receipt 不能自动算使用。
• Record reconstruction 存在：选一次真实运行，重建每步做了什么、问题是什么、如何解决、决策依据是什么；不能重建的断点要列出。
• In-flight 分类存在：modified / untracked / pending / missing gate 的内容只能叫 in-flight，不许写成 landed。
• Claim ceiling 存在：每个大结论按最弱证据给 pass / partial / fail / unknown，并列 next reaction。
• 报告落盘：重要发现必须写入文件，不只留在对话里。

审查流程

1. 先合并成簇（tool-like clusters）。不要按 task id 逐个散查，也不要只按旧段 A/B/C 叙事查。把相似任务合并为功能簇：治理底座、落地 hub、控制平面、运行时本体、trace/记录面、叶子/parked 工作。簇的判据是「共同提供什么生产行为」，不是时间顺序或编号前缀。

1. Freeze 当前状态。写 FREEZE.md 或等价文件：时间、HEAD、branch、最新 handoff、todo 摘要、receipt 统计、dirty/untracked、并发运行风险。freeze 后运行的测试或命令若改变 ledger，只能作为 post-freeze side effect 记录。

1. 回到原始需求。定位用户原文、handoff、requirements、previous analysis sessions。把原始需求拆成 obligation ledger：每条义务要能被证据回答 yes/partial/no/unknown。

1. 建 claim map。收集所有“已完成/已 landed/已实现”的自报来源：handoff、todo done、reports、session final、commit message。整段标为 self-claim，不能直接当证据。

1. 核实现状态。对关键 claim 跑确定性核查：HEAD 中是否存在、是否 tracked、是否注册、是否有下游引用、测试是否通过、gate 是否通过。工具路径查 tools/INDEX.md，不要在 skill 中硬编码。

1. 核真实运行。找真实 events / trace / dogfood / command exit，至少选一个 case 重放或读取 raw event。mock sanity、self-reported pass、只存在设计文档都不能支撑 landed claim。

1. 核 required skill 使用。先列出该簇/任务按规则应使用的 skills，再查是否有 task-bound receipt 或产物消费边。skill:* read receipt 如果没有 task_id、phase、artifact、decision output，只能证明 hook 活着，不能证明生产使用。

1. 核 hook / trace 机制。检查 hook 是否只是被动记录，还是在任务前/阶段前/任务后改变 agent 行为；检查 hook 完成后是否能恢复原任务上下文；检查 DONE claim 是否消费 required-skill ledger。再检查 trace-grade lineage：session -> task -> required skill/tool -> artifact -> report -> commit -> later skill revision 是否能连起来。receipt counter 不等于 lineage。

1. 重建一次运行过程。选一个典型 task/session，按时间线重建：输入、步骤、问题、修复、决策、测试、gate、报告、记录。若需要跨 git/report/events/receipts/todo 才能拼出真相，要标“record ergonomic gap”。

1. 区分 completed 与 in-flight。已进 HEAD、真实运行、被 gate/下游消费、记录完整的才可称 landed。pending todo、untracked file、未跑 gate、只有 mock 的内容标 in-flight。

1. 合并裁决与 next reaction。每条 obligation 给 evidence、claim ceiling、next action。不要用“总体差不多”覆盖单点 fail；大型任务常见状态是 mechanism pass + production use fail。

证据等级速记

• landed：HEAD/tracked + real runtime + gate/independent verifier + downstream consumption + task-bound record。
• partial：有代码或报告，也有部分 gate/trace，但缺 real consumption、skill-use proof 或完整记录。
• in-flight：modified/untracked/pending/mock-only/self-reported pass。
• fail：需求明确要求，但实现或记录证明缺失。
• unknown：证据不足；不能把 unknown 写成 pass。

常见陷阱

• 只按旧段 A/B 审查，漏掉 live handoff 已进入 Segment C / Phase 5。
• 把 created / registered / read 当成 used。
• 把 handoff 自报当成实现证据。
• 把 mock sanity run 当成真实运行。
• 把 untracked/in-flight 文件当成 landed。
• 只查 tool receipts，不查 skill receipts 的 task_id 和消费边。
• gate exit 0 只留 receipt，不保存 gate output，导致后续无法重读 verdict。
• 测试污染真实 ledger，审查者误把自己跑出的 temp receipt 当 freeze 证据。
• parent todo 状态与 child task landed 状态漂移。
• 记录很多，但缺 session/task/skill/artifact/report/commit 的 lineage packet。

输出模板

最少产出这些文件或等价内容：

• FREEZE.md：冻结状态。
• tasks/requirement_obligations.md：原始需求义务表。
• tasks/skill_usage_audit.md：required skill 使用与 receipt 纪律。
• tasks/record_reconstruction_<task>.md：单次运行过程重建。
• reports/<task>_large_scale_audit.md：最终裁决报告。

相关 skill / tool

• workflow_recall_first_locate：找全原始需求和 session 来源。
• workflow_precise_reading：按 obligation 逐条读够。
• workflow_session_claim_audit：审查 session 自称完成是否可信。
• workflow_data_check_review：按原始数据和 partial 反例审查 claim。
• workflow_real_task_test_case_design：真实条件测试设计。
• workflow_landing_to_production：判断 asset 是否真 landed。
• workflow_solid_decision_review：证据等级与 claim ceiling。
• workflow_tool_receipt_discipline：receipt 是否真实可用。
• workflow_version_evolution：新增或修改对外承诺类 skill / rules 时判版本。
• 工具按名引用：todo、landing_gate、tool_receipts/check_discipline、session_claim_audit_gate、git、rg。

外部 trace 参照（pressure tests）

当用户要求检查 trace / skill 使用 / 运行产物存放时，用外部 trace 系统当压力测试，而不是只看本仓 receipt：

• TraceSkill-style：能否从 session history、handoff、git、artifact 重建某个设计决策的时间线和证据。
• Traces-style：session trace 是否能绑定 agent skill、working directory、git commit / shared trace。
• Trace2Skill / skill-revision style：trace 是否能证明 skill 改变了行为，并把真实失败反哺到 skill 更新。

本仓当前 receipt 只能覆盖其中一部分；审查时要明确标出缺的 lineage 面。