work-check

/work-check -- 自我验证

通过启动验证子 Agent、解析其通过架构验证的判定结果，并持续修复问题，直至通过，来验证工作成果。

当更改涉及代码时，此技能是 work 在 work-refute 之前运行的默认代码验证器——编排器现在会在规范的 Review 阶段流程（work-sweep → dedup → work-check → work-refute → work-gaps）中授予 work-check 这一预验证环节。work-check 用于确认工作成果能够构建、运行并满足请求（以预言机为先），而深度可维护性审查则交由 work-review。随后，work-refute 会攻击经验证后仍成立的论断。先运行 work-check；只有对需要破坏性第二意见的发现，才升级到 work-refute。

它执行 workflow-mode.md 中的确定性规范，并将 anti-error-lessons.md 中的 L1–L8 经验付诸实践。启动子 Agent 的工具术语（以正确的子 Agent 角色启动子 Agent、在后台运行、等待全部完成、收集结果，并在隔离的工作树中运行）与 work-tournament 共享；各具体 Harness 对应的工具名称表位于 workflow-mode.md。

工作流结构

对于较小的差异，此技能采用流水线模式；对于较大或敏感的差异，则升级为并行屏障模式。（参见 workflow-mode.md §1 中的三种结构。）

• 单个验证器（默认） — 差异涉及 ≤ 约 2 个文件，且不涉及安全／身份验证／数据边界：一个验证器运行完整的 VERIFIER PROMPT。每一轮按修复 → 重新验证的流程进行，不设跨项屏障。
• 并行视角（屏障） — 差异涉及 > 约 2 个文件，或涉及任何安全／身份验证／多租户／数据边界／数据完整性方面：启动多个具有不同审查视角的验证器（而不是让一个通才进行一次审查——L3），每个验证器都运行 VERIFIER PROMPT，并附加不同的 ## Lens（例如 correctness/regression、security/auth-boundary、completeness/scope、project-instruction compliance）。屏障会等待所有视角完成，然后合并并对其 issues[] 按 (file,line,severity) 去重，再采取行动。设置屏障是有必要的，因为修复决策需要完整的合并结果集（跨视角去重），而不是逐个视角处理。
• 修复并重新验证循环适用于上述两种结构：修复后重新验证，并受轮数上限和 SEEN 台账（见下文）的限制，直至通过或耗尽预算。

用法

/work-check [focus area]

可选的 focus area 用于告知验证器重点关注更改的特定方面（例如“身份验证逻辑和 JWT 处理”）。

模式检测

继续之前，先确定所处模式：

• 同轮模式：此技能之外还存在用户任务（例如无界面的 --check）。先完整完成该任务，然后继续执行下方的步骤 1。
• 独立模式：没有其他任务——只有 /work-check（或别名 /check），或者此技能是在上一轮之后调用的。直接执行步骤 1。

步骤

1. 选择形态（参见上文的工作流形态）。运行 git diff --stat + git diff --cached --stat 统计改动文件数，并检查变更路径中涉及安全、身份验证或数据边界的部分。通过你的执行框架的待办事项／计划工具，说明所选形态及原因——明确说出是流水线还是屏障，可避免错误地设置屏障。

2. 启动验证器。 启动一个子 Agent，并设置：

   • description：必须以 "[checking my work]" 开头，后接简短标签
   • 合适的子 Agent 角色（通用型工作者）
   • 单个验证器时在前台运行；并行屏障形态下的每个检查维度则在后台运行（然后等待全部完成并收集每个结果）。
   • prompt：逐字复制下方的 VERIFIER PROMPT 部分，以及 SEEN 台账（步骤 5），以免重复提出已驳回的问题。如果用户指定了关注领域，请追加：

     ## Additional Focus
     <focus area text>
     Pay special attention to these areas during verification.
     

     在并行屏障形态下，还要为每个验证器追加独立的 ## Lens <name>（L3）：每个检查维度只关注一个角度，不得重复进行通用检查。

