FABRIC-3.md §H: close gap #7 -- private-topic traffic stays ungated

Checked MSG-SEND directly -- no ACL check anywhere in it today, on common
or a private topic alike. Confirmed: private-topic traffic stays ungated;
trust is established once at the handshake (CH-REQUEST/CH-ACCEPT/
CH-CONFIRM) and never re-checked per-message afterward. The message
card's scope is now final: it gates the single CH-REQUEST call, nothing
else in the messaging path.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

FABRIC-3.md

@@ -3751,13 +3751,23 @@ isn't a future design, it's already substantially built:
 **Scope confirmed narrow and one-sided**: gates only "who's allowed to post on `common`
 requesting a commune" — the *initiating* side of the H.7 handshake, i.e. who's allowed to
 call the real `CH-REQUEST` function above. The receiving VM's decision to accept/ACK (i.e.
-`CH-ACCEPT`) is **not** gated by this card. Not yet stated: whether traffic on an established
+`CH-ACCEPT`) is **not** gated by this card.
-private topic (post-handshake) is gated by this card, a different mechanism, or left ungated.
+
+**Private-topic traffic gating, resolved 2026-09-02**: checked `MSG-SEND`
+(`capsules/common/messaging.4th:213`, the underlying primitive both `CH-REQUEST` and any
+private-topic traffic use) directly — no ACL check anywhere in it today, purely mechanical.
+**Confirmed: private-topic traffic stays ungated.** Trust is established once at the
+handshake, and nothing re-checks permission on every subsequent message within an
+already-open private topic — consistent with this card's own narrow scope and the elevation
+trigger's "keep it simple for now."
+
+**The message card's full, final scope**: gates only the single call to `CH-REQUEST`.
+Nothing else in the messaging path is ACL-gated by design.
 
 **Implementation-gap note (2026-09-02)**: since `CH-REQUEST` is real, already-callable code
-with (as far as checked) no ACL gate in front of it today, this card's job is now a concrete,
+with no ACL gate in front of it today, this card's job is a concrete, well-targeted wiring
-well-targeted wiring task — add the gate check to the real function — rather than a
+task — add the gate check to the real function — rather than a hypothetical one waiting on
-hypothetical one waiting on future messaging infrastructure. Not yet built.
+future messaging infrastructure. Not yet built.
 
 ### H.9 — Gap analysis (as of 2026-09-02)
 
@@ -3791,9 +3801,9 @@ Explicitly open items surfaced during this capture pass, none decided yet:
    `MSG-ACK-LAST`/`MSG-NACK-LAST` all exist and work today in `capsules/common/messaging.4th`).
    The message card's gate is now a concrete wiring task onto a real function, not a
    hypothetical one waiting on future infrastructure.
-7. **Private-topic traffic gating (H.8).** Whether messages on an established private topic
+7. **CLOSED 2026-09-02 — private-topic traffic gating (H.8).** Confirmed ungated — `MSG-SEND`
-   (as opposed to the initiating `common` post) are gated by the message card, some other
+   has no ACL check today; trust is established once at the handshake, nothing re-checks
-   mechanism, or left ungated entirely.
+   permission afterward. The message card's scope is now final: it gates `CH-REQUEST` alone.
 8. **The `EXPIRE`/D.2 relationship.** D.2 already established "session ending = VM detach,
    reuse `COOL`" — H.1's pinned/non-pinned framing should be read as refining that, not
    replacing it, but the two have not been explicitly reconciled in one pass.