niceeval 0.13.1 → 0.13.2

package/docs-site/zh/explanation/assert.mdx

@@ -43,9 +43,9 @@ turn.calledTool("read_file", { count: 2 }).label("读取两次");
 
 `calledTool` 的第二参数只控制 `count`。`input`、`output` 与 `status` 条件写进 `toolMatch`；JSON 结构交给 `jsonMatch`，命令 token 交给 `commandMatch`。`notCalledTool` 直接接收同一类 matcher。
 
-## 两种 Eval
+## 两种评估用例
 
-`defineEval` 创建 Pass Eval。Boolean `matched` 进入 Attempt Verdict；`mismatched` 使最终 Verdict 为 `failed`，但不会阻止后续检查继续登记。连续 evaluator 与 Judge recipe 给出 `[0,1]` measurement；Pass Eval 使用 `.gate(n)` 才把它纳入 failed；`.atLeast(n)` 只记录局部 condition。
+`defineEval` 创建通过制评估。Boolean `matched` 进入 Attempt Verdict；`mismatched` 使最终 Verdict 为 `failed`，但不会阻止后续检查继续登记。连续 evaluator 与 Judge recipe 给出 `[0,1]` measurement；通过制评估使用 `.gate(n)` 才把它纳入 failed；`.atLeast(n)` 只记录局部 condition。
 
 ```ts
 turn.judge.autoevals.closedQA("回答是否给出可执行步骤？")
@@ -53,7 +53,7 @@ turn.judge.autoevals.closedQA("回答是否给出可执行步骤？")
   .label("步骤可执行");
 ```
 
-`defineScoreEval` 创建 Score Eval。它只有累计 `score`，没有 Attempt Verdict、总分、百分比或另一种数值单位。Assertion 默认只保存 evaluation，不计分；用 `.score(n)` 才让已有 Assertion 贡献 score。Boolean matched 贡献 `n`，mismatched 贡献 `0`；measurement `m` 贡献 `m * n`。`t.score(n)` 直接登记 contribution，返回的 handle 只能配置 `key` 与 `label`。
+`defineScoreEval` 创建计分制评估。它只有累计 `score`，没有 Attempt Verdict、总分、百分比或另一种数值单位。Assertion 默认只保存 evaluation，不计分；用 `.score(n)` 才让已有 Assertion 贡献 score。Boolean matched 贡献 `n`，mismatched 贡献 `0`；measurement `m` 贡献 `m * n`。`t.score(n)` 直接登记 contribution，返回的 handle 只能配置 `key` 与 `label`。
 
 ```ts
 turn.calledTool("search");                       // 只保存 evaluation
@@ -62,7 +62,7 @@ turn.judge.autoevals.closedQA("回答完整").score(5); // measurement 0.8 时 +
 t.score(5);                                      // 直接 +5
 ```
 
-Score Eval 的 measurement 不必 threshold 就能封口。`.atLeast(n)` 只增加局部 `met` / `below` condition，不改变 contribution。没有 `.score()` 的 Assertion 不显示 `+0`；正常没有计分项的 Score Eval 得到正式且可排名的 `score: 0`。
+计分制评估的 measurement 不必 threshold 就能封口。`.atLeast(n)` 只增加局部 `met` / `below` condition，不改变 contribution。没有 `.score()` 的 Assertion 不显示 `+0`；正常没有计分项的计分制评估得到正式且可排名的 `score: 0`。
 
 ## 控制流
 
@@ -74,17 +74,17 @@ await turn.succeeded().orStop();
 const search = await t.check(turn.message, includes("结论")).orStop();
 ```
 
-正常 stop 后，Pass Eval 仍按触发 Assertion 得到 `failed` Verdict；Score Eval 仍是 `scored`，保留正式 score 和 stop cause，因此可以排名。
+正常 stop 后，通过制评估仍按触发 Assertion 得到 `failed` Verdict；计分制评估仍是 `scored`，保留正式 score 和 stop cause，因此可以排名。
 
 ## Judge
 
-Judge recipe 调用时直接登记 measurement Assertion。Pass Eval 对同一 handle 用 `.gate(n)`，Score Eval 用 `.score(n)`；两种配置都只运行一次 Judge evaluator。材料、配置和失败语义见 [Judge](/zh/explanation/judge)。
+Judge recipe 调用时直接登记 measurement Assertion。通过制评估对同一 handle 用 `.gate(n)`，计分制评估用 `.score(n)`；两种配置都只运行一次 Judge evaluator。材料、配置和失败语义见 [Judge](/zh/explanation/judge)。
 
 ## 不可用与读取
 
 缺少 evidence 不能伪装成普通 mismatch。`unavailable` 与 `errored` 保留原因与脱敏 evidence。
 
-AssertionResult 也不是只保存成功或失败。所有入口都遵循同一个 `check(a, b)` 模型：每条结果保存 subject `a` 的安全结构化内容或稳定引用、evaluator / Match `b` 的 identity 与完整安全 config，以及 evaluation、policy 和显示所需的结构化结果。显式 `t.check(a, b)` 由作者提供两者；`loadedSkill`、`calledTool`、`succeeded` 与 Judge recipe 只是替作者取得 `a` 并构造 `b` 的特例，保存规则不变。
+AssertionResult 也不是只保存成功或失败。所有入口都遵循同一个 `check(a, b)` 模型：每条结果保存 subject `a` 的安全结构化内容或稳定引用、evaluator / Match `b` 的 identity 与完整安全 config，以及 evaluation、policy 和显示所需的结构化结果。显式 `t.check(a, b)` 由作者提供两者；`calledTool`、`succeeded` 与 Judge recipe 只是替作者取得 `a` 并构造 `b` 的特例，保存规则不变。
 
 例如 `t.check(await t.sandbox.runCommand(...), commandSucceeded())` 会保留已求值 `CommandResult` 的命令、参数、退出状态、运行时间以及脱敏 stdout / stderr 内容或引用。`calledTool(...)` 会保留其 scope 中归一化的 tool occurrence context。context 包括 operation / event identity、脱敏 input、status、output / error refs、coverage 与匹配 event refs。没有命中时也保留观察范围与候选 occurrence refs，而不是只存 `false`。
 

package/docs-site/zh/explanation/drive.mdx

@@ -8,7 +8,7 @@ description: "t.send() 和它返回的 Turn、t.sendFile()、多轮对话、t.ne
 
 ## `t.send()` 和它返回的 `Turn`
 
-`t.send(input)` 是唯一的动词。它底层调用 Adapter 的 `send(input, ctx)`，把返回值归一成一个 `Turn`：
+`t.send(input)` 是 Adapter 的基础执行动词。它底层调用 Adapter 的 `send(input, ctx)`，把返回值归一成一个 `Turn`：
 
 ```ts
 const turn = await t.send("布鲁克林今天天气怎么样?");
