codex-app-server/docs/chv-muse-p10-gap.md

对齐 Muse P10 差距表：支付安全（凭证隔离 + 结账检测 + 每次购买人工审批 + 一次性卡号）

依据：~/workspace/research_notes/meta-muse-ai-architecture-20261101-0755/report.md （官方以 Meta security.muse.ai 2026-09-08 为准；第三方转述要标注 来源性质，不得把转述写成官方承诺）。Muse 官方支付安全要求 （报告 §3.3，）：购物是最常见浏览器用例之一，Meta 对此 格外谨慎——已保存支付凭证的网站，浏览器内置结账页检测，每次都 弹出人工审批并展示确切购买详情；未购物过的网站，Muse 内置合规 钱包，首发合作 Stripe Link，Shop Pay 即将来临；支付时发行一次性 卡号给商家，而非真实卡号；该凭证绑定特定商家、特定金额、有限 有效期，即使经提示注入被盗也“不太有用”；Muse 是首个被 Link 购买 保障覆盖的 AI 代理（损坏/丢失商品免费保障、降价保障、免费退货、 符合条件购买的退货保证——保障条款以 Link 官方为准，本轨不编 细节、不实现理赔流程）。

连接器文档补充（wallet tools 的实际口径，见 /opt/hatch/connectors/stripe-link/CONNECTOR.md、 shop-pay/CONNECTOR.md、shopify-ucp/CONNECTOR.md）： Link 在一次购买获批后注资一张一次性虚拟卡，商家永远收不到真实 卡号；Shop Pay 原生路由用一次性 token、卡片路由在审批后才由浏览 器填卡字段；每次购买走独立 browser task 与独立审批；审批被拒即 停止、不扣款；结果未知时不重试、不换卡、不换路；取消待支付会 void 虚拟卡；已完成扣款无钱包退款、走商家退款流程；直接结账须 先查限额（每笔/每日/30 天，minor units、无货币、不换算），限额 不可用时不编造上限；step-up 未完成时 Link 要求用户先验证身份； 子代理、群聊、定时任务没有 wallet tools，不能替用户设 Link 或选 支付方式。本轨的结论：钱包能力在主应用运行时侧，不在 cloud/chv 代码里；本轨只做客内 agent 侧的支付安全门（检测、 审批、绑定、审计），真实钱包调用是待批准的集成点，见 §3。

本轨范围只限 P10：支付安全。起点是 P3（authd 替身凭证）与 P5 （对话外审批通道），已合入本分支（合并 feat-chv-muse-p5， 25bcd35）。不碰 P1（常驻 VM、气球、vsock）、不碰 P2（nspawn 单元、浏览器子代理本体）、不碰 P4（浏览器完全对齐——结账检测 与它接线，不重复造）、不碰 P6（privsep worker）、不碰 P7/P8/P9。 分支 feat-chv-muse-p10（从基线 06c3e17 分出，合入 P5 后 HEAD 为 25bcd35）。

0. 起点（P3/P5 已做的，本轨不重写）

• P3 cloud/chv/authd.py：CredentialVault（只活内存、白名单、 按次释放绑定 {连接器, 主机, 仓库路径, 操作}、单次 + 300 秒 TTL、审计绝无凭证值）+ mint_gitea_token；白名单只认 gitea/GITEA_TOKEN，支付不在其中——本轨不改 authd 的 白名单，支付凭证另立 PaymentCredentialVault（同模式，不 同库，见 §1），避免把支付键混进代码仓库凭证的白名单。
• P3 cloud/chv/sentinel.py：ApprovalQueue（ask 记入内存态 待审批，resolve 只标记不放行）；EgressRequest.describe() 只含连接器/目标/方法——支付审批借用这条队列记账，目标描述 为 connector=payment, method=purchase, scheme=https, host=<商家主机>, port=443, path=/checkout。
• P5 cloud/chv/approval_channel.py：对话外审批通道 （ApprovalRequest.payload() + Answer + HMAC-SHA256 签名

• verify_answer 五项校验 + resolve_via_channel 单次消费； 对话内容里出现的“批准”字样一律无效）。本轨只给它加一个 可选 details 字段（确切购买详情进 payload、供客户端 UI 展示），校验与消费逻辑一字不动。

1. 现状 vs Muse

