Skip to content

Commit 40dd5a5

Browse files
tedsluisclaude
tedsluis
and
claude
committed
docs: add EVENT-NOTES skeletons for planned captures CAP-053–CAP-057
Placeholder capture folders and EVENT-NOTES.md skeletons for the five new capture designs from session 0017 (Groups AO–AS), matching the existing convention used for CAP-047/CAP-050/CAP-051/ CAP-052. Each skeleton carries the Group's own Purpose/Procedure text, a Log Metadata table, a TBD Event Timeline pre-populated with the expected steps, and an Analysis checklist tailored to what that capture needs to resolve. Folders use the yyyy-MM-dd_HH-mm-ss placeholder naming and are to be renamed to the actual session timing once recorded. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HHfM6nQyQLddcxfWpfWjWw
1 parent 9193ea5 commit 40dd5a5

5 files changed

Lines changed: 429 additions & 0 deletions

File tree

‎captures/CAP-053-yyyy-MM-dd_HH-mm-ss_HH-mm-ss-Group_AO/CAP-053-EVENT-NOTES.md‎

Lines changed: 88 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,88 @@
1+
# Event Notes: Pixel Buds Pro 2 (`libmaestro` / `libgfps`) — Group AO (new), EQ outer field 16-vs-18: drag-and-release without ever tapping Save (`CAP-053`)
2+
3+
**Status:** 🔲 **Not yet captured — skeleton only.** Fill in every `TBD` below after recording,
4+
per `CAPTURE_BLUETOOTH_HCI_SNOOP.md` §5 (analysis) and §8 (what to update), and
5+
`PROJECT_RULES.md` rule 11/14 (reproducibility metadata). Once reviewed, rename this folder from
6+
the placeholder `CAP-053-yyyy-MM-dd_HH-mm-ss_HH-mm-ss-Group_AO` to the actual session
7+
date/start-time/end-time, e.g. `CAP-053-2026-09-15_08-30-00_08-40-00-Group_AO`.
8+
9+
**Purpose (`CAPTURE_BLUETOOTH_HCI_SNOOP.md` Group AO, added 2026-09-13,
10+
`ai-sessions/0017_MAINTENANCE_RESULT_2026_09_13.md` Phase 1):** `PROTOCOL.md` §4.2's "Outer field 16
11+
vs. 18" item is a genuine, unreconciled tension: `CAP-015`'s wire timing reads as "field 18 fires on
12+
slider-release" (no video-visible `Save` tap before any of 15 field-18 frames), but a full call-graph
13+
trace of `fyd.d`/`fyd.e` (`REVERSE_ENGINEERING.md`'s `qjw` entry) found field 18 (`fyd.d`) reachable
14+
through exactly **two** code paths — a dedicated `key_eq_save_button`/`title_eq_save_button` click
15+
handler (self-describing log `"On click save EQ button"`), and, newly found in session 0017, a
16+
**navigate-away-from-the-EQ-screen** path (`hod.java:36`, self-describing log `"Navigate away, save
17+
EQ"`, gated on an unsaved-changes-shaped flag) — but **no** slider-release code path to field 18
18+
anywhere in the decompiled source. This capture isolates all three candidate triggers from each
19+
other for the first time.
20+
21+
## Log Metadata
22+
23+
| Field | Value |
24+
|------------------|-----------------------------------------------------|
25+
| Capture ID | `CAP-053` |
26+
| Group(s) | AO (new) |
27+
| Date | TBD |
28+
| Firmware version | TBD |
29+
| Test device | TBD (Pixel 7a, official Pixel Buds Companion App; full DLCI 0x02 traffic retained, raw-path extraction) |
30+
| Video file | TBD — must clearly show, for each slider action: whether the `Save` button is touched, and whether the screen changes |
31+
| Log file | TBD — `CAP-053-btsnoop_hci.log` (raw path, not `btsnooz.py`) |
32+
| Buds MAC (partial, per `AGENTS.md` §7/§9) | TBD |
33+
34+
## Procedure (per `CAPTURE_BLUETOOTH_HCI_SNOOP.md` Group AO)
35+
36+
1. Open the EQ screen (Device details → Sound → Equalizer → custom sliders).
37+
2. Drag **slider 1** to a new position, release, and **wait ≥10s** with the `Save` button never
38+
tapped and **without navigating away from the EQ screen** (stay on this exact screen the whole
39+
time) — video must clearly show both: the `Save` button not being touched, and the screen not
40+
changing.
41+
3. Repeat step 2 for **slider 2** (a second, independent release-only sample, still without leaving
42+
the screen or tapping Save).
43+
4. As a clearly separated second half of the same session: drag **slider 3**, release, wait ≥10s (no
44+
Save tap, no navigation, replicating steps 2–3's isolation once more), then **deliberately tap the
45+
`Save` button** and video-confirm the tap.
46+
5. As a third, separated part: drag **slider 4**, release, wait ≥3s, then **navigate away from the EQ
47+
screen** (e.g. press back to Device details) without ever tapping `Save` — video must show the
48+
screen change clearly.
49+
50+
## Event Timeline
51+
52+
| Time | Action | Initiator | Test-ID | Wire evidence / Notes |
53+
|---|---|---|---|---|
54+
| TBD | Session start, raw-path HCI snoop logging confirmed | User | — | Conn. state: TBD |
55+
| TBD | Open EQ screen | User (App) | — | TBD |
56+
| TBD | Slider 1: drag + release, no Save, no navigation, ≥10s wait | User (App) | `EQS-*` | TBD |
57+
| TBD | Slider 2: drag + release, no Save, no navigation, ≥10s wait | User (App) | `EQS-*` | TBD |
58+
| TBD | Slider 3: drag + release, no Save, no navigation, ≥10s wait | User (App) | `EQS-*` | TBD |
59+
| TBD | Slider 3's write: `Save` button tapped, video-confirmed | User (App) | `EQP-008` | TBD |
60+
| TBD | Slider 4: drag + release, ≥3s wait | User (App) | `EQS-*` | TBD |
61+
| TBD | Navigate away from EQ screen (no Save tap), video-confirmed | User (App) | — | TBD |
62+
| TBD | Session end | — | — | TBD |
63+
64+
## Analysis checklist (per `CAPTURE_BLUETOOTH_HCI_SNOOP.md` Group AO)
65+
66+
- [ ] For sliders 1/2 (release-only, no Save, no navigation): does a `field5{field4{field18=...}}`
67+
write appear on DLCI 0x02 at any point? Expected: no, per the `hju`/`hod` code trace.
68+
- [ ] For slider 3's Save tap: confirm a field-18 write fires at that exact moment (the known,
69+
already-confirmed trigger).
70+
- [ ] For slider 4's navigate-away: does a field-18 write fire at the moment of navigation, matching
71+
the newly-found `hod.java` "Navigate away, save EQ" trigger?
72+
- [ ] Record the result plainly for each of the three conditions — a clean 3-way contrast (or a
73+
surprising positive on the release-only condition) both directly close `PROTOCOL.md` §4.2's
74+
own open item.
75+
76+
## Next steps after filling this in
77+
78+
- [ ] Cross-reference this session's own findings against `PROTOCOL.md` §4.2 and
79+
`REVERSE_ENGINEERING.md`'s `qjw` entry (`AGENTS.md` §13's traceability check).
80+
- [ ] Write `CAP-053-FINDINGS.md` per `PROJECT_RULES.md` §2, using this file's timeline as the
81+
evidence source, following the hex & script rule (§1 rule 4a).
82+
- [ ] Update this session's row in `CAPTURE_BLUETOOTH_HCI_SNOOP.md` §9 Capture Index — status
83+
from `planned` to `analyzed`, fill in Android/firmware/app-version columns and the log path.
84+
- [ ] Rename this capture's folder from the `yyyy-MM-dd_HH-mm-ss_HH-mm-ss` placeholder to the
85+
actual session date/start-time/end-time.
86+
87+
---
88+
https://github.com/tedsluis/opencontrolpixelbudspro2/blob/main/captures/CAP-053-yyyy-MM-dd_HH-mm-ss_HH-mm-ss-Group_AO/CAP-053-EVENT-NOTES.md - https://tedsluis.github.io/opencontrolpixelbudspro2/captures/CAP-053-yyyy-MM-dd_HH-mm-ss_HH-mm-ss-Group_AO/CAP-053-EVENT-NOTES

