Architecture and UX Research for Local-First Archival Reconstruction Resilience

Full report

On this page

The Imperative of Local-First Resilience

The architectural evolution of the Al.Qaeda.net Archival Reconstruction platform into a robust, local-first browser workstation fundamentally shifts the locus of data responsibility. In conventional web applications, data permanence is guaranteed by central servers, cloud databases, and continuous background synchronization. However, this workstation operates under a strict data sovereignty mandate: the user's research work belongs entirely to their local computing environment and to the discrete files they explicitly export. There is no server-side user backup, no account synchronization, no remote telemetry, and no cloud recovery. Because the architecture dictates that user data never traverses a network to a central server, the local browser environment—specifically its persistent storage sandboxes—becomes the absolute source of truth. Consequently, the application must assume the protective capabilities and fail-safes of a traditional desktop operating system. It must shield the user from accidental structural deletions, browser cache clearing, device crashes, storage exhaustion, and corrupted imports. The existing baseline has successfully established local structured desktop state, IndexedDB primary session checkpoints, an interrupted-boot marker, offline-shell behaviors, and the restoration of window positions. As future versions scale to contain substantially more user-created research, the system must deploy the next layer of resilience. This research report delineates the architecture, interaction models, and fail-safes required to make the application exhaustively resilient. By adapting classic desktop metaphors—such as System Restore, Backup Wizards, and Document Recovery panes—the system can communicate complex browser storage mechanics in a familiar, accessible vernacular, entirely masking the underlying web technologies from the end user.

The Local-Only Privacy Model

The foundational directive of the application is absolute data sovereignty. To satisfy this critical privacy requirement while maximizing data resilience, the system must strictly adhere to the following architectural axioms. The application must never transmit usage statistics, error logs, or storage quota warnings to any remote endpoint. The user interface must rely exclusively on local polling mechanisms, such as navigator.storage.estimate(), to monitor disk health, evaluating constraints entirely within the client runtime1. Furthermore, the application cannot rely on account-based sync engines or distributed state resolution across remote endpoints. All conflict resolution, particularly when multiple windows or tabs are manipulating the same dataset, must occur locally in memory or via inter-process communication native to the browser4. When a user initiates an export, the resulting backup file must be constructed entirely in memory on the client side, compressed using localized algorithms, and written directly to the user's physical file system. This ensures that the generation of a backup is a strictly offline operation. Conversely, a user opening or restoring a backup file must initiate a localized parsing process. The file contents must never be uploaded, processed, or verified by a remote server. Import operations must parse the archive locally and stream the contents directly into the local database sandbox. The application must utilize the browser's storage mechanisms as opaque silos, entirely inaccessible to other domains. However, because browsers treat local data as "best-effort" and subject to automatic eviction under disk pressure, the application must explicitly request durable status. This is achieved by invoking the navigator.storage.persist() API1. When persistent status is granted, the browser engine is prohibited from automatically clearing the application's data, regardless of storage pressure or user inactivity, protecting the workspace until the user explicitly clears their site data or uninstalls the application3.

Historical Precedents and Product Benchmarks

To ground the user experience in proven paradigms and avoid the cognitive dissonance often associated with web-based storage, six legacy and modern applications were benchmarked for their offline resilience, recovery metaphors, and data-loss prevention mechanics.

Microsoft Word and the Document Recovery Metaphor

Microsoft Word utilizes a mature "AutoRecover" mechanism that generates .asd (AutoSave) snapshot files at regular intervals, typically every 10 minutes8. These files are created invisibly in local application data directories (e.g., %appdata%\\Microsoft\\Word or %localappdata%\\Microsoft\\Office\\UnsavedFiles) and are only surfaced if the application experiences an ungraceful shutdown9. Upon a subsequent cold boot, Word detects the presence of an orphaned .asd file and presents the "Document Recovery" pane. This pane is a critical UX precedent: it allows the user to view the timestamp of the interrupted work, select the recovered file, and explicitly save it to their desired location, or discard it9. Furthermore, if a user closes a document without saving, the system can optionally retain the last AutoRecovered version as a safety net9.

Windows System Restore and Volume Shadow Copies

The classic Windows System Restore provides an exceptional mental model for global application rollback. It relies on the Volume Shadow Copy Service (VSS) to capture atomic, point-in-time snapshots of the file system and registry12. Its UX metaphor is highly applicable to the Archival Reconstruction tool: it allows users to name specific "Restore Points" prior to major system changes, maintaining a linear timeline of stable states. Restoration involves a step-by-step wizard that explicitly warns users about which parameters will be rolled back, effectively establishing the concept of workspace-level temporal navigation without exposing the underlying snapshot architecture.

