# Cron Job: 龙头融合+确认链-21:40

**Job ID:** 4f1c7fd21ea3
**Run Time:** 2026-10-04 13:32:56
**Schedule:** 40 21 * * 1-5

## Prompt

[IMPORTANT: You are running as a scheduled cron job. DELIVERY: Your final response will be automatically delivered to the user — do NOT use send_message or try to deliver the output yourself. Just produce your report/output as your final response and the system handles the rest. SILENT: If there is genuinely nothing new to report, respond with exactly "[SILENT]" (nothing else) to suppress delivery. Never combine [SILENT] with content — either report your findings normally, or say [SILENT] and nothing more.]

## Script Output
The following data was collected by a pre-run script. Use it as context for your analysis.

```
=== 龙头融合+确认链 21:40 ===

[1/2 龙头共振榜]...
  [xinfa] 250只股票(盘感好的板块内)
🐉 龙头共振榜（0只≥4路，6路融合：起涨/低位/资金/强度/量能/突破）
今日无≥4路共振候选（已按 2/2 只完成6路评分）
  ℹ️ 本步降级告警 126 条（已从展示剔除；明细见 /tmp/evening_2140_full_20261004.log）

[2/2 龙头确认链]...
🎯 龙头确认链：共振榜 0 只候选 → 无三档介入预案（上游已产出、0只≥4路，非故障）

=== 完成（2/2 全绿；数据源降级告警 126 条）===
```

龙头共振榜6路融合+确认链。纯脚本，零LLM。

## Response

## 龙头共振榜 21:40 · 周日 2026-10-04

### 1. 榜面结果（脚本口径）
- 上游候选 **2 只**，完成 6 路评分 2/2，**0 只 ≥4 路** → 确认链无三档预案。
- 已评分：`600406 国电南瑞 3/6`、`002020 京新药业 3/6`（均 ⚪ 观察）。
- 数据日期：**最后交易日 2026-09-30**（国庆休市，数据陈旧 4 天属正常，非故障）。

### 2. 🔴 结论被修正：今晚实际应有 1 只 ≥4 路候选，榜面漏报
**数据链**：`load_pool_codes()` 返回的是 **tuple `(codes, sectors)`**（`low_launch_scanner.py:119 return unique, sectors`），而 `dragon_fusion.py:70` 写的是 `for code in load_pool_codes(self.hub)` → 对 tuple 迭代拿到两个 list → `cands[list]` 抛 `TypeError: unhashable type: 'list'` → 被同段裸 `except Exception: pass` 吞掉。

**实测复现**（stock_workspace venv，直接跑）：
```
type: tuple len: 2 | codes in tuple[0]: 164 | LOOP RAISES: TypeError unhashable type: 'list'
```
→ **持仓池 + invest/auto/watch 池 164 只今晚 0 只进入候选**，候选池只剩 preselect 的 2 只。

**补跑（把 164 只按同样 6 路打分，资金流可用=164/164，无降级）**：
```
pool scored=164 errs=0 资金流不可用=0
hits>=4: [('001206.SZ', 4, '🔥 关注')]
hit 分布: {0:26, 1:107, 2:20, 3:10, 4:1}
```
**`001206.SZ 依依股份（造纸/天津）· 收 18.62 · 60日位置 41.5% · 近5日 +7.8%（9/30 收盘）**
`低位启动✅ | 资金流入✅ | 相对强度✅ | 量能异动✅ | 起涨前夜— | 突破启动— → 4/6 🔥`

**为什么守卫没抓到**：`--cron` 的「数据完整度：候选N/完成评分M/取数失败K」只统计 `fusion()` 阶段（今晚 K=0），**不覆盖 collect_candidates 内部的异常分支和 preselect 过滤损失** —— 9/29 加的完整度留痕是半截的，这正是「上游致盲 → 报成无信号」的同类缺陷。

### 3. 126 条 westock 限频告警判定：**无致盲**（与 9/27 事故不同）
- 告警源 `data_hub.py:998`（westock CLI 返回错误载荷→返回空 df）→ `get_daily` 自动回退 tushare。
- 实测：抽 5 只告警票 `get_daily` 全部 `rows=70, last=20260930`；面板加载 **250/250 只、17500 行** → 兜底全部成功，只是多花延迟。
- 结论：**今晚 0 只≥4 路的原因不是限频，是候选池 bug。**

### 4. 待修（本 cron 为只读值班，未改代码）
| 项 | 内容 |
|---|---|
| 改动 | `dragon_fusion.py:69-71` → `codes, _ = load_pool_codes(self.hub)`，并把 `except Exception: pass` 改为记入 `self.last_errors`（上游分支异常必须可见） |
| 连带 | 同模式排查全库：`for ... in load_pool_codes(` 其他调用点 |
| 验证 | ① `_probe` 复现脚本改为不再抛 TypeError ② `python3 dragon_fusion.py --cron 30` 应显示 `候选≥164` 且输出依依股份 ③ 完整度行出现 `取数失败` 时不得报「全绿」 |

**证伪条件**：若修复后候选数仍为 2，说明 tuple 之外还有第二个静默分支 —— 上面的复现只证明了这一个，不证明全部。