ND-67 的主要时间成本并不是 Skill 数量，也不是compileall等轻量检查，而是同一源码快照被多个角色重复证明，以及在轻量 driver/preflight 尚未稳定时过早进入 PyInstaller、Tauri frozen build 和桌面旅程。
因此，本次项目级优化的核心不是减少必要验证，而是把测试、构建、审查和端到端验收从“每个代理的交接仪式”改成“整个任务的一条全局验证流水线”：每个验证层级只有一个所有者，相同源码快照上的证据可以复用，只有相关输入变化才重跑。
原始笔记给出的判断
本地剪藏codex流程编排过度导致运行过慢记录了几个典型慢因：
主控下面继续堆 full-history 子代理，导致每个子任务重复阅读长上下文；
多轮“审查 → 修复 → 复审”；
高频轮询长任务；
每个小改动都执行全仓测试；
把“更多代理、更多审查”误当成更高准确率。
其中最有操作价值的 spawn 判据是：一个子任务只有在能够独立、输入输出清楚、预计确实降低总墙钟时间时才值得交给子代理。三个条件不能同时满足时，由主线程直接完成通常更快。
ND-67 的实际执行证据
ND-67 实现了单一活动文档的有界全文总结链路，并完成了模块和集成层验证。项目验证文档记录的主要结果如下：
验证层级实际结果说明
ND-67 专项回归12 tests，36.471s，exit 0覆盖严格路由、文档绑定、连续范围读取、单次 synthesis 与 fail-closed 路径
组合回归100 tests，87.916s，exit 0覆盖 ND-51、ND-53C、ND-60C～ND-67 相关链路
Python 静态检查compileallexit 0属于低成本门禁
前端回归与构建8 组 Node scripts；npm run buildexit 0Vite 仅有既有大 chunk warning
Rust/Tauricargo checkexit 0；Tauri no-bundle build 成功证明构建，不等于桌面用户旅程
Frozen sidecarfresh PyInstaller onefile build 成功source/dist/release sidecar byte comparison 通过
独立审查Terra 最终无 P0/P1、无阻塞 P2但过程中进行了多轮只读审查与测试复跑
Linux frozen Tauri/WebView 用户旅程NOT VERIFIED（用户跳过）D-Bus、onefile 等待、遗留 X display、AT-SPI app discovery 阻止形成可接受旅程
ND-67 的功能实现证据充分，但执行过程暴露出四个编排问题：
验证角色重叠。实现者、测试代理、集成验证者、审查者和 Sol 都可能重新运行类似测试，命令通过却没有新增判别价值。
高成本门禁启动过早。frozen build 和桌面旅程开始前，轻量 driver/preflight 尚未完全稳定，环境问题被包装成本放大。
审查循环偏多。最终质量可以由一次独立终审与一次有条件的窄 readback 保证，不必默认多轮完整复审。
长任务等待不够事件化。构建、启动和桌面发现阶段的频繁状态检查增加模型/工具往返，但没有增加工程证据。
需要保留一个边界：ND-67 计划确实要求 Linux 用户旅程，因此最初尝试 release gate 并不是错误；问题在于执行顺序和重试策略，而不是这个验收目标本身。用户明确跳过后，正确做法是保留NOT VERIFIED，而不是用构建成功替代用户旅程。
本次项目级优化
本次调整覆盖项目根AGENTS.md、.codex/config.toml、.codex/README.md和六个项目角色配置，形成以下规则。
1. 减少无收益并发
子代理并发上限由 4 降为 2；这是容量上限，不是并行目标；
只有 Sol 可以创建子代理，项目角色不得嵌套 spawn；
默认只有一个实现者；mapper、test engineer、integration verifier、reviewer 都按真实缺口选用；
优先使用fork_turns="none"或最小必要轮次，加自包含任务包，避免继承完整长会话；
同一模块的修复和补充说明优先复用已有代理，而不是不断创建新代理。
2. 建立唯一验证所有者
实现者默认只运行一个能够否定当前实现的最小 focused test；
test_engineer只负责测试设计或一次受影响模块回归，不运行 packaging/E2E；
integration_verifier是 broad build、跨组件、运行时和桌面旅程的唯一所有者；
independent_reviewer默认只做一次静态终审，不再充当第二个 test engineer；
Sol 检查最终 diff，只重跑被后续修改实际失效的证据。
3. 用验证账本复用证据
每条可复用证据至少记录：
{source snapshot, command, environment/data root, exit code, duration}
相同源码、配置、构建身份和环境上的同一高成本命令默认只执行一次。后续角色直接引用账本，而不是为了让交接显得完整重新运行。
证据失效遵循“相关输入变化”原则：
变化需要重跑不自动重跑
Python 生产代码focused test；必要时模块回归或compileallCargo、Tauri bundle
React/TypeScript 生产代码相关 Node scripts；最终npm run build一次Python 全套、Rust 检查
Rust/Tauri 边界对应 Cargo/Tauri 检查无关 Python/前端回归
FastAPI/OpenAPI 契约后端契约验证与一次npm run api:sync无变化时不生成客户端
test/driver受影响测试或 driver/preflight未变化的生产二进制重建
文档、AGENTS.md、.codex格式、TOML/schema、指令一致性、diff业务编译和全仓测试
4. 高成本验证后置
建议的全局验证阶梯是：
最小 focused test；
必要静态检查；
一次受影响模块回归；
验收明确要求时，执行一次集成、构建或端到端门禁；
一次独立静态终审；
只对真实发现做定向修复，并只重跑因此失效的证据。
PyInstaller、Tauri bundle、真实网络、浏览器/AT-SPI 和 frozen 用户旅程必须在低层证据、轻量 driver 和 preflight 已稳定后启动。同一路径连续失败两次，或约 30 分钟没有新证据时，应停止重复尝试，由 Sol 调整路线或请求用户决策。
5. 减少轮询和 Graphify 重建
长进程使用事件等待或 45～60 秒有界等待；状态不变时不产生重复分析；
Graphify 只在最终相关源码和文档稳定后更新一次；
不因在验证文档中回填 Graphify 统计数字而再次重建图谱。
