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 edca1f8e..de552bd8 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
@@ -552,6 +552,6 @@ P4 detection-only method прошёл в обоих успешных ON runs: la
 
 На чистой 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 в следующих методах.
 
-В отдельной 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 ON → OFF → ON на тех же физических подписанных binaries, без source/build/flag-configuration изменений. Оба harness-only commits пока не опубликованы. Первые три reviewer-like failures не требуют ручного переключения remote flags.
+В отдельной 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.
 
 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.
diff --git a/work/projects/cpm-status-2026-10-15.md b/work/projects/cpm-status-2026-10-15.md
index ab682fdf..e8770d88 100755
--- a/work/projects/cpm-status-2026-10-15.md
+++ b/work/projects/cpm-status-2026-10-15.md
@@ -1380,6 +1380,6 @@ P4 detection-only method прошёл в обоих успешных ON runs: la
 
 На чистой 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 в следующих методах.
 
-В отдельной 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 ON → OFF → ON на тех же физических подписанных binaries, без source/build/flag-configuration изменений. Оба harness-only commits пока не опубликованы. Первые три reviewer-like failures не требуют ручного переключения remote flags.
+В отдельной 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.
 
 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.
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 cf7937ac..ef08a0ec 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
@@ -642,6 +642,6 @@ P4 detection-only method прошёл в обоих успешных ON runs: la
 
 На чистой 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 в следующих методах.
 
-В отдельной 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 ON → OFF → ON на тех же физических подписанных binaries, без source/build/flag-configuration изменений. Оба harness-only commits пока не опубликованы. Первые три reviewer-like failures не требуют ручного переключения remote flags.
+В отдельной 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.
 
 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.