# Checklist: Stage 1B four-drive USB compatibility baseline

Status: complete
Type: checklist
Updated: 2026-08-01
Next Action: none; completed by the 32 KiB matrix, deterministic recovery proof, and final BOT delta regression
Parent: work/wp/completed/wp-restore-broad-usb-compatibility-baseline.md

## Goal

Establish the upfront Stage 1B hardware evidence on the four owner-selected,
freshly Windows-formatted and Pi-health-checked USB drives. The 1 KiB candidate
was exercised first and disproven by USB09; the isolated 32 KiB Stage 2
candidate must now cover USB09 and every baseline drive without drive-specific
firmware behavior before promotion.

USB09 remains a required follow-up regression because it exposed the prior
architecture, but it does not precede this four-drive baseline.

## Pinned inputs

- Source commit: `8fa1479b6b942f72f18ff4ed2cb1a5c73ddc2501`.
- Release S-record SHA-256:
  `82A277EEBBED0CC4FBDDCC848ACEFD43E706849803673C4920E7851FC2ACABB5`.
- Pretest media evidence:
  `work/evidence/usb-four-drive-windows-format-pretest-health-20260731.md`.
- Controller A: serial `1751136`, J-Link `69664082`.
- Controller B: serial `1751219`, J-Link `69660123`.

## Paired matrix

| Round | Controller A | Controller B | Independent Pi check | Status |
| --- | --- | --- | --- | --- |
| 1 | `USB01_2G` | `USB05_4G` | both drives after removal | PASS |
| 2 | `USB05_4G` | `USB01_2G` | both drives after removal | PASS |
| 3 | `USB02_8G` | `USB03_32G` | both drives after removal | FAIL on A/USB02; PASS on B/USB03 |
| 4 | `USB03_32G` | `USB02_8G` | both drives after removal | PASS diagnostic; does not erase round 3 |
| Recovery 1 | `USB02_8G` | `USB03_32G` | both drives after removal | PASS on corrected candidate |
| Recovery cross | `USB03_32G` | `USB02_8G` | prior Pi content gate retained; read/playback only | PASS after one allowed A/USB03 reseat; initial enumeration miss recorded |
| 32K USB09 | `USB09` | — | exact no-repair Pi validation | PASS end to end |
| 32K Round 1 | `USB01_2G` | `USB05_4G` | both drives after removal | PASS |
| 32K Round 2 | `USB05_4G` | `USB01_2G` | both drives after removal | PASS |
| 32K Round 3 | `USB02_8G` | `USB03_32G` | both drives after removal | PASS |
| 32K Round 4 | `USB03_32G` | `USB02_8G` | both drives after removal | PASS |
| Diagnostic insertions 1-5 | `USB03_32G` on A/B | — | same-run controller/SD CID evidence | PASS first attempt; failure did not recur |

## Checklist

- [x] Obtain explicit authorization before programming either controller.
- [x] Verify the local Release S-record hash matches the pinned hash.
- [x] Capture controller identity, safe operating state, running-image identity,
  SD protocol status, complete CID identity, and representative-sector status
  before deployment.
- [x] Program and verify Controller B first, then Controller A, using their
  serial-bound J-Link routes and the same pinned Release candidate.
- [x] Recapture running-image identity and the full SD CID block after reboot.
- [x] Reconfirm both drives assigned to the round by canonical label, capacity,
  hardware identity where valid, FAT32 layout, and unmounted Pi state.
- [x] Insert each assigned drive into its powered controller and require fresh
  enumeration, a valid FileX session, and adequate free space.
- [x] Run the same bounded customer workflow on both sides: WAV enumeration and
  load/playback, image publication, PID capture, and retained HPT CSV export.
- [x] Record per-operation terminal status, exact bytes, FileX call count and
  maximum write size, timing, system errors, media generation, and HPT
  completion state. Do not use shared progress as terminal authority.
- [x] Require normal removal-ready/idle state; do not invoke VBUS diagnostics
  or controller-driven USB power cycling during the production workflow.
- [x] Remove each USB drive while its controller remains powered, attach it to
  the Pi, and validate it independently without repair.
