# v4.5.115 (2026-09-26) — 推送失败 ≠ execute失败 + 换频道端到端验证链 + token 纪律

## 三大本session铁律

### 1. 推送失败 ≠ execute失败 (实战: ONDO加仓)

**事故**:
- 09-26 00:46 用户发 ONDO 加仓信号 (893478 → 933231 ONDO)
- `process_signal.py` 返回 `❌ 推送失败` (QQ 推送到 3805472665 失败, 可能是 mihomo proxy SSL 抽风)
- **agent 第一反应差点告诉用户"信号没处理"**

**真相**:
- `check_account.py` 验证 ONDO 已从 54 张加到 **383 张** (新加 329 张@0.518, markPx 0.520, 浮盈+$8.41)
- advisor execute 成功, 只是 QQ push QQ BOT TOKEN 推不到 QQ 群
- ONDO 加仓**完全成功**

**教训**:
- `process_signal.py` 返回 `❌ 推送失败` / `⚠️ advisor错误` **不等于没成**
- 唯一金标准 = `check_account.py [SYMBOL-USDT-SWAP]` 看实际持仓/账单
- 实战: 推 `❌ 推送失败` 后必跑 `check_account.py` 再下结论
- 同时查 `/api/v5/trade/fills-history` (近 1 小时) 验证 execute 是否真的下成
- **token 纪律**: `❌ 推送失败` 不展开成"信号类型 X → 白名单通过 → advisor 报错 Y → 推送 Z 失败 → 处理"全流程 (浪费 token), 一句话 "推送失败, 已查 OKX 持仓变化确认 execute 成功" 即可

### 2. 换频道端到端验证链 (实战: ONDO 漏发)

**事故**:
- 09-24 用户问"现在用的是哪个频道", 切换到 @shipan_jiankong
- 修复 forwarder chat_id bug (v4.5.114)
- **只检查了 DB 配置, 没验证实际信号流**
- 09-26 ONDO 加仓信号**漏发** — 用户发现 ONDO 是他自己手动开的, 大怒: "本来应该你来开仓及加仓的"

**根因**:
- 频道修复后, docker 日志确实有 "Got difference for channel 2651333064 updates" (每 15 分钟轮询)
- **但没有 `[新消息|处理规则|转发|命中黑名单]` 日志** — 说明 forwarder 收到了 update 事件, message handler 没匹配 source chat
- 频道里确实有真实信号 (用 telethon `iter_messages('shipan_jiankong', limit=10)` 验证 9-23 ~ 9-24 有 10 条真实信号), 但 forwarder 完全没转发

**4 步端到端验证链**:
1. **DB 配置**: `docker exec telegram-forwarder python3 -c "import sqlite3; ..."` 读 `/app/db/forward.db` 验证:
   - `forward_rules.source_chat_id` 是否改了?
   - `chats.telegram_chat_id` 新 chat_id 加了?
   - `enable_rule=1`?
2. **Forwarder 监听器触发**: `docker logs telegram-forwarder --tail 100` 必须看到 `[处理规则|新消息|命中黑名单]` 日志. 只有 `Got difference for channel XXX updates` 不够
3. **真信号触达**: 频道有真实交易信号? 用 telethon `iter_messages('username', limit=10)` 验证
   - 容器内需 `cp /app/sessions/user.session /tmp/u.session` 解锁
   - 容器内连 TG 必带 `proxy=('socks5','127.0.0.1',7891), request_retries=1`
4. **执行闭环**: 新信号→ pipeline → OKX execute → `check_account.py` 显示仓位变动

**只改 db 不验证后续 = 假成功**

### 3. Token 纪律: 同类操作合并输出

**事故**:
- 熬鹰 ZAMA 连续 50+ 条"🐜 蚂蚁减仓" (< 1%) 信号从 9-22 一路发到 9-26
- agent 每条都回复 "蚂蚁减仓no-op" + 重复 "USDT $576" → 浪费大量 token 输出无意义结果
- 用户怒纠: "调整一下, 蚂蚁减仓尽量减少token的消耗"

**教训**:
- 同一交易员短时间内发 50+ 条同类型噪声信号 (蚂蚁减仓/连续加仓/连续汇总) 时, **必须合并输出**
- **正确做法**:
  - 第一条: 简短说明"蚂蚁减仓已用 1% min 过滤跳过"
  - 后续同类: 只输出 "无操作" 或合并到一条总览 "⚠️ 50 条蚂蚁减仓全 no-op, 已实现累计+$X"
  - 不要再重复 "USDT $576/权益$709/持仓不变" 等固定信息
