## Evidence

For [#32520](https://git.cafe/pingdotgg/t3code/pull/32520). Before [d313b2aff3](https://github.com/pingdotgg/t3code/commit/d313b2aff31991ab94c8ac80cdc38a54dd575604); after [175298a8cd](https://github.com/pingdotgg/t3code/commit/175298a8cd17add52719b12bce9777f6758e8f77).

**Additional observation beyond the alert change:** rapid successor runs sometimes replaced a completed run before the client observed its completed shell. Thus the baseline produced 7 alerts for 9 persisted runs, and the first head capture did not expose the initial-user or command-terminal completion states. These are capture limitations, not evidence that the PR suppressed those alerts. The steering capture independently observed both allowed completions. **F4 (release with no next run) remains unverified:** the supplemental client-harness recordings were lost during severe VM overload.

Coverage: 3/3 scoped row groups have artifacts; 2/3 are complete at the requested boundary (R2 and R3), and R1 is partial because F4 is missing. R1 proves repeated native progress wakes, silence on head, and terminal replacement without a delayed duplicate. No rendering change was made or found.

**Environment — applies to every recording:** T3 Browser panel; Chrome Headless Shell 157.0.0.0 on Linux x86_64; no device emulation; CSS viewport 1440×900; device pixel ratio 2; recorded raster 2880×1800; font scaling 100%, interface 16px, default fonts; dark theme; real UTC clock. Initial scroll position is the fresh-thread top; both sides use the same automatic follow behavior. Two detached checkouts ran their own real dev server with `T3CODE_DEV_SEED=0`, fresh local databases, and the same synthetic project directory. No live database was seeded or copied. Real Claude provider turns authenticated successfully; the cheapest configured model was selected, and its private identifier is omitted. Model controls were hidden before recording.

Notification instrumentation replaces `Notification` with the PR recorder and makes `document.hasFocus()` false. Settings used “Notifications with sound”. Audio instrumentation wraps the real `AudioBufferSourceNode.start()` after calling the original, recording successful source starts and decoded durations (0.6017s). The videos have no audio track; these counts prove Web Audio playback starts, not physical speaker or OS delivery.

### R1 — same six-line Monitor workload, before and after

Interaction: submit the linked driver prompt from a fresh web composer; Bash appends six numbered lines at five-second intervals; native Monitor runs for 60 seconds; every wake replies briefly and ends; no `t3_background_wait`. Let both terminal wakes finish, then continue observing beyond two grace intervals. The same prompt was used on both revisions.

| Measure | Before | After |
|---|---|---|
| Commit | [d313b2aff3](https://github.com/pingdotgg/t3code/commit/d313b2aff31991ab94c8ac80cdc38a54dd575604) | [175298a8cd](https://github.com/pingdotgg/t3code/commit/175298a8cd17add52719b12bce9777f6758e8f77) |
| Submit marker (UTC) | 14:52:47.692 | 14:55:13.906 |
| Persisted runs | 9 | 9 |
| Completion alerts | 7 | 1 |
| Actual audio starts | 7 | 1 |
| Observed progress alerts | 5 | 0 |
| Final Monitor-stop alert | 14:54:12.835 | 14:56:32.105 |
| Last observation marker | 14:54:36.834 | 14:57:16.867 |
| No extra release alert after terminal wake | Yes | Yes |

Before recording: [r1-before.mp4](https://gh-file-drop-api-prod-mi5fy3sowv63ufte.pinglabs.workers.dev/f/fa938020ae991ffb/r1-before.mp4)

After recording: [r1-after.mp4](https://gh-file-drop-api-prod-mi5fy3sowv63ufte.pinglabs.workers.dev/f/c864a750862f3146/r1-after.mp4)

Before run listing: [r1-before-runs.json](https://gh-file-drop-api-prod-mi5fy3sowv63ufte.pinglabs.workers.dev/f/098138cee3ce7c17/r1-before-runs.json); recorder text: [r1-before-recorder.txt](https://gh-file-drop-api-prod-mi5fy3sowv63ufte.pinglabs.workers.dev/f/52c6a2f527788ab1/r1-before-recorder.txt); all shell transitions: [r1-before-recorder.json](https://gh-file-drop-api-prod-mi5fy3sowv63ufte.pinglabs.workers.dev/f/f9c6dd440bcd7edb/r1-before-recorder.json).

After run listing: [r1-after-runs.json](https://gh-file-drop-api-prod-mi5fy3sowv63ufte.pinglabs.workers.dev/f/6a68f7b84b1cc853/r1-after-runs.json); recorder text: [r1-after-recorder.txt](https://gh-file-drop-api-prod-mi5fy3sowv63ufte.pinglabs.workers.dev/f/b6f95be3f330bf02/r1-after-recorder.txt); all shell/awareness transitions: [r1-after-recorder.json](https://gh-file-drop-api-prod-mi5fy3sowv63ufte.pinglabs.workers.dev/f/1da46dc1f1ded5d1/r1-after-recorder.json).

F1 is independently observed in R2’s first run: wake=false with command+monitor pending, one immediate alert/audio pair. Its command-terminal run also alerts immediately (see R2). In R1 after, Monitor roster removal at 14:56:29.203 releases the held progress completion; the terminal run starts at 14:56:29.495, then alerts at 14:56:32.105. Observation continues to 14:57:16.867 with no duplicate. This covers F5. It does not cover F4’s no-following-run deadline.

### R2 — user steers an active progress wake (after only)

Interaction: repeat the same fresh-thread driver; prepare the follow-up “User steering check: keep the existing Monitor armed. In this same reply, acknowledge that this follow-up came from me, then end the turn. Do not wait.” Submit it through the actual “Steer message” composer control while a progress wake is active. The initial page hook mistakenly looked for “Submit message”; that unsuccessful attempt is retained as the R3 recording, not counted as R2. The corrected hook used the real control label.

| Measure | Before | After |
|---|---|---|
| Commit | [d313b2aff3](https://github.com/pingdotgg/t3code/commit/d313b2aff31991ab94c8ac80cdc38a54dd575604) | [175298a8cd](https://github.com/pingdotgg/t3code/commit/175298a8cd17add52719b12bce9777f6758e8f77) |
| Capture | Omitted as permitted: ordinary wake completions already alert on baseline | Real app, same workload + user steer |
| Submit marker | — | 15:01:10.664 UTC |
| Steer marker | — | 15:01:29.323 UTC, active run ordinal 3 |
| Persisted runs | — | 9 |
| Alerts / audio starts | — | 4 / 4 |
| Initial user alert | — | 15:01:25.249 |
| Steered-run alert | — | 15:01:34.289 |
| Command-terminal alert | — | 15:01:52.392 |
| Monitor-stop alert | — | 15:02:27.607 |
| Other progress alerts | — | 0 |

After recording: [r2-after.mp4](https://gh-file-drop-api-prod-mi5fy3sowv63ufte.pinglabs.workers.dev/f/9023bb408ec91722/r2-after.mp4)

Run listing: [r2-after-runs.json](https://gh-file-drop-api-prod-mi5fy3sowv63ufte.pinglabs.workers.dev/f/eaaf21a937e3698c/r2-after-runs.json); recorder text: [r2-after-recorder.txt](https://gh-file-drop-api-prod-mi5fy3sowv63ufte.pinglabs.workers.dev/f/473170c204e98df0/r2-after-recorder.txt); complete transitions: [r2-after-recorder.json](https://gh-file-drop-api-prod-mi5fy3sowv63ufte.pinglabs.workers.dev/f/cc80558912b3919c/r2-after-recorder.json); persisted user attachment: [r2-steering-attachment.json](https://gh-file-drop-api-prod-mi5fy3sowv63ufte.pinglabs.workers.dev/f/7bebdf45ca3d8bb3/r2-steering-attachment.json).

The user message created at 15:01:29.459 is attached to run ordinal 3, the same run triggered by an `updated` notification. Its completed shell at 15:01:34.288 has `latestRunBackgroundWake=false` and both command+monitor pending. Notification follows at 15:01:34.289, with a real audio start. This establishes the steered-follow-up exclusion through the UI, persistence, classifier, and coordinator.

### R3 — awareness phase while held and after release

Interaction: the same six-line workload. Read `ProjectionStore.getAgentAwarenessSnapshot` through a scratch process opening only the after checkout’s database read-only; pass the resulting real thread to the production `projectThreadAwarenessV2`, exporting only phase and non-private fields. Read once during a completed progress wake with a pending Monitor, and again after terminal release.

| Measure | Before | After |
|---|---|---|
| Commit | [d313b2aff3](https://github.com/pingdotgg/t3code/commit/d313b2aff31991ab94c8ac80cdc38a54dd575604) | [175298a8cd](https://github.com/pingdotgg/t3code/commit/175298a8cd17add52719b12bce9777f6758e8f77) |
| Runs / alerts / audio starts | 9 / 7 / 7 (reuse R1 before) | 9 / 1 / 1 |
| Completed progress + pending Monitor | `completed`, non-null (offline production projector on captured shells) | `running`, non-null (read-only live-server awareness snapshot) |
| After final Monitor removal | `completed`, non-null | `completed`, non-null |
| Held snapshot | See timestamped projection transcript | 14:59:11.894 UTC; run 8 completed 14:59:06.490 |
| Released snapshot | See timestamped projection transcript | 14:59:35.761 UTC; run 9 completed 14:59:21.371 |

Before recording (same workload, reused): [r1-before.mp4](https://gh-file-drop-api-prod-mi5fy3sowv63ufte.pinglabs.workers.dev/f/fa938020ae991ffb/r1-before.mp4)

After recording: [r3-after.mp4](https://gh-file-drop-api-prod-mi5fy3sowv63ufte.pinglabs.workers.dev/f/8c7827ce41f08634/r3-after.mp4)

The after clip begins with the unsuccessful steering-attempt label; no follow-up was submitted. It follows the full unmodified workload and ends with a correction that it counts for awareness only. The overlay projects live server shells using production code. The separate server transcript below calls the actual awareness snapshot reader.

Before projection transcript: [r3-before-projected.json](https://gh-file-drop-api-prod-mi5fy3sowv63ufte.pinglabs.workers.dev/f/0b89f3c4f3d14fe1/r3-before-projected.json). After read-only server transcript: [r3-server-awareness.jsonl](https://gh-file-drop-api-prod-mi5fy3sowv63ufte.pinglabs.workers.dev/f/98f1a880dce8f5b7/r3-server-awareness.jsonl). After run listing: [r3-after-runs.json](https://gh-file-drop-api-prod-mi5fy3sowv63ufte.pinglabs.workers.dev/f/ae6b8d2a9313bf0b/r3-after-runs.json); recorder text: [r3-after-recorder.txt](https://gh-file-drop-api-prod-mi5fy3sowv63ufte.pinglabs.workers.dev/f/3426aa95cc97716a/r3-after-recorder.txt); all transitions: [r3-after-recorder.json](https://gh-file-drop-api-prod-mi5fy3sowv63ufte.pinglabs.workers.dev/f/58927b78b5dbd1bd/r3-after-recorder.json).

This is local server/awareness boundary evidence. Relay publication confirmation, remote delivery, APNs, physical phones, and Live Activities were not exercised or claimed.

### Alert and sound timestamps against persisted runs

**r1-before**

| Run | Trigger outcome | Completed UTC | Alert UTC | Audio start UTC |
|---|---|---|---|---|
| 1 | user | 14:53:13.167 | 14:53:13.944 | 14:53:14.159 |
| 3 | updated | 14:53:20.937 | 14:53:22.409 | 14:53:22.496 |
| 4 | updated | 14:53:23.111 | 14:53:24.723 | 14:53:24.833 |
| 5 | updated | 14:53:26.076 | 14:53:27.129 | 14:53:27.313 |
| 6 | updated | 14:53:31.103 | 14:53:31.635 | 14:53:31.906 |
| 8 | updated | 14:53:38.241 | 14:53:39.024 | 14:53:39.103 |
| 9 | cancelled | 14:54:12.432 | 14:54:12.835 | 14:54:12.899 |

**r1-after**

| Run | Trigger outcome | Completed UTC | Alert UTC | Audio start UTC |
|---|---|---|---|---|
| 9 | cancelled | 14:56:31.491 | 14:56:32.105 | 14:56:32.198 |

**r2-after**

| Run | Trigger outcome | Completed UTC | Alert UTC | Audio start UTC |
|---|---|---|---|---|
| 1 | user | 15:01:24.905 | 15:01:25.249 | 15:01:25.313 |
| 3 | updated | 15:01:33.935 | 15:01:34.289 | 15:01:34.343 |
| 7 | completed | 15:01:52.008 | 15:01:52.392 | 15:01:52.430 |
| 9 | cancelled | 15:02:27.306 | 15:02:27.607 | 15:02:27.647 |

**r3-after**

| Run | Trigger outcome | Completed UTC | Alert UTC | Audio start UTC |
|---|---|---|---|---|
| 9 | cancelled | 14:59:21.371 | 14:59:21.759 | 14:59:21.823 |

### What else changed

- No product rendering difference was observed. Sidebar Working/Done transitions still occur for individual wakes; the PR changes alerts.
- Titles, reply wording, generated task ids, thread ids and UTC timestamps differ because these are real independent provider runs. Both R1 captures have nine persisted runs.
- Rapid-successor coalescing meant some persisted completions were not observed as completed shells: baseline runs 2 and 7; first head runs 1 and 7. These cases are disclosed rather than counted as suppressed notifications.
- The after overlay adds production awareness-projection lines; the overlay and model-label masking are capture instrumentation.
- R2 includes the requested extra user message; R3’s unsuccessful steering setup left a prepared composer message but did not submit it.
- The VM’s overload/freeze messages and gaps can affect timing. Successful real-app captures were saved before the severe failure that lost the supplemental release harness.

### Drivers and reproduction material

All files are synthetic scratch artifacts; nothing was committed. Provider/model selection is intentionally absent from published scripts. The driver prompt was submitted through the app, and project creation used the shipped project-add CLI. The awareness reader uses `readonly:true` and never initializes or migrates a database. The release harness is an **attempted supplemental client harness**, not proof: its nominal scheduled offsets diverged under VM stalls and no recording could be recovered.

[driver-prompt.txt](https://gh-file-drop-api-prod-mi5fy3sowv63ufte.pinglabs.workers.dev/f/eea2afcf63577f14/driver-prompt.txt)
[recorder.js](https://gh-file-drop-api-prod-mi5fy3sowv63ufte.pinglabs.workers.dev/f/4fe56374985b7446/recorder.js)
[read-runs.py](https://gh-file-drop-api-prod-mi5fy3sowv63ufte.pinglabs.workers.dev/f/c5a110967c2c5a86/read-runs.py)
[awareness-observer.js](https://gh-file-drop-api-prod-mi5fy3sowv63ufte.pinglabs.workers.dev/f/1c9e7f31679d9b7e/awareness-observer.js)
[awareness-reader.mjs](https://gh-file-drop-api-prod-mi5fy3sowv63ufte.pinglabs.workers.dev/f/f4bd54a5bf6065f2/awareness-reader.mjs)
[replay-captured-awareness.mjs](https://gh-file-drop-api-prod-mi5fy3sowv63ufte.pinglabs.workers.dev/f/932b111479582ae1/replay-captured-awareness.mjs)
[steer-on-wake.js](https://gh-file-drop-api-prod-mi5fy3sowv63ufte.pinglabs.workers.dev/f/87fb874a5306fc21/steer-on-wake.js)
[release-harness.js](https://gh-file-drop-api-prod-mi5fy3sowv63ufte.pinglabs.workers.dev/f/3b1c915e4695a28b/release-harness.js)

### Unverified and excluded

- **R1/F4:** no-next-run release exactly after five seconds, with an unchanged shell update not resetting the deadline. The attempted supplemental recording was lost.
- The strict per-run alert expectation is not established for completions the client never observed. R2 separately verifies initial-user and terminal-command allowed completions on head.
- F16 reconnect during grace and F3 two monitors were not captured; the brief assigns those to existing PR tests unless time remains.
- P1–P6 and unchanged F9–F14 were excluded by scope. No desktop OS notification or physical push delivery claim.

FRICTION:
```text
infra | Shared VM load rose from 33 to above 60 on 8 cores, with server stalls and preview timeouts; supplemental release recordings were lost | Capture on an unloaded VM or reserve memory/CPU for the two dev apps and browser
tool | Steering composer control changes label to “Steer message” while running; the first hook targeted “Submit message” | Inspect the active-run control label before arming the hook
tool | Preview blank navigation rejected about:blank; opening without a URL worked | Use preview_open with no URL for a blank tab
```

AI-assisted; verified with the tests and tools listed above.