- [x] Verify expected filenames and sizes, HPT `COMPLETE` trailer and record
  count, readable image/PID/WAV outputs, FAT state, and absence of unexpected
  `.tmp`, `.part`, or `.bak` files.
- [x] Archive compact round results under controller-specific ignored evidence,
  update a small versioned manifest, and leave both drives unmounted.
- [x] Repeat for all four paired rounds with no specimen-specific retry beyond
  one clean powered USB removal/reinsertion after a proven terminal request.
- [x] Run USB09 afterward as the incident-regression specimen without adding a
  USB09-specific mitigation.
- [x] Do not begin Stage 2 until every Stage 1B failure is dispositioned. USB09
  disproved the 1 KiB candidate and authorizes the isolated 32 KiB
  discriminator; this is not production acceptance.

## Runtime Closeout

- [x] Both controllers report the pinned running-image identity and normal
  responsive state after the final round.
- [x] Controller-specific SD identity and safety state remain valid.
- [x] Each of the four USB drives returned to the Pi after its observation and
  passed an unmounted canonical-label identity check.
- [x] The prior 32 KiB candidate remains a historical rollback/reference only;
  it is not silently restored during Stage 1B.

## Round 3 gate failure

`USB02_8G` reached a valid FileX handoff on Controller A after the one allowed
clean reinsertion, then the application closed the session while the USB
device remained attached. Final state was `usb_mounted=0`, acceptance mask
`15`, `usb_app_errors=1`, `system_errors=0`, pending instance `0`, and FileX
pointer `0`. Independent Pi validation found the FAT32 filesystem clean and
unchanged with no publication artifacts.

`USB03_32G` passed the complete workflow on Controller B and independent Pi
validation. This pass does not offset the USB02 failure. Details are in
`work/evidence/usb-stage1b-round3-usb02-usb03-20260731.md`.

Round 4 then passed USB03 on Controller A and USB02 on Controller B on first
insertion, through the complete workflow and independent Pi checks. USB02 is
therefore not inherently incompatible; the firmware cannot recover the
round-3 transient. Details are in
`work/evidence/usb-stage1b-round4-usb03-usb02-20260731.md`.

The narrow session-recovery correction is built and software-gated at source
commit `96b8ab4b87e438c41370b24001a5ef00bcd93492`; exact artifact hashes are in
`work/evidence/usb-session-recovery-software-candidate-20260731.md`. The exact
Release candidate is now deployed and independently read back on Controller B
first and then Controller A, with all post-reboot controller and SD gates
passing. Deployment evidence is in
`work/evidence/usb-session-recovery-controller-deployment-20260731.md`. The
exact round-3 allocation was then repeated on the corrected candidate. Both
drives mounted on first insertion and passed the complete workflow plus
independent Pi validation with zero errors. Evidence is in
`work/evidence/usb-session-recovery-round1-usb02-usb03-20260731.md`.

The opposite-controller recovery cross-check then passed WAV load/playback and
final session gates. USB02/B mounted on first insertion. USB03/A showed
electrical attachment but no fresh USBX class/media generation on its first
insertion, then mounted and passed after the single checklist-permitted clean
reseat. No VBUS or controller power action was used. Evidence is in
`work/evidence/usb-session-recovery-cross-check-usb03-usb02-20260731.md`.

USB09 then passed the same read-only Pi pretest gate used for the four-drive
baseline. Its incident label, UUID, serial, capacity, FAT state, and historical
export hash matched; a complete 8,053,063,680-byte direct read and kernel-error
gate passed, and the drive remains unmounted. Evidence is in
`work/evidence/usb09-pi-pretest-health-20260731.md`.

USB09 subsequently mounted on Controller A on first insertion with a fresh,
valid FileX/application session and zero initial errors, but the full
retained-range export failed. Request `2` selected 8,540 healthy records with
no gaps, requested 99,328 USB bytes in 97 writes capped at 1,024 bytes, then
`fx_file_close()` consumed exactly 50 seconds and returned raw `0x5C`.
Publication remained false. No VBUS, power, reseat, or specimen mitigation was
used. Evidence is in
`work/evidence/usb09-recovery-candidate-controller-failure-20260731.md`.

