# Complete bounded HPT slow-export firmware ticket

Status: complete
Type: campaign
Updated: 2026-08-17
Next Action: none
Campaign ID: 003-complete-bounded-hpt-slow-export-firmware-ticket
Campaign Number: 003
Outcome: Eliminate bounded HPT customer-export latency caused by full-history scanning while preserving export invariants and broad USB compatibility.
Primary Focus Areas: hpt-media-logging
Supporting Focus Areas: smi-firmware, usb-host-publication, qualification-release
Depends On: 002-checkpoint-sd-qualification-and-tool-shed-state
Decision: none
Detour For: none
Return To: none
Completion Gate: The ticket is complete with an approved performance budget, passing builds and focused tests, and authorized Controller A and B large-history evidence.
Completion Evidence: work/evidence/campaign-003-fast-history-route-authorization-and-clean-stop-20260817.md
Completion Date: 2026-08-17
Completion Order: 4
Disposition: completed

## Request Context

Priority: 2
Target: firmware workspace `E:\dev\high_point\7520553_SMI_FW`
Coordination: coordinated
Execution Route: work2
Parent: `work/maps/map-smi-firmware-stabilization-and-qualification.md`
Primary Ticket: `work/tickets/ticket-eliminate-full-history-scan-latency-for-bounded-hpt-customer-exports.md`

## Goal

Eliminate full-retained-history scan latency for bounded HPT customer exports
without weakening data integrity, snapshot consistency, range correctness, or
the broadly qualified USB publication path. Finish the active ticket with
software, build, and explicitly authorized Controller A/B evidence.

## Dependency gate

Require the scoped SDQ/Tool Shed checkpoint from request `002`. If it does not
exist or includes unrelated changes, stop and report that exact blocker. Keep
the SD Qualifier appliance and all terminal campaigns untouched.

## Required work

1. Read the primary ticket and canonical
   `docs/sd-card-operation-and-recovery.md` requirements. Reproduce/profile the
   current selection path and separate range location, HPT reads, validation,
   staging, and USB publication.
2. Map the snapshot, retention, gap, three-lane voting, degraded-copy,
   wrap/reclaim, concurrent-append, media-generation, capacity, and timestamp
   invariants. Do not assume timestamps are monotonic.
3. Present the baseline and obtain an owner-approved quantitative latency
   budget before choosing the final correction. The ticket's initial
   `<=60 seconds` evaluation target is not approval by itself.
4. Implement the smallest general range-addressable correction. Do not change
   the accepted 32 KiB FileX write cap, add controller/USB specimen exceptions,
   require optional USB commands, or hide long work behind misleading UI state.
5. Add oracle comparisons and deterministic edge coverage for duplicate,
   forward-jumped, backward-adjusted, boundary, missing, malformed, degraded,
   wrapped, reclaimed, concurrent, capacity-exceeded, and media-generation
   cases. Preserve request-specific progress and terminal telemetry.
6. Run focused and adjacent tests, then the canonical managed Debug and Release
   rebuilds, packaging, and artifact/hash validation. Do not use the isolated
   headless builder.
7. Stop before programming a controller or beginning physical target work
   unless the operator explicitly authorizes the exact firmware image, target,
   USB label/move, and nondestructive procedure. Powered SD-card removal or
   insertion is prohibited.
8. With that authorization, prove representative large-history Controller A/B
   behavior against a trusted full-scan oracle, verify exact CSV/FAT/publication
   results independently, and record before/after elapsed/read telemetry.
9. Update and complete the primary ticket only when every acceptance criterion
   has direct evidence. Do not create or import the final SDQ firmware bundle;
   request `004` owns that freeze.

## Completion gate

Complete only when the ticket is truthfully complete, the approved latency
budget is met on both hardware variants, builds and tests pass, data-integrity
invariants are preserved, and no newer contradictory result remains. If exact
physical authorization is absent, finish safe software/build work but leave
this queue item unchecked with the authorization blocker stated plainly.

## 2026-08-17 execution adjustment

The owner authorized replacing eight exhaustive `129600 / AFTER` iterations
per controller with a minimum-sufficient fast-history construction path. The
long runners were stopped through acknowledged firmware Stop operations and
finalized as clean bounded-stop results with case trigger not met; they do not
claim S4 completion credit. Controller A preserved 41,109 verified records and
Controller B preserved 110,097 verified records from those runs.

