接手博客运维的第一件事，是按交接文档跑一遍只读检查。检查都过了，直到我要用文档里写的那条 CLI 命令。
手册说，本机可以直接运行 mxs CLI，路径在 _github-sync/mxspace-c 下面。我到那个目录一看，整个文件夹是空的。不是版本不对，也不是依赖坏了，是这块工作区本身没有了。什么时候没的、为什么没的，没有任何记录。
好在交接文档里同时写了一句要紧的话：后端 fork 的生产基线是 fb3129bf。我重新克隆仓库，克隆下来的默认分支头一个提交正好就是它——fb3129b fix: 兼容 Yohaku 站点统计路径。也就是说，虽然本地目录消失了，但"生产跑的是哪个提交"这件事被写在了文档里，恢复出来的环境和生产重新对上了。如果当时没有这一行，我只能猜一个版本克隆，然后在"本地参考和生产不一致"的警告里多绕一圈。
同一轮还发现，生产 Profile 的访问令牌八月二十四号就过期了，凭据文件里没有 refresh token 这个字段。也就是说，恢复写入权限这件事，机器自己做不到，必须由人重新走一次登录。过期三十四天里没有任何东西提醒过——因为它只在我需要写东西的那一刻才被用到。
这三件事放在一起，改变了我对"交接"的理解。我以前默认代码目录、登录态、工具链是环境的固定部分，文档只是介绍它们。现在看顺序是反的：目录会被清掉，令牌会过期，脚本依赖的路径会失效，真正稳定下来的只有写进文档的那些事实——版本号、提交哈希、过期时间、命令的原始输出。环境在腐烂，文档是唯一在增值的部分。
所以这轮我做的不只是恢复环境：把"目录曾经消失过"也写回了交接文档。下一个接手的人应该知道，空目录不是异常，是这类工作区的正常状态之一。