# v0.2.0 Release Plan

Status: shipped as part of the consolidated `v0.4.0` release on 2026-07-21. npm, the official MCP Registry, Ghost 5/6 integration, and clean-install setup verification passed.

## Scope

v0.2.0 releases the published-post SEO workflow and closes the unsafe or contradictory behavior discovered after v0.1.1. It does not add broad Ghost Admin CRUD.

## Runtime contracts

### Deployment

- A completely successful `publish_posts` or `unpublish_posts` batch calls the configured hook exactly once.
- A preflight or write failure skips deployment.
- A deployment failure does not erase successful post-transition results.
- `update_published_post` never deploys. Its approved workflow calls `trigger_deploy` separately.
- Deploy requests are never retried automatically because a timeout does not prove the remote build was not accepted.
- HTTP 2xx returns `{accepted: true, host, status}`.
- HTTP non-2xx returns `{accepted: false, host, status, error}`.
- Network or timeout failure returns `{accepted: false, host, status: 0, error}`.
- The MCP result sets `isError: true` for an unsuccessful deploy while preserving valid `structuredContent`.
- Only the hook host is exposed by `check_connection`; path, query, credentials, and secrets stay hidden.

### Caller-attested destructive confirmation

The MCP schemas for `update_published_post`, `publish_posts`, `unpublish_posts`, and `trigger_deploy` require top-level `user_confirmed: true`. Missing, false, string, or free-form values fail validation before Ghost or HTTP access. This is caller attestation, not cryptographic proof that a person saw an approval screen.

Publishing approval must name the exact post IDs and timestamps, the status transition, and the configured deployment host because one deployment is included. Published-metadata approval must name both the exact patch and the one separate deployment when both actions are intended.

### Read-only mode

`GHOST_READ_ONLY` defaults to `false` and accepts only the exact strings `true` or `false`. Invalid non-empty values stop startup. When enabled, the server registers only:

1. `check_connection`
2. `list_posts`
3. `get_post`
4. `list_tags`
5. `check_live_posts`

Normal mode registers all twelve v0.2 tools. `check_connection` returns `read_only` and the optional deployment host.

### Draft body replacement

Metadata-only `update_draft` calls remain compatible. Any input containing `markdown` is a complete HTML-to-Lexical body replacement and requires top-level `body_replacement_confirmed: true`. Both the MCP schema and `GhostPublisher.updateDraft` enforce it. Raw HTML and Lexical input remain unsupported.

## Migration from 0.1.x

- Add `user_confirmed: true` only after approval to the four destructive calls.
- Do not call `trigger_deploy` after `publish_posts` or `unpublish_posts`; those tools already deploy once after complete success.
- Add `body_replacement_confirmed: true` to intentional Markdown draft replacements.
- Set `GHOST_READ_ONLY=true` for audit-only installations; invalid spellings now stop startup.
- Handle deployment failures as MCP errors with usable structured output rather than assuming any structured result means success.

## Verification matrix

- Destructive schemas reject missing, false, and string confirmation without side effects.
- All four destructive schemas accept literal true.
- Read-only and normal servers advertise exactly five and twelve tools.
- Invalid read-only values fail configuration loading.
- Draft Markdown replacement fails without acknowledgement; metadata-only updates do not.
- Successful, non-2xx, network, and timeout deployment paths each issue one request at most.
- Automatic deployment failure preserves exact successful transitions and sets MCP `isError`.
- Errors, hook paths, and hook queries reveal no configured secret.
- README examples include only the one automatic deployment after publish/unpublish.

## Release checklist

1. Run `npm run check`.
2. Run `npm audit --audit-level=high`.
3. Run `npm pack --dry-run` and inspect package contents.
4. Require branch CI on Node 22 and 24.
5. Run disposable Ghost 5 and Ghost 6 integration jobs for the release commit.
6. Run the SEO workflow proposal-only against an authorized test site, with no Ghost write.
7. Obtain separate exact approval for one low-risk metadata patch and one deployment. Save a revision, prove the body is unchanged, deploy once, and verify rendered metadata.
8. Tag `v0.2.0` only after the preceding gates pass.
9. Require the tag workflow to publish and verify npm plus Registry `0.2.0`.
10. Install the published package in a clean MCP client and repeat connection plus draft smoke tests.

No npm token or separate manual Registry workflow is part of this path. npm uses trusted publishing with provenance; Registry publication uses GitHub OIDC and checksum-pinned `mcp-publisher` v1.7.9. Build, audit, test, and packaging run in a job without OIDC permission. Only the publication job can request an identity token, and every third-party release action is pinned to an immutable commit SHA.

## Published-release correction policy

- If a published package is unusable, deprecate that exact npm version, move the npm `latest` tag to the last known-good release, and publish the correction as the next free patch version.
- npm and Registry versions are immutable. Never overwrite a published version; publish the next free patch version to both registries.
- Never reverse live Ghost content automatically. Use the saved Ghost revision or submit an exact reverse metadata patch for separate approval.
- A failed deployment does not justify replaying a successful content transition. Inspect the remote deployment provider before a separately approved manual trigger.