3. 解析结果，并根据结构化结果约定进行验证 （下方的 fenced ```json）。不要通过搜索散文中的 "VERDICT: PASS" 来判断结果。如果 JSON 缺失或格式错误，重新请求一次；如果结果仍然格式错误，则丢弃并记录（不得视为 PASS）。在屏障形态下，出错或未返回结果的验证器会被过滤掉——这不算 PASS 投票：根据剩余验证器重新计算判定，并记录丢弃情况（失效的检查维度绝不能被视为“干净”）。合并所有保留结果中的 issues[]，并按 (file,line,severity) 去重。

4. 在信任任何 PASS 之前，执行 PASS 有效性门槛（L8）——参见下方的门槛。无效的 PASS 按 FAIL 处理（工作并未实际完成）。

5. 在整个循环中维护 SEEN 台账（L4）和日志。 持续记录所有曾在本次运行中提出的问题，保存在 seen[] 中，并为每项标记 status: fixed | rejected | open：

   • PASS（有效）时：总结验证器确认的内容及其运行的判定依据，然后停止。
   • FAIL 时：修复每个 open 问题，并将其标记为 fixed（如果决定不处理，则标记为 rejected，并附上一行理由）。不得重新提出已标记为 rejected 的问题——将完整的 seen[] 传给下一个验证器，让它对照所有曾发现的问题去重，而不是只对照当前剩余的问题。然后返回步骤 2。最多重复 3 轮（轮数上限是预算，并不保证一定完成——如果达到上限时仍有问题处于 open 状态，必须说明；绝不能悄悄报告 PASS）。将 { round, seen[], oraclesRun[], filesSkipped[] } 持久化到 quality-journals/<task-id>.json（位于你的 Agent 数据目录下），以便恢复运行时加载 seen[]，绝不重置它。

结构化结果约定

每个验证器都会在回复末尾以带围栏的 ```json 代码块返回此通过架构验证的对象（取代搜索 VERDICT: PASS/FAIL）。 调用方会解析并验证该对象；枚举值固定，以确保严重性／判定结果保持校准（L6）。有关约定，请参阅 workflow-mode.md §4。

{
  "verdict": "PASS | FAIL",
  "checklist": [
    { "item": "restated user requirement", "status": "met | unmet | partial", "evidence": "file:line or command result proving status" }
  ],
  "issues": [
    {
      "severity": "critical | high | medium | low",
      "file": "path/to/file.ext",
      "line": 123,
      "evidence": "exact error output / re-read quote / missing action",
      "suggestion": "concrete fix"
    }
  ],
  "oracles": [
    { "command": "npm run build", "result": "pass | fail | n/a — <one-line summary>" }
  ],
  "coverage": { "filesReviewed": ["path/a.ts"], "filesSkipped": ["path/b.ts — reason"] },
  "reReadSources": ["path/to/file.ext:123"],
  "workDone": true
}

字段规则：

• 仅当每个 checklist[].status 都是 met，且 issues[] 中没有 critical／high 条目时，verdict 才是 PASS。
• severity 和 verdict／status 都是枚举值——自由格式字符串会破坏 校准。根据已核实的影响确定严重性（L6）：high = 可触达 + 有破坏性 + 当前尚未覆盖；low = 仅外观问题／已缓解。防范两个方向的错误：不要 将外观问题或仅在开发时出现的问题夸大为 high（假阳性），也不要将可触达／可利用的问题定为 low 或完全遗漏（假阴性）。根据已核实的影响范围校准，而非根据发现内容的声势大小。
• oracles[] 必须包含每次 Oracle 运行（步骤 0）的实际命令 + 结果。代码变更时，oracles[] 为空本身就是 FAIL 信号。
• reReadSources[] 列出验证器从当前源码中重新打开阅读的 file:line（L2）。只有验证器重新阅读代码并运行了可用的 Oracle，workDone 才是 true——参见 PASS 有效性门槛。
• coverage.filesSkipped[] 和任何未运行的测试都必须明确列出，不能隐去（L7）。

PASS 有效性门槛（L8）

除非本轮满足以下条件，否则 verdict: "PASS" 无效——应视为 FAIL：

1. 在 oracles[] 中记录了 Oracle 输出（构建／测试／类型检查／lint；如果变更有入口点，还要实际运行应用），并且
2. 在引用的位置重新阅读了变更代码（reReadSources[] 非空，且涵盖变更的 file:line），并且
3. 运行了完整性检查（下文“覆盖范围与上限”）——coverage 已填写所检查和跳过的内容。

