README 要先改成独立口径#

独立仓的 README 不能继续写上层业务背景。

对外读者不关心它最早从哪个项目里拆出来，也不该被迫理解原来的业务场景。README 最终改成只讲工具自身：它能做本地多 agent 治理，能生成工作区报告，有白名单 launcher、分派确认、mailbox 回传、看板观察，也写清楚怎么在本机验证。

口径一改，很多内容自然会被删掉。某个机器人、某块板卡、某套训练流程、某个私有目录，都不再是卖点。它们可能是工具诞生的原因，但不是独立仓应该携带的上下文。

公开项目最忌讳读者一打开 README 就像误入了别人的工作现场。独立口径就是把工具从现场里剥离出来。

文件集要白名单，别镜像#

发布目录不能从源目录整镜像。

首版独立仓只需要保留能支撑工具运行和理解的文件：README、LICENSE、CONTRIBUTING、SECURITY、API、RELEASING、重点脚本、看板、配置样例和测试。其它运行时成果应该默认排除。

尤其要挡住几类东西：

• .tmp。
• 临时指令文件。
• mailbox archive。
• 本地 session。
• cache。
• 上层业务文档。
• 历史任务残留。

这类文件有些看起来只是噪声，有些可能包含真实路径、会话上下文或内部任务线索。发布范围越早用白名单收紧，后面越可控。

SECURITY 不是摆设#

codex-governance 这种工具会启动本地进程，还会暴露本地 HTTP API。哪怕只监听 127.0.0.1，它也需要 SECURITY.md。

SECURITY 里补了几个最容易被误用的点：支持版本、漏洞报告方式、launcher 不能暴露到公网、API 走白名单而不是任意 shell，本地看板也只能访问受控接口。运行成果不能提交，这一点也单独写出来。

这不是为了显得正式，而是因为工具能力确实敏感。能启动本地 Codex 会话的东西，不能被当成普通静态网页看待。

API 文档要写失败场景#

本地 launcher 的 API 文档也不能光列 endpoint。

每个接口最好说明三件事：它做什么、关键字段是什么、常见失败是什么。比如会话不存在、计划还没生成、部门并发已满、mailbox 没有回传、launcher 状态过期，这些都应该成为可预期的状态，而不是前端或用户猜出来的异常。

多 agent 工具如果没有 API 文档，很快会变成只有作者知道怎么用。一旦做成独立仓，就要让别人能判断哪些接口是观察，哪些接口会启动动作，哪些接口只是读取归档。

RELEASING 要能拦旧语境#

独立发布清单最重要的一项，是扫描旧语境。

发布前最该查的不是代码有没有少拷，而是旧项目有没有跟着误混入。私有仓库名、本机绝对路径、secret、token、项目专用术语，还有 .tmp、mailbox、cache、临时输入文件这类运行残留，都要扫一遍。README、API 文档和前端文案也一样，只要还在讲上层业务，就说明这个仓库还没真正独立。

验证要在干净树里再跑一次#

在源目录里验证通过，不等于独立仓可用。

独立仓可能没有源仓的相邻目录、终端 sidecar、测试夹具或上层 AGENTS 文档。最容易出问题的地方，往往不是重点脚本本身，而是藏在脚本里的路径假设。

所以会特意在干净树里再跑一遍：先确认 Python 文件能编译，再跑治理报告和 JSON 输出，最后看 launcher、任务启动脚本的 help 能不能正常显示，看板也要能指回本机 launcher。

已知范围要写出来#

独立发布不是假装通用。

codex-governance 第一版明显偏 Windows、PowerShell、本地 Codex CLI 和本机 HTTP API。这些限制应该写在 README 里，而不是等别人自己撞上。

这些话写清楚不会削弱项目，反而会让项目更可信。它现在不是公网控制面，也不是跨平台成熟产品，更不是任意命令执行器；第一版仍然偏 Windows、PowerShell、本地 Codex CLI 和中文三省三部语义，适合本地可审查协作，不适合直接暴露成服务。

离开原项目以后还能不能站住#

把大仓里的工具独立发布，不只是搬家，还要重新定义适用范围。

这次拆完之后，对独立发布的理解也变了。它不是把代码搬到新仓库就结束，而是确认这个工具离开原来的工作现场以后，还能被别人看懂、跑起来，也不会把不该带出去的上下文一起带出去。