Independent no-repair Pi inspection found differing intact FAT copies, an
incorrect free-cluster summary, no `USB09_RCV.csv`, and a 97,280-byte
`HPTE.TMP` ending mid-record without a completion marker. The controller had
requested 99,328 bytes, leaving a 2,048-byte visible deficit. The prior valid
export remained unchanged and the Pi logged no transport errors. Evidence is
in `work/evidence/usb09-recovery-candidate-pi-failure-inspection-20260731.md`.

Raw `0x5C` is USBX `UX_TRANSFER_TIMEOUT`. The 1 KiB cap is disproven as the
compatibility baseline, while the same clean USB09 specimen previously passed
374,707 bytes in 12 calls at 32 KiB and closed in 0.01 seconds. An isolated
32 KiB discriminator is authorized; it does not pass this checklist until
USB09 and the broad matrix pass without specimen-specific behavior.

The isolated 32 KiB candidate then passed all focused software gates,
canonical managed Debug and Release rebuilds, packaging, and exact artifact
freezing at source commit `8fa1479b6b942f72f18ff4ed2cb1a5c73ddc2501`.
Evidence is in `work/evidence/usb-32k-recovery-software-candidate-20260731.md`.

The exact Release candidate was then deployed Controller B first and Controller
A second. Both full 4 MiB readbacks match the frozen S-record; both post-reboot
captures pass hardware, zero-error, HPT-ready, complete SD CID, detection, and
representative-sector gates. Evidence is in
`work/evidence/usb-32k-recovery-controller-deployment-20260731.md`.

The owner then authorized and completed a full Windows FAT32 format of USB09.
The drive passed exact Pi identity, equal-FAT, filesystem, full-device direct
read, capacity, content, unmounted-state, and kernel-error gates. Evidence is
in `work/evidence/usb09-post-windows-format-pi-health-20260731.md`.

USB09 then passed the identical Controller A failure-range regression: 8,540
healthy records, no gaps, 429,175 published bytes in 14 writes, zero close
delay, 2.12-second USB time, and zero errors. Evidence is in
`work/evidence/usb09-32k-recovery-controller-pass-20260731.md`. Independent
post-export Pi verification remains required.

Independent Pi verification then passed equal FATs, filesystem state, exact
429,175-byte size, all 8,540 sequential records, range/health metadata,
completion marker, absence of temporary artifacts, and kernel-error gates.
USB09 is resolved end to end. Evidence is in
`work/evidence/usb09-32k-recovery-pi-pass-20260731.md`.

Immediately before 32 KiB Round 1, `USB01_2G` and `USB05_4G` again passed
identity, capacity, read-only FAT, equal-FAT, retained-content,
current-insertion kernel-error, and final-unmounted gates. No repair or
specimen-specific mitigation was used. Evidence is in
`work/evidence/usb-32k-round1-precheck-usb01-usb05-20260731.md`.

The complete Round 1 controller workflow then passed on first insertion on
both sides: WAV load/playback, PID, 8 MiB image replacement, and full retained
HPT export. `USB01_2G` published 441,542 bytes in 14 writes and `USB05_4G`
published 441,912 bytes in 14 writes; both reached the 32,768-byte cap,
completed, remained mounted, and finished with zero USB/system errors. No
VBUS, power, reseat, retry, or specimen mitigation was used. Independent Pi
validation remains required. Evidence is in
`work/evidence/usb-32k-round1-controller-usb01-usb05-20260731.md`.

Independent no-repair Pi validation then passed matching identity, equal FAT
copies, clean filesystem structure, current-insertion kernel state, exact CSV
sizes and continuous record sequences, completion trailers, new PID content,
WAV validity, identical internally CRC-valid recovery images, absence of
temporary files, and final unmounted state. Round 1 is PASS end to end.
Evidence is in
`work/evidence/usb-32k-round1-pi-usb01-usb05-20260731.md`.

