joelclaw-system-check

joelclaw 系统健康检查

运行 scripts/postboot.sh，执行只读的启动后／每日拓扑巡检。它会检查 Flagg/Panda 权限划分、NAS 挂载、NFS 调优、自定义 NAS MinIO、Central Postgres、本地 Convex、Typesense、Inngest，以及影子 Central 健康状况，且不会打印机密信息。每日自动化还会检查近期的 Codex 基础设施对话记录，避免已完成的工作一直停留在聊天中。

迁移注意事项 — 2026-07-09

当前健康检查脚本仍然过于以 Panda 为中心：它把 Panda 时代的 k8s/PDS/NodePort 接口视为整个 joelclaw 系统。这已不再符合 Central 迁移愿景。

健康检查需要改为按运行通道划分：

• Central 通道：Flagg/Mac Studio 原生 launchd 服务、Redis、Typesense、Inngest、system-bus worker、agent-mail、运行捕获、会话 NAS 备份回执、可在重启后保留的状态。
• Relay 通道：仅限 Panda 的遗留部分，例如与 iMessage/账户绑定的中继、旧版 webhook/callback 接口，以及明确的弃用阻碍。
• Satellite 通道：Blaine/其他机器上的 JOELCLAW_CENTRAL_URL、outbox 积压、新鲜的捕获时间戳，以及对话记录备份的新鲜度。

在完成重写之前，应将 Panda/k8s/PDS 检查中的红色结果视为迁移 TODO，而不是 Flagg Central 已停用的证据。

~/Code/joelhooks/joelclaw-runtime/skills/joelclaw-system-check/scripts/postboot.sh

运行 scripts/health.sh，查看较旧的完整系统健康报告及 1-10 分评分。此操作开销更大，因为它会运行测试和 TypeScript。

~/Code/joelhooks/joelclaw-runtime/skills/joelclaw-system-check/scripts/health.sh

启动后／每日检查

在重启后、存储／网络操作后，以及每日自动化运行时使用。

默认命令：

POSTBOOT_NAS_BENCHMARK_MIB=1 \
  ~/Code/joelhooks/joelclaw-runtime/skills/joelclaw-system-check/scripts/postboot.sh

默认策略：

• 除在已指定的 s3 证明路径下执行极小的 NAS 验证器写入探测外，均为只读。
• 除非设置 POSTBOOT_HEAVY=1，否则不会运行 Convex 写入／读取／删除冒烟测试。
• 除非设置 POSTBOOT_RUN_FULL_HEALTH=1，否则不会运行旧版完整 health.sh。
• 绝不打印原始 .env、MinIO 密钥、Convex 管理密钥，或包含密码的 Postgres URL。
• 将 100.67.156.41:39000 上的自定义 NAS MinIO 视为权威端点。
• 仅将 29990 上的 ASUSTOR MinIO CE 视为警告／参考接口。
• 在 Flagg 上，预期 JOELCLAW_CENTRAL_URL 和直接 Typesense 助手仍指向 Panda，直到明确切换到 Central。

关键检查：

检查项	绿色状态表示
权限划分环境变量	Flagg 在作为影子节点期间，仍将 Central 捕获／搜索指向 Panda
Inngest 直接健康状态	权威 Inngest 端点在 /health 上响应；在 Flagg 上，如果未设置 INNGEST_URL，则回退到 http://panda:8288
运行捕获健康状态	Panda /api/runs/health 使用本地 Machine 身份验证返回 ok=true
已配置的 Typesense 健康状态	已配置的 Typesense 端点在 /health 上响应
NAS launchd 标签	已加载 system/com.joelclaw.central.nas-mounts，且上次退出状态未失败
NAS 10GbE/MTU 路由	到 192.168.1.163 的路由使用 en0，MTU 为 8192
NAS 挂载状态	/Volumes/nas-nvme 和 /Volumes/three-body 已从 LAN IP 导出路径挂载
NAS 验证器写入探测	服务检出目录中的 verify-nas.sh 通过
NFS 调优选项	实际挂载显示 rsize=524288,wsize=524288,readahead=128
自定义 MinIO 就绪／在线状态	自定义 NAS MinIO 在 39000 上响应
Central Postgres	socket、TCP 和就绪状态检查均通过
本地 Convex	后端 /version 和仪表板均有响应

