[E7][VERIFY] 打包真调 + keyless 兜底 + 计费/失败证据(L2/RC)

[jinjunnn]

父需求:#223。规格来源:docs/design/2026-07-22-e7-cloud-web-search-baseline.md 票 6(逐条照搬,未重新发明)。

#223 的 AC5「packaged 真调用与 keyless fallback 均有证据」当前未达成 —— 这是它的实现票。

AC

• 打包桌面端登录态下 listTools 探针见 cloud_web_search + 一次真调返回 {query,results};
• 登出态见 keyless 本地兜底;
• 计费(ledger/settle)与真实失败集(401/403/400/502 + 意外状态 LOUD、defect 消失)留证据。

边界

docs/verification/ 下 L2 harness + RC 冒烟。

out-of-scope

不做平台侧单测(平台仓自证)。

2026-07-27 裁决(owner):402 改为「采」。 本条原写「不采集 402/余额证据 —— 该路径今天不产生」,与规格来源(基线票 6 的 2026-07-25 更正:accountPreauth 已上线,402 是可采集的真实失败态,失败集须含 402)矛盾。以基线稿为准 —— 多采一项证据没有害处,漏采则要再叫 owner 一次。402 已进探针 P3.7,详见 docs/verification/2026-07-27-e7-packaged-live/README.md §6。

退出条件

证据落 docs/verification/,LIVE-PATH GATE 三项全绿;失败集证据须含 402 项 —— 若当天账户有额度/余额,402 的唯一桌面可达臂(accountPreauth)不会触发,此时 P3.7 记 not-producible + 实测账户形态 + L1 覆盖位置(不记成绿、也不静默跳过),与 403/502 同一套处置。

为什么现有证据不够(2026-07-27 核查)

仓内唯一相关证据是 docs/verification/2026-07-22-e7-deploy-probe.md,两处不足:

1. 它自己写着「唯一未做的是带真实 bearer 的端到端搜索调用(需用户登录态)」—— 它验的是前提(已部署 worker 匿名可达且 tools/list 列出 cloud_web_search、gateway 规范路径鉴权 fail-closed、打包默认 URL 与部署域同宿主),不是 packaged 真调用。
2. 它比代码旧:证据日期 2026-07-22,而 [E7] 登录态 cloud_web_search 优先，keyless websearch 兜底 #223 的实现 PR #639 于 2026-07-26 合并,其间改动了冷启动时序、失败诚实化、kill-switch。07-26 之后无新证据。

本票需基于 #639 之后的代码重新取证。

[jinjunnn]

取证准备已就绪 —— 只差你的登录态

准备件在 PR #646(docs/verification/2026-07-27-e7-packaged-live/)。打包应用已重打并真机启动验:
/Applications/alpha-code.app,alpha@94a76b669,app.asar sha256 8706d0c4…fb43ff
(装机版此前是 07-25 的 514ae7438,早于 #639,不能用于本票)。

探针未登录时拒绝产出证据并 exit 2 —— 已实测。

你要跑的(全部可复制粘贴)

# ① 用 CDP 口子重启打包应用(这是拿到 sidecar 凭证的唯一通道)
pkill -f "/Applications/alpha-code.app" ; sleep 2
ALPHA_CDP=1 open -a /Applications/alpha-code.app

② 在应用里登录(平台代付模式),等模型目录出来。

# ③ 登录态取证 —— 一条命令跑完,中途不需要你做任何判断
cd ~/app/alpha-code && git checkout verify/643-e7-packaged-live
bun docs/verification/2026-07-27-e7-packaged-live/probe.ts

④ 在应用里登出(设置 → 退出登录)。

# ⑤ 登出态 keyless 兜底取证
bun docs/verification/2026-07-27-e7-packaged-live/probe.ts --keyless

# ⑥ 结果落盘,提交
git add docs/verification/2026-07-27-e7-packaged-live/results
git commit -m "docs(verification): #643 owner 登录态取证结果"
git push

退出码:0 全绿 · 1 有必需项红 · 2 前置被挡(构建不对 / 没开 CDP / 登录态不对)。
每一项的判据、结果都在 results/latest-<phase>.json,终端也会逐行打 PASS/FAIL。

三件需要你知道的事

1)AC2(登出态 keyless 兜底)现在是红的 —— 一个真回归。
准备阶段实跑,websearch 真调返回
Web search failed: invalid response … SchemaError(SyntaxError: Unterminated string in JSON)。
上游 Exa 返回的是成功结果,客户端读截断了。脱机复现(同一请求三种读法):

