# Restore broad USB compatibility baseline

Status: complete
Type: workpackage
Updated: 2026-08-01
Next Action: none; retain the promoted baseline and reopen architecture review for any newer contradictory incident

Project Map: work/maps/map-smi-firmware-stabilization-and-qualification.md
Canonical Truth: docs/firmware-update-validation-and-recovery.md and docs/sd-card-operation-and-recovery.md

## Current Context

Firmware `00.05.00` contains required HPT 2.0 SD logging, current export-domain
selection and CSV publication, update validation, graph, warning, calibration,
and recovery work that must not be lost. The USB compatibility release in
commit `e31e0198` also added a mandatory production durability sequence using
optional SCSI commands, controller-driven VBUS cycling, re-enumeration,
remounting, and full-file reread. USB09 later produced a complete durable CSV
but an operator-visible failure in that post-publication sequence.

The last released broadly used USB baseline is tag `v00.04.11` at commit
`38611bcc`. The immediate pre-compatibility source checkpoint is `ecea1c35`.
Stage 1 must restore the 4.11 interaction architecture selectively; replacing
the complete current USB thread would discard required product functionality.

Independent cross-ecosystem USB-host research was ingested on 2026-08-01 in
`work/spikes/spike-ingest-external-usb-host-compatibility-research.md`. It is
design input for later code work, not proof that its proposed timing, transfer,
filesystem, or recovery defaults fit SSP 2.6.1, S7G2 USBHS, or this product.
The accepted constraints reinforce the existing standards-led, command-class
policy: locate the exact failing layer, distinguish SCSI command failure from
BOT transport failure, keep optional-command rejection nonfatal, preserve
finite recovery, and avoid specimen-specific production behavior.

## Recommendation

Restore the smallest common USB Mass Storage Class production lifecycle while
preserving current application features. Stage 1 tested the original
approximately 1 KiB application write behavior and disproved it on USB09.
Stage 2 therefore changes only the HPT FileX write cap to 32 KiB and requires
USB09 plus the broad matrix before promotion.

Do not add drive identities, model-specific rules, fixed per-drive delays, or
mandatory optional SCSI commands. Keep power-cycle persistence and
fresh-session CRC testing in explicit diagnostics rather than customer export.

## Current State

Completed:

- USB09 incident and architectural cause recorded.
- Broad USB compatibility policy added to `AGENTS.md`.
- Prior 32 KiB and larger-write performance evidence preserved as historical
  input rather than assumed Stage 1 qualification.
- Stage 0 planning checkpoint pushed to draft GitHub PR #4.
- Current-versus-4.11 USB interaction inventory completed and classified.
- Stage 1 restores the stock v00.04.11 USBX storage sources, USB configuration,
  and 1 KiB application write baseline while retaining current HPT 2.0 and
  export behavior.
- Normal publication no longer requires SYNCHRONIZE CACHE, controller-driven
  VBUS cycling, re-enumeration, remounting, or full-file reread.
- Canonical firmware update/recovery documentation now separates the current
  minimal production lifecycle from the superseded July 30
  qualification-only durability sequence, and the focused source check guards
  that boundary against documentation drift.
- Focused static/host checks and canonical Debug and Release rebuilds pass.
- Exact artifacts and hashes are recorded in
  `work/evidence/usb-stage-1-software-baseline-20260731.md`.
- The owner selected `USB01_2G`, `USB05_4G`, `USB02_8G`, and `USB03_32G` as
  the upfront baseline. All four passed unmounted FAT structure, partition,
  full-device read, capacity, and kernel-error checks on the Pi.
- The exact Stage 1 Release candidate was deployed serial-bound to Controller B
  first and then Controller A. Independent 4 MiB flash readback matches the
  candidate on both controllers; post-reboot SD CID, detection, representative
  sector, HPT ready state, hardware variant, and system-error gates pass.
- Stage 1B round 1 passed with `USB01_2G` on Controller A and `USB05_4G` on
  Controller B. Both completed the common WAV, playback, PID, 8 MiB image, and
  retained HPT export path; independent read-only Pi validation passed without
  repair or unexpected publication artifacts.