The opposite-controller Round 2 workflow then passed with `USB05_4G` on A
and `USB01_2G` on B. A initially detected USB05 electrically but did not
complete USBX class/media enumeration; one clean powered removal, five-second
wait, and reinsertion produced a fresh valid generation-3 session. B mounted
USB01 on first insertion. No VBUS, controller power action, firmware retry,
or drive-specific behavior was used. Both sides then passed WAV
load/playback, PID, complete 8 MiB image replacement, and full retained-range
HPT publication. USB05 published 442,642 bytes and USB01 published 443,162
bytes, each in 14 writes reaching 32,768 bytes, with zero USB/system errors.
The initial A enumeration miss remains a compatibility observation and is not
reclassified as a clean first-insertion pass. Independent Pi validation is
pending. Evidence is in
`work/evidence/usb-32k-round2-controller-usb05-usb01-20260731.md`.

Independent no-repair Pi validation then passed matching identity, equal FAT
copies, clean filesystem structure, current-insertion kernel state, exact CSV
sizes and continuous record sequences, completion trailers, new PID content,
WAV validity, identical internally CRC-valid recovery images, absence of
temporary files, and final unmounted state. Round 2 is PASS end to end. The
initial A/USB05 enumeration miss remains explicit compatibility evidence.
Evidence is in
`work/evidence/usb-32k-round2-pi-usb05-usb01-20260731.md`.

The remaining first-insertion blocker now has a diagnostic-only candidate at
source commit `a3fe1593`. It retains HCD/root-hub connection and retry state,
USBX system errors, live device state, and generic null-class notifications,
while leaving the proven 32 KiB write path and restored common-denominator
lifecycle unchanged. Both canonical builds, packaging, and focused checks
pass; the exact artifacts are frozen in
`work/evidence/usb-enumeration-diagnostic-software-candidate-20260731.md`.
The next controlled step is B-first/A-second deployment followed by repeated
USB03_32G first-insertion observations. No automatic recovery is authorized
until the failed state distinguishes exhausted enumeration from a lost retry.

That exact candidate was then deployed Controller B first and Controller A
second. Both passed serial-bound programming, independent full-flash match,
fresh post-reboot CID and representative-sector identity, HPT-ready,
hardware-variant, no-drive, and zero-error gates. Evidence is in
`work/evidence/usb-enumeration-diagnostic-controller-deployment-20260731.md`.

The bounded recovery successor was then built, software-gated, and deployed
Controller B first and Controller A second. Six additional natural
`USB03_32G` insertions alternated between the controllers; all six mounted on
the first attempt at high speed with valid USBX/FileX sessions and zero errors.
Recovery attempt count remained zero, which passes the healthy no-op gate but
does not exercise the failure-only branch. The final Controller A insertion
also passed a full 483,324-byte retained HPT export and independent read-only
Pi validation with equal FATs, 9,618 continuous records, a COMPLETE trailer,
clean current kernel state, and final unmounted state. Evidence is in
`work/evidence/usb-enumeration-recovery-six-insertion-and-export-20260801.md`.

Further natural insertion cycling is not required. The remaining gate is one
reviewed, guarded deterministic reproduction of the retained final
unconfigured USBX enumeration failure, with exactly one recovery attempt,
successful mount, and no VBUS action.

The first qualification-only candidate at source commit `80e6a455` injected
all three failures but did not exercise production recovery: USBX consumed an
additional already-queued root-hub signal, mounted the drive, and left recovery
attempt count at `0`. It is invalid as recovery proof and retained in
`work/evidence/usb-enumeration-deterministic-test-software-candidate-20260801.md`.

Corrected v2 is frozen at source commit `4032ab50`. It drains only already-
queued enumeration work after the third qualification failure, records but
does not clear HCD transfer-thread state, and changes no production recovery,
VBUS, transport, FileX, write-size, or identity behavior. All focused gates,
both canonical builds, packaging, `0x04 / 0x30 / 0x40` symbol sizes, and exact
artifact hashes pass. Deploy v2 to Controller B only, capture the one-shot
recovery and one ordinary follow-on insertion, then restore Controller B to
the frozen production recovery candidate. Controller A remains unchanged.
Evidence is in
`work/evidence/usb-enumeration-deterministic-test-v2-software-candidate-20260801.md`.

## Verification

Completion requires eight controller/drive observations, four independent
paired Pi validations, the USB09 follow-up result, exact candidate identity,
and no unexplained compatibility, corruption, false-success, or false-failure
result. A build or one-controller pass is insufficient.