项	现状（实测/代码为准）	Muse 目标	本轨做法
支付凭证隔离	无。cloud/chv 里没有任何支付代码；agent 若要支付，只能把卡号/钱包凭证以明文塞进环境或对话——这正是 Muse 明令禁止的形态	凭证与 OAuth token 存于用户 VM 内独立隔离容器，不在其他服务中；登录凭证存入单元外的安全凭证存储，代理不可见，仅在需要时注入	cloud/chv/payments.py：PaymentCredentialVault（只活内存、白名单 stripe-link/shop-pay、只存不透明支付方式 id + 掩码标签；原始卡号 PAN 拒绝入库——13–19 位数字串 + Luhn 校验命中即拒；按次释放绑定 {商家, 金额, 货币}、单次 + TTL；__repr__/审计绝无凭证值；forget 删凭证并作废未兑现释放）
结账页检测	无。浏览器侧 P2 的 chv-browser.py 只有 open/snapshot/screenshot/close/ping，无结账概念；P4 在做高风险表单拦截（detect_form_risk 扫无障碍树，密码/支付字段即标 form_risk），尚未提交	浏览器内置结账页检测	cloud/chv/checkout_detect.py（纯函数，标准库）：detect_checkout(url, a11y_nodes)——URL 信号（/checkout、/payment、/pay、/order-review 等）+ 无障碍树信号（卡号/有效期/安全码字段、“下单/支付”按钮、金额文本）；返回 is_checkout/confidence/reasons/form_risk/amount_text；确定性规则，不冒充模型分类器；只读 a11y 节点，绝不读原始 DOM；与 P4 的 detect_form_risk 同输入形状，P4 的 broker 在高风险表单提交前调本检测（接线点见 §4，P4 未提交前先留接口 + 测试）
每次购买人工审批	无。没有任何“购买前停下”的机制	已保存支付凭证的网站，每次都弹出人工审批并展示确切购买详情	PaymentGate.begin_purchase：结账检测未命中即拒；路由（见下行）；限额检查（见下行）；经 P5 通道发审批，payload 的 details 含确切购买详情（商家、商品、数量、金额、货币、钱包提供方）；审批只走通道答复，对话内“批准”无效；complete_purchase 先验签（verify_answer，不消费）、再验购买详情摘要（PurchaseDetails.digest()，篡改即拒且审批保持待处理）、最后 resolve_via_channel 单次消费；审批被拒即停止，不扣款
一次性卡号	无	支付时发行一次性卡号给商家而非真实卡号；绑定特定商家、特定金额、有限有效期；被盗也“不太有用”	OneTimeCard（绑定 {商家, 金额, 货币, 有效期}，单次兑现；换商家/超额/过期/复用一律拒 + 审计）；SimulatedWalletBackend（沙箱钱包：假 PAN 只在后端私有内存里，调用方只见掩码标签与 card_id；charge 只记账不联网；取消即 void）；真实一次性虚拟卡由 Link 在其侧发行（连接器文档原文），本轨的卡是绑定与兑现校验的等价模型，不是发卡行——见 §3
钱包路由	无。连接器文档有 stripe-link / shop-pay / shopify-ucp 三条路由，但 cloud/chv 里无路由逻辑	未购物过的网站走内置合规钱包，首发 Stripe Link，Shop Pay 即将来临	PaymentGate 路由：商家有已保存凭证 → 已保存凭证路由；无 → 合规钱包路由，stripe-link 优先、shop-pay 次之；两家都不支持 → 拒绝（no_wallet_route），不编造路由。来源时间差：报告写于 2026-11-01 时 Shop Pay 是“即将来临”，连接器文档（当前）显示 Shop Pay 已可用；本轨按连接器文档现状写优先级，并在此标注时间差
限额	无	（连接器文档）直接结账须先查限额：每笔/每日/30 天，minor units、无货币、不换算；限额不可用时不编造上限	SpendLimits.check(amount_minor)：三档逐项比 minor units；超任一档即拒（over_limit，审批前就拒）；三档全为 None（不可用）→ 通过但记 limits_checked=False，绝不编造上限
支付审计	无	审计轨迹展示已做与计划做的事	PaymentAudit.record：事件（payment_approval_requested / payment_approved / payment_denied / payment_completed / payment_refused / payment_cancelled / payment_card_voided）+ 允许字段（商家、金额、货币、掩码标签、pending_id、原因）；字段名命中 card_number/pan/cvv/token/secret/password 一律丢弃并标 redacted=True；卡号与凭证值绝不进审计

2. 改了什么（本轨交付物）

