计划会淹没在对话里
聊多了以后，真正的任务边界、验收条件和下一步动作很难再准确找回来。
为什么需要 CodeArmy
长任务一长，状态就开始散。
短任务靠聊天就够了。长任务一旦跨仓库、跨人、跨计算面，计划、证据和下一步动作就会慢慢散掉。CodeArmy 的价值，就是把这些状态留在能复查、能恢复的地方。
长作业会跑得比人更久
集群作业、等待中的检查和后续唤醒还在继续，但人的上下文已经断了。
review 和 rerun 证据四处分散
提交、审阅结论、日志和后续动作常常散落在不同线程和工具里。
多仓库修改容易失去边界
如果没有明确 scope，就会越来越难判断哪些修改是一组、哪些依赖还没闭合。
CodeArmy 能做什么
它做的事都很具体。
重点不是喊概念，而是把长任务最容易丢的那部分状态接住，让下一步动作更清楚、当前状态更可查。
把目标拆成真正能执行的任务包
计划会落成 phase、task、依赖、write scope 和 acceptance，而不是一串模糊待办。
自动看清 ready、blocked 和 waiting
Reconcile 直接从仓库真相源推导队列，而不是依赖操作员记忆。
把人工批准留在流程里
计划批准、review 结论和 reopen 决策都是显式状态，不靠默认理解。
在隔离执行面里推进工作
Source repo、分支、worktree 和远程作业都保持边界清楚、责任明确。
让长任务能等，也能回来接着做
等训练、等评估、等外部证据，不再意味着主线状态丢失。
把状态和报告一起写回仓库
驱动执行的那套任务产物，本身也能支撑 live report 和最终总结。
流程
一个目标，五步走完一轮。
这是站在用户视角的一条主线。每一步都会留下产物，方便下一位人或 agent 接着往下做。
明确目标
先把本轮目标、涉及仓库和执行边界说清楚。
campaign.md生成计划并批准
把目标落成 phase 和 task package，需要时先过人工批准门。
plans/ + task packages在隔离范围内执行
任务在隔离的仓库、分支、worktree 或作业环境中推进。
results/ + commit anchors审阅并回填
Reviewer 的结论、疑点和后续动作，写回任务本身所在的位置。
reviews/Reconcile 后进入下一轮
刷新 campaign 状态，暴露 blocker，再决定下一波动作。
live-report.md真实案例
它适合那些已经复杂起来的真实工作。
下面这些是 Alice / CodeArmy 当前工作环境里已经存在的典型 campaign 形态，不是凭空编出来的营销例子。
CodeArmy 站点改版
用一个 campaign 管网站定位、双语修复、内容审阅和最终发布，而不是边聊边改。
- 内容改写和界面修复分成明确任务，而不是混在同一轮聊天里。
- Review 记录会说明为什么通过，或者为什么打回。
- 收口时可以直接用 live report 对齐真实仓库状态。
FastEcalSim 恢复任务
把本地代码修改、smoke test、集群作业、checkpoint 检查和后续唤醒放在一条可追溯主线上。
- 任务包能直接指到 worktree、脚本、checkpoint 和质量门槛。
- 外部评估证据没回来时，blocked 状态会被显式保留下来。
- 交接说明仍然挂在同一个 campaign 下，不会漂到新线程。
JUNOSW 多仓库调优
让文档仓库、代码仓库、历史证据和 phase gate 统一落在一套规划面里。
- 旧 archive 只作为参考证据，不会悄悄污染当前主线真相源。
- Repository issues 和依赖阻塞可以由 reconcile 自动暴露。
- 下一步动作不需要再靠表格和人工状态板维护。
为什么必须仓库优先
仓库优先，不是口号，是为了接得住。
聊天可以帮助人和 agent 推进协作，但真正发生了什么、当前走到哪一步、下一步能不能继续，必须落在仓库里。只有这样，中断、交接和 review 才可靠。
- 新的 agent 可以直接从仓库产物重启，而不用回放一整周聊天。
- Review 面对的是和执行同一份 task package，而不是事后整理的摘要。
- 报告只是对仓库真相源做总结，不替代底层证据。
- 人类在批准下一步之前，可以先看清楚当前真实状态。
Campaign repo 里通常放什么
这套结构故意保持纯文本和可 diff，目的是方便检查、审阅和接力，而不是做成花哨黑盒。
campaign.md
plans/proposals/
plans/merged/master-plan.md
phases/Pxx/tasks/Txxx/task.md
phases/Pxx/tasks/Txxx/reviews/R001.md
reports/live-report.md
快速入门
最快理解它的方法，就是亲手跑一轮。
如果你想快速上手，就先建一个 campaign repo，然后把控制循环跑一遍。
建立 campaign 外壳
从真实目标和需要协作的仓库列表开始。
alice-code-army create
alice-code-army bootstrap扫描仓库和边界
先把 source repo 和执行面写清楚，再派发任务。
alice-code-army repo-scan执行 reconcile
让系统从仓库真相源里推导计划状态、可执行任务和阻塞项。
alice-code-army repo-reconcile批准、执行、审阅
保留人工门控，再把执行和 review 证据写回同一 campaign。
alice-code-army approve-plan如果你是在排查系统自己，就要把 runtime repo 和 campaign repo 一起看：前者解释控制流，后者保存长期状态。