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:
- 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-Xnaming a module path that had moved; the linker drops that silently), and the fix had to go out as4695e430-r2.vet --bootalready 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. - 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.