警告／参考检查：

• 自定义 MinIO 控制台 TCP，端口为 39001
• ASUSTOR MinIO CE 就绪状态，端口为 29990
• 汇总 joelclaw status 和 joelclaw inngest status CLI 封装命令，因为即使权威端点正常，这些命令也可能暴露本地环境漂移
• Convex LAN 和 tailnet 转发
• 本地 Convex LAN 转发器 LaunchAgent
• Flagg 影子 Central 健康状态
• 受门控的重型检查

如果 postboot.sh 失败，请优先修复关键失败项。在必要路径变为绿色之前，不要追查警告／参考检查失败项。

最近的 Codex 对话审查

健康检查脚本运行后，每日自动化应审查近期 Codex 基础设施会话。

首选索引搜索：

使用 recall 和当前的 session-search 契约。将私密查询保留在结构化 MCP 参数中。原始证据需要范围绑定的 evidenceDrilldownReceipt；缺少投影并不代表可以访问原始数据。

如果索引结果过时或缺失，请检查元数据，不要读取对话正文。访问原始内容仍需要范围限定的凭证：

tail -n 80 ~/.codex/session_index.jsonl
find ~/.codex -type f -name "rollout-*.jsonl" -mtime -2

仅审查范围受限的片段、最终答复、命令和凭证。不要倾倒完整对话或机密信息。

将持久事实整理到合适的位置：

