Positioning / 定位
> Positioning — the independent second fail-closed layer. Correctover runs as a separate verification layer, outside the agent or gateway being verified. It is fail-closed: no valid verdict means no authorization. A platform's built-in circuit breaker is not a sufficient guarantee on its own — having logs is not the same as having runtime control. Each verdict is emitted as a detached Ed25519 verification receipt: per-action, tamper-evident and independently checkable, giving the agent era an evidence trail for accountability. Correctover is not a gateway; it is the runtime verification and evidence layer.
>
> 定位——独立的第二熔断（fail-closed）层。 Correctover 作为独立验证层运行在被验证的 Agent / 网关之外，默认 fail-closed：没有有效裁决就没有授权。平台内建熔断不能作为唯一保证——日志可查不等于运行时可控。每次裁决签发独立的 Ed25519 验证收据：逐动作、防篡改、可由第三方核验，为 agent 时代提供责任界定的证据链。Correctover 不是网关，而是运行时验证与证据层。
>
> 在线服务由 Correctover 独立托管、与被验证方分离，作为第三方第二熔断层出具签名裁决与证据。
> Online service: hosted independently by Correctover, separated from the verified party, acting as the third-party second fail-closed layer that issues signed verdicts and evidence.
电商AI退款闸门（在线付费）/ Refund Guard Online
中文 | English
这个技能解决什么问题 / What it does
AI 客服/Agent 正在从"只会回复"变成"能直接执行退款、发券、打款"。一旦它被用户话术诱导、被提示注入、算错金额或越权，真金白银就会直接流出店铺。
本技能在 Agent 真正调用退款工具之前做最后一道同步硬闸门：输入一笔订单和一个退款请求，由 Correctover 在线付费后端 返回三态裁决 allow / deny / escalate，并对每次裁决签发一张可用收据内嵌公钥离线核验的 Ed25519 收据（JCS RFC8785 规范化 + SHA-256），事后平台、商家、审计方都无法篡改或抵赖。
> 重要 / Important：本分发包是纯在线薄客户端。所有退款风控规则与裁决都在后端执行，包内没有任何离线裁决/规则引擎；后端不可达、未付费或未授权时一律 fail-closed（默认不放款），客户端绝不会自行产出 allow 结论。随包附带的 refund_receipt_verify.py 只能复核后端已经返回的裁决收据，不能替代后端做任何退款判断。
As AI customer-service agents become able to issue refunds directly, prompt injection, miscalculation or privilege abuse turn into direct monetary loss. This skill is a synchronous online-only fail-closed gate invoked immediately before a refund/payout tool call. The allow / deny / escalate decision and its tamper-evident Ed25519 receipt (JCS RFC8785 + SHA-256) are produced exclusively by the Correctover paid backend; this package ships no decision engine and cannot produce a verdict offline. The bundled receipt verifier only re-checks a receipt the backend already issued.
适用场景：电商售后 AI 客服、自动退款工作流、需要"AI 不得擅自打款"合规留痕的店铺系统。
触发场景 / When to use
- "判断这笔退款能不能自动退 / 能不能放款"
- "退款风控校验 / 退款安全闸门 / refund guard / refund decision"
- 校验是否：超实付退款、重复退款、退货未签收就退款、超 7 天无理由、禁退类目（定作/鲜活/数字/报刊）、减价超限、高风险买家、AI 大额退款
- 需要对退款裁决留存可验凭证
不做：不读取聊天记录、不做内容合规判定、不替商家制定政策、不实际打款（allow 只是"形状安全可执行"的证据，最终放款仍由商家 OMS 执行）、不在本地做任何裁决。
付费与鉴权 / Billing & auth（A2M over HTTP 402）
两条通道：
- 零售（默认，支付宝 AI 按量付费）
- 首次请求无支付凭证 → 服务端返回 HTTP 402 Payment Required，响应头Payment-Needed携带商户签名账单（商品、收款方、金额、资源、商户单号、支付截止）。
- 脚本解码展示账单，并把买方引导到官方支付宝 AI 付能力（alipay-cli/@alipay/alipay-aipay）在对话内完成支付；本脚本不实现收银、不接触支付密码/商户密钥、不伪造凭证。
- 支付后把凭证写入REFUND_GUARD_PAYMENT_PROOF（兼容REFUND_GUARD_PAY_TOKEN），重跑同一条原请求（请求体不变，服务端幂等，不重复扣款、不重复裁决计费）→ 200 +Payment-Validation。
- 账单金额以商户签名账单为准，本技能不自行定价、不在文档印价。
- 只想体验账单流程：直接运行脚本看到 402 账单即可，不付款不产生任何费用。 - 运维/集成旁路（X-API-Key，不收费、永不 402，向后兼容）
- 扣子运行时托管凭据COZE_REFUND_GUARD_API_7686098015500746752（经coze_workload_identity注入），或本地/CLI 自测REFUND_GUARD_API_KEY。
- 该通道面向平台/集成/运维，零售用户走通道 1。禁止在代码/示例中硬编码任何真实密钥。
常见问题 FAQ
Q1：什么是 402？ HTTP 402 表示"先付款再交付"。退款裁决由 Correctover 付费后端产生，首次
调用无凭证，服务端先返回带 RSA2 签名的账单（金额、收款方、截止都在账单里），核对后再付款，属正常流程。
Q2：怎么付款？Payment-Proof 从哪来？ 有 alipay-cli 且提示过期/未登录时，先 alipay-cli auth
login（支付宝扫码，仅首次）再重跑原命令；只有 npx 则执行 npx -y @alipay/alipay-aipay@latest
install 后重跑。本技能不接触支付密码、不代扣款、不臆造收款页。
Q3：拿到凭证后？会重复扣费吗？
export REFUND_GUARD_PAYMENT_PROOF=<Payment-Proof base64>
python scripts/refund_guard.py examples/case_allow_return.json
服务端按商户单号幂等，不重复扣费；也可 REFUND_GUARD_PAY_TOKEN=<凭证> <原命令> 内联传入。
Q4：提示"凭证未被接受"怎么办？ 凭证无效/过期/与账单不匹配，本次未扣款。先
unset REFUND_GUARD_PAYMENT_PROOF，重新付款取得新凭证再回填。
Q5：网络错误？ 退出码 4（fail-closed）时检查网络稍后重试，账单在 pay_before 前有效；
自定义端点检查 REFUND_GUARD_ENDPOINT。
First call without a proof → HTTP 402 + Payment-Needed (merchant-signed bill). Pay in-conversation via the official Alipay AI-pay capability, set REFUND_GUARD_PAYMENT_PROOF, and retry the identical request (idempotent). X-API-Key / platform-managed credentials are a non-billed ops path. This client never invents a cashier URL or fakes a proof.
输入 / Input
脚本接受一个 JSON（文件路径或 stdin）：
{
"trace_id": "可选，链路ID",
"order": {
"oid": "ORD100238",
"paid": 329.0,
"phase": "delivered",
"return_received": true,
"category": "normal",
"quality_verified": false,
"not_received_verified": false,
"signed_days_ago": 2,
"goods_intact": true,
"already_refunded": 0.0,
"refund_closed": false,
"buyer_risk": "normal",
"allow_small_auto_refund": false
},
"request": {
"rtype": "return_refund",
"amount": 329.0,
"reason": "no_reason",
"evidence": false,
"via_ai": true
},
"shop_config": { "escalate_amount": 1000.0 }
}
字段取值：
- phase: unshipped / in_transit / delivered
- rtype: unshipped_refund（未发货退款）/ return_refund（退货退款）/ refund_only（仅退款不退货）/ price_reduction（减价部分退款）
- reason: no_reason / quality / not_received / minor_defect
- buyer_risk: normal / suspicious
用法 / Usage
# 文件（零售：首次通常返回 402 账单；付款后带 Payment-Proof 重试）
python3 scripts/refund_guard.py case.json
# stdin
cat case.json | python3 scripts/refund_guard.py
# 机器可读
python3 scripts/refund_guard.py case.json --json
# 指向自测/灰度服务（命令行优先；也可写 --endpoint=URL 或短参 -e URL）
python3 scripts/refund_guard.py case.json --endpoint http://127.0.0.1:9000
# 付款后回填凭证重跑（幂等）
REFUND_GUARD_PAYMENT_PROOF=<Payment-Proof 凭证> python3 scripts/refund_guard.py case.json
# 单独离线复核一张后端已返回的裁决收据（不产生网络请求、不产生裁决）
python3 scripts/refund_receipt_verify.py receipt.json
- 接口地址可用环境变量
REFUND_GUARD_ENDPOINT覆盖（可填根地址或完整/v1/refund/decide，默认指向线上服务）；也可用命令行--endpoint URL（或-e URL/--endpoint=URL）覆盖，命令行优先级高于环境变量。-h/--help查看完整用法。 - 网络不可用、服务异常、未付费、未授权或收据复核失败时，调用方必须按 fail-closed 处理（默认不放款）。
--no-receipt-check可跳过本地收据复核（不推荐）。
退出码 / Exit codes
0=allow（明确允许）；1=deny 或收据复核失败（拒绝）；2=escalate（转人工）；3=待支付(402)；4=入参/网络/服务错误（fail-closed，不等于允许）。
输出 / Output
verdict：allow（硬规则全部满足，可执行）/deny（非法或必然资损，函数不应执行）/escalate（需人工或平台确认）code：机器可读裁决码，如OVERPAY、DUP_REFUND、RETURN_NOT_RECEIVED、AMOUNT_HUMAN_REQUIREDreceipt：后端 Ed25519 签名收据，含订单/请求摘要与内嵌公钥；客户端默认本地验签，篡改即失败（退出码 1）Payment-Validation（响应头，付费通道）：服务端履约确认- 必须把响应中的
disclaimer含义保留展示给用户
合规依据 / Compliance basis
- 《网络交易平台规则监督管理办法》（2026-02）：不得强制商家"退款不退货"
- GB 推荐性标准《顾客联络服务 人工与智能客户服务协同要求》（2026-09-01 实施）：退款/赔偿等最终确认须人工或规范化流程（大额、高风险一律
escalate） - 淘宝/天猫退款状态机：退货退款须在商家确认签收退货后方可放款
自动结果仅为辅助风控/合规手段，不构成退款授权、审计意见或法律意见。