Figma and the IndexedDB Offline Buffer

Figma operates primarily as a cloud-first collaborative design tool, but it implements a robust local-first fallback using the browser's persistent storage. If network connectivity drops, Figma buffers user edits seamlessly into the browser's local IndexedDB15. It maintains a session-based undo history that functions offline. However, Figma's implementation highlights a critical vulnerability in browser-based tools: if a user attempts to close the tab while offline, Figma warns them, but if the user clears their browser cache or operates in a private browsing window, all unsynced offline work is irreversibly destroyed15. Figma's architecture demonstrates that relying purely on invisible browser storage without offering manual, exportable file-based backups is insufficient for absolute data resilience. Furthermore, Figma's undo history is strictly local to the client and is not persisted across sessions, meaning a page refresh clears the undo stack17.

Obsidian and Local File Recovery

Obsidian is a quintessential local-first application, treating a directory of Markdown files on the user's hard drive as the absolute source of truth. Its core resilience relies on the "File Recovery" core plugin, which captures complete, deduplicated snapshots of text files at regular intervals (e.g., every 5 minutes)18. Snapshots are retained based on a hierarchical schedule (e.g., kept for 7 days) to prevent disk exhaustion18. Crucially, Obsidian allows users to preview the exact differences between their current state and a past snapshot, displaying additions and deletions, before confirming a restoration18. Plugin architectures, such as the Archivist tool, expand this to allow hierarchical retention (daily, weekly, monthly) and deduplicated content-addressed storage, preventing redundant data from consuming disk space20.

Git and Content-Addressed Version Control

While far too technical for a public-facing graphical user interface, the underlying mechanics of Git—specifically its content-addressed storage and immutable commit history—provide the architectural foundation for reliable local rollbacks21. Git treats every snapshot of a workspace as an immutable node. Moving between states (undoing, redoing, or checking out older versions) simply updates a symbolic pointer, ensuring that traversing the version history does not destructively overwrite or corrupt the underlying data structures20. The Archival Reconstruction workstation must emulate this immutability internally while presenting it simply as "Previous Versions" to the user.

Apple Notes and Local Undo CRDTs

Apple Notes utilizes variations of local-first caching and Conflict-Free Replicated Data Types (CRDTs) to handle edits across devices, but its local undo behavior is particularly relevant. Research into collaborative data structures indicates that undo functionality in Apple Notes is linear and strictly local to the user's current device session17. If the application crashes, the most recent state is preserved in the local database, but the transient undo/redo stack is flushed17. This reinforces the standard expectation that undo is a transient memory function, while persistent data recovery relies on separate snapshot mechanisms.

Core Resilience Model and Operational Definitions

The Archival Reconstruction application must differentiate between transient memory states, automated checkpoints, and hard export backups. To prevent user confusion and align with established cognitive models, these mechanics must be presented through classic desktop metaphors. Technical terminology such as "IndexedDB," "JSON schemas," or "Cache Storage" must be entirely absent from the user interface.

Normal Local Save

A Normal Local Save occurs automatically and silently as the user interacts with the application. It represents the immediate, continuous writing of user input—such as typing text, moving folders, or modifying metadata—from volatile memory (RAM) into the browser's persistent local database. In the UI, this is communicated via a subtle, classic "Status: Saved" indicator in the lower application frame. The purpose of the Normal Local Save is to ensure that if the browser tab is forcefully closed or the operating system crashes, the exact state of the workspace is preserved at the millisecond of failure. It is a continuous overwrite of the "current" state.

Automatic Checkpoint

An Automatic Checkpoint is a periodic, immutable clone of the entire workspace state. While the Normal Local Save continuously overwrites the current working state, an Automatic Checkpoint preserves a historical milestone. In UI terms, this aligns with the "Previous Version" or "AutoRecover" concept. Checkpoints allow the user to roll back the workspace to how it existed an hour ago or a day ago, protecting against catastrophic user errors, such as accidentally deleting a massive hierarchy of research data and realizing the mistake only after the transient undo stack has been cleared.

Manual Snapshot

