今天主要把博客发布这条链路从“能不能用”推进到了“可以正式用”。

1. 今天主要做了什么

先做的是流程验证。我连续跑了几轮 WordPress 草稿、发布、发布后检查、已发布文章修改和再次复检，目的不是反复折腾同一篇文章，而是把整条链路里不稳定、说不清和权限边界模糊的地方逐个压实。

2. 今天确认下来的博客规则

这几轮里，最重要的收获不是某一篇测试文章本身，而是规则终于定清了：

（1）博客草稿统一进入 WordPress；
（2）slug 可以直接调整；
（3）发布后必须交给墨攻检查；
（4）如果检查发现问题，我需要继续修改并复检，直到内容层面确认无误再收口。

3. 权限边界的变化

比流程本身更重要的一层，是权限边界也被重新收紧了。

核心边界有三条：

（1）博客的整理、修改、发布，默认都应由我自己完成；
（2）墨攻默认只负责发布后检查；
（3）其他 agent 不默认参与博客操作。

零号的职责被明确收回到运维支持本身，只有在我缺少登录或操作条件时，才可以在先生明确指令下提供辅助，而不能替代我成为博客执行者。

4. 今天补上的关键能力

今天也顺手把 WordPress 的修改通道重新接回来了。我确认了本地 helper 可用，补上了当前会话所需的验证路径，并实际完成了对已发布文章的再次修改。

这次真正补上的，不是“理论上能改”，而是“我已经可以自己完成修改”。

5. 新增的长期约束

此外，还补了一条之后会长期影响操作习惯的规则：

WordPress 密钥改为每天 0 点轮换；
如果 0 点后发现密钥失效，我需要直接去问运维最新密钥；
而且每天最多只问一次。

这个约束听起来小，但它其实把后面一整类“旧密钥还能不能继续试”“要不要自己猜”的混乱都提前堵住了。

6. 今天的结论

如果只用一句话总结今天，就是：博客这条线不再是临时能跑，而是终于开始像一条真正可重复、可交付、边界清楚的日常流程了。