5dive

dev3 (CHANNELS=none) filed a manual gate correctly. It pinged no one. The board showed blocked, the filer was told the gate was filed, and the only reason anyone found out is that dev3 messaged its lead out of band. Measured, not inferred: every gate from an agent WITH a channel had gate_pinged_at stamped within a second; the one from the agent WITHOUT a channel had it NULL.

• the escalation code already existed and had never once fired. DIVE-1243 added an org-lead fallback for exactly this, and it probed the lead's channel by READABILITY (-r access.json). Every agent's channel dir is 0700 and its access.json 0600, so a sibling agent can NEVER read a peer's pairing state. Permission-denied was indistinguishable from unpaired, so the fallback read the whole fleet as unpaired, logged "no lead channel either", and returned 0. A feature that cannot succeed on any real box, sitting green for months.
• paired-ness is now probed separately from readability. _task_agent_paired answers "does this agent have a channel at all" from the group-readable connector token plus a bare -d on the channel dir (the parent .../channels is 0755, so the probe works from any uid). That distinction is the whole fix: unreachable must fail loudly, reachable-but-unreadable must be delivered by someone who can read it.
• the walk goes UP the whole org chart, not one hop. _gate_route_reviewer stopped at the first manager plus the coordinator; if that one manager is also unpaired the ask died there. _task_escalation_chain walks reports_to upward (depth-capped, cycle-guarded) and the alert NAMES the original filer, because it arrives on the manager's bot and would otherwise read as the manager's own gate.
• reachable-but-unreadable is delivered by a privileged re-send. New root-only task gate-escalate <ident> re-sends an already-filed, still-pending gate; agents reach it through their existing NOPASSWD sudo entry (hardcoded to /usr/local/bin/5dive — sudoers grants that exact path, so a command -v result would be refused for a reason unrelated to the channel). The raw human nonce crosses on stdin, never argv.
• an unnotified gate is FILED and MARKED, never refused — and the first cut of this got it wrong. The original fix refused to file when nobody in the chain was paired, on the principle that a gate nobody can answer should not be recorded as filed. The principle is right and the precondition was wrong: it equated "no paired Telegram channel" with "no human can answer", when the dashboard Needs you card, task inbox and task answer are answering surfaces that need no channel at all. CI went red (nothing is ever paired there), and with it 5dive goal's plan gate, tests/gate_parity_smoke.sh — which asserts precisely this contract, "gate filed CLI-only with no Telegram present" — and every solo OSS, fresh-install or headless box. A second cut tried to scope the refusal to deployments that have channels configured; that still broke the parity smoke, because whether some OTHER agent on the box is paired says nothing about whether THIS gate can be answered. Every attempt to define "nowhere to land" mis-fired in an environment we did not control, which is the signal that the condition does not exist. So the gate always files; what must never happen — an unnotified gate reading identically to a notified one — is handled by marking it instead: notified:false in the JSON, an UNNOTIFIED note on the result line, a logged delivery error, gate_pinged_at left NULL, and the 15-minute re-nag re-driving it until it lands. Losing a gate is worse than delaying one.
• the heartbeat re-nag had the same hole and the same fix. An unpaired recipient meant "retry next heartbeat" forever, which for a channel-less filer can never become true. It now escalates up the chain (that sweep runs as root, so every access.json is readable). A gate with NO delivery receipt is also retried at 15 minutes instead of waiting the full hour.
• verified live, not by reading the notify function. Filed as agent-dev3 against the real board: the unprivileged leg failed loudly and rolled the gate back; the privileged leg delivered to the paired human with a confirmed Bot API receipt (result=ok … message_id=…) and stamped gate_pinged_at.
• the pairing probe itself is three-valued, because a boolean put the conflation back one layer over (found by main reviewing the PR). _task_agent_paired read the connector env with a bare -r, so an existing-but-unreadable token would have read as unpaired. Inert today (those files are 0640 root:claude and every agent is in group claude), but converting a silent degradation into a hard refusal raises the cost of every latent probe upstream of it: before this change an unreadable probe cost a delayed gate, with fail-closed task need it costs a REFUSED gate on a healthy chain. Now 0 paired / 1 provably not paired / 2 undetermined, and only a provable 1 licenses refusing; 2 escalates to a sender that can actually see. The failure text distinguishes them as well — "nobody is paired" is only claimable when every agent up the chain was provably unpaired, otherwise what we know is that the hand-off failed. Its negative control is root-proof: the fixture points CONNECTORS_DIR at a regular file, since a chmod 000 fixture proves nothing in a root CI run.
• the first cut of this fix shipped the same bug one layer down — _task_chain_channel was called in $(…), so the TASK_CH_* it resolved died in the subshell and the "escalated" send went out with an empty token to an empty access file, still returning 0. Caught by the live run, not the suite; the suite now records the channel state AS OF THE SEND and greps for the call-site shape. task gate-escalate likewise asserts the CONFIRMED receipt rather than a resolved channel.