[viztor]

Why

The nightly catalog freshness job regenerated both vendor tables in one fail-fast step: the catalog first, then the Go limits. Since 2026-11-07 the limits generator has failed every night, because the vendor's Go page changed under its reader. So no refresh pull request has been proposed since 11-06, not even for the catalog. According to the 11-11 run's own log, the catalog moved Go 31 → 32 and Zen 82 → 87 in that time.

What changed

.github/workflows/ci.yml, the nightly "propose the refresh" step

• Both generators are guarded the same way. A failure:
  • is annotated with ::error:: where it is detected, so a later failing command cannot swallow the cause;
  • leaves its file as committed (git checkout);
  • does not stop the other file's refresh, which still goes out;
  • fails the step at the end.
• The catalog file is put back before the limits generator starts. That generator imports src/catalog-data.ts, so it never reads a half-written catalog.
• When nothing changed, the log calls current only the files that actually regenerated.
• A partial refresh replaces an open refresh PR's other file, with a warning. The branch is rebuilt from main every night. When one generator failed, the run warns that the open refresh PR no longer proposes the kept file. This is deliberate: an older night's output is never carried into a commit that says it was regenerated.
• A failed gh pr create is no longer read as "already open". The step asks GitHub whether a refresh PR is open (gh pr list … --jq length = 1). Otherwise, for example on an expired token or an API error, the run fails rather than leaving a pushed branch that no PR proposes behind a green run.

test/freshness-scope.test.ts

A new describe finds the step by name in the parsed ci.yml and executes its run text under bash -e, in a scratch git repository with stubbed pnpm, vp fmt, git push and gh. It covers:

• each generator failing;
• both failing, and neither failing;
• a failing push after a limits failure;
• a failed gh pr create with and without an open PR.

The scratch repositories drop every inherited GIT_* variable, so an exported GIT_DIR cannot redirect the step's real git commands.

CONTRIBUTING.md

One bullet in "The freshness checks in CI" that states all of the above.

The reader fix is #167, which carries these three files byte for byte. It is separate because its own limits:shim gate needs a table regenerated from the live page.

Review

Two adversarial rounds. Each finding went to two skeptics, and only upheld findings were fixed.

• Upheld and fixed:
  • the guard covered only one direction;
  • an annotation could be lost on a later failure;
  • nothing executed the step;
  • the partial-refresh replacement was unstated;
  • a misleading "both current" line;
  • the scratch repo inherited GIT_*;
  • gh failures passed for "already open".
• Declined by both skeptics: making the commit title depend on which generator failed.

Verification

Node 26 on the pushed head 38e2d7f:

• vp check: 0 errors and 21 warnings, the same as main.
• Unit suite: 92 files, 1444 tests passed.
• Mock suite: 52 passed.
• pnpm run build and scripts/check.ts: check passed.
• The step's run text, extracted from the YAML, passes bash -n.
• Red first: against the previous step text, the new step tests failed on the catalog-failure, both-fail and failing-push cases, then passed after the fix.
• No local paths in the diff.
• Freshness scope for this diff: catalog:shim, limits:shim and cli:version all report.

🤖 Generated with Claude Code

https://claude.ai/code/session_0141fKp5k6hiaJcP5ovhGtSD