Posts a native browser notification when a run reaches a terminal state (done / failed / killed) — including while this tab is in the background. Clicking a notification focuses this tab and opens the run. Client-side preference, stored in this browser only. Your browser must also grant notification permission for this site: switching the toggle ON or pressing ▶ is the gesture that lets it ask.

Shows the meter buttons (fleet header + project filter) that open mission control — per-project flow + analytics (#/factory/<project>). Client-side preference, stored in this browser only; off by default.

Lifts the muted text ramp and panel lines well past WCAG AA contrast for this browser. Client-side preference, stored in this browser only; off by default (the base palette already targets AA at the UI's small mono sizes).

The factory runs in anchored shifts — the plaque, ticker, gate and docket all window on the current shift, with vs-prev-shift deltas. DAY STARTS is when the day's first shift begins, in UTC. Server-wide setting; the shift COUNT never resets (numbered since this factory was commissioned), even when the pattern changes.

Pulls the latest commit (git pull --ff-only) and runs the deploy script. Locally modified files (e.g. edited config) are stashed for the pull and re-applied after. If the script fails, the checkout rolls back to the previous commit and the script re-runs there.

Deploy a feature branch to try it on this host: local changes are stashed, the SQLite database is backed up first (a branch may carry a different schema — the backup is the restore point), then the branch is fetched, checked out, pulled and deployed. On failure the host switches back and rolls back automatically. To swap back afterwards, deploy your main branch the same way.

Connect a GitHub App installation so runs clone repos and open PRs with per-run installation tokens — no PAT needed. ADD GITHUB opens GitHub's install page; pick an account and repos there, and GitHub sends you straight back here with the installation recorded below.

Global key/value secrets, exported as environment variables inside every run's sandbox (firecracker: they ride the read-only config drive and are exported after untrusted repo setup — the agent and its tools see them, setup never does). Values are write-only: the list shows names, never values. Runs launched after a change pick it up; a running VM keeps the secrets it launched with. Names must be env-var syntax (NPM_TOKEN, AWS_SECRET_ACCESS_KEY, …); pi-cloud's own variables (PI_*, model keys, PATH, …) are reserved.

Org-curated skills (SKILL.md packages) and plugins (pi extensions), installed into every run of the org — the guest seeds pi's global config (~/.pi/agent/skills|extensions) before the agent starts, on every backend, with no image rebuild. Test a skill on one project first (its page carries a project-tier copy), then PROMOTE it here. Runs are fixed at dispatch: a running VM keeps the skills it launched with, and an agent can never install a skill mid-run.

Markdown instruction files shared by SPEC, BUILD, PROVE, SHIP and WATCH. Add a file, folder or zip once, then reference it from a stage prompt with {{skill:name}}. These are delivered to the workdir, not installed as Pi plugins.

Stage skills are cross-tool Markdown instructions. Reference a library item with {{skill:name}}; the worker verifies every reference before an agent starts. Prompts replace the built-in default at this level.

Each project's own skills (only that repo's runs receive them — members experiment here without blessing the org). PROMOTE copies one into the org tier above (admin+); the project original survives for further iteration.

Your private LiteLLM source. Save a base URL and API key and pi-cloud discovers the models your credential can reach — they appear in the model picker as litellm/private/<model>, dispatchable with no static profile. The key is write-only: only a masked value ending in its final four characters is ever shown. Your source is visible to nobody else; an operator-configured shared source (if any) merges with yours, and yours wins conflicts.

This organization's model profiles. A run dispatched with a profile's name uses its spec + API key — the org's own credential, never the host's. Keys are write-only: the list shows names and specs, never keys.

Members and roles. A member's name is the join key for GitHub sign-in; the GH pin is the numeric GitHub account id bound on first sign-in (remove + re-add the member to reset it). Roles: owner > admin > member > viewer.

Policy for the Discord bridge (the optional packages/discord sidecar): which guilds it answers in, which channel dispatches to which repo, and who may command it. Saved policy goes live on the running bridge within a minute — no restart. The bot's DISCORD_TOKEN is not managed here: it stays in the bridge's environment (pi-cloud.env), so this server never holds it. Setup guide: packages/discord/README.md.

Reconnects the bridge's Discord gateway in-process (the bridge reports its state back by heartbeat, so the line above shows it landing). Use when the gateway is wedged or offline; policy edits above never need it.

MCP servers let your agents use external tools. pi-cloud holds the credentials — they never enter a sandbox.

Connecting opens the provider's sign-in page in this tab.

A persistent, host-side pi session in the browser (ttyd + tmux — see docs/admin-terminal.md), briefed on the factory's data layout (run evidence, the SQLite registry, host events) for troubleshooting across runs. It is root-equivalent on this host by design: the admin pi's shell runs as the service user, which can read the env file and the secrets store. Access is gated by the terminal's own credential (ttyd basic auth — the browser prompts for it), not by this page's bearer token.