Migrate room.join / room.invite onto capability-request / capability-grant-ok

[Mearman]

Once the generic primitive exists, core/room's own verbs (spec/room.cddl:126-155) become a thin instance of capability-request/capability-grant-ok rather than a parallel hand-built copy of the same flow -- no dual implementation kept around, per the standing no-legacy-shims convention.

Design pass completed (2026-09-14) -- concrete plan below, corrected against the real current code rather than assumed from earlier issue summaries (several "already done" claims turned out to be wire-shape-only; see corrections).

The outer manage-command.verb question -- resolved, not a fork

capability-request/capability-grant (see #117) MUST be sent with the outer manage-command.verb set to the target capability (e.g. "room:member"), identical to every other domain. This is forced by capability-verb's own grammar (tokens.cddl: closed alternation of colon-delimited domain:noun regexes) -- "capability.request" (a dot) cannot legally be an outer verb. Not a stylistic choice.

room.invite -- resolved via a real capability-grant primitive (#117), not left bespoke

Tracked as its own issue (#117) since it's a genuinely separate wire primitive, not part of this migration's own diff.

Concrete migration plan for room.join

CDDL (spec/room.cddl): retire room-join/room-invite; rename room-join-ok to room-join-grant-ok, riding capability-grant-ok's own open tail rather than a free-standing rule (documentation/codegen convenience -- response bytes are unchanged).

Wire impact: request side is a breaking change (old {verb:"room:member", params:{verb:"room.join"}} bytes no longer dispatch); response side is byte-identical. No documented wire back-compat policy exists in this pre-1.0, rapidly-iterating spec -- accept the break, no shim, matching how #58/#63/#64 already broke and regenerated room's wire shape.

TypeScript: new ts/packages/core/src/domain/capability-request.ts (see #78) is the real prerequisite -- this issue is blocked on #78's domain-logic half landing, not just its CDDL. Once it exists:

• room-client.ts's requestToJoin becomes a thin wrapper over requestCapability; its public signature and RoomJoinResult type stay unchanged, so callers above it (RoomPanel.tsx, use-room-messaging.ts, App.tsx) need no changes.
• createRoomRouter's "room.join" dispatch branch delegates to the new generic handler with capability: ROOM_MEMBER_CAPABILITY; handleRoomJoin's existing body (bearer check, mintCapabilityToken, members list) becomes the decide callback almost verbatim.
• Add handleRoomInvite/sendRoomInvite (net new -- wire-mesh itself has zero room.invite implementation today, confirmed by grep) built on Add capability-grant primitive (unsolicited push-grant counterpart to capability-request) #117's capability-grant.

canSatisfy -- confirmed still correctly deferred, confirmed not needed for this migration

Doesn't exist yet, gated behind #85 (generic predicate-list evaluator). Not needed here: room-join admission is either a human decision or the DM auto-approve check, neither of which is "would a held token satisfy this ask" -- and room-join grants are always root-level (no parent), so canGrant isn't load-bearing on the approval path either. Becomes relevant only if a future domain wants capability-request auto-approved based on the approver already holding a broader delegation -- a separate use case.

Two-repo follow-up (agent-comms, scope only -- not this issue's own work)

src/core/room-lifecycle.ts (joinRemoteRoom, the DM-flow join send, inviteToRoom) and src/core/room-protocol.ts (handleRoomJoin/admitRoomJoin/handleRoomInvite, registered by literal string in room-router.ts) would all need rewiring onto the new wire-mesh-core primitives once this lands. Concretely closes a real, currently-inconsistent gap: agent-comms' connect_request already has receiver-side expiry (its own PR #84) but pendingRoomJoins does not (confirmed: bare Promise, no timer) -- adopting the new generic handler unifies both admission gates onto one mechanism. Tracked as its own follow-up issue in agent-comms once #78/#83/#117 land in wire-mesh.

Verification plan

• just spec && just conformance -- new/changed vectors: replace room-join vectors with capability-request vectors targeting room:member; add a capability-grant vector (covering retired room-invite); add an expired-capability-request vector exercising Add optional valid-until to capability-request params #82's obligation.
• cargo test -p wire-mesh-wire -- verify (not assume) no new Rust structs are needed, per the precedent that the six room verbs already ride manage-request-frame's untyped params/response catch-all.
• New ts/packages/core/test/capability-request.test.ts (mirrors room-token-verification.test.ts): ungated ask, valid-until expiry refusal, receiver-side timeout auto-reject, generic grant/deny round trip.
• room-client.test.ts currently has zero invite coverage -- add real coverage as part of this migration, not just parity.
• just build && just test && just lint.

Blocked by: #78 (domain-logic half), #81 (receiver-side timeout, reopened -- generic mechanism doesn't exist in wire-mesh yet), #82 (valid-until, closed at the wire level, needs the handler from #78 to actually check it), #117 (capability-grant, for the room.invite half).

[Mearman]

Investigated directly against both repos before implementing. This is not a mechanical rename -- two real design questions need a decision before any code moves, the same "needs its own design pass" shape as relay-hub's own #102.

1. The outer manage-command.verb convention is undefined for capability-request. room-join today rides as manage-command.params under an outer verb set to the capability being asked about ("room:member"), not a verb of its own -- an established but implicit convention. capability-request's own doc comment addresses the scope field (correctly omitted, matching room-join) but says nothing about the outer verb. Migrating needs an explicit decision: does capability-request also reuse the target capability as the outer verb, or does it get its own dedicated capability-verb (e.g. "capability:request")?

2. room.invite does not fit capability-request/capability-grant-ok at all -- a genuine structural mismatch, not a naming difference. capability-request is requester-initiated (an ask, held open, granted on the response). room.invite is owner-initiated and unsolicited, with the grant riding the request itself, not a response -- there is no round-trip to generalize onto capability-grant-ok. Either room-invite stays a bespoke room-specific verb, or a second generic "unsolicited grant push" primitive would need designing from scratch (out of scope for what #78/#82 actually built).

A third, smaller wrinkle: capability-grant-ok has no members field room-join-ok's own response needs -- solvable via the existing open extension tail (* tstr => any), but it does mean losing the generated schema's strong RoomMember[] typing for that field in both TS consumers, worth deciding deliberately rather than discovering as a side effect.

Also confirmed: agent-comms independently duplicates this entire flow (src/core/mesh-store.ts's own room.join/invite handling, wire construction, and granted-token/members destructuring) -- both repos would need to migrate together, or a mixed-version mesh breaks interop. Not a blocker on the design question, but real scope: this was never a wire-mesh-only change.

Recommend resolving the two design questions first (as a design-pass issue, not inline here), then -- once decided -- the mechanical migration stacks as (a) wire-mesh spec + core regen + conformance, (b) web-console room-client.ts + tests, (c) agent-comms mesh-store.ts + tests, with wire-mesh's (a)+(b) merged before agent-comms' (c) starts.

[Mearman]

room.join half: done via PR #120. requestToJoin (ts/packages/web-console/src/room-client.ts) is now a thin wrapper over requestCapability; createRoomRouter's incoming-join handling delegates to the generic createCapabilityRequestHandler. Public RoomJoinResult/RoomJoinDecision/RoomJoinRequestEvent shapes unchanged, so no caller above room-client.ts needed changes. room-join retired from room.cddl, wire request-side is now the generic capability-request shape targeting room:member; response side (room-join-grant-ok) unchanged.

Remaining scope: room.invite, blocked on #117 (capability-grant primitive, the unsolicited-push counterpart) landing first. Sub-issue of #77, not yet built.

[Mearman]

Both halves complete. room.join migrated onto capability-request (PR #120); room.invite migrated onto the new capability-grant primitive (#117, PR #122) -- wire-mesh's own reference client (room-client.ts) now implements room.invite for the first time (it only ever had room.join before). Both retired from room.cddl as bespoke verbs; both now thin instances of the generic core/management primitives. No dual implementation kept around, per the standing no-legacy-shims convention this issue itself named.