verify

验证功能

与宿主无关的工作流。通过技能名称（verify）调用。Claude Code 斜杠路由、YAML 钩子加载器和 .claude/chain 的说明见 references/claude-code.md。

使用多个并行的专用 Agent 进行全面验证，并采用细致的评分方式（0–10 分），提供改进建议。

快速开始

verify authentication flow
verify --model=opus user profile feature
verify --scope=backend database migrations

参数解析

对于代词目标（this、them、the above），从对话中回读目标，用一行宣布，并使用它：Read("../../shared/rules/target-resolution.md")`，内联部分。

SCOPE = "$ARGUMENTS"       # Full argument string, e.g., "authentication flow"
SCOPE_TOKEN = "$ARGUMENTS[0]"  # First token for flag detection (e.g., "--scope=backend")
# $ARGUMENTS[0], $ARGUMENTS[1] etc. for indexed access (CC 2.1.59)

# Model override detection (CC 2.1.72)
MODEL_OVERRIDE = None
for token in "$ARGUMENTS".split():
    if token.startswith("--model="):
        MODEL_OVERRIDE = token.split("=", 1)[1]  # "opus", "sonnet", "haiku", "fable"
        SCOPE = SCOPE.replace(token, "").strip()

# Streak gate detection (#2540) — consecutive-pass mode
STREAK_TARGET = None
for token in "$ARGUMENTS".split():
    if token.startswith("--streak="):
        STREAK_TARGET = int(token.split("=", 1)[1])  # N consecutive READY verdicts required (N >= 2)
        SCOPE = SCOPE.replace(token, "").strip()
# When set, apply the Streak Gate (see below). Full protocol: references/streak-gate.md

如果设置了 MODEL_OVERRIDE，则通过 model=MODEL_OVERRIDE 将其传递给所有 Agent() 调用。可接受符号名称（opus、sonnet、haiku，以及 Agent 工具列出 fable 的运行环境中的 fable；请注意，2026-07-12 之后使用 fable 会产生高级 API 费用）或完整 ID（claude-opus-5-5），具体遵循 CC 2.1.74。

Opus 5.5：Agent 使用原生自适应思考（无需 MCP sequential-thinking）。Opus 5.5 自身的默认 effort 为 medium，比 Opus 5 的 high 低一级；而 CC 2.1.280+ 会让新发布的模型采用其默认值，因此验证时请传入 high 或 xhigh。扩展的 128K 输出支持生成全面的验证报告。

---

步骤 0：根据 Effort 级别调整验证规模（CC 2.1.76）

根据 /effort 级别调整验证深度：

Effort 级别	运行阶段	Agent 数量	输出
low	仅运行测试 → 通过/失败	0 个 Agent	快速检查
medium	测试 + 代码质量 + 安全 + API 合规性	4 个 Agent	评分 + 主要问题
high（默认）	全部 8 个阶段 + 视觉捕获	6–7 个 Agent	完整报告 + 评分
xhigh（Opus 5，CC 2.1.111+）	全部 8 个阶段 + 额外的跨文件模式扫描 + 自我验证轮次	6–7 个 Agent	带不确定性标注的完整报告

覆盖规则： 用户明确选择的范围（例如“全面验证”）优先于 /effort 降级设置。

步骤 0a：使用 AskUserQuestion 确认用户意图

创建任务之前，先确认验证范围：

AskUserQuestion(
  questions=[{
    "question": "What scope for this verification?",
    "header": "Scope",
    "options": [
      # multiSelect questions do not render previews (single-select only) — kept text-only
      {"label": "Full verification (Recommended)", "description": "All tests + security + code quality + visual + grades"},
      {"label": "Tests only", "description": "Run unit + integration + e2e tests"},
      {"label": "Security & code quality", "description": "Security audit (OWASP/CVE/secrets) + lint/types/complexity"},
      {"label": "Quick check", "description": "Just run tests, skip detailed analysis"}
    ],
    "multiSelect": true
  }]
)

根据回答调整工作流：

• 全面验证：运行全部 9 个阶段（8 个阶段 + 2.5 阶段），启动 7 个并行 Agent，包括视觉捕获
• 仅测试：跳过阶段 2（安全）和阶段 5（UI/UX 分析）
• 安全与代码质量：运行 security-auditor 和 code-quality-reviewer Agent
• 快速检查：仅运行测试，跳过评分和建议（跳过阶段 2，不违反 Fan-out 规则）

---

步骤 0b：选择编排模式

加载详细信息：Read("references/orchestration-mode.md")，了解环境变量检查逻辑、Agent Teams 与 Agent Tool 的比较，以及模式选择规则。

默认：Workflow（星型，workflows/verify-dispatch.js 运行阶段 2）。需要对发现进行讨论时，选择 Agent Teams（网状，验证者共享发现）；Workflow 工具不可用时，则按照编排模式参考文档选择普通的 Agent 工具（星型）。

扇出规则： 如果所选范围会运行阶段 2，单轮执行绝不能作为回退方案。阶段 2 必须通过 Workflow 调用、Agent Teams 或 Agent 工具运行；如果这些方式都没有启动验证者，则以 BLOCKED 结束运行并说明原因。跳过阶段 2 的范围（effort 为 low、仅测试、快速检查）不构成违规。

---

MCP 探测与恢复

# memory is alwaysLoad in .mcp.json (CC 2.1.121+, #1541) — probe below kept as fallback for older CC:
ToolSearch(query="select:mcp__memory__search_nodes")
Write(".claude/chain/capabilities.json", { memory, timestamp })

Read(".claude/chain/state.json")  # resume if exists

交接文件

验证完成后，写入结果：

Write(".claude/chain/verify-results.json", JSON.stringify({
  "phase": "verify", "skill": "verify",
  "timestamp": now(), "status": "completed",
  "outputs": {
    "tests_passed": N, "tests_failed": N,
    "coverage": "87%", "security_scan": "clean"
  }
}))

回归监控（CC 2.1.71）

可选择安排验证后的监控：

# Guard: Skip cron in headless/CI (CLAUDE_CODE_DISABLE_CRON)
# if env CLAUDE_CODE_DISABLE_CRON is set, run a single check instead
CronCreate(
  schedule="0 8 * * *",
  prompt="Daily regression check: npm test.
    If 7 consecutive passes → CronDelete.
    If failures → alert with details."
)

---

完成标准。 完成意味着：每个选定维度都有一个由本次会话中运行的命令支撑的评分，并且报告明确区分 VERIFIED 与 CLAIMED。遵循 Read("../../shared/rules/long-run-protocol.md")：步骤无需用户输入时继续执行；只有在无法继续或即将执行破坏性操作前才停下并询问；接受子 Agent 的证据前先逐一核查；对于无法确认的事项，注明检查过的位置。

任务管理

创建主验证任务，并为每个阶段创建一个子任务；评分必须以检查通过为前提：Read("references/task-management.md")。

---

8 阶段工作流

加载详细信息：Read("references/verification-phases.md")，查看完整阶段详情、Agent 启动定义、Agent Teams 替代方案和团队拆解流程。

阶段	活动	输出
1. 背景信息收集	Git 差异、提交历史	变更摘要
2. 并行分派 Agent	6 个 Agent 评估	0-10 分
2.5 视觉捕获	对路由进行截图、AI 视觉评估	图片库 + 视觉评分
3. 测试执行	后端 + 前端测试	覆盖率数据
4. 综合评分	计算综合得分	等级（A-F）
5. 改进建议	分析工作量与影响	优先级列表
6. 替代方案比较	比较方案（可选）	建议
7. 指标跟踪	趋势分析	历史数据
8. 报告汇总	证据材料 + gallery.html	最终报告

阶段 2 Agent（快速参考）

Agent	重点	输出
code-quality-reviewer	Lint、类型、模式	质量 0-10
security-auditor	OWASP、密钥、CVE	安全性 0-10
test-generator	覆盖率、测试质量	覆盖率 0-10
backend-system-architect	API 设计、异步处理	API 0-10
frontend-ui-developer	React 19、Zod、无障碍	UI 0-10
python-performance-engineer	延迟、资源、扩展能力	性能 0-10

不要手动编写分派流程。先在后台启动阶段 3 的测试运行（如下），然后运行执行器：

Workflow(
  scriptPath="${CLAUDE_SKILL_DIR}/workflows/verify-dispatch.js",
  args={"effort": EFFORT, "scope": "<diff summary from Phase 1>", "rubric": <rubric.json>,
        "dimensions": DIMS, "modelOverride": MODEL_OVERRIDE}
)   # add "testEvidence": {"outcome", "exitCode", "summaryLine"} if assert-evidence.sh already ran
# DIMS from STEP 0a: Full -> all six ["security","quality","coverage","api","performance","ui"] (overrides effort);
#   "Security & code quality" -> ["security", "quality"]; Tests only / Quick check -> skip Phase 2

脚本负责机制，而非文案。 它会按工作量扩展验证器（先进行安全审查），并提供证据架构；将关键阻塞项和低分项交给反驳者（high 时投 1 票，xhigh 时投 3 票，按计划票数的多数票决定；每项反驳都必须有命令作为依据）；将 Agent 数量限制在 12 个以内；并返回包含 reasons 的 verdictCap。无法确认的内容都会降低上限：未知维度、缺失评分标准、没有命令证据支持的分数、标记为 CLAIMED 的项目、已失效的验证器。缺少 testEvidence 时，它会返回 PENDING-TESTS 和 capIfTestsPass：通过以下门槛检查后，只有当证据状态为 EVIDENCE、退出码为 0、摘要显示至少一项测试通过且没有失败时，上限才为 capIfTestsPass；否则为 BLOCKED。所有项目的安全性低于 9.0 时均为 BLOCKED（operator decision 2026-09-25）；策略可以收紧其他门槛，但不能放宽。阶段 4 的评分不得超过上限。

监控 + 部分结果（CC 2.1.98）

使用 Monitor 流式查看测试输出。run_in_background 请求可能不会得到遵循，因此切勿无条件等待结果。

LOG = f"verification-output/{ts}/npmtest.log"   # named file: evidence lands here whether or not backgrounding is honoured
task = Bash(command=f"npm test > {LOG} 2>&1; echo EXIT=$? >> {LOG}", run_in_background=true)
if not task.id:                 # request ignored → the command ran inline and LOG is already complete
    pass                        # do NOT wait; there is no task to wait for
else:
    Monitor(pid=task.id)        # bounded: see the contract reference below; progress via `tail -n 5 {LOG}`
# The verdict gate is EXECUTABLE, not prose (#3263). Only outcome=EVIDENCE may be graded:
Bash(command=f"bash \"${{CLAUDE_SKILL_DIR}}/scripts/assert-evidence.sh\" {LOG} --task-id '{task.id or 'none'}'")
# exit 0 EVIDENCE   → grade from LOG's runner summary line
# exit 4 STILL-RUNNING → keep the bounded wait, re-run the gate
# exit 3 COULD-NOT-OBSERVE (0 bytes, no live process) or exit 1 NO-BANNER →
#   the Tests dimension has NO score; report `Tests: COULD-NOT-OBSERVE (assert-evidence exit N, bytes, pid_alive)`
#   and the verdict is BLOCKED. Never emit a grade from an empty run.

实测结果（#3263）：三个后台运行的测试套件写入了 0 字节，npm 自身的横幅也从未出现，而该技能却等待一个根本不会触发的完成信号约 40 分钟。空运行必须明确报错，不能一直待处理。契约和已被反驳的假设：Read("references/background-task-contract.md")。

完整模式参考（何时使用 Monitor 而非 TaskOutput、直到条件门槛、反模式）：Read("../chain-patterns/references/monitor-patterns.md")。

Agent Teams 或普通 Agent 模式下的渐进式输出和部分结果：Read("references/progressive-and-partial-results.md")。

阶段 2.5：视觉捕获（新增——与阶段 2 并行运行）

加载详细说明：使用 Read("references/visual-capture.md") 了解自动检测、路由发现、截图捕获和 AI 视觉评估。

摘要：自动检测项目框架，启动开发服务器，发现路由，使用 agent-browser 为每个路由截图，并通过 Claude 视觉功能进行评估，生成内嵌 base64 图像的自包含 gallery.html。

输出：verification-output/{timestamp}/gallery.html——在浏览器中打开，即可查看所有截图、AI 评估、评分和标注差异。

优雅降级：如果未检测到前端或服务器无法启动，则跳过视觉捕获并发出警告，不会阻塞验证。

---

评分与计分

使用 Read("../quality-gates/references/unified-scoring-framework.md") 加载维度、权重、等级阈值和改进优先级。使用 Read("references/quality-model.md") 加载 verify 专用扩展（Visual 维度）。使用 Read("references/grading-rubric.md") 加载各 Agent 的评分标准。

维度级阻断项（ork-rubric/1.0）

综合分是必要条件，但并非充分条件——较高的综合分可能掩盖关键维度的问题。在阶段 4（细致评分）中，从 rubric.json 读取各维度阈值（架构：../../shared/rubric.schema.json）：security 的 min_blocker 为 9.0（固定、硬性要求），其他每个维度的 min_blocker 为 3.0，compliance 的 min_pass 为 6.0，compliance 的 min_pass 为 6.0。

• 证据结果为 COULD-NOT-OBSERVE 或 NO-BANNER（根据 scripts/assert-evidence.sh）的维度没有分数。 请原样报告，例如：Tests: COULD-NOT-OBSERVE (assert-evidence exit 3, 0 bytes, no live pid)，并将结论标记为 BLOCKED。切勿将缺失维度计入综合分。
• 任何维度低于其 min_blocker → 无论综合分如何，结论均为 BLOCKED。 请明确报告：Security 3.2/10 (CRITICAL BLOCKER — below min_blocker 9.0)。
• 维度低于其 min_pass（但不低于 min_blocker）时，结论最高只能是 IMPROVEMENTS RECOMMENDED，不能评为 READY FOR MERGE。
• BLOCKED 结论须先列出所有触发的维度，并为每个维度说明解除阻断所需的修复。
• 项目中的 .claude/policies/verification-policy.json（参见 Policy-as-Code）可以提高这些阈值，但不能将其放宽到 rubric 默认值以下。

阈值区间和报告格式：references/grading-rubric.md（“Dimension-Level Blockers”部分）。

---

连续通过门槛（连续通过模式）

单次通过并不能证明稳定——不稳定且依赖执行顺序的测试套件可能这次通过、下次失败。使用 --streak=N 时，verify 只有在连续通过 N 次后才会宣布 READY FOR MERGE；任何未就绪的结论都会将计数重置为 0。计数会按作用范围存储在 .claude/chain/verify-streak.json 中，并在独立运行间保留。

• --streak=N（N ≥ 2；3 是合理的默认值）。若未设置，则保持今天的单次通过/失败行为不变。目标也可以来自 .claude/policies/verification-policy.json（"streak_target"）；命令行标志优先。
• 门槛位于结论之上——它绝不会放宽阻断条件，只会在连续通过次数达标前暂缓宣布“完成”。每次运行都会重新执行实际测试（不使用缓存的通过结果——独立性正是这一机制的意义所在）。
• 重置规则：任何非 READY FOR MERGE 的结论（触发阻断项、测试失败或 IMPROVEMENTS RECOMMENDED）都会将计数清零。不计部分进度。
• 结论会显示计数：STREAK 2/3 — one more green to merge，或 streak reset to 0/3 (security 3.2 < 9.0)。
• 这是 prd-to-goal quality-streak 配方（#2539）所依赖的原生机制。可将其与 /goal 循环搭配使用，但要先执行 rm 删除账本——/goal 会在本轮 verify 之前读取 until，因此过时的 met:true 会导致零次运行后直接退出（参见 streak-gate.md“过时账本防护”）。

完整协议——账本架构、运行循环、/goal 接线方式和 cover 复用：Read("references/streak-gate.md")。

---

证据与测试执行

加载详细信息：Read("rules/evidence-collection.md")，了解 git 命令、测试执行模式、指标跟踪和验证后的反馈。

---

策略即代码

加载详细信息：Read("references/policy-as-code.md")，了解配置。

在 .claude/policies/verification-policy.json 中定义验证规则：

{
  "thresholds": {
    "composite_minimum": 6.0,
    "security_minimum": 9.0,
    "coverage_minimum": 70
  },
  "blocking_rules": [
    {"dimension": "security", "below": 9.0, "action": "block"}
  ]
}

---

验证清单（已验证 vs 已声明）

Agent 评分、工具摘要，以及每一句“X 没问题 / 通过 / 已修复”，在负责人重新运行验证之前都只是声明。给出结论之前，请创建一份验证清单，为每项关键声明标记为 ✅ VERIFIED（已验证；负责人刚刚运行，并注明 command · exit · key line）、🟡 CLAIMED（已声明；由 Agent、工具或文档声称，尚未重新运行）、⬜ UNCHECKED（未检查）、⚪ WAIVED（已豁免；接受为非阻塞项，并说明原因），或 🔴 COULD-NOT-OBSERVE（无法观察；已尝试收集证据，但未观察到任何内容；引用 assert-evidence.sh 行，而处于此状态的关键项会使结论变为 BLOCKED，而不只是受限）。即使将 Agent 的“PASS”复制到报告中，也仍然只是 CLAIMED——只有负责人运行过，才能标记为 VERIFIED；子 Agent 提供的数字（价格、模型 ID、数量）在对照来源核实之前都只是 CLAIMED。

**结论规则：**任何仍标记为 🟡 CLAIMED 或 ⬜ UNCHECKED 的关键声明，都会将结论限制为 IMPROVEMENTS RECOMMENDED（建议改进），绝不能标为 READY FOR MERGE（可合并），直到该声明已标记为 ✅ VERIFIED 或 ⚪ WAIVED——这与各维度的阻塞项叠加（两者都必须解决）；在 --streak=N 模式下，会重置连续计数。

协议——声明来源、构建步骤、模板和反模式（洗白、乐观标记、遗漏）：Read("references/verification-manifest.md")。

可达性：绿色结果是否有意义？（已触达 vs 未触达）

来源说明了谁运行了测试，但不能说明通过是否有意义。一项记录为 ✅ VERIFIED · pytest · exit 0 · 214 passed 的结果可能真实无误，却毫无价值，因为测试套件通过并不能证明它触达了变更。2026-07-19 发布的一个验证器定义完整、测试充分，却从未在其调用点被调用：所有测试都在旧路径上通过了。

对于 diff 新增或修改的每项测试，清单还需标记第二项状态：

标记	含义
🟢 REACHED	运行结果表明该测试在没有变更时失败，在有变更时通过，并注明两条命令。
🟡 UNREACHED	测试通过，但从未观察到它失败。这不是证据。
⚪ WAIVED	有意接受，并用一句话说明原因。

**结论规则：**由此 diff 新增或修改、且标记为 🟡 UNREACHED 的测试，会将结论限制为 IMPROVEMENTS RECOMMENDED（建议改进），直到提供验证证据，或将该项标记为 ⚪ WAIVED。此规则与来源限制和各维度的阻塞项叠加——所有条件都必须满足。在 --streak=N 模式下，会重置连续计数。

为确保验证安全，有两条排序规则，均源于实际造成的损害：先提交，再修改（git checkout -- 会还原到 HEAD，因此修改未提交的工作会在还原时销毁变更）；以及修改调用点，而不是新单元（修改单元只能证明该单元的测试有效，却无法发现失效的调用点）。

此技能不会执行修改——它不会写入测试文件，也不会编辑源代码。验证由上游的 implement 或 cover 生成，并在此处评估；如果没有验证证据，该项将标记为 🟡 UNREACHED，结论也会受到限制。

协议——范围、5 步验证、使变异成为关键项的条件、模板和反模式（将覆盖率当作证明、批量验证、表面修改）：Read("references/reachability-proof.md")。

---

报告格式

加载 Read("references/report-template.md") 以查看完整格式。摘要：

# Feature Verification Report

**Composite Score: [N.N]/10** (Grade: [LETTER])

## Verdict
**[READY FOR MERGE | IMPROVEMENTS RECOMMENDED | BLOCKED]**

[--streak=N mode only: **STREAK [current]/[target]** — READY FOR MERGE requires the full target; any non-ready run resets to 0.]

## Verification Manifest
[✅ VERIFIED · 🟡 CLAIMED · ⬜ UNCHECKED · ⚪ WAIVED · 🔴 COULD-NOT-OBSERVE — any load-bearing 🟡/⬜ caps the verdict below READY FOR MERGE; any load-bearing 🔴 makes it BLOCKED]
[Reached: 🟢 REACHED · 🟡 UNREACHED · n/a — any 🟡 on a test this diff added/modified also caps the verdict]
| # | Load-bearing claim | Asserted by | Provenance | Reached | Evidence (cmd · exit · key line) |

完成签核（最后一步）。 报告生成后，除非用户接受，否则结论不能算作“完成”。加载 Read("../../shared/rules/done-signoff.md")，并提出其中的一个问题，三个标签保持不变："Accept done"、"Show me the evidence"、"Not satisfied"。如果有任何维度为 BLOCKED 或 FAIL，则优先说明。在用户选择 "Show me the evidence" 后，实时重新运行指定的检查，然后再次提问。在非交互式运行中（claude -p、工作流阶段）跳过提问，并将结论作为数据返回。

推送通知（CC 2.1.110+）： 对于复杂变更，验证运行超过 5 分钟很常见。最终结论就绪后，调用 PushNotification 提醒用户——他们很可能已经离开终端。需要启用 Remote Control，并配置 "Push when Claude decides"；没有此配置的用户不会收到通知，也不会报错。

PushNotification(
  message=f"ork:verify complete — {verdict} · {score}/10 · {blockers_count} blockers",
  status="proactive"
)

---

参考资料

按需使用 Read("references/<file>") 加载：

文件	内容
verification-phases.md	8 阶段工作流、Agent 启动定义、Agent Teams 模式
visual-capture.md	阶段 2.5：截图捕获、AI 视觉、图库生成
quality-model.md	评分维度与权重（统一为 8 项）
grading-rubric.md	各 Agent 的评分标准
report-template.md	完整报告格式，含视觉证据部分
verification-manifest.md	VERIFIED 与 CLAIMED 的来源记录：状态、结论规则、声明来源、模板、反模式
reachability-proof.md	REACHED 与 UNREACHED：mutate→red→restore→green 证明、优先提交和调用点规则、结论上限、反模式
alternative-comparison.md	方案比较模板
orchestration-mode.md	Agent Teams 与 Agent Tool 的比较
policy-as-code.md	验证策略配置
verification-checklist.md	飞行前检查清单
streak-gate.md	--streak=N 连续通过门槛：台账架构、重置规则、/goal 接线、封面复用

规则

按需使用 Read("rules/<file>") 加载：

文件	内容
scoring-rubric.md	综合评分、等级、结论
evidence-collection.md	证据收集与测试模式

验证门槛（横向适用）

加载 Read("../../shared/rules/verification-gate.md")——适用于所有技能中所有完成声明的最低 5 步门槛。此项不可妥协：没有最新验证证据，不得声明完成。

产出方的发现还必须满足证据重放门槛（机器可检查的 {file, line, quote} 或 {command, expected_output}，并在纳入任何结论或评分前重放）：Read("../../shared/rules/evidence-replay.md")。

反谄媚协议

加载 Read("../../shared/rules/anti-sycophancy.md")——所有验证 Agent 都应直接报告发现，避免表演式附和。“应该没问题”不是证据。“测试通过（退出码 0，47/47）”才是。

Agent 状态协议

所有验证 Agent 必须遵循标准化协议进行报告：Read("../../shared/status-protocol.md")。存在疑虑时，绝不报告 DONE。对不确定的工作，绝不默默交付。

---

Agent 协作

SendMessage（跨 Agent 发现）

跨会话回复会发到父会话（CC 2.1.248）： 子 Agent 向其他会话发送 SendMessage 时，回复会送达父会话的对话，而不是子 Agent；子 Agent 发送后继续执行，父会话读取回复。跨会话 SendMessage / ListAgents 也适用于 Bedrock、Vertex 和 Foundry，且在禁用遥测时同样可用（CC 2.1.248）。

安全 Agent 发现严重问题时，应将其分享给其他验证 Agent：

SendMessage(to="test-generator", message="Security: SQL injection in user_service.py:88 — add parameterized query test")
SendMessage(to="code-quality-reviewer", message="Security finding at user_service.py:88 — flag in review")

技能链

验证通过后，如果所有门槛均通过，则继续提交：

TaskCreate(subject="Commit verified changes", activeForm="Committing")
TaskUpdate(taskId=commit_id, addBlockedBy=[verify_task_id])
# Then: commit

会话恢复（CC 2.1.108+）： 在闲置或中断后，使用 /recap 恢复对话上下文以及检查点恢复状态。自 CC 2.1.110 起默认启用（即使禁用了遥测）。

质量标准

满足以下所有条件才算完成：

• verdict 必须恰好为 READY FOR MERGE / IMPROVEMENTS RECOMMENDED / BLOCKED 之一，并引用综合评分和每个维度的评分
• 每项作为依据的“通过／干净／已修复”声明都必须在 Verification Manifest 中标记为 VERIFIED（负责人重新运行，并引用命令、退出状态和关键行）、CLAIMED、UNCHECKED 或 WAIVED
• 测试证据必须是实际运行器的摘要行（命令、退出代码、通过数量）——绝不能转述
• diff 添加或修改的每项测试都必须带有 Reached 标记：REACHED 必须引用失败运行和通过运行；只有绿色结果的行应标记为 UNREACHED，不能作为证据
• 任何低于其 min_blocker 的维度都必须报告为 BLOCKED，无论综合评分如何
• 只有在没有仍标记为 CLAIMED/UNCHECKED 的依据性声明、没有仍标记为 UNREACHED 的 diff 新增测试（并且在 --streak=N 下满足完整连续次数要求）时，才能标记为 READY FOR MERGE
• 如果 assert-evidence.sh 的结果不是 EVIDENCE，则不得将任何维度报告为 VERIFIED；报告中必须逐字列出 COULD-NOT-OBSERVE 或 NO-BANNER 运行结果，不得悄然重新评级

相信绿色检查之前

无论故障是否存在，检查打印的内容都相同，就说明它什么也没测到；但它仍会返回结果，而该结果看起来像证据。paired-probe 技能正是为此而设，并且可由模型调用（scripts/assert-evidence.sh 是 Tests 维度的对应实现：如果运行没有产生可观察的证据，它就会拒绝给出 verdict）：它适用于任何 PASS 会决定 verdict 的检查，尤其是报告发现数量为零的扫描，或意外通过的门槛。它拒绝的是 verdict，而不是检查本身。

相关技能

• ork:implement - 完整实现与验证
• ork:review-pr - PR 专项验证
• testing-unit / testing-integration / testing-e2e - 测试执行模式
• ork:quality-gates - 质量门槛模式
• browser-tools - 用于视觉捕获的浏览器自动化

---