Add a New Venue Adapter¶

Controlled process for adding a publication destination without breaking the publish loop.

When to add a new adapter¶

A target audience needs a venue currently not supported (e.g., mastodon, internal-confluence, static-site-deploy).
An existing manual publishing flow has matured into a repeatable shape.

Adapter design proposal.
Adapter name and version.
supported_content_types it will accept.
Auth method and credential label (per credential-lifecycle-policy.yaml).
Rate limits and retry policy from venue's documented constraints.
Capabilities (dry_run, publish, unpublish, etc.).
Audit events emitted.
Schema-conformance check.
Adapter declaration validates against venue-adapter.schema.json.
Auth and secret handling.
Provision an agent-scoped credential per agent-credential-provisioning.md.
Verify least-privilege scope (SPB-04).
Verify the credential cannot be read by other adapters.
Confirm rotation cadence in credential-lifecycle-policy.yaml.
Sandbox publish validation.
Use a non-production target on the venue (sandbox account, draft workspace, hidden post).
Run publish-loop.md end-to-end with data_classification: low_sensitive test content.
Verify dry-run, publish, post-publish confirmation, unpublish (if supported).
Policy updates.
Add the new venue category (if any) to publishing-policy.yaml approvals_required.
Add classification routing rules in policy if the venue is public.
Audit conformance.
Adapter emits all required events per publish-audit-log-spec.md.
Document and announce.
Add the adapter to README.md "Files" table (if hosted here) or to a registry of adapters.
Add a row to the history below.

If the venue does not support unpublish, document the gap and require pre-publish approval criteria stricter than for unpublish-capable venues.
Maintain a published-artifact registry that supports manual takedown coordination.

Date	Adapter	Status