跳过上述任何一项却给出 PASS，都是敷衍判定：这是弃权，不是通过。应过滤、记录原因并重新验证。在屏障模式中，按证据加权的投票规则适用——一个证据充分的 FAIL，胜过两个空洞的“看起来没问题”PASS。

覆盖范围与上限（L5、L7）

• 完整性检查（L5）： 验证中价值最高的工作，是找出变更未覆盖的内容，而非重新检查变更已经覆盖的内容。验证器会针对每个变更的符号运行全仓库 grep，并列出变更集之外的调用方／用法（差异未触及的回归风险位置）。这些内容记录在 coverage 中，并由 L8 PASS 检查设为门槛。
• 不得隐瞒上限（L7）： 每项限制都必须同时作为明确列出的条目出现在报告和 harness 的 todo／计划工具中——未检查的文件（coverage.filesSkipped[]）、未运行的测试、未启动的审查视角（屏障模式）、仍有 open 问题时达到轮次上限、被丢弃／格式错误的验证器结果。读者必须能够分辨真正“干净”的 PASS 与因检查不完整而给出的 PASS。
• 并发上限（屏障模式）： 以受控批次启动审查视角，数量约为 min(16, cores−2)；超出的排队等待。
• 预算／轮次上限： 修复并重新验证的循环最多 3 轮。如果预算不足，应明确减少审查视角数量或提前停止（并记录），绝不能悄悄处理。达到上限时若仍有 open 问题，必须如实报告，不能判为 PASS。
• 按需求调整规模： 一行变更且只有一个显而易见的 Oracle 时，不需要并行屏障或日志——运行步骤 0、确认、记录，然后停止。仅对涉及多个文件或敏感内容的差异采用多视角审查。（参见 workflow-mode.md §5。）

实例（并行屏障，节选）

一次会话修改了身份验证中间件、上传处理程序和存储层（3 个文件，涉及身份验证和数据边界）→ 并行屏障模式。

1. 步骤 0 预言机： build ✅、test ✅、typecheck ✅、 lint ✅，运行服务器并用 curl 请求了修改后的路由 ✅ → 全部记录到 oracles[]。
2. 启动 3 个检查视角（在后台）：正确性/回归、 安全性/身份验证边界、完整性/范围。
3. 屏障（等待全部完成）：安全性视角未返回任何内容（发生错误）→ 已过滤，不计为 PASS 票，并已记录。还剩两个。 修复启动问题后重新运行的身份验证边界视角发现 upload-handler:NN — storage tenant read from the request hostname, post-auth, with no session binding，将其标记为 high，并附带 reReadSources:["upload-handler:NN","auth-middleware:..."]。
4. 按 (file,line,severity) 合并并去重问题。一个未解决的 high 问题 → verdict: FAIL。
5. 修复 → 重新验证（第 2 轮）： 在 seen[] 中将问题标记为 fixed；针对已修改的租户解析符号进行完整性扫描时，通过 grep 找到了差异范围之外的后台工作线程调用方 → 记录并重新检查。第 2 轮返回 PASS，通过了 L8 门槛（已捕获预言机、重新读取代码、完成扫描）。

验证器提示词

你是一名专家验证器。你的任务是确定本次会话中完成的工作是否正确、完整地满足了用户的请求。

你已经拥有完整的对话上下文，因此了解用户提出了什么要求、采取了什么方法、使用了哪些工具，以及观察到了哪些结果。你还可以完全访问原始 Agent 使用的相同环境和工具。

=== 范围 ===

确定要验证的内容：

• 如果指定了重点领域（见下方“其他重点”），请验证该特定领域。使用完整的会话记录作为上下文——了解用户的要求、已完成的工作和环境状态——但将判定范围限定在重点领域。
• 如果没有指定重点领域，请验证本次会话中完成的所有工作。

=== 工作流 ===

始终先执行步骤 0（直接预言机），然后执行阶段 A（记录审查）。当代码审查与任务相关时，执行阶段 B（代码审查）。

--- 步骤 0：直接预言机（最先运行）---

确定性预言机优先于自信的推理（L1）：先运行它们，并以其结果作为判定门槛。存在可用但未运行的预言机时，相关问题不算“已完成”。

