docs: apply project-wide audit findings from AUDIT_REPORT_2026-08-28.md

Resolves every finding from the 2026-08-28 audit: mechanical documentation
fixes applied directly (rule-9a rewrites, forward pointers, stale TODO.md/
id_registry.csv sync, a video-checked CAP-004 UUID correction), and every
FACT-promotion/ADR/judgment-call item walked through individually with the
maintainer before being applied or declined.

- DECISIONS.md: new ADR-016, retroactively signing off 7 FACT claims from
  2026-08-18 (EQ field-to-band mapping/gain-clamp/preset quintets, and four
  CAP-016 hardware-behavior facts) that had never gone through maintainer
  review, unlike every other FACT promotion in the project.
- PROTOCOL.md: ADR-016 cited throughout; CTKD section synced with CAP-014's
  second confirming instance; misleading changelog "not yet reviewed" tags
  cleaned up; a battery-message-code spec citation added as a PROPOSAL
  (Google's official spec confirms Group 0x03 Code 0x03 = "Battery updated",
  matching CAP-009's own candidate); a firmware-version (4.467 vs
  release_5.203) reconciliation gap flagged.
- TESTPLAN_BLUETOOTH_HCI_SNOOP.md: corrected the PAIR-003 "first Pixel 7a
  occurrence" claim to CAP-006 (was wrongly attributed to CAP-012).
- DESKRESEARCH_FINDINGS.md: new entry consolidating the 5-session
  btsnoop-vs-btsnooz extraction-path comparison, previously scattered across
  inline notes.
- TODO.md: closed out CAP-008/009/013 as done, corrected stale priority
  ordering, added a technical-debt entry and three new-capture research
  ideas.
- 10 capture files: rule-9a-compliant rewrites-in-place, forward-pointer
  backfills to superseding captures, ADR-008 scope corrections, a UUID
  digit fix in CAP-004 (video-checked before correcting), a date typo, and
  a stale checklist tick.

The audit report itself has been deleted — its findings are now either
applied or explicitly declined per the maintainer's review.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Bjo12itgeoZW8rPFPXUZvz

Author: tedsluis

CAPTURE_BLUETOOTH_HCI_SNOOP.md

@@ -138,19 +138,14 @@ The supported, working method on both phones:
 6. Once you've confirmed extraction worked, you can disable the HCI snoop toggle again
    (§2 step 3) to avoid unnecessary background logging and disk usage between sessions.
 
-> **PROPOSAL — pending maintainer approval (added 2026-08-27, `CAP-032-FINDINGS.md` §0.1/§7 Test
-> C):** step 3 (raw file) and step 4 (`btsnooz.py` fallback) are not interchangeable in practice —
-> across the four `Group A`-repeat captures to date, every session extracted via step 4
-> (`CAP-012`, `CAP-013`, `CAP-031`) came out severely ACL-truncated (`capinfos`-inferred ~15–126-byte
-> per-packet cap — RFCOMM data payloads beyond that are lost), while the one session extracted via
-> step 3 (`CAP-032`) came out fully untruncated (`frame.cap_len == frame.len` throughout). This is
-> one data point on the "raw" side against three on the "btsnooz" side, not a controlled test (no
-> single session has been extracted both ways for direct comparison) — but it's consistent enough
-> that **always check step 3 first and prefer it whenever the raw file is present**, and **always
-> record which path a given capture actually used** in that capture's own `CAP-NNN-FINDINGS.md`
-> (per `PROJECT_RULES.md` rule 11's reproducibility requirement) — a capture's usability for
-> anything beyond short control-frame sequencing may depend on this choice, not just on what
-> happened during the session itself.
+> **PROPOSAL — pending maintainer approval:** step 3 (raw file) and step 4 (`btsnooz.py` fallback)
+> are not interchangeable in practice — **always check step 3 first and prefer it whenever the raw
+> file is present**, and **always record which path a given capture actually used** in that
+> capture's own `CAP-NNN-FINDINGS.md` (per `PROJECT_RULES.md` rule 11's reproducibility
+> requirement) — a capture's usability for anything beyond short control-frame sequencing may
+> depend on this choice, not just on what happened during the session itself. See
+> `DESKRESEARCH_FINDINGS.md`'s 2026-08-28 entry for the full 5-session comparison and evidence
+> (still 🟡 HYPOTHESIS, not a controlled test).
 
 ---
 

DECISIONS.md

@@ -622,5 +622,70 @@ motivated this).
   DLCI `0x04`/BLE-scan HYPOTHESES noted above; those need their own follow-up before any further
   promotion.
 
