验证¶

已在 macOS 上使用 Node v24.22.1（检出目录中的 .nvmrc）在 main 3d4f5565 上执行，并在 Ubuntu 24.04 虚拟机上进行了端到端运行。

门禁¶

• npm run -s check:fast、npm run -s format:check、npx knip、npm run -s scan:todos、npm run -s docs:check、 npm run -s verify:test-discovery 和 npm run -s mcp-catalog:check：均通过。
• npm run jscpd：在 4348 个文件上有 3.52% 的重复行，与 main 上一致（4341 个文件上有 3.52%）。
• npx vitest run --project domain --project services：9537 通过，6 跳过，151 失败。同样的 151 个失败在该环境中的 main 3d4f5565 上也会发生（那里有 9513 个通过）；没有新增失败。
• 运行 npm run -s test:prepare，然后运行 npm run -s test:focused -- 覆盖环境构建、导出、导出输入和 serve CLI 边界、analysis-view CLI 和 MCP 边界，以及环境 serve MCP 边界：7 个文件，67 通过，1 失败，即“projects portable artifact inventory after the original ZIP is removed”，该失败在 main 上以相同方式存在。
• npm run verify:agentenv:environment（real-agentenv 通道）在 Ubuntu 24.04 上通过，使用 agent-env 0.9.1334。

已发布捕获的等价性与覆盖率¶

已发布的 50 个由捕获构建的环境的捕获（即捕获 Evidence JSON）以及四个限定范围的 HAR 录制（EspoCRM、Ghost、NocoDB、Sonarr）均被构建了两次：一次使用 rea environment-build <capture> <dir> --json，另一次使用三个 CLI 步骤：inspect-web-network-capture --format json（仅 HAR）、inspect-analysis-view（使用 evidence-file 来源和四个默认规则），以及 environment-export --name <the build's name>。每个包中的每个文件均通过 SHA-256 进行了比较。

• 每个捕获的覆盖率等同于使用相同规则对环境状态视图进行的独立普查（按形态的读取视图，按判定和原因的写入计划）。
• 50 个捕获中有 43 个具有回环来源，并以文件名命名（grafana.capture.json 变为 grafana），同时带有 name-from-file 警告。20 个带有 credential-named-members 警告；已发布的捕获已由其流水线清洗，但其中的占位符字符串仍会被计入。
• 被扣留的写入原因：no-state-target 86，contradicted 16，unconfirmed 14，no-observation 13，unexplained-change 8，side-effect 4，body-unusable 1，incomplete-entities 1。

端到端¶

五个环境（最近一次重建于 10-23）已使用本分支的打包 CLI 在一次性 Ubuntu 虚拟机上再次构建，其中四个来自其限定范围的 HAR 录制，Metabase 来自其捕获 Evidence，命令为 rea environment-build <capture> <dir> --name <app> --package-tarball <tarball>。随后，每个包运行了其冒烟任务、根据包自身清单和捕获生成的检索评估，以及根据其记录的写入规范生成的写入评估，使用两个模型通过 LiteLLM 代理（fireworks_ai/gpt-oss-120b、fireworks_ai/glm-5p3-flash），每个任务运行一次。

• 当构建报告将其工具列为已提供时，每个写入任务在两个模型下都通过（Metabase 的卡片删除以及 Sonarr 的 release-profile 创建、更新和删除）；当构建报告将其列为已扣留时则失败：24 个写入片段中通过了 8 个，恰好是已提供的那些。在 main 上，这些应用的其余写入被扣留；已发布的 v0.2.0 版本是使用 state-target 和 write-rule 更改构建的，这些更改会提供更多的写入。
• 检索未命中是 GLM 在与三步路径字节相同的包上的回答；gpt-oss 全部 54 项通过。
• 切换为使用 environment-build 的 real-agentenv 通道，在 Ubuntu 上从全新检出通过，使用 agent-env 0.9.1334 和宿主机 Docker：五个公开用例，冒烟任务在 26.6 秒内通过，没有新容器。

