Make project MCP workflows self-synchronizing

docs/USER_MANUAL.md

@@ -416,6 +416,7 @@ info
 validate
 build
 reindex
+sync
 check
 validate-index
 ```
@@ -424,6 +425,7 @@ validate-index
 - `validate` validates current canonical sources without requiring an index.
 - `build` rebuilds the disposable index.
 - `reindex` rebuilds and checks the index in one operation.
+- `sync` checks the index and rebuilds it only when it is missing, stale, or invalid.
 - `check` and `validate-index` verify that the existing index matches current sources.
 
 ### Query commands
@@ -505,6 +507,8 @@ Example MCP client configuration:
 
 ### Read tools
 
+- `docforge_bootstrap`
+- `docforge_sync`
 - `docforge_project_info`
 - `docforge_get_contract`
 - `docforge_get_node`
@@ -524,8 +528,11 @@ Example MCP client configuration:
 ### Proposal tools
 
 - `docforge_create_changeset`
+- `docforge_register_changes`
 - `docforge_list_changesets`
 - `docforge_get_changeset`
+- `docforge_rebase_changeset`
+- `docforge_abandon_changeset`
 - `docforge_propose_node_create`
 - `docforge_propose_node_update`
 - `docforge_propose_node_move`
@@ -545,14 +552,29 @@ creates a new hash, so an earlier approval cannot silently apply later content.
 
 Recommended agent sequence:
 
-1. Read the contract and relevant nodes.
-2. Create a changeset.
-3. Add structured operations using the hash returned by each previous mutation.
-4. Validate the changeset.
-5. Inspect its structured diff and preview.
-6. Obtain human approval for the final changeset hash when required by the client workflow.
-7. Call `docforge_apply_changeset` with that exact hash.
-8. Report changed canonical files and derived refresh results.
+1. Call `docforge_bootstrap`. It synchronizes derived state and reports the exact fixed binding.
+2. Read the relevant context and implementation.
+3. Make and verify one coherent implementation slice.
+4. Call `docforge_sync`. This is a no-op when the index is already current.
+5. Call `docforge_register_changes` once with the complete operation list.
+6. Inspect the structured diff and preview.
+7. Obtain human approval for the final changeset hash when required by the client workflow.
+8. Call `docforge_apply_changeset` with that exact hash.
+9. Call `docforge_bootstrap` to verify the new canonical and derived identity.
+
+The older create-and-append tools remain supported for interactive proposal construction.
+`docforge_register_changes` avoids intermediate empty changesets and caller-managed hash chaining.
+For update, move, and delete operations it captures the synchronized current node hash when
+`expected_content_hash` is omitted.
+
+Active changeset listing includes draft and ready proposals. Stale work remains available through
+an explicit `status="stale"` query for rebase decisions. Applied and abandoned proposals are
+terminal history, remain available by status or history request, and no longer block new proposals
+against the same canonical base.
+
+Canonical application records its terminal receipt immediately after the project-owned serializer
+verifies the new canonical state. A later index or render refresh failure is reported as degraded
+derived state with remediation, not as permission to apply the same canonical change again.
 
 Use `docforge_propose_relationship_update` when the intended change is only an edge addition or
 removal. It uses the same underlying validated update contract, but rejects empty relationship
@@ -591,15 +613,22 @@ invalidation rules, manual-application lifecycle, and lazy Logic boundary.
 
 ### `stale_index` or `visualization_stale`
 
-Canonical sources changed after the index or viewer snapshot was built.
+Normal MCP operations automatically repair a missing, stale, or invalid disposable index under a
+project lock. `docforge_sync` can be called explicitly to inspect whether synchronization was a
+no-op or rebuild. The CLI equivalent is:
 
 ```bash
-docforge --project-root "$PROJECT" reindex
+docforge --project-root "$PROJECT" sync
 docforge --project-root "$PROJECT" visualize
 ```
 
 An existing graph browser intentionally stays pinned to its original index identity. Reopen it
-after reindexing.
+after synchronization or reindexing.
+
+Every complete index build also writes a disposable whole-file SHA-256 attestation. A new MCP
+process verifies the unchanged database against that receipt instead of reconstructing every graph
+row. Missing or mismatched receipts fall back to complete verification and are recreated only after
+the full check succeeds.
 
 ### `visualization_manager_unavailable`
 
@@ -639,8 +668,9 @@ new hash rather than retrying with the old approval.
 - `content_conflict`: a target node no longer has the expected content hash.
 - `proposal_conflict`: another active proposal from the same base touches the same node or source.
 
-Do not force apply. Rebase the intended changes into a new changeset after inspecting current
-canonical content.
+Do not force apply. Call `docforge_rebase_changeset` with the exact current changeset hash. DocForge
+will rebind it only when every touched fact is unchanged and the proposal still validates. A
+content or relationship conflict remains fail-closed and requires a newly reviewed proposal.
 
 ### `application_mismatch`