plan: record the kernel service build (RA-live substrate)

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

plans/business-logic-fed-flows.md

@@ -325,6 +325,14 @@ covers everything until a DAG's cost/latency/placement forces the substrate.
   activities), so business logic can change state, which federates, which triggers more flows.
 
 ## Progress log (newest first)
+- 2026-07-02 — the REAL KERNEL SERVICE built (next/kernel/host_kernel.erl + serve.sh + tests/
+  host_kernel.sh, 4/4 over HTTP). A persistent durable-execution service: flow_store + named-flow
+  registry, parameterised flow routes (GET /flow/start/<category> → "<id>:<status>", GET
+  /flow/resume/<id>). Verified live: newsletter→instance 1 SUSPENDED, urgent/draft→DONE, resume 1 in a
+  SEPARATE request→DONE (durable state persists). serve.sh = the persistent launcher (container
+  entrypoint). This is the RA-live substrate. NEXT for RA-live: deploy the kernel (a container/
+  placement) + point host/ra.sx's real-eval at it (POST /flow) + route a durable binding to RA. TA-live
+  adds inbox/outbox routes on the same kernel.
 - 2026-07-02 — PERSISTENT-KERNEL SPIKE PASSED (plans/ra-kernel-spike.sh + ra_kernel.erl). The shared
   prerequisite for RA-live + TA-live is REACHABLE: a background sx_server (flow_store + blocking
   http:listen) holds gen_server state across HTTP requests — /start suspends instance 1, a separate