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.