Docs

Control panel vs developer lane

Owners run the site from the dashboard. Developers hold the repo. The client never sees GitHub.

Two lanes share one site. Mix them up and the owner ends up in tools they should never need. Keep the dashboard as the control panel. Keep GitHub, the host, and merge in the developer lane.

The control panel

The dashboard is the owner surface. Status is the board, not a pull request list. Preview links and delivery notes live here so the owner can accept work without opening a repository.

  • Content you turned on, edited in place.
  • Inbox for form leads, and Pipeline when that tool is on.
  • Requests: compose, thread, review card, Ship to live for the people who are allowed.
  • Team, billing, and profile in Settings.

The developer lane

The developer connects the site, mints worker keys, and reviews code in their own GitHub. xTerminal may store the linked repo as context so a worker can ship. xTerminal does not merge. GitHub and the host stay on the agent side.

  • Environment values and the live deploy.
  • Worker keys and an optional wake webhook, under Settings, Requests.
  • Site repository, written as org/repo, as context only.
  • Code review and merge in GitHub, not in this dashboard.

GitHub stays off the owner screen

The client never sees GitHub. Owner-shaped Requests hide repo, branch, and internal notes. If an owner needs a change, they file a Request or edit content. They do not get a repository login from xTerminal.

Who clicks what

  • Owner: Edit, Inbox, Looks good, Needs changes, billing, Team invites, transfer.
  • Admin: the same ops as owner except transfer, plus worker keys and Ship to live.
  • Developer: connect the site, mint keys, attach delivery, Ship to live. No billing or Team invites.

Why the split exists

Other tools hand the owner a generated site and a steering wheel. xTerminal keeps a developer between the owner and the code, and makes the job easier with a worker that still comes back for review. The review is the product.