Provider receipts are missing
GitHub PR, Slack completion, or provider receipt did not appear after a run.
Provider side effects are the handoff from a governed run to an external system: opening a GitHub PR, posting a Slack completion, or writing another approved provider action. Treat missing receipts as a chain problem, not only a provider problem.
Start From Run Detail
Open the run and check these sections:
| Section | What should be present |
|---|---|
| Policy / authority | Policy source path, SHA, policy hash, authority digest. |
| Worker / lease | Worker identity, persistent polling transport, lease status, cleanup receipt. |
| Approvals | Human gate decisions before implementation or side effects. |
| Evidence / receipts | Provider action name, status, external id or URL, failure detail. |
| Usage | Token/cost ledger when the adapter reports it. |
If the run is still blocked at a gate, the provider action has not been allowed to execute yet. Decide the gate first.
GitHub PR Did Not Open
Common causes:
- the run never reached the publish or PR action node;
- the GitHub App is not installed on the target repository;
- the policy allows read-only access to the repo;
- the branch policy denied the branch name;
- the PR action was waiting on approval or was rejected;
- the provider grant failed closed.
Check:
vpd check .
vpd worker doctor --jsonThen inspect run detail for the GitHub action receipt. A failed receipt should show the next check, such as repository installation, credential grant, branch policy, or approval state.
Slack Completion Did Not Appear
Common causes:
- Slack is not connected for the workspace/team;
- the policy
invoke.notify.channelpoints at the wrong channel id; - the Slack route did not include a source timestamp, so completion fell back to the configured channel;
- the provider action failed and the run detail has the error receipt;
- the run completed before the Slack integration was connected.
For Slack-originated runs, source-thread completion requires a source Slack timestamp. Fixture or replay runs may intentionally post to the fallback channel. For live Slack routes, verify the run detail shows the Slack event source and thread timestamp.
Slack Shows Literal \n
This is a renderer regression. Capture:
- run id;
- Slack channel id;
- Slack message timestamp;
- whether the run used source-thread completion or fallback channel completion;
- screenshot of the visible message.
Do not try to fix it by editing the policy. The canonical renderer should send real newlines.
Receipt Present But Hard To Trust
A launch-quality receipt should show:
- provider action name;
- external provider id or URL;
- approved actor when the action needed approval;
- credential or integration label, not raw token material;
- request/response summary without large raw bodies;
- timestamp.
If a receipt contains raw tokens, claim tokens, lease tokens, authorization headers, or full provider bodies, treat it as a security bug and capture a sanitized screenshot only.
What To Send Support
Collect:
vpd worker doctor --json > /tmp/vpd-worker-doctor.json
vpd status --json > /tmp/vpd-status.json
vpd check . --json > /tmp/vpd-check.jsonInclude:
- workspace/team name;
- run id;
- provider action name;
- GitHub PR URL or Slack permalink if present and safe to share;
- visible denial code or failure summary;
- whether the event started from Slack, GitHub, or a fixture/replay.
Do not include raw provider tokens, pairing codes, private keys, claim tokens, lease tokens, or credential grant material.