The replacement may use a temporary diagnostic image only to create valid
range-envelope media in append-batched writes. It must fail closed, preserve
the exact CID bindings, and be followed by an independent complete retained-
history scan. The reviewed candidate image and exact flash identity must be
restored before either measured export. This shortcut is export-test setup;
it creates no endurance, durability, recovery, or later qualification credit.

## 2026-08-17 target and successor-correction result

The append-batched fixture reached 1,000,000 retained records on each exact-CID
card in approximately 30 minutes. The reviewed Release image was restored and
verified by independent flash readback before measurement. Complete retained-
history scans then passed on A and B with 1,000,007 and 1,000,009 healthy
records, zero degraded records, and zero gaps.

Ten-minute exports completed in 4.80 seconds on A and 5.03 seconds on B,
compared with the 1,177.33-second and 693.90-second baselines. Near-visible-
capacity exports of approximately 142,560 rows completed in 200.01 seconds and
224.33 seconds. All four publications reached `PUBLISHED / COMPLETE` with zero
degraded records, gaps, or fallbacks. Independent USB-reader inspection remains
required before those files receive final CSV/FAT closeout credit.

The boundary run also exposed a stale HMI retained-start cache when the visible
retention floor advanced while the physical oldest sequence remained fixed.
The successor correction now refreshes against
`HptTripleCircularVisibleFirstSequence()`. Focused static/model/export checks,
canonical managed Debug and Release rebuilds, and package/hash validation pass.
The exact successor Release S-record SHA-256 authorized for nondestructive A/B
verification is
`75F108D5E2E77031E107B2D71852545C9FD246B128085CCB7D4F6E256BC37462`.

The authorized successor was programmed on both controllers and independently
verified by complete 4 MiB flash readback. Both captures matched expanded-image
SHA-256
`6EEF5DB83CE2AE71AEB63D598ECAD1CFA7D68475EBFE052301F4FC2A0F97DFC4`.
Post-program identity and boot health passed with the same CIDs, protocol state
6, CID-valid 1, representative-sector read status 0, HPT-ready state 5, HPT
status 0, and no system error.

The moving-floor regression passed on both controllers. The physical oldest
lane sequence remained 1 while the cached visible retained-oldest sequence
advanced from 857,491 to 857,492 on A and from 857,492 to 857,493 on B after
the next ordinary production record. Both graph caches reached ready state.
No SD media was moved or reinitialized. Export telemetry is idle on both
controllers, so the remaining USB-reader step is ready for the operator move.

The operator moved `USB07_32G` and `USB05_4G` to the Raspberry Pi reader.
Independent read-only inspection passed every campaign CSV: declared, parsed,
and published record counts agree; line numbers are sequential; health is
clean; snapshot/requested gaps are zero; validation and trailers are
`COMPLETE`; and no `.tmp`, `.part`, or `.bak` file exists. Both FAT copies are
byte-identical. `USB05_4G` retains its root-only volume-label convention.
`USB07_32G` retains its accepted two-cluster primary-FSInfo offset unchanged
and is not described as repaired or clean. Both volumes were unmounted after
inspection.

The only remaining ticket criterion is the ordinary wrapped-history hardware
case. The existing `RunWrapDiagnostic` is not nondestructive: it calls
`HptLogQualificationFormatWrapDiagnostic()` before constructing wrapped media
and would erase each installed million-record dataset. That action is outside
the current nondestructive authorization. Preserve both datasets until the
owner explicitly chooses separate expendable cards or approves a revised
acceptance disposition.

## 2026-08-17 owner acceptance and closeout

The owner accepted the recommended disposition: preserve both installed
million-record datasets, accept the passing deterministic wrapped-history
model and invariant coverage for this bounded-export ticket, and defer the
destructive physical wrap diagnostic to later qualification. This changes the
evidence allocation, not production behavior or fail-closed requirements.

The campaign completion gate passes: the quantitative budget was approved;
focused and adjacent tests pass; canonical Debug/Release builds and package
validation pass; exact successor A/B flash and boot verification pass; both
million-history small and near-capacity target cases pass; independent CSV/FAT
inspection passes with the accepted USB07 media-state observation; and no newer
contradictory result remains.