- Stage 1B round 2 passed after exchanging those drives. Both repeated the
  complete workflow and prior-image replacement path on the opposite hardware
  variant, and independent Pi validation passed. Image timing follows the USB
  drive rather than the controller, while compatibility passes on both.
- Stage 1B round 3 passed `USB03_32G` on Controller B but failed `USB02_8G` on
  Controller A. USB02 reached a valid FileX handoff after one clean
  reinsertion, then the application closed the session while the device
  remained attached. Independent Pi validation found clean, unchanged media
  with no output artifacts. The inherited `fx_media_volume_get()` gate
  discards the exact failure status and cannot recover a still-attached
  session; incident and evidence are recorded separately.
- Diagnostic round 4 passed `USB03_32G` on Controller A and `USB02_8G` on
  Controller B on first insertion through WAV, playback, PID, image, HPT, and
  independent Pi validation. This proves USB02 is capable on the current
  hardware/data path and localizes round 3 to a non-recoverable application
  session transient. It does not restore the failed Stage 1B gate.
- The narrow recovery correction removes the unused volume-label and
  nonexistent-directory readiness probes, stops application close of
  USBX-owned FileX media, re-arms deferred handoff for an invalidated
  still-attached session, and adds exact lifecycle telemetry. All focused
  checks and canonical managed Debug/Release rebuilds pass at source commit
  `96b8ab4b87e438c41370b24001a5ef00bcd93492`; exact candidate hashes are
  recorded separately.
- The exact recovery candidate was deployed serial-bound to Controller B first
  and then Controller A. Independent 4 MiB readback matches the candidate on
  both controllers; post-reboot SD CID, representative-sector, HPT-ready,
  hardware-variant, zero-error, and no-USB-attached gates pass. Evidence is in
  `work/evidence/usb-session-recovery-controller-deployment-20260731.md`.
- Recovery round 1 repeated the exact previously failing allocation:
  `USB02_8G` on Controller A and `USB03_32G` on Controller B. Both mounted on
  first insertion and passed WAV, playback, PID, 8 MiB image, retained HPT
  export, final attached-state, read-only FAT, exact output, and kernel-error
  gates with zero controller errors and no reseat or VBUS action. Evidence is
  in `work/evidence/usb-session-recovery-round1-usb02-usb03-20260731.md`.
- The opposite-controller cross-check passed bounded WAV load/playback and
  final session gates on both drives. USB02/B mounted on first insertion;
  USB03/A had one recorded below-class first-insertion enumeration miss 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 passed an unchanged, read-only Pi pretest with its exact incident
  identity. FAT structure, complete 8,053,063,680-byte direct read, capacity,
  historical export hash, and kernel-error gates passed; the drive is
  unmounted and ready for Controller A regression. Evidence is in
  `work/evidence/usb09-pi-pretest-health-20260731.md`.
- USB09 mounted on Controller A on first insertion with a fresh valid session,
  but its full retained-range recovery regression failed. The scan selected
  8,540 healthy records with no gaps; USB publication requested 99,328 bytes
  in 97 writes capped at 1,024 bytes, then `fx_file_close()` consumed exactly
  50 seconds and returned raw `0x5C`. Publication remained false although the
  drive remained mounted and the application session valid. 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 confirms the failed publication: the
  two intact FAT copies differ, the free-cluster summary is wrong, the final
  file is absent, and `HPTE.TMP` is 97,280 bytes, 2,048 bytes shorter than the
  controller-requested count, ending mid-record without a completion marker.
  The prior valid export is unchanged and no Pi transport errors occurred.
  Evidence is in
  `work/evidence/usb09-recovery-candidate-pi-failure-inspection-20260731.md`.