A Manual Snapshot is a user-initiated Checkpoint. Using the classic "System Tools" metaphor, the user can navigate to the application menu, select "Create Checkpoint," and provide a descriptive name (e.g., "Stable state before reorganizing the Middle East archive"). Architecturally, a Manual Snapshot functions exactly like an Automatic Checkpoint, but it is explicitly exempt from routine algorithmic pruning. It remains permanently in the local database until the user explicitly deletes it, serving as a reliable anchor point for major structural experimentation.

Downloadable Backup

A Downloadable Backup is the ultimate fail-safe. It is a highly compressed archive file (conceptually akin to a .zip file) containing the entirety of the workspace state, exported out of the browser's isolated sandbox and onto the user's physical hard drive. Because browsers can arbitrarily evict site data under extreme storage pressure, or because users may accidentally clear their browsing history, the Downloadable Backup is the only artifact completely immune to browser-level data loss1. The UI must present the creation of this file as a classic "Export Backup Wizard," reinforcing that the user is taking physical custody of their data.

The Command Pattern, CRDTs, and Undo/Redo Mechanisms

Understanding what actions can be reversed, and through which mechanism, is critical for establishing user trust. The system relies on two distinct layers of reversibility: the active Undo/Redo stack (which is transient) and the Checkpoint/Restore system (which is persistent).

Global Undo vs. Per-Application Undo

In complex local-first systems that support concurrent operations, defining the scope of the undo command is historically challenging. According to research on concurrent data structures and Conflict-Free Replicated Data Types (CRDTs), a "Global Undo" attempts to reverse the last chronological action across the entire system, regardless of who performed it or where it occurred22. Global undo implicitly assumes that users are aware of all changes happening globally; if they are not, triggering a global undo can result in disorienting, invisible structural shifts outside the user's current viewport22. Conversely, "Local Undo" reverses the last action performed by the specific user in their specific active context22. For the Archival Reconstruction workstation, undo must be strictly isolated per document or per discrete active window. If a user has two document windows open side-by-side, pressing Ctrl+Z (or selecting "Undo" from the Edit menu) in Document A must only reverse the last action in Document A. Operations in Document B remain untouched.

Undo History Length and the Command Pattern

The active undo/redo history is stored in memory using the Command Pattern. Each user action is encapsulated as an object containing both the forward action (the state mutation) and its exact mathematical inverse24. Because these command objects are stored in volatile RAM to ensure instantaneous UI responsiveness, the undo history length is practically bound by the session duration17. When the user closes the tab or refreshes the browser, the active undo stack is permanently discarded. To compensate for this expected volatility, the application relies on the underlying persistent Checkpoints to allow recovery of older states.

Operation and Undo Matrix

The following matrix defines the boundaries of reversibility across the application, dictating whether an action is handled by the transient memory stack or requires interaction with persistent storage.

Checkpoint Strategy, Storage Mechanics, and Pruning

To manage long-term state recovery without exhausting the browser's storage limits, the application requires an automated, hierarchical checkpoint strategy paired with explicit storage durability requests.

Browser Storage Quotas and Eviction Rules

The application operates within a hostile storage environment. Browsers impose strict, variable quotas on local databases based on the user's total disk size and the specific browser engine.

• Chromium/Edge: Origins can store up to 60% of the total disk size1.
• Firefox: Best-effort data is limited to the smaller of 10% of total disk size or 10 GiB. However, if the user grants persistent storage permissions, this limit increases to 50% of the disk size (capped at 8 TiB)1.
• Safari/WebKit: Browser apps are granted up to 60% of total disk size, but if the web application is embedded in another app (via a WebView), the limit drops severely to 15%1.

If the application attempts to write data beyond these limits, the browser throws a fatal QuotaExceededError1. Furthermore, under extreme system storage pressure, operating systems instruct browsers to evict site data. Browsers evict "best-effort" storage using an all-or-nothing Least Recently Used (LRU) algorithm, meaning the entire workspace database could be wiped out silently to make room for system updates1.

Durability Policies and Storage Buckets

To mitigate data loss during abrupt power failures or operating system kernel panics, the application must configure its primary database connections utilizing the modern Storage Buckets API, explicitly requesting durability: "strict"26. The API offers a trade-off between write performance and power-failure safety. A "relaxed" durability policy allows the operating system to buffer writes in volatile memory, which improves performance and battery life but risks losing the last few seconds of data if the power is cut26. A "strict" durability policy forces the operating system to flush the data directly to the physical storage medium (disk platters or non-volatile SSD cells) before acknowledging the transaction as complete26. Because the Archival Reconstruction tool lacks a central server to recover lost data, it must mandate "strict" durability for all Normal Local Saves and Checkpoints to guarantee absolute data integrity.

