Launch checklist
The acceptance bar for a team before treating Viewport as ready for daily governed agent work.
Use this checklist after the first setup run. It is intentionally concrete: if a box is not true, keep the rollout gated to the setup owner and fix the gap before inviting the rest of the team.
For the first human proof, fill out Cold-path acceptance while the operator runs the setup from a clean browser session.
Team Scope
- One workspace and one team are selected for the first rollout.
- At least two humans can approve a gate for that team.
- Reviewer tags used in
.viewport/policy.yamlmatch real team members. - The first repository is a sandbox or low-risk team repo.
- Production deploys, direct merges, and broad organization-wide repository access are not part of the first proof.
Integrations
- GitHub App is installed only on the repositories the workflow may touch.
- Slack is connected for completion receipts.
- Slack source-thread completion has been verified for any Slack route used in the first launch.
- Linear, Jira, Notion, Confluence, and managed runners are not required for the first launch unless your workspace has a separate live proof for that provider.
- Provider failure copy is understandable to the operator without reading server logs.
Worker
vpd pair --worker --transport=polling --workdir "$HOME/.viewport/worktrees"completed for the selected workspace.vpd worker doctor --jsonshows the expected server, workspace, transport, workdir, and capabilities.- Exactly one persistent worker is running for the server/workspace/executor.
- The team knows who owns the worker process and how it restarts after host reboot or upgrade.
- If you need a proof-only run, use a one-shot worker instead of starting a second persistent worker.
- The worker machine has only the local model/tool credentials it needs.
GitOps Config
.viewport/policy.yamland.viewport/routes/*.yamlare committed and pushed.vpd check .passes.vpd check .does not warn that.viewport/is gitignored.- The sync source shows a current SHA and no repeated HMAC failures.
- The composed workflow has a plan gate before implementation and bounded branch
publishing to
agent/**or an equivalent non-protected branch pattern.
First Run
A launch-quality first run shows:
- route match from the provider event;
- policy source path, ref, SHA, and policy hash;
- self-hosted worker claim;
- brokered checkout;
- plan-only node before approval;
- human approval with approver and timestamp;
- implementation node after approval;
- usage and cost when the adapter reports them;
- bounded branch publish;
- GitHub PR receipt with provider URL;
- Slack completion receipt with provider URL;
- source-thread Slack reply when the run started from Slack;
- cleanup receipt;
- no raw tokens, lease tokens, or large provider bodies in stored metadata.
Support Handoff
Before inviting more users, verify the setup owner can collect:
vpd worker doctor --json > /tmp/vpd-worker-doctor.json
vpd status --json > /tmp/vpd-status.json
vpd check . --json > /tmp/vpd-check.jsonThe support packet should include sanitized ids and screenshots from run detail. It should not include raw provider tokens, pairing codes, bootstrap tokens, lease tokens, worker private keys, or model API keys.
For suspected wrong-route execution, wrong provider writes, exposed credentials, or repeated side effects, use Incident response for early partners before restarting the worker.
Ready For Team Use
Treat the team as ready only when:
- the setup owner can repeat the first run from a clean browser session;
- another team member can approve the gate;
- run detail explains the route, policy, worker, approvals, side effects, and receipts without raw logs;
- a failed provider action shows a clear next check;
- the team knows who owns the worker process and how to restart it.
Where To Go Next
- Operate vpd workers
- Read run detail
- Early-partner security review
- Runner won't claim work
- Support packet
Not Yet Covered
These are intentionally outside the first launch checklist:
- billing automation;
- Viewport-managed ephemeral runners;
- broad enterprise retention/export policy;
- tamper-evident audit claims;
- blanket source-thread Slack guarantees for routes your workspace has not tested. Verify each new Slack route before treating it as launch-ready.