Repository navigation
UI-12: route Bloom Shell power hold through lifecycle shutdown #643
Description
Observed behavior
On signed Mini Plus runtime v0.1.0-dev-0b3b5d96, a physical power hold from the Bloom Shell root produced no Saving or Shutting Down surface. Bloom Shell remained visible for about 30 seconds, then the device powered off. This was observed separately from the SSH recovery in PR #642 and is not counted as a UI-12 shutdown pass.
Root cause
system_state_update() correctly classifies the frontend as MODE_BLOOM_SHELL, but keymon::deepsleep() has no branch for that mode. It sets /tmp/.offOrder, leaves Bloom Shell running, waits the 30-second watchdog, and falls through to force_shutdown(). Because runtime.sh is still blocked waiting for Bloom Shell, it never reaches check_off_order "End", so the lifecycle surface is never drawn.
Required correction
- terminate Bloom Shell through a bounded graceful path after publishing the shutdown order;
- let Bloom Shell finish its normal state/media cleanup;
- treat the shutdown-triggered frontend return as expected in the shell guard;
- let
runtime.shrender the built-in lifecycle surface before the clean power service runs; - preserve the existing game/save shutdown path and clean FAT shutdown behavior;
- add focused host tests for Bloom Shell shutdown, guard state, and lifecycle ordering;
- validate with a guarded candidate first, then one physical Mini Plus power-hold check;
- keep remote/process/framebuffer evidence distinct from the required physical observation.
Safety
This issue does not authorize Wi-Fi/profile/key/listener mutation. The device is currently signed known_good, healthy, and key-only SSH is clean.
Activity
boburning commentedon Aug 31, 2026
Physical Mini Plus retest on signed candidate �0.1.0-dev-e9ce0c30 failed the UI gate.\n\nObserved by the maintainer:\n- poweroff completed much faster than the prior approximately 30-second watchdog path;\n- neither the Saving surface nor the power-off/Shutdown surface was physically visible;\n- the device powered back on successfully.\n\nPost-boot bounded telemetry:\n- installed candidate remained exact and deliberately unconfirmed in esting;\n- boot attempts: 2;\n- aggregate health: healthy;\n- clean-shutdown telemetry recorded successful swap disable and read-only FAT remount;\n- network transaction: idle;\n- listener audit: clean with reviewed key-only SSH;\n- retained rollback source remains the previous signed known-good version.\n\nDisposition: the graceful Bloom Shell exit portion of #644 is effective, but its lifecycle presentation is not. The current runtime launches �ootScreen asynchronously and starts clean power after a fixed one-second delay, so the renderer has no completion boundary or guaranteed physical dwell. I am correcting that ordering in #644 itself; this candidate will not be confirmed.
boburning commentedon Sep 1, 2026
Second signed Mini Plus physical gate failed on
v0.1.0-dev-8aa37619.Observed by the maintainer:
Verified recovery:
v0.1.0-dev-0b3b5d96;8aa37619as the failed version;known_good.Follow-up commit
c1fc6624targets the shared renderer failure point: Saving and Shutdown no longer enter the legacy battery-header path, andbootScreennow retains framebuffer ownership for 1.5s/2.5s inside the renderer rather than exiting before an external shell sleep. Focused lifecycle checks pass 14/14 and the changedbootScreensource compiles with the pinned Miyoo ARM toolchain. A new signed candidate will remain unconfirmed until the next physical LCD/power gate passes.boburning commentedon Sep 1, 2026
Physical Mini Plus gate: PASS
v0.1.0-dev-c1fc6624from commitc1fc66240475a0763d132da84342b8fb3cdeb66cbootScreenandruntime.shhashes matched across the two boots.known_good.Structured evidence:
docs/validation/ui/plus-ui12-shutdown-c1fc6624-20260831.jsonScope remains Mini Plus only; no video capture, non-Plus hardware, audio, gameplay, save-semantics, or soak claim is made.