- **实战黄金原则**:
  - 同类 ≤ 3 条: 逐条简短
  - 同类 4-10 条: 合并成"X 条 X 操作已 no-op"
  - 同类 > 10 条: 只回"X 条已过滤" 一行

### 4. 1000PEPE advisor BadSymbol 绕过手法

**事故**:
- 1000PEPE 加仓信号 (`1000PEPEUSDT 永续`) 触发 advisor
- advisor 内部用 `1000PEPE-USDT-SWAP` 查 symbol → OKX 上**不存在** (币安合约名) → BadSymbol 崩溃
- advisor 报 `⚠️ advisor错误`, 整条信号失败
- agent 手动 raw REST 用 `PEPE-USDT-SWAP` 开 PEPE 26 张对冲 (OKX 上 OKX 是 PEPE 不是 1000PEPE)

**教训**:
- advisor symbol 是硬编码 `1000PEPE-USDT-SWAP`, 不会自动 fuzz 到 `PEPE-USDT-SWAP`
- 同类 1000SHIB/1000FLOKI 等"1000x"币种都是 OKX 上没前缀版本
- 手动 raw REST 时主动用 `PEPE-USDT-SWAP` 而不是 `1000PEPE-USDT-SWAP`
- **TODO 待修**: advisor 加 symbol_fuzziness 映射层 (v4.5.38 已记但未实装)

### 5. 白名单配置变更纪律

**事故 (隐含)**:
- 用户多次强调"换频道不动其他" / "只动 forward_rules.source_chat_id"
- agent 仍有可能 "顺手优化" 黑名单/关键词/transit delay → 引入新风险

**纪律**:
- 任何配置变更, 只动用户明确说的部分
- 其它字段保持不变, 即使"看起来可以更优化"
- 如要建议其他优化, **单独询问**, 不自动做

### 6. 硬编码黑名单 USDT/CNY 误杀完整排查

**2026-09-22 修复** (前 session 实装, 本 session 触发了一次回归验证):
- 症状: 所有熬鹰信号 `❌ 命中硬编码黑名单, 跳过转发`
- 根因: `user_handler.py` 的 `HARD_BLACKLIST_PATTERNS` 含 `r'(?i)usdt|cny|套现'`, 而信号格式 `【币种】：BTCUSDT 永续` 必含 USDT
- 修复: `r'(?i)(usdt|cny)(?!永续|usdt).{0,4}套现|套现'` 只拦"套现"
- 修复后必跑 `iter_messages` + `process_signal.py '<测试信号>'` 验证信号真的能被转发

详见 `references/forwarder-hard-blacklist-usdt-blocking-2026-09-22.md`

## 实战顺序 (本session 修复后端到端流程)

```
用户发信号
  ↓
agent 跑 process_signal.py (推送可能失败, 视为已知噪声)
  ↓
[关键] check_account.py 验证实际 execute
  ↓ 成功
  ↳ 回复 "已 execute: SYMBOL X 张 @ avgPx, 浮盈 ±$Y, 锁已加"
  ↓ 失败
  ↳ raw REST 手动兜底 (sleep 15s 重试, 或绕过 advisor bug)
  ↓
连续同类信号合并输出
```

## 实战失误 (本session 真实发生)

| 时机 | 失误 | 教训 |
|---|---|---|
| 9-22 ZAMA 减仓 | `❌ 推送失败` 报告"信号失败" | 推送失败≠execute失败, 必查 check_account |
| 9-24 切频道 | 只改 db, 没验证执行闭环 | 4 步端到端验证链 |
| 9-24~26 ZAMA 蚂蚁 | 50+ 条逐条 no-op + 重复持仓 | 合并输出, 只回状态 |
| 9-25 用户问"现在用的哪个频道" | 没有 4 步验证, 只回答了 db 配置 | 切频道必查真信号流 |

## 参考

- v4.5.114: TG forwarder chat_id 提取 bug
- v4.5.113: classify 严格模式
- v4.5.111: 1% min 减仓过滤 + 4 熬鹰号白名单
- v4.5.110: ZAMA 蚂蚁减仓双层过滤
- v4.5.103: 4 熬鹰号首次识别为同一人
- v4.5.38: advisor 1000PEPE symbol fuzziness
- v4.5.71: whitelist.json 配置化 + query-first-no-asking
- references/forwarder-hard-blacklist-usdt-blocking-2026-09-22.md
- references/v4.5.114-2026-09-24-tg-forwarder-chat-id-extract-bug-and-channel-swap.md