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

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

@@ -61,7 +61,7 @@ Ported and adapted from `alex/cpm-messaging-readiness-telemetry`:
 
 These values are captured in the first-failure snapshot and sent in the same terminal episode report, retaining `daily+count`. Unavailable values are omitted. The two error fields describe only the first newly observed error 6 for the corresponding background-load attempt. Repeated error-list notifications preserve its original time and app state; a replacement view/context clears that attribution. Errors seen before any view was created do not qualify.
 
-Readiness observation shares the existing `cpmBackgroundDelegateProxy` switch. It calls the public `loadBackgroundContent` API on the next main-queue turn after a new view is created. Disabling observation invalidates pending callbacks; reenabling on an existing view leaves readiness unknown until the next view creation. Error 6 also marks the observed load failed if WebKit never completes its load callback. Later readiness changes and errors do not replace the episode's first-failure snapshot. `pending` means the load was still pending at that snapshot; it may complete or fail later. For example, a snapshot taken 4 seconds after view creation stays `pending` even if error 6 arrives at 30 seconds; that later error is not included when the episode is reported.
+Readiness observation shares the existing `cpmBackgroundDelegateProxy` switch. It calls the public `loadBackgroundContent` API on the next main-queue turn after a new view is created. Disabling observation invalidates pending callbacks; reenabling on an existing view leaves readiness unknown until the next view creation. Error 6 also marks the observed load failed if WebKit never completes its load callback. Later readiness changes and errors do not replace the episode's first-failure snapshot. `pending` means the load was still pending at that snapshot; it may complete or fail later. For example, a snapshot taken 4 seconds after view creation stays `pending` even if error 6 arrives at 30 seconds; that later error does not update the load fields. If observed before stuck confirmation, it appears in the bg_events continuation.
 
 The added fields' combined distinguishability with the retained `bg_events` still needs checking.
 
@@ -80,7 +80,7 @@ The added fields' combined distinguishability with the retained `bg_events` stil
 
   
 
-`bg_events` is kept included, using the existing encoder: the latest 12 events at the first failure, oldest first, as sanitized `token@age` entries. Ages use `30s`, `1m`, `2m`, `5m`, `15m` and `over_15` buckets; older entries are dropped to keep the value within 255 characters. The timeline can contain error descriptors. Later failures and recovery do not replace or append to this snapshot.
+`bg_events` contains the first-failure history and, for confirmed stuck episodes, a `;` followed by events observed afterwards up to that confirmation, before its automatic recovery. Non-stuck episodes keep only the first-failure history. A standalone `...` at the start of either phase means older events were dropped. Both phases share a limit of 12 events and 255 characters, including separators and markers; oldest events are dropped first. Sanitized `token@age` entries retain order and duplicates. Ages use `30s`, `1m`, `2m`, `5m`, `15m` and `over_15`, relative to the first failure before `;` and stuck confirmation after it. An empty phase has no events. Consumers split on both `,` and `;`, ignoring empty entries and standalone `...`. Example: `...,load@1m,view@30s;error_e:6@30s`. No second full diagnostic snapshot is collected.