Goal: Decide from DFG-7 and DFG-8 evidence whether a developer-only canonical changeset application command is justified.
In scope: Review read-only and proposal workflow evidence; define the exact human authorization boundary; evaluate repeated integration work; require clean base hashes and repeat validation; and either specify one narrow application command or record manual integration as permanent policy.
Out of scope: OpenClaw canonical application; automatic commit, push, deployment, or publication; arbitrary commands; accounts; HTTP transport; a web UI; and implementation before the evidence review supports it.
Done when: The project records either a proven narrow developer-only application contract or a reasoned decision to keep proposals manually integrated.
Owners: DocForge owns proposal evidence and generic safety constraints. Each project owns canonical source semantics and integration policy. A developer retains authorization, review, build, Git, and publication ownership.
Decision: Manual canonical integration is the permanent DocForge 0.x policy. No application command was added.
Proof: DFG-8 required one reviewed content replacement after DocForge had already validated, diffed, and previewed the proposal. It completed without failure or material repeated work. An application command would add canonical writers, authorization, rollback, and project-format ownership without measured need. Existing protocol and proposal tests prove that MCP and proposal workflows cannot alter canonical sources.
