Replace draft with full manual (docs-as-code, colors, logo, versioning)

docs/user-guide/updating.md

@@ -0,0 +1,46 @@
+# Keeping the will up to date
+
+An inheritance transaction spends specific UTXOs. If those UTXOs change, the transaction the Will-Executors are holding becomes invalid — so the will has to be rebuilt.
+
+The plugin handles this for you: **every time you close Electrum it checks your balance and UTXO set**, and if something changed it asks you to refresh the will. You confirm the signature; it never signs on your behalf.
+
+This is what makes it practical to use an inheritance-ready wallet for everyday transactions.
+
+## What triggers a refresh
+
+- You receive funds.
+- You spend funds.
+- You add, remove, or edit an heir.
+- You change the delivery date.
+
+## Postponing vs anticipating
+
+The two directions are not symmetric, and the difference has a real cost:
+
+=== "Anticipating (earlier date)"
+
+    Bringing the delivery date **forward** is cheap. The plugin signs a new inheritance with an earlier locktime and sends it to the Will-Executors. Because it becomes valid sooner, it supersedes the previously distributed transaction — **no on-chain fee**.
+
+    This is also how balance and heir changes are handled: the will is anticipated by one day and redistributed, without invalidating the old one on-chain.
+
+=== "Postponing (later date)"
+
+    Pushing the delivery date **back** requires invalidating the committed coins **on-chain first**. Otherwise a Will-Executor still holding the old, earlier-locktime transaction could broadcast it and execute the inheritance too early.
+
+    That invalidation is a real Bitcoin transaction: you sign it and it costs a **miner fee**.
+
+!!! tip
+    If you expect to adjust the date often, plan for it: a rolling deadline that you re-anticipate is cheaper than repeatedly postponing.
+
+## Watch-only copies on other devices
+
+If you monitor the same wallet from another device using its public key (Zpub/Xpub), funds arriving there are **not** added to the inheritance automatically. Open the wallet in Electrum with the plugin so it can pick up the new UTXOs and re-send the updated will to the Will-Executors.
+
+!!! danger "The same seed on multiple devices invalidates the inheritance"
+    Using the same seed on more than one device is strongly discouraged in general. With BAL it has a specific consequence: spending even a single satoshi from the other device changes the wallet's UTXO structure, and the nodes will **discard the inheritance transaction** when the Will-Executors try to broadcast it.
+
+## How often to renew
+
+Renewing is not strictly required, but it is recommended roughly **every 2–3 years**. A practical approach is a rolling deadline — "always five years from today" — refreshed at regular intervals.
+
+Renewing serves two purposes: it lets you include Will-Executors that joined the network in the meantime (and drop the ones that shut down), and it picks up future protocol changes.