feat: expand companion platform, device controls, and memoir workflows

Add customer and operator login, BLE provisioning, device fleet controls, call memory, memoir generation, and refreshed family and maintenance portals. Include API contracts, migrations, firmware sources, tests, assets, and deployment documentation.
2026-10-08 10:06:44 +08:00
parent 98fb2965d0
commit bf1233d5df
861 changed files with 94614 additions and 3209 deletions
@@ -0,0 +1,51 @@
+# EchoEar screen wake, 2026-10-07
+
+Firmware `1.7.0-controls.32` (fleet version code 15) and API
+`0.99.58-rc.screen-wake1` add wake by a short screen tap while in standby.
+The first tap restores the display and microphone without starting a call.
+The next tap keeps the existing start/stop conversation behavior. The existing
+50–1500 ms short-touch threshold, 300 ms debounce, and provisioning long press
+are preserved.
+
+The touch task queues the wake to the control worker. Before changing hardware,
+the worker persists an event UUID and the applied configuration revision in NVS.
+After local wake succeeds, the authenticated control report includes that event.
+The API changes only desired power from standby to active under the twin row lock,
+increments its revision once, and records the receipt in the same transaction as
+the actual hardware report. The firmware clears the event only after an exact
+receipt and a committed NVS erase, then applies returned configuration. Newer
+cloud revisions supersede an old offline event; duplicate delivery is idempotent.
+
+An offline tap can wake after initial configuration has been applied. During
+initialization, a tap is retained until a configuration revision is available.
+Hardware, NVS, and missing-receipt failures retry. An unacknowledged event survives
+a reboot. No database migration, credential change, or binding reset is needed.
+
+Verification:
+
+- Three host suites compile the production C with undefined-behavior sanitizer:
+  screen-call, screen-wake, and device-power. They cover first-tap consumption,
+  debounce, offline wake, hardware/NVS failures, receipts, and restart recovery.
+- Six onboarding tests passed against an isolated PostgreSQL/Redis environment
+  initialized with all 77 production migrations, with no skips. They cover actual
+  reports, tenant/device isolation, duplicate and concurrent wake delivery,
+  revision fencing, and preservation of volume and device name.
+- `go vet`, Linux API build, ESP-IDF firmware build, and task-path diff checks pass.
+- Production API was built from release `0.99.57-rc.viking-console1` plus only the
+  two onboarding source/test changes. Its binary was read back and verified after
+  deployment. All 157 web files, runtime configuration, schema version 77, and
+  21 other containers are unchanged.
+- Firmware compilation inputs were checked against the installed `.31` baseline:
+  five changed production files, two new wake files, and 5407 verified inputs.
+- The published application is 3776624 bytes, below the 4194304-byte OTA limit,
+  SHA256 `7b61a24a1d38c7a98db7b11de4d5866339c767c448ddd538d6b4ef88b12f7133`.
+  HTTPS publication readback matched exactly.
+- COM6 device `KP01-8995ACF5E69E` installed this image through OTA into slot
+  `0x10000`. Boot verification and server receipt both reported success. Firmware
+  and version code report `.32`/15, one binding at generation 1, volume 45, and
+  standby at configuration revision 4. The first attempt retained `.31` after
+  DRAM allocation failed at final verification; reboot and retry succeeded.
+
+Physical touch confirmation is tracked separately in the package verification
+record. Automated tests and successful installation do not establish that a
+person has touched the physical display.