Snapshot Pruning and Hierarchical Retention

Checkpoints capture the full content of the workspace. Over months of intensive research, these snapshots can consume significant disk space. The system will implement a hierarchical retention schedule, commonly referred to in enterprise systems as a "Grandfather-Father-Son" backup strategy, which automates the lifecycle of recovery points20.

• High-Frequency (Son): A checkpoint is taken every 15 minutes, provided the workspace has mutated since the last check. These granular checkpoints are retained for 24 hours, offering immediate recovery from short-term mistakes.
• Daily (Father): The final checkpoint of each active day is isolated and retained for 7 days.
• Weekly (Grandfather): The final checkpoint of each active week is isolated and retained for 4 weeks.

Once a checkpoint ages out of its respective time window, an asynchronous background task permanently purges it from the local database to recover quota space. Manual Snapshots, explicitly named by the user, are completely excluded from this pruning logic and must be deleted manually.

Import Atomicity, Upgrades, and Corruption Handling

Data destruction most frequently occurs during complex state transitions. The application must guarantee that operations such as importing massive legacy workspaces or upgrading underlying data schemas are mathematically atomic: they either succeed completely or fail gracefully, leaving the original state untouched.

Import Atomicity and the Staging Area

When a user imports a large Downloadable Backup, the parsing and writing process might take several seconds or minutes depending on device hardware. If the browser crashes, the tab is closed, or the device loses power mid-import, the workspace could be left in a mangled, half-applied state28. To avoid this, the application utilizes IndexedDB transactional atomicity30. The Backup Wizard unpacks the backup file and streams the data into an entirely separate, temporary "staging" object store within the local database. Only when the entire archive is successfully unpacked, cryptographically verified, and indexed does the system execute a final, atomic pointer swap, designating the staging store as the new primary workspace. If any error occurs during the unpacking process, the transaction is automatically aborted, the staging store is dropped, and the original workspace remains perfectly intact31.

Application Version Upgrades and Schema Migration

As the Archival Reconstruction application evolves over years of development, the underlying JSON data structures and database schemas will inevitably change. Every Checkpoint and Downloadable Backup must carry a strict schema version identifier. When a user boots a newer version of the application or attempts to import a backup file generated by an older version, the system detects the version mismatch. It immediately halts the boot process and triggers an automatic "Pre-Migration Checkpoint" to guarantee a safe rollback path. It then executes a sequential chain of migration scripts, translating the data structure from its origin version to the current schema32. The UI displays a classic progress bar: "Upgrading Workspace Database."

Handling Corrupt Backup Files

If a user attempts to import a Downloadable Backup that has been corrupted—perhaps due to a failed USB drive transfer, disk bit-rot, or incomplete download—the application must not crash or overwrite the current workspace with garbage data.

• Integrity Checks: Backup files must utilize standard magic bytes in their headers and include cryptographic checksums (e.g., SHA-256) in their manifest files.
• Partial Extraction: If the manifest checksum fails, the Restore Wizard will halt the import and alert the user: "Archive Corrupted." However, borrowing the metaphor of classic WinZip utilities, it will offer a secondary option: "Attempt Partial Recovery." The application will scan the corrupted archive for any intact, readable document structures and salvage them into a designated "Recovered Documents" folder within the existing workspace, allowing the user to manually sort through the surviving data.

Multi-Tab Concurrency and State Synchronization

A common and highly destructive vector for data corruption in local-first browser applications occurs when a user opens the application in multiple tabs or windows simultaneously. If both tabs attempt to write conflicting data to the single local database concurrently, the workspace state can fracture, resulting in orphaned records or overwritten work34.

The Web Locks API and Leader Election

To prevent simultaneous writes and ensure data integrity, the application will utilize the W3C Web Locks API to manage cross-tab coordination34. Upon initialization, each tab attempts to acquire an exclusive lock (e.g., navigator.locks.request('archival-workspace-lock')) on the primary workspace database34.

