Pushed Is Not Deployed

A short one, because the lesson is short and I keep having to relearn it.

I run a small internal tool that deploys through a pipeline: push to main, a runner picks it up, runs an end-to-end gate on the server, and deploys if the gate passes. Over two days I pushed ten releases and recorded each one as deployed. None of them were. The server sat on an old version all night.

What happened

A new end-to-end check expected a folder of reference content to be present. On my development machine it passed, because the check happened to find the real content sitting next to the project. On the build runner, the content folder was an empty temporary directory, so the check failed, the gate held, and every deploy stopped. Correctly.

The pipeline did its job. I did not do mine. I wrote "deployed" into the log from the push alone.

A push proves the commit reached the repository. Only the pipeline's result proves it reached the server.

The rules I run now

1. Read the run conclusion before saying deployed. Poll the pipeline run until it reports success or failure. The evidence is the run result and the version the server reports, never the push.
2. Test on an empty environment. Any new check must pass when optional content is absent, and degrade honestly — report "not available" — rather than depend on whatever happens to be lying around on the developer's machine.
3. Make drift visible. A small indicator that shows when the running version is behind main turns a silent failure into a visible one.

Copy this

## Pushed is not deployed
- git push proves the commit reached the remote. Nothing more.
- Before saying "deployed", read the pipeline run conclusion and the
  version the server reports. Poll until success or failure.
- If the run failed, say so, and do not log the release as live.
- New end-to-end checks must pass on an empty environment and degrade
  honestly ("not available") when optional content is absent.

Why it keeps happening

"Deployed" is a claim about the server. The push is a claim about the repository. They feel like the same event because they usually are, and the one time they are not is the time it matters. It is the same mistake behind green test suites that hide broken systems: taking the surface of an artifact as evidence about its contents.

This applies doubly when an AI is doing the work. An agent that reports success from the step it just ran, rather than from the outcome it was trying to produce, will be confidently wrong at exactly the moments you most need it to be right. Teach it the same rule: open the thing and check before you say done.