- Raw `0x5C` is `UX_TRANSFER_TIMEOUT`, passed unchanged through the stock USBX
  FileX driver. The restored 1 KiB cap is disproven as the compatibility
  baseline: USB09 needed 97 calls and failed close, whereas the same
  specimen's clean prior 32 KiB run completed 374,707 bytes in 12 calls and
  closed in 0.01 seconds. The accepted 32 KiB ADR is therefore reopened as an
  isolated recovery discriminator; no transport, lifecycle, VBUS, or
  specimen-specific behavior is bundled with it.
- The isolated 32 KiB candidate passes all focused USB/export/code-review
  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 deployed B first and A second. Both complete
  4 MiB readbacks match the frozen S-record; both controllers 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`.
- After explicit authorization and a full Windows FAT32 format, USB09 passed
  exact Pi identity, equal-FAT, filesystem, full 8,053,063,680-byte 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 on the
  deployed isolated 32 KiB candidate: 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 Pi verification 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`.
- The immediate Round 1 repeat Pi gate passed `USB01_2G` and `USB05_4G` on
  identity, capacity, read-only FAT structure, equal FATs, retained content,
  current-insertion kernel state, and final unmounted state. Evidence is in
  `work/evidence/usb-32k-round1-precheck-usb01-usb05-20260731.md`.
- The complete 32 KiB Round 1 controller workflow passed both hardware
  variants on first insertion. WAV load/playback, PID, image replacement, and
  full retained HPT exports completed with exact 32 KiB writes, clean
  publication, retained mounted sessions, and zero USB/system errors. The Pi
  closeout remains pending. Evidence is in
  `work/evidence/usb-32k-round1-controller-usb01-usb05-20260731.md`.
- Independent no-repair Pi validation passed equal FATs, exact CSV sizes and
  continuous sequences, completion trailers, PID/WAV content, identical
  internally CRC-valid recovery images, kernel state, absence of temporary
  artifacts, and final unmounted state. Round 1 is PASS end to end. Evidence
  is in `work/evidence/usb-32k-round1-pi-usb01-usb05-20260731.md`.
- Opposite-controller 32 KiB Round 2 passed the controller workflow with
  `USB05_4G` on A and `USB01_2G` on B. A required one clean powered reseat
  after an initial below-class USB05 enumeration miss; B mounted USB01 on
  first insertion. Both completed WAV load/playback, PID, full image
  replacement, and full retained HPT publication in 14 writes reaching the
  exact 32 KiB cap with zero USB/system errors. No VBUS, controller power, or
  drive-specific behavior was used. The enumeration miss remains explicit
  compatibility evidence, and independent Pi validation is pending. Evidence
  is in
  `work/evidence/usb-32k-round2-controller-usb05-usb01-20260731.md`.
