frontend-patterns/research/reviews/StorageReceiverRecovery.md

Concrete storage and receiver recovery

2026-09-28, Codex author-model review; no independent human validation. Owner: FEP-WP-0003 T04. Preregistration at aea9796; runner and reproduction, retained receipt.

Result and task disposition

Nine checks pass on SQLite 3.45.1 and Git 2.43.0. This completes T04's bounded concrete-pair investigation with explicit negative controls and remaining unknowns. The Git receiver is upstream receive-pack, launched against a disposable bare repository; the sender/outbox integration is authored research code. It is neither a deployed frontend nor a replacement for the Matrix experiment's missing real Matrix-server proof. No candidate contract or maturity is promoted.

Obligation	Observation	Boundary
Interrupted local transaction	SIGKILL before commit leaves old document and pending operation intact after reopen/integrity check	Process interruption, not power loss or a kill inside commit I/O
Commit before acknowledgement	SIGKILL after commit retains new document, new pending identity and old superseded state	SQLite WAL, synchronous FULL on this host
Supersession	Kill between statements rolls the transaction back; committed path changes all three facts	No sender concurrency or transmitted-operation recall guarantee
Negative local control	Committing old-operation supersession separately leaves no replacement after interruption	Atomic grouping is necessary in this fixture
Lost local receipt	Actual receive-pack accepts A; killed sender leaves A pending in SQLite	Git response arrived at sender; local acknowledgement was not persisted
Same-identity replay	New push of A reports up-to-date; history still has only base plus A	Identity is the immutable commit, not arbitrary business intent
Stale ancestry	A forced divergent update after B is refused by the receiver's denyNonFastForwards setting; branch stays at B and local work remains pending	Ancestry policy differs from exact expected-version comparison
Identity retention	Fresh processes and garbage collection preserve reachable A and show it is an ancestor of B	Reachability is the tested retention scope, not indefinite retention or an authenticated receipt
Negative receiver control	Rebuilding the same intent as a new commit on B adds a fourth history entry	Git cannot deduplicate business intent with different identities

Interpretation and documentary basis

The SQLite atomic commit description explains transaction recovery. Its synchronous pragma defines FULL synchronization for WAL. These are engine contracts, not observations of this machine's power-loss resilience; the fixture tests ordinary process kills.

Git's receive configuration and push documentation distinguish ref updates, ancestry and expected-value leases. The experiment forces a divergent transmission and observes server refusal, rather than counting a client-side lease refusal as receiver evidence. Replay while A is the tip is a no-op. Once B is the tip, checking A's reachable ancestry supplies scoped evidence of inclusion; trying to push A again is not a general outcome-lookup API. A fresh identity does not prove freshness of intent, and object existence alone does not prove a branch accepted that object.

This corroborates the existing separation among Local Commit Boundary (CAND-0002), Pending Synchronization (CAND-0003), Version-Checked Mutation (CAND-0006) and Mutation Outcome Tracking (CAND-0007). Git's ancestry rule is only a related mechanism for CAND-0006: it is not exact version equality or a frontend implementation. SQLite and Git observations are one authored integration, not two independent full uses.

Evidence limits and existing ownership

No failed development run occurred; the negative-control failures of the proposed contracts are retained as successful detection checks. There were no inference calls. No power failure, filesystem fault, device-loss restore, remote durability guarantee, identity-expiry test, authorization change, user interaction or accessibility test was performed. SQLite and Git cannot form one distributed transaction here. Full frontend contracts and production recurrence remain unknown.

T04 is done for this selected pair and tested process-failure envelope. Broader implementation evidence remains WP-0003 T01; validated cases/human/AT evidence remain WP-0003 T02 and WP-0002 T03. Those existing obligations retain the stronger claims; this review opens no task, workplan or stronger recovery promise. Device-loss backup is an explicit exclusion, not silently inferred from synchronization. Frozen 0.1 publication and historical assessments remain unchanged.