• Primary Tab (Leader): The first tab to load successfully acquires the exclusive lock. It becomes the "Leader" and is granted full read/write access to the database. All user edits are processed and saved normally.
• Secondary Tabs (Followers): Subsequent tabs fail to acquire the lock because it is exclusively held by the Primary Tab34. These tabs degrade gracefully into a safe "Read-Only Mode." The UI displays a classic desktop status banner: "Workspace is locked for editing by another window. Read-Only Mode."
• Crash Recovery: If the Primary Tab crashes, is force-closed, or navigates away, the browser's lock manager automatically and instantaneously releases the exclusive lock34. One of the queued Secondary Tabs is immediately granted the lock, promoting itself to Primary, enabling write access, and removing the Read-Only banner from its UI34.

View Synchronization via BroadcastChannel

While Secondary Tabs cannot write to the database, they must not display stale or inaccurate data. The Primary Tab will use the BroadcastChannel API to broadcast state mutations to all other open tabs within the same origin4. When the Primary Tab saves an edit (e.g., modifying a document title or moving a folder), it broadcasts a lightweight differential payload. Secondary tabs listen to this channel and update their in-memory Document Object Model (DOM) in real-time. This ensures that the read-only views remain perfectly synchronized with the true system state, acting as accurate reference monitors for the user5.

Edge-Case Behaviors: Quota, Eviction, and Incognito

The browser environment presents unique hostile conditions that a native, compiled desktop application does not face. The system must anticipate and gracefully handle these edge cases to maintain the illusion of a stable, native application.

Browser Quota Exhaustion

Because browsers enforce hard limits on storage, the application must proactively defend against quota exhaustion.

• Proactive Monitoring: The application will routinely poll navigator.storage.estimate() in the background to calculate available headroom1.
• Graceful Degradation: If the storage quota reaches 95% utilization, the application takes defensive action. It halts all background Automatic Checkpoint generation to preserve remaining space for the user's manual document saves. The UI surfaces a persistent warning icon and status message: "Low Disk Space: The application is critically low on storage. Please export a backup and delete old checkpoints using System Tools."

Private and Incognito Mode Vulnerability

When run in Private or Incognito mode, browsers utilize an ephemeral storage sandbox. While the application will appear to function perfectly, this sandbox is immediately and permanently destroyed by the browser the moment the window is closed3.

• Detection and UX Metaphor: Upon detecting ephemeral storage (via heuristics or quota behavior), the application must aggressively warn the user. The UI displays a prominent "Temporary Mode" alert. Crucially, the UI disables the standard "Save" terminology, replacing it with "Export to Disk," continually reminding the user that relying on the browser's internal state is futile and that their work will vanish upon exit.

User Clearing Site Data

If a user manually clears their browser history and site data via the browser settings, the persistent storage is instantly wiped, bypassing all application-level fail-safes and locks3. There is no programmatic defense against this destructive action. Therefore, the absolute safety of the system relies entirely on the frequency of Downloadable Backups. The application UI must heavily emphasize external, file-based backups as the only true guarantee of data permanence.

UI/UX Design: Classic Desktop Metaphors

Strict visual constraints dictate the exclusion of modern, web-native terminology. The user interface must rely on established System Tools conventions to communicate complex browser mechanics intuitively. Terms like "Cache," "Local Storage," "Sync," and "Cloud" are prohibited. The lexicon is restricted to: Save, Save All, Backup, Restore, Previous Version, Recover Documents, Undo, Recycle Bin, Checkpoint, and Emergency Recovery.

Emergency Recovery Dialog Design

Modeled after the classic MS Office "Document Recovery" pane9, this modal dialog appears automatically on boot if the application detects that the previous session ended abruptly (e.g., an interrupted-boot marker was found in the database configuration).

• Header: Features a classic warning triangle icon ⚠️ alongside the text "Emergency Recovery."
• Body Text: "The application closed unexpectedly during your last session. The following unsaved changes were recovered from your local disk."
• List View: A detailed, sortable list of recovered documents featuring timestamps, file sizes, and status indicators.
• Actions: Two primary buttons: "Save Recovered Documents" (which commits them to the active workspace) or "Discard" (which permanently purges the orphaned states).

Backup and Restore Wizard Design

The Backup/Restore process is presented as a multi-step property sheet wizard, a staple of classic desktop operating systems, avoiding all mention of JSON serialization or IndexedDB extraction.

