一个功能可能同时涉及 API 服务、客户端应用和公共库。这些修改属于同一个目标，却不一定属于同一个 Git 仓库。2026 年 9 月 26 日发布的 Genesis 0.13.4 为可写的关联仓库加入持久化工作树，让跨仓库工作有了更明确的执行边界。
从访问代码到隔离工作
0.11.4 已引入额外仓库的读写支持，包括逐仓库审查以及对只读仓库的写入限制。0.13.4 在此基础上，为每个可写关联仓库提供持久化工作树：智能体在其中工作，而不移动仓库主 HEAD，也不干扰其主要工作区。 v0.11.4
指向关联仓库的路径会相对于该工作树解析。智能体的初始上下文显示其位置，跨仓库任务委派也以此为基础。当不同仓库具有不同目录结构，或仍有其他开发活动时，这让变更发生的位置更加清晰。 v0.13.4
集成仍然逐仓库决定
0.13.0 引入了逐仓库审查卡片，分别显示合并、拒绝操作、合并检查和处理状态。全部合并快捷操作可以一起接受尚未处理的仓库，同时保留各自的结果。该版本也修复了任务只修改关联仓库时的审查流程。 v0.13.0
一次 API 修改可以沿服务、客户端与公共库各自的历史接受审查。先约定接口版本和集成顺序，再针对组合后的结果运行检查。
准备一次跨仓库审查
委派前，确认各仓库可写工作树的位置；完成后，通过对应审查卡片检查修改、合并检查与处理状态。跨项目任务由此落实为一组明确的验收决定。开发历史视图可以帮助追溯这些决定背后的提交。