Read run detail

Run detail is the launch source of truth. Slack messages and GitHub PRs are external receipts, but the run detail explains how the work was admitted, routed, approved, executed, and reported.

Use this page after the first run and any time a teammate asks, "what actually happened?"

The Short Version

A healthy first run should answer seven questions:

If one of those questions has no answer, keep the rollout gated until you know whether the missing evidence is a UI gap, provider failure, worker sync issue, or policy problem.

1. Trigger And Route

Start at the top of the run:

• provider source: Slack, GitHub, webhook, or fixture;
• source id or event id;
• matched route name;
• route file path and Git SHA;
• team/workspace that owns the route.

If the run started from Slack, the source timestamp should be present for threaded completion. If the timestamp is missing, Slack completion may fall back to the configured channel. That is not the same as source-thread proof.

2. Policy And Workflow Version

The run should show the policy contract that was actually used:

• .viewport/policy.yaml path;
• repository, ref, and commit SHA;
• policy hash or composed workflow version;
• plan-review gate before implementation;
• branch/path boundaries.

Do not debug from a local working tree alone. The server uses synced Git state, not unsynced local edits.

3. Worker And Workspace

The worker section should show:

• the paired worker or executor;
• persistent polling or the transport used;
• claim/lease state;
• checkout or context materialization receipt;
• cleanup state after completion.

If the worker never claimed, open Runner won't claim work and compare the denial code with vpd worker doctor --json.

4. Plan Gate

For the first rollout, implementation should not start before the human gate is approved.

The gate should show:

• plan text;
• reviewer tag or reviewer context;
• decision: approved, rejected, or changes requested;
• approver identity;
• timestamp;
• optional decision message.

If changes were requested, the implementation node should remain queued until a revised plan is approved. See Approval or plan revision is stuck if it loops or appears to proceed too early.

5. Implementation And Tests

After approval, inspect the implementation node:

• prompt or task summary;
• exit status;
• changed file summary when available;
• shell/test command receipt when tests ran;
• failure copy if the node failed.

For launch, shell/test execution should be explicit and bounded by policy. Do not treat broad local shell capability as a provider side-effect approval.

6. Provider Side Effects

Provider receipts should be concrete:

If a PR or Slack message is missing, use Provider receipts are missing.

7. Usage, Cost, And Cleanup

Usage is present when the adapter reports it. Treat missing usage as an adapter or provider limitation unless the run expected a provider with known usage support.

Check for:

• input/output token counts when available;
• model/provider name;
• reported or estimated cost;
• run duration;
• cleanup receipt.

For the current launch path, customer-local/BYOK model usage is the default. Daemon-reported USD is operational evidence, not a hosted billing source.

Red Flags

Stop and investigate if run detail shows:

• implementation started before the plan gate was approved;
• reviewer tag resolved to nobody;
• provider write happened without an approval or allowed policy;
• worker workspace/team does not match the route owner;
• source-thread Slack route posted only to a fallback channel and nobody noticed;
• raw tokens, pairing codes, lease tokens, or model keys in metadata;
• GitHub PR targets a protected branch directly;
• cleanup receipt is missing after a completed run.

When It Is Ready

The first team can broaden usage when:

1. the setup owner can explain the run from trigger through cleanup;
2. another team member can approve the gate;
3. the GitHub and Slack receipts point to real external objects;
4. failures show a next check without reading server logs;
5. the support packet can be collected without secrets.

Related Pages

• Launch checklist
• Audit log
• Provider integrations
• Support packet