# Deploy hygiene

`main` is what is deployed. The live site's source SHA must be reachable from `origin/main`. If live was built from a feature branch and `main` never caught up, the system that edits against `main` is now serving older content than the public site. The owner edits a stale base. Their save silently reverts live work. That is a breakage, not untidiness.

Clients never deploy. They edit a branch off `main`. Review, merge, then an operator deploys `main`. That separation is the safety property: a client cannot publish a mistake to their own live site.

Commands in this file are relative to a folder named `beargrassai` on the machine that runs them. If you do not have that folder, you cannot run the commands. Do not invent a home path.

## Who you are while you run it

You are about to change something that can reach production, or you are about to say what is live. You wear the deploy craft if you have it. This file is the checklist either way. Mark gates secrets, DNS, and production. You do not guess "push."

## Before

A deploy is not authorized until: the repo has a remote, it is on `main`, `origin/main` contains the SHA you will build, and you rebuild from HEAD immediately before deploying.

A dirty working tree is a state, not an incident. Uncommitted files matter in the sixty seconds before a deploy and at no other time. Do not raise a data-loss alarm about untidiness. Do not raise one about `Clients/*` at all: that tree is storage, not git.

Clone and push with the business SSH alias on this station. Not the default `git@github.com` host, which resolves to the wrong account.

```
git remote get-url origin
git fetch --prune origin
git ls-remote --symref origin HEAD
```

Run those reads yourself. Do not wrap them in a script. An opaque script around git reads is indistinguishable from automation that acts.

One repo at a time. No bulk push.

## After

Live SHA equals `origin/main`. A deploy without a rollback is not a deploy. If a campaign or hotfix line must go live, `main` is fast-forwarded to it in the same session — not later.

## Temptations (refuse these)

- Deploying from any branch other than `main`
- Leaving `main` behind live and calling it a follow-up
- Gating a deploy on a tidy tree instead of on deployed bits equal built bits
- Pushing because the tree is clean
- Raising a data-loss alarm on `Clients/*`
- A no-remote repo treated as fine. It is a data-loss exposure; report it before any deploy, not after