fix(security): exclude invite-only pods from agent discovery

[lilyshen0722]

Superseded my own comment-only change on this branch — sprint-review out-argued the position it documented, so the code moved instead of the comment.

My reasoning was premature, not wrong. I justified the divergence as "an agent should see a room it could ask to join." But H5 request-access does not exist — ADR-016 reserves it as a future slot. An agent shown an invite-only row can neither join nor request access. It is a dead end, which is the same reasoning that excluded those rows from human Discover. The argument becomes correct the moment H5 ships and the row acquires a verb; that is recorded as the revisit trigger.

Adopts joinPolicy: { $ne: 'invite-only' } only. Deliberately does not adopt communityDiscoverQuery wholesale: its members: { $ne: callerId } clause exists because human Discover means find something new, whereas this route means what may I see — adopting it would delete with one hand what the $or branch adds with the other. sprint-review separated these two clauses correctly; I had lumped them.

Both halves now have a test (6 passing, up from 4).

Measured before changing: 3 community-listed pods, 0 invite-only — so the divergence is theoretical today and a test against production data would pass vacuously. Fixed anyway, because #793's comment claimed this route could not drift from human Discover, and that should be true rather than aspirational. AX entry 1 is about precisely that class of comment.

[lilyshen0722]

Approve. The behavior is right and both new tests are real. One non-blocking finding, and it is about the line this PR added.

Verified

Mutation-tested both new tests (agentsRuntime.podEnumeration.test.js, 6/6 green on the branch):

mutation	result
strip joinPolicy: { $ne: 'invite-only' }	only "invite-only pods are excluded" red — 5 green
add members: { $ne: … } back in	only "pods the agent IS in are not excluded" red — 5 green

Each test is pinned to exactly one behavior with no collateral. That is the property that makes them worth keeping.

The adopted clause is character-identical to podListing.ts:34, so the agent path and human Discover exclude the same set — not merely a similar one.

$ne: 'invite-only' is exhaustive today. models/Pod.ts:85 enumerates ['open','invite-only'] with default 'open', and podController.ts:391 coerces any input to one of the two. No third value can slip past. $ne also matches documents missing the field, so any pre-default row stays visible rather than silently vanishing.

No projection-kills-guard hazard. joinPolicy is not in the .select(), but nothing downstream reads it — the response map emits name / description / type / members / updatedAt / summary only. (publicRead and communityListed are projected and never read; harmless.)

The type guards differ and that is safe. The route's nonDiscoverableTypes is ['dm','agent-admin','agent-room','agent-dm']; NON_LISTABLE_POD_TYPES is the same minus legacy 'dm'. The route is strictly stricter, so the delta cannot leak.

Finding — the drift-proofing does not cover the clause that needs it

The comment says "composed rather than restated, so the listing rule itself cannot drift." Half of it is composed. COMMUNITY_LISTING_QUERY is spread; the invite-only half is restated. After this PR there are two copies of joinPolicy: { $ne: 'invite-only' } — podListing.ts:34 and agentsRuntime.ts:2432 — and the duplicated one is the clause added to stop divergence.

The failure this sets up is the PR's own revisit trigger. When H5 ships, invite-only rows should become visible here. Whoever implements H5 will edit communityDiscoverQuery — it is the named, imported, obvious thing. agentsRuntime.ts:2432 has no import binding it to that edit; only a comment asks someone to come back. A comment is a note, not a trigger. The route keeps excluding, and the divergence reopens in the exact line written to close it.

podListing.ts already names this predicate — isDirectlyJoinable = isCommunityListed(pod) && pod?.joinPolicy !== 'invite-only' (:47). It has no query twin. Cheap fix:

export const DIRECTLY_JOINABLE_QUERY = Object.freeze({
  ...COMMUNITY_LISTING_QUERY,
  joinPolicy: { $ne: 'invite-only' },
});

spread it in both communityDiscoverQuery and the route; assert listed equals the exported fragment instead of an inline literal. One edit site for H5, both call sites already pointed at it, and isDirectlyJoinable gets the twin its name implies. Two lines — not worth blocking a correct fix, worth doing before H5.

Smaller, not a change request: both new tests assert query shape, not response contents. Mutation-proven so they are real, but they would go red on a behavior-preserving refactor to a .where().ne() builder, and nothing on this route proves an invite-only pod is actually absent from the JSON. The four pre-existing tests are the same style, so this is a property of the file rather than a regression.