+## ADR-016 — Retroactive sign-off: EQ field-to-band mapping/gain-clamp/preset quintets, and four `CAP-016` hardware-behavior FACTs
+
+- **Date**: 2026-08-28
+- **Status**: Accepted
+- **Note on process**: this ADR was drafted by an AI agent, but per `AGENTS.md` §6's requirement
+  for explicit human/maintainer sign-off before an agent commits a new `DECISIONS.md` ADR as
+  settled: the maintainer directly reviewed `AUDIT_REPORT_2026-08-28.md`'s `GOV-01` finding and
+  explicitly approved consolidating sign-off for all findings below into one ADR (session of
+  2026-08-28). That instruction is the explicit approval this rule requires — recorded here so the
+  provenance is auditable, not assumed.
+- **Context**: on 2026-08-18, `PROTOCOL.md` was updated directly from two independent capture
+  sessions — `CAP-015` (EQ, completing/superseding `CAP-005`'s partial attempt) and `CAP-016`
+  (Group U re-run) — promoting seven distinct claims to 🟢 FACT. Unlike every FACT promotion from
+  2026-08-21 onward (`ADR-011`–`ADR-015`), these seven were never given a corresponding
+  `DECISIONS.md` ADR or an explicit "maintainer sign-off obtained" citation; `PROTOCOL.md`'s
+  changelog table still marked both 2026-08-18 entries "not yet reviewed by maintainer" as of
+  `AUDIT_REPORT_2026-08-28.md`'s `GOV-01` finding. This ADR closes that gap.
+- **Findings being recorded**:
+  1. **EQ field-to-band mapping** (`PROTOCOL.md` §4.2): quintet field 1↔Low bass, 2↔Bass, 3↔Mid,
+     4↔Treble, 5↔Upper treble (wire order is the reverse of the on-screen top-to-bottom order).
+     Evidence: `CAP-015-FINDINGS.md` §5 — all 5 sliders dragged individually, 3 passes each; 4 of 5
+     fields video-confirmed by finger-on-slider position, the 5th by elimination against a
+     perfectly repeating field-change order across all 3 passes; matches `CAP-005`'s earlier
+     single-band inference exactly, 5 days apart, independently.
+  2. **Band-gain range, ±6.0 clamp** (`PROTOCOL.md` §4.2). Evidence: `CAP-015-FINDINGS.md` §4 — 8
+     of 10 extreme-drag samples land at exactly ±6.0, the remaining 2 at 5.8/5.9 (consistent with
+     the drag gesture not quite reaching the slider's physical edge before release, not a different
+     clamp value). Units not independently confirmed (plausibly dB), unaffected by this promotion.
+  3. **Confirmed preset quintets** (`PROTOCOL.md` §4.2): `Last saved`/Heavy bass/Light bass/
+     Balanced/Vocal boost/Clarity, each a `[Low bass, Bass, Mid, Treble, Upper treble]` 5-tuple.
+     Evidence: `CAP-015-FINDINGS.md` §5 — Heavy bass's quintet independently matches the
+     2026-08-15 capture's own decode byte-for-byte.
+  4. **Reconnect, Buds-initiated variant** (`PROTOCOL.md` §5.1): a single `Rcvd Connect Request` →
+     `Sent Accept Connection Request` → `Rcvd Connect Complete` sequence, landing within 0.5s of
+     on-camera earbud removal from the case. Evidence: `CAP-016-FINDINGS.md` §1, frames 1213–1217.
+  5. **Disconnect-on-redock** (`PROTOCOL.md` §7): ACL `Disconnection Complete` (reason `0x13`,
+     Buds-initiated) fires the instant the *second* bud is placed in the case, not on lid-close
+     alone. Evidence: `CAP-016-FINDINGS.md` §1.
+  6. **Case-lid zero-signal** (`PROTOCOL.md` §7): opening/closing the case lid while both buds
+     remain outside the case produces no wire-visible signal on any RFCOMM channel. Evidence:
+     `CAP-016-FINDINGS.md` §5, independently reproducing `CAP-007-FINDINGS.md`(old) §3.4 —
+     2-capture-confirmed.
+  7. **DLCI 0x08 `Group 0x04 Code 0x12`'s alternating value is event-driven *and* autonomous**
+     (`PROTOCOL.md` §6 Resolved): fires in step with DLCI-0x08 channel-(re)open events, and also
+     continues firing during otherwise-idle stretches with no channel churn — neither purely
+     reactive nor purely free-running. Evidence: first characterized this way in
+     `CAP-004-FINDINGS.md` §5a Task 5 and `CAP-007-FINDINGS.md`(old) §3.2/§5, independently
+     reconfirmed by `CAP-016-FINDINGS.md` §7 (8 pushes, cycling `0x02`/`0x03`, 2 in step with
+     channel-(re)opens, 4 during idle stretches with no churn).
+- **What this ADR does NOT clear**:
+  - EQ's outer field 16 vs. 18 ("preview" vs. "fires on slider-release") reading remains 🟡
+    HYPOTHESIS, unaffected — `PROTOCOL.md` §4.2 already states this explicitly; not promoted here.
+  - DLCI 0x08 Code `0x12`'s value's actual *meaning* (what `0x02`/`0x03`/`0x04` represents) remains
+    🔴 OPEN — this ADR covers only the event-driven-and-autonomous *behavior* characterization, not
+    the value's semantics.
+  - `CAP-016`'s other findings, already explicitly marked "not promoted"/"awaiting maintainer
+    sign-off" in its own §8 (the ANC settable-toggles-byte refinement, the `AndroidHeadTracker` HID
+    decode), are **not** covered by this ADR — they remain open, as already correctly tracked.
+  - Band-gain units (dB or otherwise) remain unconfirmed.
+- **Decision**: all seven findings above are accepted as 🟢 FACT.
+- **Consequences**: `PROTOCOL.md`'s changelog rows for 2026-08-18 updated to cite this ADR instead
+  of "not yet reviewed by maintainer"; the corresponding body sections (§4.2, §5.1, §7 ×2, §6
+  Resolved) gain an explicit `ADR-016` citation, matching the citation style already used for
+  `ADR-011`–`ADR-015`.
+
 ---
 https://github.com/tedsluis/opencontrolpixelbudspro2/blob/main/DECISIONS.md - https://tedsluis.github.io/opencontrolpixelbudspro2/DECISIONS

