Cold-path acceptance
The pass/fail worksheet for proving a new team can complete the first governed run without engineer intervention.
Use this worksheet when validating a fresh early-partner workspace. It is the acceptance record for the setup owner, not a broad enterprise security review.
A pass means one operator can complete the hosted setup, pair a self-hosted worker, trigger a governed run, approve it, and explain the receipts from run detail without private help from an engineer.
Scope
Run this against:
- one hosted Viewport workspace;
- one team;
- one sandbox or low-risk GitHub repository;
- one controlled Slack channel;
- one self-hosted persistent polling worker;
- one committed
.viewport/policy and route set.
Do not include production repositories, broad provider scopes, managed runners, billing, Linear/Jira/Notion, or enterprise retention/export claims in this acceptance pass.
Before Starting
Record these non-secret identifiers:
| Field | Value |
|---|---|
| Workspace name/id | |
| Team name/id | |
| GitHub repository | |
| Slack channel id | |
| Worker machine label | |
| Setup owner | |
| Date/time |
Never paste raw pairing codes, worker private keys, claim tokens, lease tokens, provider tokens, cookies, or model keys into this worksheet.
Acceptance Steps
| Step | Pass condition | Evidence to capture |
|---|---|---|
| 1. Sign up | Operator creates or opens the hosted workspace from a clean browser session. | Screenshot of workspace/team landing state. |
| 2. Team setup | Team has at least one reviewer tag used by policy and at least one matching reviewer. | Team settings screenshot or reviewer tag name. |
| 3. GitHub connect | Viewport GitHub App is installed on exactly the sandbox repo needed for the proof. | Installation/repo list screenshot. |
| 4. Slack connect | Slack workspace is connected and the proof channel is selected or known. | Integration state and channel id. |
| 5. Pair worker | App-generated command pairs the worker with --worker --transport=polling --workdir "$HOME/.viewport/worktrees". | Pair command shape, with code redacted. |
| 6. Doctor | vpd worker doctor --json shows expected vpdProfile, server, workspace, workdir, transport, capabilities, and processLock.active=false before start. | Sanitized doctor output. |
7. Commit .viewport/ | .viewport/policy.yaml and .viewport/routes/*.yaml are committed and pushed. | Commit SHA and file paths. |
| 8. Check config | vpd check . passes and does not report .viewport/ as ignored. | Sanitized command output. |
| 9. Sync source | App shows the GitOps source as synced with current SHA, route count, and composed workflow. | Sync source screenshot. |
| 10. Start worker | vpd worker start --mode persistent --transport polling runs without duplicate-worker or profile errors. | Terminal line or worker status screenshot. |
| 11. Trigger run | Slack or GitHub event creates exactly one governed run for the expected route. | Provider event id and run id. |
| 12. Plan gate | Run pauses before implementation and shows a plan/review gate with reviewer and policy provenance. | Run detail screenshot. |
| 13. Approve | Authorized reviewer approves or requests changes, and the run resumes as expected. | Gate decision receipt. |
| 14. Implementation | Worker executes the bounded implementation/test path after approval. | Node status and usage/cost when reported. |
| 15. GitHub receipt | Run creates a bounded branch and PR, or a provider proposal if PR creation is intentionally disabled. | PR URL or proposal receipt. |
| 16. Slack receipt | Completion message appears in Slack; Slack-originated runs reply in the source thread. | Slack permalink and thread screenshot. |
| 17. Cleanup | Run detail shows cleanup/lease completion and vpd worker doctor --json shows no active orphaned worker lock (processLock.active=false, or stale=true only before running vpd worker stop). | Cleanup receipt and sanitized doctor output. |
| 18. Explainability | A teammate can read run detail and explain route, policy, worker, approval, side effects, and receipts without raw logs. | Teammate name and brief notes. |
Fail Fast
Stop the pass and fix before inviting more users if any of these happen:
- policy sync accepts a reviewer tag with no matching human;
- the worker claims work for the wrong workspace, team, repo, or route;
- implementation starts before the plan/review gate is approved;
- a provider action happens after rejection or cancellation;
- Slack renders literal
\nor source-thread delivery fails for a live Slack-originated route; - GitHub App token or provider credential material appears in UI, logs, proof, or support packet;
- run detail cannot show route, policy, approval, PR/Slack receipt, usage, and cleanup without inspecting raw server logs.
Pass Record
Use this short result line in your launch tracker:
Cold-path pass: WORKSPACE / TEAM / RUN_ID / PR_URL / SLACK_PERMALINK / WORKER_LABEL / DATEIf any proof is fixture-only, mark it fixture-only. Fixture proof does not close the cold-path gate.