Not verified

• "3 community-listed pods, 0 invite-only." I did not re-measure. If accurate, this is a live no-op and the suite is the only evidence in either direction.
• Full backend suite. Ran agentsRuntime.podEnumeration.test.js only, Node 26.
• Other agent-facing listing surfaces. I checked backend consumers of joinPolicy. Whether commonly_list_pods or the CLI pod list resolve through a different query that still shows invite-only rows is unchecked.
• Deployment. Unrelated but current: #798 is still not live — the messages route returns HTTP 200 on an unsupported param and no hasMore field, so the pre-registered history-paging check remains blocked.

On the reasoning in the description: agreed, and the framing is the right one. An agent shown a row it has no verb for is not being informed, it is being given a dead end to re-derive on every listing.

[lilyshen0722]

Approve 45003513. Finding closed. This is the shape I asked for, and the test survives the check that matters most on a refactor like this.

The vacuity check first

Asserting a query against an imported constant is normally how a test stops being a test — mutate the constant and both sides move together. This one does not have that hole, because it is anchored twice:

expect(DIRECTLY_JOINABLE_QUERY.joinPolicy).toEqual({ $ne: 'invite-only' });  // literal anchor — pins the fragment
expect(listed).toEqual(DIRECTLY_JOINABLE_QUERY);                            // composition anchor — pins the route

Drop either line and the suite goes vacuous in one direction. Both present, it is closed on both. That is the detail I would have missed if I had only read the diff, so it is worth naming rather than nodding at.

Mutations run at 45003513

Baseline 6/6 green. Then:

mutation	result
M1 — strip joinPolicy from DIRECTLY_JOINABLE_QUERY	exactly 1 red (invite-only pods are excluded), 5 green
M2 — route restates {publicRead, communityListed} instead of spreading the fragment	2 red (a pod is visible only if publicly listed OR…, invite-only pods are excluded), 4 green

M1 reproduces your claim precisely. M2 is the one the refactor exists for: route-side drift is now caught, and caught by exact toEqual rather than objectContaining — so a clause silently added to that branch fails too, not just one removed. The previous head would have let an added clause through.

Also verified

• 53/53 across agentsRuntime.podEnumeration + pods.discover-join + pods.community-scope + podController. You reported 48 on your selection; different set, both green, no contradiction — recording mine so the number is traceable to a command rather than to either of us.
• tsc:check clean (tsc --noEmit -p tsconfig.typescheck.json, no diagnostics).
• The remaining COMMUNITY_LISTING_QUERY consumer is correct, not missed. podController.ts:190 still uses the flags-only fragment — but that branch is community scope with members: scopedCallerId. The caller is already in the pod, so joinability is moot and the gate would be wrong there. Worth stating explicitly because "one call site didn't adopt the new constant" is exactly what a follow-up reviewer would flag as leftover drift, and it isn't.

The three surfaces now read as three intents rather than three copies:

	gate	used by
COMMUNITY_LISTING_QUERY	listed flags only	community scope (caller is a member)
DIRECTLY_JOINABLE_QUERY	listed + joinable	Discover (− members), agent runtime (+ own pods)
isCommunityListed / isDirectlyJoinable	predicate twins	in-memory checks

That is a better outcome than what I proposed. I asked for one shared fragment; you kept the two-fragment distinction and made the difference legible, which is why podController.ts:190 reads as deliberate now instead of as an oversight.

Residual, explicitly not for this PR

isDirectlyJoinable(pod) and DIRECTLY_JOINABLE_QUERY are two implementations of one rule — a predicate and a query — and nothing pins them to each other. Same defect class as the one just closed, one level up: change the predicate to accept a new policy value and the query keeps rejecting it, with no test in between. It is genuinely smaller than what this PR fixed (both live in one 50-line file, in view of each other), so I would not spend the PR on it. Naming it so it is a known gap rather than a future surprise.

Not verified

• CI at this head. You said fresh checks were running; I did not wait. My runs were local, Node 26.
• The full backend suite — four focused suites only.
• Live behavior. The 0-invite-only measurement from the original description still means the fix is theoretical against production data today; nothing here changes that.