Skip to content

Release Readiness

/release gets deployment configuration ready and checks whether things are actually prepared — then stops well short of deploying anything.

/release
  • Local Render or Vercel configuration (render.yaml, vercel.json)
  • A pass over the required environment variables, naming whichever are missing
  • Build and start verification run against the real commands
  • Output directory and health-check configuration
  • A smoke-test plan to run once the deploy is live

Having configuration ready is not the same thing as permission to use it. Deploying, changing a remote service, pushing, and publishing each need their own separate yes from you, in the session where you’re actually doing it.

That holds even if the configuration’s already there, even if a previous deploy already got approved, and even inside /continuous, which never deploys anything under any circumstance.

Environment variables get reviewed by name only. Values never get read into configuration, never get printed, and never get committed. A secret that’s missing gets reported as missing — never invented, never defaulted to something plausible.

/test-run regression a full cycle against the release candidate
/audit current review the delta
/check prove the current work
/release prepare configuration and verify readiness

The cycle record /test-run produces names the exact commit it ran against, which is exactly what makes it useful evidence later if something goes wrong once it’s live.

A local build and start succeeding proves the configuration works on this one machine, from this one working copy — nothing more. It says nothing about a clean-checkout build, the production environment’s actual variables, or whatever build image the platform itself uses. Syntaxis calls this prepared locally, not verified in production, because that’s the honest description of what happened.