docs(d8-phase-2): inbound never reads the gate — active pod is its own switch, leaving it is heard, the page writes podId

[lilyshen0722]

Follow-up to #1545 from Vera's review of #1550 (pod 63797): isRelayableIntegration decided inbound by the gate for user-scoped rows, so once the reconciler pruned gates[A] for a pod the owner left, every message they typed into their own DM was dropped with a server log line while the page still read linked to A. Fails closed, but silently (REVIEW rule 19).

Ruling (63798): D3 stands. The gate is pod → me; the active pod is me → pod. Two facts, two switches.

What changes in the note:

• D3: inbound compares podId, never gates; its outer guard is membership, checked at receive as outbound checks it at send; an unrelayable bare message (no podId, or owner not a member) is answered in the chat once per message; /pod was never built, so the page writes podId (owner-only, member-of-pod).
• D3 prune: dropping the gate for the pod that is also podId unsets podId in the same write.
• D2: a not linked to a pod row (idle dot, ink Pick a pod).
• D4: mono active tag on the active pod, bordered Make active in each other pod's collapsed section; expanded picker when podId is unset.
• §3: PR C carries the inbound comparison, the chat reply and the podId prune; PR D carries the page pieces.
• §4: seed 6b walks the leave-the-active-pod path both before and after the sweep, plus the owner/creator/non-member PATCH answers.

Docs only. Code lands in #1550 (PR C) and the page PR.

🤖 Generated with Claude Code

[lilyshen0722]

Gate clear at 2e1aaa48. Docs only, one file, base main.

The ruling is carried correctly rather than patched over the top:

• D3's /pod claim is retired, not softened. The bullet now states plainly that nothing in the webhook writes podId and that ADR-025 D12 named a command that was never built, then hands the write to the page. That sentence was the load-bearing error — a note that keeps a nonexistent verb as its recovery path describes a system nobody can use.
• The two switches are now stated as two facts. Gate is pod → me, active pod is me → pod, and the inbound predicate compares podId. That closes the divergence between the note and isRelayableIntegration.
• Silence is named as the bug. The unrelayable bare message is answered in the chat once per message, on both providers, with the copy given inline.
• Seed 6b is the right shape. It asserts the chat reply both before and after the sweep, asserts the prune unsets podId alongside the gate, and pins the case the ruling turns on: gates[B] off with podId: B changes nothing inbound. It also covers the two 403s on PATCH { podId } — non-owner and non-member.

One non-blocking note

D4 describes the gate list as "one row per pod the user is in (GET /api/pods filtered as the pod picker already is — never community/showcase)".

The server has never enforced that filter. POST /:installableId/install validates podId as an ObjectId and then checks isPodMember — nothing narrows by pod type — so PATCH { podId } as specified inherits the same gap, and both verbs will accept a community or showcase pod the owner happens to belong to.

The impact is small: it is the owner's own DM authoring into a pod they are already a member of, which they could post to from the web regardless. But the note now leans on that filter in two places while it exists only in the page, which is the inverse of this plan's own rule that the page never renders a control the server does not enforce. Either both verbs narrow by pod type server-side, or D4 should stop citing the filter as if it were a guarantee.

Nothing here blocks the press.