复杂任务规划与执行控制 · 个人项目
当多个复杂任务并行时，如何保持方向、边界、任务质量和可追溯决策？
Chief 是个人方法项目。它把复杂目标拆成任务，并明确规划、执行、审查与验收之间的职责边界。
项目简介
Chief 是一套面向多项目 AI 工作流的人工中控方法。当 Owner 没有精力同时盯住多个项目时，它负责收束方向、明确边界、写成可验收的任务，再把实施交给独立执行窗口。它把事实、推断、建议和决定分开，也把规划、执行、审查和验收分开。执行结果不能由执行者自验后直接进入生产，必须回到 Chief 复审。
自动执行器曾验证过状态机、隔离、写入边界和回滚，但现实中的网络、认证、沙箱与进程回收还不足以承担无人值守责任。因此目前保留治理方法，封存自动派发：可追溯和可恢复，优先于自动化程度。
核心机制
规划、执行、审查、验收，四道职责边界。
规划｜拆解目标、依赖和完成条件。
执行｜在明确范围内完成任务，不自行扩大权限。
审查｜检查证据、风险和遗漏。
验收｜只有满足预先定义的标准，任务才算完成。
当前边界
治理方法已公开，自动执行器未进入生产。
当前边界：治理方法已公开；自动执行器只完成设计验证，未进入生产。实际工作仍由人工启动执行窗口，并在关键节点复审。
补充证据
角色链与自动执行器被封存的原因。
以下内容是上面主叙事的工程底稿，均可在公开仓库中逐项复核。
Owner
→Chief
→Julius / Director / Eval
→隔离 Executor
Chief 只编写任务书、复审与决策记录；代码修改、测试、提交、合并、部署由人工启动的隔离 Executor 执行。
为什么封存自动执行器
已证明成立的部分
- 任务、项目、租约和状态机可以工作
- 独立 clone 与 fail-closed 写边界可实施
- 白名单外写入可被内核拒绝
- 失败可回滚到已知安全入口
没有进入生产的原因
- 执行器 A：隔离环境中网络/API 可达性不稳定
- 执行器 B：CLI 依赖桌面/Node 环境，出现挂起
- 执行器 C：白名单、输出契约、进程回收、凭证清理均存在缺口
当前裁定：保留 Chief 的治理方法，自动执行器接入标记为 DESIGN-ONLY / ARCHIVED。以不同任务窗口手工撰写方案，再由人工启动的执行窗口实施。