- Independent no-repair Pi validation passed equal FAT copies, exact CSV
  sizes and sequences, completion trailers, PID/WAV content, identical
  internally CRC-valid recovery images, current kernel state, no temporary
  artifacts, 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`.
- 32 KiB Round 3 passed the controller workflow with `USB02_8G` on A and
  `USB03_32G` on B. Both completed WAV load/playback, PID and image
  publication, and full retained HPT export in 14 writes reaching the exact
  32 KiB cap with zero USB/system errors. USB03 required one clean powered
  reseat on B after a below-class first-insertion miss. No FileX write had
  begun, so this is not a 32 KiB write failure; it remains explicit
  broad-compatibility evidence. Independent Pi validation subsequently passed
  equal FAT copies, exact continuous CSVs and COMPLETE markers, PID/WAV and
  internally CRC-valid images, kernel state, no temporary artifacts, and
  final unmounted state. Round 3 is PASS end to end. Evidence is in
  `work/evidence/usb-32k-round3-controller-usb02-usb03-20260731.md` and
  `work/evidence/usb-32k-round3-pi-usb02-usb03-20260731.md`.
- 32 KiB Round 4 passed the controller workflow with `USB03_32G` on A and
  `USB02_8G` on B. Both completed WAV load/playback, PID and image
  publication, and full retained HPT export in 14 writes reaching the exact
  32 KiB cap with zero USB/system errors. USB03 required one clean powered
  reseat on A after another below-class first-insertion miss. No FileX write
  had begun, so this is not a 32 KiB write failure; it remains explicit
  broad-compatibility evidence. Independent Pi validation subsequently passed
  equal FAT copies, exact continuous CSVs and COMPLETE markers, PID/WAV and
  internally CRC-valid images, kernel state, no temporary artifacts, and
  final unmounted state. Round 4 is PASS end to end. Evidence is in
  `work/evidence/usb-32k-round4-controller-usb03-usb02-20260731.md` and
  `work/evidence/usb-32k-round4-pi-usb03-usb02-20260731.md`.
- USB09 plus all eight four-drive/controller 32 KiB observations now pass end
  to end. The write-size discriminator is successful; the remaining blocker
  is the repeated below-class first-insertion pattern, which occurs before
  FileX and must be diagnosed without changing the proven 32 KiB write path.
  Matrix closeout is in
  `work/evidence/usb-32k-four-drive-matrix-closeout-20260731.md`.
- A diagnostic-only successor at source commit `a3fe1593` now retains USBX
  system errors, HCD connection/retry state, live device state, and generic
  null-class connection notifications. It also makes the application and
  generated USB event routing null-safe. It changes no write, transport,
  VBUS, SCSI, timeout, retry, or specimen behavior. Focused checks, canonical
  Debug/Release rebuilds, packaging, and exact artifact freezing pass.
  Evidence is in
  `work/evidence/usb-enumeration-diagnostic-software-candidate-20260731.md`.
- The exact diagnostic Release image was deployed B first and A second. Both
  controllers passed serial-bound programming, independent full-flash match,
  fresh SD CID and representative-sector identity, HPT-ready, hardware,
  no-drive, and zero-error gates. Evidence is in
  `work/evidence/usb-enumeration-diagnostic-controller-deployment-20260731.md`.
- Five consecutive natural `USB03_32G` insertions across A/B passed on first
  attempt at high speed with configured USBX devices, valid FileX sessions,
  and zero errors. The failure did not recur, but the retained prior terminal
  state supports one root-port re-enumeration attempt rather than a write-path
  or VBUS change. Evidence is in
  `work/evidence/usb03-enumeration-diagnostic-five-insertion-observations-20260731.md`.
- The bounded recovery candidate at source commit `29fcaa11` retries only a
  final unconfigured `UX_DEVICE_ENUMERATION_FAILURE` with an exhausted USBX
  signal path, once per physical attachment. It changes no drive identity,
  transport, write, 32 KiB cap, or VBUS behavior. All focused gates, canonical
  builds, packaging, exact artifact freezing, and telemetry-size checks pass.
  Evidence is in
  `work/evidence/usb-enumeration-recovery-software-candidate-20260731.md`.
- The exact bounded recovery candidate was deployed Controller B first and
  Controller A second. Both passed serial-bound programming, independent full
  4 MiB S-record comparison, fresh post-reboot SD CID and representative-sector
  identity, HPT-ready, hardware, no-drive, zero-error, and zero-recovery-attempt
  gates. Evidence is in
  `work/evidence/usb-enumeration-recovery-controller-deployment-20260801.md`.
- Six additional natural `USB03_32G` insertions, three per controller and
  alternating B/A, all mounted on the first attempt at high speed with valid
  USBX/FileX sessions and zero errors. Recovery attempts correctly remained
  zero. The final Controller A insertion also passed a 483,324-byte retained
  HPT export in 15 FileX writes capped at 32 KiB and independent read-only Pi
  validation with matching 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`.
- The first qualification-only deterministic candidate at source commit
  `80e6a455` injected all three native USBX root-enumeration failures, but the
  target then consumed another already-queued root-hub signal and mounted with
  recovery attempt count `0`. That result is invalid as recovery proof and is
  retained honestly in
  `work/evidence/usb-enumeration-deterministic-test-software-candidate-20260801.md`.
