Add explicit cross-identity proposal acceptance

docs/CANONICAL_APPLICATION.md

@@ -13,7 +13,11 @@ files.
 - 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 changeset creator must be a configured proposal writer.
+- Application defaults to changesets created by the applier identity. A project-owned server may
+  explicitly bind additional configured proposal writers that its applier is authorized to accept.
+- Cross-identity acceptance does not let the applier edit the contributor's proposal and does not
+  give the contributor an application tool.
 - The exact final changeset hash is required. Any proposal mutation invalidates an earlier
   approval.
 
@@ -33,6 +37,7 @@ The application boundary requires:
 
 - exact changeset-hash approval;
 - startup-bound applier identity;
+- an explicit accepted-writer allowlist for any cross-identity application;
 - project-owned serializers for custom adapters;
 - canonical path and symbolic-link confinement;
 - rollback and semantic round-trip verification;

docs/MCP_CONTRACT.md

@@ -191,7 +191,10 @@ An explicit project integration may construct the full fixed surface only after
 confined proposal policy and startup-bound writer. Adapter proposal validators may narrow the
 writer's declared operations further. They cannot add arbitrary tools or weaken core changeset
 validation. The fixed application tool is registered only through the separate canonical applier
-gate.
+gate. Application accepts only changesets created by the applier identity unless the project-owned
+factory explicitly supplies `accepted_proposal_writers`. Every accepted identity must already be a
+configured proposal writer. This allowlist permits review and acceptance across process identities;
+it does not grant proposal mutation or application tools to a contributor process.
 
 ## Isolated proposal tools
 

docs/POLICY_PRECEDENCE.md

@@ -43,9 +43,10 @@ Capability modes are:
 - `operator`: reserved; it currently adds no tools.
 
 Mode describes the maximum registered surface. Actual authority can be narrower. A descriptor must
-declare the selected writer, including allowed families and operation types. Application requires
-the matching configured writer, changeset creator, and canonical-applier identity. A mode name
-cannot create a missing descriptor grant.
+declare the selected writer, including allowed families and operation types. Application defaults
+to a matching configured writer, changeset creator, and canonical-applier identity. A project-owned
+server may explicitly authorize its applier to accept changesets from additional configured writers.
+A mode name cannot create a missing descriptor grant or extend that accepted-writer allowlist.
 
 Generic generated client fragments default to read mode. Other construction paths preserve their
 documented compatible factory defaults. Treat `docforge_bootstrap.session_contract` and its actual

docs/USER_MANUAL.md

@@ -815,7 +815,14 @@ docforge-mcp \
 ```
 
 Without `--canonical-applier`, `docforge_apply_changeset` is not registered. The flag is an
-identity, not a command. The changeset creator, configured writer, and canonical applier must agree.
+identity, not a command. Generic CLI and MCP application require the changeset creator, configured
+writer, and canonical applier to agree.
+
+A project-owned adapter server can separately pass `accepted_proposal_writers` to
+`create_project_server`. This explicit allowlist lets its startup-bound applier accept an exact
+reviewed changeset from another configured contributor identity. The default remains the applier
+identity only. Accepted contributors retain their original proposal permissions and do not receive
+canonical application authority.
 
 Call `docforge_bootstrap` first. Its version-1 `session_contract` contains the fixed binding,
 current graph generation, effective policy, actual capabilities, render policies, prohibitions,