fix markdown

Author: tedsluis

captures/CAP-009-2026-08-23_18-33-52_20-12-55-Group_X/CAP-009-EVENT-NOTES.md

@@ -22,17 +22,17 @@ pushes).
 
 ## Log & Video Metadata
 
-|      Field       |                       Value                        |
-|------------------|-----------------------------------------------------|
-|    Capture ID    |                      `CAP-009`                     |
-|      Group(s)    |                         X                          |
-|       Date       |                     2026-08-23                     |
-| Firmware version | not queried this session (⚪ ASSUMPTION `release_5.203`, same physical device as `CAP-023`/`CAP-025`) |
-|   Test device    | Pixel 7a, Android 17 (⚪ ASSUMPTION, consistent with `CAP-023`/`CAP-025`), official app not confirmed this session |
-| Video file 1     | `CAP-009-recording1.mp4` — burned-in wall-clock overlay confirms it runs **18:33:52 → ~20:01:14** (`ffprobe` duration 5241.9s), **not** 18:33:52–20:00:27 as originally assumed — see "Video-boundary correction" below |
-| Video file 2     | `CAP-009-recording2.mp4` — burned-in overlay confirms it runs **~20:01:16 → ~20:12:51+** (`ffprobe` duration 699.7s) |
-| Log file         | `CAP-009-btsnoop_hci.log` — 2026-08-23 18:33:47.20–20:15:00.73 (wall clock, +0200), 30,234 packets |
-| Buds MAC (partial, per `AGENTS.md` §7/§9) | `04:00:6e:cf:6e:07` — **independently re-derived**, see "MAC verification" below |
+| Field                                      | Value                                                                                                                         |
+|-------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------|
+| Capture ID                                 | `CAP-009`                                                                                                                     |
+| Group(s)                                   | X                                                                                                                             |
+| Date                                       | 2026-08-23                                                                                                                    |
+| Firmware version                           | not queried this session (⚪ ASSUMPTION `release_5.203`, same physical device as `CAP-023`/`CAP-025`)                       |
+| Test device                                | Pixel 7a, Android 17 (⚪ ASSUMPTION, consistent with `CAP-023`/`CAP-025`), official app not confirmed this session          |
+| Video file 1                               | `CAP-009-recording1.mp4` — burned-in wall-clock overlay confirms it runs **18:33:52 → ~20:01:14** (`ffprobe` duration 5241.9s), **not** 18:33:52–20:00:27 as originally assumed — see "Video-boundary correction" below |
+| Video file 2                               | `CAP-009-recording2.mp4` — burned-in overlay confirms it runs **~20:01:16 → ~20:12:51+** (`ffprobe` duration 699.7s)    |
+| Log file                                   | `CAP-009-btsnoop_hci.log` — 2026-08-23 18:33:47.20–20:15:00.73 (wall clock, +0200), 30,234 packets                     |
+| Buds MAC (partial, per `AGENTS.md` §7/§9) | `04:00:6e:cf:6e:07` — **independently re-derived**, see "MAC verification" below                                            |
 
 ### Video-boundary correction (independent finding)
 
@@ -65,12 +65,14 @@ ways before filtering on it:
    already documented since `CAP-001`, per `AGENTS.md` §15's hardcoded-string exception) occurs
    **75 times** in the raw log file, always as part of DLCI `0x08` traffic on the same connection
    handle as (1):
-   ```
+
+   ```bash
    $ python3 -c "
    data = open('CAP-009-btsnoop_hci.log','rb').read()
    print(data.count(b'google-pixel-buds-pro-v1'))"
    75
    ```
+
    (Note: `tshark -Y 'frame contains "google-pixel-buds-pro-v1"'` returned 0 matches for reasons
    not fully diagnosed — likely a display-filter string-escaping quirk with the embedded hyphens —
    so this check was done as a raw byte search instead; the hex is directly visible in every
@@ -95,7 +97,7 @@ percentage row, tiled into contact sheets with the relative playback time burned
 ≈594 frames**, covering both files end-to-end. This surfaced every visible percentage change
 without presupposing where they were.
 
-```
+```bash
 $ ffmpeg -ss <chunk_start> -t 600 -i CAP-009-recording1.mp4 \
     -vf "crop=420:80:150:670,drawtext=fontfile=<mono.ttf>:text='%{pts\:hms}':x=5:y=2:fontsize=14:fontcolor=yellow:box=1:boxcolor=black@0.7,select='not(mod(n\,300))',tile=6x10" \
     -frames:v 1 -vsync 0 out.png
@@ -131,7 +133,7 @@ not battery values at all (a deliberate finger-tap on the Right battery icon, an
 notification banner/dismissal) — see the table below.
 
 | # | Maintainer's note | Independent finding (video, sub-2s precision unless noted) | Verdict |
-|---|---|---|---|
+| --- | --- | --- | --- |
 | A | 18:34:14: L96/Case72/R93 | Matches; first stable reading from ~18:34:11 | ✅ confirmed |
 | B | 19:02:49: Case72→71, R93→90 | **19:02:47.35–48.02** | ✅ confirmed (2–5s earlier) |
 | C | 19:26:30: L96→95 | **19:26:28.02–29.02** | ✅ confirmed (~2s earlier) |
@@ -193,9 +195,9 @@ indiscriminately regardless of which device the researcher cares about. Verified
 assumed:
 
 ```
