# HPT initialization mailbox and Pi adapter software deployment evidence

Status: PASS for the original adapter checkpoint; superseded for future programming by `work/evidence/hpt-initialization-readiness-software-continuation-20260805.md`
Type: evidence
Date: 2026-08-05
Parent: work/wp/active/wp-build-standalone-pi-sd-qualification-operator-application.md

## Outcome

The missing HPT initialization path is now implemented on both sides of the
controller boundary. Firmware exposes a guarded fixed-mailbox ABI owned by the
SD thread, and the Pi qualifier provides an exact, non-replayable operation
adapter with immutable intent, full preflight, finite read-only reconciliation,
terminal validation, and required post-initialization CID capture.

This checkpoint is software-only. No controller endpoint was enabled, no tools
container ran, no J-Link target was contacted, no controller was programmed,
and no SD card was initialized. Therefore this checkpoint creates no new
controller or CID evidence. The last valid Controller A identity remains the
2026-08-05 baseline evidence linked below.

## Firmware implementation and gates

- Source base: `dd99776ad6c1ee67bcf1b2f30721f5f60f644a7b`.
- Reviewed source snapshot SHA-256:
  `c9ada4d5122b52727fcb0533148253ed4026b10bbe724abc598b8784fd8bbde2`.
- The request is 176 bytes and binds the exact request UUID, operation UUID,
  boot witness, bundle/artifact/mapping SHA-256 identities, CID, authorization
  expiry, and safe-state token.
- The 256-byte command mailbox uses odd/payload/even coherent publication,
  CRC32, a command sequence, and a publication sequence.
- The acknowledgement is 80 bytes and the progress/terminal status is 160
  bytes; both use coherent publication.
- Only the SD-owner thread consumes the request. It validates identity,
  boot/session, expiry, eligibility, conflicts, and duplicate IDs/sequences
  before invoking the existing initialization implementation.
- The legacy HMI service cannot publish the new mailbox, and no debugger
  function call or private-variable write is part of the contract.
- Terminal success requires HPT ready, readable commissioning state, matching
  CID, and proof that the exact request was consumed.
- Canonical managed Debug and Release rebuilds passed.
- Existing commissioning invariants passed `95/95`; HPT2 endurance checks and
  model passed; the new mailbox checker passed `15/15`.
- Packaging script parse, bundle member hashes, S-record validation, and
  `git diff --check` passed.

The immutable Release bundle is
`smi-00-05-00-c9ada4d5122b-e51ae77e9fab-release` with:

- ELF SHA-256: `886a143cbe5ca2e6e78d029becb48a0710f4aabaebbe5c6421234e170a2aed6c`
- S-record SHA-256: `e51ae77e9fabc031ae57b3968aa9b0c8a6a404764663e54ae96e69138d5ae2c6`
- Mapping SHA-256: `b2ef9403567c1afb6fef3f57b4a7424f7733691b2b1d5050c945a50907dff917`
- Manifest SHA-256 after Pi import:
  `7f44a6b4d9812ea1c63a04cd2bcef24422d9fc93254f4e33d318ff805a4fc1f8`
- Imported state: valid, `admitted=false`, scope `none`.

## Pi qualifier implementation and gates

Pi source commit `1572ed39ca2d9d0ae2daaa954be1136289d2c790`
adds the exact `HPT_INITIALIZE` authorization envelope, durable operation and
phase models, migration `0016`, guarded preparation/execution/reconciliation
commands, strict bundle/mapping/flash/CID preflight, and a one-shot tools
service. The adapter will not replay a consumed publication and requires a
fresh post-initialization CID capture before success.

- Migration drift check passed with no changes detected.
- Initialization/mailbox/scrub focused suite passed `54/54`.
- Compose-policy suite passed `5/5`.
- Full generic-container suite: `148 passed, 3 failed`; the three known
  environment-dependent tests require the HPT execution mount or host clock
  marker absent from that generic test container. Focused exact-image and live
  health gates passed, so these are recorded as environment gaps rather than
  product regressions.
- Python compilation and source diff checks passed; no secret-like material
  was found in the source diff.

The deployed fixture-only release is
`hpt-initialization-adapter-1572ed3`, image digest
`sha256:491a0708cb81a9e1789db3309fe678b75d414d5e54dcd30a75e9faa81de865ad`.
Database migration `0016` is applied. HTTP health is ready for database,
storage, clock, web, command worker, and notification worker. Fixture-only is
true, live admission is false, every state-changing profile remains disabled,
both controller-role lists/endpoints are empty, and no initialization tools
container is running.

Rollback and recovery surfaces:

- Pre-deployment image tag:
  `srv-rpi00-sd-qualifier:rollback-1e62f33-pre-hpt-init`.
- Verified database backup:
  `/backups/sd-qualifier-20260805T125627Z.dump`.
- Verified offline release package:
  `/home/jong/dev/sd_qualification/release-media/hpt-initialization-adapter-1572ed3`.

## Gate disposition

The adapter is deployable but deliberately not live-admitted. The new firmware
changes the exact controller image, so the earlier Controller A full-address
scrub cannot qualify it. The next sequence is:

1. Firmware-owner review and admission of the exact bundle above.
2. Separate authorization to program and verify Controller A.
3. Fresh exact-candidate read-only observation with the complete boot-relevant
   CID identity block.
4. A new full-address baseline scrub under that exact candidate.
5. Only after those gates pass, review and mint the short-lived exact
   initialization envelope and machine intent.

Do not reuse or replay the earlier scrub or initialization intent, and do not
initialize manually. Controller A's last accepted baseline remains
`work/evidence/controller-a-baseline-scrub-readonly-reconciliation-20260805.md`.
