# Canonical application decision

**Status:** Superseded by the DocForge 0.13 hash-bound application contract.

## Decision

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.

## Why the earlier decision changed

The earlier DFG-9 decision preserved manual integration because there was not yet repeated evidence
for canonical application. Later multi-project use produced recurring proposal application work,
stale-index round trips, and an explicit user requirement for faster approved integration. The new
contract addresses the original safety concerns with:

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