diff --git a/applications/PoP/docs/perf_l13_room23.md b/applications/PoP/docs/perf_l13_room23.md
index b0e3dc0..6c1042e 100644
--- a/applications/PoP/docs/perf_l13_room23.md
+++ b/applications/PoP/docs/perf_l13_room23.md
@@ -237,3 +237,35 @@ memory `blit_cost_model`), а 16-битная арифметика в стеко
 
 Существующая страховка уже есть и остаётся: `pop_blit_b` уводит кадр с
 `img[1] | img[3] != 0` на общий путь `blit_b_oversize`.
+
+**Регресс после дня оптимизации 11/15 (`d0ac4b1`, 2026-08-19), 2367 кадров:**
+
+| максимум по секции | эталон `mob-order-B-done` | сейчас | разница |
+|---|---:|---:|---:|
+| работа | 913 848 | **911 862** | −1 986 |
+| синяя | 159 810 | **149 106** | −10 704 |
+| зелёная | 440 418 | **436 494** | −3 924 |
+| циан | 393 000 | **382 770** | −10 230 |
+
+Период: **3 растра в 2341 кадре, 4 в 23, 5 в 2** — как в эталоне.
+
+Почему сумма минусов по фазам не равна минусу по работе: максимумы разных
+фаз достигаются В РАЗНЫХ КАДРАХ (пик синей — не тот кадр, где пик зелёной),
+а «работа» здесь — максимум СУММЫ, а не сумма максимумов.
+
+Что из правок 11/15 сюда дошло: P16 и P2b дали синюю и циан (они про
+проверки и луч видимости, а те работают в любой сцене), HEAL-WIDTH дал
+зелёную (плита 64 → 58 на шести heal'ах кадра).
+
+**Зелёная по-прежнему выше растрового кадра** (436 494 против 430 000).
+Главный оставшийся кандидат именно для этой сцены — **P9 (G8)**: при
+падении плиты помечаются ДВА тайла, и соседний перезапекается целиком и
+повторно (`draw_tile` соседа дважды на одну пометку), хотя потревожены у
+него только левые 28 пикселей.  При шести падающих плитах это умножается
+на шесть.
+
+**ВАЖНО ДЛЯ ПРОЦЕССА.**  Этот прогон вскрыл регрессию, которую не поймали
+ни хост-тесты, ни сцена 11/15: гейт `loose_any` (позиция P5) не взводился
+в `check_fall_flo`, и плиты уровня 13 дрожали, не падая.  Сцену 13/23 надо
+прогонять после КАЖДОЙ правки loose-механики, а не только когда меняешь её
+сознательно.