steventsvik/tellurion 是一款监控应用，用于实时观察 Claude Code、Codex、Gemini 等 AI 编码代理在单个 macOS 终端中工作的情形。2026 年 11 月 4 日合并的 PR #118 修复了发布检查那一侧。它废除了 release.sh 在构建出的应用二进制中硬编码五个仅用于测试的开关名称来查找的做法，改为由新脚本 release-checks.sh 直接从 Swift 源码中抽取当前名称并加以比较。在同一次提交中，release.sh 的上游版本确认方式也发生了变化：改为读取 build.zig.zon 中的包版本，而不再使用 git 标签；CI 工作流中新增了一行，用于运行新添加的 test_release_checks.py。此次变更共 218 行，其中新增 216 行、删除 2 行，涉及四个文件。
这里的“开关”指的是只进入测试构建的内部环境变量和标志。该应用需要在发布前筛掉仍带有测试钩子的二进制，但如果把名称列表手工写下来，一旦源码中的名称发生变化，grep 就什么都找不到，检查看上去就会像是通过了。新脚本从源码中读取形如 TestHooks.value 或 TestHooks.flag 的名称，并以大写字母开头的名称作为候选；同时，由于 Swift 会把 15 字节及以下的字符串藏在命令里、使 grep 看不见这一限制，它只把 16 字节及以上的名称作为检查对象。返回值分为三种。0 表示干净，1 表示发现了开关，2 表示检查本身未能执行，而 2 同样按失败处理。无法执行检查的情况不视为通过，这一原则原样写在代码注释里。
不过，这项检查是依赖命名规则和源码排布的字符串搜索。如果从源码中抽取到的名称少于 20 个，这件事本身就会报告为失败；而名称的长度和书写方式一旦改变，搜索对象也会随之改变。新测试直接创建用于通过的文件和用于失败的文件，并运行脚本加以确认，但提交资料中没有执行结果的数值。PR #118 只不过是对发布流水线内部安全装置的调整，资料中没有关于应用功能或性能发生变化的内容。它看起来是为了提高发布流程准确性的改动，但要判断实际发布结果还为时过早。