读法	chunk	字节
Stream.runForEachWhile(readBoundedBody 现在的写法)	1	4,090
Stream.runForEach	3	18,063
response.text	—	18,034

runForEachWhile 在谓词恒真时仍只读第一个 chunk，于是任何多 chunk 的搜索响应被截断。
#639 之前那里是 const body = yield* response.text,属那一刀带进来的回归。
本仓 packages/opencode/src/tool/read.ts:143-145 早就记过同一个 API 的雷。

我没有在这张 VERIFY 票里改源码。修复应另开一张 CODE 票;在它修好并重新打包前,
AC2 不可能转绿 —— 你现在跑 ⑤ 会稳定看到 K1.5 红、K1.6 绿(失败是可辨的 typed failure,
不是匿名 defect,所以「defect 消失」那条仍然成立)。

2)402 采不采,需要你裁决。 本 Issue 正文写 out-of-scope 且「失败集证据无 402 项」;
但基线稿票 6 的 2026-07-25 更正写的正相反(平台 accountPreauth 已上线,402 是可采集的真实失败态,
「须含 402 项」)。探针按本 Issue 正文执行(记 out-of-scope),冲突原文同时写进结果 JSON。
你若判以基线为准,加一项即可。

3)云工具在引擎里的真实 id 可能不是 cloud_web_search。
引擎给远端 MCP 工具起名 = sanitize(server名)_sanitize(远端名),alpha 的 server 名是 cloud,
而 2026-07-22 实测该 worker tools/list 返回的远端名已经是 cloud_web_search ⇒ 引擎侧可能是
cloud_cloud_web_search(全仓 grep cloud_cloud 零命中,此前两次取证走的都是裸 MCP 客户端不经引擎)。
探针 P1.3/P1.4 记录实测值、不假定;若不一致会带 MISMATCH,那意味着所有按字面量下的闸
(permission deny、ext 的 tool.execute.before)要按真实 id 重核 —— 另开 CODE 票。

探针覆盖 vs 本票 AC

AC	覆盖项
登录态 listTools 见 cloud_web_search	P1.1(/mcp connected)· P1.2(注入的 url + {file:} token)· P1.3(LIVE-PATH GATE ① 对已部署端点做 tools/list)· P1.4(记录引擎侧真实 id)· P1.5/P1.7(本地 keyless 被抑制 = 云优先)
一次真调返回 {query,results}	P2.1(打包应用经自己的引擎真调)· P2.2(LIVE-PATH GATE ② 用应用自己的 token 直调,确定性对照)
登出态见 keyless 本地兜底	K1.1/K1.2(云暗 + keyless 还原)· K1.4(工具重新可见)· K1.5(真调)
计费(ledger/settle)	P2.3(真调前后 account.summary()/transactions() 差分)
失败集 401/400	P3.1 / P3.2 / P3.3(真打已部署 gateway)
失败集 403 / 502 / 意外状态	P3.4 / P3.5 / P3.6 —— not-producible,带理由与 L1 覆盖位置。造不出来的失败态记成绿就是假闸门
defect 消失	P3.8(代付态调被 deny 的本地 websearch → 可辨 tool error)· K1.6(keyless 失败同样可辨)
402 / 余额	P3.7 —— out-of-scope,见上面第 2 点
云侧失败不可分类	P3.9 —— 已登记缺口 alpha-platform#105

不覆盖:平台侧单测(平台仓自证);kill-switch ALPHA_WEBSEARCH_DISABLE(那是 #223 AC4,
不在本票三条 AC 内,判据在 packages/ext/src/cloud-websearch-kill.test.ts 等 L1 套件)。

[jinjunnn]

取证准备已就绪,但先别叫 owner —— 有一条真回归会让 AC2 必红

