---
name: twohost-rig-real-notify-mode
description: "The [twohost] rig runs the notify shell in REAL mode (resident → notify-0 ONLINE) — a drive-drop rung asserting offline against notify-0 fails on the rig"
metadata: 
  node_type: memory
  type: project
  originSessionId: 5b0a69e3-d6a3-47f7-8152-ee14e5b4ff5c
---

The `[twohost]` CI rig (twohost-a/twohost-b in ci.yml) sets
`SPT_TWO_HOST_NOTIFY_BIN`, so `seed_notify_shell` runs in **real mode**: the
notify-shell binary is **resident** and BINDS → `notify-0` is **ONLINE** on the
rig. In **fallback** mode (no NOTIFY_BIN, local dev) the spawn is a noop that
never binds → `notify-0` OFFLINE. So a rung's behavior against notify-0 DIVERGES
by mode.

This bit M11-W5 (run 27604406083): the W2 cross-node drive **drop-not-wake** rung
(landed at W2, `[twohost]`-gated so NEVER run on the rig until W5's first fire)
drove `notify-0` asserting `dropped`+`offline` — but on the real rig notify-0 is
ONLINE, so the drive **delivered to the live slot (latest-wins)** and the assert
panicked: "drove notify-0 type=stick (live slot, latest-wins)". Production drive
logic is correct (online→deliver, offline→drop); the rung's "offline" assumption
was a fallback-mode artifact. Role A panicking there also aborted it before the
gateway rung → role B timed out (consequential).

**Rule:** for a drive-DROP / offline-shell proof on the rig, use a
**deterministically-offline noop shell** (own adapter, noop spawn, never binds) —
NOT the mode-dependent resident notify shell. Anything asserting offline behavior
against notify-0 will be wrong on the real rig.

**Lesson:** a `[twohost]`-gated rung that has never actually fired on the rig is
UNPROVEN regardless of how green normal CI is — its assumptions meet reality only
on the first real fire. Fire `[twohost]`-gated rungs before trusting them.
Related: [[m11-w4-progress]], [[no-machinewide-killon-shared-runner]].