# Controller A second power-cut attempt disposition

Status: invalid physical attempt; retained as proof that Controller A did not reset
Type: evidence
Updated: 2026-07-23
Next Action: repeat the armed cut using the now-proven J-Link-off/discharge sequence and require automatic post-cut boot verification
Campaign Reason: Historical record from campaign 013-close-hpt-media-2-initial-release-qualification; retained independently after campaign closure and requires no separate owner-queue execution.
Campaign: standalone

## Disposition

The arm capture proves firmware commit `dff53e2d` reached the requested
data-durable-before-commit hold on Controller A `1751136`, J-Link `69664082`,
and `HPTCS0`. The interrupted sequence was `188`; sequence `187` was the last
acknowledged setup record.

The operator disconnected power from J-Link, then removed controller power,
observed the display turn off, restored controller power, waited for boot, and
only then powered J-Link again. The controller displayed
`SD card is not installed`.
Read-only inspection proved this was not a raw-HPT boot failure and not a true
MCU reset:

- diagnostic command remained `0x48504331`;
- diagnostic state remained `HOLDING_CUT_POWER`;
- the diagnostic block-device wrapper remained installed;
- the controller run delta advanced from 4 at arm to 562 after reconnection;
- public SD state remained the harness's intentional `UNAVAILABLE` hold state;
- HPT media and store status remained healthy with all three lanes present; and
- interrupted sequence `188` had not advanced the store tail while held.

The retained command, diagnostic state, and wrapper are ordinary `.bss`
objects. The Renesas startup path zeros `.bss` from `__bss_start__` through
`__bss_end__`, and the map places all three diagnostic objects inside that
range. Powering J-Link after controller boot cannot recreate their prior
values. The capture therefore proves only that this startup-clearing path was
not observed. It does not prove the operator left J-Link powered or performed
the sequence incorrectly. Possible explanations include a supply rail that
remained above the MCU reset threshold long enough to bridge the interruption,
a brownout/hold-up condition that did not execute normal startup, or an error
in the qualification method that must be isolated with a simpler witness test.

The hold was cancelled after capture. Cancellation completed the interrupted
append and restored normal raw ownership. Post-cancel status showed
`SD_CARD_STATE_RAW_HPT`, HPT/SSP status zero, normal device context, all 15
queued records completed, zero drops, and next sequence advancing through
normal logging. Because cancellation allowed sequence `188` to commit, no
recovery qualification may be run from this attempt.

The host harness now has a `VerifyPostCutBoot` gate. It captures the diagnostic
command/state, startup counters, HPT media/store state, device context, media
generation, and recovered tail. Recovery is blocked unless the gate proves:

- diagnostic command and state were cleared by a true reset;
- the normal HPT device context replaced the diagnostic wrapper;
- raw HPT reopened healthy;
- media generation did not change;
- the recovered next sequence equals the interrupted sequence; and
- no system error is present.

The new gate rejected this attempt exactly as intended because diagnostic state
survived and sequence `188` was later committed by cancellation.

A subsequent RAM-only witness passed when the operator powered J-Link off,
waited 10 seconds, powered Controller A off, left both unpowered for 30
seconds, booted Controller A with J-Link off, and then powered J-Link on. Both
volatile markers cleared and raw HPT reopened healthy. This validates the
operator sequence and shows that later J-Link power-up does not recreate the
diagnostic RAM. The next armed attempt will use these explicit discharge waits.

Do not use this directory to claim a verified cold boot, physical power-loss
recovery, or completion of the power-cut qualification. Preserve the
operator-reported power sequence as valid testimony; the unresolved problem is
why firmware startup clearing was not reflected in the captured state.
