carlos / platform Public

vet: refuse a binary that doesn't report the version being shipped; and a browser gate before promote Feature Request open

Two checks carlos vet is well placed to make:

  1. The stamp. Versions are immutable once shipped, so a binary that reports the wrong version is on the release list for good. ips shipped one reporting dev (a -X naming a module path that had moved; the linker drops that silently), and the fix had to go out as 4695e430-r2. vet --boot already boots the binary and polls /healthz. It could also read /api/version (or the app's build probe) and refuse unless the body names the version being shipped.
  2. The screens. Tests pass before merge; nothing checks the canary before promote. A pipeline rung (or vet --drive <cmd>) that runs the app's own browser smoke suite against a canary URL and refuses the promote on failure would close the gap between "tests green" and "serving". Replit's agent now drives the built app in a browser for this reason.

--- Filed from the ips repository (Turnkey's insolvency practice system, built on rastrillo v0.26.0 and deployed on CARLOS), where this was worked around. Paths without a repository prefix are in ips.