• Step 1 (Welcome): "Welcome to the Workspace Restore Wizard. This tool will help you restore your archive from a backup file or a previous system checkpoint."
• Step 2 (Source Selection): Radio buttons offering "Restore from a Local Checkpoint" or "Restore from a Backup File (.zip)."
• Step 3 (Preview and Selective Restoration): A split-pane window. The left pane displays a hierarchical tree view of the backup's contents. The right pane displays a read-only preview of the selected document, highlighting structural differences. Checkboxes next to each node allow the user to perform a "Selective Restoration," extracting only specific folders or documents without overwriting the entire current workspace20.
• Step 4 (Execution): A classic indeterminate progress bar detailing the extraction process ("Unpacking archive...", "Verifying integrity...", "Applying changes...").
• Step 5 (Completion): "Restoration Complete. View Recovered Documents."

Export-Backup Schedules and Reminders

Because manual, file-based backups are the only defense against browser cache clearing, the system must encourage frequent exports. However, it must do so without causing alert fatigue or annoying the user3.

• Cadence Logic: The system calculates the volume of changes since the last Downloadable Backup. If the user has made significant edits (e.g., creating 50 new documents), a reminder threshold is met.
• Delivery Mechanism: Reminders are never delivered via OS push notifications or intrusive pop-ups that interrupt active typing. Instead, they appear as a persistent, dismissible status bar message at the top of the workspace upon the first boot of a new week: "It has been 7 days since your last backup. Export a Backup to secure your recent work."

Accessibility Requirements for Recovery UX

Recovery scenarios are inherently high-stress. Ensuring that the UI is accessible to all users, particularly those utilizing assistive technologies or keyboard navigation, is paramount and must be strictly governed by WCAG 2.1 AA standards37.

Focus Management and Keyboard Trapping

When the Emergency Recovery dialog or the Backup Wizard opens, it establishes a temporary, critical interaction mode.

• Keyboard Trap: The UI must strictly trap keyboard focus within the boundaries of the modal. Pressing the Tab key must cycle through the modal's interactive elements and wrap back to the beginning. The user must absolutely not be able to interact with or navigate to the disabled background workspace38.
• Standard Exit Methods: The dialog must support standard exit methods, specifically mapping the Escape key to close or cancel the operation safely41.
• Focus Restoration: Upon closing the recovery dialog or completing the wizard, programmatic focus must be returned exactly to the UI element (e.g., the menu button) that originally triggered it. This prevents screen-reader users from losing their spatial context within the complex DOM structure40.

ARIA Roles and Modal Semantics

• Alert Dialogs: For critical data-loss warnings and Emergency Recovery panes, the container element must utilize role="alertdialog". This distinct role forces assistive technologies to interrupt their current reading queue and announce the critical message immediately39.
• Standard Dialogs: The Backup and Restore wizards, which are procedural rather than urgent, must utilize role="dialog"39.
• Inert Backgrounds: To ensure screen readers do not read the visually obscured background content, the modal container must include aria-modal="true". This attribute natively signals to the accessibility tree that background content is inert, superseding the need for legacy aria-hidden implementations on background wrapper divs39.
• Accessible Naming: Every recovery modal must have an aria-labelledby attribute pointing directly to its visible heading element. This ensures users utilizing screen readers understand the modal's exact purpose immediately upon focus, without having to manually explore the container's contents39.

Failure-State Diagrams in Prose

The robustness of the resilience model is best illustrated by mapping it against distinct, catastrophic failure narratives. Narrative 1: The Abrupt Power Failure

1. State: The user is actively typing a massive research document. The system has completed a Normal Local Save to the database using durability: "strict" one second prior.

2. Trigger: The physical machine loses power. The browser process is killed instantly, halting all scripts.

3. Boot Phase: The machine restarts. The user opens the browser and navigates to the application.

4. Detection: Upon initialization, the application reads its IndexedDB configuration store. It finds an interrupted-boot flag set to true, indicating the previous session did not shut down gracefully.

5. Mitigation: The application queries the local database for orphaned save states and compares timestamps against the last known stable Checkpoint.

6. Resolution: The Emergency Recovery dialog (role="alertdialog") renders over an empty workspace. It presents the exact document state from one second prior to the crash. The user clicks "Save Recovered Documents," and the workspace loads seamlessly, losing effectively zero data.

Narrative 2: The Browser Quota Exhaustion

1. State: The user attempts to import a massive folder containing hundreds of high-resolution embedded images into their workspace.

2. Trigger: The operating system denies the write request because the disk is nearly full. The browser throws a QuotaExceededError.

3. Detection: The global IndexedDB error handler catches the exception. The duplication transaction is immediately aborted by the database engine, preventing half-written, corrupted file structures.