- Corrected v2 source commit `4032ab50` drains only already-queued root and
  enumeration-semaphore signals after the third qualification failure, records
  but does not clear HCD transfer work, and leaves production recovery, VBUS,
  transport, FileX, write size, and identity behavior unchanged. All focused
  gates, canonical Debug/Release rebuilds, packaging, `0x04 / 0x30 / 0x40`
  symbol checks, and artifact freezing pass. Evidence is in
  `work/evidence/usb-enumeration-deterministic-test-v2-software-candidate-20260801.md`.
- The corrected v2 candidate then produced the missing target proof on
  Controller B: three guarded native USBX enumeration failures reached the
  final failure disposition, production recovery attempted exactly once, and
  `USB03_32G` mounted at high speed with a valid USBX/FileX session and no VBUS
  action. An ordinary removal/reinsertion advanced media generation without a
  second recovery attempt. The qualification hook was removed, the exact
  production candidate was restored, and its full-flash/no-drive gates plus
  canonical Debug/Release rebuilds passed. Evidence is in
  `work/evidence/usb-enumeration-deterministic-v2-target-proof-20260801.md`.
- The isolated active-path BOT correction at source commit `ca6f573a` validates
  exact CSW length, signature, tag, residue, and status before interpreting a
  command result. The linked blocking reset helper already used the required
  Reset/Bulk-In/Bulk-Out order, so no reset-order mutation was needed. All
  deterministic malformed-CSW models, focused gates, canonical builds, exact
  Controller B programming/readback, first-insertion mount, WAV load/playback,
  final zero-error session, and independent unmounted Pi/FAT checks pass.
  Evidence is in
  `work/evidence/usb-bot-csw-validation-and-smoke-20260801.md`.
- The exact BOT candidate was then deployed to Controller A and independently
  read back, matching Controller B. The bounded delta passed `USB03_32G` on A
  plus `USB01_2G`, `USB05_4G`, and `USB02_8G` on B, while preserving the prior
  USB03/B smoke and the full write/publication matrix. Every first insertion
  mounted at high speed with acceptance mask `15`, a valid FileX/application
  session, zero recovery attempts, and zero errors; every WAV load passed.
  Independent unmounted Pi checks proved unchanged equal FATs and clean
  current-insertion kernel state. No reseat, VBUS action, remount sequence,
  optional SCSI lifecycle, media write, or specimen rule was used. Final
  no-drive captures on both controllers passed complete SD CID,
  representative-sector, HPT-ready, FileX-ownership, and zero-error gates.
  Evidence is in
  `work/evidence/usb-bot-representative-delta-regression-20260801.md`.

Incomplete:

- None within this workpackage. A future contradictory incident reopens
  architecture review; it does not justify a specimen exception by itself.

## Goal

Deliver a standards-led USB production path that preserves all current product
features, behaves like the 4.11 common-denominator USB lifecycle, and provides
a controlled baseline for evaluating a single 32 KiB FileX write-size change.

## Why It Matters

The team has spent approximately one week reacting to individual USB-drive
failures. USB09 proved that the current path can publish valid data and still
report failure. Broad compatibility and operator trust must be restored
quickly without throwing away the HPT 2.0 and export work already completed.

## Major Outcomes

- Current non-USB and application-level export features preserved.
- Original USB interaction semantics restored without a wholesale file rollback.
- Stage 1 baseline built and software-gated.
- Representative hardware/specimen matrix defined and executed separately.
- Stage 2 changes only the HPT FileX maximum write from the restored baseline
  to 32 KiB.

## Delivery Stages

Use stages when sequencing, parity gates, or handoff cost matter.

| Stage | Outcome | Entry Evidence | Exit Evidence |
| --- | --- | --- | --- |
| 0 | Current state checkpointed | current dirty tree and five local commits reviewed | intentional commits pushed to GitHub and draft PR available |
| 1 | Current features plus 4.11 USB lifecycle | `v00.04.11`, `ecea1c35`, USB09 incident, current source | scoped diff, static/host tests, canonical Debug and Release builds; no production STOP/VBUS/remount sequence |
| 1B | Hardware baseline | reviewed exact Stage 1 artifacts, four-drive pretest health, and authorized controller plan | all four owner-selected drives on A and B with independent Pi checks, then USB09 incident regression |
| 2 | Isolated 32 KiB FileX write recovery candidate | 1 KiB baseline disproven by USB09 plus prior 32 KiB evidence | USB09 and identical matrix demonstrate compatibility and speed without specimen-specific behavior |

