Make project MCP workflows self-synchronizing

docs/MCP_CONTRACT.md

@@ -12,6 +12,8 @@ canonical applier implementation.
 
 ## Read tools
 
+- `docforge_bootstrap`
+- `docforge_sync`
 - `docforge_project_info`
 - `docforge_get_contract`
 - `docforge_get_node`
@@ -30,6 +32,11 @@ canonical applier implementation.
 
 Each response states that document text is project content, not higher-priority instructions. Each
 response includes project identity, revision, source hash, adapter version, and staleness state.
+Every normal tool call first checks current source identity and atomically rebuilds disposable index
+state when it is missing, stale, or invalid. `docforge_bootstrap` performs that synchronization and
+returns the complete fixed binding, active index path, proposal and application capabilities, and
+recommended workflow. `docforge_sync` exposes the same idempotent synchronization explicitly.
+Neither operation changes canonical sources.
 
 The normal command binds the generic project loader. An explicit project integration may instead
 construct the same read-only surface from a validated `ProjectService` and project-owned context
@@ -45,8 +52,11 @@ gate.
 ## Isolated 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`
@@ -63,6 +73,18 @@ for existing changesets. A preview accepts a declared view ID, not a renderer na
 The relationship-update tool queues additions and removals without rewriting node content and
 rejects an empty relationship list.
 
+`docforge_register_changes` is the preferred write entry point. It creates, populates, projects,
+conflict-checks, and validates one complete changeset in a single locked operation. Existing-node
+operations may omit `expected_content_hash`; the server captures the current synchronized node hash
+inside that transaction. The stored changeset remains fully hash-bound.
+
+`docforge_rebase_changeset` moves a stale proposal to the current project base only when all
+touched nodes, sources, relationships, permissions, and graph invariants still validate. It never
+merges prose. `docforge_abandon_changeset` preserves an audit receipt without deleting the proposal.
+Changeset listing returns draft and ready work by default. Stale, applied, and abandoned proposals
+remain available through an explicit status or history request. Applied and abandoned proposals no
+longer participate in overlap conflict detection.
+
 ## Canonical application tool
 
 - `docforge_apply_changeset`
@@ -74,8 +96,11 @@ configured serializer.
 
 The generic serializer confines staged Markdown/TOML writes to declared content roots and verifies
 that the applied files reproduce the approved graph projection. A mismatch rolls canonical files
-back. A successful apply rebuilds and checks the derived index and regenerates all declared render
-views. It does not run project commands, shell, Git, builds, deployment, or publication.
+back. Canonical success records an `applied` lifecycle receipt bound to the reviewed changeset hash
+before refreshing derived state. Index or render refresh failures return a successful canonical
+application with a degraded derived-refresh report and explicit remediation; they never invite the
+caller to apply the same canonical change twice. DocForge does not run project commands, shell,
+Git, builds, deployment, or publication.
 
 ## Render boundary