No live no-bridge fixture: PolicyMap export-suppression is untested end to end

[NickFlach]

Problem

The Hive bridge's PolicyMap is fail-closed by design: a channel whose no-bridge policy has never been resolved is not exported, and a channel flagged no-bridge stops being exported within HIVE_POLICY_REFRESH_SECS.

None of that is exercised against real data. Surveying wss://buzz.ninja-portal.com as the 0xscada-qe organ returned 25 channels, and not one carried private or no-bridge:

Kannaka-01, Kannaka-02, hive-pulse, hive-mem-test, obs-ytl15, menu-tou8t, job-5084q, typ-ltrxo, two-test, plus multiple phase0-test / agent-test / vending-test fixtures.

So the unit tests cover the policy logic, but no end-to-end run can currently demonstrate that a flagged channel actually stops crossing to NATS.

Why this is the risky half

no-bridge is the only privacy control on the bridge. Human messages cross to the bus and into 90-day JetStream retention by default; the flag is what stops that. An untested export-suppression path is the one you least want to discover is broken.

The refresh window is the subtle part: buzz stores kind 39000 channel-scoped, so live subscriptions never receive it by fan-out. The bridge only learns about a newly-set flag by re-querying history on a timer. A channel flagged no-bridge keeps exporting for up to one refresh interval, and nothing has yet proven it stops after that.

What's needed

Relay-side, not code: flag one channel no-bridge on the Buzz box so there's a live fixture. A throwaway room (phase0-test, two-test) is enough — this doesn't need a real one.

That enables the spec's own end-to-end check: post in a bridged channel, confirm it reaches /nostr, set no-bridge, confirm traffic stops within HIVE_POLICY_REFRESH_SECS.

Note this also depends on relay support for the flag existing — Phase 1b of the bridge spec (the no_bridge column, the kind-9002 edit path, and emitting it on kind 39000) is upstream work in flaukowski/kannaka-buzz and may not have landed yet. If it hasn't, this issue is blocked on that.

Context

• docs/superpowers/specs/2026-07-26-hive-swarm-traffic-on-nostr-design.md, Phase 1b and "Risks"
• Survey evidence: docs/superpowers/specs/2026-07-26-seat-0xscada-qe-in-hive-design.md, "Run log"
• Coordination board: coord-cid

[NickFlach]

Partly addressed in #671 — leaving this open, because it only closes one of the two halves you identified.

What's closed: the suppression path is now proven. The gate only existed inside the daemon's event loop, which a test can't reach, so it moved to hive_bridge::export_decision(event, roster, policy, now_ms) — composing map → policy gate → channel-name re-map as one decision. That placement matches the module's own doc ("the binary is plumbing; everything testable lives here").

Six tests, both directions:

• a no-bridge channel produces no export
• an unflagged channel still does — so suppression can't be achieved by exporting nothing at all
• an unresolved channel is fail-closed (the cold-start case, before the metadata sweep finishes)
• flipping an open channel to no-bridge stops its export
• the agent subject bypasses the channel gate, pinned so that exemption isn't later widened into "anything without a channel bypasses policy"
• an unmappable event yields nothing regardless of policy

The gate check removes the policy call: exactly the flagged, unresolved and flipped cases fail while the two "still exports" guards stay green.

What's still open — and why I stopped: you asked for a live fixture on wss://buzz.ninja-portal.com, and your survey found none of the 25 channels carrying the flag. Creating one means writing state to a production relay, which I'm not going to do unprompted. A live fixture would prove something my tests can't: that the relay's own kind-39000 metadata reaches the bridge intact and is parsed as expected.

Happy to create the channel if you want it — or if you'd rather flag an existing throwaway (hive-mem-test, two-test, one of the phase0-test fixtures), say which and I'll do that instead.

[NickFlach]

Sweep triage 2026-08-07: still blocked on #645 (nothing emits a no-bridge tag yet, so there is no real flagged channel to exercise the fail-closed path against). Once #645 lands relay-side, the fixture is: flag one throwaway channel, assert it stops crossing to NATS within HIVE_POLICY_REFRESH_SECS, and assert an unresolved channel never crosses at all.

[NickFlach]

Unblocked: flaukowski/kannaka-buzz#18 (merged 2026-08-07) shipped the relay-side no-bridge policy — channels.no_bridge column (migration 0027), owner/admin-tier kind:9002 no-bridge tag edit, and the no-bridge tag on relay-signed kind:39000. The end-to-end fixture described here is now runnable: flag a throwaway channel on buzz.ninja-portal.com, assert it stops crossing to NATS within HIVE_POLICY_REFRESH_SECS, and assert an unresolved channel never crosses.

[NickFlach]

Verified at kannaka-memory master 78ab2e5 on 2026-08-10. This issue has two halves and they are in different states.

The code half is DONE

The specific gap this issue named — "the unit tests cover the policy logic, but no end-to-end run can currently demonstrate that a flagged channel actually stops crossing to NATS" — was closed in-code by #671 (5821a26, "test(hive-bridge): prove export suppression end to end (#636)"). export_decision was extracted precisely so the composition can be exercised, and src/hive_bridge/mod.rs:518-534 now holds:

/// #636 — the risky half. A channel flagged `no-bridge` must produce NO
/// export. Previously PolicyMap and map_event were each unit-tested while
/// nothing exercised the two together, so the suppression path itself was
/// unproven.
#[test]
fn no_bridge_channel_produces_no_export() { … }

paired with bridgeable_channel_still_exports so suppression can't be achieved by exporting nothing at all — i.e. the assertion is not vacuous. PolicyMap also has the flip/ordering cases covered (src/hive_bridge/policy.rs:162-210: no_bridge_channel_is_not_bridgeable, policy_flip_to_no_bridge_is_honoured, older_event_does_not_reopen_no_bridge_channel, newer_event_does_unflag_no_bridge).

The live-fixture half is BLOCKED upstream — confirmed, not assumed

This issue predicted it: "this also depends on relay support for the flag existing — Phase 1b … is upstream work in flaukowski/kannaka-buzz and may not have landed yet. If it hasn't, this issue is blocked on that."

It has not landed. Checked the local flaukowski/kannaka-buzz checkout at 575d6e4af: a case-insensitive search for no_bridge / no-bridge / nobridge / bridgeable across all .rs, .sql, and .toml returns zero hits, including across all 8+ migrations. Buzz does emit and serve kind:39000 channel metadata (crates/buzz-admin/src/main.rs:515-538, crates/buzz-acp/src/relay.rs:711) and already carries a comparable per-channel boolean in archived (relay.rs:162) — so the shape exists, but the no_bridge column, the kind-9002 edit path, and emitting the flag on kind 39000 are all still unwritten.

So the relay-side ask ("flag one channel no-bridge on the Buzz box") cannot be done yet — there is nothing on the relay that would accept or serve the flag.

Recommendation

Retitle/rescope this to track only the live end-to-end verification, and mark it blocked on kannaka-buzz Phase 1b. The concrete unblocking order is:

1. flaukowski/kannaka-buzz: add the no_bridge column, accept it on the kind-9002 channel-edit path, and emit it as a tag on kind 39000. The archived flag is the closest existing precedent to copy.
2. Flag a throwaway room (phase0-test / two-test) on the Buzz box.
3. Run the spec's check: post in a bridged channel → confirm it reaches /nostr; set no-bridge → confirm traffic stops within HIVE_POLICY_REFRESH_SECS.

Until step 1 exists there is no kannaka-memory change that would move this forward, so I have not opened a PR against it.