Servicing requests

The Request loop is the status path. This page is who does the work. A human files, reviews, and can Ship to live. A worker can pick up, build, and attach proof. Neither side skips the other.

One board

Do not open a second tracker. The dashboard list is the board. The worker door reads the same Requests. If you need the status words, see The Request loop.

What a person does

Owner and admin

• File the Request. Write what should be true, not a patch file.
• Answer when status is Needs a reply.
• Open preview, follow How to check, then Looks good or Submit changes.

Developer

• Triage by hand when a worker is not connected.
• Attach delivery and a preview, or review what the worker attached.
• Ask to Ship to live after accept. That records promote. It does not merge.

What a worker does

1. First act on a new Request writes picked up.
2. Build on the connected site, outside xTerminal.
3. Attach a preview link and a complete delivery note, then move to Review.
4. After someone asks to Ship to live, mark shipped. Not before.

When to pick it up yourself

If no worker is connected, the developer services the Request in the dashboard. Same delivery rules. Same review card. The loop does not change because a person typed instead of a key.

Do not skip review

Looks good is a person. Ship to live is a person who is allowed. Live is only after promote was requested. That is the product, not a training mode.

Where this sits in Settings

Settings, Requests turns the board on and holds the site repository. Admin or developer also mint worker keys there. The handbook for those keys is Gateway, APIs, and MCP.