[2026-10-16] eagle: work/projects/cpm-pr0-episode-telemetry-summary-2026-10-16.md

work/projects/cpm-pr0-episode-telemetry-summary-2026-10-16.md

@@ -20,11 +20,11 @@ The first `4s` timeout **opens** an episode and captures one diagnostic snapshot
 
 The pixel is **submitted when the episode is closed** (a qualifying dashboard response or a 5-minute deadline closes).
 
-Further failures or extension reloads are recorded in the same episode and included in its final report. If no qualifying response arrives, the report is sent 5min after the first failure, even if the user does not open or reload another page. The existing rules for confirming a persistent failure and automatically reloading the extension stay the same.
+Further failures or extension reloads are recorded in the same episode and included in its final report. If no qualifying response arrives, the report is sent 5min after the first failure, even if the user does not open or reload another page (with `outcome=no_response_before_deadline`). The existing rules for confirming a persistent failure and automatically reloading the extension stay the same.
 
 A dashboard response tells us the extension answered the app. It does not confirm that the page received its initialization reply (`initResp`). For example, tab B may answer while the original failing tab A is still broken.
 
-No response within five minutes means we did not observe one during that time; CPM may recover later. Pending episodes are kept only in memory. If the browser closes or crashes, or the health monitor is replaced before the episode ends, that episode can be lost without sending a report.
+Deadline expiry does not prove permanent failure; unfinished episodes can be lost if the monitor or process is destroyed.
 
 **Reporting frequency:**