Branches and publishing

Nothing is published by default

While you iterate ("make it bluer", "the title is wrong"), the agent edits files on your worker and you check the preview. Those edits live on the worker only. They are not on GitHub. That is the normal, correct state.

The agent is blocked from publishing until you clearly ask. "Done" and "looks good" do not count.

When you want it on GitHub

Say one of:

• Push the changes
• Commit and open a PR
• Publish / Ship it
• Get this ready for review

The agent then:

1. Unlocks publishing for about 30 minutes
2. Creates a branch in each product repo it changed — a separate copy of the code with only your change on it
3. Pushes that branch to GitHub. Never the main line.
4. Opens a pull request (PR) if you asked for one — the page where a colleague reviews the change

A typical branch name looks like this:

bugfix/hero-button-PM-1234

PM-1234 is the Tickets number when the work belongs to a ticket. That is how the team traces the PR back to the task. Test-suite-only work uses autotests/… instead of bugfix/….

The simple picture

• main — the live product line. The agent never pushes here.
• bugfix/hero-button-PM-1234 — a side copy with only your change, waiting for someone to review and merge it into main.

GoPublic is four product repos, not one:

One chat can touch more than one repo, so you may get more than one PR. That is normal. Review all of them.

Two habits that keep this clean:

• Do not start a second unrelated job on the same worker while the first is unpublished. The files will mix.
• If a PR already exists for a ticket, the agent keeps using it instead of opening a second one.

Merge is a second decision

Publishing a PR is not merging it. Green checks, an approval, or "looks ready" are not a merge either.

Merge only happens when someone says merge it — in the chat, or with the Merge button on the Tickets task. After merge, the normal deploy takes the change to clients.

"Review this hard"

For changes that matter, say "review this hard". The agent brings the branch up to date with the newest main line, runs independent code reviews on every changed repo, fixes what they find, runs the full test suite, and only then asks a human for the final review. It still never merges.

Test sites for Worker tickets

When a bugfix worker fixes a Worker-labelled ticket, it also stands up a temporary site running the fix:

https://eph-<branch-name>.agent.gopublic.dk

It is a real Staging site with template content, so a reviewer can see the fix without a worker. It disappears when the PR is merged, or after 7 days.

Cursor's own branch picker

When you start an agent, Cursor may show a repo and a branch for beru-org/Agent. That is the orchestration repo, not the product. The real edits happen in Backoffice, Frontend, Headless and Assets.

• Ignore the idea that "the agent works on the Agent repo".
• The branches that matter are the bugfix/… branches the agent names in the chat when you publish.
• If the agent only ever talks about beru-org/Agent and never names a product repo, something is off. Tell it to work in the product repos.

Reset vs branches

Reset to default cleans the preview content. It does not close PRs and it does not delete unpublished code.

To throw away unpublished code on the worker, say so in those words: "Discard the local code changes."

Branches already pushed stay on GitHub until a human closes or merges them.