架构与采纳模型
推荐方法
scaffold + selective modules + reference docs
生成本地基线 → 只复制项目需要拥有的文件 → 按需引入可选模块 → 其余保持引用
为什么不默认使用 Submodule
将此仓库作为 submodule 使用通常很别扭：
- 大多数采纳的文件需要本地编辑
- 项目会以不同速度分叉演进
- 同一规则在本地和上游同时存在时所有权模糊
- 许多文档作为参考有价值，但不应该在每个项目中维护
submodule 对只读标准镜像仍然合理，但不应该是默认采纳路径。
Bootstrap 层次
agent-bootstrap/
templates/core/
基线，每个项目都要
README.md.tpl
.gitignore
docs/BOOTSTRAP_ADOPTION.md
docs/OPERATIONS.md
schemas/
scripts/validate_repo_structure.sh
artifacts/runs/
templates/modules/
可选附加模块
tmux/
eval-harness/
multi-run/
browser-adapter/
docs-dual-format/
docs/
参考材料，通常不复制
core/
modules/
adoption-model.md
overview.md
什么会被复制
| 内容 | 说明 |
|---|---|
| 最小仓库布局 | artifacts/, docs/, schemas/, scripts/ |
| 运行时工作空间基线 | artifacts/runs/ 作为一次性运行输出的默认位置 |
| .gitignore 基线 | 忽略本地密钥、缓存、运行时工作空间、评测临时文件 |
| 运维与采纳文档 | OPERATIONS.md, BOOTSTRAP_ADOPTION.md |
| 状态与事件 Schema 样例 | JSON schema 与示例文件 |
| 最小验证脚本 | validate_repo_structure.sh |
| 选定的模块模板 | 项目选择启用的模块 |
什么保持为引用
| 内容 | 原因 |
|---|---|
| 理念与权衡解释 | 理解"为什么"，但不属于运行时行为 |
| 反模式与迁移说明 | 按需查阅，不需要常驻项目中 |
| 项目未采纳的可选模块 | 避免膨胀 |
| 组织级指导 | 跨项目相关，但不是项目运行时一部分 |
项目级所有权
关键原则
模板一旦复制，项目就拥有它们。Bootstrap 仓库是新起点的来源，而不是每个项目必须持续跟踪的运行时依赖。
对维护者
如果更改模板、模块覆盖范围或文档化文件表面，请运行：
scripts/validate_template_integrity.sh