Everyday tasks

Fix a bug someone reported

1. Paste the report: the Tickets number, the message from support, or your own words. Add the screenshot if there is one.
2. The agent reads the ticket (if there is one), then reproduces the bug on its own preview before changing anything.
3. It tells you one of three things:

• Fixed — here is the preview link, look at it.
• Cannot reproduce — here is what it tried, and what it needs from you.
• Not a bug — the product did what it is meant to do, and here is why.

1. Look at the preview. If it is right, decide whether to publish (see Branches and publishing).

Do not skip step 3. "Fix it" without a reproducible report leads to a plausible-looking change that fixes nothing.

Change a text, a colour, or a layout

On the frontpage, change the hero button text to "Book et møde" and make it the same blue as the header.

The agent edits and hands you the link. Iterate in the same chat: "a bit darker", "also on the English page". None of this is published until you say so.

Set up content on your preview

You can ask the agent to create pages, modules, news items, users — anything you would otherwise click through in the admin:

Create a page called "Testside" under Content with a chat module and a headline "Hej".

It uses the admin API, then opens the page in a browser to confirm it looks right, and gives you both the website link and the admin link.

Pictures and files you upload on your preview stay on your worker. They do not land on the real CDN.

Work on a Tickets ticket

Fix PM-1234.

The agent reads the ticket, reproduces, fixes, and shows you the preview. When you are happy:

Push the changes, open a PR, and post the result on PM-1234.

That puts the branch on GitHub, opens the pull request, and writes a comment on the ticket with the links. Nothing goes to Tickets unless you ask.

Worker tickets — the automatic bug fixers

Some tickets are handled without a human in the chat. When support escalates a bug from Brain, it lands in Tickets with the Worker label. A pool of bugfix workers picks those up on their own.

What a bugfix worker does:

1. Claims the ticket (so two workers never take the same one).
2. Reproduces the bug. Same rule as above: no reproduction, no fix.
3. If it is a real bug: fixes it, pushes a branch, and stands up a test site at https://eph-<branch>.agent.gopublic.dk running the fix. Where it can, it builds a small demo page on that site so you can see the fixed thing in one click.
4. Comments on the ticket: how it reproduced the bug, how it verified the fix, the test-site links, and the pull request.
5. The ticket then shows Accept / Merge / Send buttons for a human to decide.

If the worker gets stuck (cannot reproduce, needs a screenshot, needs a decision), it writes a comment headed Worker handoff (waiting) with what it tried and what it needs, and removes the Worker label. Answer in the ticket, put the Worker label back on, and a worker picks it up again with your answer.

Test sites are removed when the pull request is merged, or after 7 days.

Check something on a real client site

The agent can log in to a Staging or POC client site as "GoPublic Agent" and check or set up content there — for example, filling in pages before a go-live:

Look at the frontpage of dkr on Staging and tell me which modules are on it.

Reading is free. Writing to a site with real visitors needs your explicit yes in the chat, and the agent asks for it. Production sites are not open to the agent yet.

A client's website address in a bug report is not a reason to touch that site. The agent reproduces on its preview, as always.

Ask a question

Not every chat has to change something:

How does the newsletter module decide who gets the mail?

What did we decide about cookie banners for municipalities?

The agent reads the code, checks Brain, and answers. No files change.

Run the tests

After a bigger change, the agent offers to run the automatic tests on your preview. Say yes if you want the extra confidence; it takes a few minutes. Tiny tweaks do not need it.