# reader 日报链路在 OpenClaw/Feishu 外层执行中被 SIGTERM 截断

## 背景
2026-04-06 在 OpenClaw 中执行 reader 日报流程时，出现多次“前半段有产物、最终产物缺失”的现象。

典型表现：
- 能生成 `raw/freshrss.raw.json`
- 能部分生成 `extracted/item-xx.extracted.json`
- 但经常拿不到：
  - `run-report.json`
  - `candidates/openclaw-delivery-payload.json`
  - `candidates/digest-brief.json`
- 外层日志多次出现 `Exec failed (..., signal SIGTERM)`

## 已确认结论

### 1. RSS 抓取与排序正常
已确认：
- FreshRSS API 正常
- 原始 raw 数据能拉到
- 默认排序正常（默认相当于 `r=d`，新到旧）

因此问题不在：
- RSS 接口
- 鉴权
- 排序规则

### 2. reader 前半段模块正常
已确认：
- 单篇 summary 能成功
- 单篇 filter + candidate 构建能成功

因此问题不在：
- summary 模块整体损坏
- candidate 构建整体损坏

### 3. 真正问题在长链路执行方式
更合理的判断是：

> 整条 reader 日报 pipeline 是长串行任务，在 OpenClaw / Feishu 当前这条外层执行链路里，容易被外层执行环境提前 `SIGTERM`。

也就是说：
- 不是 reader 总是自己抛 Python 异常退出
- 更多是脚本尚未跑完，外层执行会话先被终止

## 关键认知
当天很多排障与补跑步骤，实际不是通过稳定常驻的 MCP 服务在跑，而是直接执行 reader 仓库里的 Python 脚本：

- `python scripts/run_freshrss_pipeline.py`
- `python scripts/run_article_summaries.py`

因此更准确地说：

> 当前 reader 正式日报运行入口偏 CLI/脚本模式，而不是稳定 MCP 服务调用模式。

这也是为什么长任务更容易受外层 exec 生命周期影响。

## 为什么前几次没问题
可能原因：
1. 之前任务更短、内容更轻，刚好能在外层执行环境截断前跑完
2. 之前不是链路天然稳，而是还没撞上边界条件
3. 当前正式链路缺少稳健的断点恢复能力，因此一旦遇到较重任务，就暴露出问题

## 当天动作记录

### 做过的排查
- 确认 FreshRSS 默认排序
- 确认 raw 文件能生成
- 确认 extracted 文件能部分生成
- 单独验证单篇 summary 成功
- 单独验证单篇 filter / candidate 成功

### 做过的临时修复
当天曾尝试加入：
- `--resume`
- 中间产物复用
- 断点恢复思路

目的是降低 SIGTERM 后的损失。

### 当前状态
这些临时代码修改已全部回滚，reader 工作区已恢复干净。

## 当天结果
虽然正式链路异常，但通过手工恢复推进，最终仍补齐了：
- `candidates/openclaw-delivery-payload.json`
- `candidates/digest-brief.json`
- `run-report.json`

当天最终保留文章：
- 1
- 3

## 后续建议

### 短期
- CLI 仅保留为 debug / fallback
- 不再把正式生产日报流主要建立在长脚本入口上

### 中期
- 将 reader 作为正式 MCP 服务
- OpenClaw 正式通过 MCP tool 调用：
  - `run_freshrss_openclaw_pipeline`
  - `generate_article_summaries`

### 长期
让 reader 的正式能力具备：
- run_id
- status 查询
- resume
- 中间产物复用
- 分阶段补跑