4. Mitigation: The application polls navigator.storage.estimate() and confirms 0 bytes of available headroom.

5. Resolution: The active Undo/Redo stack remains perfectly intact. The system displays the "Low Disk Space" property sheet. It locks the workspace from further additions until the user navigates to System Tools, exports a Backup, and deletes older Checkpoints to free up space.

Narrative 3: The Corrupted Import Interruption

1. State: The user initiates a Restore Wizard using a highly valuable, historical .zip backup file.

2. Trigger: The user impatiently closes the laptop lid halfway through the progress bar. The operating system suspends the browser, breaking the file stream.

3. Detection: Upon waking, the IndexedDB transaction times out and raises an abort signal.

4. Mitigation: Because the entire import was being written strictly to a temporary staging namespace, the primary workspace pointer was never modified.

5. Resolution: The system automatically drops the corrupted staging namespace upon waking. The primary workspace remains entirely unaffected. The UI logs a standard status message: "Restore Failed: Connection Interrupted," allowing the user to simply try again.

Phased Implementation Priorities and Acceptance Criteria

To systematically deploy this architectural model without destabilizing the current baseline functionality, engineering should follow a phased, incremental rollout schedule.

Phase 1: Core Transactional Safety and Durability

• Priority: Implement atomic IndexedDB transactions for all save and import operations. Configure databases with durability: "strict" to prevent power-loss corruption.
• Acceptance Criteria: A synthetic test simulating a browser process kill (SIGKILL) during a 1GB import payload results in zero bytes of corrupted or half-written state in the primary database upon reboot.

Phase 2: Session Resilience and Hierarchical Checkpoints

• Priority: Deploy the hierarchical Checkpoint engine (15-min, daily, weekly) and the automated pruning logic. Implement the "Previous Versions" and "Recover Documents" UI panels.
• Acceptance Criteria: Storage telemetry (strictly internal to the local environment) verifies that older checkpoints are successfully deleted according to the Grandfather-Father-Son schedule, ensuring that disk usage plateaus rather than growing infinitely over simulated months of usage.

Phase 3: Concurrency and Edge Case Defense

• Priority: Integrate the Web Locks API for multi-tab leader election and the BroadcastChannel for view synchronization. Implement navigator.storage.persist() requests on boot.
• Acceptance Criteria: Opening the application in three tabs simultaneously results in exactly one read-write Leader and two gracefully degraded, perfectly synchronized read-only Followers. Modifying a document in the Leader tab reflects in the Follower tabs within 100 milliseconds.

Phase 4: Wizard UX and WCAG Accessibility

• Priority: Construct the Backup/Restore wizards and the Emergency Recovery pane. Implement all WCAG 2.1 modal semantics (aria-modal, role="alertdialog", focus trapping).
• Acceptance Criteria: The entire Backup and Restore process can be completed successfully using only a keyboard and an industry-standard screen reader (e.g., NVDA or VoiceOver). The focus must remain trapped within the wizards, and the close action must reliably return focus to the invoking menu item.

Works cited

1. Storage quotas and eviction criteria \- Web APIs \- MDN Web Docs, https://developer.mozilla.org/en-US/docs/Web/API/Storage\_API/Storage\_quotas\_and\_eviction\_criteria

2. Updates to Storage Policy \- WebKit, https://webkit.org/blog/14403/updates-to-storage-policy/

3. The Browser Storage API \+ Cheat Sheet | by Tanvi Dadwal | Medium, https://medium.com/@tanvidadwal799/the-browser-storage-api-cheat-sheet-be6e4afff0c0

4. The Broadcast Channel API \- Client-Side JavaScript, https://blog.carlosrojas.dev/the-broadcast-channel-api-bf1c6f9f850c

5. Real-time React: Syncing State Across Browser Tabs, https://dev.to/childrentime/real-time-react-syncing-state-across-browser-tabs-hn5

6. Persistent storage | Articles \- web.dev, https://web.dev/articles/persistent-storage

7. Does navigator.storage.persist() only protect against data removal in, https://stackoverflow.com/questions/78474823/does-navigator-storage-persist-only-protect-against-data-removal-in-the-case-o

8. How Word's autorecovery process works \- Litera Support, https://support.litera.com/article/How-Word-s-autorecovery-process-works

9. Recover Unsaved Word Document: AutoRecover Path \+ 6 Methods, https://gentext.ai/errors/recover-unsaved-document/

