# Clearon Editorial Pipeline MCP

MCP server for immutable editorial revisions, explicit human approval, and draft-only publishing handoffs.

The server does not write prose and does not claim to detect AI authorship. Its job is to preserve revisions, expose transparent style heuristics, and require explicit human review before export.

## What it does

- Creates append-only editorial projects.
- Preserves immutable revisions with SHA-256 fingerprints.
- Validates and normalizes declared `source_urls` metadata.
- Flags style heuristics without pretending to be an authorship detector.
- Requires explicit editorial, factual, and quotation review confirmations.
- Exports draft-only WordPress payloads for a separate publishing workflow.
- Carries forward the latest matching source-audit gate for article exports.

## What it does not do

- It does not publish.
- It does not make editorial decisions for you.
- It does not verify sources or quotations against external material.
- It does not sanitize raw HTML exports automatically.

## Requirements

- Node.js `20` or newer
- A local MCP client that can launch a stdio server

## Installation

```sh
cd tools/clearon-editorial-pipeline-mcp
npm install
npm test
npm run smoke
```

## MCP client setup

Example stdio configuration:

```json
{
  "mcpServers": {
    "clearon-editorial-pipeline": {
      "command": "node",
      "args": ["/absolute/path/to/clearon-editorial-pipeline-mcp/server.mjs"]
    }
  }
}
```

## Storage

By default, project data is stored outside the repository in a user data directory:

- macOS: `~/Library/Application Support/clearon-editorial-pipeline-mcp/projects`
- Linux: `${XDG_DATA_HOME:-~/.local/share}/clearon-editorial-pipeline-mcp/projects`
- Windows: `%APPDATA%\\clearon-editorial-pipeline-mcp\\projects`

Override that location with `CLEARON_EDITORIAL_ROOT`.

Each project stores:

- `project.json`
- `revisions/*.txt`
- `revisions/*.json`
- `approvals/*.json`
- `handoffs/*.json`

## Recommended workflow

1. Call `create_editorial_project`.
2. Call `audit_revision`.
3. Rewrite the content in your normal editorial environment.
4. Call `propose_revision`.
5. Review the exact proposed text, protected passages, protected blocks, and audit output.
6. Call `apply_revision`.
7. Call `approve_revision` only after human editorial, factual, and quotation review.
8. Call `export_wordpress_payload`.
9. For article projects, make sure the latest source-audit report matches the approved revision. Export requires that report to be `ready_for_human_approval`.
10. If the exported payload includes pending `source_audit.pending_publish_update_review_findings`, keep going with dry-run review only. Publish or update must wait for explicit user approval of those exact source-integrity items.
11. Run the exported payload through a separate publishing dry-run workflow.

## Tools

- `get_server_health`
- `create_editorial_project`
- `list_editorial_projects`
- `get_editorial_project`
- `audit_revision`
- `propose_revision`
- `apply_revision`
- `approve_revision`
- `export_wordpress_payload`

## HTML exports

If a project uses `content_format=html`, `export_wordpress_payload` requires `trusted_html=true`.

For `content_type=article`, `export_wordpress_payload` also reads the latest source-audit report for the same slug from `CLEARON_SOURCE_AUDIT_ROOT` or the default Clearon source-audit data directory. The report must match the approved revision fingerprint and be `ready_for_human_approval`. When `ready_for_publish_or_update` is still false, the payload records the pending source-integrity review list so downstream dry runs can surface it and real publish/update flows can block on it.

That requirement is explicit because the server passes stored HTML through as-is. If you need sanitization, do it in a separate trusted preprocessing step before export.

## Protected passages

`protected_passages` are not just substring checks anymore. At project creation, the server captures the full original block containing each protected passage and later revisions must preserve that exact protected block. This is still a lightweight structural safeguard, not a full semantic diff or legal-redline system.

## Development

```sh
npm test
npm run smoke
npm run syntax
```