CAP-050/CAP-051 findings: PRIV-001 repeat and qhr field 13 ANC-parallel-path

Full non-sampled tshark analysis of both captures. CAP-050 (Group AG
repeat): 14 full samples across 16 reconnects resolve 5/7 previously
unmapped PRIV-001 codes to "not a match"; 2/7 remain inconclusive; no
evidence of the recalled mis-docking event. CAP-051 (Group AM): all 4
ANC actions confirm DLCI 0x04's Notify-without-Set pattern for physical
gestures (CAP-038 hypothesis), with a clean negative for any parallel
DLCI 0x02 qhr field-13 write.

Findings and proposed PROTOCOL.md updates / new Test-ID (ANC-005) are
flagged as proposals awaiting maintainer sign-off per AGENTS.md §6/§15
and are not yet promoted to FACT or written into DECISIONS.md.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Author: tedsluis

CAPTURE_BLUETOOTH_HCI_SNOOP.md

@@ -1809,8 +1809,8 @@ is how the 2026-08-18 `CAP-005`/`CAP-007`/`CAP-010` ID-reuse incident (see
 | `CAP-047` | *planned* | Pixel 7a | TBD | TBD | TBD | AL (new) | none existing — flagged as a `TESTPLAN_BLUETOOTH_HCI_SNOOP.md` follow-up, not assigned here (see `CAP-047-EVENT-NOTES.md`) | Purpose-built hypothesis test for the `CAP-021` DLCI 0x0a burst trigger — up to 3 bracketed sub-sessions (app background/foreground, long idle window, charge-state change), per `PROJECT_RULES.md` §4's fixed template | — | — | planned |
 | `CAP-048` | 2026-09-12 | Pixel 7a | 17 | release_5.203 (⚪ assumed) | 1.0.955078536 | AD (repeat) | `OBS-004` | Repeat of `CAP-037`'s dock-state anomaly with an open ACL, with continuous physical dock-state video | `captures/CAP-048-2026-09-12_17-41-41_17-52-44-Group_AD/CAP-048-btsnoop_hci.log` (`.log.last` present, determined leftover pre-session content, not used) | same file | analyzed — see `CAP-048-FINDINGS.md`. **`CAP-037`'s own flagged anomaly directly resolved**: a mid-connection `Settable-toggles` flip with no preceding Get is confirmed, via video at the exact wire timestamp, to be a genuine real-time docking action — consistent with ADR-016 (disconnect follows once the second bud docks too). 13/13 zero-miss ADR-022 replication. **A genuine, video-confirmed counter-example to a simple ADR-024 reading**: two fresh reconnects report "docked" while the case is visibly empty on video — reported plainly, not reconciled away. The draft's own claimed 25-reconnect rapid-alternation table does not survive verification — actual cadence was much slower/less regular. Bonus: an unexplained 7-event connection-retry burst, plausibly linked to a closed case |
 | `CAP-049` | 2026-09-12 | Pixel 7a | 17 | release_5.203 (⚪ assumed) | 1.0.955078536 | AF (repeat) | `OBS-006` | Repeat of `CAP-039`'s unexplained disconnect/reconnect cycling, with continuous phone-screen recording | `captures/CAP-049-2026-09-12_18-13-54_18-21-49-Group_AF/CAP-049-btsnoop_hci-combined.log` (genuine same-session `.log.last` rotation, safely combined per this session's own Step G method — see `CAP-049-FINDINGS.md` §0; video renamed from `-recordings.mp4`) | combined file (main+`.log.last`) | analyzed — see `CAP-049-FINDINGS.md`. **Clean negative: the cycling did not reproduce** — after one deliberate reconnect, the classic connection stays open and stable for the rest of the ~9-minute session (RFCOMM traffic still flowing near the log's own end). `OBS-006`'s Set-vs-Get `Settable-toggles` comparison confirmed consistent (both `0xe8`), a further same-session ADR-024 confirmation |
-| `CAP-050` | *planned* | Pixel 7a | TBD | TBD | TBD | AG (repeat) | `PRIV-001` | Repeat of `CAP-040`'s DLCI 0x08 unmapped Get-shaped codes correlation, this time using a trigger confirmed to actually reopen DLCI 0x08 (OS Bluetooth toggle or physical dock/undock), not the app's own Connect/Disconnect buttons | — | — | planned |
-| `CAP-051` | *planned* | Pixel 7a | TBD | TBD | TBD | AM (new) | none existing — flagged as a `TESTPLAN_BLUETOOTH_HCI_SNOOP.md` follow-up, not assigned here (see `CAP-051-EVENT-NOTES.md`); incidental `ANC`-family, `TOUCH-007` | `qhr` field 13 ANC-parallel-path wire confirmation — isolated in-app tap and isolated physical press-and-hold gesture, checking whether either correlates with a DLCI 0x02 `field13` write alongside DLCI 0x04's confirmed path | — | — | planned |
+| `CAP-050` | 2026-09-14 | Pixel 7a | 17 (⚪ assumed, carried over) | ⚪ assumed `release_5.203` (carried over) | 1.0.955078536 (⚪ assumed) | AG (repeat) | `PRIV-001` | Repeat of `CAP-040`'s DLCI 0x08 unmapped Get-shaped codes correlation, this time using a trigger confirmed to actually reopen DLCI 0x08 (OS Bluetooth toggle or physical dock/undock), not the app's own Connect/Disconnect buttons | `captures/CAP-050-2026-09-14_21-01-01_21-13-30-Group_AG/CAP-050-btsnoop_hci.log` | same file, raw path, 0/20,060 truncated | analyzed — see `CAP-050-FINDINGS.md`. **Session-local DLCI reassignment confirmed a second time** (one reconnect placed HFP, not the private envelope, on DLCI 0x08) — the private envelope was re-identified per reconnect by content signature, giving 15 confirmed + 1 inconclusive channel opens (not the video's own "well over 20" in-app-label estimate). All 7 `PRIV-001`-flagged codes fire on every private-envelope (re)open (14 full samples, vs. `CAP-040`'s N=1); 5 of 7 resolve to "not a match"/"no candidate found" (constant neighbors), 2 (`04 04`/`04 15`) remain inconclusive — their neighbors (`04.05`/`04.16`) fluctuate near dock-state changes but don't reproduce for the same physical configuration across reconnects. Both of `CAP-050-EVENT-NOTES.md`'s own flagged ambiguous dock-state windows resolved via wire+video correlation; one genuine `Settable-toggles` stale-reading counter-example found (consistent with `CAP-048-FINDINGS.md` §5's already-documented pattern, not a new contradiction of `DECISIONS.md` ADR-024). No clear video evidence of the maintainer-recalled mis-docking event at the review densities applied |
+| `CAP-051` | 2026-09-14 | Pixel 7a | 17 (⚪ assumed, carried over) | ⚪ assumed `release_5.203` (carried over) | 1.0.955078536 (⚪ assumed) | AM (new) | none existing — a candidate Test-ID (`ANC-005`) is proposed in `CAP-051-FINDINGS.md` §5 item 4, awaiting maintainer sign-off; incidental `ANC`-family, `TOUCH-007` | `qhr` field 13 ANC-parallel-path wire confirmation — isolated in-app tap and isolated physical press-and-hold gesture, checking whether either correlates with a DLCI 0x02 `field13` write alongside DLCI 0x04's confirmed path | `captures/CAP-051-2026-09-14_21-42-55_21-44-09-Group_AM/CAP-051-btsnoop_hci.log` | same file, raw path (confirmed, not just claimed), 0/2,457 truncated | analyzed — see `CAP-051-FINDINGS.md`. **All four ANC-mode actions confirmed against DLCI 0x04's already-FACT path**: the in-app tap produces a genuine `Set`(`0x12`)+ACK+`Notify` sequence; all three physical press-and-hold gestures produce only a spontaneous `Notify`(`0x13`) with no preceding `Set`/`Get` anywhere in the log — directly confirming `CAP-038-FINDINGS.md` §5's previously-unconfirmed "physical gesture" hypothesis for its own Get-less/Set-less Notify frames. **Central Group AM question: clean, confirmed negative** — no `field5{field4{field13=N}}` write (or any DLCI 0x02 `Sent`-direction payload at all) appears on DLCI 0x02 for any of the four actions, contrasting with `REVERSE_ENGINEERING.md`'s own `qhr`-entry static-analysis finding (a real, compiled write path exists for both triggers) — not contradicted, but not observed to fire in this session |
 | `CAP-052` | *planned* | Pixel 7a | TBD | TBD | TBD | AN (new) | none existing — flagged as a `TESTPLAN_BLUETOOTH_HCI_SNOOP.md` follow-up, not assigned here (see `CAP-052-EVENT-NOTES.md`) | `CAP-041` Case%-change bracket — ≥30-minute session with a genuine Case battery charge/discharge, to test whether DLCI 0x02's recurring 2-field sub-message actually tracks Case% or merely coincided with a constant value | — | — | planned |
 | `CAP-053` | *planned* | Pixel 7a | TBD | TBD | TBD | AO (new) | `EQS-004`, `EQP-008` | EQ outer field 16-vs-18 — drag-and-release without ever tapping Save, isolated from the newly-found navigate-away trigger too, added `ai-sessions/0017` | — | — | planned |
 | `CAP-054` | *planned* | Pixel 7a | TBD | TBD | TBD | AP (new) | `BATT-002`, `BATT-003` | Connection-free Battery Notification scan bracketing a single-bud insertion/removal event (per the Fast Pair spec's own "optional" trigger condition), added `ai-sessions/0017` | — | — | planned |

TESTPLAN_BLUETOOTH_HCI_SNOOP.md

@@ -167,7 +167,7 @@ _Physical interactions with the device._
 | `TOUCH-004` | Triple-tap on a bud | User (Hardware) | N | 🔵 | Previous track. **Captured 2026-08-30 (`CAP-027`)** — confirmed on AVRCP, not RFCOMM. | `CAP-027-FINDINGS.md` §3 |
 | `TOUCH-005` | Swipe forward on a bud | User (Hardware) | N | 🔵 | Raise volume. **Captured 2026-08-30 (`CAP-027`)** — confirmed on AVRCP, not RFCOMM. | `CAP-027-FINDINGS.md` §3 |
 | `TOUCH-006` | Swipe backward on a bud | User (Hardware) | N | 🔵 | Lower volume. **Captured 2026-08-30 (`CAP-027`)** — confirmed on AVRCP, not RFCOMM. | `CAP-027-FINDINGS.md` §3 |
-| `TOUCH-007` | Press and hold on a bud | User (Hardware) | N | 🔵 | Cycles ANC mode (incl. Adaptive) **or** activates Gemini/digital assistant, depending on per-earbud configuration (see `HOLD-*`). Requires Android 6.0+. **Captured 2026-08-30 (`CAP-027`)** — unlike `TOUCH-002`–`TOUCH-006`, confirmed on RFCOMM DLCI 0x04 (official Fast Pair Message Stream ANC Notify), not `libmaestro`. | `CAP-027-FINDINGS.md` §4 |
+| `TOUCH-007` | Press and hold on a bud | User (Hardware) | N, AM | 🔵 | Cycles ANC mode (incl. Adaptive) **or** activates Gemini/digital assistant, depending on per-earbud configuration (see `HOLD-*`). Requires Android 6.0+. **Captured 2026-08-30 (`CAP-027`)** — unlike `TOUCH-002`–`TOUCH-006`, confirmed on RFCOMM DLCI 0x04 (official Fast Pair Message Stream ANC Notify), not `libmaestro`. **Second confirming session, 2026-09-14/15 (`CAP-051`, Group AM):** three isolated physical gestures, video-confirmed, each producing a `Notify`(`0x13`)-only frame with no preceding `Set`/`Get` — reproduces `CAP-027`'s mechanism and directly confirms `CAP-038-FINDINGS.md` §5's own previously-unconfirmed "physical gesture" reading for its two Get-less/Set-less Notify frames. No accompanying DLCI 0x02 write found (clean negative, `CAP-051-FINDINGS.md` §3). | `CAP-027-FINDINGS.md` §4, `CAP-051-FINDINGS.md` §2/§3 |
 | `HEAD-002` | Head gesture: Nod | User (Hardware) | O, AQ | 🔵 | Answers a call. Can also reply to a text via dictation if 'Spoken notifications' is on — English only. **Attempted 2026-09-12 (`CAP-028`) — inconclusive**: gestures not camera-visible (recording frames the phone, not the head); zero wire-visible traffic on the Buds' own connection, but no active call/notification existed for the gesture to act on, so this cannot distinguish "functionally inert, as expected" from "gesture not actually triggered." **Re-checked 2026-09-13 (`ai-sessions/0017`)**: the same clean-negative result re-confirmed across `CAP-028`'s *entire* 227.71s log (not just the originally-checked window), plus zero AT+/HFP, AVRCP, or SCO/eSCO traffic anywhere in the log — no new signal found. A correctly-scoped repeat (an actual call/notification active, camera also framing the gesture itself) is designed as `CAPTURE_BLUETOOTH_HCI_SNOOP.md` Group AQ (planned `CAP-055`). | `CAP-028-FINDINGS.md` §4 |
 | `HEAD-003` | Head gesture: Shake | User (Hardware) | O, AQ | 🔵 | Rejects a call. Can also dismiss a text reply under the same condition. **Attempted 2026-09-12 (`CAP-028`) — inconclusive, same caveat as `HEAD-002`.** **Re-checked 2026-09-13 (`ai-sessions/0017`)** — same full-log re-verification and Group AQ repeat design as `HEAD-002` above. | `CAP-028-FINDINGS.md` §4 |
 | `CONV-002` | User starts speaking (voice), triggering Conversation Detection | User (Hardware) | P | 🟢 | Triggers Conversation Detection (if on) — pauses media, switches to Transparency. **Attempted 2026-09-12 (`CAP-029`) — clean negative**: media visibly pauses on screen, but zero DLCI 0x02/0x04/0x08 traffic accompanies it, and no ANC-mode change occurs anywhere in the session. | `CAP-029-FINDINGS.md` §2 |
@@ -264,7 +264,7 @@ exercise HFP's Service Level Connection setup and channel 5/DLCI 0x0a's audio pa
 | `GSND-001` | Whether DLCI 0x08 ("GSND CONTROL"), 0x0a ("GSND AUDIO"), 0x06 ("DEBUG APP"), or 0x12 ("BTIS") — service names `CAP-033-FINDINGS.md` §3's SDP browse found on the Buds' own SDP database — are opened/used by a phone with no Google Play Services present at all (Pixel 9a, GrapheneOS), no Pixel Buds app, no third-party GATT/BLE tool | App/OS (Auto) | AB | 🟡 | Added 2026-09-02. A full, mechanical companion-APK search (per `ADR-017`'s boundary) found zero references to any of these names/UUIDs anywhere in the app's decompiled code — the app never registers or looks up these services itself, leaving two candidate explanations open: the OS/vendor Bluetooth stack connects to them independent of any app, or Google Play Services' Nearby module does. **Attempted 2026-09-02 (`CAP-035`), maintainer sign-off obtained per `AGENTS.md` §6:** DLCI 0x08's content reproduces byte-identical, twice in one session (fresh connect and reconnect), with Google Play Services present but `dumpsys`-*verified* disabled (`com.google.android.gms enabled=3` = `COMPONENT_ENABLED_STATE_DISABLED_USER`) — a materially more rigorous confirmation of `CAP-004-FINDINGS.md` §4a's existing "GMS present but disabled" finding, on a different phone/OS, still short of the genuinely GMS-*absent* test this row was originally designed around. DLCI 0x0a opens in lockstep with 0x08 both times but carries zero payload both times; DLCI 0x06/0x12 never open at all, anywhere in the session — clean negatives for both. See `CAP-035-FINDINGS.md` for the full command+hex evidence. **Still open, for full closure:** a repeat with `com.google.android.gms` genuinely uninstalled rather than merely disabled. | `CAP-004-FINDINGS.md` §4b, `CAP-035-FINDINGS.md` |
 | `SDP-001` | Which RFCOMM/SDP UUID(s) the companion app's own channel-selection logic (`gbm.java`, `REVERSE_ENGINEERING.md`) sees when SDP is queried via the OS's own pairing flow only (app force-stopped, never opened), vs. the baseline where the app has already opened and can run its own `fetchUuidsWithSdp()` (`fxm.java:110`) | App (Auto) / User (Hardware) | AA | 🔴 | Added 2026-08-30. Tests whether the "default internal rfcomm socket" UUID (`3a046f6d-...`, `REVERSE_ENGINEERING.md`'s `gbm`/`fzd` entries, `DECISIONS.md` ADR-018) ever appears before the app's own re-fetch has a chance to run — every capture on file to date (26 files, every format this project has — `*btsnoop_hci.log`, `*btsnooz_hci.log`, both nRF Connect logs — see `REVERSE_ENGINEERING.md`'s `gbm` entry Open questions) shows only the "pigweed" UUID (`25e97ff7-...`), always in a session where the app had already opened. **Attempted 2026-08-30 (`CAP-033`) — still 🟡 HYPOTHESIS, not resolved**: a confirmed procedure-order deviation (Forget before Force-stop) and a missing app-open comparison half cap the result short of FACT; "default" UUID still not observed. **2nd attempt 2026-09-13 (`CAP-044`) — still 🟡 HYPOTHESIS, a different isolation gap**: Force-stop now correctly precedes Forget, and step 3 (app-open) is executed on-camera this time, but no Force-stop is confirmed covering the ~2m8s window before the actual "Pair" tap that triggers the one SDP browse in the log, and step 3 produces no second SDP transaction to compare against (the classic connection never drops in between) — "default" UUID absent a 5th consecutive time; a procedure refinement (an explicit on-device process-liveness check before the "Pair" tap) is proposed for a possible 3rd attempt. | `CAP-033-FINDINGS.md` §1/§5; `CAP-044-FINDINGS.md` §2/§4/§5 |
 | `SDP-002` | Whether an actual firmware OTA update changes which of the two internal-RFCOMM-socket SDP UUIDs (`gbm`/`fzd`, `DECISIONS.md` ADR-018) the Buds/case advertise | Buds/Case (Auto) | AA | 🔴 | Added 2026-08-30. Opportunistic only — needs an actual pending firmware update to become available, same caveat as `FWUPD-001`/`FWUPD-002`. Tests the hypothesis that the "pigweed"/"default" UUID pair is a pre-/post-migration artifact, not a live runtime choice. **Not attempted 2026-08-30 (`CAP-033`)** — no update was pending. | `CAP-033-FINDINGS.md` §6 |
-| `PRIV-001` | Semantic decode, via correlation not guessing, of DLCI 0x08's unmapped zero-length `[Group][Code][00 00]`-shaped `Sent` frames (`05 0c`, `04 02`, `04 04`, `04 11`, `04 13`, `04 15`, `0e 04`) found in `CAP-036-FINDINGS.md` §5, structurally identical to DLCI 0x04's confirmed "Get" pattern but never attributed to any known setting | App/OS (Auto) | AG | 🔴 | Added 2026-09-05. Per `AGENTS.md` §13.6's zero-creativity rule, these can only be decoded by bracketing a known, independently-verifiable changing value (battery discharge, or deliberately varied dock state) across several reconnects and checking whether any `Rcvd` response tracks it. **Attempted 2026-09-06 (`CAP-040`) — inconclusive, not resolved:** the session's own procedure deviation (app Connect/Disconnect buttons producing zero wire signal, `CAP-040-FINDINGS.md` §1) meant DLCI 0x08 only opened once, so every one of the 7 codes has N=1, no bracket to correlate against. Still needs a re-run with a trigger that genuinely reopens DLCI 0x08. | `CAP-040-FINDINGS.md` |
+| `PRIV-001` | Semantic decode, via correlation not guessing, of DLCI 0x08's unmapped zero-length `[Group][Code][00 00]`-shaped `Sent` frames (`05 0c`, `04 02`, `04 04`, `04 11`, `04 13`, `04 15`, `0e 04`) found in `CAP-036-FINDINGS.md` §5, structurally identical to DLCI 0x04's confirmed "Get" pattern but never attributed to any known setting | App/OS (Auto) | AG | 🔴 | Added 2026-09-05. Per `AGENTS.md` §13.6's zero-creativity rule, these can only be decoded by bracketing a known, independently-verifiable changing value (battery discharge, or deliberately varied dock state) across several reconnects and checking whether any `Rcvd` response tracks it. **Attempted 2026-09-06 (`CAP-040`) — inconclusive, not resolved:** the session's own procedure deviation (app Connect/Disconnect buttons producing zero wire signal, `CAP-040-FINDINGS.md` §1) meant DLCI 0x08 only opened once, so every one of the 7 codes has N=1, no bracket to correlate against. **Repeated 2026-09-14/15 (`CAP-050`), a genuine dock/undock trigger, 14 full samples — largely resolved, not fully closed:** 5 of 7 codes now resolve to "not a match"/"no candidate found" against the dock-state bracket (their nearest non-zero-length neighbors are byte-identical across every reconnect); the remaining 2 (`04 04`/`04 15`) stay 🔴 open — their neighbors (`Group 0x04 Code 0x05`/`Code 0x16`) fluctuate near dock-state changes but do not reproduce for the same physical dock configuration across different reconnects, so no semantic reading is proposed. | `CAP-040-FINDINGS.md`, `CAP-050-FINDINGS.md` §3/§4 |
 
 ---