Document the 1.4.0 release candidate

docs/CONTRACT.md

@@ -1,4 +1,4 @@
-# DocForge post-1.0 development contract
+# DocForge 1.4 contract
 
 ## Authority boundary
 
@@ -34,13 +34,19 @@ commit when Git is available; it cannot change repository state.
 - Reference adapter configuration: `schemas/reference-adapter.schema.json`, version 1.
 - Index schema: version 3, disposable and reproducible.
 - Index attestation: schema version 1, disposable and reproducible.
-- Core, CLI, and MCP server: version 1.3.0.dev0.
+- Distribution, Python package, CLI, generic MCP, reference MCP, and viewer manager: version 1.4.0.
 - Incremental extraction cache: version 1, disposable and reproducible.
 
 Schema files describe the generic interchange contract. Runtime validation remains responsible for
 path confinement, source hashing, relationship resolution, dependency cycles, project limits, stale
 state, and adapter-specific rules that JSON Schema cannot prove by itself.
 
+`src/docforge/_version.py` is the sole package-version authority. The maintained executable
+surfaces report exactly `docforge 1.4.0`, `docforge-mcp 1.4.0`,
+`python -m docforge.reference_mcp 1.4.0`, and `docforge-viewer-manager 1.4.0` for `--version`.
+Generated generic and adapter client configurations bind `docforge_version` into their validated
+hashes.
+
 ## Generic node storage
 
 Markdown nodes begin with a TOML metadata block delimited by `+++`. The remaining Markdown is the
@@ -73,6 +79,13 @@ Index replacement is the derived publication commit point. Attestation, cheap so
 and latest-generation-diff receipts are independent post-commit evidence. Their failure produces
 bounded degraded success and never falsely reports that a committed index mutation failed.
 
+Derived publication stages and flushes one complete bounded artifact before atomic replacement or
+no-clobber publication, then flushes the containing directory. An interruption therefore leaves
+the preceding complete artifact, the new complete artifact, or explicit degraded post-commit
+evidence. Index attestations, manual render receipts, generation-diff baselines, and portable-graph
+manifests have maintained exact-oracle corruption-and-repair proofs. Canonical project files remain
+unchanged throughout those recoveries.
+
 Before replacement, a build accepts a predecessor only when its exact main-file inode has a
 matching whole-file attestation, has no WAL, journal, or shared-memory sidecar, and passes the
 published SQLite identity, row, hash, FTS, integrity, and policy checks. It uses an immutable
@@ -174,6 +187,30 @@ default active listing contains only draft and ready work. Stale, applied, and a
 remain queryable by explicit status or history request. Terminal proposals do not block new
 proposals.
 
+## Canonical application durability
+
+Generic canonical application stages replacements and backups in a mode-0700
+`.docforge/application/transaction-*` directory. Before each canonical create, update, or delete,
+it compares exact file identity at the publication boundary. Creates use no-clobber publication.
+Updates and deletes use atomic exchange and no-replace detachment. A concurrent canonical-target
+mutation fails closed, is rolled back only when exact displaced state remains provable, or is
+retained without overwriting foreign data.
+
+This is per-file compare-and-swap publication, not multi-file crash atomicity. In-process failures
+run rollback across already published files, but there is no process-death journal. Process or host
+death between publications may leave a partial canonical application and requires operator
+inspection before a new proposal or restoration.
+
+The private transaction namespace is integrity-confined against ordinary path access. It is not a
+filesystem sandbox, and deliberate arbitrary tampering by another process with the same operating-
+system UID is outside the contract. DocForge identity-checks private files before consuming or
+removing them.
+
+After the serializer reproduces the approved graph, canonical success is final. If private cleanup
+then degrades, application still returns `applied`, closes the proposal, and persists bounded
+`application_recovery` lifecycle metadata with status `cleanup_required`, retained paths, and
+remediation. The reviewed changeset must not be applied twice.
+
 ## Declared rendering and previews
 
 Render configuration is optional. A configured project declares one template root, one isolated