diff --git a/HISTORY/2026-08-14-session-log.md b/HISTORY/2026-08-14-session-log.md
index 6a9517e..3666f40 100644
--- a/HISTORY/2026-08-14-session-log.md
+++ b/HISTORY/2026-08-14-session-log.md
@@ -1221,3 +1221,21 @@ cert-expiration — чисто; единственный LB-сервис — ing
 3. Перепроверить: события кластера, логи vip-подов, /health с локали.
 4. Тест: внешний SQS-цикл с таймстемпами — проверить, ушёл ли период 31с.
 Риск: при рестарте vip-подов возможен краткий (секунды) флап ARP-анонса VIP.
+
+## 2026-08-15 — ПОЧИНКА БАГОВ ПЛАТФОРМЫ ВЫПОЛНЕНА
+
+**Баг 1 (leaderelection в удалённый ns 0a42bef3):** `kubectl rollout restart
+ds -n kube-vip shturval-vip` — после рестарта все 4 пода делают нормальные
+выборы лидера (lease ingress/kubevip-shturval-ingress-controller-controller),
+ошибок 0a42bef3 больше нет. Победил под на v8zq4, kube-vip обновил аннотацию
+vipHost: control-plane-xb699 → workers-vqphm-v8zq4 (VIP переехал штатно).
+
+**Баг 2 (provider без пулов):** нашёл, что provider читает ConfigMap kubevip
+из namespace **kube-system** (env KUBEVIP_NAMESPACE=kube-system), а там лежал
+ПУСТОЙ ConfigMap (130д, 0 данных) — изначальная недонастройка платформы.
+Добавил `cidr-global: 185.247.187.151/32` в kube-system/kubevip, удалил свой
+ошибочный CM в kube-vip, рестартнул provider. Результат: «Taking address from
+[cidr-global]», «Ensured load balancer», SyncLoadBalancerFailed прекратился.
+
+**Проверки после починки:** /health с локали — 200 (36–41мс). LB IP сервиса
+ингресса в статусе: 185.247.187.151 (ipMode VIP). Далее — нагрузочный тест.