---
name: trading-signal-aggregator
description: Aggregates and categorizes high-frequency trading signals (A/B/C/D/E) to prevent spam and manage risk.
version: 1.0.0
tags: [trading, signal, crypto, eth, btc]
---

# Trading Signal Aggregator (TSA)

This skill manages the high-frequency signal stream from multiple sources (e.g., 5912, 熬鹰, 麻吉) to prevent chat-flooding while maintaining enough granularity for profitable execution.

## ⚠️ Core Logic (The "Anti-Spam" Filter)

### 1. Signal Classification (Priority: High)
When a signal arrives, classify it immediately to determine the appropriate response/push.

| Class | Trigger Condition | Push Strategy (to QQ) |
|:---:|---|---|
| **A-加仓** | (e.get_pos_change() > 5%) OR (New high-conviction signal) | **Full Template**: Trend analysis + detailed plan. |
| **B-减仓/危险** | (Pos change < -5%) OR (Liquidation risk high) | **Full Template**: Focus on risk/exit. |
| **C-新开仓** | (First appearance of coin/trader) | **Full Template**: Light entry plan. |
| **D-持有更新** | (Pos change < 5% OR minor price/leverage adjustment) | **Minimalist**: Skip trend analysis, show current status + plan. |
| **E-多鲸对比** | (Multiple signals or cross-trader comparison) | **Comparison Template**: Side-by-side summary. |

### 2. The "Noise" Rule (Cruo/D-class)
If the change in position or price is within a certain threshold (e.g., <2% or <5% depending on context), **do not push a new message**. Instead, track it in the current session.
- If multiple signals arrive in one tick, prioritize the one with the largest absolute change or highest risk/reward.
- If a signal is "D-class" (minor adjustment), it should only be pushed if it crosses a significant threshold or if the user asks for an update.

## 📦 Templates (Reference)

### [trade-confirm] - Full Template
(Use for A, B, and C classes)
```text
⚡ 跟单建议 | {币种} {方向} {杠get_leverage}x

📊 {交易员} {仓位} {币种} (价值{总值})
入场: {入场价} | 当前: {当前价}
浮盈/亏: {盈亏} 🔥 | 强平距: {距离} ✅

📈 趋势分析
• {trend_point_1}
• {trend_point_2}

🛡️ ATR/Risk Check
• {atr_info} | {risk_status} (e.g. SL/ATR check)

🎯 跟单方案
• 入m: {入场价} (市价/参考均价)
• 止损: {止损价} ({+/-%}, {amount}, 盈亏比)
• 止盈: {止盈价} ({+/-%}, {amount})
• 仓位: {建议仓位} (e.g. 轻/中/重)

回复 Y 确认 / N 取消
```

### [trade-update] - Minimalist (D-class)
(Use for minor adjustments/noise)
```text
📊 {交易员} {仓位} {币种} (当前: {当前价})
入场: {入场价} | 状态: {status_msg} (e.get_pos_change())

🎯 跟单方案
• 入场: {入场价}
• 止损/止盈: {sl_tp_info}
• 仓位: {建议仓位}

回复 Y 确认 / N 取消
```

## 🛠️ Operational Rules (The "Golden Rule")

1. **No redundant analysis**: If the signal is a minor adjustment (D-class), do not re-calculate trend/ATR unless it's a significant enough change to warrant it.
2. **Priority**: A-class (加仓) and C-class (新开) always get full attention.
3. **Aggregator logic**: If multiple signals arrive, group them into a single response if possible (e.g., "Summary of last 3 signals").
4. **Manual override**: If the user asks for a summary or "what's next", use the current state to provide a consolidated view.
### 5. **No verbose tracking** (User correction 2026-07-02): Do NOT create statistical tables, trend analysis, or verbose summaries for D-class signals. Just process A/B/C signals with the opening skill and push to QQ. For D-class signals, simply note "跳过QQ推送" (skip QQ push) without detailed tracking tables. The user explicitly said: "有信号就用开仓技能就行了，其他不需要你统计" (Just use the opening skill for signals, no need for you to do statistics).

