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.