diff --git a/clients/cascades-tucson/reports/2026-06-17-power-outage-incident.md b/clients/cascades-tucson/reports/2026-06-17-power-outage-incident.md
index 4678c943..579edbc7 100644
--- a/clients/cascades-tucson/reports/2026-06-17-power-outage-incident.md
+++ b/clients/cascades-tucson/reports/2026-06-17-power-outage-incident.md
@@ -91,6 +91,20 @@ restore from on-box auto-backups, eliminating the duplicate dhcpd, **resetting +
 5. **Optional monitoring:** alert on DHCP-not-completing / duplicate-dhcpd / mass device-disconnect
    so a future event is caught in minutes.
 
+## Post-Recovery Casualties / Lessons (updated 2026-06-18)
+
+- **Kitchen thermal printer (iPad POS ticket printer)** — reported "disconnected from the network"
+  and would not print the morning after. Root cause: it powered up **during the DHCP-down window**
+  of the recovery (duplicate dhcpd + 2nd-floor switch not passing offers), never got an IP, and
+  cached a disconnected state without retrying once the network was healthy. **Power-cycling the
+  printer** forced a fresh DHCP request against the now-healthy network and it resumed printing
+  (confirmed printing iPad tickets). Not a printer or network fault — a device that needed a manual
+  kick post-recovery.
+- **Recovery-checklist item:** after a network/power outage, **power-cycle any device that booted
+  during the DHCP-down window (printers, POS, IoT, cameras, appliances)** — they frequently do not
+  re-acquire DHCP on their own even after the network is restored. Sweep for stragglers proactively
+  rather than waiting for user reports.
+
 ## Reference Information
 
 - **pfSense:** `192.168.0.1`, Plus 25.07-RELEASE, ZFS. WAN: Cox (`igc0`, 184.191.143.x). LAN: `igc1`