From 062ee43a575a4cfb2d5913ec40ee81aac9432f77 Mon Sep 17 00:00:00 2001 From: Alexey Martemyanov Date: Mon, 19 Oct 2026 23:10:24 +0600 Subject: [PATCH] [2026-10-19] eagle: work/projects/cpm-readiness-telemetry-tech-design-2026-10-15.md work/projects/cpm-status-2026-10-15.md work/projects/cpm-web-extension-code-guide-2026-10-09.md --- ...readiness-telemetry-tech-design-2026-10-15.md | 16 +++++++++++----- work/projects/cpm-status-2026-10-15.md | 16 +++++++++++----- .../cpm-web-extension-code-guide-2026-10-09.md | 16 +++++++++++----- 3 files changed, 33 insertions(+), 15 deletions(-) diff --git a/work/projects/cpm-readiness-telemetry-tech-design-2026-10-15.md b/work/projects/cpm-readiness-telemetry-tech-design-2026-10-15.md index de552bd8..2b74e137 100755 --- a/work/projects/cpm-readiness-telemetry-tech-design-2026-10-15.md +++ b/work/projects/cpm-readiness-telemetry-tech-design-2026-10-15.md @@ -546,12 +546,18 @@ P4 detection-only method прошёл в обоих успешных ON runs: la ## Проверка отчёта о трёх падениях late-startup app tests — 19 октября 2026 -Исходный screenshot: failed `testLateStartupIsDetectedWithRecoveryDisabledWithoutReload`, `testOverBudgetInstallRecoversFirstDocumentWithoutExtendingNavigationWait`, `testOverBudgetUpgradeRecoversFirstDocumentWithoutExtendingNavigationWait`; остальные 6 methods зелёные. Assertion text reviewer run не предоставлен, поэтому идентичность конкретных причин его трёх failures не утверждается. +Исходный screenshot: failed `testLateStartupIsDetectedWithRecoveryDisabledWithoutReload`, `testOverBudgetInstallRecoversFirstDocumentWithoutExtendingNavigationWait`, `testOverBudgetUpgradeRecoversFirstDocumentWithoutExtendingNavigationWait`; остальные 6 methods зелёные. Assertion text и macOS/Xcode reviewer run не предоставлены, поэтому идентичность конкретной причины его каждого failure не утверждается. На Virfield macOS 27 воспроизведены все три имени и найдены ошибки timing assumptions в harness. -Проверены published production `674bb809f2` и harness `d26a1c55d1`: оба shared scheme задают flags автоматически; ручной шаг включения late recovery не пропущен. Normal задаёт `CPM_APP_INTEGRATION=1`; disabled дополнительно задаёт оба DISABLE overrides=1 и выбирает ровно 6 recovery methods. На host macOS 26.7.1 / Xcode 27.1 исходный harness дал **3 PASS / 0 FAIL / 0 SKIP** для reported methods, затем полный disabled **0 PASS / 6 ожидаемых functional FAIL / 0 SKIP**, затем normal **9 PASS / 0 FAIL / 0 SKIP**. +**Опубликованный harness: `29da2c1587571e91f85915c35c8322f273e07eb0`, branch `codex/cpm-fix-init-loss-integration-tests`.** Обычный fast-forward push от `d26a1c55d1`; локальный чистый worktree `alex/cpm-fix-p1-p2` также fast-forward обновлён. Новые изменения затрагивают ровно три существующих файла: CPMAppIntegrationHarness.swift, CPMBackgroundRecoveryIntegrationTests.swift, README.md. Production PR #7379 остаётся на `674bb809f2`, base `alex/cpm-messaging-readiness-telemetry` (#7376); production files, flags/defaults, reload safeguards и 5-second navigation timeout не менялись. Production head — ancestor harness; полный diff harness относительно production по-прежнему содержит только 12 harness paths, без новых submodule changes. Оба shared schemes автоматически задают flags: normal `CPM_APP_INTEGRATION=1`; disabled дополнительно задаёт оба DISABLE overrides=1 и выбирает ровно 6 recovery methods. Ручной шаг включения late recovery в PR instructions не пропущен; текущие 10 шагов PR сохранены, README уточнён. -На чистой Virfield macOS 27.0 (26A428), Xcode 27.0 (27A266a), arm64 исходный harness дал normal **5 PASS / 4 FAIL / 0 SKIP**: edited-document и over-budget install истекали на 6.5-second first-document precondition; следующие P4-detection и over-budget upgrade падали с SIGINT. Disabled дал **0 PASS / 6 FAIL / 0 SKIP**, но часть падений была precondition/host failures, поэтому этот VM run не считается успешным отрицательным контролем. Пример normal install: policy callback 16:05:46.736120Z; fixture timeout 16:05:51.770356Z; didStart 16:05:51.806345Z — fixture бросил ошибку за 36 ms до окончания корректного пятисекундного gate, включив в свой бюджет холодную подготовку окна/WebKit. Unstructured navigation tasks не отменялись и не ожидались на пути ошибки, продолжая работу во время teardown перед SIGINT в следующих методах. +Исходный `d26a1c55d1` на host macOS 26.7.1 (25G241) / Xcode 27.1 (27A9275) дал: reported 3 methods **3 PASS / 0 FAIL / 0 SKIP**; полный disabled **0 PASS / 6 ожидаемых functional FAIL / 0 SKIP**; следующий normal **9 PASS / 0 FAIL / 0 SKIP**. На чистой Virfield macOS 27.0 (26A428), Xcode 27.0 (27A266a), arm64 исходный harness дал normal **5 PASS / 4 FAIL / 0 SKIP**: edited-document и over-budget install истекали на 6.5-second first-document precondition; следующие P4-detection и over-budget upgrade падали с SIGINT. Disabled дал **0 PASS / 6 FAIL**, но часть была precondition/host failures, поэтому этот исходный VM run не считается успешным отрицательным контролем. Пример normal install: policy callback 16:05:46.736120Z, fixture timeout 16:05:51.770356Z, didStart 16:05:51.806345Z — fixture бросал ошибку за 36 ms до release корректного пятисекундного gate, включив холодную подготовку окна/WebKit в общий бюджет. Незавершённые unstructured navigation tasks продолжали работу во время teardown перед следующими SIGINT. -В отдельной source copy подготовлен harness-only fix: перед late-startup сценарием прогревается реальное окно через ineligible about:blank, production coordinator waiter измеряется отдельно (5-second gate, прежний 1.5-second scheduler tolerance), page completion получает отдельный 15-second fixture budget, причём startup обязан оставаться pending при release gate/редактировании. Навигации используют structured async let для cancellation/join до teardown. Production timeout, flags и recovery-код не меняются. Четыре локальных late-startup/edited regressions после исправления: **4 PASS / 0 FAIL / 0 SKIP**, strict SwiftLint **0 violations**. Промежуточный VM run только с этими изменениями убрал precondition/SIGINT cascade и дал **6 PASS / 3 FAIL / 0 SKIP** ровно в трёх reported methods: при 8-second startup WebKit 27 доставил настоящие native dashboard и page initResp через ~3 секунды после окончания gate, до 4-second response deadline. Поэтому не было missing-response pixel/reload: первая страница была здоровой, ожидание обязательного recovery было ошибкой fixture. Повторный intermediate normal после disabled также дал **6 PASS / 3 FAIL**, app/test hashes до/после всех трёх запусков совпали; это не загрязнение flags предыдущей схемой. Дополнительный harness-only commit `8a27a69776`: late-startup delay 12 секунд (больше 5-second gate + 4-second response deadline), ожидание completion/detection до 10 секунд и явный assertFailed исходного probe; обычный P1 idle-wake остаётся 8 секунд. При первой 12-second локальной попытке recovery работало, но два over-budget tests проверяли P4 count до completion; после ожидания реального callback финальные 4 methods дали **4 PASS / 0 FAIL / 0 SKIP**. Gate elapsed install **5.00193 s**, upgrade **5.01807 s**; startup pending при release, finishCount=2 для обоих reload cases. P4-only detections=1, finishCount=1, без reload. Production limits и assertions результата не ослабляются. Первый полный 12-second VM run (`8a27a69776`) дал **7 PASS / 2 FAIL / 0 SKIP**: P4-only тест ошибочно запрещал поздний original response после уже зафиксированного таймаута; install проверял response_received сразу после reload finish (через ~38 ms), не ожидая dashboard delivery. В follow-up `0a6d90e4c0` P4 сохраняет обязательный исходный failed probe/detection=1/finishCount=1/no-reload, но допускает естественный поздний ответ. Recovery требует reload_started, затем ровно два finish, ACK уже нового документа и отдельное ожидание attributed response_received, с сохранением точного списка outcomes. Новые локальные четыре methods: **4 PASS / 0 FAIL / 0 SKIP**. Первый VM run окончательного `0a6d90e4c0` дал **8 PASS / 1 FAIL / 0 SKIP**: все три исходных reported methods и edited-document прошли, install/upgrade дождались обоих reload outcomes. Единственный FAIL — отдельный P2: после намеренно вызванного error 6 retry background PID 3001 также завершился настоящим 30-second error 6 (первое notification 16:36:14.455Z, повторное 16:36:44.468Z), затем same-document recovery timeout. Crash/OOM report в собранных логах не найден; причина второго WebKit load failure пока не установлена и не объявляется инфраструктурной. Все предыдущие VM normal attempts проходили P2. Исходный failed bundle сохранён (`vm-verified-first/normal.xcresult`). Контрольный repeat `0a6d90e4c0` на тех же физических binaries снова дал **8 PASS / 1 P2 FAIL / 0 SKIP**, с повторным error 6 на retry PID 3265 (16:40:38.693Z → 16:41:08.707Z); на 24-й секунде процесс был жив, sleeping, 0% CPU, stack sample не успел до его завершения. Console VM разблокирована/активна; доказанной причины повторного WebKit timeout нет. OFF → ON продолжается отдельно без перезаписи обоих failed normal bundles. Для отделения test-lifetime изменения от реального повторного WebKit failure поставлен контроль одного P2 на исходном published `d26a1c55d1` в той же VM. Несвязанное с тремя reported methods преобразование P2 Task→async let убирается из финального diff; исходная Task и WebKit timing P2 сохраняются, при этом late-startup navigation cleanup остаётся structured. Локальная/VM проверка этого уточнения ещё выполняется. Harness commits пока не опубликованы. Первые три reviewer-like failures не требуют ручного переключения remote flags. +Промежуточный вариант с прогревом окна, отдельным измерением реального coordinator waiter и structured late navigation cleanup убрал precondition/SIGINT cascade, но на VM дал **6 PASS / 3 FAIL**, затем disabled **0 PASS / 6 FAIL**, затем normal снова **6 PASS / 3 FAIL** на неизменных binaries. Ровно три reported methods требовали failure/recovery от здоровой страницы: при 8-second startup WebKit 27 доставлял настоящий native dashboard и page initResp через ~3 секунды после release gate, до 4-second response deadline. Поэтому отсутствие missing-response/reload было корректным поведением app. Late-startup fixture delay увеличен до **12 секунд**, чтобы пересечь и 5-second gate, и 4-second response deadline; обычный P1 idle-wake остаётся 8 секунд. Используется реальное приложение, AppDelegate/Tab/lifecycle coordinator, system WebKit, CPU delay в extracted test copy extension и настоящие ответы; ACK/ошибки/пиксели не фабрикуются. -Virfield lease `lease-671a00b65fc4efdfc9b0df677a0ff51f`, expiry `2026-10-19T17:49:35Z`; используются Apple Development signed host build и точные generated .xctestrun, private signing keys в VM не передавались. Первая transfer попытка пересеклась с Xcode build и завершилась rsync exit 23; она сохранена и не считается test run. Следующая stable copy успешно запустила baseline VM tests. Deep signature verification локального Debug build сообщает missing/invalid sealed resource в вложенном VPN helper PrivacyConfig.framework, при этом CPM app host запускается локально и на VM. Артефакты всех попыток: `/private/tmp/cpm-pr7379-three-late-failures-20261019/`; baseline VM raw xcresults сохраняются отдельно от финального fixed run. +Checkpoint `8a27a69776` включил эти harness fixes. Первая локальная 12-second попытка: **2 PASS / 2 FAIL**, оба over-budget cases проверяли P4 count до реального background completion; после ожидания callback локальные четыре methods дали **4 PASS / 0 FAIL**. Первый полный 12-second VM run: **7 PASS / 2 FAIL** — P4-only ошибочно запрещал естественный поздний original response после уже зарегистрированного timeout, а install проверял response_received через ~38 ms после reload finish без отдельного ожидания. Follow-up `0a6d90e4c0` сохраняет исходный failed probe, P4 detection=1, finishCount=1 и отсутствие reload при recovery OFF, но допускает поздний original response. Recovery требует reload_started, ровно два finish, ACK уже нового документа и отдельное ожидание attributed response_received с точным списком outcomes. Локальные четыре methods после этого: **4 PASS / 0 FAIL / 0 SKIP**. Несвязанный перевод P2 navigation Task→async let затем убран в `ddee0e5be0`: финальный P2 method сохраняет исходную Task и timing. Это ограничение diff, а не заявленный фикс повторного WebKit failure. Локальный отдельный P2 после возврата исходной Task: **1 PASS / 0 FAIL / 0 SKIP**. `29da2c1587` добавляет README-only описание оставшегося failure. Strict SwiftLint двух изменённых Swift files: **0 violations**, diff checks clean. + +**Финальный VM цикл на коде `ddee0e5be0` (published head `29da2c1587` отличается только README): normal 9 PASS / 0 FAIL → disabled 0 PASS / 6 ожидаемых functional FAIL → normal 8 PASS / 1 unexpected P2 FAIL; везде 0 SKIP.** Все три исходных reported methods и edited-document PASS в обоих normal runs. Disabled failures проверены по причинам: install/upgrade/slow wake не получают первый ответ в срок, P2 не восстанавливает исходный документ, late install/upgrade не выполняют automatic recovery; host crashes/setup errors не засчитаны как controls. Финальные measured gate waits: install **5.00827 s**, upgrade **5.01224 s**; после OFF соответственно **5.01076 s**, **5.00807 s**. При release startup оставался pending; оба recovery cases имеют finishCount=2 и оба reload outcomes. P4-only имеет detections=1, finishCount=1, без reload/recovery outcomes. App/test SHA-256 до/после всех трёх phases совпали и совпали с локальным payload; пересборки между phases не было. Полный green **9 → 6 expected red → 9** на финальной версии не подтверждён; последний enabled run действительно красный из-за P2. + +**Оставшийся P2: retry тоже иногда получает настоящий background-load error 6.** Два отдельных normal runs `0a6d90e4c0` дали **8 PASS / 1 P2 FAIL**, но тот же неизменный payload после disabled дал **9 PASS / 0 FAIL**. В первой failed попытке второй error 6 пришёл через 30 секунд после первого (16:36:14.455Z → 16:36:44.468Z, retry PID 3001); повтор дал 16:40:38.693Z → 16:41:08.707Z, PID 3265. Контроль единственного P2 на исходном published `d26a1c55d1` в той же VM также дал **0 PASS / 1 FAIL / 0 SKIP** с повторным error 6, поэтому явление воспроизводится и без новых late-startup fixes. Для baseline retry PID 3952 успешно сняты background/app stack samples: WebKit 22625.1.29.11.27, background footprint 11.3 MB, main thread в XPCServiceMain/xpc_main/NSRunLoop/Mach wait, 0% CPU; app main thread в XCTest/AppKit run loop. Эти стеки не показывают CPU busy-loop и совместимы с неустановившимся XPC/bootstrap connection, но точная root cause не доказана. Console VM была разблокирована/активна; crash/OOM report в собранных логах не найден. Failure не объявляется infrastructure-only и не игнорируется. Финальный normal после OFF снова поймал его; README явно считает это unexpected enabled-scheme failure, а не валидный отрицательный контроль. Production-изменений для второго error 6 в этой работе нет. + +Все raw xcresults, logs, JSON attachments, generated .xctestrun/flag environment, app/test hashes, export manifests и samples сохранены в `/private/tmp/cpm-pr7379-three-late-failures-20261019/`: `vm-baseline/`, `vm-eight-second-intermediate/`, `vm-twelve-intermediate/`, `vm-verified-first/`, `vm-confirmation/` (включая baseline-p2.xcresult и samples), `vm-final/`. SHA-256 manifests экспортированных VM bundles совпали с оригиналами; финальный экспорт проверен по **3820 files**. Локальные failed/positive attempts также сохранены отдельно. Первая transfer попытка пересеклась с Xcode build и завершилась rsync exit 23 до test execution; stable copy затем успешно запустила baseline. Deep signature verification локального Debug build сообщал missing/invalid sealed resource во вложенном VPN helper PrivacyConfig.framework; это не засчитано как причина reported failures. Использовался Apple Development signed host app/test build, guest signing identities отсутствуют, private signing keys в VM не передавались. Virfield lease `lease-671a00b65fc4efdfc9b0df677a0ff51f`, expiry `2026-10-19T17:49:35Z`; VM не удалялась без отдельного разрешения. diff --git a/work/projects/cpm-status-2026-10-15.md b/work/projects/cpm-status-2026-10-15.md index e8770d88..ea38b004 100755 --- a/work/projects/cpm-status-2026-10-15.md +++ b/work/projects/cpm-status-2026-10-15.md @@ -1374,12 +1374,18 @@ P4 detection-only method прошёл в обоих успешных ON runs: la ## Проверка отчёта о трёх падениях late-startup app tests — 19 октября 2026 -Исходный screenshot: failed `testLateStartupIsDetectedWithRecoveryDisabledWithoutReload`, `testOverBudgetInstallRecoversFirstDocumentWithoutExtendingNavigationWait`, `testOverBudgetUpgradeRecoversFirstDocumentWithoutExtendingNavigationWait`; остальные 6 methods зелёные. Assertion text reviewer run не предоставлен, поэтому идентичность конкретных причин его трёх failures не утверждается. +Исходный screenshot: failed `testLateStartupIsDetectedWithRecoveryDisabledWithoutReload`, `testOverBudgetInstallRecoversFirstDocumentWithoutExtendingNavigationWait`, `testOverBudgetUpgradeRecoversFirstDocumentWithoutExtendingNavigationWait`; остальные 6 methods зелёные. Assertion text и macOS/Xcode reviewer run не предоставлены, поэтому идентичность конкретной причины его каждого failure не утверждается. На Virfield macOS 27 воспроизведены все три имени и найдены ошибки timing assumptions в harness. -Проверены published production `674bb809f2` и harness `d26a1c55d1`: оба shared scheme задают flags автоматически; ручной шаг включения late recovery не пропущен. Normal задаёт `CPM_APP_INTEGRATION=1`; disabled дополнительно задаёт оба DISABLE overrides=1 и выбирает ровно 6 recovery methods. На host macOS 26.7.1 / Xcode 27.1 исходный harness дал **3 PASS / 0 FAIL / 0 SKIP** для reported methods, затем полный disabled **0 PASS / 6 ожидаемых functional FAIL / 0 SKIP**, затем normal **9 PASS / 0 FAIL / 0 SKIP**. +**Опубликованный harness: `29da2c1587571e91f85915c35c8322f273e07eb0`, branch `codex/cpm-fix-init-loss-integration-tests`.** Обычный fast-forward push от `d26a1c55d1`; локальный чистый worktree `alex/cpm-fix-p1-p2` также fast-forward обновлён. Новые изменения затрагивают ровно три существующих файла: CPMAppIntegrationHarness.swift, CPMBackgroundRecoveryIntegrationTests.swift, README.md. Production PR #7379 остаётся на `674bb809f2`, base `alex/cpm-messaging-readiness-telemetry` (#7376); production files, flags/defaults, reload safeguards и 5-second navigation timeout не менялись. Production head — ancestor harness; полный diff harness относительно production по-прежнему содержит только 12 harness paths, без новых submodule changes. Оба shared schemes автоматически задают flags: normal `CPM_APP_INTEGRATION=1`; disabled дополнительно задаёт оба DISABLE overrides=1 и выбирает ровно 6 recovery methods. Ручной шаг включения late recovery в PR instructions не пропущен; текущие 10 шагов PR сохранены, README уточнён. -На чистой Virfield macOS 27.0 (26A428), Xcode 27.0 (27A266a), arm64 исходный harness дал normal **5 PASS / 4 FAIL / 0 SKIP**: edited-document и over-budget install истекали на 6.5-second first-document precondition; следующие P4-detection и over-budget upgrade падали с SIGINT. Disabled дал **0 PASS / 6 FAIL / 0 SKIP**, но часть падений была precondition/host failures, поэтому этот VM run не считается успешным отрицательным контролем. Пример normal install: policy callback 16:05:46.736120Z; fixture timeout 16:05:51.770356Z; didStart 16:05:51.806345Z — fixture бросил ошибку за 36 ms до окончания корректного пятисекундного gate, включив в свой бюджет холодную подготовку окна/WebKit. Unstructured navigation tasks не отменялись и не ожидались на пути ошибки, продолжая работу во время teardown перед SIGINT в следующих методах. +Исходный `d26a1c55d1` на host macOS 26.7.1 (25G241) / Xcode 27.1 (27A9275) дал: reported 3 methods **3 PASS / 0 FAIL / 0 SKIP**; полный disabled **0 PASS / 6 ожидаемых functional FAIL / 0 SKIP**; следующий normal **9 PASS / 0 FAIL / 0 SKIP**. На чистой Virfield macOS 27.0 (26A428), Xcode 27.0 (27A266a), arm64 исходный harness дал normal **5 PASS / 4 FAIL / 0 SKIP**: edited-document и over-budget install истекали на 6.5-second first-document precondition; следующие P4-detection и over-budget upgrade падали с SIGINT. Disabled дал **0 PASS / 6 FAIL**, но часть была precondition/host failures, поэтому этот исходный VM run не считается успешным отрицательным контролем. Пример normal install: policy callback 16:05:46.736120Z, fixture timeout 16:05:51.770356Z, didStart 16:05:51.806345Z — fixture бросал ошибку за 36 ms до release корректного пятисекундного gate, включив холодную подготовку окна/WebKit в общий бюджет. Незавершённые unstructured navigation tasks продолжали работу во время teardown перед следующими SIGINT. -В отдельной source copy подготовлен harness-only fix: перед late-startup сценарием прогревается реальное окно через ineligible about:blank, production coordinator waiter измеряется отдельно (5-second gate, прежний 1.5-second scheduler tolerance), page completion получает отдельный 15-second fixture budget, причём startup обязан оставаться pending при release gate/редактировании. Навигации используют structured async let для cancellation/join до teardown. Production timeout, flags и recovery-код не меняются. Четыре локальных late-startup/edited regressions после исправления: **4 PASS / 0 FAIL / 0 SKIP**, strict SwiftLint **0 violations**. Промежуточный VM run только с этими изменениями убрал precondition/SIGINT cascade и дал **6 PASS / 3 FAIL / 0 SKIP** ровно в трёх reported methods: при 8-second startup WebKit 27 доставил настоящие native dashboard и page initResp через ~3 секунды после окончания gate, до 4-second response deadline. Поэтому не было missing-response pixel/reload: первая страница была здоровой, ожидание обязательного recovery было ошибкой fixture. Повторный intermediate normal после disabled также дал **6 PASS / 3 FAIL**, app/test hashes до/после всех трёх запусков совпали; это не загрязнение flags предыдущей схемой. Дополнительный harness-only commit `8a27a69776`: late-startup delay 12 секунд (больше 5-second gate + 4-second response deadline), ожидание completion/detection до 10 секунд и явный assertFailed исходного probe; обычный P1 idle-wake остаётся 8 секунд. При первой 12-second локальной попытке recovery работало, но два over-budget tests проверяли P4 count до completion; после ожидания реального callback финальные 4 methods дали **4 PASS / 0 FAIL / 0 SKIP**. Gate elapsed install **5.00193 s**, upgrade **5.01807 s**; startup pending при release, finishCount=2 для обоих reload cases. P4-only detections=1, finishCount=1, без reload. Production limits и assertions результата не ослабляются. Первый полный 12-second VM run (`8a27a69776`) дал **7 PASS / 2 FAIL / 0 SKIP**: P4-only тест ошибочно запрещал поздний original response после уже зафиксированного таймаута; install проверял response_received сразу после reload finish (через ~38 ms), не ожидая dashboard delivery. В follow-up `0a6d90e4c0` P4 сохраняет обязательный исходный failed probe/detection=1/finishCount=1/no-reload, но допускает естественный поздний ответ. Recovery требует reload_started, затем ровно два finish, ACK уже нового документа и отдельное ожидание attributed response_received, с сохранением точного списка outcomes. Новые локальные четыре methods: **4 PASS / 0 FAIL / 0 SKIP**. Первый VM run окончательного `0a6d90e4c0` дал **8 PASS / 1 FAIL / 0 SKIP**: все три исходных reported methods и edited-document прошли, install/upgrade дождались обоих reload outcomes. Единственный FAIL — отдельный P2: после намеренно вызванного error 6 retry background PID 3001 также завершился настоящим 30-second error 6 (первое notification 16:36:14.455Z, повторное 16:36:44.468Z), затем same-document recovery timeout. Crash/OOM report в собранных логах не найден; причина второго WebKit load failure пока не установлена и не объявляется инфраструктурной. Все предыдущие VM normal attempts проходили P2. Исходный failed bundle сохранён (`vm-verified-first/normal.xcresult`). Контрольный repeat `0a6d90e4c0` на тех же физических binaries снова дал **8 PASS / 1 P2 FAIL / 0 SKIP**, с повторным error 6 на retry PID 3265 (16:40:38.693Z → 16:41:08.707Z); на 24-й секунде процесс был жив, sleeping, 0% CPU, stack sample не успел до его завершения. Console VM разблокирована/активна; доказанной причины повторного WebKit timeout нет. OFF → ON продолжается отдельно без перезаписи обоих failed normal bundles. Для отделения test-lifetime изменения от реального повторного WebKit failure поставлен контроль одного P2 на исходном published `d26a1c55d1` в той же VM. Несвязанное с тремя reported methods преобразование P2 Task→async let убирается из финального diff; исходная Task и WebKit timing P2 сохраняются, при этом late-startup navigation cleanup остаётся structured. Локальная/VM проверка этого уточнения ещё выполняется. Harness commits пока не опубликованы. Первые три reviewer-like failures не требуют ручного переключения remote flags. +Промежуточный вариант с прогревом окна, отдельным измерением реального coordinator waiter и structured late navigation cleanup убрал precondition/SIGINT cascade, но на VM дал **6 PASS / 3 FAIL**, затем disabled **0 PASS / 6 FAIL**, затем normal снова **6 PASS / 3 FAIL** на неизменных binaries. Ровно три reported methods требовали failure/recovery от здоровой страницы: при 8-second startup WebKit 27 доставлял настоящий native dashboard и page initResp через ~3 секунды после release gate, до 4-second response deadline. Поэтому отсутствие missing-response/reload было корректным поведением app. Late-startup fixture delay увеличен до **12 секунд**, чтобы пересечь и 5-second gate, и 4-second response deadline; обычный P1 idle-wake остаётся 8 секунд. Используется реальное приложение, AppDelegate/Tab/lifecycle coordinator, system WebKit, CPU delay в extracted test copy extension и настоящие ответы; ACK/ошибки/пиксели не фабрикуются. -Virfield lease `lease-671a00b65fc4efdfc9b0df677a0ff51f`, expiry `2026-10-19T17:49:35Z`; используются Apple Development signed host build и точные generated .xctestrun, private signing keys в VM не передавались. Первая transfer попытка пересеклась с Xcode build и завершилась rsync exit 23; она сохранена и не считается test run. Следующая stable copy успешно запустила baseline VM tests. Deep signature verification локального Debug build сообщает missing/invalid sealed resource в вложенном VPN helper PrivacyConfig.framework, при этом CPM app host запускается локально и на VM. Артефакты всех попыток: `/private/tmp/cpm-pr7379-three-late-failures-20261019/`; baseline VM raw xcresults сохраняются отдельно от финального fixed run. +Checkpoint `8a27a69776` включил эти harness fixes. Первая локальная 12-second попытка: **2 PASS / 2 FAIL**, оба over-budget cases проверяли P4 count до реального background completion; после ожидания callback локальные четыре methods дали **4 PASS / 0 FAIL**. Первый полный 12-second VM run: **7 PASS / 2 FAIL** — P4-only ошибочно запрещал естественный поздний original response после уже зарегистрированного timeout, а install проверял response_received через ~38 ms после reload finish без отдельного ожидания. Follow-up `0a6d90e4c0` сохраняет исходный failed probe, P4 detection=1, finishCount=1 и отсутствие reload при recovery OFF, но допускает поздний original response. Recovery требует reload_started, ровно два finish, ACK уже нового документа и отдельное ожидание attributed response_received с точным списком outcomes. Локальные четыре methods после этого: **4 PASS / 0 FAIL / 0 SKIP**. Несвязанный перевод P2 navigation Task→async let затем убран в `ddee0e5be0`: финальный P2 method сохраняет исходную Task и timing. Это ограничение diff, а не заявленный фикс повторного WebKit failure. Локальный отдельный P2 после возврата исходной Task: **1 PASS / 0 FAIL / 0 SKIP**. `29da2c1587` добавляет README-only описание оставшегося failure. Strict SwiftLint двух изменённых Swift files: **0 violations**, diff checks clean. + +**Финальный VM цикл на коде `ddee0e5be0` (published head `29da2c1587` отличается только README): normal 9 PASS / 0 FAIL → disabled 0 PASS / 6 ожидаемых functional FAIL → normal 8 PASS / 1 unexpected P2 FAIL; везде 0 SKIP.** Все три исходных reported methods и edited-document PASS в обоих normal runs. Disabled failures проверены по причинам: install/upgrade/slow wake не получают первый ответ в срок, P2 не восстанавливает исходный документ, late install/upgrade не выполняют automatic recovery; host crashes/setup errors не засчитаны как controls. Финальные measured gate waits: install **5.00827 s**, upgrade **5.01224 s**; после OFF соответственно **5.01076 s**, **5.00807 s**. При release startup оставался pending; оба recovery cases имеют finishCount=2 и оба reload outcomes. P4-only имеет detections=1, finishCount=1, без reload/recovery outcomes. App/test SHA-256 до/после всех трёх phases совпали и совпали с локальным payload; пересборки между phases не было. Полный green **9 → 6 expected red → 9** на финальной версии не подтверждён; последний enabled run действительно красный из-за P2. + +**Оставшийся P2: retry тоже иногда получает настоящий background-load error 6.** Два отдельных normal runs `0a6d90e4c0` дали **8 PASS / 1 P2 FAIL**, но тот же неизменный payload после disabled дал **9 PASS / 0 FAIL**. В первой failed попытке второй error 6 пришёл через 30 секунд после первого (16:36:14.455Z → 16:36:44.468Z, retry PID 3001); повтор дал 16:40:38.693Z → 16:41:08.707Z, PID 3265. Контроль единственного P2 на исходном published `d26a1c55d1` в той же VM также дал **0 PASS / 1 FAIL / 0 SKIP** с повторным error 6, поэтому явление воспроизводится и без новых late-startup fixes. Для baseline retry PID 3952 успешно сняты background/app stack samples: WebKit 22625.1.29.11.27, background footprint 11.3 MB, main thread в XPCServiceMain/xpc_main/NSRunLoop/Mach wait, 0% CPU; app main thread в XCTest/AppKit run loop. Эти стеки не показывают CPU busy-loop и совместимы с неустановившимся XPC/bootstrap connection, но точная root cause не доказана. Console VM была разблокирована/активна; crash/OOM report в собранных логах не найден. Failure не объявляется infrastructure-only и не игнорируется. Финальный normal после OFF снова поймал его; README явно считает это unexpected enabled-scheme failure, а не валидный отрицательный контроль. Production-изменений для второго error 6 в этой работе нет. + +Все raw xcresults, logs, JSON attachments, generated .xctestrun/flag environment, app/test hashes, export manifests и samples сохранены в `/private/tmp/cpm-pr7379-three-late-failures-20261019/`: `vm-baseline/`, `vm-eight-second-intermediate/`, `vm-twelve-intermediate/`, `vm-verified-first/`, `vm-confirmation/` (включая baseline-p2.xcresult и samples), `vm-final/`. SHA-256 manifests экспортированных VM bundles совпали с оригиналами; финальный экспорт проверен по **3820 files**. Локальные failed/positive attempts также сохранены отдельно. Первая transfer попытка пересеклась с Xcode build и завершилась rsync exit 23 до test execution; stable copy затем успешно запустила baseline. Deep signature verification локального Debug build сообщал missing/invalid sealed resource во вложенном VPN helper PrivacyConfig.framework; это не засчитано как причина reported failures. Использовался Apple Development signed host app/test build, guest signing identities отсутствуют, private signing keys в VM не передавались. Virfield lease `lease-671a00b65fc4efdfc9b0df677a0ff51f`, expiry `2026-10-19T17:49:35Z`; VM не удалялась без отдельного разрешения. diff --git a/work/projects/cpm-web-extension-code-guide-2026-10-09.md b/work/projects/cpm-web-extension-code-guide-2026-10-09.md index ef08a0ec..ce7cf6b2 100755 --- a/work/projects/cpm-web-extension-code-guide-2026-10-09.md +++ b/work/projects/cpm-web-extension-code-guide-2026-10-09.md @@ -636,12 +636,18 @@ P4 detection-only method прошёл в обоих успешных ON runs: la ## Проверка отчёта о трёх падениях late-startup app tests — 19 октября 2026 -Исходный screenshot: failed `testLateStartupIsDetectedWithRecoveryDisabledWithoutReload`, `testOverBudgetInstallRecoversFirstDocumentWithoutExtendingNavigationWait`, `testOverBudgetUpgradeRecoversFirstDocumentWithoutExtendingNavigationWait`; остальные 6 methods зелёные. Assertion text reviewer run не предоставлен, поэтому идентичность конкретных причин его трёх failures не утверждается. +Исходный screenshot: failed `testLateStartupIsDetectedWithRecoveryDisabledWithoutReload`, `testOverBudgetInstallRecoversFirstDocumentWithoutExtendingNavigationWait`, `testOverBudgetUpgradeRecoversFirstDocumentWithoutExtendingNavigationWait`; остальные 6 methods зелёные. Assertion text и macOS/Xcode reviewer run не предоставлены, поэтому идентичность конкретной причины его каждого failure не утверждается. На Virfield macOS 27 воспроизведены все три имени и найдены ошибки timing assumptions в harness. -Проверены published production `674bb809f2` и harness `d26a1c55d1`: оба shared scheme задают flags автоматически; ручной шаг включения late recovery не пропущен. Normal задаёт `CPM_APP_INTEGRATION=1`; disabled дополнительно задаёт оба DISABLE overrides=1 и выбирает ровно 6 recovery methods. На host macOS 26.7.1 / Xcode 27.1 исходный harness дал **3 PASS / 0 FAIL / 0 SKIP** для reported methods, затем полный disabled **0 PASS / 6 ожидаемых functional FAIL / 0 SKIP**, затем normal **9 PASS / 0 FAIL / 0 SKIP**. +**Опубликованный harness: `29da2c1587571e91f85915c35c8322f273e07eb0`, branch `codex/cpm-fix-init-loss-integration-tests`.** Обычный fast-forward push от `d26a1c55d1`; локальный чистый worktree `alex/cpm-fix-p1-p2` также fast-forward обновлён. Новые изменения затрагивают ровно три существующих файла: CPMAppIntegrationHarness.swift, CPMBackgroundRecoveryIntegrationTests.swift, README.md. Production PR #7379 остаётся на `674bb809f2`, base `alex/cpm-messaging-readiness-telemetry` (#7376); production files, flags/defaults, reload safeguards и 5-second navigation timeout не менялись. Production head — ancestor harness; полный diff harness относительно production по-прежнему содержит только 12 harness paths, без новых submodule changes. Оба shared schemes автоматически задают flags: normal `CPM_APP_INTEGRATION=1`; disabled дополнительно задаёт оба DISABLE overrides=1 и выбирает ровно 6 recovery methods. Ручной шаг включения late recovery в PR instructions не пропущен; текущие 10 шагов PR сохранены, README уточнён. -На чистой Virfield macOS 27.0 (26A428), Xcode 27.0 (27A266a), arm64 исходный harness дал normal **5 PASS / 4 FAIL / 0 SKIP**: edited-document и over-budget install истекали на 6.5-second first-document precondition; следующие P4-detection и over-budget upgrade падали с SIGINT. Disabled дал **0 PASS / 6 FAIL / 0 SKIP**, но часть падений была precondition/host failures, поэтому этот VM run не считается успешным отрицательным контролем. Пример normal install: policy callback 16:05:46.736120Z; fixture timeout 16:05:51.770356Z; didStart 16:05:51.806345Z — fixture бросил ошибку за 36 ms до окончания корректного пятисекундного gate, включив в свой бюджет холодную подготовку окна/WebKit. Unstructured navigation tasks не отменялись и не ожидались на пути ошибки, продолжая работу во время teardown перед SIGINT в следующих методах. +Исходный `d26a1c55d1` на host macOS 26.7.1 (25G241) / Xcode 27.1 (27A9275) дал: reported 3 methods **3 PASS / 0 FAIL / 0 SKIP**; полный disabled **0 PASS / 6 ожидаемых functional FAIL / 0 SKIP**; следующий normal **9 PASS / 0 FAIL / 0 SKIP**. На чистой Virfield macOS 27.0 (26A428), Xcode 27.0 (27A266a), arm64 исходный harness дал normal **5 PASS / 4 FAIL / 0 SKIP**: edited-document и over-budget install истекали на 6.5-second first-document precondition; следующие P4-detection и over-budget upgrade падали с SIGINT. Disabled дал **0 PASS / 6 FAIL**, но часть была precondition/host failures, поэтому этот исходный VM run не считается успешным отрицательным контролем. Пример normal install: policy callback 16:05:46.736120Z, fixture timeout 16:05:51.770356Z, didStart 16:05:51.806345Z — fixture бросал ошибку за 36 ms до release корректного пятисекундного gate, включив холодную подготовку окна/WebKit в общий бюджет. Незавершённые unstructured navigation tasks продолжали работу во время teardown перед следующими SIGINT. -В отдельной source copy подготовлен harness-only fix: перед late-startup сценарием прогревается реальное окно через ineligible about:blank, production coordinator waiter измеряется отдельно (5-second gate, прежний 1.5-second scheduler tolerance), page completion получает отдельный 15-second fixture budget, причём startup обязан оставаться pending при release gate/редактировании. Навигации используют structured async let для cancellation/join до teardown. Production timeout, flags и recovery-код не меняются. Четыре локальных late-startup/edited regressions после исправления: **4 PASS / 0 FAIL / 0 SKIP**, strict SwiftLint **0 violations**. Промежуточный VM run только с этими изменениями убрал precondition/SIGINT cascade и дал **6 PASS / 3 FAIL / 0 SKIP** ровно в трёх reported methods: при 8-second startup WebKit 27 доставил настоящие native dashboard и page initResp через ~3 секунды после окончания gate, до 4-second response deadline. Поэтому не было missing-response pixel/reload: первая страница была здоровой, ожидание обязательного recovery было ошибкой fixture. Повторный intermediate normal после disabled также дал **6 PASS / 3 FAIL**, app/test hashes до/после всех трёх запусков совпали; это не загрязнение flags предыдущей схемой. Дополнительный harness-only commit `8a27a69776`: late-startup delay 12 секунд (больше 5-second gate + 4-second response deadline), ожидание completion/detection до 10 секунд и явный assertFailed исходного probe; обычный P1 idle-wake остаётся 8 секунд. При первой 12-second локальной попытке recovery работало, но два over-budget tests проверяли P4 count до completion; после ожидания реального callback финальные 4 methods дали **4 PASS / 0 FAIL / 0 SKIP**. Gate elapsed install **5.00193 s**, upgrade **5.01807 s**; startup pending при release, finishCount=2 для обоих reload cases. P4-only detections=1, finishCount=1, без reload. Production limits и assertions результата не ослабляются. Первый полный 12-second VM run (`8a27a69776`) дал **7 PASS / 2 FAIL / 0 SKIP**: P4-only тест ошибочно запрещал поздний original response после уже зафиксированного таймаута; install проверял response_received сразу после reload finish (через ~38 ms), не ожидая dashboard delivery. В follow-up `0a6d90e4c0` P4 сохраняет обязательный исходный failed probe/detection=1/finishCount=1/no-reload, но допускает естественный поздний ответ. Recovery требует reload_started, затем ровно два finish, ACK уже нового документа и отдельное ожидание attributed response_received, с сохранением точного списка outcomes. Новые локальные четыре methods: **4 PASS / 0 FAIL / 0 SKIP**. Первый VM run окончательного `0a6d90e4c0` дал **8 PASS / 1 FAIL / 0 SKIP**: все три исходных reported methods и edited-document прошли, install/upgrade дождались обоих reload outcomes. Единственный FAIL — отдельный P2: после намеренно вызванного error 6 retry background PID 3001 также завершился настоящим 30-second error 6 (первое notification 16:36:14.455Z, повторное 16:36:44.468Z), затем same-document recovery timeout. Crash/OOM report в собранных логах не найден; причина второго WebKit load failure пока не установлена и не объявляется инфраструктурной. Все предыдущие VM normal attempts проходили P2. Исходный failed bundle сохранён (`vm-verified-first/normal.xcresult`). Контрольный repeat `0a6d90e4c0` на тех же физических binaries снова дал **8 PASS / 1 P2 FAIL / 0 SKIP**, с повторным error 6 на retry PID 3265 (16:40:38.693Z → 16:41:08.707Z); на 24-й секунде процесс был жив, sleeping, 0% CPU, stack sample не успел до его завершения. Console VM разблокирована/активна; доказанной причины повторного WebKit timeout нет. OFF → ON продолжается отдельно без перезаписи обоих failed normal bundles. Для отделения test-lifetime изменения от реального повторного WebKit failure поставлен контроль одного P2 на исходном published `d26a1c55d1` в той же VM. Несвязанное с тремя reported methods преобразование P2 Task→async let убирается из финального diff; исходная Task и WebKit timing P2 сохраняются, при этом late-startup navigation cleanup остаётся structured. Локальная/VM проверка этого уточнения ещё выполняется. Harness commits пока не опубликованы. Первые три reviewer-like failures не требуют ручного переключения remote flags. +Промежуточный вариант с прогревом окна, отдельным измерением реального coordinator waiter и structured late navigation cleanup убрал precondition/SIGINT cascade, но на VM дал **6 PASS / 3 FAIL**, затем disabled **0 PASS / 6 FAIL**, затем normal снова **6 PASS / 3 FAIL** на неизменных binaries. Ровно три reported methods требовали failure/recovery от здоровой страницы: при 8-second startup WebKit 27 доставлял настоящий native dashboard и page initResp через ~3 секунды после release gate, до 4-second response deadline. Поэтому отсутствие missing-response/reload было корректным поведением app. Late-startup fixture delay увеличен до **12 секунд**, чтобы пересечь и 5-second gate, и 4-second response deadline; обычный P1 idle-wake остаётся 8 секунд. Используется реальное приложение, AppDelegate/Tab/lifecycle coordinator, system WebKit, CPU delay в extracted test copy extension и настоящие ответы; ACK/ошибки/пиксели не фабрикуются. -Virfield lease `lease-671a00b65fc4efdfc9b0df677a0ff51f`, expiry `2026-10-19T17:49:35Z`; используются Apple Development signed host build и точные generated .xctestrun, private signing keys в VM не передавались. Первая transfer попытка пересеклась с Xcode build и завершилась rsync exit 23; она сохранена и не считается test run. Следующая stable copy успешно запустила baseline VM tests. Deep signature verification локального Debug build сообщает missing/invalid sealed resource в вложенном VPN helper PrivacyConfig.framework, при этом CPM app host запускается локально и на VM. Артефакты всех попыток: `/private/tmp/cpm-pr7379-three-late-failures-20261019/`; baseline VM raw xcresults сохраняются отдельно от финального fixed run. +Checkpoint `8a27a69776` включил эти harness fixes. Первая локальная 12-second попытка: **2 PASS / 2 FAIL**, оба over-budget cases проверяли P4 count до реального background completion; после ожидания callback локальные четыре methods дали **4 PASS / 0 FAIL**. Первый полный 12-second VM run: **7 PASS / 2 FAIL** — P4-only ошибочно запрещал естественный поздний original response после уже зарегистрированного timeout, а install проверял response_received через ~38 ms после reload finish без отдельного ожидания. Follow-up `0a6d90e4c0` сохраняет исходный failed probe, P4 detection=1, finishCount=1 и отсутствие reload при recovery OFF, но допускает поздний original response. Recovery требует reload_started, ровно два finish, ACK уже нового документа и отдельное ожидание attributed response_received с точным списком outcomes. Локальные четыре methods после этого: **4 PASS / 0 FAIL / 0 SKIP**. Несвязанный перевод P2 navigation Task→async let затем убран в `ddee0e5be0`: финальный P2 method сохраняет исходную Task и timing. Это ограничение diff, а не заявленный фикс повторного WebKit failure. Локальный отдельный P2 после возврата исходной Task: **1 PASS / 0 FAIL / 0 SKIP**. `29da2c1587` добавляет README-only описание оставшегося failure. Strict SwiftLint двух изменённых Swift files: **0 violations**, diff checks clean. + +**Финальный VM цикл на коде `ddee0e5be0` (published head `29da2c1587` отличается только README): normal 9 PASS / 0 FAIL → disabled 0 PASS / 6 ожидаемых functional FAIL → normal 8 PASS / 1 unexpected P2 FAIL; везде 0 SKIP.** Все три исходных reported methods и edited-document PASS в обоих normal runs. Disabled failures проверены по причинам: install/upgrade/slow wake не получают первый ответ в срок, P2 не восстанавливает исходный документ, late install/upgrade не выполняют automatic recovery; host crashes/setup errors не засчитаны как controls. Финальные measured gate waits: install **5.00827 s**, upgrade **5.01224 s**; после OFF соответственно **5.01076 s**, **5.00807 s**. При release startup оставался pending; оба recovery cases имеют finishCount=2 и оба reload outcomes. P4-only имеет detections=1, finishCount=1, без reload/recovery outcomes. App/test SHA-256 до/после всех трёх phases совпали и совпали с локальным payload; пересборки между phases не было. Полный green **9 → 6 expected red → 9** на финальной версии не подтверждён; последний enabled run действительно красный из-за P2. + +**Оставшийся P2: retry тоже иногда получает настоящий background-load error 6.** Два отдельных normal runs `0a6d90e4c0` дали **8 PASS / 1 P2 FAIL**, но тот же неизменный payload после disabled дал **9 PASS / 0 FAIL**. В первой failed попытке второй error 6 пришёл через 30 секунд после первого (16:36:14.455Z → 16:36:44.468Z, retry PID 3001); повтор дал 16:40:38.693Z → 16:41:08.707Z, PID 3265. Контроль единственного P2 на исходном published `d26a1c55d1` в той же VM также дал **0 PASS / 1 FAIL / 0 SKIP** с повторным error 6, поэтому явление воспроизводится и без новых late-startup fixes. Для baseline retry PID 3952 успешно сняты background/app stack samples: WebKit 22625.1.29.11.27, background footprint 11.3 MB, main thread в XPCServiceMain/xpc_main/NSRunLoop/Mach wait, 0% CPU; app main thread в XCTest/AppKit run loop. Эти стеки не показывают CPU busy-loop и совместимы с неустановившимся XPC/bootstrap connection, но точная root cause не доказана. Console VM была разблокирована/активна; crash/OOM report в собранных логах не найден. Failure не объявляется infrastructure-only и не игнорируется. Финальный normal после OFF снова поймал его; README явно считает это unexpected enabled-scheme failure, а не валидный отрицательный контроль. Production-изменений для второго error 6 в этой работе нет. + +Все raw xcresults, logs, JSON attachments, generated .xctestrun/flag environment, app/test hashes, export manifests и samples сохранены в `/private/tmp/cpm-pr7379-three-late-failures-20261019/`: `vm-baseline/`, `vm-eight-second-intermediate/`, `vm-twelve-intermediate/`, `vm-verified-first/`, `vm-confirmation/` (включая baseline-p2.xcresult и samples), `vm-final/`. SHA-256 manifests экспортированных VM bundles совпали с оригиналами; финальный экспорт проверен по **3820 files**. Локальные failed/positive attempts также сохранены отдельно. Первая transfer попытка пересеклась с Xcode build и завершилась rsync exit 23 до test execution; stable copy затем успешно запустила baseline. Deep signature verification локального Debug build сообщал missing/invalid sealed resource во вложенном VPN helper PrivacyConfig.framework; это не засчитано как причина reported failures. Использовался Apple Development signed host app/test build, guest signing identities отсутствуют, private signing keys в VM не передавались. Virfield lease `lease-671a00b65fc4efdfc9b0df677a0ff51f`, expiry `2026-10-19T17:49:35Z`; VM не удалялась без отдельного разрешения.