# Proof audit, pass 2 — corrected inventory

## Findings

1. **Missing exercised evidence: B4, B5a, B8.** The changed attention key controls delivery count for focused in-app toasts, sounds, and root attention aggregated from child requests. Neither the supplied transcript nor the delivered browser test exercises these cases. The test fixes `inApp = false`, `focused = false`, `mode = notifications`, and supplies root-only shells. A mock existing in a test is not an exercised assertion. Source tracing makes the expected behavior clear, but does not satisfy this pass's explicit requirement that every affected row be covered by a test or transcript. Small focused cases in the existing harness, with event-count assertions, would close these gaps; screenshots are unnecessary.
2. **Pass-1 claims are stale and corrected below.** B2's changed-request-ID notification is contradicted by current code and the passing regression. B1 now uses status alone. B3 now has parameterized queue/overlap/reset coverage. B4 must not promise another toast merely for a new request ID while status stays constant. B8 no longer uses an empty request-ID prefix. These are corrections to the old inventory, not defects in the current implementation.

No contradicted claim was found within the supplied runtime transcript. Its current-head result is precisely **zero additional Notification constructor calls after reload and two more queued messages**, not a fresh one-notification run at current HEAD. The one-notification fresh sequence belongs to the earlier revision. Its background Read-call observation does not exercise child approval/input aggregation or establish the issue's original every-tool-call trigger.

## Identity and scope

