cross-domain slice 1: events as a fed-sx peer + allocate-a-post-to-a-calendar (LIVE)

The first cross-domain federated workflow — behaviors defined by TYPES, across domains.

- events.rose-ash.com is now a fed-sx PEER: a lib/host instance with SX_DOMAIN=events whose 'calendar'
  TYPE declares an on-allocate behavior. Replaces the Python events service (no strangler). serve.sh
  gates domain types/behaviors on SX_DOMAIN (blog=article publish/digest; events=calendar+allocate).
- DIRECTED cross-domain delivery: an activity with :to <peer-base> is delivered to that peer's inbox
  (∪ followers). The wire gains 'to'. So 'allocate' targets the events peer specifically.
- host/blog--allocate-activity/allocate! + POST /:slug/allocate?calendar=<id>; the events calendar
  type's allocate-link DAG (an execute-fold effect) fires on receipt.
- docker-compose: the sx_events service (own store, shared SX_FED_SECRET, externalnet for a future
  events.rose-ash.com Caddy route).

LIVE PROOF: publish 'Gig Night' on blog.rose-ash.com → POST /gig-night/allocate?calendar=main → the
events peer RECEIVES the directed, signed activity (/activities: 'allocate article gig-night') and
its calendar type's on-allocate behavior FIRES (/flows: 'linked gig-night'). blog 218/218, full
conformance green.

NEXT: events runs lib/events (real calendars/recurrence/ticketing); link event→post; shop
(lib/commerce) sells tickets — same federated, type-declared shape.

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

plans/business-logic-fed-flows.md

@@ -334,6 +334,17 @@ 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 — CROSS-DOMAIN slice 1 DONE + LIVE-VERIFIED: allocate-a-post-to-a-calendar (blog→events).
+  events.rose-ash.com is now a fed-sx PEER — a lib/host instance with SX_DOMAIN=events, whose
+  "calendar" TYPE declares an on-allocate behavior (behaviors ARE type-declared — confirmed). Built:
+  DIRECTED delivery (activity :to <peer> → delivered to that peer's inbox, in addition to followers;
+  wire gains "to"); host/blog--allocate-activity/allocate! + POST /:slug/allocate?calendar=; serve.sh
+  SX_DOMAIN gate (blog=article behaviors, events=calendar+allocate-link DAG); the sx_events container
+  (own store, shared fed secret). LIVE: publish "Gig Night" on blog → allocate to calendar main → the
+  events peer RECEIVES the directed activity (/activities) and its calendar type's on-allocate behavior
+  FIRES (/flows "linked gig-night"). Signed + directed cross-domain federation, type-declared reaction.
+  NEXT (the vision): events runs lib/events (real calendars/events/recurrence/ticketing); make "linked"
+  a real relation/event; then link an event→post; then shop (lib/commerce) sells tickets. Same shape.
 - 2026-07-02 — FEDERATION PRODUCTION LAYER DONE + LIVE-VERIFIED (the actor model + the rest). (1)
   ACTOR MODEL: activities carry a real :actor (SX_ACTOR, not "site"); delivery is FOLLOWER-based, not
   a static peer list — a peer POSTs {verb:follow, actor, base} to /inbox to subscribe; B follows A at