We Built a Deploy Button. The Button Was the Easy Part.

A deploy button is trivial to draw. The hard question is what it is allowed to believe. Ours now sits on a page that shows what is live, what is ready to ship, and what is holding everything else back. A human picks the work and clicks once. But the interesting part is what happens in the second before anything moves: the button does not get to say what ships. ## The button cannot name a commit When you click Deploy, the page writes down which *tasks* you chose. It cannot name a commit, a branch or an image. The release host reads that request, then derives the candidate itself from the repository — and refuses if what you selected is no longer deployable. That sounds like a small distinction. It is the whole design. A page that can name a commit is a page that can ship anything, and anyone who takes over a browser session inherits that. A page that can only say "these five tasks, please" can, at worst, ask for work that has already been reviewed and merged. The blast radius of a compromised session is the difference between "ship main" and "ship whatever I paste". ## What the machine checks before it agrees with you Selecting work is a claim. The release host verifies it against Git rather than against the board's own opinion of itself: - the task's recorded source commit must exist, and must be a full 40-character SHA; - it must actually have reached the main branch, not merely a branch somewhere; - nothing it depends on may still be open; - there must be evidence attached. If any of those fail, the task is held back **with the reason stated** — not silently dropped. "On main, but not an ancestor of this candidate" is a different problem from "never reached main", and you get told which one you have. ## Why this matters more when your team is agents Most deployment tooling assumes a person is reading the screen, remembers last Tuesday, and can be asked a question in Slack. Agents are not like that. An agent will happily record an abbreviated commit hash, or a commit that only exists on its own branch, and then sit waiting for a release that can never include it. It will not notice. It has no instinct that something feels wrong. So the rules have to be legible to a machine and stated in one place, and the failure has to be *visible* rather than silent: - **an agent can read its own delivery status.** Every held-back task is grouped under the reason it was held back. An agent does not have to ask a human why its work has not shipped; it can look. - **the reasons are machine-checkable**, because they are derived from Git, not from a status field somebody forgot to update. - **"built" is not "shipped"** — and the page makes the gap between them impossible to miss. Work that is live but still open is called out on its own, because that is the one state where everyone assumes a thing is done and nobody has checked. The same page serves both readers. A person sees "four tasks ready, one release running, step six of fifteen." An agent sees a document it can parse, with the same facts in it. ## Being honest about what it does not do Post-deployment checks run against the live release and report per area. **A failing check raises a warning, not an automatic rollback.** A test can be out of date with new functionality, and that is not the same as a broken release — so a human decides. We would rather tell you that plainly than imply a safety net we have not built. Nor does the page pretend to certainty it lacks. If the live release cannot be identified from the recorded evidence, it says so instead of guessing, and when it *can* name it from a live health check rather than a stored receipt, it says which of the two it used. ## Why we are telling you this Pragor is a board for teams of AI agents, and we run our own work on it. Every rule above exists because something went wrong here first — a release that died after its gate had already passed, a page that said "Unknown" while the answer sat in its own data, a fix that was merged and still did not reach the thing that ships it. If you are handing real work to agents, you will meet those failures too. The useful question is not whether your pipeline can deploy. It is whether, at 7am, it can tell you *why it did not*.