# 0.5.1 physical downlink validation — 2026-10-04

This is an in-progress physical record. Software test success does not establish
screen or speaker success. Next tests: [checklist](physical-downlink-0.5.1-next-test.md).

## Released baseline

- Mac main, origin/main and Lighthouse main: `52d1d609ee980a88737bd0143e7b84d88cd4a4c3`, clean.
- Gateway restarted at 09:45:40 Asia/Shanghai; active/running, health ok, NRestarts 0.
- Production firmware freshly built on main: version 0.5.1, 2,123,456 bytes.
- Merged SHA-256: `9204bb3a8513c7ee897adca895a1575a87eaf9928a002796b1b79c478269f71a`.
- Flashed and hash verified on Mac: `/dev/cu.usbmodem1101`.
- Full Lighthouse suite: 137 Python, 18 Node, six firmware host harnesses,
  Gateway smoke and authenticated TLS voice smoke passed; IDF build and linked glyph checks passed.
- Pi target: `01a0fcd2-7b96-77fb-a57a-40bbfb9fe5da`, project `/home/lighthouse/esp32-dev`.
- Speech Mode OFF confirmed through Gateway.

## First voice attempt: live Pi lacked its control endpoint

Physical capture completed with 59 chunks / 208,152 PCM bytes, no capture failure,
successful voice_start/end sends, transcript-ready (12 bytes, zero missing glyphs),
and a queued SEND decision. Firmware then received voice_error/FAILED, with no
Agent RUNNING. The user saw `input failed`.

Read-only checks showed a live IDLE heartbeat but an absent session control socket
(ENOENT) and HTTP 502 from settings. The user ran `/reload` in that same Pi session.
Its control ping and settings then succeeded. No duplicate runtime was started,
and input was not automatically replayed. The original endpoint-init failure is
unknown; reload restored it.

## Retry: input and text downlink reached hardware; DONE notification crashed

The retry captured 55 chunks / 194,040 PCM bytes without error. Firmware received
SENT, RUNNING on the selected session, accepted text activity on PI with no modal,
and DONE with `final_bytes=277`. The selected Pi session returned a Chinese final
reply acknowledging the voice input.

Immediately after DONE, the first notification PWM pulse logged successfully,
then serial reported:

```text
***ERROR*** A stack overflow in task pi_notify has been detected.
ELF file SHA256: 963117b25
Rebooting...
```

Exact-ELF decoding identifies vApplicationStackOverflowHook / vTaskSwitchContext.
The corrupted remainder does not identify an individual driver frame. This is a
physical firmware notification failure, not evidence of failed final-text delivery.
After reboot, the device reconnected and received the same 277-byte final again.
Screen correctness and stable terminal rendering remain unconfirmed.

The follow-up firmware fix gives vibration tasks using the M5IOE1 PWM/I2C/logging
path 4096 bytes instead of 2048, including DONE/FAILED and approval patterns. It
logs the minimum free stack in bytes after the pattern completes. Rebuild and
physical pattern-completion/margin/no-reboot evidence are still required.

## Current physical status

| Area | Status |
|---|---|
| Voice input to selected Pi | PHYSICAL PASS on retry after extension reload |
| RUNNING / text activity / final payload receive | Serial evidence PASS; visible screen checks pending |
| Chinese Agent rendering / final screen | NOT YET CONFIRMED |
| DONE notification stability | PHYSICAL FAIL: pi_notify stack overflow; follow-up fix awaits retest |
| Read Screen / AUTO_REPLY / interrupt | NOT TESTED |
| Screen flicker | Visual observation pending |
| Startup page | Serial shows Overview initially, then automatic PI selection on target restore; independent UI issue |

Full local traces and conductor state are preserved under ignored
`dist/physical-validation-20261004/` on the Mac. No credentials or audio are
included in this document. Tests 2–6 are suspended until notification stability
is restored. No network, audio transport or I2S tuning was performed.