# 运维决策日志

记录服务器运维层面的关键设计决策、踩坑教训。

## 架构决策

### O-2026-06-14: 独立运维日志仓库
**决策**：新建 beast/server-ops 仓库，独立于各服务仓库。
**原因**：跨服务的变动总结（如一天内 Dashboard + Caddy + cron 同时变动）不属于任何单一服务仓库。
**边界**：单服务变动记录在各服务自己的 CHANGELOG，跨服务总结记录在 server-ops。

### O-2026-06-14: 每日收尾防遗漏机制
**决策**：每天对话结束时强制执行固化检查清单。
**清单**：
1. 今日所有 Git 仓库是否 clean？
2. 跨服务总结是否写入 daily/YYYY-MM-DD.md？
3. 新确立的工程规范是否写入 decisions/ 或 MEMORY.md？
4. 各服务 CHANGELOG 是否已更新？

### O-2026-06-14: 夜间自动化收尾双任务
**决策**：在 WorkBuddy 中建立两个每日自动化任务，利用"WorkBuddy 一直开着"的特点。
**原因**：服务器 cron 能做脚本，但缺乏判断力（不知道什么该有、什么遗漏）；智能体有判断力但不能主动执行。WorkBuddy 自动化是两者的桥梁。

**任务一：每晚 23:00 固化检查** (automation-1781446224881)
- 扫描 8 个 Gitea 仓库的 git status
- 检查 CHANGELOG/DECISION_LOG 是否有今天条目
- 检查工作空间日志和 server-ops daily 是否完整
- 自动补漏 + git push + 微信通知结果

**任务二：每晚 22:15 工作报告** (automation-1781446248242)
- 读取灵感收集器 daily_digest（服务器 cron 22:00 生成）
- 读取待办系统状态
- 生成"今日工作报告"（灵感摘要+待办概览+服务器变动+明日建议）
- 通过 Server酱 推送到微信

**时间线**：
```
22:00  服务器 cron → daily_digest 生成 + git push
22:15  WorkBuddy 自动化 → 读取 digest + 待办 → 微信推送工作报告
23:00  WorkBuddy 自动化 → 全量固化检查 → 补漏 → git push → 微信通知
```

### O-2026-06-20: 音频滚动淘汰 + 本地归档分层存储

**决策**：服务器每节目只保留最新 3 集，旧集通过 `archive_old_audio.sh` 移到 `archive_pending/`，再由 `sync_archive.sh` SCP 到本地 D 盘归档。

**原因**：
- 服务器磁盘有限（59G 总量，40G 可用），不滚动物理上无法长期扩容
- 冯先生明确要求旧音频不直接删除，要保存为个人财富
- 本地 D 盘 392G 可用，足以存储大量音频

**架构**：
```
服务器 audiobooks/ (3集) → archive_pending/ (暂存) → D:/服务器备份/有声书/ (永久)
```

### O-2026-06-20: 章节排序以源端发布时间为准

**决策**：同一专辑多集章节的排序，必须依据 B站/YouTube 的 `upload_date`，不准靠文件名或主观判断。

**原因**：中文文件名排序（Unicode 码位顺序）与实际发布时间经常不一致。`【深】` vs `【妖】` 在中文排序中【深】靠前，但视频发布顺序是【妖】先于【深】。

**实施**：下载时 `--print upload_date` 记录源端时间，按 upload_date 升序排列生成 01-N 前缀。

### O-2026-06-20: 多部门工作空间拆分

**决策**：从单一 Claw 工作空间拆分为 6 个独立工作空间：
| 部门 | 路径 | 职责 |
|:---|:---|:---|
| 主任 | Claw | 总协调、宏观记忆 |
| 办公室 | 办公室 | 公文写作 |
| 交易部 | 服务器 | 策略研发/实盘 |
| 智库办 | 智库办 | 形势分析 |
| 开发部 | dev-department | 部署/运维 |
| 文体部 | 文体部 | 播客/有声书 |

