实时后台工作验证¶

在仓库根目录运行，并已安装依赖（vp 提供固定的 Node 版本）。这会使用真实的 provider CLI 凭据并消耗模型用量：

node apps/server/scripts/verify-background-live.ts --repeat 2

每个场景都会在一个全新的临时 T3 主目录和 Git 项目中启动生产服务器。它通过经过认证的 HTTP 以及客户端所使用的同一类型化 WebSocket RPC 契约进行连接。没有替换适配器、内存数据库或预置的投影行。现有 T3 环境不会被修改。

这些场景涵盖了父级结束其回合后的委托完成、将结果投递到活动的前台命令中、原生后台命令唤醒，以及嵌套的委托结果。本地 HTTP 请求会持有实际的后台命令，直到观察到所需的父级状态。其随机响应不会包含在父级提示词中。要通过测试，智能体必须检索该结果、确认收到并完成；仅凭投递回执是不够的。

断言还会检查任务结果的发布、确认状态、类型化通知（而不是额外的用户消息条目）、运行边界，以及空的 provider 后台名册。成功的场景会重启真实服务器，并检查确认状态是否保留以及运行是否仍然处于已完成状态。这是干净重启后的持久性检查，而非投递期间崩溃恢复的证明。

使用 --scenario idle|active|native|nested、--model、--provider 和 --timeout（秒）来缩小运行范围。默认 provider 是 claudeAgent，默认模型是 claude-sonnet-4-6。native 场景专门请求 Claude 的后台 Bash 工具；不要将其视为通用的 provider 一致性测试。active 投递期望 provider 支持主动引导。缺少认证、不支持的能力、provider 故障以及模型指令违规都视为失败，绝不会跳过而通过。检查保留的 trace 以区分这些情况。

使用真实失败的 HTTP 依赖来检查验证器的失败检测：

node apps/server/scripts/verify-background-live.ts --scenario active --fail-gate

该命令必须以非零状态退出。它不能被计为通过的产品测试。

每次运行都会打印其证据目录。它保留 SQLite 数据库、原生 provider 日志、流式事件、最终投影、提示词、修订和脏文件清单，以及机器可读的判定结果。套件报告会链接每一次尝试，包括失败；重复测试不会抹去之前的失败。证据保存在本地，可能包含 provider 输出。请勿上传整个 T3 主目录。

该循环不会验证渲染后的折叠、移动端 UI、取消，或 provider 接受与回执持久化之间进程突然丢失的情况。在宣称完整的后台生命周期覆盖之前，还需要额外的场景。