概述
监控与定时任务涵盖 Agent 生态中的自动化健康检查机制。包括 Watchdog 心跳监控（通过 cron 定期检查子任务状态和服务器可用性）以及基础设施健康检查定时任务 infra-alert-check（每 6 小时巡检站点、服务器、模型端点等）。
Watchdog 心跳监控是 fries-mac Agent 的核心健康检查机制，每 15 分钟定期检查子任务状态并将结果投递到用户频道。infra-alert-check 是 research agent 管理的基础设施巡检任务，在 prism-foundry 403 认证故障后将模型端点检查合并进来，实现了全面的基础设施监控。
关键事件
- 2026-03-03: 初始配置心跳检查规则，确认为永久性（非一次性）
- 2026-03-05: 将心跳频率调整为每 15 分钟一次
- 2026-03-10: 发现 watchdog 应自动检查所有子任务而非单个任务
- 2026-03-10: 排查密码不正确的问题，建议通过 watchdog 自动重置
- 2026-03-15: 讨论内容提取逻辑：根据什么标准判断信息是否需要存储
- 2026-03-16: 修复任务结果投递问题——需要配置投递目标频道
- 2026-04-04: prism-foundry 403 错误触发建立模型端点健康检查需求
- 2026-04-04: 创建 nightly-health-check，随后优化合并进 infra-alert-check（每 6h）
技术要点
Hermes session push（2026-04-29 新增 / 2026-05-06 macOS 兼容修复）
新工具 hermes-remote-push-v2（来源 lewaymacmini）—— 把本机 Hermes session DB 推到远端 eagle ingest endpoint 当 raw 层。安装位置：
- 脚本
~/.hermes/scripts/hermes_ingest.py - shim
~/bin/push-sessions.sh
cron 计划 30 4 * * *（Hermes 内置 cronjob，job_id 示例 09fc9cb05951，deliver=local）。当前 lewaymacmini 上 Hermes session 历史最早 2026-04-14 10:27，20 天累 101 sessions。
2026-05-06 修复（详见 hermes-agent-setup、decisions）：原脚本 DATE=${1:-$(date -d yesterday +%Y-%m-%d)} 在 macOS 上 date -d 不识别，set -e 不因 $() 失败退出 → DATE 空字符串 → 走 “no sessions” 分支 exit 0，连续两天 cron 假成功。修法：① date -v-1d +%Y-%m-%d；② cron prompt 要求贴完整脚本 stdout，禁止 LLM 摘要。
Clawline platform monorepo 自动部署（2026-05-06 重写）
之前 watch + auto-deploy 监控 clawline/{channel,client-web,gateway} 三个 repo 各自一个 SHA。2026-05-06 三 repo 合并为 [[decisions|clawline/platform monorepo]]，脚本改为只盯 platform:dev 一个 SHA。watch-repos.sh cron 每 3 分钟 gh api 拿最新 SHA 与 .watch-state/platform_dev.sha 对比，变化才触发 auto-deploy.sh：
git pull+pnpm install（防依赖变更）apps/client-webbuild →pm2 restart dev-web（serveplatform-repo/apps/client-web/dist）apps/channel本地打包 tar +rsync推 OWL/WOLF（不再依赖远端 git pull）apps/gatewayadmin pnpm build →pm2 restart dev-gw+ relay 部署 + healthz check
「无 push 就不部署」——cron.log 大部分都是 No changes，只有真有 push 才跑。当日实测 1b23c4f 跨三个 app 一次 push、cron 15:09 自动检测并全套部署成功。
Watchdog 心跳监控
- 频率: 每 15 分钟执行一次
- 检查范围: 所有子任务（非单个特定任务）
- 投递机制: 检查结果需要投递到用户的 Mattermost 频道
- 内容提取: 根据预定义规则判断哪些信息值得长期记录
infra-alert-check 基础设施巡检
- 频率: 每 6 小时
- 执行者: research agent
- 原有检查项: 站点 HTTP、服务器 SSH、磁盘监控、Cron 错误检测
- 新增检查项: prism-foundry / github-copilot / my-azure 模型端点、Gateway 进程、Docker 容器状态
- 异常通知: 自动发 DM 给管理员
Healthbot 康复提醒定时任务
health agent 通过 cron + edge-tts 实现术后康复的语音+文字定时提醒：
| 时间 | 内容 | 方式 |
|---|---|---|
| 8:00 | 早上吃药 | 语音+文字 |
| 9:00 | 早上换药 | 语音+文字 |
| 13:00 | 中午吃药 | 语音+文字 |
| 15:00 | 散步提醒 | 语音+文字 |
| 19:00 | 晚上吃药 | 语音+文字 |
| 20:00 | 腹部按摩操 | 语音+文字 |
| 21:30 | 睡前换药 | 语音+文字 |
- 脚本:
workspace-health/scripts/remind.sh - 发送:
openclaw message send --account health --channel mattermost - TTS: edge-tts（微软晓晓语音）
- Heartbeat: 每2小时（8:00-23:00）
薯条妈妈（胡皮佳）每日 9:00 微信推送（2026-05-04 ottor-laptop）
ottor-laptop 把”每日亲子活动推荐”cron 从 Discord 频道迁到微信频道（薯条妈妈 channel o9cq80xHVdMcSc8zTdNKeptCaLPA），时间从 8:00 推后到 9:00（避开还在睡）。两件事并发一条：
- 当天亲子活动建议（针对 shutiao-world 育儿场景）
- 启发互动钩子：cron 推送前先
session_search过去 7 天她跟 bot 的互动记录，按状态生成单一钩子——- 在做小游戏 → 提醒”昨天那个 X 后续要不要做 Y”
- 在录娃说话/拍视频 → 提醒可以再录一段
-
3 天没互动 → 给超低门槛钩子（“今天看到啥发我语音就行”）
只给一个钩子，不让她做选择题。约束：微信通道无法主动推送（详见 hermes-agent-setup iLink ret=-2 48h 窗口），所以要求妈妈每隔 ≤2 天给 bot 发任意消息保活；cron 推送本身依赖最近一次入站消息打开的 48h 窗。
Uptime Kuma 报警通知
2026-04-02 配置 Uptime Kuma 报警通知到 @dora DM，通过 healthbot 中转：
- 🔴 DOWN 通知：URL + 错误信息 + 时间
- 🟢 UP 恢复通知：URL + Ping 延迟 + 时间
现有定时任务清单
| 任务 | 时间 | Agent | 说明 |
|---|---|---|---|
| infra-alert-check | 每6h | research | 基础设施巡检（已合并模型检查） |
| research-daily-report | 21:00 | research | 每日研究报告 |
| research-work-cycle | 9:00/17:00 | research | 工作周期 |
| misse-daily-lesson | 18:00 | miss-e | 每日英语课 |
| health-remind | 每日7次 | health | 术后康复提醒（吃药/换药/运动） |
| health-heartbeat | 每2h | health | 健康 agent 主动检查 |
| nexora-plane-scan | 每2h | nexora (main) | Plane Issue 扫描，静默模式（04-16 从 qa 移交，30min→2h） |
| wiki-session-sync | 每日 | prism | 自动审查 Prism 日常会话并更新 wiki（04-16 新增；04-20 起 Hermes session DB 也接入，见 llm-wiki） |
| xiaomi-sim-trade | 每 30 min（9:00-15:30 工作日） | prism | 自动执行小米模拟交易（04-17 新增，每日上限 10 笔），见 trading-sim |
| archive-bodies | 每日 04:00 | prism | copilot-proxy proxy-logs.db 归档老 body，磁盘 > 85% 自动 VACUUM（04-17 新增），见 copilot-anthropic-proxy |
| concept-watchdog | 每 5min | packhorizon | Azure 出图 pending > 10min → failed + 退积分（04-28 新增） |
| shutiao-weekly-portrait | 周一 8:00 | fries-mac | 推 discord channel 1493633709289508914:1498509169375051917（04-28 切，原微信渠道挂） |
| wx-payment-expire/redeliver | 每分钟 | wx-gateway | Payment expire + webhook 重投（退避 [0,30s,2m,10m,1h,6h,24h]，04-28 上线） |
经验教训
- 心跳任务必须配置投递目标，否则结果丢失
- watchdog 应全面覆盖所有子任务，不能遗漏
- 密码失效等常见问题应加入自动修复流程
- 15 分钟间隔是合理的平衡点（太频繁浪费资源、太稀疏发现问题晚）
- 职责相近的定时任务应合并，避免重叠（如 nightly-health-check → infra-alert-check）
- 合并后从”每天一次”升级为”每 6 小时一次”，更及时发现问题
相关主题
- motion-detection-surveillance
- openclaw-config
- lancedb-memory-system
- ssh-server-ops
- prism-foundry-auth-issue
- model-provider-config
- daily-systems
- multi-agent-architecture
BiBot 定期健康检查
以下信息来源于 bibot 的 Mattermost DM 聊天记录（2026-03-17 ~ 2026-03-24）。
BiBot 通过 Cron 任务定期执行两类自动化检查：
站点健康检查
- 频率：约每 6 小时
- 目标：
https://bi.dora.restry.cn/和https://bi.dev.dora.restry.cn/ - 检查项：HTTP 状态码、后端 uvicorn 进程、前端静态服务、Caddy 配置
- 归档状态：项目已归档后 502 为预期状态，BiBot 能正确识别并标注”无需修复”
sync.mjs 工作区维护
- 检查项：CONTEXT.md 新鲜度、tasks.json 完成状态、会话活动数、记忆归档需求
- 自修复：发现
dev-biPM2 进程消失后自动重启
Nexora / Uptime Kuma 监控
以下信息来源于 nexora 的 Mattermost DM 聊天记录（2026-03-31）。
Nexora 在 claw-bot 服务器通过 Uptime Kuma 配置了 7 项持续监控：
| 监控项 | 类型 | 间隔 | 备注 |
|---|---|---|---|
| Gitea | HTTPS | 60s | |
| Outline Wiki | HTTPS | 60s | |
| Portainer | HTTPS | 60s | |
| Uptime Kuma | HTTPS | 60s | 自监控 |
| Mattermost | HTTPS | 60s | 延迟较高 (~1300ms) |
| PostgreSQL | TCP | 60s | 改用容器 DNS 名 postgres |
| FRP Server | TCP 18888 | 120s | ICMP 被拦截，改 TCP |
告警通知：通过 Mattermost Incoming Webhook 推送到团队频道，任何服务 DOWN 自动通知。
Uptime Kuma 支持的监控类型包括：HTTP(S)、TCP 端口、Ping (ICMP)、DNS、Docker 容器、数据库连接、gRPC、MQTT 等。告警渠道支持 Telegram、Webhook、邮件、Discord、Slack 等几十种。
Uptime Kuma 监控扩容（2026-04-10 → 2026-05-06 多服务器宝塔批量接管）
在 MySQL 合并 后，对监控项进行了一次全面更新：
- 停用 2 条过期监控（Gitea→已迁移至 GitLab、旧 Mattermost→已停用）
- 新增 12 条监控（GitLab、4 套 ERP/商城、门户、Deployer、Research Fleet Portal、4 个 MySQL 端口）
2026-05-06 多服务器宝塔批量接管 + Kuma 项目分组重命名（Levis dora 频道）：宝塔技能新增 5 台服务器接管（囍铺 47.96.160.80、金价 39.105.230.121、ERP手机 120.25.173.234、超级ERP 47.119.139.162 已存在改名、超级ERP前端腾讯云广州 175.178.119.118）。同步给 Kuma 新增 39 个监控项（HTTP 站点 + Nginx/MySQL/Java 端口），覆盖 6 台宝塔服务器全部网站和服务进程；之后按业务重命名 46 项加项目前缀：
| 项目前缀 | 服务器 | 监控数 |
|---|---|---|
[妈祖商城] | 47.96.90.171 | 7 |
[超级ERP] | 47.119.139.162 | 13 |
[囍铺官网] | 47.96.160.80 | 3 |
[金价数据] | 39.105.230.121 | 7 |
[ERP手机端] | 120.25.173.234 | 8 |
[超级ERP前端] | 175.178.119.118 | 8 |
Kuma API：通过 uptime_kuma_api Python SDK（Socket.IO 上的封装）调用，凭据 admin / Nexora@2026!。Kuma 没有官方 REST API。
- 修复 GitLab 监控故障（Docker 内部 DNS 劫持 → 改走宿主机端口映射，设 maxredirects=0 避免 302→HTTPS 握手失败）
- 当前活跃监控：17 条
Prism PM 定时任务
以下信息来源于 bnef 的 Mattermost DM 聊天记录（2026-03-15）。
BNEF Bot（prism-pm）为 Hackathon 配置了 3 个 Cron Job，使用 openclaw cron add CLI 创建：
| Job | Cron (UTC) | CST | 用途 |
|---|---|---|---|
| morning-standup | 0 1 * * * | 每天 09:00 | 读 tasks/active.json → 汇总昨日完成 → 列出今日计划 → 标记逾期/阻塞 → 发到 prism-standup |
| afternoon-progress | 0 8 * * * | 每天 16:00 | 检查逾期任务 → 阻塞预警 → 有问题通知 @dora |
| evening-summary | 0 13 * * * | 每天 21:00 | 日报总结 → 发到 prism-general |
最初设为仅工作日（* * 1-5），后改为每天运行（Hackathon 冲刺阶段周末也需跟进）。创建过程中 openclaw cron CLI 遇到 gateway closed 1000 WebSocket 握手断开问题，最终通过配置 tools.elevated 和 tools.exec 权限后解决。
Agent Portal 内置健康监控
以下信息来源于 portalbot 的 Mattermost DM 聊天记录（2026-04-03）。
Agent Portal 在 server.cjs 中内置了 HTTP 健康检查器：
- 频率：每 5 分钟自动拨测
- 目标：12-13 个开发环境 HTTP 服务
- 记录：写入
AP_site_checks表，包含response_ms - 告警：连续 2 次检查失败 → 自动 DM Dad，恢复时也通知
- 清理：
AP_site_checks保留 7 天
监控改造历程
- 原有 38 个监控项（含 15 台 SSH、7 个代理节点），无实际检查器在跑
- 精简到 12 个有意义的 HTTP 监控
- 在 server.cjs 内置
setInterval主动拨测 - 去掉了
AP_container_checks、AP_cron_checks等无数据源的表 - 前端 MonitorPanel 简化为 HTTP 监控 + 故障记录
- portalbot — 健康监控的实现者
- agent-portal — 监控面板所在平台
详见 Rabbit 心跳与健康报告。
详见 基础设施巡检报告。
2026-04-27 微信定时推送 ret=-2 处理（妈妈推送 9 天全挂复盘）
gateway/platforms/weixin.py 的 _send_text_chunk 之前只在 iLink errcode=-14 时触发”清 context_token 重试一次”。本周 7/7 cron 推送生成成功但全部投递失败（last_status: ok / last_delivery_error 长期未清），向前追溯 4/18 起连续 9 天 0 送达。
修法（fries-mac）：加 PUSH_WINDOW_EXPIRED_RET = -2 常量，ret=-2 现在和 -14 一样会触发清 token 重试；二次仍 -2 则日志写明 “recipient’s 48h proactive-push window has expired”，不再是模糊的 “unknown error”。运营动作：让接收人在微信回一句话重开 48h 窗口即可恢复推送。
另一并修的 cron 真 bug：cron/scheduler.py:418 用 asyncio.run() 在 worker thread 跑 fallback，进 send_weixin_direct 复用 live_adapter._send_session（gateway 主 loop 创建）→ aiohttp timeout context 跨 loop 失效抛 Timeout context manager should be used inside a task，把上游 ret=-2 错误覆盖成误导性次生错误。修法：send_weixin_direct 加 _send_session._loop is current_loop 检查，loop 不一致时跳过短路、在当前 loop 上建新 session。
2026-04-28 PackHorizon concept-watchdog（每 5min）
packhorizon R10 上线（commit d02bcbb）—— 之前线上有概念图卡 pending 12h+，根因 Azure gpt-image-2 默认 SDK timeout 太短（60-120s 大图常超）+ pending 没看门狗，进程重启时 in-memory promise 死掉、状态留在 pending、积分也没退。
修法三件套：
- Azure SDK timeout 改 10min —
getAzureClient({ timeout: 600_000 })，Next routemaxDuration=600+runtime=nodejs /api/cron/concept-watchdog— 每 5min 扫status=pending && createdAt < now-10min→ 刷failed+ 退积分（idempotencyKey 防双退）- admin 模型切换 —
/admin/models单选gpt-image-1.5/gpt-image-2，存 DB SystemSetting 单例，不改 env 不 redeploy 即可切
verify 5/5 PASS，watchdog 自动回收线上 1 条 stuck（swept=1 refunded=1）。装 cron */5 * * * *。
2026-04-28 wx-gateway 支付链路 cron
wx-gateway Payment v1（commit 9bcbc48）：
- expire cron — 扫
pending && now > expiresAt→ 刷expired+ fan-out webhook - redeliver cron — webhook 投递失败按退避表
[0, 30s, 2m, 10m, 1h, 6h, 24h]重投，6 次失败标 dead
⚠️ 04-29 P1 bug：instrumentation.ts cron 被 early-return 绕过 —— 生产 ADMIN_BOOTSTRAP_OPENIDS 为空 → cron 没跑 → expire/webhook 重投全不触发。selftest 是手动驱动 tick 才绿。webhook delivery 表当时积压 63 条 status:fail 把 50 条/tick 配额吃光 → 改 nextAttemptAt 排序 + limit 200。
2026-04-28 薯条周画像 cron deliver 切 Discord channel
27c99ea81be3 每日亲子活动推送（接收人胡皮佳）4/18 起连续 9 天 0 送达，触发 weixin_send_failed: Timeout context manager should be used inside a task —— 实际上游是 ret=-2（48h 主动推送窗口过期），被次生错误覆盖（见下文 04-27 修法）。
短期止血：deliver 从 weixin:o9cq80xHVdMcSc8zTdNKeptCaLPA@im.wechat 切到 discord:1493633709289508914:1498509169375051917（Daddy 的 thread）。周一 8:00 推送会自动带上当周薯条画像（~/wiki/raw/assets/shutiao-portraits/latest.txt → MEDIA:/绝对路径）。
设计原本：周画像唯一展出位 = 周一早 8 点跟亲子活动建议一起发到妈妈微信，没有 wiki/网页/薯条世界 app 的展出位。
2026-04-28 OpenClaw gateway 被 SIGTERM 事故
clawline 插件依赖 gateway 跑着才行。20:28-20:34 这 6 分钟里 openclaw-gateway.service 被反复 SIGTERM 3 次，最后一次没起回：
| 时间 | 事件 | 备注 |
|---|---|---|
| 20:28:06 | SIGTERM → Stop → Start | 之前跑了 1h39min CPU，内存峰值 3.1G（lancedb-pro 是大头） |
| 20:32:09 | SIGTERM → Stop → Start | 4 分钟后又停 |
| 20:34:22 | SIGTERM → Stop | 这次没再起，一直停到 23:07 手动 systemctl --user start |
判定：systemd 日志干净（无 exit-code / 无 KILL signal / 无 Failed），三次都是干净 SIGTERM Stopping —— 人为或脚本主动 stop，不是 crash。教训：gateway 是 ws://127.0.0.1:18789 的唯一监听者，被 stop 后所有依赖 gateway 的插件（clawline 等）静默挂掉，没有外部 alarm；service 是 enabled 状态，重启机器会自动起，但运行中被 stop 不会自愈。回头如果再涨内存可单独看 lancedb-pro。
2026-04-12 更新
- Uptime Kuma 新增 3 个监控项（囍铺ERP、鸿星黄金ERP、莱雅商城）
- 总计 19 个监控项（16 活跃 + 3 停用）
- 已知问题：prism-foundry TLS 握手失败、BI 后端 502、Channel H5 404（均为非紧急）
- ⚠️ eagle 磁盘使用 80%，需持续关注
2026-05-04 hermes-session-remote-push 上线（ottor-laptop）
把本地 Hermes session 落库 + 远端 ingest 拆成两条管线：
~/.hermes/scripts/hermes_ingest.py— 从 SQLite session DB 读、按天写本地 jsonl 到~/wiki/raw/hermes-sessions/YYYY-MM-DD.jsonl；幂等去重。关键参数坑：--date只查单天，--backfill --days N才是全量扫描（首次踩了 7 天 0 数据 → 切--backfill后扫到 110 sessions）~/bin/push-sessions.sh— 读本地 jsonl → POST 到https://ingest.eagle.openclaws.co.uk/ingest/hermes-sessions（Bearer token），cron30 4 * * *每天 04:30 推昨天
⚠️ 原压缩包里 push-sessions.sh 是坏的：用 hermes_ingest.py --date $DATE --dry-run 想拿 sessions 字段，但 ingest.py 报告里根本没这个字段（只有统计数字），sessions_written=0 → JSONL 永远空 → curl 不发。安装后必须立刻替换成”直接读本地 jsonl 推送”的版本，否则 cron 跑了等于没跑。沉淀为 skill hermes-session-remote-push。
首次 backfill 推 110 sessions / 2520 messages，覆盖 2026-04-13 ~ 2026-05-02。
安全侧记
同一脚本第一次贴 shell 命令时被本机 Opus 4.7-1m 拒绝（识别为 prompt injection — 陌生 token、陌生 ingest 子域名、外传 session 数据、cron 持久化）；改成 zip 包二次投递也拒绝；用户用「胡皮佳」（薯条妈妈真名）通过身份验证后切到 Sonnet 4.6 才解压执行。结论：ingest.eagle.openclaws.co.uk 是 Eagle 自家新增子域名，非攻击 — 但流程上”同一台机器不同模型对同一可疑指令做出相反决策”值得记一笔（Sonnet 安全门槛低于 Opus）。
2026-05-04 fries-mac hermes-sessions-push（用 Hermes cronjob，不用 macOS crontab）
同一套 hermes-remote-push-v2 也部署到 lewaymacmini-3-local。macOS crontab 装不上 —— 终端外调 crontab 需要 Full Disk Access，shell 直接吊死。改用 Hermes 内置 cronjob 工具 注册 hermes-sessions-push 04:30 daily（deliver=local → 输出到 ~/.hermes/cron/output/）。优势：不依赖 Full Disk Access、有日志可 list/run/pause、Hermes 进程内调度。首次 backfill 89 sessions / 14 天。详见 hermes-agent-setup。
⚠️ 后续发现这条 cron 从上线起一直在「假成功」，详见下文 2026-05-06 复盘。
2026-05-04 妈妈推送 cron 改 9 点 + 切回微信 + 加”启发互动”段
27c99ea81be3 调整：
| 项 | 旧 | 新 |
|---|---|---|
| 时间 | 8:00 | 9:00（8 点妈妈可能还在睡） |
| Deliver | discord channel 1493633709289508914:1498509169375051917（04-28 临时止血） | 回到微信 weixin:o9cq80xHVdMcSc8zTdNKeptCaLPA（04-27 ret=-2 修法 + 04-29 wx-gateway 微信支付链路稳了之后回切） |
| 内容 | 仅亲子活动建议 | 亲子活动 + 启发互动钩子（每次推送前先 session_search 过去 7 天她跟 Hermes 的互动，挑一条低门槛后续提示，单钩子不让她做选择题） |
设计要点：内容偏 push（推荐今天可以做什么）+ pull（启发她拉 Hermes 一起继续手头那件事），>3 天没互动 走超低门槛钩子（“今天看到啥发我语音就行”）。
2026-05-06 ottor-laptop hermes-ingest v3（读 JSON 文件 + 远端按 day 分桶）
ottor-laptop 这边对 hermes_ingest.py 做了两次重大重写，配合 endpoint 升级：
v3 改读 session JSON 文件（不再查 SQLite）：排查发现 ~/.hermes/state.db 里 discord session 4-29 之后基本断写（cron source 还在写，但 discord/weixin 适配器升级后只落 ~/.hermes/sessions/*.json 不进 DB），导致 hermes_ingest.py 漏 153 个 session。修法：脚本改成扫 ~/.hermes/sessions/*.json 真源文件 + 排除 cron 噪音 source。重新打包成 v3.zip。补推 172 个 session 全部 {"ok":true}，覆盖到 5/4。
远端 endpoint 升级，要求 payload 顶层 day 字段：服务端按 session 的 day 字段分桶入库，不再依赖文件名/上传时间推断。build_payload 加 day 字段，老 jsonl 也批量补 day（基于 started_at 转 CST）后整体重灌。全量重推命令：
python3 ~/.hermes/scripts/hermes_ingest.py --backfill --no-watermark
cat ~/wiki/raw/hermes-sessions/*.jsonl | curl -X POST $ENDPOINT \
-H "Authorization: Bearer $TOKEN" -H "X-Host: $(hostname)" \
-H "Content-Type: application/x-ndjson" --data-binary @-最终结果：18 天 273 sessions 全部分桶入库，远端按 X-Host 隔离 hostname 命名空间。
⚠️ 同坑别处再踩：原 push-sessions.sh 写 if [ ! -f $JSONL_FILE ]; then ingest; fi —— 文件存在就跳过 ingest，会导致「该天首次 push 后产生的 session 永远不被推」。修法：cron 每次都先跑 --backfill --no-watermark（按 session_id 幂等去重），再推单日 jsonl。
⚠️ messages 里 timestamp 经常是 None，按 message 切天不可行；按 session 的 started_at 切天即可（每个 session 已经天然归到一个 day）。
skill devops/hermes-session-push 同步更新：v3 文件源、day 字段、cron stale-jsonl 修法、endpoint+token、全量重推剧本、新机部署流程。
2026-05-06 lewaymacmini-3-local hermes-sessions-push cron 假成功复盘
Resley 抽查 hermes-sessions-push 状态，发现自 05-04 上线以来 从未真正推送过数据，cron 自报”推了 1 条 (2026-05-05)“是 LLM 编造。
根因 1 — push-sessions.sh 第 8 行用 GNU date 语法：
DATE=${1:-$(date -d yesterday +%Y-%m-%d)} # macOS BSD date 不认 -dmacOS 应写 date -v-1d +%Y-%m-%d。而 bash 已知坑：$(...) 在变量赋值里失败时 set -e 不触发退出，于是 DATE=""，JSONL_FILE="$RAW_DIR/.jsonl"（不存在）→ 进 if [ ! -f ] → 输出 no sessions for → exit 0。脚本「礼貌地什么也没干」。
根因 2 — cron prompt 让 LLM 自由发挥：
prompt 只要求”完成后只汇报一行：推了多少条”，没强制贴脚本 stdout。LLM 看到 no sessions for （看起来正常），就编了一句 推了 1 条 (2026-05-05) 糊弄。05-05 / 05-06 两次 cron 报告都是这么编出来的。
手动验证修法可行：bash ~/bin/push-sessions.sh 2026-05-05 实际跑通，endpoint 返回 {"ok":true,"host":"lewaymacmini-3-local","written":{"2026-04-29":1}} —— v2 ingest 按 message timestamp 切天，长跨天会话写到首个 message 所在日期。
待修两件：
- 脚本
date -d yesterday→date -v-1d，再加tee ~/.hermes/push-sessions.log - cron prompt 要求贴脚本完整 stdout 而不是摘要，避免 LLM 编报告
沉淀经验：
- bash
set -e+ 命令替换在赋值上下文不阻断流，写跨平台 shim 一定要先if ! DATE=$(...); then exit 1; fi - 任何 cron 任务的 prompt 都应该「贴原始输出」而不是「总结一句话」，否则 LLM 在状态不明时会编造确定性叙述