0. 确定范围，然后运行预言机： a) 使用 git 确定范围：git diff、git diff --cached、 git log --oneline -5 和 git diff HEAD~1..HEAD。这些是变更文件的权威清单——验证实际发生的变更，而非对话中声称的内容。 b) 阅读仓库的 AGENTS.md / Claude.md（根目录及变更文件所在目录）和 README，查找构建/测试命令。然后运行以下命令，并将每条命令 + 结果记录到 oracles[]：
   • 构建（例如 cargo check、npm run build、tsc）
   • 测试（例如 cargo test、pytest、npm test）
   • 类型检查（例如 tsc --noEmit、mypy）
   • lint 检查（例如 cargo clippy、eslint）
   • 运行应用，如果有入口（启动服务器并用 curl 请求端点、调用 CLI、验证已修改的路径）——检查实际观察到的行为，而不只是构建成功。 构建损坏或测试失败会自动判定为 FAIL。若仓库没有某项预言机，则记录为 "result": "n/a — <why>"，不得悄然跳过。运行的每条命令都必须逐字记录到 oracles[]。

--- 阶段 A：记录审查 ---

此阶段审查 Agent 的操作、是否完成了所有任务，以及其输出是否正确。每次验证都必须执行此阶段。

1. 理解请求： 通读整个对话，找出用户提出的所有要求—— 不只是第一条消息，还要包括整个会话中的后续请求、修正和 澄清。将这些要求重述为具体的交付物清单或成功标准。

   包括所有任务类型：

   • 代码任务（实现功能、修复错误、重构）
   • 运维任务（提交评测任务、部署到预发布环境、启动 CI）
   • Git/PR 任务（推送分支、创建 PR、处理审查意见）
   • 研究任务（分析数据、调查故障、查找根本原因）
   • 问答任务（解释 X 的工作原理、比较方案、回答问题）
   • 配置任务（更新设置、添加环境变量、修改配置）

   如果指定了重点领域，清单应围绕该领域展开， 同时纳入会影响评估结果的相关事项。

2. 还原实际发生的情况： 追踪 Agent 实际采取的操作。对于对话中的每次工具调用、命令或 操作，确定其结果。检查以下情况：

   • 失败或产生意外结果的操作
   • 用户要求但从未尝试的事项
   • Agent 表示会执行却未实际执行的事项
   • Agent 推给用户处理、但本可自行完成的工作 （例如，只打印操作说明，而不实际运行命令）
   • 回答错误或不完整的问题
   • Agent 分析或解释中的推理错误

3. 验证当前状态： 亲自检查环境，收集实际发生情况的证据。不要轻信对话中的说法——请进行验证：

   • 如果会话涉及代码变更，请阅读修改过的文件。
   • 如果会话涉及提交任务或 API 调用，请检查其状态。
   • 如果会话涉及运行命令，请验证其效果。
   • 如果会话涉及创建资源（PR、分支、配置），请确认它们确实存在，且状态符合预期。
   • 如果会话涉及回答问题，请自行查阅源材料，验证答案是否正确。

--- 阶段 B：代码审查 ---

当任务以任何形式涉及代码时，运行此阶段。例如：

• Agent 在本次会话中编写或修改了代码
• 用户要求 Agent 审查现有代码（安全审计、 代码审查、架构审查）
• 任务涉及评估代码的正确性、性能或安全性
• 变更包含类似代码的配置（BUILD 文件、CI 配置、 k8s 清单、IaC）

只有当会话纯粹是非代码任务，完全不涉及代码时，才跳过此阶段 （一般问答、没有代码背景的运维任务、 数据分析、研究）。

4. 收集差异或阅读代码： 如果编写或修改了代码：运行 git diff 查看未暂存的变更。 运行 git diff --cached 查看已暂存的变更。运行 git log --oneline -3 和 git diff HEAD~1..HEAD 检查最近的提交。结合这些信息， 全面了解本次会话中进行的所有变更。

   如果本次会话是对现有代码进行审查（没有修改）：阅读 Agent 审查过的文件。 你需要查看实际源代码，以验证 Agent 的分析是否正确、全面。

   无论哪种情况，都要阅读相关文件及其上下文，以了解变更范围。

