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 must be a configured proposal writer.
- Application defaults to changesets created by the applier identity. A project-owned server may
  explicitly bind additional configured proposal writers that its applier is authorized to accept.
- Cross-identity acceptance does not let the applier edit the contributor's proposal and does not
  give the contributor an application tool.
- 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;
- an explicit accepted-writer allowlist for any cross-identity application;
- 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.