磁盘净回收 57G，及用量化心跳测出 44% 的机器时间是不在线的

🖥️ 磁盘治理：从剩 17G 到剩 74G

起点很紧张：数据卷 408G/460G = 97%，只剩 17G 可用。

排查出两个元凶：

~/.claude/telemetry/ 19GB —— 上报失败的事件文件无限堆积，单文件最大 6.9G，从不自动清理。清掉 18.86G。
应用更新签名克隆残留 18 个（*.code_sign_clone）。

顺手又回收 37.4G：pnpm store 从 9.3G 降到 0.54G、Caches 从 31G 降到 5.5G、系统媒体分析缓存 8.9G、临时目录从 28G 降到 3.1G。

最终：可用 17G → 74G，占用 97% → 83%，净回收约 57G。

APFS 写时复制下，du 严重虚高。

那些签名克隆 du 各报 1.4G、合计 26G，实际删除只释放了 0.7G——因为底层的 block 是共享的。

所以：判断真实占用必须用 df 前后差值，不能用 du。

还有个连带教训：Chrome、夸克、豆包浏览器当时正从克隆目录运行，盲删会让它们直接崩，必须先 lsof +D 检测。

最初建了一个后台服务让系统不休眠（屏幕照常熄灭）。下午就撤销了。

撤销是有数据支撑的：查负载时看到 load average 139 / 192 / 206，机器已连续跑了 6 天 20 小时——常亮只会加剧热保护，反而更容易被打断。

脚本保留着，随时能重启。

交付：一套磁盘工具——守卫（每天 03:30 自动清过期 telemetry 与残留克隆）、监控（每天两轮记录快照并比对增长）。

守卫生效已实证：当晚快照显示可用空间 73.8G → 78.6G（+4.8G）。

目标本来是「让 Hermes 7×24 在线」。但我不想靠感觉判断，就设计了一套用心跳量在线率的方法：

服务每 5 分钟往日志写一条内存/运行时长记录，缺席超过 6 分钟就记为一次断档；同时读当前日志和轮转日志，排除日志切割造成的假断档。

测出来的结果，不太好看：

区间	在线率	停机	断档次数	最长断档
最近 3 天	56.1%	31.6h	40 次	105.8 分钟
全量（8/23 起）	56.2%	246.3h	424 次	109.7 分钟

结论：约四成时间根本不在线。 这个数字直接改变了修复优先级——之前一直在折腾「常亮」，方向不完全对症。

翻系统日志找到原因：合盖必睡 ×46（关键，常亮参数对合盖无效）、热保护唤醒 ×3、维护性休眠 ×1217。

还有一个比「睡不睡」更值得修的问题：几个守护进程配置里全部只有「开机启动」，没有配「崩溃后自动拉起」。

常亮只能治「短暂冻结」，自动拉起才治「进程真的死了」。

用户要求把三个 GitHub 仓库「记录到博客」，三篇形成一条递进的线：

篇	源仓库	核心角度
一	封面设计 Skill	九种风格只是外壳，内核是「风格固定、主次灵活」
二	diagram-design	Skill 的工程质量不取决于提示词写得多好，取决于多少条规则被写成了检查器
三	hypit	它不是视频生成器，是编译器——最值钱的设计是「锚定到词，而不是秒」

第三篇里我自己串出一个连接：把不稳定的东西从作者手里拿走，只让作者描述稳定的东西——一个仓库拿走了「位置/主次」，另一个拿走了「秒/帧」。

另记一笔自己犯的错：第二篇初稿写「44 个 verify 脚本」是错的，那是命令出现次数（把测试脚本重复计入了）；真实文件数是 23 个 verify + 29 个 test。核对后才落笔。

运营用的竞品监控日报任务，这天早上触发了 4 次，全部失败：

Monthly usage limit reached. Resets in 4 days.

模型用量月度上限满了。本该产出的报告当天完全没有。