• 系统拓扑以及 Panda/Flagg 的权限归属 -> skills/system-architecture/SKILL.md
• NAS 访问、LAN/MTU/NFS 行为 -> skills/three-body/SKILL.md
• 自定义 NAS MinIO 行为 -> skills/minio/SKILL.md
• 本地 Convex 暴露情况和日常使用方式 -> skills/local-convex/SKILL.md
• 带日期的凭证和决策 -> .brain/resources/*.svx

将进行中的子 Agent 线程以及没有最终答复的会话视为线索，而非架构事实。

活跃的 Codex 自动化：

• ID：daily-joelclaw-postboot-system-check
• 计划：每天当地时间 08:15
• 工作区：/Users/joel/Code/joelhooks/joelclaw-runtime
• 命令意图：运行 POSTBOOT_NAS_BENCHMARK_MIB=1 skills/joelclaw-system-check/scripts/postboot.sh，总结故障/警告，审查近期 Codex 基础设施对话，报告尚未记录的持久事实，并避免输出机密信息。

完整健康检查（16 个组件）

检查项	内容	正常（10）	警告（5-7）	异常（1-3）
k8s 集群	joelclaw 命名空间中的 Pod	4/4 正在运行，0 次重启	部分 Pod	无 Pod
pds	:9627 上的 AT Proto PDS	版本 + 集合	Pod 正在运行，主机发布降级	Pod 未运行
worker	:3111 上的 system-bus	16 个以上函数	有响应，数量偏少	已停止
inngest server	:8288 可访问	有响应	—	已停止
agent-mail	:8765 上的本地 Flagg MCP 邮件	存活 + 邮箱可见	计数/搜索降级	不可用
redis/gateway	Redis + gateway 会话队列	已连接，待处理队列较短	已连接，积压不断增加	不可用
typesense/otel	Typesense 健康状态 + OTEL 查询路径	健康 + 可查询	健康，查询降级	不可用
tests	system-bus 中按文件隔离运行的 bun test	0 个失败	—	存在失败
tsc	tsc --noEmit	无问题	—	类型错误
repo sync	monorepo HEAD 与 origin/main	同步	超前/落后	仓库不可用
memory pipeline	joelclaw inngest memory-health	检查健康	检查降级	检查失败
pi-tools	已安装扩展依赖	3 项依赖全部就绪	—	缺失
git config	已设置 user.name + email	已设置	—	缺失
active loops	joelclaw loop list	可查询	查询降级	不可用
gogcli	Google Workspace 认证	账户已认证，令牌有效	已存储令牌，无密码	未配置
disk	可用空间 + loop 临时目录	使用率 <80%	—	使用率 >80%
stale tests	__tests__/ + 验收测试	无问题	—	存在

Agent 会话捕获 + NAS 备份检查

当检查需要证明 Pi/Claude/Codex 对话活动已在 Flagg、Blaine 和 Panda 之间捕获并备份时，请使用 agent-session-capture-backup 技能。

从 ~/Code/joelhooks/joelclaw 运行快速审计/修复命令：

bun scripts/agent-session-audit-backup.ts \
  --hosts flagg,blaine,panda \
  --central-url http://joels-mac-studio.tail7af24.ts.net:3111 \
  --backup-root /Volumes/three-body/sessions \
  --repair-env \
  --sync=true \
  --replay-outbox \
  --replay-limit 250 \
  --replay-max-bytes 10485760

每日持久工作流：

• function：system/agent-session.capture-backup.verify
• event：system/agent-session.capture-backup.requested
• cron：TZ=America/Los_Angeles 15 5 * * *
• 凭证：/Volumes/three-body/sessions/receipts/*.json

即使 runs_dev Typesense 索引是最新的，如果 /Volumes/three-body/sessions 内容过时或为空，也应视为严重备份故障。Typesense 是派生数据；原始对话和运行数据块才是事实来源。

何时运行

• 会话开始时 — 开始工作前了解系统状态
• 循环完成后 — 确认没有问题
• 基础设施变更后 — k8s、worker、Redis 配置
• 感觉不对劲时 — 快速排查

修复常见问题

仓库偏离：cd ~/Code/joelhooks/joelclaw && git fetch origin && git status -sb

pi-tools 故障：cd ~/.pi/agent/git/github.com/joelhooks/pi-tools && bun add @sinclair/typebox @mariozechner/pi-coding-agent @mariozechner/pi-tui @mariozechner/pi-ai

PDS 无法访问：curl -fsS http://localhost:9627/xrpc/_health，然后运行 kubectl get deploy,svc,pods,pvc -n joelclaw | rg 'bluesky-pds|NAME'（或者，如果 pod 已停止：kubectl rollout restart deployment/bluesky-pds -n joelclaw）

Worker 停止运行：joelclaw inngest restart-worker --register

测试失败：检查受影响的行为并修复有效的覆盖。测试的来源本身绝不能成为移除测试的理由。

系统总线测试误报失败：健康检查脚本会在各自独立的 Bun 进程中运行每个 src/**/*.test.ts 文件，因为一些旧测试会对全局对象打猴子补丁，或使用 mock.module。如果汇总健康检查通过，但直接运行 bun test 却失败，应先排查文件间的 mock 泄漏，再判定运行时代码有问题。

循环产物：检查任务归属和未收集的工作。仅删除授权范围内已确认可丢弃的产物。

Inngest 运行卡住时的快速排查

如果运行在第一个步骤后似乎卡住：

joelclaw run <run-id>

如果跟踪显示 Finalization 失败，并出现 "Unable to reach SDK URL"：

1. 验证注册状态和健康状况： joelclaw inngest status

2. 验证预期位置是否存在该函数： joelclaw functions | rg -i "manifest-archive|<function-name>"

3. 在 Inngest UI/API 中检查是否存在过期的应用注册，并移除过期的 SDK URL。

4. 考虑处理程序可能阻塞，而不只是网络问题： 检查最近的步骤代码，确认步骤响应前是否存在文件系统/Redis/子进程阻塞。