🔭 Preview before prod

The pattern for public apps here is short enough to fit in a sentence: push the task branch, get a preview URL, share it, merge to main only after a human says yes. The point is not distrust of the agent. It is that “does this look right to the person who owns it” is a question only that person can answer, and a preview URL is the cheapest way to ask.

The loop

1. Work happens on agent/<slug> in its worktree.
2. A push to that branch produces a preview deployment with its own URL.
3. The agent reports the URL, with screenshots at phone and desktop width already taken and looked at.
4. The human opens it on a phone, because that is where the public will.
5. Merge to main. Main deploys the changed apps automatically.

For the private console, the loop is shorter because the only user is the operator: deploy, look, then commit. The order flips only when the page stamps its own commit hash, as Part 3 explained.

Land it in one motion

Half-finished work spread across sessions is its own failure mode: a branch with commits nobody remembers, a worktree that is dirty for a week, a task board row that says “in progress” forever. A skill on this machine exists purely to close a task cleanly: commit what this session changed in sensible groups, run the canonical check once, push, merge if on a branch, deploy, verify the live content, update the task board, and leave the tree clean. It runs when the human says “finish up”. Everything before that is a draft.

What the agent never does

Force-push to main. Merge without the human’s yes on a public app. Bypass hooks. Delete a branch that has unpushed commits. Each is a one-line rule in the constitution, and each is there because the agent is fast enough to do all four before you have finished your coffee.