POSTSTEWARD DOCUMENTATION

One operation contract. Two audiences.

Owners decide authority and inspect consequences. Agents call a bounded publishing contract. The human docs explain the model; the machine surfaces remain the authoritative integration formats.

RuntimeLoading…

Choose the surface that matches the job.

Agent guideConnect an owner, delegate a token, publish approved copy and inspect evidence safely. Operation referenceSearch the generated operation catalogue by name, tier and required scope. Runtime helpMachine-readable availability and operation discovery for the deployment you are actually using. OpenAPIHTTP schema for clients that prefer a standard API description.

The model is intent → authority → effect → evidence.

PostSteward does not treat an API response as proof that a social post exists. It stores the reviewed intent, resolves an explicit destination, fences duplicate external effects and keeps provider readback separate from reservation state.

Do not retry uncertainty blindly.

If a provider write has an ambiguous outcome, inspect the existing receipt and provider evidence. Reusing a new idempotency key to force another post defeats the safety boundary.

Implementation and live availability are different facts.

The code can implement an OAuth path while a provider application is still unapproved or unconfigured in a deployment. `/readiness.json`, `/help.json` and the returned operation errors describe runtime availability; reviewed release-gate evidence records what has actually been accepted.

PostSteward therefore avoids promising X, LinkedIn, Advanced automation, public signup or browser WebMCP merely because corresponding code exists.

Agents can skip this interface entirely.

The human documentation is additive. Agents may continue to use the raw guide, generated operation Markdown, OpenAPI, `catalog.json`, `help.json`, `llms.txt`, HTTP or remote MCP directly.