diff --git a/CHANGELOG.md b/CHANGELOG.md
index 6fc7b7e..b243e8f 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -1654,3 +1654,360 @@ behaviour is reintroduced).
**Outcome:** DONE (delivered as test ZIP v0.5.2; commit only after the owner
confirms the ZIP works, especially that in BASIC the Check Alive is visible,
read-only even with "Panel editable Date and Fee" on, and shown as a Date).
+
+---
+
+## 27. v0.5.3 - BASIC mode: build the will against "now" (not Check Alive) + clearer "cannot build" message
+
+**Date:** 2026-07-04
+
+**Goal (owner request, two related fixes):**
+
+1. In BASIC mode, pressing Check (or rebuilding after a change) could refuse to
+ (re)build the will and show "Balance is too low, or CheckAlive is in the
+ past. Skipped", even with a healthy balance. Root cause found by tracing the
+ real code with the owner: will construction filters heirs by
+ `delivery_time > from_locktime`, and `from_locktime` is `date_to_check` = the
+ Check Alive. In BASIC the Check Alive is hidden and NOT editable, so when its
+ (fixed) default ends up LATER than the delivery time, every heir is excluded
+ and the will cannot be built. The Check Alive must never govern construction
+ in BASIC.
+2. The "Skipped" message itself was misleading: it claimed the Check Alive was
+ "in the past", whereas the real blocking condition is the opposite - the
+ Check Alive is LATER than the delivery time.
+
+**What changed:**
+
+- `bal/gui/qt/window.py` (`build_will`): the `from_locktime` passed to
+ `get_transactions` is now `datetime.now().timestamp()` when
+ `is_basic_mode()` is true, instead of `self.date_to_check` (the Check Alive).
+ In BASIC an heir is kept as long as its delivery time is in the future,
+ independently of the non-editable Check Alive. ADVANCED mode is unchanged
+ (still uses `date_to_check`). Deliberately scoped to CONSTRUCTION only:
+ `check_will_expired` / `check_amounts` / `is_will_valid` still use
+ `date_to_check` exactly as before, keeping the change targeted and low-risk
+ (the broad `date_to_check` rewrite tried in the discarded v0.5.4 line is NOT
+ reintroduced).
+ - Known, owner-accepted limitation: a delivery time equal to "today" (same
+ instant) may still not build, because `now()` includes the current time of
+ day. The owner will test this edge case separately.
+- `bal/gui/qt/dialogs.py`: replaced the misleading build-failure message with
+ the owner-approved wording: "Could not build the will. Possible reasons: the
+ Check Alive date is later than the delivery time (it must be earlier), the
+ balance is too low, or the heirs' shares are below the minimum. Skipped".
+ Text only; the message still appears under exactly the same condition
+ (`build_will()` returned nothing) as before.
+
+**Verification:**
+
+- Full test suite: `266 passed`, plus the same 2 pre-existing, unrelated
+ failures (stale `baltx_fees=100` expectation vs the v0.5.0 default of `20`).
+- `ruff`: no new errors (only pre-existing star-import noise and the
+ pre-existing `F841` at dialogs.py, both present in clean v0.5.0).
+- Windows behaviour (especially the delivery-time-equals-today edge case) to be
+ confirmed by the owner from the test ZIP.
+
+**Outcome:** DONE (delivered as test ZIP v0.5.3; commit only after the owner
+confirms it works, in particular that in BASIC the will now (re)builds and the
+new message is clear).
+
+---
+
+## 28. v0.5.4 - BASIC mode: Check Alive fully ignored at the root (date_to_check = now())
+
+**Date:** 2026-07-04
+
+**Goal (owner-approved, Option B "fix the root"):** After v0.5.3 fixed only the
+build path, the owner hit "No Heirs" on Check even with heirs present, in BASIC
+AND ADVANCED. A full map of every Check Alive usage (see the analysis
+spreadsheet) showed the Check Alive is read in ~11 places, all through the SAME
+value `self.date_to_check`, and only some were mode-gated. Fixing them one by
+one was whack-a-mole. Option B fixes the single root instead.
+
+**Root cause:** `self.date_to_check` (window.py, init_class_variables) was
+ALWAYS set to the Check Alive (threshold), in BASIC and ADVANCED. Every
+downstream check reads it: the build filter (get_locktimes/get_transactions),
+the heir count in check_willexecutors_and_heirs (source of "No Heirs" when
+delivery < Check Alive), check_will_expired, check_amounts, and the
+"locktime is lower than threshold" guard. In BASIC the Check Alive is hidden
+and not editable, so whenever its fixed value ended up later than the delivery
+time, these checks wrongly blocked the will.
+
+**What changed:**
+
+- `bal/gui/qt/window.py` (`init_class_variables`): in BASIC mode
+ `self.date_to_check` is now set to `datetime.now().timestamp()` instead of
+ the Check Alive. Every downstream check is therefore evaluated against "now"
+ (i.e. the Check Alive effectively does not exist in BASIC), while the
+ delivery time (locktime) is still fully enforced. ADVANCED mode is unchanged
+ and keeps using the user-controlled Check Alive. This single change covers
+ every point in the usage map at once.
+- `bal/gui/qt/window.py` (`build_will`): removed the now-redundant per-mode
+ branch added in v0.5.3 (it computed now() locally for the build filter).
+ Since `date_to_check` is already now() in BASIC from the root fix, build_will
+ simply passes `self.date_to_check` again - one source of truth, no duplicate
+ logic.
+- The CheckAliveError "you are alive -> postpone" guard was already skipped in
+ BASIC and is unchanged.
+
+**Why this differs from the discarded v0.5.4-era experiments:** the earlier
+broken attempt set date_to_check to `locktime - 2h` (odd and fragile). This
+sets it to plain `now()`, which is the natural meaning of "the Check Alive does
+not apply in BASIC".
+
+**Verification:**
+
+- Full test suite: `266 passed`, plus the same 2 pre-existing, unrelated
+ failures (stale `baltx_fees=100` expectation vs the v0.5.0 default of `20`).
+- `ruff`: no new errors (only pre-existing star-import noise).
+- Windows behaviour to be confirmed by the owner from the test ZIP: in BASIC
+ the "No Heirs" / "cannot rebuild" problems should be gone; ADVANCED unchanged.
+
+**Outcome:** DONE (delivered as test ZIP v0.5.4; commit only after the owner
+confirms it works in BASIC and that ADVANCED is unaffected).
+
+---
+
+## 29. v0.5.5 - ADVANCED defaults to RAW (1y/30d); Check Alive hidden again in BASIC
+
+**Date:** 2026-07-04
+
+**Goal (owner request, two GUI changes):**
+
+1. In ADVANCED mode, both the Delivery time and the Check Alive fields should
+ default to the RAW editor (showing "1y" / "30d") instead of the calendar
+ ("Date") editor.
+2. In BASIC mode, hide the Check Alive field again everywhere (revert the
+ v0.5.2 experiment that showed it read-only in the main window).
+
+**What changed (all in `bal/gui/qt/widgets.py`, GUI only):**
+
+- `BalTimeEditWidget.__init__` (default editor selection): in ADVANCED mode the
+ default editor is now forced to RAW (index 0) for both fields (Delivery time
+ and Check Alive both derive from this class). BASIC mode still forces the
+ Date editor (index 1) and hides the Raw/Date selector, as before. Because the
+ relative defaults already exist in plugin_base
+ (`default_will_settings_relative` -> locktime "1y", threshold "30d"), the RAW
+ editor opens showing "1y" / "30d". If the stored value happens to be an
+ absolute timestamp, the forced-RAW path substitutes the relative default so
+ the field never shows a bare timestamp number. The user can still switch to
+ Date manually (the selector is visible in ADVANCED); only the initial choice
+ changed.
+- `WillSettingsWidget.__init__` and `apply_user_type_visibility`: the Check
+ Alive (threshold) row is hidden in BASIC in BOTH layouts again (main window
+ and wizard), reverting the v0.5.2 "visible read-only in the main window"
+ behaviour.
+- `apply_editable_dates`: reverted the v0.5.2 threshold read-only special-case
+ back to the original single line (no longer needed now that the Check Alive
+ is hidden in BASIC).
+
+**Verification:**
+
+- Full test suite: `266 passed`, plus the same 2 pre-existing, unrelated
+ failures (stale `baltx_fees=100` expectation vs the v0.5.0 default of `20`).
+- `ruff`: no new errors (only pre-existing star-import noise).
+- Windows behaviour to be confirmed by the owner: in ADVANCED both fields open
+ in RAW showing 1y/30d; in BASIC the Check Alive is no longer visible anywhere.
+
+**Outcome:** DONE (delivered as test ZIP v0.5.5; commit only after the owner
+confirms it works).
+
+---
+
+## 30. v0.5.6 - Five small UX fixes (tooltips, empty-ics warning, revert forced RAW, message reword, Check Alive red highlight)
+
+**Date:** 2026-07-04
+
+**Goal (owner request, five items in one release):**
+
+1. Add a "Local time (not UTC)" note to the Delivery time AND Check Alive
+ tooltips.
+2. When the calendar export has no reminder events (delivery date too close or
+ already passed), warn the user and do NOT create an empty .ics file.
+3. Revert the v0.5.5 "always RAW in ADVANCED" default back to the 0.5.0
+ behaviour (default editor follows the stored value's format).
+4. Reword "Inheritance already executed (on blockchain)" to "An inheritance of
+ this wallet is already executed (on blockchain)".
+5. Highlight the Check Alive box with a soft red when it is later than the
+ delivery time (ADVANCED only).
+
+**What changed:**
+
+- `bal/gui/qt/widgets.py`:
+ - `ThresholdTimeWidget.help_text` and `LockTimeWidget.help_text`: appended a
+ note that the date/time is in the computer's Local time, not UTC (#1).
+ - `BalTimeEditWidget.__init__`: removed the v0.5.5 forced-RAW-in-ADVANCED
+ block; the default editor again follows the stored value (absolute number
+ -> Date, relative "1y"/"30d" -> Raw). BASIC still forces the Date editor
+ and hides the selector (#3).
+ - `WillSettingsWidget.on_locktime_change`: if the Check Alive timestamp is
+ >= the delivery time, tint the Check Alive box soft red (#FCE4E4, border
+ #E9A8A8) with an explanatory tooltip; clear it when the relationship is
+ valid. ADVANCED only (the field is hidden in BASIC) (#5).
+- `bal/gui/qt/dialogs.py`:
+ - `_ics_provider`: returns None when there are no reminder events (instead of
+ a header-only .ics), so the caller can warn (#2).
+ - Reworded the "inheritance already executed" message (#4).
+- `bal/gui/qt/calendar.py`:
+ - `_ensure_ics`: when the provider returns no content, show the warning
+ "No reminders were saved: the delivery date is too close (or already
+ passed)" and create no file (#2).
+
+**Verification:**
+
+- Full test suite: `266 passed`, plus the same 2 pre-existing, unrelated
+ failures (stale `baltx_fees=100` expectation vs the v0.5.0 default of `20`).
+- `ruff`: no new errors (only pre-existing star-import noise and a pre-existing
+ E401 in calendar.py, present in clean v0.5.0).
+- Manual check: `_ics_provider` returns events for a far delivery date and None
+ for a delivery date of "today" (0 days), confirming the empty-events warning
+ path.
+- Windows/visual confirmation (soft-red tint, tooltips, calendar warning) to be
+ done by the owner from the test ZIP.
+
+**Outcome:** DONE (delivered as test ZIP v0.5.6; commit only after the owner
+confirms it works).
+
+---
+
+## 31. v0.5.7 - Consistent Raw/Date default per mode, including runtime switch
+
+**Date:** 2026-07-04
+
+**Goal (owner request):** Make the Raw/Date editor default simple and
+consistent, both at startup and when toggling BASIC<->ADVANCED at runtime:
+ * BASIC -> always the Date (calendar) editor, selector hidden.
+ * ADVANCED -> RAW by default (showing "1y"/"30d"), selector visible so the
+ user can switch to Date manually; a manual Date choice must be
+ respected on later runtime mode switches (not forced back to RAW).
+
+**Background:** v0.5.6 (ToDo #3) had reverted to the value-driven default and
+left the runtime switch untouched, so switching ADVANCED->BASIC at runtime could
+leave a field stuck on RAW while the selector was hidden (and BASIC->ADVANCED
+did not restore RAW). This makes the behaviour explicit and symmetric.
+
+**What changed (all in `bal/gui/qt/widgets.py`):**
+
+- `BalTimeEditWidget.__init__`: default editor is now chosen by MODE, not by the
+ stored value's format: BASIC -> Date (index 1); ADVANCED -> RAW (index 0). In
+ ADVANCED, if the stored value is an absolute timestamp, the relative default
+ ("1y"/"30d") is loaded into the RAW editor so it never shows a bare number.
+- Added `self._user_picked_editor` flag plus `_on_user_picked_editor`, connected
+ to the combo's `activated` signal (fires only on real user interaction, not on
+ programmatic index changes). This records a manual Raw/Date choice.
+- `apply_user_type_visibility`: besides showing/hiding the selector, it now sets
+ the active editor on a runtime switch: BASIC -> always Date; ADVANCED -> RAW
+ unless the user had manually picked an editor, in which case their choice is
+ left untouched. Wrapped in try/except so a cosmetic editor switch can never
+ break mode toggling.
+
+**Verification:**
+
+- Full test suite: `266 passed`, plus the same 2 pre-existing, unrelated
+ failures (stale `baltx_fees=100` expectation vs the v0.5.0 default of `20`).
+- `ruff`: no new errors (only pre-existing star-import / E401 noise).
+- Windows/interactive confirmation (startup defaults + runtime BASIC<->ADVANCED
+ switch, including a manual Date choice being respected) to be done by the
+ owner from the test ZIP.
+
+**Outcome:** DONE (delivered as test ZIP v0.5.7; commit only after the owner
+confirms it works).
+
+---
+
+## 32. v0.5.8 - Fix: Check Alive red highlight no longer hides the up/down arrows
+
+**Date:** 2026-07-04
+
+**Problem (owner-reported, screenshot):** the soft-red highlight added in v0.5.6
+(ToDo #5) made the Check Alive box lose its native up/down spin arrows. Cause:
+the stylesheet set a `border` on the whole container; styling the border of a
+QDateTimeEdit / QAbstractSpinBox via stylesheet makes Qt stop drawing its native
+sub-controls (the spin arrows).
+
+**Fix (`bal/gui/qt/widgets.py`, `on_locktime_change`):** the warning styling now
+sets ONLY a `background-color` (no border), and scopes the rule to the inner
+editor widget types (`QDateTimeEdit, QLineEdit, QAbstractSpinBox`) instead of the
+whole container, so the tint still shows but the native up/down arrows are
+preserved.
+
+**Verification:**
+- Full test suite: `266 passed` (same 2 pre-existing unrelated failures).
+- `ruff`: no new errors.
+- Visual confirmation (arrows present + soft-red tint) to be done by the owner
+ from the test ZIP.
+
+**Outcome:** DONE (delivered as test ZIP v0.5.8; commit only after confirmation).
+
+---
+
+## 33. v0.5.9 - Clearer 3-point "could not build the will" message
+
+**Date:** 2026-07-04
+
+**Goal (owner request):** Now that the Check Alive box turns soft red when it is
+later than the delivery time (v0.5.6/v0.5.8), that mistake is hard to make, so
+the build-failure message was rewritten as a clearer, numbered 3-point list.
+
+**What changed (`bal/gui/qt/dialogs.py`, text only):** the message shown when
+`build_will()` returns nothing is now:
+
+ Could not build the will ! Possible reasons:
+ 1- the Balance of wallet is too low to cover the fees for miners and will executors,
+ 2- the Heirs' shares are below the minimum (Dust UTXO, less than 546 Satoshi),
+ 3- the Check Alive Date/Time is later than the delivery time (it must be earlier),
+ Skipped
+
+Line breaks use "\n", which the message panel converts to
(see the render
+that joins labels with
and replaces \n), so the three points appear on
+separate lines. Same trigger condition and warning colour as before; text only.
+
+**Verification:**
+- Full test suite: `266 passed` (same 2 pre-existing unrelated failures).
+- `ruff`: no new errors.
+- Visual confirmation of the multi-line layout to be done by the owner.
+
+**Outcome:** DONE (delivered as test ZIP v0.5.9; commit only after confirmation).
+
+---
+
+## 34. v0.5.10 - Pressing CHECK no longer resets a manual Date/RAW choice (Opzione 2)
+
+**Date:** 2026-07-04
+
+**Problem (owner-reported):** In ADVANCED, manually setting the Check Alive and
+Delivery time boxes to Date and then pressing CHECK snapped them back to RAW.
+
+**Cause:** v0.5.7 put the per-mode editor default (BASIC->Date, ADVANCED->RAW)
+inside `BalTimeEditWidget.apply_user_type_visibility`, which is invoked from
+`BalWindow.update_all()` - and update_all() also runs on every CHECK/refresh, not
+only on a real USER TYPE change. So CHECK re-applied the RAW default.
+
+**Fix (Opzione 2 - separate the two concerns):**
+
+- `bal/gui/qt/widgets.py`:
+ - `BalTimeEditWidget.apply_user_type_visibility`: reverted to flipping ONLY the
+ Raw/Date combo visibility (no editor change), so it is side-effect free on
+ every refresh/CHECK.
+ - New `BalTimeEditWidget.apply_user_type_editor_default`: holds the per-mode
+ editor default (BASIC->Date; ADVANCED->RAW unless the user picked manually).
+ - New `WillSettingsWidget.apply_user_type_editor_default`: applies it to both
+ the locktime and threshold boxes.
+- `bal/gui/qt/plugin.py`:
+ - New `_apply_editor_default_on_toolbars()` helper that reaches the WILL/HEIR
+ toolbars of every open window and applies the editor default.
+ - `on_user_type_change` now calls it ONLY on a real USER TYPE change (both the
+ normal switch and the revert-to-BASIC path), right before `update_all()`.
+
+**Result:** CHECK no longer touches the active editor (the transaction-list
+refresh in update_all() at `will_list_widget.update_will(...)` is untouched, so
+the list still updates on CHECK). The per-mode default is applied only when the
+user actually switches BASIC<->ADVANCED, and a manual Date choice is preserved.
+
+**Verification:**
+- Full test suite: `266 passed` (same 2 pre-existing unrelated failures).
+- `ruff`: no new errors.
+- Interactive confirmation (Date stays on CHECK; switch still applies defaults;
+ transaction list still refreshes) to be done by the owner from the test ZIP.
+
+**Outcome:** DONE (delivered as test ZIP v0.5.10; commit only after confirmation).