diff --git a/docs/hendi_lockout_findings.md b/docs/hendi_lockout_findings.md
index 8b53e51..fb2a280 100644
--- a/docs/hendi_lockout_findings.md
+++ b/docs/hendi_lockout_findings.md
@@ -1,9 +1,9 @@
 # Hendi remote-control lockout findings
 
-Firmware under test: **v1.12** (`getSoftwareVersion()` / `I?`+`V?` via
-`components/actor/hendiCtrl.py`). Reproduced and verified on real hardware
-using `scripts/hendi_ctrl_app.py`'s `--trigger-error-state`, `--reset` and
-`--test-heater` flags.
+Reproduced and verified on real hardware using `scripts/hendi_ctrl_app.py`'s
+`--trigger-error-state`, `--reset` and `--test-heater` flags, across two
+firmware versions (`getSoftwareVersion()` / `I?`+`V?` via
+`components/actor/hendiCtrl.py`).
 
 ## Trigger
 
@@ -11,13 +11,16 @@ Calling `remoteEnable(True)` (`R1`) and then disconnecting/exiting without a
 matching `remoteEnable(False)` (`R0`) - i.e. an ungraceful disconnect while
 remote control is enabled - puts the device into a locked-out state.
 
-## Recovery attempts
+## Recovery attempts - v1.12 vs v1.14
 
-| # | Recovery method | Mechanism | Result |
+v1.14 flashed via `--update-firmware HendiCtrl_0114.srec`;
+`getSoftwareVersion()` confirmed `v1.14` afterward.
+
+| Recovery method | Mechanism | v1.12 (original) | v1.14 (firmware fix) |
 |---|---|---|---|
-| 1 | `--reset` (toggle DTR/RTS reset line) | Soft reset via serial control lines, no power loss | **Fails** - `remoteEnable(True)` still returns `HendiException("Communication error")` on the next connection |
-| 2 | `--reset` immediately followed by `--test-heater` in the *same* process/connection | Soft reset, then reuse the still-open serial connection | Succeeded once, but not reproducible across repeat isolated attempts - not a reliable recovery path |
-| 3 | Physical power cycle (device knob) | Full power-off/on of the unit | **Recovers** - `remoteEnable(True)` succeeds immediately afterward, heater sweep runs cleanly |
+| Plain reconnect, no `--reset` | Fresh serial connection only, no DTR/RTS toggle | **Fails** | **Fails** - unchanged, a bare reconnect alone still does not clear the lockout |
+| `--reset`, isolated process | Soft reset via DTR/RTS toggle, no power loss | **Fails** (one fluke recovery when combined with `--test-heater` in the *same* process/connection - not reproducible in isolation) | **Recovers** - reproducible across two independent trigger/reset/verify cycles |
+| Physical power cycle (device knob) | Full power-off/on of the unit | **Recovers** | Not retested on v1.14 (superseded by `--reset` working) |
 
 ## Symptom while locked out
 
@@ -29,7 +32,11 @@ remote control is enabled - puts the device into a locked-out state.
 ## Conclusion
 
 On firmware v1.12, only a physical power cycle clears the lockout; neither a
-serial soft-reset nor a fresh serial reconnect does. This is the behavior the
-planned firmware fix should address - a graceful-disconnect timeout, an
-explicit unlock command, or making the DTR/RTS reset line actually clear the
-lockout flag.
+serial soft-reset nor a fresh serial reconnect does reliably.
+
+**Firmware v1.14 fixes this partially**: a soft reset (`--reset`, i.e.
+toggling the DTR/RTS line) now reliably clears the lockout, confirmed across
+two independent trigger/reset/verify cycles - no physical power cycle
+needed. However, a plain reconnect *without* `--reset` still does not clear
+it, so the fix specifically ties recovery to the DTR/RTS reset line rather
+than to any new connection.