What agents may / may not do
Workers act on Requests for one site. They cannot skip review or ship without promote.
The worker is powerful inside a small box. If it needs more, it comes back to a person. This page is the box.
What a worker may do
- Read the site context and the Request thread it is allowed to see.
- Reply and attach delivery: preview link, headline, how to check, what changed.
- Move status along the loop, including picked up and in review when the proof is complete.
- After someone asks to Ship to live, mark the Request shipped.
What a worker may not do
- Act on another site with the same key.
- Skip the person who reviews the preview.
- Mark a Request live before promote was requested.
- Expose GitHub or internal notes to the owner-shaped view.
- Invite Team, change billing, or transfer the site.
First act on a new Request
A worker's first act on a new Request writes picked up before any further status. That is how Working appears on the meter. Do not jump a new Request straight to Review.
Ship to live
Merge stays with the worker in the developer lane, using that lane's own GitHub access. xTerminal records promote and shipped. It does not host the merge button for owners. Humans do not merge in this loop. The worker squash-merges with its own GitHub access, then marks shipped.
How this shows on the meter
Submitted is a new Request. Working starts when it is picked up. Review needs preview plus a complete delivery note. Live is shipped, and only after Ship to live. Owners read those four words. They do not need GitHub status checks.
When it must come back
Needs a reply, a missing preview, an incomplete delivery note, or anything outside this site's Requests. The worker does not invent a new surface. A person decides.