Cromford 是一个开源软件工厂：只要投入工单，就会交付经过评审、合并以及发布前验证的变更。2026 年 11 月 3 日 03:52 UTC 的提交 b35afb0 改动了 8 个文件、425 行（420 行新增，5 行删除）。提交标题是“Cromford 2026.11.03 (upstream 22d8c0ad9714)”，对象是把提交状态发布到 GitHub 的 shell 脚本及其配置、文档与测试。来源是 GitHub 上的该提交（https://github.com/cromford-ai/cromford/commit/b35afb0f4607921d6b4800b6e601554cb82448ce）。
核心有两点。bin/lib/gh-rest.sh 从响应的 JSON 中取出 `.message`，保存为 GH_REST_MESSAGE。只有在响应既不是 2xx、也不是 304 或 404 时才取值，先把换行折叠成一行，再截断到 200 字符。bin/lib/verdict-status.sh 的 vs_publish 在能够生成 App 令牌的盒子（gh_auth_armed）上只用以 ghs_ 开头的安装令牌发布。由于 gh-token.sh 在生成失败时会输出 PAT，因此不是 ghs_ 的令牌会被视为失败；在再尝试生成一次之后仍不是 ghs_ 时，只留下一行“vs_publish: no App token for <slug>”并且不发布（rc 1）。
也加入了让失败原因更易读懂的改动。错误行现在会同时写出 HTTP 状态与原因、令牌种类（app|pat|gh-auth|other，不输出令牌值），以及 GitHub 发来的消息。而且只有在 403/429 被判定为速率限制、且 GitHub 的 Retry-After 不小于 1 秒时，才会等待相应的时间后再发布一次。等待的最大秒数是 VS_RETRY_AFTER_MAX_S，通过新加入的 catalog/lanes.d/_lib.verdict-status.json 中的 lib.verdict-status.vs_retry_after_max_s 配置读取，代码默认值为 30 秒。如果配置值不是整数，就回落到 30 秒。
不过，仅凭这个提交难以界定范围。改动仅限于 shell 脚本内部的状态发布路径，已公开的事实中没有许可证、适用案例或性能数据。285 行的测试文件和 2026-11-02 的 BH-8848 设计笔记只展示了确认步骤，并未给出执行结果。令牌分类也只依赖前缀，因此并未揭示实际权限级别。另外，提交标题写的是“App 生成失败时用继承令牌发布”，但 diff 实际上阻止了在 armed 盒子上用继承令牌发布。究竟哪一方才是预期行为，仅凭这个提交无法确定。