-$ tshark -r CAP-009-btsnoop_hci.log 2>/dev/null | wc -l                                    # 30234
-$ tshark -r CAP-009-btsnoop_hci.log -Y "bthci_acl.chandle==0x0002" 2>/dev/null | wc -l     # 2503
-$ tshark -r CAP-009-btsnoop_hci.log -Y "bthci_acl.chandle==0x0001" 2>/dev/null | wc -l     # 21
+tshark -r CAP-009-btsnoop_hci.log 2>/dev/null | wc -l                                    # 30234
+tshark -r CAP-009-btsnoop_hci.log -Y "bthci_acl.chandle==0x0002" 2>/dev/null | wc -l     # 2503
+tshark -r CAP-009-btsnoop_hci.log -Y "bthci_acl.chandle==0x0001" 2>/dev/null | wc -l     # 21
 ```
 
 **DLCI inventory, whole log, exhaustive (not limited to already-expected channels):**
@@ -219,7 +221,7 @@ numbering happens to match several prior sessions', but that is not guaranteed i
 ## Event Timeline
 
 | Time (bracket) | Action | Initiator | Test-ID | Wire evidence |
-|----------|---|---|---|---|
+| ---------- | --- | --- | --- | --- |
 | 18:33:47.20–18:34:01.51 | Session/log start; Bluetooth off → connecting | — | — | Log opens 18:33:47.20 (frame 1); classic ACL `Connection Complete` 18:34:01.51 (frame 674, handle `0x0002`) |
 | 18:34:14 | L96%/Case72%/R93% first stable on screen | — | `BATT-006` | `AT+CIND?` queried once, 18:34:01.90 (frame 884) → `battchg=4` (≈80%, matches none of L/Case/R). First `AT+BIEV=2,93` 18:34:02.04 (frame 972) — matches R exactly. |
 | (18:40:36, not on-screen-checked) | wire-only transient | — | `BATT-006` | `AT+BIEV=2,92` 18:40:36.31 (frame 5556) |

captures/CAP-009-2026-08-23_18-33-52_20-12-55-Group_X/CAP-009-FINDINGS.md

@@ -21,7 +21,7 @@ promoted.
 ## 0. Capture Metadata & Methodology
 
 | Field | Value |
-|---|---|
+| --- | --- |
 | Capture ID | `CAP-009` |
 | Purpose | `BATT-006` — cross-check `AT+CIND?`'s `battchg` against `AT+BIEV=2,...` over a natural, multi-hour battery discharge, following up `CAP-001-FINDINGS.md` §3's single-snapshot disagreement (`battchg=3`≈60% vs. `AT+BIEV=2,100`=100% at the same instant) |
 | Date | 2026-08-23 |
@@ -106,9 +106,9 @@ Value-transition frames only (raw hex for each, `AT+BIEV=2,<value>\r` — ASCII,
 RFCOMM/HFP):
 
 | Frame | Time | Value | Hex |
-|---|---|---|---|
-| 972   | 18:34:02.036 | 93 | `41 54 2b 42 49 45 56 3d 32 2c 39 33 0d` |
-| 5556  | 18:40:36.313 | 92 | `41 54 2b 42 49 45 56 3d 32 2c 39 32 0d` |
+| --- | --- | --- | --- |
+| 972 | 18:34:02.036 | 93 | `41 54 2b 42 49 45 56 3d 32 2c 39 33 0d` |
+| 5556 | 18:40:36.313 | 92 | `41 54 2b 42 49 45 56 3d 32 2c 39 32 0d` |
 | 14612 | 19:02:47.245 | 90 | `41 54 2b 42 49 45 56 3d 32 2c 39 30 0d` |
 | 20632 | 19:26:28.135 | 89 | `41 54 2b 42 49 45 56 3d 32 2c 38 39 0d` |
 | 26459 | 19:50:29.368 | 88 | `41 54 2b 42 49 45 56 3d 32 2c 38 38 0d` |
@@ -134,7 +134,7 @@ Comparing the `AT+BIEV` value sequence (`93→92→90→89→88`) against the ma
 timeline (`CAP-009-EVENT-NOTES.md`):
 
 | Component | On-screen sequence (independently re-timed to sub-2s precision, see `CAP-009-EVENT-NOTES.md`) | Matches `AT+BIEV`? |
-|---|---|---|
+| --- | --- | --- |
 | Right earbud | 93 → 90 (19:02:47.35–48.02) → 89 (19:29:20.01–28.01) → 88 (20:00:01.68–02.01, bundled w/ case-insert) | **Yes** — same values, same order |
 | Left earbud | 96 → 95 (19:26:28.02–29.02) → 94 (19:50:29.02–30.02) → 100 (20:00:01.68–02.01, placed in case) | No — none of 96/95/94/100 appear in the `AT+BIEV` sequence |
 | Case | 72 → 71 (19:02:47.35–48.02) → 68 (20:00:01.68–02.01) → 75 (20:11:02.03–05.70) | No — none of 72/71/68/75 appear in the `AT+BIEV` sequence |
@@ -146,7 +146,7 @@ confirming the on-screen UI does not repaint on every individual wire push, but
 coarser trigger (see the case-jump timing in §4 for the clearest example of this):
 
 | Value push (wire) | On-screen change (independent video timing) | Δt (screen − wire) |
-|---|---|---|
+| --- | --- | --- |
 | `AT+BIEV` R 92→90 @ 19:02:47.245 (frame 14612) | R 90 visible @ 19:02:47.35–48.02 | **~0.1–0.8s** |
 | `AT+BIEV` R 90→89 @ 19:26:28.135 (frame 20632) | R 89 visible @ 19:29:20.01–28.01 | ~2min 52s–3min |
 | `AT+BIEV` R 89→88 @ 19:50:29.368 (frame 26459) | R 88 visible @ 20:00:01.68–02.01 (bundled with case-insert) | ~9min 32s |
@@ -267,7 +267,7 @@ recorded in `PROTOCOL.md` §4.3 Option A at this same HYPOTHESIS level (`AGENTS.
 ## 5. Answer to `BATT-006`
 
 | Question | Answer |
