task-36: chrecd already runs CHRE; the gap is three chre_slpi methods

docs/tasks/36-chre-nanoapp-host.md

@@ -47,20 +47,56 @@ Nanoapp binary format is confirmed standard CHRE: `elmyra.napp_header` parses
 as `NanoAppBinaryHeader` — magic `NANO`, appId `0x476f6f676c00100e`,
 appVersion 3, target CHRE API 1.5.
 
+## MOST OF THIS ALREADY EXISTS (found 2026-07-27, after the task was written)
+
+The original framing — "open the `chre_slpi` handle from Linux" — was wrong
+about the starting line. **We already do that, and CHRE is already started on
+the SLPI right now.**
+
+`hexagonrpc-blueline` ships `/usr/libexec/hexagonrpc/chrecd`, and hexagonrpcd
+spawns it (`hexagonrpcd … -p /usr/libexec/hexagonrpc/chrecd`). Both are running
+on the phone today (pid 863 under pid 729). `blueline-hexagonrpcd-sdsp` is
+active, so the doorbell that TASK-13's 07-26 entry recorded as crash-looping is
+healthy.
+
+The gap is precise and small. `~/Projects/hexagonrpc/chrecd/interfaces/chre_slpi.def`
+defines **exactly two** remote methods:
+
+```
+HEXAGONRPC_DEFINE_REMOTE_METHOD(0, chre_slpi_start_thread,         0, 0, 0, 0)
+HEXAGONRPC_DEFINE_REMOTE_METHOD(1, chre_slpi_wait_on_thread_exit,  0, 0, 0, 0)
+```
+
+chrecd starts the CHRE thread and waits for it to exit. That is all it does.
+There is no nanoapp loading and no host↔CHRE messaging — so CHRE is running on
+this device with **zero nanoapps in it**.
+
+What the vendor daemon uses beyond those two is visible in
+`blobs/los-vendor/bin/chre_daemon_msm`: `loadNanoapp`, a "MsgToHost thread",
+and `get_message_to_host returned unexpected error (%d)`. The skel side
+(`dsp/sdsp/libchre_slpi_skel.so`) dispatches through `chre_slpi_skel_invoke`
+and carries the matching host-message strings ("Cannot deliver NULL pointer
+nanoapp message from host", "Rejecting message of size %zu bytes").
+
+So the missing methods are stop-thread, get-message-to-host, and
+deliver-message-from-host.
+
 ## Shape of the work
 
-1. **Open the handle.** `remote_handle_open("chre_slpi", &h)` against the SLPI
-   over FastRPC, then `remote_handle_invoke` for the skel's methods. Our
-   `blueline-hexagonrpcd-sdsp` already owns the SLPI FastRPC session and does
-   the hard part (glink/FastRPC session setup, HexagonFS) — but it serves a
-   filesystem; it does not open arbitrary remote handles. Decide early whether
-   this is a new client process sharing the session or a hexagonrpcd feature.
-2. **Start CHRE.** The skel's thread-start invoke, then the host↔CHRE message
-   pipe (`chreSendMessageToHostEndpoint` is what nanoapps call outward).
-3. **Load a nanoapp.** Push header + binary through the load invoke. Start
-   with `elmyra` since TASK-13 gives an unambiguous pass/fail: squeeze the
-   phone, get an event.
-4. **Surface it.** A squeeze becomes an input event through the gesture/
+1. **Get the method indices from the source, do not guess them.** CHRE is
+   AOSP-open (`system/chre`), and `chre_slpi.idl` there is the authoritative
+   ordering; the skel's dispatch table is the cross-check. Getting this wrong
+   invokes the wrong method with a plausible-looking signature.
+2. **Extend `chre_slpi.def`** with those methods, in hexagonrpc's existing
+   macro form. This is upstream-shaped work (codeberg sensh/hexagonrpc), not
+   blueline-specific.
+3. **Message pump.** A get-message-to-host loop plus a deliver-from-host path.
+   CHRE's host protocol is flatbuffers-encoded and also lives in `system/chre`.
+4. **Load `elmyra`.** Header + binary through the load-nanoapp request. TASK-13
+   gives an unambiguous pass/fail: squeeze the phone, get an event. The
+   nanoapp then calls `ashConfigureElmyraFilters` itself — which is the whole
+   point, since that symbol is unreachable from anywhere else.
+5. **Surface it.** A squeeze becomes an input event through the gesture/
    keyboard routing system (INTERFACE-ARCHITECTURE §4), never a hardcoded
    binding — and the radial dial (TASK-31) is what it opens.