Rune 作为公开依赖¶

决策（Dax，2026-10-22）： Rune（anomalyco/rune）以 MIT 许可证公开，与 Hex 所采用的许可证相同。Hex 将其作为普通的公开 Git 依赖项：

rune = { git = "https://github.com/anomalyco/rune.git", rev = "<sha>" }

rune-kit 和 rune-theme-opencode 使用相同的 URL 和 rev。

Rune 以干净的提交历史发布：其 main 被替换为单个根提交（7eea3a3），该提交保存了最后一个私有 main 的代码树以及许可证。此前的提交，包括 Hex 之前固定的每个 rev（例如 338d22a），在 Rune 的分支上已不复存在。

为什么¶

Cargo 会获取 Cargo.lock 中的每个 Git 依赖项，包括可选的依赖项。在 Rune 还是私有的时候，即使是没有启用 Rune 的构建，也会因为无法访问 Rune 而失败（CI、Nix flake 和外部贡献者）。Hex 和 Rune 都没有发布到 crates.io（publish = false）；切勿运行 cargo publish。以下替代方案均被拒绝：

• 部署密钥或 Token 机密。Fork 的拉取请求不会获得机密，而 Nix 的固定输出获取器无法使用 SSH，因此每个公开消费者仍然会失败。
• 将 Rune vendor 进 Hex。发布 vendor 副本无论如何都等同于发布 Rune，而且该副本会偏离 Rune 的 main。
• 私有 Cargo 注册表。它与 Git 存在相同的凭据问题，而且还需要运行一个注册表。
• 为 Rune 前端建立私有仓库，以库（library）形式依赖 Hex。公开的 Hex 将不带 UI 发布，而且单进程设计会把 Rune 的事件循环放在 Hex 的主进程中。

这对 Hex 意味着什么¶

• 无需凭据或 SSH。.cargo/config.toml 不再设置 net.git-fetch-with-cli。
• CI 会像获取任何其他 crate 一样获取 Rune；Rune 是一个普通依赖项（没有 cargo feature），因此每次检查都会构建并测试它。检查工作流在推送到 dev 时运行。
• Nix：nix/package.nix 在 cargoGitDependencies."rune-0.0.1" 中列出 Rune 的 rev 和哈希，并且该哈希会以 rune-0.0.1 的形式出现在 cargoLock.outputHashes 中。一个条目即可覆盖该仓库中的每个 crate。每次 Rune pin 更新都必须同时更新这两处。 要获取新哈希，请将其设置为 lib.fakeHash 并运行 nix build .#hex.cargoDeps；错误信息会打印出要使用的哈希。scripts/check-nix-git-pins.py 会使记录的 rev 与 Cargo.lock 不匹配的拉取请求失败。
• 一次 pin 更新会同时更改所有三个 crate 上的 rev，随后运行 cargo update -p rune -p rune-kit -p rune-theme-opencode。在 Cargo.lock 中为 gpu-allocator 保留 windows 0.62.2，以便 Windows DX12 构建保持绿色。