审查¶

一次独立审查重建了本分支并试图反驳它。审查确认了以下场景的字节相等：pretty-printed、CRLF 和无换行符的 Evidence，跨输出部分边界的 Unicode HAR，内联和文件视图来源，浏览器场景 Evidence，以及相对路径或符号链接路径；并确认重构后的导出与 main 完全一样地处理 16 个成功和拒绝用例。其发现均已被处理：

• 凭据扫描原先会递归，一个嵌套深度达 5,000 的 4 KB 主体会导致构建崩溃；现在它使用自己的栈进行遍历，并同时扫描请求头名称、查询名称和表单主体。
• 捕获读取后的 SIGINT 原先会被忽略；现在构建会在各阶段之间检查信号，如果在 bundle 阶段之前取消，则不写入任何内容。
• 覆盖率视图不应用服务时的目录和状态准入检查；这是一项限制，文档现已说明。
• 一次 dry run 接受了构建所拒绝的 tarball；现在它会尝试打开该 tarball 以进行读取。
• 重复的 --template-rule 值曾被去重；现在会像视图拒绝它们一样予以拒绝。保存为 .json 的 HAR 会得到提示，从文件派生的名称遵循 bundle 名称规则，localhost. 为匿名，并且下一条命令会以 shell 引号包裹。
• no-observation 提示现在涵盖状态从未持有的实体的更新和删除；文档不再声称构建不启动任何进程，而是说明字节相等的条件，并指明检查排除的请求头；MCP 工具描述中指明视图。

对 main 584120e8 的评审轮次¶

该分支合并了 main 584120e8：现在导出文件的读取会像 main 一样，在构建的操作名称下通过 Result 返回权限拒绝；同时，environment-coverage 一句位于 main 的 inspect_analysis_view 描述中。四个自动化审查发现的问题已修复，每个问题都有一个在合并时会失败的测试：

• 浏览器场景中保留的头部值及其记录 URL 的查询参数，会像 HAR 那样被扫描凭证名称；清单和重放记录的投影保持不变。
• --dry-run --package-tarball 通过导出自身的常规文件作用域纳入并释放 tarball；因此，无法确认的关闭操作会被重试，然后报告为不完整的清理，并保留其所有者。
• dry run 会在读取 tarball 之后、报告计划之前检查是否已取消。
• 证据被序列化为一个精确大小的缓冲区，而不是通过复制拼接的块。这些字节仍会在认证前被解析和密封，因此认证读取的正是实际发送的内容。

在 macOS 和 Node v22.23.1 上：静态门禁通过（npm run jscpd：3.53%），npx vitest run --project domain --project services 通过（9753 个，跳过 6 个），环境边界项目通过（102 个），并且聚焦的 build、export、export-inputs、serve 和 analysis-view 边界及工具模式有效性通过（9 个文件，96 个）。在同样的 50 个捕获和四个 HAR 上重新构建后，全部 54 个包与三步路径的包逐字节相同，覆盖范围、serve 写入和警告与上一轮相同。

对 main 3d84215b 的评审轮次¶

该分支将 main 合并至 3d84215b：#6946（承载此构建器，合入于 27a4e3986），随后是 #7008。整合 #6946 采用了 main 的基于事件的凭证扫描；这也回应了审查中发现的问题：包含重复响应或内容事件的场景事务会隐藏其凭证名称。一个验证事务被记录两次后其两个内容事件均会被扫描的测试，在 0895c89bc 上失败。该整合曾删除了 0895c89bc 中针对无媒体类型表单文本记录的测试及其 body-unusable 提示；两者均已恢复，并且 main 的扫描也通过了这些测试。

在 05566419e 处，使用同样的 50 个捕获和四个 HAR 重新构建后，全部 54 个包与三步路径的包逐字节相同，它们的警告和凭证数量与上一轮相等。