trading skills: 文档同步 (单币上限规则/平仓盈亏字段/静默规则/推送模板)

signal-confirmation-templates/references/horizontal-table-format.md

@@ -188,3 +188,40 @@ for r in a_h[:12]:
 - 单票详情 (用纵向 bullet 更清楚)
 - 推送字段 < 3 行 (表格无意义)
 - 一次性提示 (cron 启动/失败通知)
+
+---
+
+## 💰 有预算上限的信号推送: 重点分配, 不要平均分 (2026-07-30 实战)
+
+**用户原话**: "怎么跟上次的号不一样呢" / "要有重点的分配"
+
+**错** (平均分, 用户不喜):
+- "5 个候选号各买 1 元"
+- "跟单金额平均分到 3 个交易员"
+
+**对** (权重分配, 🥇🥈🥉 让用户识别重点):
+```python
+# 默认预算 (lottery 特码 / 跟单 / 做T 都用这个)
+splits = [5, 4, 3, 2, 1]  # ¥15 = 5/4/3/2/1
+for i, (code, weight) in enumerate(top5):
+    emoji = ['🥇', '🥈', '🥉', '4', '5'][i]
+    amt = splits[i]
+    L.append(f"| {emoji} {code} | ¥{amt} | 占比 {amt*100//budget}% |")
+```
+
+**用户反应**: 平均分会让用户问"怎么跟上次不一样", **直接诊断** "这次用权重排序 vs 上次临时排序" 不要防御性回避。
+
+**适用 cron**:
+- `lottery_特码.py` (¥15 = 5/4/3/2/1)
+- 币圈跟单 (`process_signal.py`)
+- 股票做 T 信号
+
+---
+
+## ⚠️ 2026-09-09 现状更新: QQ markdown 渲染可能被平台静默降级
+
+上文"QQ bot 渲染注意事项"中"Markdown 表格在 QQ bot 渲染良好"**已不完全成立**。QQ 官方 bot 的 markdown 渲染是**资质特权** (需在 QQ 开放平台报备审核); 腾讯收紧未报备 bot 权限时, `msg_type=2` 会被**静默降级**为纯文本 — API 返回 success, 消息正常发, 但表格/加粗渲染没了, 用户看到原始管道符。
+
+排查时: 代码没变 + git log 无相关提交 + API success → **平台行为, 别改 adapter/config**。给用户两个选项: (a) QQ 开放平台申请 markdown 资质 (b) 推送改纯文本对齐格式。
+
+配套排查 + Longport SDK 权限表噪声过滤见 `references/longport-noise-filter-and-push-path-2026-09-09.md`。

signal-confirmation-templates/references/longport-noise-filter-and-push-path-2026-09-09.md

@@ -0,0 +1,47 @@
+# Longport SDK 行情权限噪声过滤 + QQ 推送链路 (2026-09-09 实战)
+
+## 问题 1: Longport SDK 初始化打印行情权限表格, 淹没真实推送
+
+**现象**: `股息登记日前一天 - A股港股` cron 推送开头是 **9 张重复的行情权限表** (`| CN | LV1 Real-time Quotes |` / `| USOption | You do not have access...`), 真正的除权数据被挤到尾部。
+
+**根因**: `dividend_alert.py` 里有 2 处 `openapi.QuoteContext(config=...)` 实例化, SDK 每次 init 都往 stdout 打一张权限表 (Rust 编译, 无 verbosity 开关)。多市场扫描循环里反复触发 init → 打 9 次。
+
+**为什么不能在 Python 里关**: `longport.openapi.Config` 只有 `from_env` / `refresh_access_token`, 无 log level 配置; `QuoteContext` 是 built-in class, inspect 不到源码。
+
+**正解: shell wrapper 层 grep 过滤** (`dividend_alert_cn_hk.sh`):
+```bash
+proxychains4 -f ~/.proxychains/proxychains.conf \
+  python3 .../dividend_alert.py --market cn_hk 2>&1 \
+  | grep -v "^\[proxychains\]" \
+  | grep -vE "^\+\-\-\-.*\+$" \
+  | grep -vE "^\|\-\-\-\-" \
+  | grep -vE "^\| (US|HK|CN|USOption) +\| +[A-Za-z]"
+```
+
+注意: 除权数据表也是 markdown (`| 票 | 名称 | ...`), 但行首是**中文列名**, 不会被 `| (US|HK|CN) | [A-Za-z]` 误杀 — 该 regex 只匹配权限表那种"英文市场名 + 英文描述"的行。改过滤 regex 后**必须用上一次真实 cron output 文件回放验证** (`cat <上次output> | grep ...`) 再上线。
+
+## 问题 2: 手动 bash 跑 wrapper ≠ 推送 (no_agent cron 推送链路)
+
+cron 推送有两种机制:
+1. **no_agent cron**: stdout 非空 → hermes 自动把 stdout 推 QQ
+2. **agent-driven cron**: agent 跑完 final response 推 QQ
+
+手动 `bash wrapper.sh` 两种机制都没有 → 只有终端输出, QQ 不推。
+
+**手动补推标准流程**:
+```bash
+bash wrapper.sh > /tmp/out.txt 2>&1
+timeout 30 hermes send -t qqbot "$(cat /tmp/out.txt)"
+```
+
+**`hermes send` 可能 timeout** (gateway WS 忙) — 重试一次; state 显示 `connected` 但 send 卡死时, 查 `journalctl --user -u hermes-gateway.service | grep qqbot`。
+
+## 问题 3: agent-driven cron "没推送" 排查顺序
+
+1. `ls -lt ~/.hermes/cron/output/<job_id>/` — 看最近 run 的 .md 是否有内容
+2. wrapper 是否自带 `push_to_qq.sh` 调用 (grep 一下)
+3. gateway qqbot state (`~/.hermes/gateway_state.json` → `.platforms.qqbot.state`)
+4. 都正常但没收到 → 手动补推 (上面流程)
+
+## 版本
+- 2026-09-09: 初版 (过滤 regex 三连 + 手动补推流程)