SUPPORT
Bring the evidence, not the secrets.
Most PostSteward failures already return a bounded code, request/reference ID, durable receipt or runtime status. Those are the safest starting points for support.
Before reporting a problem
- Refresh the workspace or inspect runtime status.
- For publication uncertainty, inspect the existing receipt and provider post before attempting any retry.
- For an agent integration problem, inspect help.json, the operation reference and the returned error code.
- For sign-in/OAuth failure, retain the PostSteward reference ID shown on the browser error page.
What to include
- The environment and approximate time.
- The bounded error code/reference ID.
- The operation name and whether the call used HTTP, remote MCP or the owner browser.
- A receipt/delivery ID when reporting publication evidence.
- What you expected versus what the PostSteward evidence currently says.
Do not publish secrets in support.
Never include social access/refresh tokens, agent bearer tokens, Stripe/payment credentials, GitHub credentials, session cookies or private repository contents in a public issue or screenshot.
Where to report
GitHub issuesUse for non-sensitive product defects, documentation problems and reproducible feature bugs.Security guidanceReview the safe disclosure guidance before reporting a security-sensitive problem.DocumentationHuman guide plus generated machine contracts for owners and agent builders.Runtime statusRead the deployed release, provider application state and reviewed external gates.
Consequential incidents
If a provider effect is ambiguous, pause new work if needed and preserve the existing ledger. If recovery is active, follow the owner-only recovery state machine instead of forcing provider operations. If billing is uncertain, inspect the existing billing status before starting another purchase.