Add gated changeset application and graph controls

docs/APPLICATION_DECISION.md

@@ -1,62 +1,47 @@
 # Canonical application decision
 
-**Status:** DFG-9 complete.
+**Status:** Superseded by the DocForge 0.13 hash-bound application contract.
 
-**Decision:** DocForge does not apply changesets to canonical project files. Accepted proposals are
-manually integrated through the owning project's established source, build, test, and Git workflow.
-This is the permanent DocForge 0.x policy, not a deferred implementation item.
+## Decision
 
-## Evidence
+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.
 
-DFG-8 produced one real AssetForge proposal. DocForge automated source-hash checks, writer scope,
-changeset storage, conflict detection, project validation, structured diffing, and escaped preview
-rendering. The remaining integration step was one reviewed content replacement in one existing
-Markdown chapter. That step completed without an integration failure, lost work, or material delay.
+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.
 
-There is no recorded evidence of repeated manual-integration errors, costly multi-file application,
-or another project requiring canonical application. A generic application command would therefore
-add more authority and failure handling than the observed workflow needs. It would require:
+## Authorization
 
-- project-specific Markdown and TOML writers instead of the current read and validation adapters;
-- atomic rollback across every affected canonical file;
-- recovery when source application succeeds but a project build or validation later fails;
-- a developer authorization boundary that cannot be reached through MCP or an agent writer;
-- exact handling for create, move, delete, metadata, relationship, and manifest ownership; and
-- new cross-project proof that the generic core does not assume Worldforge source semantics.
+- 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.
 
-Adding those capabilities to remove one deliberate copy step would weaken the existing ownership
-boundary without measured benefit.
+## Application boundary
 
-## Permanent 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.
 
-DocForge may read canonical sources and write only configured indexes, changesets, previews, and
-declared derived renders. It may validate, diff, and preview a proposed graph. It does not write,
-rename, or delete canonical sources through its library, CLI, or MCP server.
+Application does not run project commands, tests, shell operations, Git, deployment, publication,
+or arbitrary renderers. Those remain with the owning project workflow.
 
-The developer or project owner retains these actions:
+## Why the earlier decision changed
 
-1. review the complete changeset diff and preview;
-2. confirm the current canonical source and base hashes still match;
-3. manually integrate only the accepted content through the project's canonical source owner;
-4. run the project's builder, index refresh, tests, and generated-output checks; and
-5. inspect, commit, push, deploy, or publish through the project's normal workflow.
+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:
 
-If canonical state changes before integration, the proposal must be refreshed or recreated. A
-developer must not bypass a stale or conflicting changeset by applying it mechanically.
-
-## Reopening criteria
-
-DFG-9 is closed. Canonical application may be reconsidered only through a new explicitly approved
-gate with measured evidence of repeated integration failures or meaningful repeated work across
-more than one project. That gate must define source-format ownership, developer authorization,
-atomic rollback, failure recovery, compatibility, and complete cross-project proof before code is
-written. It must not add an MCP application tool.
-
-## Proof
-
-- The MCP protocol test asserts the exact tool list and rejects any tool name containing `apply`,
-  `commit`, `push`, `deploy`, `publish`, or `shell`.
-- Proposal and adapter tests prove canonical source bytes remain unchanged during create, validate,
-  diff, preview, conflict, and stale-source operations.
-- DFG-8 completed a real reviewed proposal through manual integration and the Worldforge canonical
-  builder without an application command.
+- 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.