**原因**：单空间上下文被压缩，各部门任务相互污染。拆分后各空间独立记忆，主任只保留宏观摘要。


### O-2026-06-16: 非RSS抓取替代方案 —— 因RSS全线死亡

**决策**：放弃所有国内媒体 RSS 订阅，改为非RSS方式抓取（JSON API + 静态HTML解析）。

**原因**：新华网、新浪、人民、澎湃、凤凰、环球、第一财经、界面 — 均无可用 RSS。新华网 RSS 返回 2022 年旧闻，新浪 RSS 返回 2018 年旧闻。

**实施**：
| 源 | 方式 | 时效来源 |
|---|------|---------|
| 新浪新闻 | JSON API | Unix时间戳 |
| 新华网 | 静态HTML | URL日期 YYYYMMDD |
| 人民网 | 静态HTML | URL日期 YYYY/MMDD |
| 观察者网 | 静态HTML | URL日期 YYYY_MM_DD |
| 微博热搜 | API JSON | 抓取时间 |

### O-2026-06-16: RAW存档机制 —— 全量保存永不丢失

**决策**：所有新闻在送AI精选前，全量写入 ndjson 文件归档。

**原因**：AI精选阶段有信息损耗（500条->80条）。保存全量RAW便于未来用更强模型重新分析。

**格式**：（逐行JSON，零token开销）

### O-2026-06-17: 个人数据中心四件套架构

**决策**：服务器上的服务按功能分为四个支柱。

**架构**：
| 支柱 | 服务 | 用途 |
|:---|:---|:---|
| 存储 | WebDAV | 日记/文件同步 |
| 密码 | Vaultwarden | 统一密码管理 |
| 阅读 | Calibre-Web + Audiobookshelf | 电子书 + 有声书 |
| 发布 | Halo | 博客/公开内容 |

### O-2026-06-19: Dashboard 指标必须与策略逻辑统一

**决策**：Dashboard 展示的指标/数据必须与策略实际决策逻辑完全一致，不能有偏差。

**原因**：此前 Dashboard 显示的指标与策略代码中实际计算的参数不匹配，造成误判。

**实施**：Dashboard Tab3 震荡指标面板的数据源直接从策略代码提取，不再手工维护。

### O-2026-06-19: 主任严禁越俎代庖

**决策**：主任（Claw 工作空间）的 AI 不得亲自编写策略代码、修改配置文件、部署服务、开发 Dashboard。

**原因**：v1.1~v1.6 连续 6 个版本均由主任亲自写代码部署，严重越界。主任的职责是理解需求->出方案->派任务->跟进->验收。

### O-2026-06-15: 灵感收集器周报定位调整

**决策**：周报从工作报告风格改为私人思考伙伴风格。

**原因**：AI 的角色不应该是给老板写报告，而是陪用户思考。日报格式更符合私人知识库定位。

### O-2026-06-20: 定时任务时间窗口统一为滚动窗口

**决策**：所有"每日"定时任务的数据过滤，从日历日字符串匹配改为滚动时间窗口（过去N小时）。

**原因**：阅读日报使用 `date_str = datetime.now().strftime("%Y-%m-%d")` 严格按日历日过滤。22:00 cron 触发时抓取 `2026-06-20` 的数据，但用户 23:00 的晚间阅读标记为 `2026-06-20`，次日 22:00 的报告只认 `2026-06-21`，这条数据漏入日历间隙。

**实施**：
- 灵感日报：`list_memos(days=1)` → 本就是 24h 滚动窗口，无需修改
- 阅读日报：`load_today_data()` → 从日期字符串匹配改为 `since_dt = now - timedelta(hours=24)` 时间戳比较
- `parse_time_from_line()` → 从只截取日期改为捕获完整 datetime 对象

**教训**：任何"每日"定时任务如果用日历日过滤，必须考虑夜间时段的归属。滚动窗口（过去N小时）比日历日更鲁棒。尤其是用户活跃时段与 cron 触发时间接近或重叠时。