-|---|---|
+| --- | --- |
 | Does `AT+CIND?`'s `battchg` track a real battery-level change over time? | 🟢 **No** — it is queried exactly once, at SLC setup, and never refreshes again, even across ~13 percentage points of real, confirmed change on the peer's Right earbud during the same HFP session. |
 | Does `AT+BIEV=2` track a real battery-level change over time? | 🟢 **Yes, for the Right earbud specifically**, in this session — 5 distinct values over 86 minutes, each matching R's on-screen value, each landing at or before the corresponding on-screen check. |
 | Is either indicator a case- or Left-earbud-aware aggregate? | 🟢 **No** — neither indicator's value ever matches Left or Case at any point in this 101-minute session (§3). |
@@ -373,9 +373,9 @@ Decoding each as `03 03 00 03 <b1> <b2> ff` and printing only the frames where `
 from the previous one gives **14 transitions across the whole session**:
 
 | Frame | Time | b1 | b2 | Note |
-|---|---|---|---|---|
-| 1044  | 18:34:02.127 | 96 | 93 | first frame |
-| 5551  | 18:40:36.297 | 96 | 92 | b2 changes |
+| --- | --- | --- | --- | --- |
+| 1044 | 18:34:02.127 | 96 | 93 | first frame |
+| 5551 | 18:40:36.297 | 96 | 92 | b2 changes |
 | 14609 | 19:02:47.243 | 96 | 90 | b2 changes |
 | 18031 | 19:17:26.107 | **95** | 90 | b1 changes |
 | 20627 | 19:26:28.126 | 95 | **89** | b2 changes |