Cromford is an open-source software factory that delivers changes finished with review, merge, and pre-release validation once a ticket is submitted. The November 3, 2026 03:52 UTC commit b35afb0 touched 8 files and 425 lines (420 insertions, 5 deletions). The commit title is “Cromford 2026.11.03 (upstream 22d8c0ad9714)”, and the targets are the shell script that publishes commit statuses to GitHub along with its configuration, documentation, and tests. The source is the corresponding commit on GitHub (https://github.com/cromford-ai/cromford/commit/b35afb0f4607921d6b4800b6e601554cb82448ce).
There are two core points. bin/lib/gh-rest.sh extracts `.message` from the response JSON and leaves it as GH_REST_MESSAGE. It takes a value only from responses that are neither 2xx nor 304 or 404, folds line breaks into a single line, and then truncates to 200 characters. vs_publish in bin/lib/verdict-status.sh publishes only with an installation token starting with ghs_ in boxes where App tokens can be minted (gh_auth_armed). Because gh-token.sh prints a PAT when minting fails, tokens that are not ghs_ are treated as failures; after one more minting attempt, if it still is not ghs_, it leaves only the single line “vs_publish: no App token for <slug>” and does not publish (rc 1).
Changes that make the causes of failures easier to read also went in. The error line now records the HTTP status and reason, the token type (app|pat|gh-auth|other, without printing the token value), and the message sent by GitHub. And only when 403/429 is classified as a rate limit and GitHub's Retry-After is 1 second or more does it wait that long and then publish once more. The maximum seconds to wait is VS_RETRY_AFTER_MAX_S, read from the lib.verdict-status.vs_retry_after_max_s setting in the newly added catalog/lanes.d/_lib.verdict-status.json, and the code default is 30 seconds. If the setting is not an integer, it falls back to 30 seconds.
That said, it is hard to determine the scope from this commit alone. The changes are confined to the status publishing path inside the shell script, and the published facts contain no license, use case, or performance figures. The 285-line test file and the 2026-11-02 BH-8848 design note show the verification procedure only, with no execution results given. The token classification also depends on the prefix alone, so it does not reveal the actual permission level. Furthermore, the commit title says “publish with an inherited token if App minting fails”, but the diff blocks publishing with an inherited token in an armed box. Which of the two is the intended behavior cannot be confirmed from this commit alone.