diff --git a/work/projects/cpm-web-extension-repro-and-fix-2026-10-08.md b/work/projects/cpm-web-extension-repro-and-fix-2026-10-08.md
index 5813268f..af14062c 100644
--- a/work/projects/cpm-web-extension-repro-and-fix-2026-10-08.md
+++ b/work/projects/cpm-web-extension-repro-and-fix-2026-10-08.md
@@ -200,6 +200,13 @@ cd SharedPackages/WebExtensions && CPM_REPRO=1 swift test --filter CPMReproBackg
 - Чем реально вызван старт дольше 4 с на устройствах, неизвестно. Кандидаты: конкуренция за CPU с загружаемой вкладкой, запуск процесса без prewarm на iOS, низкий приоритет процесса extension (RunningBoard), занятый Network-процесс. Мерить на iPhone: от wake до первого `recv init`.
 - Speculative fix: (1) будить background заранее — при старте навигации или при выходе приложения на передний план, без блокировки; (2) не эскалировать в M4 и не рестартовать, пока background view моложе ~15 с; (3) телеметрия: возраст background view в секундах на момент сбоя и задержка позднего ответа на recovery-пикселе; (4) опционально держать background живым, пока приложение на переднем плане (цена — память одного WebContent-процесса).
 
+**Сигналы готовности background (тест `testReadinessSignalsDuringSlowWake`, worker стартует 5 с):**
+- `isLoading=false` у background view через 0,11 с — бесполезен: страница загружается задолго до worker'а.
+- `loadBackgroundContent` completion пришёл через 5,096 с, сразу после выполнения кода worker'а верхнего уровня («prelude evaluated» на 5,08 с). Это точный сигнал. Вызов сам будит выгруженный background.
+- Первое нативное сообщение worker'а (`getResourceIfNew`) — на 5,088 с. Тоже точный сигнал, менять расширение не нужно.
+- SPI для готовности нет: у `WKWebExtensionContext` из относящегося к background есть только `_backgroundWebView`, `_backgroundContentURL`, `isLoaded` (это контекст, не background) и `loadBackgroundContentWithCompletionHandler:`.
+- В диагностике нет числа вкладок и числа загружающихся вкладок; гипотезу «много вкладок → медленный старт» проверить нечем.
+
 **Стабильный `baseURL` (ветка `alex/cpm-stable-base-url`, не закоммичено): оценка.**
 - Объясняет только подгруппу «после load/reload» (~¼ iOS, ~15% macOS группы 1) и, вероятно, первый сбой после M4. Основная часть (пробуждение после idle) не затронута: чистка идёт только в `load()`.
 - Изменение: `context.baseURL = webkit-extension://<uniqueIdentifier>/`, где `uniqueIdentifier` = `UUID()` на установку/обновление (`WebExtensionManager+EmbeddedExtensions.swift:157`).