## Related Artifacts

- Tickets:
- Checklists:
  work/checklists/checklist-stage-1b-four-drive-usb-compatibility-baseline.md
  work/checklists/checklist-usb-bot-representative-delta-regression.md
- Spikes:
- ADRs: work/adr/adr-adopt-32-kib-usb-hpt-production-write-cap.md
- Runbooks:
- Inventories: work/inventories/inventory-usb-host-transactions-and-compatibility-policy.md
- Decision matrices:
- Incidents: work/incidents/incident-usb09-false-write-failure-and-usb-compatibility-architecture-correction.md

## Rough Sequence

1. Checkpoint and publish the current Git branch and planning state.
2. Inventory the exact application, USBX, FileX, HCD, configuration, and VBUS
   differences from 4.11.
3. Preserve HPT 2.0 and current export behavior while removing the mandatory
   production durability lifecycle and restoring stock interaction semantics.
4. Restore and test the baseline application write size before changing it.
5. Add static and host-side regression checks and run canonical builds.
6. Review and execute the separately authorized Stage 1B hardware matrix.
7. After USB09 disproves 1 KiB, change only the HPT FileX maximum write to
   32 KiB and repeat USB09 plus the broad matrix.

## Milestones

### Milestone 1: Stage 1 software baseline

Completion criteria:

- [x] Current branch and planning state are pushed to GitHub.
- [x] Every current USB-layer divergence from 4.11 is classified as preserve,
  restore, qualification-only, or separately review.
- [x] HPT 2.0, current CSV/export semantics, firmware updates, graph, warning,
  calibration, and recovery features remain present.
- [x] Normal exports do not require SYNCHRONIZE CACHE, START STOP UNIT,
  controller-driven VBUS cycling, re-enumeration, remount, or full-file reread.
- [x] Baseline application write behavior matches the intended 4.11 comparison.
- [x] Focused checks and canonical Debug and Release rebuilds pass.

### Milestone 2: Stage 1 hardware baseline

Completion criteria:

- [x] The exact candidate and hashes are recorded before deployment.
- [x] The upfront matrix covers `USB01_2G`, `USB05_4G`, `USB02_8G`, and
  `USB03_32G` on both controllers with reviewed paired allocation.
- [x] USB09 is tested afterward without a new specimen-specific mitigation.
- [x] Exports have exact size, completion marker, independent readability, and
  recorded FAT state.

### Milestone 3: Stage 2 isolated 32 KiB candidate

Completion criteria:

- [x] The FileX write maximum is the only behavior changed from accepted Stage 1.
- [x] The same specimen matrix passes without drive-specific production logic.
- [x] Measured export improvement justifies adoption.

## Open Questions

- Whether any later standards-based MBR classification correction is required
  after observing the unmodified 4.11 behavior on USB08.
- Whether stock FileX flush semantics are acceptable for the baseline only or
  need a separately reviewed, optional command policy before release.

## Completion Standard

This completion standard is satisfied: Stage 1 and Stage 2 have comparable
software and hardware evidence, the production path is standards-led and free
of specimen-specific behavior, USB09 and the newer enumeration incidents are
resolved, BOT error handling is deterministic, the representative delta
passes, and current truth is promoted to canonical USB documentation.

## Closeout Routing

- Current truth promoted to: `docs/firmware-update-validation-and-recovery.md` and `docs/sd-card-operation-and-recovery.md`
- Historical context remains in: completed reactive USB workpackages and the USB09 incident
- Runtime/status evidence: `work/evidence/` summaries with raw output under ignored generated evidence
- Cleanup deferred to: USBX modernization beyond the selective 4.11 restoration