• cloud/chv/checkout_detect.py（新，标准库）：CheckoutVerdict + detect_checkout(url, a11y_nodes)（URL 信号 + 无障碍树信号 + 金额文本抽取；支付字段即 form_risk=payment、密码字段即 form_risk=password；页面文本只作展示信号，扣款金额永远以 PurchaseDetails 为准——页面文本是不受信任输入，见 P6 口径）。
• cloud/chv/payments.py（新，标准库）：PaymentCredentialVault + PaymentRelease + OneTimeCard + SimulatedWalletBackend + PurchaseDetails（digest() 防篡改）+ SpendLimits + PaymentAudit + PaymentGate（编排：检测 → 路由 → 限额 → 审批 → 铸卡 → 兑现校验 → 记账 → 审计）。
• 接线（cloud/chv/approval_channel.py，最小扩展）：ApprovalRequest 增加可选 details 字段，payload() 有 details 时才带上；request_approval 增加可选 details 参数；verify_answer/resolve_via_channel 一字不动；P5 既有测试不受影响。
• cloud/tests/test_chv_muse_p10_checkout.py、test_chv_muse_p10_payments.py、test_chv_muse_p10_gate.py（新测试，含否定测试：无审批不支付、审批详情被篡改即拒、一次性卡号换商家/超额/过期/复用被拒、原始卡号拒绝入库、凭证泄露面为零、对话内伪造批准无效、答复重放无效、超限额审批前即拒、限额不可用时不编造上限、取消即 void 卡）。

3. 诚实边界（本轮不宣称的东西）

1. 真实支付不做，零真实扣款：全部用沙箱/模拟钱包与假卡号 （Stripe 测试卡号段 400000000000xxxx）验证，不联网、不调 任何真实钱包接口。真实 Link / Shop Pay 集成（wallet tools 是主应用运行时能力，不在 cloud/chv 代码里）列为待用户 另行批准的事项，本轨不产生任何真实扣款、不持有任何真实 卡号。
2. 一次性卡号的“发行”在本轨是模拟：真实一次性虚拟卡由 Link 在其侧发行（连接器文档原文：“Link funds a one-time virtual card”）；本轨的 OneTimeCard 是绑定（商家 + 金额

• 货币 + 有效期）与兑现校验的等价模型，不是发卡行。不要把 “模拟钱包铸了测试卡号”写成“已接通 Link 发卡”。

3. 购买保障只作口径引用：Link 购买保障（损坏/丢失、降价、 免费退货、退货保证）的 eligibility 由 Link 判定、理赔走 Link；本轨不实现理赔流程、不承诺任何一笔购买受保障，保障 条款以 Link 官方页面为准。
4. 结账检测是启发式，不是 100% 检出：URL 特征 + 无障碍树 特征；商户自定义结账页、单页应用内嵌结账可能漏检。漏检时 的安全底线是：无审批的支付一律拒绝（PaymentGate 拒绝 任何未经审批的扣款），不宣称“所有结账页都会被拦下”。
5. 限额检查依赖钱包侧返回的限额：限额不可用时不编造上限， 只记 limits_checked=False；审批仍须过。不要把“限额未知” 写成“限额已校验通过”。
6. 钱包路由优先级按连接器文档现状：报告（2026-11-01）写 Shop Pay“即将来临”，连接器文档（当前）显示 Shop Pay 已可 用；本轨按连接器文档现状写 stripe-link 优先、shop-pay 次之， 并标注了这一时间差；若连接器文档滞后于实际，以实际钱包 能力为准。

4. 真机待验证清单（未做，排队在 round-11 与 P4～P9 之后）

1. P4 的 broker 接线：高风险表单提交前调 detect_checkout， 结账页命中时 open 导航返回 ask 并暂停（与 P4 差距表 §4 的 form_submit ask 种类对齐）。
2. 真实钱包集成（待用户另行批准）：wallet tools 的 list_payment_methods / 审批单 / approved_card 回包与 PaymentGate 的对接；payment_method_changed（用户在 审批单里换卡）时详情摘要重算与重新审批。
3. 真实商户结账页上的检测命中率抽查（Shopify / Stripe Checkout / 常见电商各一例），漏检样例记入回归。
4. 限额读取：wallet.get_user_info 的三档限额与本轨 SpendLimits 的对接；限额不可用时的表现。
5. 取消与未知结果：取消待支付 void 虚拟卡；结果未知时不重试 的端到端表现（须真实钱包侧配合）。