==============================
Conflict Resolution Protocol
==============================

Nube ensures data preservation is absolute. This document outlines the conflict detection logic and the resolution strategy used by the SyncManager.

Core Axiom
----------
"Data Preservation is Absolute." Under no circumstances must a remote change be overwritten by an unaware local change.

Detection Logic
---------------
#. **Calculate Hash:** ``Hash(Local_File)``
#. **Identify Basis:** ``Parent_Hash`` (the state of the local file at the time editing began).
#. **Check Remote Head:**
   - If ``DAG_Head == Parent_Hash``: Clean Write (fast-forward update of the remote reference).
   - If ``DAG_Head != Parent_Hash``: **CONFLICT** (divergent modifications detected).

Traceability: Implements `[FUNC-SYNC-FABRIC]` and `[FUNC-DYNAMIC-SHARING]`.
Identifier: `[TECH-CONFLICT-CRP]`

Resolution Strategy (The "Sidecar")
-----------------------------------
When a conflict is detected:
#. **Upload:** The ``Local_File`` content is uploaded immediately to the blockstore.
#. **Rename (Local):** The local filesystem file ``File A.ext`` is renamed to ``File A (Conflict [User] [Timestamp]).ext``.
#. **Download:** The ``DAG_Head`` (remote version) is downloaded and written to ``File A.ext``.
#. **Notify:** A real-time notification is sent via the SSE broker to alert the user via the Web UI.

The "Zombie" Edge Case
----------------------
If a node crashes while holding a lock on a shared directory/file, upon daemon restart:
- The client attempts to acquire the lock.
- The lock request is denied if the file has been modified by another peer in the meantime.
- The client triggers the Sidecar Strategy immediately to prevent data loss.