# v4.5.34 (2026-07-08) advisor --execute 返回 success 但未真下单 (SSL 之外的第二类静默失败)

## 与 v4.5.27 SSL 静默失败的差异

| 维度 | v4.5.27 SSL/Timeout | v4.5.34 本次 |
|---|---|---|
| advisor 异常 | 抛 traceback / `ReadTimeout` / `SSLError` | 不抛错,stdout 是干净 JSON |
| advisor 返回 `contracts` | 0 或 N/A | **正常数值**(本次是 1.45/0.51/3.5 张) |
| advisor 返回 `auto_execute` | False / 缺字段 | **`true`** |
| 实际持仓变化 | 0 | **0** |
| frozenBal 变化 | 0 | **0** |
| agent 误判 | "⚠️ advisor 错误" 消息 | "✅ 已推送 X 张"假阳性 |

## 触发币种 (2026-07-08 实测)

1. **SPCX-USDT-SWAP** short 新开仓 → advisor 推 1.45 张,execute 返回完整 JSON,实际持仓 = 0
2. **SPCX-USDT-SWAP** long 新开仓 → advisor 推 3.5 张,execute 返回完整 JSON,实际持仓 = 0
3. **MU-USDT-SWAP** short 新开仓 → advisor 推 0.51 张 @10x,execute 返回完整 JSON,实际持仓 = 0 (后续同币种加仓信号成功了 0.52 张)

## 共同特征

1. 都是**新币种合约**(SPCX / MU 上线时间短)
2. 都是**首次/早期 execute**(OKX 合约 metadata 未完全加载)
3. advisor `auto_execute: true`,输出 JSON 含 `tp_price`/`sl_price`/`contracts`/`margin` 等所有字段
4. 实际调单路径静默丢失(可能 OKX 内部订单路由 / 撮合层 reject,但无异常抛回 ccxt)

## 二次校验硬约束 (强制)

`process_signal.py` 的 execute 路径,**绝对不能信 advisor --execute 返回的 JSON 字段**。必须反查:

```python
def verify_executed(symbol, expected_side, expected_sz_min):
    """调单后反查持仓 + 余额变化"""
    time.sleep(2)
    actual_pos = fetch_position(symbol)
    if actual_pos is None or abs(actual_pos) < expected_sz_min:
        return False  # 没真下单
    return True
```

反查不通过 → 推 "⚠️ {symbol} advisor 返回 success 但持仓未变化,需手动 retry" 到 QQ,不推"已跟单 X 张"。

## v4.5.27 的修复不覆盖这种情况

v4.5.27 只处理 SSL/Timeout/ReadTimeout 异常路径,加 retry。但 v4.5.34 是 `execute()` 返回成功但不 fill,**retcetry 没意义**(再跑一次同样的 ccxt 路径还是同样结果)。

需要的是**执行后反查持仓**,不是**执行前 retry**。

## 用户建议的修复方向 (未落地)

实测后,用户已多次确认:
- 遇到 advisor 报 SSL/Timeout → 等 30-60 秒 → retry 一次 (v4.5.27)
- 遇到 advisor 报 success 但 execute 未 fill → **必须反查持仓验证**,反查失败推"⚠️ 需手动"
- 反查通过 → 推"✅ 已跟单 X 张"(才允许)
- **这是 v4.5.18 post-execute-verification 的强化版**

## 实战 case-by-case 决策树

```
advisor --execute 返回:
├─ 抛 traceback (SSL/Timeout/ReadTimeout)
│  └─ retry 一次 (v4.5.27)
│     ├─ 成功 → 推"已跟单"
│     └─ 仍失败 → 推"⚠️ advisor 错误,需手动"
│
├─ 返回 JSON 且 contracts > 0
│  └─ 2 秒后反查 /api/v5/account/positions
│     ├─ 该币种 pos 出现 + frozenBal 增加 → 推"✅ 已跟单 X 张"
│     └─ 该币种 pos 未出现 + frozenBal 未增加 → 推"⚠️ advisor success 但未 fill"
│
└─ 返回 JSON 且 contracts = 0 (余额不足)
   └─ 推"⚠️ 余额不足,建议仓位=0张"
```

## 关键陷阱

1. **不要把 advisor 的 JSON 输出当 fill 凭证** — 它只是"已发出下单请求"的凭证
2. **不要用 advisor 输出的 order_id** — advisor 在 JSON 里没返回 order_id (v4.5.0 的 bug)
3. **不要忽视"返回 success 但没 fill"** — 这是 2026-07-08 SPCX 4 次都中招的根因
4. **小额(< 0.5 张) / 新币种** 是高发场景,要重点反查

## 关联

- v4.5.0 假阳性成功 → v4.5.18 post-execute-verification → v4.5.27 SSL silent execute → v4.5.34 execute-returns-success-no-fill
- 累计 4 个版本的 execute 失败模式,每个修复都覆盖了上一版的盲区,但不替代上一版
- 终极统一修复:`execute` 后**始终**反查持仓,不依赖 advisor 返回值判断成功