Complete DFG-9 application decision

docs/APPLICATION_DECISION.md

@@ -0,0 +1,62 @@
+# Canonical application decision
+
+**Status:** DFG-9 complete.
+
+**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.
+
+## Evidence
+
+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.
+
+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:
+
+- 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.
+
+Adding those capabilities to remove one deliberate copy step would weaken the existing ownership
+boundary without measured benefit.
+
+## Permanent boundary
+
+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.
+
+The developer or project owner retains these actions:
+
+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.
+
+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.

docs/CONTRACT.md

@@ -10,6 +10,11 @@ only isolated changesets. Canonical application, project builds, Git mutation, d
 publication remain external integration actions. Passive revision detection may read the current Git
 commit when Git is available; it cannot change repository state.
 
+DFG-9 made manual canonical integration the permanent DocForge 0.x policy. The library, CLI, and
+MCP server do not apply changesets to canonical files. Reconsidering that boundary requires a new
+approved contract and measured cross-project evidence; it is not an unimplemented 0.x feature. See
+`APPLICATION_DECISION.md`.
+
 ## Versioned contracts
 
 - Project descriptor schema: `schemas/project.schema.json`, version 1.

docs/MCP_CONTRACT.md

@@ -62,5 +62,9 @@ The normal server never exposes shell execution, arbitrary reads or writes, cano
 application, declared project-output rendering, arbitrary renderer execution, Git mutation, project
 builds, deployment, publication, global project selection, or cross-project retrieval.
 
+DFG-9 permanently retained manual canonical integration for DocForge 0.x. No application tool is
+planned for MCP. A future local developer workflow may be considered only through a new approved
+contract, and it must not make canonical application reachable from an MCP writer.
+
 DocForge pins the official stable Python MCP SDK to the compatible `mcp>=1.28,<2` release line.
 Migration to a later major release requires a separate contract and protocol compatibility review.