From db62bd40e4aec1efaa59b10fe4cd796de68e38dc Mon Sep 17 00:00:00 2001 From: Alexey Martemyanov Date: Fri, 16 Oct 2026 20:16:37 +0600 Subject: [PATCH] [2026-10-16] eagle: work/projects/cpm-status-2026-10-15.md --- work/projects/cpm-status-2026-10-15.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/work/projects/cpm-status-2026-10-15.md b/work/projects/cpm-status-2026-10-15.md index 01691c0a..336d2129 100755 --- a/work/projects/cpm-status-2026-10-15.md +++ b/work/projects/cpm-status-2026-10-15.md @@ -900,3 +900,11 @@ Targeted unit suites: **170 PASS**, включая 5 новых manager tests (` `install-upgrade-repeat.xcresult`: install **10/10 PASS**, upgrade **4/10 PASS + 6/10 functional FAIL** (native dashboard и page initResp отсутствуют, настоящий first-failure snapshot). Это не teardown/инфраструктура. Первый общий 4/4 не подтверждает устойчивость этого режима. Логи failed upgrade показывают release навигации примерно через 5.0 s и общий failed probe около 9.1 s; worker fixture задержан ровно на 5000 ms, то есть без запаса относительно gate cap 5 s. Выбор правильного context unit-проверен, реальный overlap `[0,1,2,1]` подтверждён. Для установления точной причины добавлены обычные локальные debug logs `[CPM Background]` с request/callback временем и причиной release navigation wait. Они не меняют pixels/schema и не увеличивают cap. Следующий шаг — измерить реальный WK callback относительно deadline на том же 5 s fixture, прежде чем менять ожидания или утверждать, что проблема исправлена. Все 20 iterations и их JSON сохранены в `install-upgrade-repeat-evidence/`. + +### Причина граничных upgrade failures установлена по timestamp + +`upgrade-timing-visible.log`: ожидается именно **новый** context (UUID совпадает с новой extracted installation), но gate отпускает навигацию по `TimeoutError(timeout: 5.0s)` **до** WK callback. Измеренные callbacks 5.150336 s и 5.184716 s, соответственно через ~44 ms и ~97 ms после release. Это выход за предусмотренный бюджет 5 s, а не выбор старого context. На 5000 ms busy-loop ошибочно ожидался безусловный healthy first document: полный запуск WK дольше самого busy-loop. Strict assertions не ослаблены и timeout не увеличен. + +Для install/upgrade regression в пределах контракта выбран busy-loop **4500 ms** (временной запас на WK startup), с теми же требованиями native dashboard + page initResp без first failure. `CPM_APP_INTEGRATION_INSTALL_DELAY_MS=5000` сохраняет возможность повторить граничный/выходящий за бюджет эксперимент на той же сборке. Предел записан и в README: новая реализация, как #7379, не гарантирует первый документ, если startup не помещается в 5 s. Артефакты всех красных прогонов сохранены; нельзя представлять их как успешно исправленный режим. + +Финальный общий app-прогон и 10× повторы будут выполнены после пересборки с этим явным разделением contract regression и over-budget эксперимента. 170 unit-тестов с актуальной shared logic снова PASS (`unit-final-visible.log`), 16 Swift lint 0.