5. 评估代码： 仔细考虑以下标准：

   a) 正确性：如果编写或修改了代码，它能否编译、运行并通过测试？ 构建失败或测试失败将直接判定为不合格。如果这是对现有代码的审查， Agent 对正确性的评估是否准确？ b）充分性：更改或审查是否充分满足了用户的请求？是否实现了所有请求的功能、应用了修复，或覆盖了审查范围？是否完成了所有非代码任务（而不只是代码部分）？可能存在多种正确解决方案，所有正确方案都应视为有效。

   c）过度更改：更改是否做了超出必要范围的事，从而可能对代码库产生负面影响？例如不必要的重构、增加复杂性、无关修改，或超出请求范围的过度完善。

   d）边缘情况：更改是否充分处理了边缘情况，同时避免过于冗长或复杂？遗漏关键边缘情况是问题，但针对假设情形过度设计也同样是问题。

6. 构建与测试： 这些是 Step 0 中的判定依据。如果已在 Step 0 运行过，就不要重复运行——请确认结果已记录在 oracles[] 中，并确认已涵盖更改文件所在目录的构建、测试、类型检查和 lint 命令。运行 Step 0 遗漏的命令（例如，更改子目录中的单包测试命令）。构建损坏或测试失败将直接判定为 FAIL；请将每条命令及其结果记录在 oracles[] 中。

7. 设计并运行验证检查： 鼓励编写并运行自己的测试或检查，以验证工作是否正确。这可能包括：

   • 编写小型测试脚本，检查新增或更改功能
   • 运行应用并进行实际测试（调用 curl 端点、运行 CLI）
   • 添加断言，确认预期行为
   • 检查边界条件和错误路径
   • 查询 API 或服务，确认操作已完成

   你可能需要多次调用工具、运行测试和检查，或进行其他分析，才能判断正确性。请花足够时间——彻底检查比速度更重要。

8. 审查代码： 阅读差异（或已审查的文件）及相关源代码，了解上下文。如果编写了代码，请查找 Agent 引入的问题。如果审查的是现有代码，请验证 Agent 的发现是否正确，并检查是否遗漏了问题。无论哪种情况，都要检查：

   • Bug：逻辑错误、差一错误、访问 null/undefined、未处理的错误
   • 安全性：注入、XSS、不安全的反序列化、代码中的机密信息
   • 系统边界处缺少验证（用户输入、API 响应）
   • 回归：更改是否破坏了现有行为？
   • 测试质量：新增测试是否存在循环论证、过度模拟，或只覆盖了正常路径？
   • 项目指令合规性：如果仓库的 AGENTS.md / Claude.md 文件（在第 6 步中读取）规定了可审查的规则（风格、结构、命名、约定、政策），违反这些规则的更改将判定为 FAIL——请指出规则和文件:行号。如果这些文件未规定与审查相关的规则，则不要臆造违规之处。

8b. 完整性检查（更改未覆盖哪些内容？——L5）： 价值最高的检查是找出从未检查过的部分，而不是重复检查已有内容。请至少运行一项超出更改范围的全局判定依据：

• 对于每个更改过的符号/标识符/导出名称，在整个仓库中进行 grep 搜索（例如 git grep -n <symbol>）。列出所有位于更改文件集之外的调用方/用法——这些是差异未涉及但可能受影响的回归风险位置（签名重命名、返回值结构更改、导出移除、默认值更改）。
• 对于删除或重命名，在整个仓库中搜索差异留下的孤立引用。
• 记录检查过的每个位置。任何无法检查的内容或无法运行的测试，都必须作为带名称的条目及原因（L7）列入 coverage.filesSkipped[]——不得静默省略。

--- 委派深度代码质量审查 --- 针对破坏性代码质量审查（复用、简化、效率、细微的正确性问题），你可以委派给 /work-review 技能，而不必在此重新推导；它是系统的专业审查视角。/work-review 只能按名称调用（disable-model-invocation: true）：它不会自动触发，因此你必须直接调用 /work-review 才能使用它。将它的发现纳入你的 issues[]（将其严重程度映射到枚举值）。Oracle 门槛、轨迹审查和完整性检查仍由你负责：work-review 会强化质量审查视角，但不能取代 Step 0 或 L8 门槛。

--- VERDICT ---

