Document the 1.4.0 release candidate

docs/SECURITY.md

@@ -1,7 +1,8 @@
 # Security model
 
 DocForge is a project-bound knowledge compiler. Its security boundary is an explicit project root,
-closed configuration, bounded data, and exact identities. It is not a general process sandbox.
+closed configuration, bounded data, and exact identities. It is not a general process or
+filesystem sandbox.
 
 Start with [core authority](CORE_CONCEPTS_AND_AUTHORITY.md), then use
 [policy precedence](POLICY_PRECEDENCE.md) to decide which capabilities a server should expose.
@@ -18,6 +19,13 @@ Confinement protects DocForge operations. It does not stop another process with
 from changing files. Long-running bindings revalidate descriptor and adapter implementation
 identity and require a restart after drift.
 
+Generic canonical application stages backups and replacements below
+`.docforge/application/transaction-*` in mode-0700 directories. That private namespace confines
+ordinary path access and prevents access by other users. Deliberate arbitrary tampering by another
+process running as the same operating-system user is outside this boundary. DocForge still
+identity-checks private files before using or removing them, but mode `0700` is not isolation from
+the same UID.
+
 ## Untrusted project content
 
 Documentation, source text, templates, adapter metadata, compiler-database entries, and changeset
@@ -56,16 +64,33 @@ the exact changeset hash that was reviewed. Source identity, content hashes, per
 conflicts, graph validity, and serializer round trips are checked before success. DocForge never
 turns prose approval into a fuzzy merge.
 
+The generic applier compares exact canonical file identity immediately before each publication.
+Create uses no-clobber publication. Update and delete use atomic exchange and no-replace moves.
+Concurrent canonical-target mutation therefore fails closed, rolls back when the exact displaced
+state is still provable, or retains recovery evidence without overwriting foreign data.
+
+This compare-and-swap protection is not a process-death journal. One file publication is atomic,
+and an in-process failure runs exact rollback, but an application spanning several canonical files
+does not promise crash atomicity if the process or host dies between publications. Operators must
+inspect canonical state and retained transaction evidence before retrying after such an
+interruption.
+
 ## Derived state and publication
 
 SQLite indexes, source-generation receipts, extraction caches, render fragments, previews, and
 portable artifacts are disposable. Corrupt, stale, foreign, oversized, or mismatched derived
 state is rejected or rebuilt from current project evidence.
 
-Generated command-reference publication serializes cooperating writers and uses no-clobber or
-compare-and-swap publication. A raced target is restored or retained for recovery instead of being
-silently discarded. Projection publication records when an artifact was committed but later
-receipt verification degraded, so a completed mutation is never reported as an ordinary failure.
+Derived publication stages complete bounded output, flushes file and directory state, and commits
+with atomic replacement or no-clobber compare-and-swap. It is crash-safe: an interruption leaves
+the prior verified artifact, the complete new artifact, or explicit degraded post-commit evidence,
+not a mixed publication. Generated command-reference publication also serializes cooperating
+writers. A raced target is restored or retained for recovery instead of being silently discarded.
+
+Projection and canonical-application lifecycles record when semantic content committed but later
+private cleanup or receipt verification degraded. Canonical success closes the applied proposal
+and persists compact `application_recovery` metadata with retained paths and remediation. A
+completed mutation is never reported as an ordinary retryable failure.
 
 ## Limits and denial-of-service resistance