DESKRESEARCH_FINDINGS.md

@@ -162,5 +162,50 @@ Status legend (consistent with `PROTOCOL.md` §0):
 - **Promoted to:** `PROTOCOL.md` §6 (Commands & schemas) — both results added as dated open-item
   updates, 2026-08-17.
 
+### 2026-08-28 — Extraction-path (`btsnoop` vs. `btsnooz`) truncation pattern across all captures
+
+- **Trigger:** `AUDIT_REPORT_2026-08-28.md`'s `XC-01` finding — the extraction-path pattern
+  (`CAPTURE_BLUETOOTH_HCI_SNOOP.md` §3's own inline PROPOSAL note, first raised from `CAP-032`'s
+  single comparison against three prior sessions) is exactly the kind of "check this byte pattern
+  across all existing logs" correlation this document exists for, but had never been consolidated
+  here — only as scattered per-capture notes and one inline blockquote.
+
+- **Method:** for every `CAP-NNN`'s extracted log, checked (a) the filename suffix
+  (`-btsnoop_hci.log` = raw path, `CAPTURE_BLUETOOTH_HCI_SNOOP.md` §3 step 3; `-btsnooz_hci.log` =
+  `btsnooz.py`-from-bugreport fallback, §3 step 4) and (b) whether `frame.cap_len == frame.len` for
+  every frame:
+  ```
+  capinfos <CAP-NNN-btsnoop(z)_hci.log>
+  tshark -r <CAP-NNN-btsnoop(z)_hci.log> -T fields -e frame.number -e frame.cap_len -e frame.len \
+    | awk '$2!=$3 {c++} END{print "mismatches:", c+0}'
+  ```
+
+- **Captures examined:** every capture whose own `FINDINGS.md` already documented an extraction
+  path or truncation result — `CAP-012`, `CAP-013`, `CAP-017`, `CAP-031` (all `btsnooz`-extracted),
+  `CAP-032` (raw-extracted). (`AUDIT_REPORT_2026-08-28.md`'s own re-verification pass additionally
+  confirmed all other real captures — `CAP-001`–`CAP-011` excl. `012`/`013`, `CAP-014`–`CAP-016`,
+  `CAP-019`–`CAP-025` — are untruncated, either raw-extracted or from a freshly-restarted log; not
+  repeated here since none of those used the `btsnooz` fallback.)
+
+- **Result (🟡 HYPOTHESIS — one data point per session, not a controlled test):**
+
+  | Capture | Extraction path | `capinfos` inferred cap | Mismatched frames |
+  |---|---|---|---|
+  | `CAP-012` | `btsnooz` fallback | 15–126 bytes (range) | 254 / 1,436 |
+  | `CAP-013` | `btsnooz` fallback | 15 bytes (flat) | 320 / 1,747 |
+  | `CAP-017` | `btsnooz` fallback | ~15 bytes | 268 / 1,747 |
+  | `CAP-031` | `btsnooz` fallback | 15–126 bytes (range) | 259 / 1,747 |
+  | `CAP-032` | raw `btsnoop_hci.log` | none (uncapped) | 0 / 2,455 |
+
+  4 of 4 `btsnooz`-extracted sessions came out severely ACL-truncated; the 1 raw-extracted session
+  came out fully untruncated. This is consistent enough across 5 independent sessions to treat as
+  a reliable *practical* rule — **always check `CAPTURE_BLUETOOTH_HCI_SNOOP.md` §3 step 3 (the raw
+  file) first and prefer it whenever present** — but it remains 🟡 HYPOTHESIS, not 🟢 FACT: no
+  single session has been extracted both ways for a direct controlled comparison, so this is 5
+  data points agreeing, not an isolated causal test.
+
+- **Promoted to:** `CAPTURE_BLUETOOTH_HCI_SNOOP.md` §3's existing PROPOSAL note (trimmed to point
+  here, 2026-08-28), `TODO.md`'s "Known technical debt" section (2026-08-28).
+
 ---
 https://github.com/tedsluis/opencontrolpixelbudspro2/blob/main/DESKRESEARCH_FINDINGS.md - https://tedsluis.github.io/opencontrolpixelbudspro2/DESKRESEARCH_FINDINGS