DocForge2/docs/CANONICAL_APPLICATION.md

# Canonical application

DocForge may apply one isolated changeset to canonical project sources through an explicit,
project-bound canonical applier. Application is available through both CLI and MCP. It is never an
implicit consequence of validation, diffing, previewing, or rendering.

The generic adapter owns a deterministic Markdown/TOML serializer. Custom adapters must provide a
project-owned `CanonicalApplier`. Core DocForge does not guess how adapter nodes map back to source
files.

## Authorization

- CLI requires `apply CHANGESET_ID --changeset-hash SHA256 --applier WRITER_ID`.
- MCP registers `docforge_apply_changeset` only when the server starts with an explicit canonical
  applier identity and compatible applier implementation.
- The changeset creator and applier identity must match a configured proposal writer.
- The exact final changeset hash is required. Any proposal mutation invalidates an earlier
  approval.

## Application boundary

Application revalidates the canonical base, node hashes, graph, permissions, conflicts, target
paths, and projection. Generic writes are staged, confined to declared content roots, and rolled
back if the result does not reproduce the approved projection. Successful application rebuilds and
checks the derived index and regenerates declared render views.

Application does not run project commands, tests, shell operations, Git, deployment, publication,
or arbitrary renderers. Those remain with the owning project workflow.

## Safety contract

The application boundary requires:

- exact changeset-hash approval;
- startup-bound applier identity;
- project-owned serializers for custom adapters;
- canonical path and symbolic-link confinement;
- rollback and semantic round-trip verification;
- deterministic derived-state refresh; and
- complete separation from Git, builds, deployment, and publication.