host P0.3: wire the seam into the live publish path (LIVE-VERIFIED)

Publishing a post now fires the on-publish behavior DAG through the seam. host/blog--{transport
(activity log), triggers (on-publish: create+article → publish-DAG), driver (records each effect in
the flow log), publish-engine (behavior/make-engine over the four adapters + the execute-fold runner
+ publish-ctx), fire-publish!, maybe-publish!}. Both write handlers (form-submit POST /new,
edit-submit POST /:slug/edit) detect the draft→published TRANSITION (fire-once) in the handler body
and run behavior/process. GET /flows renders the flow log (the effect-as-data the driver dispatched).

LIVE PROOF: logged in + POST /new on blog.rose-ash.com → /flows shows 'validate' + 'notify' (the
publish-DAG branched on the default urgent category), driven end-to-end by the real behavior engine.
Every piece is a seam adapter — swapping the runner for Erlang (RA) or the transport for fed-sx (TA)
federates this same wiring unchanged.

blog 207/207 (+4 P0.3), full host conformance 595/595. GAP: flow log is in-memory (P0.3b = persist).

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

plans/business-logic-fed-flows.md

@@ -146,11 +146,16 @@ fed-sx yet — those are adapter phases (RA/TA). Every piece swaps later; the DA
   memoization / optimize (fuse/dedup/dce) / schedule / FEDERATION (a flow result reused across peers
   by content-id — the federation vision, free). The capability model makes that migration seamless
   (same DAGs, richer runner; the execute-fold is just the pragmatic sync runner NOW). See phase AX.
-- [ ] **P0.3 — wire the seam on the live host.** A local-SX trigger registry (on-publish →
-  publish-DAG), an in-process transport (a KV-backed log), the host as effect driver. In edit-submit
-  detect the draft→published TRANSITION (prev≠published & new=published — fire-once), build the
-  activity, behavior/process it (in the handler BODY, not a render). ACCEPTANCE: publish a post on
-  the LIVE host → the effect surfaces (a /flows page + a durable record).
+- [x] **P0.3 — wire the seam on the live host. DONE + LIVE-VERIFIED 2026-07-02.** host/blog--
+  {transport, triggers (on-publish: create+article → publish-DAG), driver (records each effect),
+  publish-engine, fire-publish!, maybe-publish!}. Both write handlers (form-submit POST /new,
+  edit-submit POST /:slug/edit) call maybe-publish!(slug, prev-status, new-status) — a non-published
+  → published TRANSITION fires the flow (fire-once), in the handler BODY. /flows renders the flow
+  log. LIVE PROOF: logged in + POST /new on blog.rose-ash.com → /flows shows `validate` + `notify`
+  (category defaulted to urgent). behavior→exec-runner→driver all real. blog 207/207, conformance
+  595/595. GAP: the flow log is IN-MEMORY (clears on restart) — "durable record" is P0.3b (persist
+  the log to the blog store + boot-load, string-keyed to dodge the keyword/persist split). Also: the
+  live test post `p0.3-seam-live-test` persists (no delete route) — harmless, clean up if wanted.
 - [ ] **P0.4 — canonical activity + reconcile.** Move host/blog--publish-activity to the seam shape
   {:verb :actor :object <cid> :object-type :delta :ts :id}; keep the category/slug fields the DAG reads.
 
@@ -209,6 +214,12 @@ 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 — P0.3 DONE + LIVE-VERIFIED. The seam wired into the live publish path: on-publish
+  registry + in-process transport + host driver + the execute-fold runner, fired by the draft→
+  published transition in both write handlers. Published a real post on blog.rose-ash.com → /flows
+  surfaced validate + notify, driven by the actual behavior engine. blog 207/207, conformance
+  595/595. NEXT: P0.4 (canonical activity shape) or P0.3b (durable flow log); then P1 (types declare
+  behavior — build the engine per type from its :behavior bindings, runner derived via caps).
 - 2026-07-02 — DON'T-CALCIFY note (user: "artdag may in the future contain business logic"). The
   execute-fold-vs-artdag split from P0.2 is a capability SNAPSHOT, not a boundary. Added phase AX:
   artdag grows +{effect,branch,each} node-kinds and business logic migrates onto it to inherit