# v4.5.60 (2026-08-22) BTC持仓来源误归属 + 三连ghost execute

**本次session三个新坑**(都是v4.5.54/56/57/58/59的延伸,**但模式已稳定**,建议升级为class-level规则):

---

## 坑1: BTC持仓来源误归属(第11次"你查了持仓再来看"风险)

**事件**:
- 熬鹰BTC空单信号2026-08-15 18:46进来 → process_signal输出`✅ 已推送`
- 我回复"你无BTC持仓"
- 用户反问"你查了持仓再来看" → 重查 → **BTC short 1.47张@10x avgPx 63,198 浮盈+$2.62 实际存在**
- 进一步trace → position_locks显示锁来源是**予与实盘**,不是熬鹰

**根因**:
- 熬鹰BTC signal进来时,BTC其实早就被**予与实盘**之前的加仓信号锁住了
- process_signal报告"无BTC持仓"是错的——予与的execute成功了,signal_dedup里的锁记录指向予与
- 我没有用锁追溯方法(查position_locks + confirmed_signals),直接口头推断"无持仓"

**回复侧硬规则(升级)**:
- 任何"无持仓/有持仓/是X的"回答前,**先跑check_account.py + 查position_locks**
- 如果position_locks有该币种记录 → trader归属以锁为准,不是以"最近一条信号"为准
- 持仓数字来自**实际positions数组**,不是来自signal_history.db的confirmed_signals(silent execute路径可能漏记录)

**实战追溯三步**(验证可执行):
```bash
# 1. 实时持仓 + 余额
python3 ~/.hermes/skills/trading/okx-auto-position/scripts/check_account.py

# 2. 锁来源
sqlite3 ~/.hermes/trading/signal_history.db "SELECT * FROM position_locks WHERE symbol='BTC';"

# 3. 触发execute的信号记录
sqlite3 ~/.hermes/trading/signal_history.db "SELECT * FROM confirmed_signals WHERE symbol='BTC' ORDER BY timestamp DESC LIMIT 3;"

# 4. 原始信号文本
sqlite3 ~/.hermes/trading/signal_dedup.db "SELECT * FROM recent_signals WHERE symbol='BTC' ORDER BY timestamp DESC LIMIT 1;"
```

---

## 坑2: 三连ghost execute(trader='未知'闸形同虚设,2026-08-22 实测)

**事件**: 同一次session连出3个"信号源未知"但实际execute成功的案例:
- SKHYNIX short 0.145张@2x (avgPx 1136.88, 浮盈+$1.10)
- BTC long 0.63张@5x (avgPx 65364.9, 浮亏-$0.01)
- HYPE long 26张@2x (avgPx 72.41, 浮亏-$0.41)

**根因**(v4.5.53闸 + v4.5.54修复都失效):
- 信号从signal_queue.db中**之前积压未消费**的消息里出来
- parse_signal()提取trader失败 → fallback到'未知' → 第一道闸skip
- 但signal_queue里**之前已经走过execute**了,新进来的信号只是notification重复
- process_signal看到'未知' → skip → 但实际仓已经在那里了

**判断规则(新,class-level)**:
- trader='未知' 信号 → **先查confirmed_signals + position_locks**看有没有对应记录
- 如果有 → 那是历史execute的notification,**持仓确实存在,只是这条信号本身不触发新execute**
- 报告: `[实测确认] {品种} {方向} {张数}张 来源:{trader} 历史execute已记录,本条不重复执行`

**修复方向**:
- [ ] process_signal.py加持仓变化检测(进入时check,出时check,diff)
- [ ] trader='未知' 信号进入时: `if locked_by_existing_trader: return 'already_executed'`
- [ ] signal_queue.db 加 `executed_at` 字段 + `executed_by` 字段,避免重复execute

---

## 坑3: 矿工Jasonleo 20+ reduce信号洪流(实测模板)

**事件**: 矿工持续推BTC/ETH short减仓信号(每次1-200张不等),我处理了20+条无持仓信号。

**应对模板**(本次验证可用):
```
[矿工{trader} {symbol} {side} {action}] {pos_change}张 @ {open_px} 当前{mark_px}, 已{profit_pct}%; 你无{short/long}持仓
```

**重点**:
- 减仓信号=同方向继续加仓的动作,**不触发自动execute**(本来就是空)
- 每条都简短报,**禁止分析**(v4.5.36铁律)
- "幻象加仓"识别(单条>1000张跳变) — v4.5.59已记录,但实测发现"加仓948张"这种300-1000区间也要警惕

**新判断规则**:
- 单条加仓跳变 > 1000张 → 不解读为真实信号,推"展示性"
- 单条加仓跳变 300-1000张 → 可能是真实但**仍不自动execute**(我们本来也没锁矿工的BTC/ETH)
- 单条加仓跳变 < 300张 → 正常,简短报告

---

## 实战session净状态

USDT $127.16(无冻结)→ HYPE long 26张@2x(浮亏-$0.41)
+ 累计本次session盈利: BTC long +$17.50 + 多个ghost close盈利

---

## 部署清单(下次session第一件事)

- [ ] process_signal.py trader='未知' 进入路径加 position_locks 反查
- [ ] check_account.py 输出加 `executed_by` 字段(从position_locks提取)
- [ ] agent 写"无持仓/有持仓"前硬性触发position_locks + confirmed_signals双查
- [ ] signal_queue.db schema升级:`executed_at` + `executed_by` 字段
- [ ] 矿工Jasonleo加入signal_tracker已知trader名单(BTC/ETH short 4-6x 仅推不跟)