🔒 Publishing rules

New here? Publish (also called deploy, “put it online”) means making a version of your work visible and accessible to other people on the internet—instead of only running on your computer. It’s the difference between a draft on your desk and a letter that’s been mailed.

Imagine an excellent, fast intern working alone on a draft report for a client. They research, write, and review the formatting — they do all of that on their own, without needing approval for every sentence. But there’s one line they never cross on their own: clicking “send” on the email that goes to the client. That’s always the manager’s decision — even if the intern is sure it’s ready.

The coding agent is exactly this intern. It can build, test, adjust the design (modules 5.1 through 5.6), and even run the publishing command on its own if you let it — it has the technical ability. The question in this module isn't "can it publish on its own?" (it can). It's "should it?" And the answer, by default, is no — until you explicitly say yes.

New here? O CLAUDE.md is a plain text file that you keep inside your project folder (covered in depth in module 0.4) with standing instructions for the agent — it reads this file automatically every time it opens the project. It's the right place to record a rule that must always apply, in every session, even with a new agent or after several months.

This module’s golden rule is short and should be written word for word near the top of that file: The agent never publishes or deploys on its own — only when a human gives an explicit order for that specific publication. “It published before, so it can do it again” doesn’t count. Each publication is a new decision.

Caption: the agent has full freedom to build and test locally (green on the left) — but before anything crosses the yellow gate with a lock toward `git push`, it needs your explicit instruction. After the push, the external tool (dashed yellow on the right) publishes on its own — automatically and outside your direct control.

New here? One repository (or “repo”) is a project folder stored with a complete version history, usually hosted on a service like GitHub. Commit is the command that records a "snapshot" of the changes you made, with a message explaining what changed. Push it’s the command that sends those saved commits from your computer to the cloud repository.

Here’s the point that confuses many people who are just starting out: in most projects in this course, “publish” isn’t a special publishing button. It’s just this: commit + push to the repository. An external tool — Vercel, GitHub Pages, and others like them — keeps an eye on that repository and, as soon as it detects a new change, publishes it automatically, without any further action from you.

This divides the work into two clearly separated parts: the part you (or the agent, following your instructions) control directly—building, testing, and sending the push — and the automated part, which runs on its own afterward and is outside your direct control. There’s no point checking the tool’s dashboard every minute: once the push is out, the rest happens between the repository and the publishing tool.

Not every rule written in CLAUDE.md truly protects you. Some seem safe but leave a gap; others are explicit enough to keep the agent on track even on a day when it “is sure” everything is ready. Compare:

Three steps to make this work in your project: write the rule, test it on localhost before publishing anything, and only then authorize the push with an explicit phrase. Let’s get straight to what to paste.

## Publishing rules

- **Never publish/deploy without an explicit instruction.** This includes `git push`,
  any manual deploy command, or reactivating a stuck deploy.
- Building and testing at `<your localhost address>` are allowed — they don't
  need approval at every step.
- Publish only after I say something like "you can publish" or "put it online"
  — explicit wording that refers to THIS specific change.
- If publishing fails after the push, let me know. Don't try to fix it
  by triggering the deploy again on your own.

git add <arquivos que mudaram, ou . se for tudo>
git commit -m "<mensagem curta explicando o que mudou>"
git push

Since module 5.1, this track has repeated a figure: the agent quickly delivers about 60% of any interface—generic, functional, but without soul—and the final 40% (the brand, the polish, the fine-tuning) depend on you bringing in references, taste, and review. This module shows that the same principle applies to publishing: the final 40% aren't just about looks; they're about governance — when e if anything going live is always your decision, never delegated by default.

This isn't bureaucracy or a lack of trust in the agent. It's the same discipline any serious team applies to any new person: complete freedom to produce, with a final approval that is never automatic. Separating "I built and tested it locally" from "I authorized publishing" in two different sentences is what ensures that an error in one step never becomes a live problem without anyone reviewing it.