[2026-10-15] eagle: work/projects/cpm-status-2026-10-15.md

work/projects/cpm-status-2026-10-15.md

@@ -239,3 +239,26 @@ Harness позволяет отдельно выбирать controller вкла
 Оба 35-секундных документа теперь используют разные URL image. Ожидания изменены по наблюдению первого прогона: здоровый длинный документ — no failure; потеря dashboard — stuck с живой view, не P5. Расширен test-only background trace на все типы autoconsent-сообщений, чтобы установить, какое сообщение повторно будит worker на finish.
 
 Watcher больше не удерживает WKWebView через await, а idle-helper требует и освобождения background в WebKit, и dealloc по recorder. Повтор пяти новых/уточнённых проверок: `p5-refined-and-controls.log`.
+
+### Здоровый startup-контроль подтверждён
+
+`testCurrentControllerBeforeContextLoadRemainsHealthy` — зелёный, 1.190 с: вкладка с правильным controller проходит стартовый gate, получает initResp и скрипты, initialization_failed=0. Одной ранней загрузки контекста для P6 в этом сценарии недостаточно.
+
+Повтор one-wake listener подтвердил восстановление и отсутствие stuck. Остался только ошибочный assertion формата счётчика: pixel `bg_view_creations` для трёх view равен `3_to_5`, а не строке `3`. Проверка заменена на raw `backgroundWebViewCreateCount == 3`; будет повторена. Расширенный trace действительно показывает дополнительные `report`/`eval` после init — проверяю их связь с повторным пробуждением длинного документа.
+
+### P5 с исправными tab/controller/scripts — воспроизведён
+
+**`testNoRuntimeListenerMetadataFromFirstStartupMatchesP5` зелёный, 70.149 с.** Пропуск runtime listener с первого старта, две реальные idle-выгрузки (между ними explicit background load), затем две навигации дали actual stuck:
+`load>view>proxy_on>dealloc>view>proxy_on>dealloc`, view=false, creations=2, context/tab/controller/scripts=true, errors=none, network_restarted=false. Content script отправляет init; новые view не создаются. После разрешения регистрации listener в установленной тестовой копии скрипта, explicit background load и навигации получен initResp.
+
+Это соответствует P5 с внешне исправной вкладкой. **Доказан механизм пустых listener metadata при test-only инъекции; естественная потеря metadata в приложении/WebKit не найдена.** В отличие от него, одноразовый пропуск listener после здорового старта восстанавливается на следующем wake.
+
+**Два долгих документа с потерянными dashboard** после устранения image-cache — зелёная отрицательная проверка, 80.181 с: оба load действительно по 35 с, в обоих документах есть initResp, production monitor получает stuck, но в его snapshot view=true и цепочка заканчивается `view>proxy_on`. Это воспроизводит сбой диагностического канала, но **не P5**. Здоровый контроль ещё выполняется. Лог: `p5-refined-and-controls.log`.
+
+### Долгие документы: повтор завершён
+
+Здоровый контроль с двумя разными 35-секундными image — зелёный, 70.683 с: оба документа получили initResp, initialization_failed=0 и stuck=0. На finish background снова просыпается: trace показывает `recv report` и `recv eval` примерно на 35.39 с после `background none` на 32.35 с. Таким образом, в проверенном сценарии длинная загрузка сама по себе не даёт P5.
+
+Повтор пяти тестов завершён: четыре зелёных, один красный исключительно из-за ранее описанного сравнения bucket со строкой «3» (исправлено). Начат финальный прогон оставшихся сценариев и исправленного assertion: `p5-p6-final-regressions-and-stall.log`.
+
+Добавлен десятый эксперимент `testMainActorStallDelaysActualFailureSnapshots`: после реального initResp искусственно теряется dashboard, затем test host main actor дважды блокируется на 35 с при ожидающем production timeout. Тест требует actual failures/stuck и восстановления; совпадение P5 отдельно записывается как `matchesP5`, а не предполагается. Это исследование задержанного выполнения host callbacks, **не реальная iOS suspend/resume**.