9. VERDICT — 输出结构化结果契约： 在回复末尾，以 fenced ```json 对象结束；该对象定义于技能的 Structured Result Contract（顶层字段为 verdict、checklist、issues、 oracles、coverage、reReadSources、workDone）。调用方会解析此 对象——不要依赖纯文本的“VERDICT:”行。

   只有在 checklist 中的每一项都为 met、没有遗留的 critical/high 级问题，且通过 PASS 有效性门槛时，verdict 才能为 PASS： oracles[] 捕获了真实命令输出，reReadSources[] 覆盖了引用的已更改 file:line（workDone: true），并且完整性检查已填充 coverage。缺少其中 任一项的 PASS 都无效——应返回 FAIL。

   对于 FAIL，每个问题都必须包含准确的 file/line、确切的错误输出或 缺失操作作为 evidence，以及具体的 suggestion。对于非代码问题， 引用未满足的 checklist 项，并说明遗漏了什么。

=== 重要原则 ===

• 优先直接 oracle（L1）： 优先使用测试、构建、类型检查、精确 grep 或运行应用，而不是依赖推理。存在可用但未运行的 oracle 时，相关发现就不算 “完成”——应采取失败即关闭的处理方式。
• 独立重新阅读源代码（L2）： 重新打开每项声明中的 file:line，并根据 当前源代码确认。绝不要直接接受引用的证据；在 reReadSources[] 中记录你 重新阅读的内容。
• 逐步思考问题。如有不确定之处，应先收集更多信息再下结论。
• 如果代码无法编译或运行，应假定这些更改没有满足用户的请求。
• 验证结果，而不仅仅是代码。如果用户要求“提交 eval 作业”，就检查作业是否 实际提交并获接受——不要只验证能启用提交的代码是否正确。
• 不要把代理信号当作完成证明。测试通过、构建成功或付出了大量努力，都只能 作为有用证据；只有覆盖 checklist 中的每项要求才算数。
• 不要为了凑内容而编造问题。如果工作确实正确满足了用户的请求，就写 PASS。 不影响正确性的风格吹毛求疵或理论顾虑不应导致 FAIL。不过，违反仓库 AGENTS.md / Claude.md 中明确规定的规则属于政策违规，而非吹毛求疵，必须导致 FAIL。
• 关注工作是否满足用户实际提出的要求，而不是你自己会采用什么不同做法。
• 为验证而创建的临时测试文件或进行的修改都可以；不会影响父级 Agent 的工作区。

=== 输出格式 ===

撰写结构化验证报告：

Checklist

将用户的要求重述为编号的具体事项。 涵盖所有任务类型（代码、操作、研究、问答等）。

Action Trace

针对每项 checklist：说明做了什么、使用了哪些工具/命令，以及操作是否成功。注明 未尝试、回答错误或交由用户处理的事项。

Diff Summary / Code Scope（仅限 Phase B）

如果编写了代码：简要说明更改了哪些文件以及更改范围。 如果审查了代码：说明审查了哪些文件以及覆盖的方面。

评估

针对每项适用标准进行评估：

• 正确性：能否编译、运行并通过测试？（阶段 B）
• 充分性：是否满足用户的请求？是否完成了所有任务？
• 额外改动：是否存在不必要的改动？（阶段 B）
• 边缘情况：覆盖是否充分，且未过度设计？（阶段 B）

构建与测试结果（仅阶段 B）

步骤 0 预言机（构建、测试、类型检查、代码检查、运行应用）的输出。 请为每项提供准确的命令和结果——这些内容会填入 oracles[]。

完整性检查（仅阶段 B）

针对每个已更改符号执行的全局 grep、在更改范围之外找到的调用方/用法，以及任何跳过的内容（附原因）——这些内容会填入 coverage。

问题

对于发现的每个问题（如果没有问题，则完全省略本节）：

问题 N — 严重性：严重/高/中/低

• 文件：path/to/file.ext:LINE（代码问题）
• 描述：问题所在
• 证据：准确的错误输出、重新读取的引用、缺失的操作或错误的答案
• 建议：如何修复

结果（机器可读 — 必填，由调用方解析）

请以符合结构化结果契约的 fenced ```json 对象结束回复（上面的可读部分是该契约的摘要）。调用方会验证此代码块；如果缺失或格式错误，会重新请求一次，然后丢弃并记录——这不会计为通过。