Stage O-A: the Tripod is an observer -- outside the compudynamic comparison, acting on events (FABRIC-3.9.0 §2, 3.9.8)

Observer flag on switch-signal slots, set by the kernel for the Tripod
(is_fleet_foundation, hoisted; Hera in kernel_main). The decision: an
observer in progress or holding an event keeps the CPU; observers with
events (mail, Hera's console input) go ahead of participants, oldest wait
stamp first; participants compared by work heat as before. Observers are
never charged (O-2) nor floored. Uncommitted heat-share charge discarded.

Evidence, byte-identical amd64/aarch64/riscv64: G interleave unchanged;
Hestia's mail runs before any worker output (HHHABB...); a line typed
while two workers run is read and executed mid-stream (...ABAB1 2 + . /
3 ok / ABAB...) -- console responsive under load. Relay 3, dict_hash
unchanged. Busy-wait DOE deliberately not run (deadlocks by design until
O-C). FABRIC-3.9.0 records rulings and Captain Bob's messaging note (§7).

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

FABRIC-3.9.0.md

@@ -154,3 +154,41 @@ C-4 (α)'s starvation: under load, the console, USB and storage wait until every
 4. **O-4:** device servicing under load: (c) accept for the relaunch and (b) interrupt-driven
    later (proposed), or (a) treat the device-poll interval as a Hera event.
 5. **Discard the uncommitted absolute-heat-share charge** (proposed), or keep it as a safety net.
+
+**RULED 2026-09-24, Captain Bob: "all as proposed."** O-1 through O-4 and the discard (5) all go
+as proposed above.
+
+## 7. Raised 2026-09-24: messaging should flow on its own (OPEN, not yet designed)
+
+**Captain Bob, verbatim:** *"Another potential defect is perhaps in messaging itself. We
+shouldn't have to actually specifically decide to send a message … that should be autonomous by
+the operating system itself … The messages should just flow. … However, I would still have a
+manual method of sending and receiving messages … I should be able to create channels manually,
+I should be able to destroy channels manually, I should be able to inject messages into the
+queue, all of that should be manual, but also able to operate autonomously."*
+
+**What exists today** (traced, not proposed):
+- **The kernel side is complete in C:** `sk_hermes_channel_create/destroy/subscribe/unsubscribe/
+  is_member/member_count`, `sk_hermes_publish`, `sk_hermes_send_one`, and the negotiation calls
+  (`channel_request/respond/close/open_policy`), in `kernel_hermes.c`.
+- **Only `SEND` reaches FORTH.** There are also the fixed-purpose `KH-BLK-ATTACH-SEND` and
+  `KH-ELEVATE-SEND`. There is no FORTH word to create or destroy a channel, subscribe, publish,
+  or inspect a queue.
+- **Every message today is sent because some code decided to send it:** the console relay,
+  BLK-ATTACH, `SEND` in a job. Nothing is routed by the OS on its own.
+
+**Two parts, which separate cleanly:**
+- **Manual.** FORTH words over the existing C API: create/destroy a channel, subscribe and
+  unsubscribe, publish, inject a message into a queue, and inspect queues. Mechanical: mostly
+  exposure, not new mechanism. The ACL decides who may use them (`ACL.4th`, never C).
+- **Autonomous.** What should flow without anyone deciding, and on what trigger, is a real design
+  question. Candidates to discuss:
+  - events the OS already knows about (a VM born, killed, parked idle; a device attached);
+  - results a VM leaves on its stack or in a known place, routed to whoever subscribed;
+  - heat/physics events routed to observers, which fits "observers act on events".
+
+  Not designed. It needs Captain Bob's framing first.
+
+**Relation to the O stages:** independent of O-B to O-D. The event-driven DoE driver (O-C) is one
+concrete case: a worker's completion notice is today a `SEND` in the job text, and could become an
+OS event ("worker parked idle after its job") if autonomous flow lands first.