进阶练习：用非敏感规则减少多机重复说明

没有真机复现，也没有提供同步脚本。 这是 Nimrod 自建 HQ 的缩小版，不是 T3 的内建同步。官方设置批量修改以提交 6d35d09060a901d15e31ab7ccdeedfe6696c23c5 为准。本站 项目设置译文 是旧提交 d2c25950。

适合已经完成 两台主机 和 工作流，并且确实在反复向不同主机解释同一套项目规则的人。还没跑通单机的人先不要做。

Nimrod 的 HQ、fleet.py 和 /fleet 是他自己的工具。W1 本练习只写规则、由人审查、再逐台应用。不实现他的脚本，不自动改用户级配置，不复制 secret。他的文章里有 secret 文件分发和双向 Full access，这两项都不要做。

流程

一份非敏感规则原稿
    → 人审查改动
    → 逐台查看现有规则
    → 按该 provider 支持的方式应用
    → 用新线程验收

T3 可以对多个已连接环境做一次批量设置修改。官方写明这不是持续的全局自动同步：离线环境保留原来的值。D6 以后那些机器上线，也不会因为这一次批量编辑就自动跟上。

步骤

1. 在你选的练习位置写一份草稿。先不要覆盖任何现有 AGENTS.md、CLAUDE.md 或全局配置。
2. 只记录工具不能可靠查询的约定。下面是整理建议，不是 T3 强制读取的格式。

项目用途：
机器职责，例如哪台用于构建、哪台仅用于试验：
允许修改范围：
测试与检查入口，注明仓库中的依据：
必须先询问的动作：
禁止动作，包括部署、读生产数据、复制凭据：
任务完成时必须报告的验证与未运行项：
规则负责人和最后核对日期：

3. 草稿里不要写配对码、token、SSH 私钥、cookie、账号密码或 secret 文件内容。公开发布前再检查内部主机名、用户名和路径要不要删掉。
4. 逐台看现有 provider 规则。比较哪些适用、哪些冲突。不要假设所有 provider 都读同一个文件，或使用同一种导入语法。
5. 你审核之后，按该 provider 已经确认的配置方式应用这些非敏感规则。应用前留下原文件，不自动覆盖。
6. 新建线程，要求它复述当前项目边界和验证入口。用只读小任务看规则是否真的生效。
7. 在应用记录里写清主机、provider、规则版本和验收结果。离线机器留在待办里，不标成已经更新。

验收与排查

两个新线程能给出一致的项目边界，并指向各自机器上正确的检查入口。规则里没有 secret，现有配置没有被无意覆盖。只有做完逐机验收的机器才标“已应用”。

新线程没有遵守规则时，先查这个 provider 是否真的加载了那个文件、作用域对不对、有没有项目级覆盖。不要一律归咎于模型，也不要为了同步方便去复制 provider 的凭据目录。D2

如果以后确实要自动同步，先限定允许的文件和目标机，并提供 dry run、备份、冲突报告和人工确认。本章没有提供也没有审核这种脚本。

来源：W1 第 6–8 节、D2、D6。安全缩减和模板是整理建议。视频只作 入口，不证明 HQ 已经是 T3 功能。