Reviewed [#24882](https://git.cafe/pingdotgg/t3code/issues/24882), branch `fix/issue-24882`, worktree `/home/ubuntu/wt/issue-24882`.

- Current HEAD: [8e83c58ac3](https://git.cafe/pingdotgg/t3code/commit/8e83c58ac34c2479ac8b3b33402dfe2e8a877393), independently resolved from the checkout before and after the test.
- Pinned base: [f3b058cd6a](https://git.cafe/pingdotgg/t3code/commit/f3b058cd6a737e51894bc265927560b23742f0f0), independently resolved and verified as an ancestor; `git merge-base f3b058cd6a 8e83c58ac3` returns this base.
- Interim: [107c2c98c6](https://git.cafe/pingdotgg/t3code/commit/107c2c98c679435b134ee2d9f817615c99ae0fae), independently resolved and inspected. Its key is request ID plus status; current HEAD is status alone.
- Local `main` is older and resolves to [184d915d87](https://git.cafe/pingdotgg/t3code/commit/184d915d8774615a01ebae0350235a1039852e85). Its merge-base with HEAD differs. All review comparisons use the requested pinned base; this is not a patch or evidence mismatch.
- Exactly three changed files: coordinator key construction, a logic-file comment, and the browser regression/fixture. No rendered component, notification payload, toast icon/style/action, badge implementation, provider adapter, wire contract, or mobile code changes.

## Visual matrix

| Fixture | Data/route | Presentation change | Viewport × theme | Capture | Status |
| --- | --- | --- | --- | --- | --- |

**Empty: zero rows and zero required captures.** Delivery frequency changes; rendered presentation rules do not. The coordinator is a startup service, called from web app initialization and shared with the Electron renderer. It has no rendered surface of its own. Approval card, queue count, settings, sidebar, theme, width, title wrapping, and native notification appearance remain unchanged. A still would not prove absence of a later duplicate. No capture rebuilding applies. This does not excuse missing behavioral evidence in affected rows.

## Corrected behavioral inventory and coverage

`T` below means the delivered browser test at current HEAD, independently executed here. `R-base`, `R-interim`, and `R-head` mean the respective sections of the supplied runtime transcript. Historical red results are reported by the task brief; they were not independently rerun. Code-predicted counts are explicitly labeled and are not runtime observations.

| Row | Current behavior / exact sequence | Affected? | Test or transcript at stated revision | Status |
| --- | --- | --- | --- | --- |
| B1 — Direct approval, queued runs | After a working baseline, approval A appears; latest run changes R1 → R2 → R3 while status stays approval. One initial announcement, no repeats. Key is `approval`, independent of both identities. | Yes, versus pinned base. | T approval case covers run churn and overlaps together: final count 1. R-base records 4 constructor calls for initial request + 3 queues. R-interim records 1 for that sequence. R-head records 0 additional after reload + 2 queues. T at head supplies the fresh initial-announcement proof absent from R-head. | COVERED |
| B2a — Overlapping approvals / request replacement | With status continuously approval and latest run fixed, shown request A → B → A stays at one announcement. A genuinely different request ID does not itself re-arm attention. This replaces old B2. | Yes versus interim; same-run ID changes were already silent at pinned base. | T approval case explicitly sets request-1 → request-2 → request-1 and asserts `[Approval needed]`. Not exercised by R-head, which retains the same request. Brief reports the delivered test fails at interim; the request-key source explains why. | COVERED |
| B2b — Clear and re-arm | Approval → working/no pending request → approval C, with the same latest run, yields a second announcement. This distinguishes status-contiguous suppression from permanent suppression. | Preserved behavior, essential boundary of the changed key. | T approval case asserts the second title after clearing then request-3. No runtime claim made for this sequence. | COVERED |
| B3 — Direct blocking user input | Input A stays input through run churn and A → B → A request changes: one announcement. Clear to working and show C: second announcement. Nonblocking input while working is excluded by unchanged shell presentation. | Yes for blocking input churn; nonblocking classification unchanged. | T input parameter case exercises the same complete sequence as B1/B2, asserting `[Input needed]` then two titles. R contains approvals only. Nonblocking classification is code-inspected, not claimed as newly exercised. | COVERED for affected behavior |
| B4 — Focused other-thread in-app toast | Visible/focused client on another thread/environment or Settings; in-app enabled. One add across same-status run/request churn; another only after leaving/re-entering that status (or a category change). Payload remains identical. | Yes, add-event count. | T disables in-app delivery and forces unfocused. R forces unfocused and records Notification constructors. Neither counts focused toast adds. Shared upstream gate is source-traced only. | MISSING |
| B5a — Sound delivery | Sound or notifications-and-sound mode: same-status run/request churn must not replay sound; clearing/re-entering can play again. | Yes, play-event count. | T mocks sound but uses notifications-only mode during churn; the old badge test switches to sound only for cleanup, with no subsequent churn or sound-count assertion. R explicitly uses Notifications only. | MISSING |
| B5b — Suppressed delivery | Focused target thread, disabled in-app while focused, unavailable Notification API, denied permission: delivery suppression rules unchanged. | No changed suppression rule. | Source inspection only. No assertion of fresh behavioral coverage; no changed presentation fixture. | UNCHANGED / N/A |
| B6 — Baseline/lifecycle/interaction | First sighting suppresses attention. Archive, loss of snapshot, removal, environment/settings cleanup and click navigation retain existing rules. Re-observed same pending status after reload remains silent across queued runs. | Lifecycle rules unchanged; current-key continuation after baseline is relevant. | R-head records reload then two queues with 0 calls. Existing T badge cases cover approval/input initial notification, click navigation, and disabling notification badge cleanup. Other lifecycle branches were inspected, not newly run as separate cases. | COVERED for reload/churn; remainder UNCHANGED |
| B7 — Guest request, failure, limit, completion | Guest/failure/limit retain run-plus-status keys. Completion retains settled-time/grace/cancellation behavior. | No. | Existing completion T case passed. Other branch implementations are unchanged; no claim of new runtime coverage. | UNCHANGED / N/A |
| B8 — Aggregated subagent attention | Child approval/input raises root category. Children are skipped for direct notification. Root key is just `approval` or `input`, regardless of absent/direct request ID; root run churn during aggregate attention must stay silent. Same-category direct/child handoff also stays silent. | Yes, versus pinned base on root run churn and versus interim on direct/aggregate identity handoff. | T shells are root-only (`relationshipToParent: null`) with no pending children. R's background Read calls have no pending child approval/input and do not cover aggregation. Production aggregation and status priority were traced only. | MISSING |
| B9 — Client/platform/title/theme/width | Web and Electron share this coordinator; native mobile is separate. Notification payload, tag, body, icons, toast layout and theme/width behavior are unchanged. Badge counts distinct thread tags, so duplicate same-thread construction is not an increasing-badge regression. | No presentation change; shared upstream behavior covered to the limits above. | T and R record Notification construction, not native OS rendering or Electron IPC. No native-rendering claim. | UNCHANGED / N/A |
| B10 — Approval/input category switch | Approval → input or input → approval announces the changed category even without a null-attention gap. One continuous mixed set of requests can therefore announce again when the selected category changes. This is once per contiguous status, not once per entire pending-request set. | Observable rule preserved from pinned base and interim. | Source inspection: old and new keys differ whenever the category differs; unchanged gate announces changed non-null keys. The delivered tests parameterize categories separately and do not exercise a mixed-category sequence. | UNCHANGED / N/A; not dynamically tested |

## Transcript claim audit

Source: [runtime transcript](https://gh-file-drop-api-prod-mi5fy3sowv63ufte.pinglabs.workers.dev/f/af0767bc1b53e783/runtime-transcript.md), downloaded using curl as requested. It is a first-person runtime record, not a bundle of underlying browser/SQL/server logs. Runtime facts below remain attributed to that record; this audit did not independently recreate them.

| Claim | What the delivered evidence actually shows | Assessment |
| --- | --- | --- |
| Fresh isolated dev setup on fs-15; paired client; Sonnet 5.5 Supervised; Bash touch waiting; Notifications only; recorder and forced unfocused state | Setup paragraph specifies all of these. No supporting launch/SQL/browser logs are attached. T independently uses the same relevant delivery mode and focus/recorder conditions, but a synthetic root shell rather than Claude. | Recorded setup, not independently verified runtime provenance. No contradiction found. |
| Pinned base has one pending approval and four notifications after three queued messages | Base section names the correct resolvable SHA, records one pending row/creation time, and lists four timestamped Approval needed calls labeled initial + queues one/two/three. Its source keys by latest run, consistent with duplicates when queues change that run. | Supported by supplied runtime record; exact total 4. Not a universal every-tool-call reproduction. |
| About ten background subagent Read calls caused no extra notification at base | A separate sentence records this observation. No per-call log or child request is attached. | Limited to incidental Reads; not evidence for B8 or for dedupe of child requests. No contrary claim made. |
| Interim head produces one notification after three queues | Interim section names the correct resolvable SHA, records one pending row/creation time, one timestamped call, and `3 queued` with no further calls. Request-key source is consistent. | Supported for interim only. Must not label this the fresh current-head run. |
| Current head reload sees the same still-pending request, then two additional queues with no notification | Head section names the correct resolvable SHA, reports status pending, reload, recorder reinstallation, `5 queued`, and no recorded calls. It does not record request ID/creation time again or fresh first-announcement behavior. | Supports the reported post-reload zero-additional result. Exact cross-reload identity is an operator report, not independently reconstructible from identifiers in this artifact. T supplies separate initial and overlap behavior proof. |
| First sighting never notifies | Gate returns immediately when no prior observation exists, before attention delivery. | Consistent with current source and the reload result; not a new behavior introduced by the patch. |
| Approval/input now keyed on status | Current coordinator source explicitly returns `status` for these two categories; pinned base and interim source have the different keys above. | Independently verified at exact checked-out HEAD. |

No transcript claim asserts native OS notification presentation. Replacing `window.Notification` proves constructor counts only. There is no focused-toast, sound, input-runtime, child-request-runtime, reminder, provider-feedback, or approval-reason claim in this transcript.

## Closeout revision change

After the requested-head test and source audit completed, a concurrent process moved the worktree to merge commit [9ef95ebd12](https://git.cafe/pingdotgg/t3code/commit/9ef95ebd12b5700d9b674a1128973fd6fb5c85df), whose first parent is the requested review head. This audit remains pinned to the requested head and base. The later merge was not audited or tested by this reviewer. No checkout/ref change was performed by this reviewer.

## Test execution

From `/home/ubuntu/wt/issue-24882/apps/web` at exact HEAD:

```text
$ vp test run src/components/ThreadNotificationCoordinator.badge.browser.test.ts
RUN v5.0.5 /home/ubuntu/wt/issue-24882/apps/web
Test Files  1 passed (1)
Tests       5 passed (5)
Start at    09:19:31
Duration    14.79s
exit code   0
```

The [unaltered test output](https://gh-file-drop-api-prod-mi5fy3sowv63ufte.pinglabs.workers.dev/f/4c30333de42bcbca/head-test.log) is uploaded separately.

The five cases are approval badge/click/cleanup, input badge/click/cleanup, completion grace, approval queue/overlap/re-arm, and input queue/overlap/re-arm. No real-app dev server was started or stopped, no worktree source was edited, and no forge write/comment/push occurred. The specified head test was the only test execution. All three changed files plus relevant gate, status, shell presentation, child aggregation, and production caller were inspected. Worktree status remained clean. Audit completed within the 60-minute budget.

FRICTION:
- other | Another process advanced the shared worktree after the pinned-head audit/test completed. | Preserve this result as a pinned-head audit; review later revisions separately.
- infra | Local main is older than the requested pinned base, so an unqualified main comparison would review the wrong range. | Use the brief's explicit base SHA, as done here.

VERDICT: INSUFFICIENT B4, B5a, B8