# Ticket: Offer explicit format action from installed-unformatted SD notification

Status: complete
Type: ticket
Updated: 2026-08-11
Next Action: none
Parent: work/wp/active/wp-triple-mirrored-circular-hpt-log-store.md
Project Map: work/maps/map-smi-firmware-stabilization-and-qualification.md

Remote Execution Owner: jong@srv-rpi00.local:~/dev/sd_qualification

The remaining injected failure is a remote campaign case. This repository owns
the firmware behavior and final local operator-visible review, not campaign
orchestration or generated evidence collection.

## Problem

When an SD card is physically installed and readable but does not contain the
current supported HPT format, the controller reports the condition but does not
offer the user a direct recovery action from that notification. The user must
navigate separately to the formatting service.

## Expected Behavior

The installed-but-unformatted/unsupported-format notification includes a
`Format` button. Selecting it enters the existing guarded destructive-format
workflow. It must never begin erasure from the notification itself and must
retain the explicit whole-card warnings and confirmations.

## Acceptance Criteria

- [x] The Format button appears only when a card is installed, has valid
  protocol identity and readable representative sectors, and requires explicit
  HPT initialization or supported reformat.
- [x] No Format button is offered for no-response, representative-read failure,
  write-protected media, or another state where formatting is unsafe.
- [x] Selecting Format routes to the canonical format workflow and preserves
  all required destructive-operation confirmation screens.
- [x] Dismissing or backing out of the workflow performs no media write and
  returns to a stable notification/home state.
- [x] Successful format clears the notification and returns normal HPT status;
  a failure remains visible with the specific failure reason and recovery path.
- [x] The notification, button action, cancellation, success, and injected
  failure paths are driven and observed through J-Link where practical.
- [x] Final operator involvement is limited to visual confirmation of wording,
  button placement, legibility, and navigation behavior.

## Verification

Use host/source invariants plus target RAM-command/status evidence for
eligibility, action, cancellation, success, and failure. Perform one final
operator screen review on the frozen candidate.

## Development evidence

The source/invariant gates and Controller B read-only J-Link evidence pass on
2026-07-25. Controller B reported valid CID/read state, FAT32-needs-
initialization, eligibility true, and no initialization request. The card was
not formatted. See
`work/evidence/hpt-log-store-circular-mirror/pre-freeze-integration-20260725.md`.

Controller B subsequently passed the CID-bound guarded HPT initialization,
post-initialization reopen, three cold-start/reopen/CID witnesses, final-image
program/verify/reset, full-address scrub, and integrated HPT/chart/logging
gate. This closes the autonomous successful-initialization baseline without
claiming the notification's operator-visible presentation or every injected
failure state.

The exact pre-format write-protect state is not electronically distinguishable
on this board because the generated SDMMC instance uses
`SDMMC_WRITE_PROTECT_NONE`; the initializer still queries/rejects driver
write-protection before the first write. The final candidate's failure text is
therefore verified through the deterministic HMI mapping and accepted common
progress-screen navigation rather than an unavailable remote injection
profile. Generic `SD Error 900/901` failure text was replaced with confirmed
phase, HPT status, driver status, service-468 recovery, and
power-off-before-replacement guidance. Final evidence and the explicit
target-injection equivalence disposition:
`work/evidence/hpt-operator-failure-message-closeout-20260811.md`.
