diff --git a/pump_controller_8_2_OLED_DONE/README.md b/pump_controller_8_2_OLED_DONE/README.md
index c501e44..360a7b2 100644
--- a/pump_controller_8_2_OLED_DONE/README.md
+++ b/pump_controller_8_2_OLED_DONE/README.md
@@ -267,6 +267,18 @@ STATUS: OK
 * События, произошедшие без Wi-Fi или при неудачной отправке, не буферизуются
   и не повторяются — webhook теряется, флаги `mainAlarmSent` /
   `emergencyActiveSent` выставляются независимо от результата POST.
+  Ретраи и очередь сознательно не реализованы: контроллер рассчитан на работу
+  и без отправки событий, автономность — штатный режим, а не отказ.
+* **Пауза мониторинга при старте без сохранённой сети.** `wm.autoConnect()`
+  поднимает портал настройки и блокирует `setup()` в цикле ожидания до
+  истечения `setConfigPortalTimeout(120)`. Пока `setup()` не завершён, `loop()`
+  не выполняется: дребезг не считается, аварии не формируются, выходы не
+  переключаются (они остаются в безопасном `LOW`, выставленном до Wi-Fi).
+  В установке, где сеть не настраивается никогда, эти 2 минуты повторяются
+  при каждом включении питания. Принято как есть; при необходимости лечится
+  `wm.setConfigPortalBlocking(false)` + `wm.process()` в `loop()` — с оговоркой,
+  что в неблокирующем режиме `setConfigPortalTimeout` не применяется и гасить
+  портал придётся своим таймером.
 * Логика аварии — «оба стоят»: остановка одного насоса штатной ситуацией
   не считается и никак не сигнализируется.
 * Webhook URL хранится в EEPROM в открытом виде и отдаётся веб-панелью всем,