准备件全部就位(PR#646):打包产物重打于 alpha@94a76b669(装机版原本是 2026-07-25 的 514ae7438,早于 #639,按票面不可用)、探针 docs/verification/2026-07-27-e7-packaged-live/probe.ts、证据目录与 README。探针的未登录自检明确失败([BLOCKED] P0.4 … EXIT=2,零证据产出),反向 --keyless 在登录态下同样 blocked —— 故意不做自动切相位,会自己切相位的探针永远报不出「未登录」。

为什么现在不叫 owner

登出态 keyless 真调在本构建上是坏的:Web search failed: invalid response … SyntaxError: Unterminated string in JSON。上游返回的是成功结果,客户端读截断了。

脱机对同一请求三种读法实测:

读法	chunk	字节
Stream.runForEachWhile(readBoundedBody 现状)	1	4,090
Stream.runForEach	3	18,063
response.text	—	18,034

packages/opencode/src/tool/mcp-websearch.ts:272 用了 Stream.runForEachWhile,谓词恒真时仍只读第一个 chunk。这是 #489(有界读取)引入、#639 之前不存在的回归。

同一个雷本仓自己写过警告:packages/opencode/src/tool/read.ts:143-146 明写「we avoid Stream.runForEachWhile (it currently swallows the final unterminated line…)」,并改用 runForEach + tagged error 提前中止上游。同一个 API、同一个仓、第二次踩 —— 教训写在注释里,但没有任何机制阻止复发。

修复已另开 CODE 票并在做。注意它不能天真地换成 runForEach:readBoundedBody 存在的理由是 #223 R2 Major 6 的字节上限硬约束(单个 3 MiB chunk 曾实收 3,145,728 字节而上限是 2,097,152),换错了会把那个 DoS 洞放回来。

取证顺序因此调整:修复合入 → 重新打包 → 再请 owner 一次跑完。现在叫人,AC2 必红,等于让 owner 白跑一趟第二次。

三处待裁 / 待跟踪

1. 402 采不采(冲突):本票正文写 out-of-scope 且「失败集证据无 402 项」;基线稿票 6 的 2026-07-25 更正写正相反(accountPreauth 已上线,402 是可采集的真实失败态,「须含」)。裁定:采。多采一项证据没有任何害处,漏采则要再叫 owner 一次;并请把本票正文改成与基线稿一致,别让这处冲突留着。
2. 403 / 502 / 意外状态覆盖不到:桌面端只持 route-purpose 绑定令牌,造不出 scope 不足;拆生产 gateway 密钥不在探针权限内。已记 not-producible + 理由 + L1 覆盖位置,没有记成绿——这是对的做法。
3. 云工具在引擎里的真实 id 存疑:引擎给远端 MCP 工具起名 = sanitize(server名)_sanitize(远端名),alpha 的 server 名是 cloud,而 2026-07-22 实测该 worker 返回的远端名已经是 cloud_web_search ⇒ 引擎侧可能是 cloud_cloud_web_search(全仓 grep cloud_cloud 零命中——此前两次取证都走裸 MCP 客户端不经引擎)。探针 P1.3/P1.4 记录实测值不假定,不一致会带 MISMATCH;若真不一致,所有按字面量下的闸(permission deny、ext 的 tool.execute.before)都要按真实 id 重核。

[jinjunnn]

登录态四红定性(2026-07-28,只做定性与开票,未改任何代码)

被测件仍是 results/logged-in-20260728T020545Z.json 那一次(alpha@e578e00ae);
下面每条的复测都是对同一个仍在运行的引擎做只读读取,没有重跑取证、没有动登录态。

项	定性	一句话依据
P1.5	探针缺陷	判据断的是"每个 agent 的 config 键有 deny",而结果是对的:对同一运行引擎按 Permission.evaluate 的 findLast 复算,十个 agent(含 general/explore)有效判决全 deny —— 上游 explore 硬写的 websearch:"allow"(规则第 37 位)被 alpha 全局 deny(第 61 位)压过;活 sidecar 另带 ALPHA_LOCAL_WEBSEARCH_DENY=1 作纵深
P2.1 / P2.2	真缺陷(在 alpha-platform)	云 MCP 的 cloud_web_search 要求 purpose === "model.invoke",而桌面云通道令牌 ALPHA_CLOUD_TOKEN 实测 purpose: "cloud.dispatch";一个 MCP server 只带一个 Authorization,兄弟工具又要 cloud.* ⇒ 桌面端无解 → alpha-platform#131
P1.2	探针缺陷(非脱敏)	断言跑在原值上(probe.ts:575-576,redact() 只作用于 observed),假红来自观测点:引擎在加载时就解析掉 {file:}(config/variable.ts:33-61),/config 天然看不到 file ref。注入面写的确实是 Bearer {file:…},磁盘上零个配置文件带 Authorization ⇒ 不是内联 → #651
P3.8	探针缺陷	与同一次运行里 pass 的 P1.7 自相矛盾:平台模型工具表已不含 websearch,而 resolveTools(session/llm/request.ts:208-213)里用户 tools map 只能关不能开 ⇒ 模型根本没拿到该工具,toolPartsSeen: [] 是判据的必然结果,note 里"re-run"是误判 → #651
P1.4 MISMATCH	真缺陷	真实引擎 id cloud_cloud_web_search 已实测;逐处重核见 #650

README §7 那三处闸,逐处结论(判据是"拿真实 id 跑一遍",不是 grep)

1. permission deny(packages/ui-mac/src/main/cloud-web-search.ts:1/:149)—— 是空闸门。
   permission key 经 Wildcard.match 编成 ^cloud_web_search$,对真实 id 不命中。
2. ext tool.execute.before(packages/ext/src/cloud-websearch-kill.ts:183-193)—— 不是空闸门。
   isWebSearchToolId 是去符号后的 includes("websearch"),刻意无字面量,真实 id 照样命中。
   因此 [E7] 登录态 cloud_web_search 优先，keyless websearch 兜底 #223 AC4 的 kill-switch 没有被击穿 —— 这一点与本票 README §7 的预判相反,已在 [REQ-223][CODE] 云 web-search 闸改按真实引擎 id 命中 —— 现在盯的 cloud_web_search 引擎从不注册 #650 写明。
3. catalog 拼名(packages/opencode/src/mcp/catalog.ts:117-119)—— 本身正确,它就是双前缀的来源。

外加一处 §7 没列到的:packages/ext/src/cloud-contract-hook.ts:3/:6/:18-23 对
cloud_dispatch/cloud_status/cloud_await/cloud_artifacts 用精确相等,四个兄弟工具的契约校验
同样从未执行过。

对本票 AC 的影响

• AC1 不能判过:云侧真调恒 forbidden(alpha-platform#131),{query,results} 拿不到;
  且 P1.3「LIVE-PATH GATE ①」是空绿 —— alpha-cloud 的 /mcp 传输层零鉴权
  (alpha-platform#132),tools/list 通与账户无关。AC1 里"listTools 见 cloud_web_search"
  这半句需要换成一条真与账户绑定的判据。
• AC2 可以判过:登出态 keyless 十项全绿,并在新产物上独立跑了两遍。
• AC3 部分可判:401/400×2 已取真证据,402 记 not-producible 带实测账户形态(合规);
  但 "defect 消失"这一条(P3.8)当前无有效证据 —— 判据不可满足,需按 [REQ-223][CODE] 修正 E7 探针四条判据的观测点 —— 三条假红加一条空绿 #651 收敛后才算。
• 结论:本票现在不能关;阻塞项 = alpha-platform#131(部署后才能重取 AC1 证据),
  伴随 [REQ-223][CODE] 云 web-search 闸改按真实引擎 id 命中 —— 现在盯的 cloud_web_search 引擎从不注册 #650/[REQ-223][CODE] 修正 E7 探针四条判据的观测点 —— 三条假红加一条空绿 #651/alpha-platform#132。

[jinjunnn]

Blocked — Owner action, review 2026-08-03.

AC1/AC3 阻塞于 alpha-platform#131(云通道令牌 purpose=cloud.dispatch,而 cloud_web_search 要 model.invoke -> 真调恒 forbidden)+ 该修复需手动部署(本仓无部署 job);AC3 的 P3.8 判据构造上不可满足,待 alpha-code#651 收敛。AC2(登出态 keyless)已取证通过。需 owner 决定 #131 的排期。