### 6. **"无持仓 + 减仓信号 = 静默跳过" (User correction 2026-09-20) 🔇

**踩坑现场**: 熬鹰币安实盘**重复发同一减仓信号**（同币种同方向），如果用户**没有对应持仓** → `process_signal.py` line 1131 推 `⏭️ 减仓信号: 你无 ZAMA 持仓, 跳过` 到 QQ → **1 分钟内刷屏 50+ 条相同消息**。User 原话: "这种减仓的，而我没有持仓的就不处理了"。

**正确行为** (修改 `process_signal.py`):
```python
if not our_pos:
    msg = None              # None = 不推 QQ
    outcome = 'silent_no_pos'
    # ... 后续 record_signal + dedup 正常执行, 但跳过 push_to_qq
if msg is None:
    return f"🔇 静默跳过 | {symbol} {side} {leverage}x"
```

**铁律**:
- **静默** "无持仓 + 减仓信号" 路径 = **不推 QQ** 但仍然 record_signal (用于去重)
- **不要**给静默留 push 选项 ("要不要 push 一下说明?") — 用户明令"不处理"
- **静默指标**: `outcome = 'silent_no_pos'` 写到 `_tracker_record()` 便于事后查询"为什么没动"
- **同类 D-class 静默候选**: 平仓信号无持仓、加仓信号总资产超阈值 ($1000)、调杠杆信号无持仓、减仓信号无持仓

### 7. **process_signal 失败路径仍 mark_done — 信号队列 bug (2026-09-20 实战)

**踩坑现场**: BTC 平仓信号 (queue 337, 9/21 03:12) → `close_position_raw()` 因 proxy 抽风返 None → `process_signal.py` line 868 `return "❌ 平仓失败: ..."` → **returncode = 0**（正常退出）→ `signal_queue.py` line 110 `if r.returncode == 0: mark_done(row_id, r.stdout[:200])` → **queue 标 done 但仓位没平**。

**事故代价**: BTC 1.6 张 short 5 小时持仓, 价格波动导致 UPL 从 -X% 到 **-50.5% (-$69)** — 用户手动发现前已扩大亏损 (User 原话: "是啊，为什么标记done了，亏损翻倍了")。

**根因**:
- `signal_queue.py` **只判 returncode**, 不看 result 内容
- `process_signal.py` 平仓失败分支只 `return` 字符串, **不抛异常** → returncode = 0
- `result` 列被写成 `❌ 平仓失败: ...` 但被标为 done

**当前修复 (临时)**:
1. 平仓失败必须推 QQ (line 864-866 已修, 2026-09-16)
2. **用户会看到** ❌ 推送 → 手动补救
3. **但 queue 仍然标 done** → 不会 retry → 错过的信号不会再来

**推荐修复 (TODO)**:
- `process_signal.py` 平仓失败时 `sys.exit(1)` 或 raise exception → `signal_queue.py` mark_failed
- **OR**: `signal_queue.py` 改判 returncode + 检测 stdout 是否含 `❌`/`失败`/`proxy 抽风`
- **OR**: 加 retry 字段 (retries < 3 才 fail)

**应急检测** (查历史有没有漏掉的失败):
```bash
sqlite3 ~/.hermes/trading/signal_queue.db \
  "SELECT id, substr(created_at,1,19), substr(result,1,80) \
   FROM queue WHERE result LIKE '%❌%' AND status='done' ORDER BY id DESC LIMIT 20"
# → 列出来的就是"标 done 但实际失败"的信号, 必须手动补救
```

**铁律**:
- `signal_queue.db` 的 `status` **不等于** `实际结果` — 必须看 `result` 列
- 任何 `status='done'` + `result` 含 `❌` / `失败` / `proxy 抽风` = **实际失败**, 必须 re-fetch OKX 验证
- 不要信任 cron "跑过" 的日志 — 必须 cross-check 实际仓位