feat(comm): enable cross-namespace messaging in AllowAll gate mode

[ohdearquant]

Problem

comm.send denies every cross-namespace message unconditionally — even when the runtime is in the AllowAll (OSS / local-MCP) gate mode. This makes agent-to-agent messaging effectively dead in the default OSS configuration: any send where from != recipient_ns returns CrossNamespaceWrite regardless of policy.

Evidence

crates/khive-pack-comm/src/message.rs:81–100 — the recipient namespace is compared to the sender and rejected with CrossNamespaceWrite before the policy gate is ever consulted:

if from != recipient_ns_str {
    return Err(CrossNamespaceWrite);
}

The denial is hardcoded; the AllowAll gate has no opportunity to permit it.

Expected

Cross-namespace comm.send should be governed by the active policy gate, not a hardcoded comparison:

• AllowAll / OSS mode → permit (local single-tenant deployments need agent↔agent messaging).
• Restricted / multi-tenant mode → continue to deny per ADR-007.

Fix sketch

Route the cross-namespace decision through the gate (same pattern other write paths use) instead of the unconditional if from != recipient_ns_str short-circuit. Add a regression test for both gate modes.

Priority: p1 — blocks the comm pack's primary use case in OSS deployments.

Ported from old repo issue #516 (repo since recreated; old numbers invalid). Verified against current source 2026-06-07.

[ohdearquant]

Triage update (λ:khive, 2026-06-20) — premise is stale on current main; reclassifying to needs-design

The issue's evidence (if from != recipient_ns → CrossNamespaceWrite unconditional, "before the policy gate is ever consulted", ported from old #516 / verified 2026-06-07) no longer matches current main. dual_write_message in crates/khive-pack-comm/src/message.rs:84-119 now does:

1. Actor-routed sends (from_actor.is_some(), e.g. comm.send(to="lambda:leo")) → gate is skipped; both copies land in the caller's namespace (ADR-057 dual-write). These already work — no PermissionDenied.
2. Pure namespace cross-ns sends (no actor) → gated by the allowed_outbound_namespaces config allowlist (runtime.config().allowed_outbound_namespaces). Permitted if the recipient ns is declared; otherwise PermissionDenied with a message telling the operator to add it to actor.allowed_outbound_namespaces in khive.toml.

So the unconditional hardcoded denial described here is gone — there is a config-driven gate.

What remains of the ask is narrower and a design question, not a bug: should the AllowAll / OSS gate mode auto-permit cross-ns sends without requiring the allowed_outbound_namespaces allowlist? That couples directly to the namespace-authorization model being actively redefined in ADR-007 Rev work (#179 Rev 7, #157 Rev 2) — specifically ADR-007 Rev 3's "authorization lives at one seam: the Gate." The current pack-level config allowlist is arguably a second seam that Rev 7 may consolidate into the Gate.

Recommendation: hold #13 for the ADR-007 Rev decision rather than patch the comm pack now (changing the cross-ns authorization path mid-ADR-flux risks conflicting with #179). Once ADR-007 Rev lands and defines the Gate's cross-ns policy by mode, #13 becomes a mechanical wire-up. Relabeling needs-design + coordinate-with-ADR-007. Not touched this overnight sweep.

[ohdearquant]

Re-verified against current main (crates/khive-pack-comm/src/message.rs). The unconditional denial this issue describes (if from != recipient_ns { return Err(CrossNamespaceWrite) }) no longer exists. Current dual_write_message (message.rs:131-167) behaves as:

• Same-namespace send (from == recipient): no check.
• Actor-addressed send (from_actor set, e.g. to="lambda:leo"): the cross-namespace gate is skipped by design (ADR-057 dual-write; both copies land in the caller namespace, stamped with to_actor). This is the primary agent-to-agent path and it works in AllowAll/OSS mode today.
• Raw namespace-to-namespace send (no actor label): gated by the sender allowed_outbound_namespaces config list; non-listed recipients get PermissionDenied.

So the original p1 claim ("blocks the comm pack primary use case in OSS") is no longer accurate. The residual is narrower: should a raw ns->ns send (no actor) consult the active gate mode (AllowAll permit) rather than the static allowlist? ADR-007 Rev 6 already centralizes authorization at the Gate and treats namespace as attribution, so the cleanest resolution is to have AllowAll mode permit (or auto-populate the allowlist) rather than add a second policy seam in the handler.

Recommendation: downgrade from p1 and re-scope to that residual design question, or close if the explicit allowlist is accepted as the intended OSS-safe default (even single-tenant deployments arguably should declare cross-namespace recipients). Flagging for a maintainer decision rather than building a gate change, since it touches the ADR-007 one-seam principle.