仓库
TinyBrains 分布在几个并列的仓库中。参赛时，你的模型放在自己的仓库里，与这些仓库都无关。用这份地图来了解平台的行为，或为它贡献改动。
四个应用仓库
这四个仓库构成运行中的平台。
| 仓库 | 负责 | 从这里读起 |
|---|---|---|
| Soma | API、认证、数据库模式、赛季管理和运行器网关，外加审核、配对、评分和版本生命周期；发布 Soma 节点镜像 | channels/、workflows/、sql/、migrations/、plugins/、docker/ |
| Kalam | 对局执行、认领、判罚和回放上传；发布运行器镜像 | workflows/、channels/、docker/ |
| Ants | 游戏规则、观测、回放重建和查看器，外加 baselines/ 中平台自带的参赛模型是如何训练的 | engine/src/turn.rs、engine/src/observe.rs、engine/src/maps.rs、engine/src/replay.rs、viz/、baselines/ |
| Web | 浏览器应用和类型化的 API 客户端，外加 docs/ 中的本书 | src/api/client.ts、应用组件、代理配置、docs/ |
参赛者可以阅读的三个仓库
这三个都不在平台中运行，而且都是为你写的。
| 位置 | 含义 |
|---|---|
| cli | tinybrains 二进制文件：对局、审核的各项检查、conform 和训练环境，为 macOS、Linux 和 Windows 发布，用 Homebrew 安装。src/wave.rs 是它对 Kalam 对局循环的复刻，src/matchfile.rs 是对局文件格式 |
| ants-starter | Ants 入门套件：一个不做修改就能通过审核的 nano 参赛模型、train.py（重新训练它的唯一命令）、models/ 中三个训练好的对手和两个对局文件。从这里开始：它是唯一需要克隆的仓库，每个游戏都有一个 <game>-starter |
| ants/baselines | 平台自带的参赛模型是如何训练的：编码、教师、学习者和导出，就放在它们所编码的规则旁边。它不提交任何模型：训练好的模型在入门套件里，赛季的基线由管理员上传到赛季中。入门套件的 requirements.txt 把它作为库安装，train.py 运行它。逐步讲解从 src/tb_baselines/planes.py 读取它的清单 |
Orion 自己的 models 实体负责 ONNX 加载、表达式语言和操作预算，所以没有模型运行器仓库。Soma 的时钟负责审核、配对、计分、撤回和租约回收，所以也没有对局调度仓库。
改动归哪个仓库？
规则或观测的改动属于 Ants，并要配上相应的参赛者文档和适配器兼容性检查。求值器操作符或操作计数的改动属于上游，即 datalogic。本平台无法做这种改动，所以操作符参考只指向引擎实际拥有的内容，自己不维护列表。一项提交检查可能横跨 Soma 的请求契约、admit 时钟的裁定和节点报告的事实：动手修改前先弄清每一部分的职责。
对局执行和结果持久化属于 Kalam；评分计算和对手选择属于 Soma 的时钟和插件。每一条数据库定义都归 Soma，无论哪个包使用它。部署地址和机密信息属于各个镜像的环境变量，绝不放进包定义里。
生成的产物以发布版本和镜像的形式交付
没有任何仓库会提交自己生成的东西。每个仓库交付自己的构建产物（Ants 的 tb-ants.wasm、cartridge.json 和查看器包，以及 wasm 插件），使用方指明自己要取的产物，不读取任何并列的检出目录。Ants 发布的是 GitHub 发布版本：它的 build 工作流在每次推送时运行质量门禁，并在需要时把所有产物打成一个压缩包，以它所携带的引擎为标签。Soma、Kalam 和 Web 交付各自 Dockerfile 构建出的镜像。Soma 和 Kalam 的包是手写的 JSON，整体提交：频道、工作流、连接器，以及 Soma 中其工作流所指名的 sql/ 文件。Kalam 不带任何 SQL，因为运行器需要的每条语句都是对 Soma 网关的一次调用。两者都没有生成器：orion-server compile 把编写形式（$from、$use、$each、$sql）解析成管理 API 接受的形式。
Kalam 不自带卡带。它的镜像构建从 Ants 的最新发布版本获取组件，所以发布一个 Ants 发布版本就会改变天梯所用的引擎。赛季进行中的部署应把 ANTS_RELEASE 锁定到某个标签。如果你让摘要在赛季进行中发生变化，运行器将无法认领该赛季排队中的任何对局。
每个插件还需要一个对其摘要的有效 Ed25519 签名。签名由部署方生成，因为信任密钥在部署方手里。插件或引擎重新构建后都要重新签名：过期的签名会让调用该插件的频道被隔离，节点在启动应用包时就会停止。
运行平台不需要任何检出目录。本地运行给出了命令。只有在你构建镜像时，并列的检出目录才有意义，它是构建的默认源码来源。
尚未提供的部分
这些仓库实现的部署路径是 Compose，本地和生产环境都是如此。它们都不包含云端自动扩缩容，发布版本靠手动部署。