@@ -86,8 +86,10 @@ t.check(fresh.reply, satisfies("没有记忆泄漏", (r) => !r.includes("小明"
 有些 agent 会在一轮执行中间停下来,等审批或缺失信息,而不是直接跑完。这时这一轮以 `status: "waiting"` 结束,并带一条或多条 `input.requested` 事件说明在等什么。完整的心智模型(握手时序、Adapter 侧义务、rejected 语义)见 [HITL](/zh/explanation/hitl),这里讲评估侧怎么用。
 
 ```ts
+import { equals } from "niceeval/expect";
+
 const draft = await t.send("拟一封跟进邮件,但先别发,等我确认。");
-draft.parked().label("停在审批上");
+t.check(draft.status, equals("waiting")).label("停在审批上");
 
 const request = t.requireInputRequest({
   prompt: /是否发送/,

package/docs-site/zh/explanation/evals.mdx

@@ -4,7 +4,7 @@ sidebarTitle: "评估"
 description: "评估用例是一个测试用例：描述和 test 函数，agent-neutral。了解评估用例如何被发现、调度、评分和报告。"
 ---
 
-一个 eval 是一个可运行的测试用例。它通常由一个 `*.eval.ts` 文件导出，通过 `defineEval` 声明。
+一个评估用例是一个可运行的测试用例。它通常由一个 `*.eval.ts` 文件导出，通过 `defineEval` 声明。
 
 ## 评估用例的组成
 
@@ -31,7 +31,7 @@ export default defineEval({
 | 字段 | 说明 |
 |---|---|
 | `description` | 给人看的描述，出现在报告里 |
-| `environment` | 可选的环境需求 profile，由 sandbox spec 的 `environments` 表映射到具体预制环境 |
+| `sandbox` | 评估用例拥有的可选 Sandbox layer；Experiment 提供 template-bearing layer 时省略 |
 | `test(t)` | 交互和断言逻辑 |
 
 评估用例本身不声明用哪个 Agent——它默认保持 agent-neutral，同一个评估用例可以在不同 experiment 下跑不同 Agent。选哪个 Agent 是 experiment 的字段，不由 CLI 临时覆盖。
@@ -67,7 +67,7 @@ npx niceeval exp local weather/brooklyn
     [NiceEval](https://niceeval.com/) 收集值断言、作用域断言与 Judge measurement，并登记 score contribution。
   </Step>
   <Step title="终态">
-    Pass Eval 把断言结果折叠成最终 Verdict；Score Eval 累计正式 score。
+    通过制评估把断言结果折叠成最终 Verdict；计分制评估累计正式 score。
   </Step>
   <Step title="Report">
     控制台和 reporters 输出结果，事实同时提交进 `.niceeval/` Record 根。
@@ -76,14 +76,14 @@ npx niceeval exp local weather/brooklyn
 
 ## Verdict 类型
 
-Pass Eval 的 Attempt 终态只有四种：
+通过制评估的 Attempt 终态只有四种：
 
 <CardGroup cols={2}>
   <Card title="passed" icon="circle-check" color="#22c55e">
-    所有 Boolean Assertion 都 matched，所有 measurement 都达到 `atLeast` 阈值，并且没有执行错误。
+    所有 Boolean Assertion 都 matched，所有 gated measurement 都达到 `.gate(n)` 阈值，并且没有执行错误。
   </Card>
   <Card title="failed" icon="circle-xmark" color="#ef4444">
-    至少一个 Boolean condition mismatched，或 measurement 低于阈值。
+    至少一个 Boolean condition mismatched，或 measurement 低于明确的 `.gate(n)` 阈值。
   </Card>
   <Card title="errored" icon="triangle-exclamation" color="#f59e0b">
     执行异常、超时或作者错误，本次执行无法形成可信结论。
@@ -93,11 +93,13 @@ Pass Eval 的 Attempt 终态只有四种：
   </Card>
 </CardGroup>
 
-Score Eval 没有 Verdict；它只有累计 `score`，分数越高越好。正常没有计分项时 score 为 `0`。
+计分制评估的主读数是累计 earned score，分数越高越好。正常没有计分项时 score 为 `0`。默认报告显示 earned score，不把正常封口状态算进通过率。
+
+`.score(points)` 中的 `points` 是单项贡献权重，不是固定总分。默认报告不会把 earned score 自动换算成百分比。一个 Experiment 同时包含通过制评估与计分制评估时，报告分别显示两种主读数。
 
 ## 判定与测量值
 
-Boolean `matched` 默认进入 Verdict。连续测量值与 Judge 输出是 `[0, 1]` 的 measurement；Pass Eval 使用 `.gate(n)` 才把它纳入 failed，`.atLeast(n)` 只记录局部 condition。完整规则见 [Assert](/zh/explanation/assert)。
+Boolean `matched` 默认进入 Verdict。连续测量值与 Judge 输出是 `[0, 1]` 的 measurement；通过制评估使用 `.gate(n)` 才把它纳入 failed，`.atLeast(n)` 只记录局部 condition。完整规则见 [Assert](/zh/explanation/assert)。
 
 ## `*.eval.ts` 约定
 

package/docs-site/zh/explanation/experiment.mdx

@@ -31,11 +31,11 @@ Experiment 还有一对实验级 Hook `setup` / `teardown`：整个实验只跑
 
 要按实验在 Sandbox 里准备环境，把操作挂在 `sandbox` 字段的 spec 上。`dockerSandbox({ source: { type: "image", image: "node:24-slim" } })` 等工厂返回的对象可以链 `.setup()` / `.teardown()`。两者的边界与写法见[写实验 · 启动 Experiment 共享服务](/zh/tutorials/write-experiment#启动-experiment-共享服务)与[Sandbox provider · 生命周期](/zh/tutorials/sandbox-providers#生命周期)。
 
-同一实验里的评估用例需要不同预制环境时，评估用例只声明 provider-neutral 的 `environment` profile。sandbox spec 的 `environments` 表再把 profile 映射到 Docker image、E2B template 或 Vercel Sandbox snapshot。这样任务需求留在评估用例，provider 产物留在 spec，一个实验仍覆盖全部评估用例、对比不拆分。写法见[写实验 · 让不同评估用例使用不同预制环境](/zh/tutorials/write-experiment#让不同评估用例使用不同预制环境)。
+同一实验里的评估用例需要不同预制环境时，把对应的 template-bearing `sandbox` layer 直接放在各评估用例上，并让 Experiment 不再提供 template。重复 layer 用普通 TypeScript 辅助函数复用；这里没有 environment profile registry。同一个 Experiment 仍能覆盖全部评估用例，因为 link planning 会逐条把评估用例 layer 与 Experiment layer 配对。写法见[写实验 · 让不同评估用例使用不同预制环境](/zh/tutorials/write-experiment#让不同评估用例使用不同预制环境)。
 
 ## 矩阵对比
 
-要比较的每个变体写一个 experiment 文件：两个模型就是两个文件，只差 `model` 一行。prompt A/B 就是只差一个参数。同一批 eval 在多个 experiment 下各跑一遍，pass rate、成本、延迟就有了可比的横截面——`niceeval view` 里叠着看。适合比什么、结果怎么读，见[实验矩阵](/zh/tutorials/experiments)。
+要比较的每个变体写一个 experiment 文件：两个模型就是两个文件，只差 `model` 一行。prompt A/B 就是只差一个参数。同一批评估用例在多个 experiment 下各跑一遍，pass rate、成本、延迟就有了可比的横截面——`niceeval view` 里叠着看。适合比什么、结果怎么读，见[实验矩阵](/zh/tutorials/experiments)。
 
 ## 相关阅读
 

package/docs-site/zh/explanation/hitl.mdx

@@ -14,13 +14,13 @@ HITL（human-in-the-loop，人工介入）指 agent 在执行中间停下来，
 - **Codex**：审批模式（suggest / auto-edit 等）决定哪些动作要先经人确认，本质是同一扇门。
 - **AI SDK 应用**：工具不带 `execute` 时，工具调用会浮到前端，由界面上的人确认后把结果交回（`addToolResult`），模型再继续——这是自研应用里最常见的审批门写法。
 
-对被测对象来说，这条"停下来等人"的分支和别的行为一样需要回归：批准后该发生的事发生了吗？拒绝后真的没做吗？问错了人、停错了地方呢？但评估用例是自动跑的，里面没有人。[NiceEval](https://niceeval.com/) 的做法是把"人"折叠成三个可编排的动作：看到 agent 停了（`t.parked()`）、检查它在等什么（`t.requireInputRequest()`）、替人回答（`t.respond()`）。批准、拒绝、补充信息，从此都是能写进评估用例的路径。
+对被测对象来说，这条"停下来等人"的分支和别的行为一样需要回归：批准后该发生的事发生了吗？拒绝后真的没做吗？问错了人、停错了地方呢？但评估用例是自动跑的，里面没有人。[NiceEval](https://niceeval.com/) 的做法是把"人"折叠成三个可编排的动作：用 `t.check(turn.status, equals("waiting"))` 确认 agent 停下、用 `t.requireInputRequest()` 检查它在等什么、再用 `t.respond()` 替人回答。批准、拒绝、补充信息，从此都是能写进评估用例的路径。
 
 ## 停轮如何表达：waiting + input.requested
 
 `send` 返回的 `Turn.status` 有三个值：`"completed"`（跑完了）、`"failed"`（出错了）、`"waiting"`——**这一轮没跑完，agent 停在等人输入上**。waiting 不是失败，是挂起：回答到达后同一轮接着跑，不重发请求、不开新对话。
 
-停下的轮次还要同时说明"在等什么"：每个待回答的问题吐一条 `input.requested` 事件，带一个稳定的请求 `id`、停在哪个动作上（`action`）、可选的裁决项（`options`，如 approve / deny）。状态和事件缺一不可——`waiting` 让 eval 知道该回答了，`input.requested` 让回答有的放矢。
+停下的轮次还要同时说明"在等什么"：每个待回答的问题吐一条 `input.requested` 事件，带一个稳定的请求 `id`、停在哪个动作上（`action`）、可选的裁决项（`options`，如 approve / deny）。状态和事件缺一不可——`waiting` 让评估用例知道该回答了，`input.requested` 让回答有的放矢。
 
 ## 一次完整握手
 
@@ -36,10 +36,10 @@ HITL（human-in-the-loop，人工介入）指 agent 在执行中间停下来，
 ## 评估侧：三个动作
 
 ```ts
-import { toolMatch } from "niceeval/expect";
+import { equals, toolMatch } from "niceeval/expect";
 
 const draft = await t.send("给老板发一封周报邮件。");
-draft.parked();                                          // ① 断言这一轮停下了
+t.check(draft.status, equals("waiting"));                // ① 断言这一轮停下了
 
 const req = t.requireInputRequest({ action: "send_email" });   // ② 取出待答请求
 
@@ -47,7 +47,7 @@ await t.respond({ request: req, optionId: "approve" });  // ③ 替人回答,发
 t.calledTool(toolMatch("send_email", { status: "completed" }));
 ```
 
-- `t.parked()` 断言这一轮确实以 waiting 停下。反过来 `t.succeeded()` 在 waiting 轮上会失败——停轮是显式状态，不会被当成"跑完了"。
+- `t.check(draft.status, equals("waiting"))` 断言这一轮确实以 waiting 停下。反过来 `draft.succeeded()` 在 waiting 轮上会失败——停轮是显式状态，不会被当成"跑完了"。
 - `t.requireInputRequest(filter)` 从待处理请求里精确取一个（按 `id` / `prompt` / `action` / `optionIds` 等字段匹配），匹配到 0 个或超过 1 个都会抛，多个请求并停时靠它消歧。
 - `t.respond(...)` 回答并发出下一轮。同类请求要给同一个答案时（比如逐个批准一批改动），`t.respondAll(optionId)` 一次处理完。
 
@@ -57,13 +57,13 @@ t.calledTool(toolMatch("send_email", { status: "completed" }));
 
 HITL 对 Adapter 的全部要求就三件事——前两件发生在停下的那一轮，第三件发生在回答到达的下一轮：
 
-1. **停轮时如实返回 `status: "waiting"`**，不要把挂起报成 `"completed"`，否则 `parked()` 失效、`succeeded()` 假通过。
+1. **停轮时如实返回 `status: "waiting"`**，不要把挂起报成 `"completed"`，否则 `t.check(turn.status, equals("waiting"))` 会失败、`succeeded()` 可能假通过。
 2. **每个待回答的问题吐一条 `input.requested`**，`id` 稳定、字段尽量填全——评估侧的检查和对位全靠它们。
 3. **下一次 `send` 先交裁决、再续跑**：从 `input.responses` 按 `requestId` 把裁决交回应用（不要按顺序猜），然后接着上一轮挂起的地方继续，而不是重发请求。
 
 "挂起的现场"（比如读了一半的 SSE 流）存在本会话线的 `ctx.session` 上。Adapter 用 `createSessionSlot<Pending>()` 声明私有 slot，停轮时 `ctx.session.set(slot, pending)`，回答轮 `ctx.session.take(slot)` 取回，取到即清除。怎么和流式驱动拼起来，见[写 send](/zh/tutorials/write-send#第五步：hitl) 第五步的完整骨架。
 
-和 [NiceEval](https://niceeval.com/) 的其它能力一样，HITL 没有布尔声明：**做到了就是有**。send 返回过 `"waiting"` 并吐了 `input.requested`，`t.respond` 就能工作。没做到，eval 会在第一个 `parked()` 或 `requireInputRequest()` 上明确失败，而不是静默假通过。能力如何从构造中来，见 [Adapter](/zh/explanation/adapter#能力从哪来：构造证明，不是问卷)。
+和 [NiceEval](https://niceeval.com/) 的其它能力一样，HITL 没有布尔声明：**做到了就是有**。send 返回过 `"waiting"` 并吐了 `input.requested`，`t.respond` 就能工作。没做到，评估用例会在状态检查或 `requireInputRequest()` 上明确失败，而不是静默假通过。能力如何从构造中来，见 [Adapter](/zh/explanation/adapter#能力从哪来：构造证明，不是问卷)。
 
 ## 拒绝不是故障
 
@@ -71,7 +71,7 @@ HITL 对 Adapter 的全部要求就三件事——前两件发生在停下的那
 
 ## 哪些 agent 用不到 HITL
 
-不是每个 agent 都有这条分支，没有就整个跳过——Adapter 不用管 `waiting`，eval 里也不会出现 `t.respond`：
+不是每个 agent 都有这条分支，没有就整个跳过——Adapter 不用管 `waiting`，评估用例里也不会出现 `t.respond`：
 
 - **每轮一口气跑完的 agent**：问答、检索、翻译这类单发即回的服务，执行中没有等人的环节。
 - **审批门被关掉的运行形态**：Claude Code、Codex 产品本身是 HITL 的，但作为被测对象在 Sandbox 里通常全自动跑（跳过权限确认）——内置的 `claude-code` / `codex` / `bub` sandbox agent 就是这样，所以它们都不做 HITL。
@@ -81,7 +81,7 @@ HITL 对 Adapter 的全部要求就三件事——前两件发生在停下的那
 
 ## 相关阅读
 
-- [Drive](/zh/explanation/drive#人工介入-hitl) — 评估侧的完整用法：`t.parked()`、`t.requireInputRequest()`、`t.respond()` / `t.respondAll()`。
+- [Drive](/zh/explanation/drive#人工介入-hitl) — 评估侧的完整用法：状态检查、`t.requireInputRequest()`、`t.respond()` / `t.respondAll()`。
 - [Adapter](/zh/explanation/adapter#不同回答的入参) — 回答到 Adapter 的结构化入参，四种典型形态。
 - [写 send](/zh/tutorials/write-send) — Adapter 侧实操：typed session slot 与流式 + HITL 的完整骨架。
 - [接入你的 Agent](/zh/tutorials/connect-your-agent) — 接入全景：最小接入、参数通道与增量地图。

package/docs-site/zh/explanation/judge.mdx

@@ -44,7 +44,7 @@ t.judge.autoevals.closedQA("文档是否说明了安装和回滚？", {
 
 ## 声明 capability 和配置
 
-只有 eval 声明了 `judge` 才能创建 Judge Assertion：
+只有评估用例声明了 `judge` 才能创建 Judge Assertion：
 
 ```ts
 export default defineEval({
@@ -72,12 +72,12 @@ export default defineConfig({
 });
 ```
 
-字段优先级是 Eval 对象、Experiment、项目配置。未指定时，`baseUrl` 为 OpenAI 兼容端点，`apiKeyEnv` 为 `OPENAI_API_KEY`，`timeoutMs` 为 180000 毫秒。
+字段优先级是评估用例对象、Experiment、项目配置。未指定时，`baseUrl` 为 OpenAI 兼容端点，`apiKeyEnv` 为 `OPENAI_API_KEY`，`timeoutMs` 为 180000 毫秒。
 运行器把解析结果冻结一次，并将同一份配置用于指纹、预检和实际 evaluator。
 
 ## 阈值与分数
 
-Pass Eval 用 `.gate(n)` 把 Judge measurement 纳入 failed；`.atLeast(n)` 只记录局部 condition。
+通过制评估用 `.gate(n)` 把 Judge measurement 纳入 failed；`.atLeast(n)` 只记录局部 condition。
 
 ```ts
 const quality = turn.judge.autoevals.closedQA("回答是否准确且完整？")
@@ -88,7 +88,7 @@ await quality.orStop();
 
 `.orStop()` 是同一 handle 的 async barrier。低于阈值时它停止当前 continuation；正常 stop 后 Attempt 仍得到 `failed` Verdict。
 
-Score Eval 直接调用 `.score(n)`：measurement `m` 贡献 `m * n`。`.atLeast(n)` 只增加局部 condition，可以单独配置，也可以与 `.score(n)` 同一条 Assertion 共存。
+计分制评估直接调用 `.score(n)`：measurement `m` 贡献 `m * n`。`.atLeast(n)` 只增加局部 condition，可以单独配置，也可以与 `.score(n)` 同一条 Assertion 共存。
 
 ```ts
 turn.judge.autoevals.closedQA("回答质量如何？").score(20).atLeast(0.5);
@@ -110,6 +110,6 @@ Judge 给出的理由写入通用 `explanation`。`evidence` 只保存裁剪、
 
 ## 相关阅读
 
-- [Assertion 与 Match](/zh/explanation/assert) — 调用即登记与两种 Eval。
+- [Assertion 与 Match](/zh/explanation/assert) — 调用即登记与两种评估用例。
 - [通过制与计分制](/zh/tutorials/evaluation-kinds) — `atLeast` 与 `score` 的选择。
 - [驱动](/zh/explanation/drive) — Turn、session 与跨轮材料。

package/docs-site/zh/explanation/overview.mdx

@@ -7,7 +7,7 @@ description: "理解 Experiment、Record、Analysis 与 Report 如何组成一
 NiceEval 把评估定义、运行、已发布结果和报告分成清楚的职责。你定义评估用例与 Experiment，Runner 执行它们；完整 Run 发布到 Record；查看和分享时，Analysis 从选中的结果形成闭合值，Report 再把这些值组织成页面。
 
 ```text
-Eval 与 Experiment
+评估用例与 Experiment
         ↓
 Runner
         ↓
@@ -24,7 +24,7 @@ Report
 
 ## 评估如何运行
 
-Eval 定义任务、断言和需要的 Fixture。Experiment 选择 Eval，并声明 Agent、模型、并发、预算与其他运行条件。Adapter 连接被测系统；Sandbox 提供隔离的执行位置。
+评估用例定义任务、断言和需要的 Fixture。Experiment 选择评估用例，并声明 Agent、模型、并发、预算与其他运行条件。Adapter 连接被测系统；Sandbox 提供隔离的执行位置。
 
 Runner 为每个选中的 Experiment 建立一个 Run。Run 列出本次应有的位置，因此它定义结果计算的分母。每个位置最多有一个 Member。
 
@@ -40,7 +40,7 @@ Record 是可携带、可复制并可进入 Git 的已发布结果集。应用
 
 用户用不带 locator 或 `--run` 的命令选择仍匹配当前项目的结果，或用 locator、`--run` 选择历史事实。NiceEval 根据这个选择形成 `Sample`，它保留完整的预期范围和分母，但不允许页面重新选择或重新打开结果。
 
-`project-current` 扫描所有已发布 Run，只保留 Experiment、Eval 和执行身份仍匹配当前项目的位置。它不按时间只留一个 Run。
+`project-current` 扫描所有已发布 Run，只保留 Experiment、评估用例和执行身份仍匹配当前项目的位置。它不按时间只留一个 Run。
 
 `--run` 保留具名 Run 的完整预期范围。每个已选位置都是 `included`、`not-recorded`、`core-invalid` 或 `excluded`。选择建立框架后，缺少分析输入不会悄悄缩小分母。
 

package/docs-site/zh/explanation/runner.mdx

@@ -4,7 +4,7 @@ sidebarTitle: "运行器"
 description: "了解 Runner 怎样建立 Run、选择执行或采用 Attempt，并返回可供后续读取的 receipt。"
 ---
 
-Runner 把选中的 Experiment 和 Eval 排成一次 Invocation。它在当前进程中安排执行、显示进度，并把停稳后的业务事实写入 Record。
+Runner 把选中的 Experiment 和评估用例排成一次 Invocation。它在当前进程中安排执行、显示进度，并把停稳后的业务事实写入 Record。
 
 ## Invocation、Run 与 Attempt
 

package/docs-site/zh/index.mdx

@@ -15,11 +15,11 @@ import { DirectMode } from '/snippets/diagram-direct-mode.jsx';
 
 </div>
 
-[NiceEval](https://niceeval.com/) 是一个受 [eve](https://eve.dev) 启发的 Agent-Native 评估框架与 Harness：`defineEval` 负责写清楚测什么，Harness 负责连被测对象、跑、打分、出报告——两者合在一起，就是从写 Eval 到看结果、优化 Agent 的完整闭环。它首先追求良好的开发体验：一个项目可以在 10 分钟左右接入，评估用例文件足够直观，结果也足够容易读。
+[NiceEval](https://niceeval.com/) 是一个受 [eve](https://eve.dev) 启发的 Agent-Native 评估框架与 Harness：`defineEval` 负责写清楚测什么，Harness 负责连接被测对象、运行、评分并生成报告。两者合在一起，就是从编写评估用例到查看结果、优化 Agent 的完整闭环。它首先追求良好的开发体验：一个项目可以在 10 分钟左右接入，评估用例文件足够直观，结果也足够容易读。
 
-它也框架无关、足够通用：可以用来评估给 Claude Code / Codex 写的 coding-agent 插件、Hook 和 Skill，也可以评估你自己的 AI Agent 应用。无论你的应用基于 AI SDK、LangGraph、Pi，还是自研 agent loop，都可以通过 Adapter 接入。
+它也框架无关、足够通用：可以用来评估给 Claude Code / Codex 写的 Coding Agent 插件、Hook 和 Skill，也可以评估你自己的 AI Agent 应用。无论你的应用基于 AI SDK、LangGraph、Pi，还是自研 Agent loop，都可以通过 Adapter 接入。
 
-评估运行完成后，[NiceEval](https://niceeval.com/) 会生成易读报告和结构化 artifacts，让你能查看 agent 的行为细节，调试失败原因，并持续优化 pass rate、成本和延迟。
+评估运行完成后，[NiceEval](https://niceeval.com/) 会生成易读报告和结构化 Artifact，让你能查看 Agent 的行为细节，调试失败原因，并持续优化通过率、成本和延迟。
 
 <CardGroup cols={3}>
   <Card title="Agent Framework 接入" icon="code-branch" href="/zh/examples">

package/docs-site/zh/reference/builtin-agents.mdx

@@ -10,17 +10,17 @@ description: "NiceEval 内置的 claude-code、codex、bub 适配器分别做到
 
 | 能力 | 对应的断言 / API |
 |---|---|
-| 收发消息（基础契约） | `t.send()`（可多次调用）、`t.reply`、`turn.outputEquals` / `outputMatches`、按状态判断的 `t.succeeded()` |
-| 事件流完整性 | `calledTool` / `toolOrder` / `usedNoTools` / `maxToolCalls` / `messageIncludes` / `noFailedActions` / `event` / `eventOrder` 等整套作用域断言。**负断言（`notCalledTool` 等）有完整事件流才可信** |
+| 收发消息（基础契约） | `t.send()`（可多次调用）、`t.reply`、`t.check(turn.data, equals(...))` / `matches(...)`、按状态判断的 `t.succeeded()` |
+| 事件流完整性 | `calledTool` / `usedNoTools` / `maxToolCalls` / `noFailedActions` / `event` 等作用域断言；`toolOrder` / `eventOrder` 只在 Turn 或 Session 上接收 matcher。消息用 `t.check(turn.message, includes(...))` 或 `t.check(turn.message, pattern(...))`。**负断言（`notCalledTool` 等）有完整事件流才可信** |
 | 会话续接 | 跨轮记忆断言、`t.newSession()` 会话隔离 |
-| HITL（人工介入） | `t.parked()`、`t.requireInputRequest()`、`t.respond()` / `t.respondAll()` |
+| HITL（人工介入） | `t.check(turn.status, equals("waiting"))`、`t.requireInputRequest()`、`t.respond()` / `t.respondAll()` |
 | `tracing` | trace decoding、`niceeval view` 的调用瀑布图 |
 
 ## 三个内置 agent 分别做到哪
 
 | Agent | 收发 | 事件流 | 会话续接 | HITL | tracing | 备注 |
 |---|---|---|---|---|---|---|
-| `claude-code` | ✅ | ✅ | ✅（`claude --resume <id>`） | ❌ | ✅（`http/protobuf` → OTLP，beta 开关） | 内置 parser 自动吐 `compaction` 事件，`t.event("compaction")` 可用 |
+| `claude-code` | ✅ | ✅ | ✅（`claude --resume <id>`） | ❌ | ✅（`http/protobuf` → OTLP，beta 开关） | 内置 parser 自动吐 `compaction` 原始事件，供报告和诊断读取；当前没有公开 `eventMatch` selector |
 | `codex` | ✅ | ✅ | ✅（`codex exec resume <id>`） | ❌ | ✅（`http/json` → OTLP） | 内置 parser 自动吐 `compaction` 事件 |
 | `bub` | ✅ | ✅ | ✅（`--session-id` + tape 续接） | ❌ | ✅（`http/protobuf` → OTLP） | 内置 parser 自动吐 `compaction` 事件 |
 
@@ -44,13 +44,13 @@ description: "NiceEval 内置的 claude-code、codex、bub 适配器分别做到
 ### codex
 
 - 连接方式：Sandbox 里跑 `codex exec --json`（续接时是 `codex exec resume <id> --json`），stdout JSONL 当 transcript。命令带 `--dangerously-bypass-approvals-and-sandbox` 与 `--dangerously-bypass-hook-trust`：Sandbox 里没人能回答 codex 的交互确认，插件或 `postSetup` 装好的 hook 因此不需要交互授信就能生效。
-- 鉴权：`CODEX_API_KEY`（不是 `OPENAI_API_KEY`），可选 `CODEX_BASE_URL` 接 OpenAI 兼容代理。配置项见下方 `CodexConfig`。
+- 鉴权：`OPENAI_API_KEY`，可选 `OPENAI_BASE_URL` 接 OpenAI 兼容代理。配置项见下方 `CodexConfig`。
 - `tracing` 通过 `~/.codex/config.toml` 的 `[otel.trace_exporter.otlp-http]` 段配置，协议 `http/json`。
 
 ### bub
 
 - 连接方式：Sandbox 里跑 `bub run` + `--session-id`，从 `~/.bub/tapes/<hash>.jsonl` 读 tape 当 transcript。
-- 鉴权：`BUB_API_KEY` + `BUB_API_BASE`（OpenAI 兼容代理）。配置项见下方 `BubConfig`。
+- 鉴权：`OPENAI_API_KEY` + `OPENAI_BASE_URL`（OpenAI 兼容代理）。配置项见下方 `BubConfig`。
 - `tracing` 通过环境变量注入（`OTEL_EXPORTER_OTLP_TRACES_ENDPOINT` 等），协议 `http/protobuf`。
 - 安装走 `uv tool install`（非 npm 包），首次安装带 checkpoint 缓存以加速后续 Sandbox。
 
@@ -85,8 +85,8 @@ baseUrl?: string;
 env?: Readonly<globalThis.Record<string, string>>;
 ```
 
-Extra process environment for Claude Code. Values stay private runtime data and do not enter carry identity.
-Mirror behavior-changing non-secret values into Experiment flags or the owning Plugin identity.
+Claude Code 进程的额外环境变量。值只保留在运行时，不进入结果沿用身份。
+会改变行为的非敏感值应同时写入 Experiment flags 或所属 Plugin 的身份。
 
 #### `maxTurns`
 
@@ -168,7 +168,7 @@ preTeardown?: readonly SandboxCommand[];
 apiKey?: string;
 ```
 
-代理 / OpenAI API key。省略时读 CODEX_API_KEY env。
+代理 / OpenAI API key。省略时读 OPENAI_API_KEY env。
 
 #### `baseUrl`
 
@@ -176,7 +176,7 @@ apiKey?: string;
 baseUrl?: string;
 ```
 
-OpenAI 兼容代理 base URL(如 `https://s2a.example.com/v1`)。省略时读 CODEX_BASE_URL env。
+OpenAI 兼容代理 base URL(如 `https://s2a.example.com/v1`)。省略时读 OPENAI_BASE_URL env。
 
 #### `env`
 
@@ -187,7 +187,7 @@ env?: Readonly<globalThis.Record<string, string>>;
 注入每次 Codex CLI 进程的额外环境变量。首轮 `codex exec` 与续轮 `codex exec resume`
 使用同一份声明；Codex 启动的 lifecycle Hook、MCP 动态 header 与命令子进程都会继承。
 值只经 Sandbox command options 传入，不拼进 shell 文本或写入 setup manifest，并全部按
-潜在敏感值从 timing / execution / error 证据中脱敏。`CODEX_API_KEY` 仍由 `apiKey` 或
+潜在敏感值从 timing / execution / error 证据中脱敏。`OPENAI_API_KEY` 仍由 `apiKey` 或
 宿主同名环境变量提供，Adapter 的鉴权值会覆盖这里的同名键。
 env value 不进入 carry 身份。会改变被测行为的非敏感值必须同时声明在 Experiment flags
 或所属 Plugin identity；只轮换凭据不会让旧结果失效。
@@ -267,7 +267,7 @@ preTeardown?: readonly SandboxCommand[];
 apiKey?: string;
 ```
 
-OpenAI 兼容代理的 API key。省略时读 BUB_API_KEY env。
+OpenAI 兼容代理的 API key。省略时读 OPENAI_API_KEY env。
 
 #### `apiBase`
 
@@ -275,7 +275,7 @@ OpenAI 兼容代理的 API key。省略时读 BUB_API_KEY env。
 apiBase?: string;
 ```
 
-OpenAI 兼容代理的 base URL。省略时读 BUB_API_BASE env。
+OpenAI 兼容代理的 base URL。省略时读 OPENAI_BASE_URL env。
 
 #### `skills`
 

package/docs-site/zh/reference/capabilities.mdx

@@ -19,7 +19,7 @@ description: "Agent 的构造方式、运行时行为与必填的六通道 evide
 | `tracing`（OTLP 接收 → `niceeval view` 瀑布图） | CLI 型 Agent 配置 `tracing`。长驻应用在 config 配置固定的 `telemetry` 端口 | Span 只进时间瀑布图，不能填补行为证据缺口 |
 | 跨轮续接与 `t.newSession()` 隔离 | 用 `ctx.session.id` / `capture` 续接后端会话，或用 `ctx.session.get` / `set` 保存 Adapter 私有的强类型历史 | 会话接法决定实际行为，不从一个 evidence bit 推断 |
 | HITL（`t.respond()`） | `send` 返回 `status: "waiting"` 和 `input.requested` | 下一轮回答按结构化 request ID 对位 |
-| Compaction 可见 | 官方 parser 或完整的手写映射发出 `compaction` 事件 | `t.event("compaction")` 还要受下方 `events` 覆盖声明约束 |
+| Compaction 可见 | 官方 parser 或完整的手写映射发出 `compaction` 事件 | 原始事件进入报告与诊断；当前没有公开 `eventMatch` selector |
 
 ## 必填的六通道声明
 

package/docs-site/zh/reference/cli.mdx

@@ -71,7 +71,7 @@ npx niceeval exp list compare/codex
 npx niceeval exp list --json
 ```
 
-默认输出每个配置的 `experimentId`、描述、agent、model、attempts、选中的 eval 数和 labels。`--json` 输出单个 `niceeval.experiments` 文档，并在每项附上完整的 `selectedEvalIds`。
+默认输出每个配置的 `experimentId`、描述、agent、model、attempts、选中的评估用例数和 labels。`--json` 输出单个 `niceeval.experiments` 文档，并在每项附上完整的 `selectedEvalIds`。
 
 ### 查看一个配对的完整 Shell 与 lifecycle
 
@@ -80,7 +80,7 @@ npx niceeval debug compare/codex memory/commit0
 npx niceeval debug compare/codex memory/commit0 --json
 ```
 
-两个 selector 都必须唯一。精确 ID 优先，否则可以使用唯一前缀。Eval 只能从 Experiment 自己选中的范围里匹配；零命中或多命中会列出精确候选。
+两个 selector 都必须唯一。精确 ID 优先，否则可以使用唯一前缀。评估用例只能从 Experiment 自己选中的范围里匹配；零命中或多命中会列出精确候选。
 
 计划包含 Plugin lifecycle、author prepare、Agent ensure/setup/teardown、test、cleanup 与 Provider finalizer。能静态声明的 `shell()` / `command()` 展开为实际命令，普通 callback 标为 `opaque`。
 
@@ -136,7 +136,7 @@ E2B template name 与 Vercel snapshot ID 是 Provider 管理的任意字符串
 
 ## 常用 flags
 
-下表由 CLI 的 flag 解析表生成，表外的 flag 一律按未知 flag 报错并以非零状态退出。**没有**用于选择 Sandbox provider 的 CLI flag，也没有项目级默认 provider。请在 Eval 或 Experiment 上声明 template-bearing `SandboxLayer`，并从 `niceeval/sandbox` 导入下列工厂之一：
+下表由 CLI 的 flag 解析表生成，表外的 flag 一律按未知 flag 报错并以非零状态退出。**没有**用于选择 Sandbox provider 的 CLI flag，也没有项目级默认 provider。请在评估用例或 Experiment 上声明 template-bearing `SandboxLayer`，并从 `niceeval/sandbox` 导入下列工厂之一：
 
 - `dockerSandbox({ source: { type: "image", image } })`
 - `dockerComposeSandbox({ file, workspaceService })`
@@ -174,15 +174,19 @@ E2B template name 与 Vercel snapshot ID 是 Provider 管理的任意字符串
 | `--experiment` | string[] | `show` / `view` 命令专用：按完整 ExperimentId 收窄当前项目结果；可重复，不接受前缀或逗号列表。 |
 | `--record` | string | `show` / `view` / `accept` / `sandbox enter\|list\|stop` 共用:指定实际 Record root;CLI 不补接 `.niceeval/record` 或其它后缀。 |
 | `--run` | string[] | `show` / `view` 可重复传入 `--run`;每次按完整 RunId 增加一个显式 Run,重复 identity 去重。 |
-| `--report` | string | `show` / `view` 命令专用：内建 `overview` 或受信任的 Report module 路径。 |
+| `--report` | string | `show` / `view` 命令专用：内建 `standard` 或受信任的 Report module 路径。 |
 | `--page` | string | `show` / `view` 命令专用:选择报告的初始页;`show` 渲染该页并在尾部附其余页索引,`view` 以它作初始路由。未命中的页 id 按用法错误退出并列出可用页 id。 |
 | `--teardown` | boolean | `exp` 命令专用:补齐被强杀打断的实验级 teardown——只对选中的实验各执行一次 teardown(新进程语义),不派发 attempt、不跑 setup;没有遗留登记也照常执行。与 eval 前缀位置参数组合是用法错误。 |
+| `--recover-shared-state` | string | `exp --teardown` 专用:显式恢复一个永不自动接管的 sharedState lease；必须同时提供 --owner-token、--confirm-owner-terminated 和 --confirm-remote-quiesced。 |
+| `--owner-token` | string | `--recover-shared-state` 专用:要恢复的不可变 owner token；错误或过期 token 不会修改 lease。 |
+| `--confirm-owner-terminated` | boolean | `--recover-shared-state` 专用:确认原 owner 已终止。 |
+| `--confirm-remote-quiesced` | boolean | `--recover-shared-state` 专用:确认远端外部状态已静止。 |
 | `--dry` | boolean | 只打印本次会匹配到的 eval × 运行配置,不实际执行(人读文本或 `--json` 单文档,见「机器怎么读:--json」)。 |
 | `--force` | boolean | `sandbox prune` 专用:除 orphan 外也销毁 unverified 实例;`exp` 明确拒绝此 flag,重跑失败项或全部项请用 `--rerun` / `--rerun all`。 |
 | `--rerun` | boolean | `exp` 命令专用:重新运行失败项(裸写/failed)或全部项(all),不改变长期指纹。 |
 | `--early-exit` / `--no-early-exit` | boolean | 某个 eval 的一次 attempt 通过后,停止该 eval 剩余的 attempts;省略默认关(`attempts` 默认跑满、测完整通过率)。 |
 | `--open` / `--no-open` | boolean | `view` 命令专用:启动后自动打开浏览器(默认行为)。 |
-| `--yes` | boolean | `clean` / `migrate` 专用：确认不可逆 maintenance 动作或没有 Git restore point 的 migration。 |
+| `--yes` | boolean | `clean` / `migrate` 专用：确认不可逆 maintenance 动作或在 clean Git restore point 下执行 migration。 |
 | `--help` | boolean | 打印用法说明并退出。 |
 | `--version` | boolean | 打印 niceeval 的版本号并退出。 |
 
@@ -235,7 +239,7 @@ pnpm exec niceeval view --host 192.168.0.199
 
 打开本地结果查看器。它和 `show` 共用默认 Report 与选择规则。不带 locator 或 `--run` 的命令读取所有身份仍匹配当前项目的结果；精确 `@<AttemptLocator>` 显示该 Attempt 的默认概览；`--run` 读取指定历史 Run。NiceEval 随后形成固定 Sample、枚举全部 Page 与参数实例，并构建完整站点。
 
-没有显式 `--report` 时，`--run` 使用内建 `run-membership-overview`，精确 locator 使用 `attempt-overview`。`project-current` 才使用配置里的 Report，并在没有配置时回退到通用 `default-overview`。显式 `--report` 始终优先。Config 仍会为 Theme 和 `view` rebuild 加载；这里只说明配置里的 Report 不参与显式 Run 的默认选择。
+没有显式 `--report` 时，`--run` 使用内建 `run-membership-overview`，精确 locator 使用 `attempt-overview`。`project-current` 才使用配置里的 Report，并在没有配置时回退到内建 `standard`。显式 `--report` 始终优先。Config 仍会为 Theme 和 `view` rebuild 加载；这里只说明配置里的 Report 不参与显式 Run 的默认选择。
 
 省略 `--host` 时，`view` 只监听 `127.0.0.1`。传入具体 hostname / IP 会显式监听该地址；只写 `--host` 时则监听全部 IPv4 接口。wildcard listener 先打印 loopback URL，再打印可用接口 URL；`--page` 应用到每条 URL，自动打开浏览器只使用第一条。
 
@@ -259,23 +263,25 @@ pnpm exec niceeval show --run 01H... --report ./reports/summary.tsx --json
 
 参数 Page 的 show 路径只对请求 key 调用 `decode()`、canonical `encode()`、`load()` 与 `render()`。它不调用 `enumerate()`，也不为了查找成员资格而执行其它 Page。通过 Page 的关闭 Evidence 边界验证的 locator、identity 或 key 不属于当前 Sample 时，命令返回类型化错误。
 
-不带 locator 或 `--run` 的 `show` 规划当前项目身份，并扫描默认 Record 中全部 published Run。只有 Experiment、Eval、Attempt 序号、evaluation kind、input identity 与 config identity 仍匹配的 slot 才进入 Sample；命令不会按时间只留一个 Run。没有匹配结果时显示空 Sample，过期结果仍可用完整 `--run` 读取。
+不带 locator 或 `--run` 的 `show` 规划当前项目身份，并扫描默认 Record 中全部 published Run。只有 Experiment、评估用例、Attempt 序号、evaluation kind、input identity 与 config identity 仍匹配的 slot 才进入 Sample；命令不会按时间只留一个 Run。没有匹配结果时显示空 Sample，过期结果仍可用完整 `--run` 读取。
 
 `--run` 可重复，只读取这些显式历史 Run。`--experiment <id>` 可重复，按完整 ExperimentId 收窄当前项目目标，不能与 `--run` 合用。`exp`、不带 `--record` 的 `show` 与 `view` 默认使用同一份结果集。
 
-单个 `--run` 用于核对这一轮的 expected-slot 分母与 membership；多个 `--run` 用同一表形状比较多个固定历史边界。即使两个 Run 指向同一个 Attempt，它们也可能分别由实际执行、自动沿用或人工采用形成。`exp --json` 最后一条 receipt 的 `runIds` 是机器稳定出口；TTY 完成反馈也显示 Run ID。`accept` 的成功反馈会显示新 Run ID，但这行人读文本不是 JSON receipt 或自动化输入契约。
+单个 `--run` 用于核对这一轮计划的 Attempt 与结果；多个 `--run` 比较多个固定历史边界。即使两个 Run 指向同一个 Attempt，它们也可能分别由实际执行、自动沿用或人工采用形成。`exp --json` 最后一条 receipt 的 `runIds` 是机器稳定出口；TTY 完成反馈也显示 Run ID。`accept` 的成功反馈会显示新 Run ID，但这行人读文本不是 JSON receipt 或自动化输入契约。
 
 内建 `run-membership-overview` 固定使用 `reportId: "run-membership-overview"`、`pageId: "run-membership"` 和 route `/`。
 
-`Run membership` 表的稳定 column keys 分成三组：
+默认 Human 页使用 `Experiment`、`Eval`、`Attempt`、`Result` 与 `Details`。如果 Run 在创建 Attempt 前失败，页面先显示真实 `Run errors` 和 `N attempts not started`，不显示空通过率、空 evidence、空 Analysis notes 或内部 membership 字段。
+
+`show --json` 继续保留机器 membership 字段，稳定 column keys 分成三组：
 
 - row identity：`runId`、`slotId`。
 - Core 与 provenance：`slotState`、`memberRelation`、`sourceAttemptLocator`、`membershipState`、`membershipOutcome`。
 - Attempt 事实：`verdictState`、`verdict`。
 
-单 Run 和多 Run 都按 `runId`、`slotId` 排序；表在排序后最多显示 200 rows，并显示省略数量。
+单 Run 和多 Run 的机器 rows 都按 `runId`、`slotId` 排序；Human 的 planned attempts 与机器 rows 都最多显示 200 项，并显示省略数量。
 
-`membershipOutcome` 是内建报告给出的来源结果，值为 `carried`、`accepted`、`executed`、`not-dispatched` 或 `interrupted`。它用于说明本次位置如何得到结果。内建表是 bounded summary；已知 Attempt 的身份与证据用 `show @<AttemptLocator>` 下钻，需要其它 Run 字段时显式选择自定义 Report。
+`membershipOutcome` 是机器面给出的来源结果，值为 `carried`、`accepted`、`executed`、`not-dispatched` 或 `interrupted`。它用于说明本次位置如何得到结果。已知 Attempt 的身份与证据用 Human 页的 `Details` locator 或 `show @<AttemptLocator>` 下钻，需要其它 Run 字段时显式选择自定义 Report。
 
 选择完成后，`show` 只执行目标 Page 需要的 Measure 与领域视图。`partial`、`unsupported`、`failed` 等 Analysis 状态会随结果显示；未使用的数据问题不影响当前页面。`show --json` 是同一个单目标读取：内建 Report 返回 Host-owned 领域文档，自定义 Report 返回一个 Page 的 rendered text manifest。完整契约见[查看结果](/zh/tutorials/viewing-results)。
 
@@ -302,4 +308,4 @@ view 与静态导出都从同一完整站点版本读取 bytes。运行中的 vi
 | `2` | 运行时崩溃（未捕获异常），CLI 顶层捕获后退出。 |
 | `130` | 收到中断信号（Ctrl-C / SIGTERM）后退出。 |
 
-CI 的退出码直接来自 Pass Eval 的 Boolean conditions 与最终 Verdict；JUnit 使用同一份已封口的断言结果。
+CI 的退出码直接来自通过制评估的 Boolean conditions 与最终 Verdict；JUnit 使用同一份已封口的断言结果。