Compiled workflows

For the declarative launch path, Automations are the customer-facing object. Routes and Policies live inside Automations. A workflow is the compiled execution graph Viewport creates after a route matches a git-backed policy.

Most customers should start with Automations, routes, and policies, not this page.

A compiled workflow is the operating procedure for one kind of agent work. It answers:

1. What starts it?
2. Which repos and files are in scope?
3. Which context can it use or update?
4. Who approves plans, implementations, and side effects?
5. Which provider actions may happen?
6. Which runner should execute it?

The app stores an immutable workflow version for execution and audit. In the declarative path, that version is generated from .viewport/policy.yaml and .viewport/routes/*.yaml; hand-authored graphs are an advanced escape hatch.

Launch Workflow Shape

For early partners, keep the first workflow small:

Slack or GitHub trigger
  -> route to team policy
  -> composed workflow
  -> resolve scoped context
  -> PM plan gate
  -> engineering gate
  -> self-hosted worker execution
  -> GitHub PR/proposal
  -> Slack completion receipt
  -> audit packet

This proves the workflow boundary without introducing production blast radius.

Runners

The launch path uses a self-hosted polling worker:

vpd pair PAIRING_CODE --worker --transport=polling --workdir "$HOME/.viewport/worktrees"
vpd worker doctor --json
vpd worker start --mode persistent --transport polling

The worker executes locally and syncs evidence back to the paired server. It does not decide that it is allowed to work. The server issues the claim, lease, and grants.

Approvals

Use explicit gates:

• PM or reviewer approves the plan;
• engineer approves implementation or PR proposal;
• provider side effects execute only after the configured approval state.

Requesting changes should return the run to the appropriate agent/revision step. A side effect should not execute while the run is blocked or awaiting revision.

Provider Actions

Provider actions are things like:

• open a GitHub pull request;
• post a Slack completion message;
• create a context update proposal;
• comment on a ticket.

Prefer brokered provider actions over raw shell commands that hide side effects. The run detail should show what happened, who approved it, and the provider object URL or proposal receipt.

Usage And Receipts

Every meaningful step should leave evidence:

• trigger and route;
• worker claim and cleanup;
• context resolution;
• approval decision;
• agent output;
• shell/test result;
• provider side effect;
• usage metadata when reported.

Fixture proof can validate the substrate. Live launch proof still needs a real or operator-verified Slack/GitHub path.