Phase 16 — A watcher that refuses

⚠ This phase is parked, by operator call: “chat-watch is a little side project. If it isn’t broken I don’t want to mess with it right now.” It is specced, not scheduled, and nothing is blocked on it.

The goal in one sentence: make the one operating constraint the previous phase ships with a machine refusal instead of a written rule — because the moment it matters is the moment nobody is reading the doc.

“Nobody arms a watcher while calmly reading a playbook; they arm one while debugging something at speed, which is when a written constraint is least likely to surface.”

A documented rule has to be recalled at exactly the wrong moment. The check is one indexed lookup. The silent failure is two agents talking until their budgets are gone. Cheap machine refusal, expensive silent failure — and that asymmetry is the whole argument.

It came out of removing a clause from the posting tool, which exposed that the clause had been standing in for a guard that does not exist. The watcher’s sender-exclusion list is hand-maintained: armed with two ids while the agent users had grown to four, with thirteen more planned. Nothing fails when it falls behind. Agents simply start being heard.

⭐ The measured fact that bounds the exposure: the fleet alone cannot close a loop. Each bridge joins exactly one channel, that binding is unique, and a bridge replies into its own room. So one agent reaching another is one hop, then silence.

The watcher is the one component with none of those constraints — no uniqueness, arbitrary channels, and a filter that can silently fall behind. It is precisely where a loop could close.

The work was scoped into three slices, and the first needs nothing from anyone: refuse at startup to watch a channel that already has a bound responder. One indexed lookup. The second — filtering on the account flag instead of a hand-kept list, which is correct by construction — needs an operator decision about scope, because it changes which populations an agent can hear. The third retires the stale arming instructions from both runbooks.

⚠ It was deliberately kept out of the previous phase, and the reason is not purity. That scoping question is an operator decision rather than an implementation detail — and this program has already been burned by exactly this shape: a phase grew from one slice to eight by absorbing found work, and had to be reverted mid-build.

⭐ So the written constraint is the standing answer, not a stopgap: do not arm a watcher over a channel with a bound responder. It is enforceable today by not doing it, and both live watchers point at a channel no bridge answers. Unpark it if a watcher is ever pointed at a fleet channel, or if the stale filter actually bites.