10. Recover Unsaved Word, Excel and PowerPoint Files: Step-by-Step, https://www.hp.com/us-en/tech-takes/software/how-to/recover-unsaved-word-excel-powerpoint-files.html

11. Microsoft Word \- Recovering Unsaved Documents, https://kb.siue.edu/149077

12. Understanding System Backup and Restore Functions \- Techietory, https://techietory.com/os/understanding-system-backup-restore-functions/

13. DIY Database Clones \- SQLServerCentral, https://www.sqlservercentral.com/articles/diy-database-clones

14. The Smart Way to How to Set Restore Point in Windows — How To, https://cloud.motorsport.unibo.it/article/the-smart-way-to-how-to-set-restore-point-in-windows

15. What can I do offline in Figma?, https://help.figma.com/hc/en-us/articles/360040328553-What-can-I-do-offline-in-Figma

16. Building a local-first web application with Bun, React, Tailwind CSS, https://laidrivm.com/how-i-built-mellon-part-1

17. System Design: Real-Time Collaborative Editor \- Cracking Walnuts, https://crackingwalnuts.com/post/collaborative-editor-system-design

18. File recovery \- Obsidian Help, https://obsidian.md/help/plugins/file-recovery

19. How I synchronize and backup my Obsidian Notes \- Sébastien Dubois, https://www.dsebastien.net/how-i-synchronize-and-backup-my-obsidian-notes/

20. MMoMM-org/obsidian-archivist \- GitHub, https://github.com/mmomm-org/obsidian-archivist

21. Oppsyncer – Obsidian Plugin, https://www.obsidianstats.com/plugins/obsyncer

22. Undo and Redo Support for Replicated Registers \- arXiv, https://arxiv.org/html/2404.11308v1

23. Undo and Redo Support for Replicated Registers \- arXiv, https://arxiv.org/pdf/2404.11308

24. Advancing Big Data Analytics and Management with Design Patterns, https://arxiv.org/pdf/2410.03795

25. Persistent Iterators with Value Semantics \- arXiv, https://arxiv.org/pdf/2604.14072

26. Storage Buckets \- GitHub Pages, https://wicg.github.io/storage-buckets/explainer.html

27. Your Browser Has Storage Buckets Now, and They Are Not What, https://blog.isdevs.cv/browser-storage-buckets-api

28. Indexed Database API \- W3C, https://www.w3.org/TR/2011/WD-IndexedDB-20111206/

29. Indexed Database API \- W3C, https://www.w3.org/TR/2011/WD-IndexedDB-20110419/

30. Indexed Database API \- W3C, https://www.w3.org/TR/2010/WD-IndexedDB-20100819/

31. IndexedDB Tutorial for Beginners: A Comprehensive Guide with, https://medium.com/@kamresh485/indexeddb-tutorial-for-beginners-a-comprehensive-guide-with-coding-examples-74df2914d4d5

32. Not all storage is created equal: introducing Storage Buckets | Blog, https://developer.chrome.com/docs/web-platform/storage-buckets

33. CLI-Anything: Towards Agent-Native Computer Use \- arXiv, https://arxiv.org/html/2606.03854v1

34. https://www.w3.org/TR/web-locks/

35. Web Locks API \- MDN Web Docs \- Mozilla, https://developer.mozilla.org/en-US/docs/Web/API/Web\_Locks\_API

36. Angular : Cross-Tab Sync with BroadcastChannel API & Web Locks, https://medium.com/@piyalidas.it/angular-cross-tab-sync-with-broadcastchannel-api-web-locks-api-ac31eff0a947

37. Web Content Accessibility Guidelines (WCAG) 2.1 \- W3C, https://www.w3.org/TR/WCAG21/

38. Understanding Success Criterion 2.1.2: No Keyboard Trap | WAI | W3C, https://www.w3.org/WAI/WCAG21/Understanding/no-keyboard-trap

39. Mastering Accessible Modals with ARIA and Keyboard Navigation, https://www.a11y-collective.com/blog/modal-accessibility/

40. Accessible Modal Dialog a Guide to WCAG Compliance, https://www.adacompliancepros.com/blog/accessible-modal-dialog

41. Accessible Modal Dialogs: Focus Trapping and Screen Reader, https://testparty.ai/blog/modal-dialog-accessibility

42. Dialog (Modal) Pattern | APG | WAI \- W3C, https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/