‎captures/CAP-054-yyyy-MM-dd_HH-mm-ss_HH-mm-ss-Group_AP/CAP-054-EVENT-NOTES.md‎

Lines changed: 86 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,86 @@
1+
# Event Notes: Pixel Buds Pro 2 (`libmaestro` / `libgfps`) — Group AP (new), Battery Notification: bracket a single-bud insertion/removal, connection-free (`CAP-054`)
2+
3+
**Status:** 🔲 **Not yet captured — skeleton only.** Fill in every `TBD` below after recording,
4+
per `CAPTURE_BLUETOOTH_HCI_SNOOP.md` §5 (analysis) and §8 (what to update), and
5+
`PROJECT_RULES.md` rule 11/14 (reproducibility metadata). Once reviewed, rename this folder from
6+
the placeholder `CAP-054-yyyy-MM-dd_HH-mm-ss_HH-mm-ss-Group_AP` to the actual session
7+
date/start-time/end-time, e.g. `CAP-054-2026-09-15_08-30-00_08-40-00-Group_AP`.
8+
9+
**Purpose (`CAPTURE_BLUETOOTH_HCI_SNOOP.md` Group AP, added 2026-09-13,
10+
`ai-sessions/0017_MAINTENANCE_RESULT_2026_09_13.md` Phase 2):** `CAP-043` (Group Q repeat)
11+
established, under rigorously clean connection-free isolation, that the Buds' idle/case-closed
12+
`0xFE2C` BLE advertisement does not structurally match `PROTOCOL.md` §4.3 Option A's documented
13+
Battery Notification layout — but only tested the idle/case-closed condition. The official Fast Pair
14+
spec itself describes the Battery Notification extension as "**optional** when a single bud is
15+
inserted/removed" — a materially different trigger condition, not yet bracketed by any capture to
16+
date.
17+
18+
## Log Metadata
19+
20+
| Field | Value |
21+
|------------------|-----------------------------------------------------|
22+
| Capture ID | `CAP-054` |
23+
| Group(s) | AP (new) |
24+
| Date | TBD |
25+
| Firmware version | TBD |
26+
| Test device | TBD (Pixel 7a, official Pixel Buds Companion App **force-stopped** for the entire session, matching `CAP-043`'s methodology) |
27+
| Video file | TBD — must show the system Bluetooth settings panel and the exact bud removal/re-insertion moments |
28+
| Log file | TBD — `CAP-054-btsnoop_hci.log` |
29+
| Buds MAC (partial, per `AGENTS.md` §7/§9) | TBD (expected: not observed, per `CAP-043`'s own isolation — no classic connection this session) |
30+
31+
## Procedure (per `CAPTURE_BLUETOOTH_HCI_SNOOP.md` Group AP)
32+
33+
1. Force-stop the official Pixel Buds app (as `CAP-043` did) and confirm, before starting the log,
34+
that no classic RFCOMM connection to the Buds is active (system Bluetooth settings showing
35+
"not connected," or the Buds already disconnected).
36+
2. Start HCI snoop logging and a screen/phone-camera recording of the system Bluetooth settings
37+
panel (matching `CAP-043`'s own methodology).
38+
3. With the case closed and the phone otherwise idle, **remove exactly one earbud from the case**
39+
(video-confirm the exact removal moment), then wait ≥15s without touching anything else.
40+
4. **Re-insert that same earbud** into the case (video-confirm), wait ≥15s again.
41+
5. Repeat steps 3–4 once more for the **other** earbud, as an independent second sample.
42+
6. Throughout, avoid opening the official app or making any classic RFCOMM connection — per
43+
`AGENTS.md` §7's bounded scanning exception (filtered to the bonded device, foreground-triggered,
44+
time-boxed).
45+
46+
## Event Timeline
47+
48+
| Time | Action | Initiator | Test-ID | Wire evidence / Notes |
49+
|---|---|---|---|---|
50+
| TBD | Session start, app confirmed force-stopped, no active connection | User | — | Conn. state: TBD |
51+
| TBD | Earbud 1 (Left/Right — specify) removed from case, video-confirmed | User (Hardware) | `CASE-004`/`CASE-005` | TBD |
52+
| TBD | Wait ≥15s, nothing touched | — | — | TBD |
53+
| TBD | Earbud 1 re-inserted into case, video-confirmed | User (Hardware) | — | TBD |
54+
| TBD | Wait ≥15s, nothing touched | — | — | TBD |
55+
| TBD | Earbud 2 (the other one) removed from case, video-confirmed | User (Hardware) | `CASE-004`/`CASE-005` | TBD |
56+
| TBD | Wait ≥15s, nothing touched | — | — | TBD |
57+
| TBD | Earbud 2 re-inserted into case, video-confirmed | User (Hardware) | — | TBD |
58+
| TBD | Wait ≥15s, nothing touched | — | — | TBD |
59+
| TBD | Session end | — | — | TBD |
60+
61+
## Analysis checklist (per `CAPTURE_BLUETOOTH_HCI_SNOOP.md` Group AP)
62+
63+
- [ ] Isolation check (per `CAP-043`'s own method): confirm zero classic connection, zero RFCOMM,
64+
zero SDP to the Buds' known classic address anywhere in this log.
65+
- [ ] For each of the 4 bracketed events (2 removals + 2 insertions), does a `0xFE2C` service-data
66+
advertisement carrying the documented Battery Notification layout
67+
(`[Flags=0x00][Account Key Data][0x33/0x34 marker][L][R][Case]`) appear within a few seconds?
68+
- [ ] If still a clean negative across all 4 events, record that plainly — this strengthens the case
69+
for reframing `PROTOCOL.md` §4.3 Option A's status, per `CAP-043-FINDINGS.md` §7's own
70+
recommendation (a maintainer decision, not to be made unilaterally here).
71+
- [ ] If a positive match is found, decode the payload per the documented layout and cross-reference
72+
against `AGENTS.md` §13.6's zero-creativity rule.
73+
74+
## Next steps after filling this in
75+
76+
- [ ] Cross-reference this session's own findings against `PROTOCOL.md` §4.3 Option A and
77+
`CAP-043-FINDINGS.md` (`AGENTS.md` §13's traceability check).
78+
- [ ] Write `CAP-054-FINDINGS.md` per `PROJECT_RULES.md` §2, using this file's timeline as the
79+
evidence source, following the hex & script rule (§1 rule 4a).
80+
- [ ] Update this session's row in `CAPTURE_BLUETOOTH_HCI_SNOOP.md` §9 Capture Index — status
81+
from `planned` to `analyzed`, fill in Android/firmware/app-version columns and the log path.
82+
- [ ] Rename this capture's folder from the `yyyy-MM-dd_HH-mm-ss_HH-mm-ss` placeholder to the
83+
actual session date/start-time/end-time.
84+
85+
---
86+
https://github.com/tedsluis/opencontrolpixelbudspro2/blob/main/captures/CAP-054-yyyy-MM-dd_HH-mm-ss_HH-mm-ss-Group_AP/CAP-054-EVENT-NOTES.md - https://tedsluis.github.io/opencontrolpixelbudspro2/captures/CAP-054-yyyy-MM-dd_HH-mm-ss_HH-mm-ss-Group_AP/CAP-054-EVENT-NOTES

‎captures/CAP-055-yyyy-MM-dd_HH-mm-ss_HH-mm-ss-Group_AQ/CAP-055-EVENT-NOTES.md‎

Lines changed: 86 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,86 @@
1+
# Event Notes: Pixel Buds Pro 2 (`libmaestro` / `libgfps`) — Group AQ (new), Head gestures (Nod/Shake) with an active call/notification (`CAP-055`)
2+
3+
**Status:** 🔲 **Not yet captured — skeleton only.** Fill in every `TBD` below after recording,
4+
per `CAPTURE_BLUETOOTH_HCI_SNOOP.md` §5 (analysis) and §8 (what to update), and
5+
`PROJECT_RULES.md` rule 11/14 (reproducibility metadata). Once reviewed, rename this folder from
6+
the placeholder `CAP-055-yyyy-MM-dd_HH-mm-ss_HH-mm-ss-Group_AQ` to the actual session
7+
date/start-time/end-time, e.g. `CAP-055-2026-09-15_08-30-00_08-40-00-Group_AQ`.
8+
9+
**Purpose (`CAPTURE_BLUETOOTH_HCI_SNOOP.md` Group AQ, added 2026-09-13,
10+
`ai-sessions/0017_MAINTENANCE_RESULT_2026_09_13.md` Phase 3):** `CAP-028` (Group O) found zero
11+
wire-visible traffic on the Buds' own connection during a claimed Nod/Shake gesture window — but
12+
`TESTPLAN_BLUETOOTH_HCI_SNOOP.md`'s own description ties Nod/Shake's actual function to an active
13+
call ("answers a call") or notification ("dismisses a text reply"), and no call/notification was
14+
active during `CAP-028`'s own window, so the clean-negative result cannot distinguish "functionally
15+
inert, as expected" from "gesture not actually triggered." This Group fixes that specific gap.
16+
Session 0017's APK cross-reference additionally confirmed `HeadGesture`'s result enum (`qin`) is
17+
genuinely 3-valued (raw `{0,1,2}`) but carries no name for any value — this capture is the only way
18+
to determine which raw value is Nod and which is Shake, if the enum is ever observed on the wire.
19+
20+
## Log Metadata
21+
22+
| Field | Value |
23+
|------------------|-----------------------------------------------------|
24+
| Capture ID | `CAP-055` |
25+
| Group(s) | AQ (new) |
26+
| Date | TBD |
27+
| Firmware version | TBD |
28+
| Test device | TBD (Pixel 7a, official Pixel Buds Companion App; "Use head gestures" toggled ON, re-confirmed on camera) |
29+
| Video file | TBD — must frame **both** the phone screen (call/notification state) **and** the user's head/ears (the gesture itself) |
30+
| Log file | TBD — `CAP-055-btsnoop_hci.log` |
31+
| Buds MAC (partial, per `AGENTS.md` §7/§9) | TBD |
32+
33+
## Procedure (per `CAPTURE_BLUETOOTH_HCI_SNOOP.md` Group AQ)
34+
35+
1. Confirm "Use head gestures" is toggled ON (Device details → Controls and gestures) before starting
36+
— re-confirm on camera (do not rely on a carried-over assumption from `CAP-020`).
37+
2. With the Buds connected and worn, **trigger an actual incoming phone call** (e.g. call the test
38+
phone from a second phone). While the call is ringing, perform a **Nod** gesture — camera angled to
39+
capture both the phone screen (call being answered) and the head/ears (the gesture itself).
40+
3. During the call, end it normally; then trigger a second incoming call and perform a **Shake**
41+
gesture to reject it — same dual camera framing.
42+
4. Separately, trigger a text-message notification (with 'Spoken notifications'/dictation-reply
43+
context if feasible) and perform a Nod (reply via dictation) or Shake (dismiss) gesture, camera
44+
angled the same dual way.
45+
46+
## Event Timeline
47+
48+
| Time | Action | Initiator | Test-ID | Wire evidence / Notes |
49+
|---|---|---|---|---|
50+
| TBD | Session start, "Use head gestures" confirmed ON on camera | User | — | Conn. state: TBD |
51+
| TBD | Second phone calls test phone — incoming call rings | User (Phone) | `CALL-001` | TBD |
52+
| TBD | Nod gesture performed (answer call), camera on head+screen | User (Hardware) | `HEAD-002` | TBD |
53+
| TBD | Call ends normally | User | — | TBD |
54+
| TBD | Second incoming call rings | User (Phone) | `CALL-001` | TBD |
55+
| TBD | Shake gesture performed (reject call), camera on head+screen | User (Hardware) | `HEAD-003` | TBD |
56+
| TBD | Text-message notification triggered | User (Phone) | — | TBD |
57+
| TBD | Nod or Shake gesture performed in response, camera on head+screen | User (Hardware) | `HEAD-002`/`HEAD-003` | TBD |
58+
| TBD | Session end | — | — | TBD |
59+
60+
## Analysis checklist (per `CAPTURE_BLUETOOTH_HCI_SNOOP.md` Group AQ)
61+
62+
- [ ] For each gesture, check for a wire-visible signal correlated with it: SCO/eSCO setup/teardown
63+
change, AVRCP command, or a DLCI 0x02/0x04/0x08 write (per `PROTOCOL.md` §4.1's ANC-Notify
64+
pattern as a template for what a hardware-gesture-triggered push might look like).
65+
- [ ] If a DLCI 0x02 `HeadGesture`-shaped RPC is found, check it against `REVERSE_ENGINEERING.md`'s
66+
`qin` register (updated by session 0017 — the response enum is 3-valued, raw `{0,1,2}`) and
67+
record, per `AGENTS.md` §13.6, which raw value corresponds to Nod and which to Shake — this is
68+
new evidence, not a guess, since both the gesture and (if found) the wire value are now
69+
camera/log-confirmed together for the first time.
70+
- [ ] Record a clean negative plainly if no signal is found even with an active call/notification —
71+
this would be a stronger result than `CAP-028`'s own inconclusive one (it would rule out the
72+
"no call was active" confound entirely).
73+
74+
## Next steps after filling this in
75+
76+
- [ ] Cross-reference this session's own findings against `TESTPLAN_BLUETOOTH_HCI_SNOOP.md`'s
77+
`HEAD-002`/`HEAD-003` rows and `PROTOCOL.md` §6 (`AGENTS.md` §13's traceability check).
78+
- [ ] Write `CAP-055-FINDINGS.md` per `PROJECT_RULES.md` §2, using this file's timeline as the
79+
evidence source, following the hex & script rule (§1 rule 4a).
80+
- [ ] Update this session's row in `CAPTURE_BLUETOOTH_HCI_SNOOP.md` §9 Capture Index — status
81+
from `planned` to `analyzed`, fill in Android/firmware/app-version columns and the log path.
82+
- [ ] Rename this capture's folder from the `yyyy-MM-dd_HH-mm-ss_HH-mm-ss` placeholder to the
83+
actual session date/start-time/end-time.
84+
85+
---
86+
https://github.com/tedsluis/opencontrolpixelbudspro2/blob/main/captures/CAP-055-yyyy-MM-dd_HH-mm-ss_HH-mm-ss-Group_AQ/CAP-055-EVENT-NOTES.md - https://tedsluis.github.io/opencontrolpixelbudspro2/captures/CAP-055-yyyy-MM-dd_HH-mm-ss_HH-mm-ss-Group_AQ/CAP-055-EVENT-NOTES

0 commit comments

Comments
 (0)