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.
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
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.
PostSteward Local beta feedback
Include the release SHA from poststeward status --json, your OS, the installation step and a redacted error code. For a suspected duplicate, preserve the local and cloud effect IDs, generation and payload digest. Pause new work and reconcile the existing receipt before retrying. Keep pairing codes, runtime tokens, private campaign text and raw diagnostic exports out of public issues.