QA Commander: the default agent persona, its desktop and the human handoff

Status, in two halves.

• Server provisioning: OFF. The platform setting qaCommander.autoProvisionNewOrgs ships false, so POST /v1/orgs behaves as before. When on, every NEW org gets a persona "QA Commander" (@qa-commander) inside its own create transaction, on an UNISSUED key (role cap member, scopes read/write; no plaintext token exists until the activation controller issues one). Existing orgs are provisioned by an operator script. No route, MCP tool, permission or OpenAPI path is added.
• Runtime, desktop and handoff: not live yet. The activation controller, the per-org isolated instance (gVisor runsc), the per-org desktop with a browser and the live-view handoff are client tooling that is not released. Nothing runs unless the bridge config sets commander.enabled (and commander.desktop.enabled for the desktop).

Never tell a person QA Commander will answer them while the runtime is not live: until then the persona exists but nothing replies.

How a conversation with it works (design)

1. A person DMs or @mentions @qa-commander. The event bridge acknowledges at once ("this first reply takes longer, I am being activated") and starts ONE isolated instance for that org.
2. On every start the controller writes a size-capped restore packet from GoodQA: DM history, the coordinator bootstrap, agent knowledge, and the person's open follow-ups.
3. Each turn may drive a desktop (qacd-<orgId>: Chromium, noVNC) through one MCP server inside that container (Playwright MCP plus screenshot, click, type, needs_human, fill_login).
4. Handoff: needs_human({reason, url, instructions, timeout}) pauses the worker, DMs the person a one-time, org-bound live-view link (Done / Skip / Take control / Hand back), files a blocked-needs-user follow-up ticket and returns signed_in | done | skipped. fill_login({alias, origin}) fills a vault login into that exact origin and returns field names only; the model never sees the secret.
5. Three days with no human reply: ASLEEP (instance stopped, volume kept, nothing proactive until a person writes).

Limits: global admission control, per-org turns per hour, a daily cost ceiling, per-org and global kill switches, and a per-org audit log. Each instance holds only its org's persona key.

The goodqa CLI inside the instance (not released yet)

When the instance image is built with it, /usr/local/bin/goodqa is in every instance (guide). It finds the instance identity on its own (the commander's persona key and the organization from the instance environment), so in the box:

• goodqa secrets list and goodqa run --mask --secrets NAME -- <command> run a command with the vault secrets the organization listed for QA Commander in its environment (organization switch vaultEnv.enabled, off by default); no value is printed, logged or sent to the model. The commander's instructions tell it to use exactly this and never to read a value.
• goodqa data ... reaches the organization's custom data with the data role bound to QA Commander.
• goodqa opens the terminal chat. Because the box speaks as QA Commander, a person at the instance's terminal types /login to talk to it as themselves; that sign-in is held in memory for the session, never written to the instance's disk, which the agent shares.
• When a person chats from their own terminal, QA Commander can ask to run a command there (a goodqa-run block in its reply); the person approves it, the values stay on their machine, and the masked result comes back as untrusted data.

Reference

• API reference: QA Commander adds none; it uses the persona routes (/persona/...), the coordinator bootstrap and agent knowledge in /v1/openapi.json (tags messaging, agent-memory).
• MCP tools: the desktop's own tools run inside its container (not GoodQA's MCP server); GoodQA-side work uses the MCP tool reference.