wire-mesh-core 1.14.0 → 1.16.0

package/dist/adapters/frame-codec.d.cts

@@ -1,4 +1,4 @@
-import { E as Frame } from "../protocol-MnxTzpRP.cjs";
+import { D as Frame } from "../protocol-Dhswk7YD.cjs";
 //#region src/adapters/frame-codec.d.ts
 export declare function messageFromFrame(frame: Frame): Uint8Array<ArrayBuffer>;
 /** A frame that fails schema validation, caught separately from a decode failure so it can be dropped without disconnecting. */

package/dist/adapters/frame-codec.d.mts

@@ -1,4 +1,4 @@
-import { E as Frame } from "../protocol-MnxTzpRP.mjs";
+import { D as Frame } from "../protocol-Dhswk7YD.mjs";
 //#region src/adapters/frame-codec.d.ts
 export declare function messageFromFrame(frame: Frame): Uint8Array<ArrayBuffer>;
 /** A frame that fails schema validation, caught separately from a decode failure so it can be dropped without disconnecting. */

package/dist/adapters/node-identity.d.cts

@@ -1,5 +1,5 @@
-import { N as IdentityKey, b as DeviceId } from "../protocol-MnxTzpRP.cjs";
-import { t as IdentityPort } from "../identity-DkEe1465.cjs";
+import { P as IdentityKey, x as DeviceId } from "../protocol-Dhswk7YD.cjs";
+import { t as IdentityPort } from "../identity-BldV8xFj.cjs";
 import { webcrypto } from "node:crypto";
 //#region src/adapters/node-identity.d.ts
 export declare function deriveDeviceId(publicKey: Uint8Array): Promise<DeviceId>;

package/dist/adapters/node-identity.d.mts

@@ -1,5 +1,5 @@
-import { N as IdentityKey, b as DeviceId } from "../protocol-MnxTzpRP.mjs";
-import { t as IdentityPort } from "../identity-D8iJZRZZ.mjs";
+import { P as IdentityKey, x as DeviceId } from "../protocol-Dhswk7YD.mjs";
+import { t as IdentityPort } from "../identity-B1hBV3YA.mjs";
 import { webcrypto } from "node:crypto";
 //#region src/adapters/node-identity.d.ts
 export declare function deriveDeviceId(publicKey: Uint8Array): Promise<DeviceId>;

package/dist/adapters/tcp-transport.d.cts

@@ -1,4 +1,4 @@
-import { Transport } from "../ports/transport.cjs";
+import { r as Transport } from "../transport-hEUxrdhT.cjs";
 //#region src/adapters/tcp-transport.d.ts
 /** A Node net.Socket-based Transport: length-prefixed, CBOR-encoded frames over plain TCP -- matching Cascade's own transport shape, since interop with Cascade nodes is wire-mesh's stated goal. Framing (not TLS) is this adapter's own concern; a TLS-terminated variant is a separate adapter behind the same Transport contract. */
 export declare function createTcpTransport(): Transport;

package/dist/adapters/tcp-transport.d.mts

@@ -1,4 +1,4 @@
-import { Transport } from "../ports/transport.mjs";
+import { r as Transport } from "../transport-BNNdUBq-.mjs";
 //#region src/adapters/tcp-transport.d.ts
 /** A Node net.Socket-based Transport: length-prefixed, CBOR-encoded frames over plain TCP -- matching Cascade's own transport shape, since interop with Cascade nodes is wire-mesh's stated goal. Framing (not TLS) is this adapter's own concern; a TLS-terminated variant is a separate adapter behind the same Transport contract. */
 export declare function createTcpTransport(): Transport;

package/dist/adapters/tls-transport.d.cts

@@ -1,4 +1,4 @@
-import { Transport } from "../ports/transport.cjs";
+import { r as Transport } from "../transport-hEUxrdhT.cjs";
 //#region src/adapters/tls-transport.d.ts
 export interface TlsIdentity {
   certificatePem: string;

package/dist/adapters/tls-transport.d.mts

@@ -1,4 +1,4 @@
-import { Transport } from "../ports/transport.mjs";
+import { r as Transport } from "../transport-BNNdUBq-.mjs";
 //#region src/adapters/tls-transport.d.ts
 export interface TlsIdentity {
   certificatePem: string;

package/dist/domain/capability-grant.cjs

@@ -0,0 +1,90 @@
+Object.defineProperty(exports, Symbol.toStringTag, { value: "Module" });
+const require_generated_protocol = require("../generated/protocol.cjs");
+const require_domain_tokens = require("./tokens.cjs");
+//#region src/domain/capability-grant.ts
+/**
+* The generic, capability-agnostic capability-grant primitive (wire-mesh#117, spec/management.cddl) -- the unsolicited push counterpart to capability-request.ts's own ask/response primitive. Where capability-request lifts core/room's room.join shape (a pull: the requester asks, the owner mints and returns a grant on the same response) out of that one domain, capability-grant lifts room.invite's own shape (a push: the owner mints unprompted and delivers the grant in the request itself, since there is no approval round-trip to carry it back) the same way. core/room's own room-client.ts is the reference consumer: it builds sendRoomInvite as a thin wrapper over sendCapabilityGrant below, and wires createRoomRouter's dispatch onto createCapabilityGrantHandler for the receiving side.
+*
+* Two responsibilities, split the same way capability-request.ts already splits them: sendCapabilityGrant is the pushing side (a thin wrapper over MeshSession.sendManageRequest), and createCapabilityGrantHandler is the receiving side (validates the pushed token against all four of management.cddl's own capability-grant obligations, then hands the verified grant to the domain). Unlike capability-request's handler, there is no decide()/timeout mechanism here: management.cddl deliberately specifies no protocol-level approval round trip for this primitive (a receiver's manage-response reports validation success or failure only, never a human decision), so onGrant is a plain notification callback, not an event carrying its own responder.
+*/
+/**
+* Builds a capability-grant command per management.cddl. The outer `manage-command.verb` is the capability string itself, the identical convention capability-request.ts's own buildCapabilityRequestCommand already establishes -- a receiver's per-capability handler is how it knows which grant this push is even for. `params.verb` is the fixed "capability.grant" marker. No scope or invitee field: manage-request-frame's own top-level scope already carries the former, and the request's own destination already carries the latter -- naming either a second time inside params could only ever disagree with the fact it duplicates.
+*/
+function buildCapabilityGrantCommand(capability, grantedToken) {
+	return {
+		verb: capability,
+		params: {
+			verb: "capability.grant",
+			"granted-token": grantedToken
+		}
+	};
+}
+/**
+* Pushes an already-minted grantedToken to whichever peer this request is addressed to -- the caller mints grantedToken itself beforehand (there is no minting step here, unlike capability-request's own accept path, since this primitive carries a token the sender already decided to hand over unprompted). Resolves with the raw manage-response outcome: `{result:"ok"}` on successful validation, an ordinary manage-error otherwise (per management.cddl's own capability-grant obligations, this is a validation-failure code only, never a human "no" -- an application wanting a human-decision gate applies it on the RECEIVING side's own onGrant callback instead, exactly as core/room's own room.invite→room_invite delivery event already does today in agent-comms).
+*
+* scope and targetDevice forward directly to MeshSession.sendManageRequest's own identically-named parameters (the request's own top-level scope obligation 4 checks the token against, and relay routing respectively).
+*/
+async function sendCapabilityGrant(session, capability, grantedToken, scope, targetDevice) {
+	return session.sendManageRequest(buildCapabilityGrantCommand(capability, grantedToken), scope, targetDevice);
+}
+/**
+* Builds a reusable handler for one capability's incoming capability-grants. The returned function checks, in order: the outer verb names this handler's own capability (otherwise `{result:"error", code:"malformed"}`, matching capability-request.ts's identical check); the params payload parses against capability-grant's own CDDL shape (otherwise "malformed"); the embedded token independently passes every ordinary verifyCapabilityToken obligation with `expectedBearer` set to this receiver's OWN identity -- obligations 1 and 3 together, since an unsolicited push must name its actual recipient as bearer and must otherwise be exactly as valid as any other token (a verification failure responds with verifyCapabilityToken's own specific TokenVerdictReason as the error code, e.g. "expired"/"revoked"/"bad_signature", rather than a single generic code, mirroring how capability-request.ts already distinguishes "expired" from "malformed"); the token's own capability claim equals this handler's capability (obligation 2, otherwise "capability_mismatch"); and the token's own scope equals or roots the enclosing request's own top-level scope (obligation 4, via tokens.ts's own scopeNarrows -- otherwise "scope_mismatch"). Only once every obligation passes does it respond `{result:"ok"}` and invoke onGrant -- there is no decide()/timeout mechanism the way createCapabilityRequestHandler has one, since management.cddl specifies no protocol-level approval round trip for this primitive at all.
+*/
+function createCapabilityGrantHandler(options) {
+	return async function handleCapabilityGrant(incoming) {
+		if (incoming.command.verb !== options.capability) {
+			await incoming.respond({
+				result: "error",
+				code: "malformed"
+			});
+			return;
+		}
+		const parsed = require_generated_protocol.capabilityGrantSchema.safeParse(incoming.command.params);
+		if (!parsed.success) {
+			await incoming.respond({
+				result: "error",
+				code: "malformed"
+			});
+			return;
+		}
+		const grantedToken = parsed.data["granted-token"];
+		const verdict = await require_domain_tokens.verifyCapabilityToken(grantedToken, {
+			identity: options.identity,
+			clock: options.clock,
+			revocation: options.revocation,
+			expectedBearer: options.identity.deviceId
+		});
+		if (!verdict.ok) {
+			await incoming.respond({
+				result: "error",
+				code: verdict.reason
+			});
+			return;
+		}
+		if (verdict.claims.capability !== options.capability) {
+			await incoming.respond({
+				result: "error",
+				code: "capability_mismatch"
+			});
+			return;
+		}
+		if (!require_domain_tokens.scopeNarrows(verdict.claims.scope, incoming.scope)) {
+			await incoming.respond({
+				result: "error",
+				code: "scope_mismatch"
+			});
+			return;
+		}
+		await incoming.respond({ result: "ok" });
+		options.onGrant({
+			capability: options.capability,
+			grantedToken,
+			scope: incoming.scope,
+			granterDevice: options.granterDevice
+		});
+	};
+}
+//#endregion
+exports.buildCapabilityGrantCommand = buildCapabilityGrantCommand;
+exports.createCapabilityGrantHandler = createCapabilityGrantHandler;
+exports.sendCapabilityGrant = sendCapabilityGrant;

package/dist/domain/capability-grant.d.cts

@@ -0,0 +1,44 @@
+import { F as ManageCommand, o as CapabilityScope, s as CapabilityToken, x as DeviceId } from "../protocol-Dhswk7YD.cjs";
+import { t as IdentityPort } from "../identity-BldV8xFj.cjs";
+import { t as Clock } from "../clock-DiSx-WKM.cjs";
+import { IncomingManageRequest, ManageOutcome, MeshSession } from "./mesh-session.cjs";
+import { RevocationCheck } from "./tokens.cjs";
+//#region src/domain/capability-grant.d.ts
+/**
+ * Builds a capability-grant command per management.cddl. The outer `manage-command.verb` is the capability string itself, the identical convention capability-request.ts's own buildCapabilityRequestCommand already establishes -- a receiver's per-capability handler is how it knows which grant this push is even for. `params.verb` is the fixed "capability.grant" marker. No scope or invitee field: manage-request-frame's own top-level scope already carries the former, and the request's own destination already carries the latter -- naming either a second time inside params could only ever disagree with the fact it duplicates.
+ */
+export declare function buildCapabilityGrantCommand(capability: string, grantedToken: CapabilityToken): ManageCommand;
+/**
+ * Pushes an already-minted grantedToken to whichever peer this request is addressed to -- the caller mints grantedToken itself beforehand (there is no minting step here, unlike capability-request's own accept path, since this primitive carries a token the sender already decided to hand over unprompted). Resolves with the raw manage-response outcome: `{result:"ok"}` on successful validation, an ordinary manage-error otherwise (per management.cddl's own capability-grant obligations, this is a validation-failure code only, never a human "no" -- an application wanting a human-decision gate applies it on the RECEIVING side's own onGrant callback instead, exactly as core/room's own room.invite→room_invite delivery event already does today in agent-comms).
+ *
+ * scope and targetDevice forward directly to MeshSession.sendManageRequest's own identically-named parameters (the request's own top-level scope obligation 4 checks the token against, and relay routing respectively).
+ */
+export declare function sendCapabilityGrant(session: Readonly<MeshSession>, capability: string, grantedToken: CapabilityToken, scope: Readonly<CapabilityScope>, targetDevice?: DeviceId): Promise<ManageOutcome>;
+/** One incoming, fully-verified capability-grant, surfaced for the domain to react to (store the token, notify a human, etc.) -- there is no decide() here because management.cddl specifies no protocol-level approval round trip for this primitive; by the time onGrant fires, the wire response has already been sent. */
+export interface CapabilityGrantEvent {
+  /** The capability granted -- equals both the outer manage-command.verb and the verified token's own capability claim (obligation 2 already enforced this before onGrant fires). */
+  capability: string;
+  /** The pushed token, already confirmed to independently pass every ordinary verifyCapabilityToken obligation, name this receiver as its own bearer, and scope-match the enclosing request (obligations 1, 2, 3, and 4 respectively). Ready to use exactly as capability-request.ts's own CapabilityGrantOk["granted-token"] is on the pull side. */
+  grantedToken: CapabilityToken;
+  /** The scope this grant's own manage-request-frame carried -- e.g. core/room's `{kind:"room", path: roomPath}` -- passed through unchanged so the domain can inspect it (a room handler reads `.path` back out) without this module needing to know its shape. */
+  scope: Readonly<CapabilityScope>;
+  /** The peer device-id authenticated on the connection this grant arrived on -- the granter, surfaced so the domain can attribute the push (e.g. core/room's own room_invite event names the inviter). Never itself checked against the token's bearer (obligation 1 checks the RECIPIENT's own identity instead -- an unsolicited push names its own recipient by where it was sent, not by who sent it). */
+  granterDevice: DeviceId;
+}
+export interface CreateCapabilityGrantHandlerOptions {
+  /** The capability this handler accepts pushed grants for. Checked against the incoming command's own outer verb (a mismatch is refused as malformed, mirroring capability-request.ts's identical capability check) and against the verified token's own capability claim (obligation 2); a caller wanting to accept grants for several distinct capabilities over one session constructs one handler per capability, the same way core/room constructs one handler for `room:member` and nothing else. */
+  capability: string;
+  /** This receiver's own identity -- both the verification primitives every pushed token is checked with, and (via `.deviceId`) the value obligation 1 requires the token's own bearer to equal. There is no separate bearerDevice option the way CreateCapabilityRequestHandlerOptions has one: capability-request's handler mints a NEW token for whichever peer asked, so it needs that peer's device-id as an input; capability-grant's handler verifies an ALREADY-minted token against this side's own identity, which identity.deviceId already provides. */
+  identity: IdentityPort;
+  clock: Clock;
+  revocation: RevocationCheck;
+  /** The peer device-id authenticated on this session's own connection -- the granter, surfaced on every CapabilityGrantEvent so the domain can attribute the push. Never used for verification itself (see CapabilityGrantEvent.granterDevice's own doc comment on why obligation 1 checks the recipient's identity instead). */
+  granterDevice: DeviceId;
+  /** Called once per incoming, fully-verified capability-grant. Fires after the wire response has already been sent (see createCapabilityGrantHandler's own doc comment) -- this is a notification, not a decision point. */
+  onGrant: (event: Readonly<CapabilityGrantEvent>) => void;
+}
+/**
+ * Builds a reusable handler for one capability's incoming capability-grants. The returned function checks, in order: the outer verb names this handler's own capability (otherwise `{result:"error", code:"malformed"}`, matching capability-request.ts's identical check); the params payload parses against capability-grant's own CDDL shape (otherwise "malformed"); the embedded token independently passes every ordinary verifyCapabilityToken obligation with `expectedBearer` set to this receiver's OWN identity -- obligations 1 and 3 together, since an unsolicited push must name its actual recipient as bearer and must otherwise be exactly as valid as any other token (a verification failure responds with verifyCapabilityToken's own specific TokenVerdictReason as the error code, e.g. "expired"/"revoked"/"bad_signature", rather than a single generic code, mirroring how capability-request.ts already distinguishes "expired" from "malformed"); the token's own capability claim equals this handler's capability (obligation 2, otherwise "capability_mismatch"); and the token's own scope equals or roots the enclosing request's own top-level scope (obligation 4, via tokens.ts's own scopeNarrows -- otherwise "scope_mismatch"). Only once every obligation passes does it respond `{result:"ok"}` and invoke onGrant -- there is no decide()/timeout mechanism the way createCapabilityRequestHandler has one, since management.cddl specifies no protocol-level approval round trip for this primitive at all.
+ */
+export declare function createCapabilityGrantHandler(options: Readonly<CreateCapabilityGrantHandlerOptions>): (incoming: Readonly<IncomingManageRequest>) => Promise<void>;
+//#endregion

package/dist/domain/capability-grant.d.mts

@@ -0,0 +1,44 @@
+import { F as ManageCommand, o as CapabilityScope, s as CapabilityToken, x as DeviceId } from "../protocol-Dhswk7YD.mjs";
+import { t as IdentityPort } from "../identity-B1hBV3YA.mjs";
+import { t as Clock } from "../clock-DiSx-WKM.mjs";
+import { IncomingManageRequest, ManageOutcome, MeshSession } from "./mesh-session.mjs";
+import { RevocationCheck } from "./tokens.mjs";
+//#region src/domain/capability-grant.d.ts
+/**
+ * Builds a capability-grant command per management.cddl. The outer `manage-command.verb` is the capability string itself, the identical convention capability-request.ts's own buildCapabilityRequestCommand already establishes -- a receiver's per-capability handler is how it knows which grant this push is even for. `params.verb` is the fixed "capability.grant" marker. No scope or invitee field: manage-request-frame's own top-level scope already carries the former, and the request's own destination already carries the latter -- naming either a second time inside params could only ever disagree with the fact it duplicates.
+ */
+export declare function buildCapabilityGrantCommand(capability: string, grantedToken: CapabilityToken): ManageCommand;
+/**
+ * Pushes an already-minted grantedToken to whichever peer this request is addressed to -- the caller mints grantedToken itself beforehand (there is no minting step here, unlike capability-request's own accept path, since this primitive carries a token the sender already decided to hand over unprompted). Resolves with the raw manage-response outcome: `{result:"ok"}` on successful validation, an ordinary manage-error otherwise (per management.cddl's own capability-grant obligations, this is a validation-failure code only, never a human "no" -- an application wanting a human-decision gate applies it on the RECEIVING side's own onGrant callback instead, exactly as core/room's own room.invite→room_invite delivery event already does today in agent-comms).
+ *
+ * scope and targetDevice forward directly to MeshSession.sendManageRequest's own identically-named parameters (the request's own top-level scope obligation 4 checks the token against, and relay routing respectively).
+ */
+export declare function sendCapabilityGrant(session: Readonly<MeshSession>, capability: string, grantedToken: CapabilityToken, scope: Readonly<CapabilityScope>, targetDevice?: DeviceId): Promise<ManageOutcome>;
+/** One incoming, fully-verified capability-grant, surfaced for the domain to react to (store the token, notify a human, etc.) -- there is no decide() here because management.cddl specifies no protocol-level approval round trip for this primitive; by the time onGrant fires, the wire response has already been sent. */
+export interface CapabilityGrantEvent {
+  /** The capability granted -- equals both the outer manage-command.verb and the verified token's own capability claim (obligation 2 already enforced this before onGrant fires). */
+  capability: string;
+  /** The pushed token, already confirmed to independently pass every ordinary verifyCapabilityToken obligation, name this receiver as its own bearer, and scope-match the enclosing request (obligations 1, 2, 3, and 4 respectively). Ready to use exactly as capability-request.ts's own CapabilityGrantOk["granted-token"] is on the pull side. */
+  grantedToken: CapabilityToken;
+  /** The scope this grant's own manage-request-frame carried -- e.g. core/room's `{kind:"room", path: roomPath}` -- passed through unchanged so the domain can inspect it (a room handler reads `.path` back out) without this module needing to know its shape. */
+  scope: Readonly<CapabilityScope>;
+  /** The peer device-id authenticated on the connection this grant arrived on -- the granter, surfaced so the domain can attribute the push (e.g. core/room's own room_invite event names the inviter). Never itself checked against the token's bearer (obligation 1 checks the RECIPIENT's own identity instead -- an unsolicited push names its own recipient by where it was sent, not by who sent it). */
+  granterDevice: DeviceId;
+}
+export interface CreateCapabilityGrantHandlerOptions {
+  /** The capability this handler accepts pushed grants for. Checked against the incoming command's own outer verb (a mismatch is refused as malformed, mirroring capability-request.ts's identical capability check) and against the verified token's own capability claim (obligation 2); a caller wanting to accept grants for several distinct capabilities over one session constructs one handler per capability, the same way core/room constructs one handler for `room:member` and nothing else. */
+  capability: string;
+  /** This receiver's own identity -- both the verification primitives every pushed token is checked with, and (via `.deviceId`) the value obligation 1 requires the token's own bearer to equal. There is no separate bearerDevice option the way CreateCapabilityRequestHandlerOptions has one: capability-request's handler mints a NEW token for whichever peer asked, so it needs that peer's device-id as an input; capability-grant's handler verifies an ALREADY-minted token against this side's own identity, which identity.deviceId already provides. */
+  identity: IdentityPort;
+  clock: Clock;
+  revocation: RevocationCheck;
+  /** The peer device-id authenticated on this session's own connection -- the granter, surfaced on every CapabilityGrantEvent so the domain can attribute the push. Never used for verification itself (see CapabilityGrantEvent.granterDevice's own doc comment on why obligation 1 checks the recipient's identity instead). */
+  granterDevice: DeviceId;
+  /** Called once per incoming, fully-verified capability-grant. Fires after the wire response has already been sent (see createCapabilityGrantHandler's own doc comment) -- this is a notification, not a decision point. */
+  onGrant: (event: Readonly<CapabilityGrantEvent>) => void;
+}
+/**
+ * Builds a reusable handler for one capability's incoming capability-grants. The returned function checks, in order: the outer verb names this handler's own capability (otherwise `{result:"error", code:"malformed"}`, matching capability-request.ts's identical check); the params payload parses against capability-grant's own CDDL shape (otherwise "malformed"); the embedded token independently passes every ordinary verifyCapabilityToken obligation with `expectedBearer` set to this receiver's OWN identity -- obligations 1 and 3 together, since an unsolicited push must name its actual recipient as bearer and must otherwise be exactly as valid as any other token (a verification failure responds with verifyCapabilityToken's own specific TokenVerdictReason as the error code, e.g. "expired"/"revoked"/"bad_signature", rather than a single generic code, mirroring how capability-request.ts already distinguishes "expired" from "malformed"); the token's own capability claim equals this handler's capability (obligation 2, otherwise "capability_mismatch"); and the token's own scope equals or roots the enclosing request's own top-level scope (obligation 4, via tokens.ts's own scopeNarrows -- otherwise "scope_mismatch"). Only once every obligation passes does it respond `{result:"ok"}` and invoke onGrant -- there is no decide()/timeout mechanism the way createCapabilityRequestHandler has one, since management.cddl specifies no protocol-level approval round trip for this primitive at all.
+ */
+export declare function createCapabilityGrantHandler(options: Readonly<CreateCapabilityGrantHandlerOptions>): (incoming: Readonly<IncomingManageRequest>) => Promise<void>;
+//#endregion

package/dist/domain/capability-grant.mjs

@@ -0,0 +1,87 @@
+import { capabilityGrantSchema } from "../generated/protocol.mjs";
+import { scopeNarrows, verifyCapabilityToken } from "./tokens.mjs";
+//#region src/domain/capability-grant.ts
+/**
+* The generic, capability-agnostic capability-grant primitive (wire-mesh#117, spec/management.cddl) -- the unsolicited push counterpart to capability-request.ts's own ask/response primitive. Where capability-request lifts core/room's room.join shape (a pull: the requester asks, the owner mints and returns a grant on the same response) out of that one domain, capability-grant lifts room.invite's own shape (a push: the owner mints unprompted and delivers the grant in the request itself, since there is no approval round-trip to carry it back) the same way. core/room's own room-client.ts is the reference consumer: it builds sendRoomInvite as a thin wrapper over sendCapabilityGrant below, and wires createRoomRouter's dispatch onto createCapabilityGrantHandler for the receiving side.
+*
+* Two responsibilities, split the same way capability-request.ts already splits them: sendCapabilityGrant is the pushing side (a thin wrapper over MeshSession.sendManageRequest), and createCapabilityGrantHandler is the receiving side (validates the pushed token against all four of management.cddl's own capability-grant obligations, then hands the verified grant to the domain). Unlike capability-request's handler, there is no decide()/timeout mechanism here: management.cddl deliberately specifies no protocol-level approval round trip for this primitive (a receiver's manage-response reports validation success or failure only, never a human decision), so onGrant is a plain notification callback, not an event carrying its own responder.
+*/
+/**
+* Builds a capability-grant command per management.cddl. The outer `manage-command.verb` is the capability string itself, the identical convention capability-request.ts's own buildCapabilityRequestCommand already establishes -- a receiver's per-capability handler is how it knows which grant this push is even for. `params.verb` is the fixed "capability.grant" marker. No scope or invitee field: manage-request-frame's own top-level scope already carries the former, and the request's own destination already carries the latter -- naming either a second time inside params could only ever disagree with the fact it duplicates.
+*/
+function buildCapabilityGrantCommand(capability, grantedToken) {
+	return {
+		verb: capability,
+		params: {
+			verb: "capability.grant",
+			"granted-token": grantedToken
+		}
+	};
+}
+/**
+* Pushes an already-minted grantedToken to whichever peer this request is addressed to -- the caller mints grantedToken itself beforehand (there is no minting step here, unlike capability-request's own accept path, since this primitive carries a token the sender already decided to hand over unprompted). Resolves with the raw manage-response outcome: `{result:"ok"}` on successful validation, an ordinary manage-error otherwise (per management.cddl's own capability-grant obligations, this is a validation-failure code only, never a human "no" -- an application wanting a human-decision gate applies it on the RECEIVING side's own onGrant callback instead, exactly as core/room's own room.invite→room_invite delivery event already does today in agent-comms).
+*
+* scope and targetDevice forward directly to MeshSession.sendManageRequest's own identically-named parameters (the request's own top-level scope obligation 4 checks the token against, and relay routing respectively).
+*/
+async function sendCapabilityGrant(session, capability, grantedToken, scope, targetDevice) {
+	return session.sendManageRequest(buildCapabilityGrantCommand(capability, grantedToken), scope, targetDevice);
+}
+/**
+* Builds a reusable handler for one capability's incoming capability-grants. The returned function checks, in order: the outer verb names this handler's own capability (otherwise `{result:"error", code:"malformed"}`, matching capability-request.ts's identical check); the params payload parses against capability-grant's own CDDL shape (otherwise "malformed"); the embedded token independently passes every ordinary verifyCapabilityToken obligation with `expectedBearer` set to this receiver's OWN identity -- obligations 1 and 3 together, since an unsolicited push must name its actual recipient as bearer and must otherwise be exactly as valid as any other token (a verification failure responds with verifyCapabilityToken's own specific TokenVerdictReason as the error code, e.g. "expired"/"revoked"/"bad_signature", rather than a single generic code, mirroring how capability-request.ts already distinguishes "expired" from "malformed"); the token's own capability claim equals this handler's capability (obligation 2, otherwise "capability_mismatch"); and the token's own scope equals or roots the enclosing request's own top-level scope (obligation 4, via tokens.ts's own scopeNarrows -- otherwise "scope_mismatch"). Only once every obligation passes does it respond `{result:"ok"}` and invoke onGrant -- there is no decide()/timeout mechanism the way createCapabilityRequestHandler has one, since management.cddl specifies no protocol-level approval round trip for this primitive at all.
+*/
+function createCapabilityGrantHandler(options) {
+	return async function handleCapabilityGrant(incoming) {
+		if (incoming.command.verb !== options.capability) {
+			await incoming.respond({
+				result: "error",
+				code: "malformed"
+			});
+			return;
+		}
+		const parsed = capabilityGrantSchema.safeParse(incoming.command.params);
+		if (!parsed.success) {
+			await incoming.respond({
+				result: "error",
+				code: "malformed"
+			});
+			return;
+		}
+		const grantedToken = parsed.data["granted-token"];
+		const verdict = await verifyCapabilityToken(grantedToken, {
+			identity: options.identity,
+			clock: options.clock,
+			revocation: options.revocation,
+			expectedBearer: options.identity.deviceId
+		});
+		if (!verdict.ok) {
+			await incoming.respond({
+				result: "error",
+				code: verdict.reason
+			});
+			return;
+		}
+		if (verdict.claims.capability !== options.capability) {
+			await incoming.respond({
+				result: "error",
+				code: "capability_mismatch"
+			});
+			return;
+		}
+		if (!scopeNarrows(verdict.claims.scope, incoming.scope)) {
+			await incoming.respond({
+				result: "error",
+				code: "scope_mismatch"
+			});
+			return;
+		}
+		await incoming.respond({ result: "ok" });
+		options.onGrant({
+			capability: options.capability,
+			grantedToken,
+			scope: incoming.scope,
+			granterDevice: options.granterDevice
+		});
+	};
+}
+//#endregion
+export { buildCapabilityGrantCommand, createCapabilityGrantHandler, sendCapabilityGrant };

package/dist/domain/capability-request.cjs

@@ -0,0 +1,118 @@
+Object.defineProperty(exports, Symbol.toStringTag, { value: "Module" });
+const require_generated_protocol = require("../generated/protocol.cjs");
+const require_domain_tokens = require("./tokens.cjs");
+//#region src/domain/capability-request.ts
+/**
+* The generic, capability-agnostic capability-request / capability-grant-ok primitive (wire-mesh#78, spec/management.cddl). Lifts core/room's own room.join shape -- an ungated ask, held open, a human (or any other domain-supplied decision) accepts or refuses, acceptance mints and returns a token on the same response -- out of that one domain so any capability can reuse it, not just room:member. core/room's own room-client.ts is the reference consumer: it rewires requestToJoin/createRoomRouter's room.join handling onto requestCapability/createCapabilityRequestHandler below, supplying room-specific extension fields (its member list) through this module's own extensions mechanism rather than this module knowing anything about rooms.
+*
+* Two responsibilities live here, split the same way tokens.ts and room-token-verification.ts already split verification concerns: requestCapability is the asking side (a thin wrapper over MeshSession.sendManageRequest, parsing the grant response), and createCapabilityRequestHandler is the receiving side (validates the incoming ask, arms a receiver-side timeout so an unanswered request never hangs a requester forever, and hands the decision to the domain).
+*/
+const TOKEN_ID_BYTE_LENGTH = 16;
+function randomTokenId() {
+	const bytes = new Uint8Array(TOKEN_ID_BYTE_LENGTH);
+	crypto.getRandomValues(bytes);
+	return bytes;
+}
+/**
+* Builds a capability-request command per management.cddl. The outer `manage-command.verb` is the capability string itself -- the same value as this map's own `params.capability` field -- never a generic literal: capability-verb's own CDDL grammar is a closed alternation of colon-delimited `domain:noun` regexes (spec/tokens.cddl), so a bare literal like "capability" could never satisfy it, and routing by capability (the same way room.send/room.join already share the ROOM_MEMBER_CAPABILITY outer verb) is how a receiver's own per-capability handler knows which grant this ask is even for. `params.verb` is the fixed "capability.request" marker that distinguishes this ask from any other verb sharing the same outer capability (mirroring room.send/room.join's own inner `params.verb` split under one shared outer verb). `valid-until`, when given, bounds how long this ask is worth granting (wire-mesh#82) -- a receiver refuses outright once its own clock has passed it, rather than presenting a stale ask to a human for approval.
+*/
+function buildCapabilityRequestCommand(capability, validUntil) {
+	return {
+		verb: capability,
+		params: {
+			verb: "capability.request",
+			capability,
+			...validUntil !== void 0 ? { "valid-until": validUntil } : {}
+		}
+	};
+}
+/**
+* Sends a deliberately ungated capability-request (no token field at all -- per management.cddl's own header comment, this primitive puts access control entirely in the receiving side's own decision, not a capability check on the request itself, the same design room.join already established). Resolves with the freshly granted capability-grant-ok on approval (its own open `* tstr => any` tail may carry domain-specific extension fields, e.g. core/room's member list -- a caller that needs those parses the raw result itself, the same way room-client.ts's own requestToJoin wrapper does); rejects on denial (an ordinary manage-error) or a malformed response.
+*
+* targetDevice and timeoutMs forward directly to MeshSession.sendManageRequest's own identically-named parameters (relay routing and a requester-side give-up bound respectively -- wire-mesh#80 is already implemented there, not duplicated here). validUntil, when given, is attached to the request itself (wire-mesh#82) so a slow-to-answer receiver -- or a relay/facilitator forwarding this request on the caller's behalf -- can refuse or drop a now-stale ask outright rather than holding or forwarding it.
+*/
+async function requestCapability(session, capability, scope, targetDevice, timeoutMs, validUntil) {
+	const outcome = await session.sendManageRequest(buildCapabilityRequestCommand(capability, validUntil), scope, targetDevice, void 0, timeoutMs);
+	if (outcome.result !== "ok") throw new Error(`capability request for "${capability}" was refused (${outcome.code})`);
+	const parsed = require_generated_protocol.capabilityGrantOkSchema.safeParse(outcome);
+	if (!parsed.success) throw new Error(`capability request for "${capability}" response was malformed`);
+	return parsed.data;
+}
+/**
+* Builds a reusable handler for one capability's incoming capability-requests. The returned function is the generic counterpart to room-client.ts's own (now capability-specific) handleRoomJoin: given one IncomingManageRequest, it refuses a request for the wrong capability or a malformed payload as `{result:"error", code:"malformed"}`, refuses an already-expired request (per its own `valid-until`, wire-mesh#82) as `{result:"error", code:"expired"}` without ever invoking onRequest, otherwise arms the receiver-side timeout described on CreateCapabilityRequestHandlerOptions.timeoutMs and calls onRequest so the domain can accept (minting a fresh token via mintCapabilityToken and responding `{result:"ok", "granted-token": token, ...extensions}`) or reject (an ordinary manage-error) via the event's own decide().
+*/
+function createCapabilityRequestHandler(options) {
+	return async function handleCapabilityRequest(incoming) {
+		const parsed = require_generated_protocol.capabilityRequestSchema.safeParse(incoming.command.params);
+		if (!parsed.success || parsed.data.capability !== options.capability) {
+			await incoming.respond({
+				result: "error",
+				code: "malformed"
+			});
+			return;
+		}
+		const validUntil = parsed.data["valid-until"];
+		if (validUntil !== void 0 && validUntil <= options.clock.now()) {
+			await incoming.respond({
+				result: "error",
+				code: "expired"
+			});
+			return;
+		}
+		let settled = false;
+		const timeoutHandle = setTimeout(() => {
+			if (settled) return;
+			settled = true;
+			incoming.respond({
+				result: "error",
+				code: "timeout",
+				message: "no decision within the capability-request timeout"
+			}).catch(() => void 0);
+		}, options.timeoutMs);
+		timeoutHandle.unref();
+		options.onRequest({
+			scope: incoming.scope,
+			requesterDevice: options.bearerDevice,
+			async decide(decision) {
+				if (settled) return;
+				settled = true;
+				clearTimeout(timeoutHandle);
+				if (decision.kind === "reject") {
+					await incoming.respond({
+						result: "error",
+						code: "denied",
+						...decision.reason !== void 0 ? { message: decision.reason } : {}
+					});
+					return;
+				}
+				const verdict = await require_domain_tokens.mintCapabilityToken({
+					identity: options.identity,
+					clock: options.clock,
+					tokenId: randomTokenId(),
+					bearer: options.bearerDevice,
+					capability: decision.capability,
+					scope: incoming.scope,
+					expires: decision.expires,
+					...decision.delegationsRemaining !== void 0 ? { delegationsRemaining: decision.delegationsRemaining } : {}
+				});
+				if (!verdict.ok) {
+					await incoming.respond({
+						result: "error",
+						code: "mint_failed"
+					});
+					return;
+				}
+				const grantedToken = verdict.token;
+				await incoming.respond({
+					result: "ok",
+					"granted-token": grantedToken,
+					...decision.extensions ?? {}
+				});
+			}
+		});
+	};
+}
+//#endregion
+exports.buildCapabilityRequestCommand = buildCapabilityRequestCommand;
+exports.createCapabilityRequestHandler = createCapabilityRequestHandler;
+exports.requestCapability = requestCapability;

package/dist/domain/capability-request.d.cts

@@ -0,0 +1,56 @@
+import { F as ManageCommand, i as CapabilityGrantOk, o as CapabilityScope, x as DeviceId } from "../protocol-Dhswk7YD.cjs";
+import { t as IdentityPort } from "../identity-BldV8xFj.cjs";
+import { t as Clock } from "../clock-DiSx-WKM.cjs";
+import { IncomingManageRequest, MeshSession } from "./mesh-session.cjs";
+//#region src/domain/capability-request.d.ts
+/**
+ * Builds a capability-request command per management.cddl. The outer `manage-command.verb` is the capability string itself -- the same value as this map's own `params.capability` field -- never a generic literal: capability-verb's own CDDL grammar is a closed alternation of colon-delimited `domain:noun` regexes (spec/tokens.cddl), so a bare literal like "capability" could never satisfy it, and routing by capability (the same way room.send/room.join already share the ROOM_MEMBER_CAPABILITY outer verb) is how a receiver's own per-capability handler knows which grant this ask is even for. `params.verb` is the fixed "capability.request" marker that distinguishes this ask from any other verb sharing the same outer capability (mirroring room.send/room.join's own inner `params.verb` split under one shared outer verb). `valid-until`, when given, bounds how long this ask is worth granting (wire-mesh#82) -- a receiver refuses outright once its own clock has passed it, rather than presenting a stale ask to a human for approval.
+ */
+export declare function buildCapabilityRequestCommand(capability: string, validUntil?: number): ManageCommand;
+/**
+ * Sends a deliberately ungated capability-request (no token field at all -- per management.cddl's own header comment, this primitive puts access control entirely in the receiving side's own decision, not a capability check on the request itself, the same design room.join already established). Resolves with the freshly granted capability-grant-ok on approval (its own open `* tstr => any` tail may carry domain-specific extension fields, e.g. core/room's member list -- a caller that needs those parses the raw result itself, the same way room-client.ts's own requestToJoin wrapper does); rejects on denial (an ordinary manage-error) or a malformed response.
+ *
+ * targetDevice and timeoutMs forward directly to MeshSession.sendManageRequest's own identically-named parameters (relay routing and a requester-side give-up bound respectively -- wire-mesh#80 is already implemented there, not duplicated here). validUntil, when given, is attached to the request itself (wire-mesh#82) so a slow-to-answer receiver -- or a relay/facilitator forwarding this request on the caller's behalf -- can refuse or drop a now-stale ask outright rather than holding or forwarding it.
+ */
+export declare function requestCapability(session: Readonly<MeshSession>, capability: string, scope: Readonly<CapabilityScope>, targetDevice?: DeviceId, timeoutMs?: number, validUntil?: number): Promise<CapabilityGrantOk>;
+/**
+ * A receiver's decision on one incoming capability-request, mirroring room-client.ts's own (now capability-specific) RoomJoinDecision, generalized to any capability: "accept" mints and returns a fresh token; "reject" sends an ordinary manage-error carrying an optional human-readable reason.
+ */
+export type CapabilityGrantDecision = {
+  kind: "accept";
+  /** The capability the minted token actually carries -- usually, but not necessarily, the same string the request itself asked for (a receiver is free to grant something narrower). */
+  capability: string;
+  expires: number;
+  delegationsRemaining?: number;
+  /** Fields the domain wants merged onto the `{result:"ok", "granted-token": token, ...}` response, riding capability-grant-ok's own open `* tstr => any` tail -- the mechanism core/room's own room-join-ok uses for its `members` field, generalized so this module never needs to know what any particular capability's own grant response should additionally carry. Omit for a capability (e.g. a bare exec grant) whose response needs nothing beyond the token itself. */
+  extensions?: Record<string, unknown>;
+} | {
+  kind: "reject";
+  reason?: string;
+};
+/** One incoming, not-yet-expired capability-request, surfaced for the domain to accept or reject via decide(). */
+export interface CapabilityGrantRequestEvent {
+  /** The scope this request's own manage-request-frame carries -- e.g. core/room's `{kind:"room", path: roomPath}` -- passed through unchanged so the domain can inspect it (a room handler reads `.path` back out) without this module needing to know its shape. */
+  scope: Readonly<CapabilityScope>;
+  /** The peer device-id authenticated on the connection this request arrived over -- the requester, and so the future bearer of any token minted on acceptance. Same role as RoomRouterOptions.peerDevice / RoomJoinRequestEvent.requesterDevice. */
+  requesterDevice: DeviceId;
+  /** Resolves this request with the domain's decision. Settles the request's response exactly once: whichever of a real decide() call or the handler's own receiver-side timeout comes first wins, and the other is a no-op -- the same single-settle guarantee agent-comms' own PendingConnection timer/accept/reject/disconnect race already established (ported here, not reinvented). */
+  decide: (decision: Readonly<CapabilityGrantDecision>) => Promise<void>;
+}
+export interface CreateCapabilityRequestHandlerOptions {
+  /** The capability this handler grants. Checked against both the incoming request's own `params.capability` field (a mismatch is refused as malformed rather than trusted -- nothing about manage-command.verb structurally guarantees params.capability agrees with it) and used as the scope this handler is willing to act on at all; a caller wanting to grant several distinct capabilities over one session constructs one handler per capability, the same way core/room constructs one handler for `room:member` and nothing else. */
+  capability: string;
+  identity: IdentityPort;
+  clock: Clock;
+  /** The peer device-id authenticated on this session's own connection -- the requester, and so the future bearer of any token this handler mints. One handler is constructed per session for the same reason one RoomRouter is (RoomRouterOptions.peerDevice): MeshSession exposes no way for domain code to learn the authenticated peer independently. */
+  bearerDevice: DeviceId;
+  /** Receiver-side auto-reject window (wire-mesh#81): how long an incoming request may sit awaiting the domain's decision before this side responds with a real manage-error timeout rather than leaving the requester's own sendManageRequest hanging indefinitely. Ported from agent-comms' PendingConnection pattern (`wire-mesh-transport.ts`'s `pendingConnectionTimeoutMs` / `expirePendingConnection`): an unref'd timer so a stray one can never by itself keep the process alive, cleared the instant decide() is actually called so it can never fire after the request has already been answered. IncomingManageRequest exposes no requester-disconnect signal at this layer (unlike agent-comms' own transport, which owns the raw connection), so only the timeout half of that pattern is implemented here -- there is nothing to detect the requester giving up early honestly, so this module does not pretend to. */
+  timeoutMs: number;
+  /** Called once per incoming, not-yet-expired capability-request, for the domain to accept or reject via the event's own decide(). */
+  onRequest: (event: Readonly<CapabilityGrantRequestEvent>) => void;
+}
+/**
+ * Builds a reusable handler for one capability's incoming capability-requests. The returned function is the generic counterpart to room-client.ts's own (now capability-specific) handleRoomJoin: given one IncomingManageRequest, it refuses a request for the wrong capability or a malformed payload as `{result:"error", code:"malformed"}`, refuses an already-expired request (per its own `valid-until`, wire-mesh#82) as `{result:"error", code:"expired"}` without ever invoking onRequest, otherwise arms the receiver-side timeout described on CreateCapabilityRequestHandlerOptions.timeoutMs and calls onRequest so the domain can accept (minting a fresh token via mintCapabilityToken and responding `{result:"ok", "granted-token": token, ...extensions}`) or reject (an ordinary manage-error) via the event's own decide().
+ */
+export declare function createCapabilityRequestHandler(options: Readonly<CreateCapabilityRequestHandlerOptions>): (incoming: Readonly<IncomingManageRequest>) => Promise<void>;
+//#endregion

package/dist/domain/capability-request.d.mts

@@ -0,0 +1,56 @@
+import { F as ManageCommand, i as CapabilityGrantOk, o as CapabilityScope, x as DeviceId } from "../protocol-Dhswk7YD.mjs";
+import { t as IdentityPort } from "../identity-B1hBV3YA.mjs";
+import { t as Clock } from "../clock-DiSx-WKM.mjs";
+import { IncomingManageRequest, MeshSession } from "./mesh-session.mjs";
+//#region src/domain/capability-request.d.ts
+/**
+ * Builds a capability-request command per management.cddl. The outer `manage-command.verb` is the capability string itself -- the same value as this map's own `params.capability` field -- never a generic literal: capability-verb's own CDDL grammar is a closed alternation of colon-delimited `domain:noun` regexes (spec/tokens.cddl), so a bare literal like "capability" could never satisfy it, and routing by capability (the same way room.send/room.join already share the ROOM_MEMBER_CAPABILITY outer verb) is how a receiver's own per-capability handler knows which grant this ask is even for. `params.verb` is the fixed "capability.request" marker that distinguishes this ask from any other verb sharing the same outer capability (mirroring room.send/room.join's own inner `params.verb` split under one shared outer verb). `valid-until`, when given, bounds how long this ask is worth granting (wire-mesh#82) -- a receiver refuses outright once its own clock has passed it, rather than presenting a stale ask to a human for approval.
+ */
+export declare function buildCapabilityRequestCommand(capability: string, validUntil?: number): ManageCommand;
+/**
+ * Sends a deliberately ungated capability-request (no token field at all -- per management.cddl's own header comment, this primitive puts access control entirely in the receiving side's own decision, not a capability check on the request itself, the same design room.join already established). Resolves with the freshly granted capability-grant-ok on approval (its own open `* tstr => any` tail may carry domain-specific extension fields, e.g. core/room's member list -- a caller that needs those parses the raw result itself, the same way room-client.ts's own requestToJoin wrapper does); rejects on denial (an ordinary manage-error) or a malformed response.
+ *
+ * targetDevice and timeoutMs forward directly to MeshSession.sendManageRequest's own identically-named parameters (relay routing and a requester-side give-up bound respectively -- wire-mesh#80 is already implemented there, not duplicated here). validUntil, when given, is attached to the request itself (wire-mesh#82) so a slow-to-answer receiver -- or a relay/facilitator forwarding this request on the caller's behalf -- can refuse or drop a now-stale ask outright rather than holding or forwarding it.
+ */
+export declare function requestCapability(session: Readonly<MeshSession>, capability: string, scope: Readonly<CapabilityScope>, targetDevice?: DeviceId, timeoutMs?: number, validUntil?: number): Promise<CapabilityGrantOk>;
+/**
+ * A receiver's decision on one incoming capability-request, mirroring room-client.ts's own (now capability-specific) RoomJoinDecision, generalized to any capability: "accept" mints and returns a fresh token; "reject" sends an ordinary manage-error carrying an optional human-readable reason.
+ */
+export type CapabilityGrantDecision = {
+  kind: "accept";
+  /** The capability the minted token actually carries -- usually, but not necessarily, the same string the request itself asked for (a receiver is free to grant something narrower). */
+  capability: string;
+  expires: number;
+  delegationsRemaining?: number;
+  /** Fields the domain wants merged onto the `{result:"ok", "granted-token": token, ...}` response, riding capability-grant-ok's own open `* tstr => any` tail -- the mechanism core/room's own room-join-ok uses for its `members` field, generalized so this module never needs to know what any particular capability's own grant response should additionally carry. Omit for a capability (e.g. a bare exec grant) whose response needs nothing beyond the token itself. */
+  extensions?: Record<string, unknown>;
+} | {
+  kind: "reject";
+  reason?: string;
+};
+/** One incoming, not-yet-expired capability-request, surfaced for the domain to accept or reject via decide(). */
+export interface CapabilityGrantRequestEvent {
+  /** The scope this request's own manage-request-frame carries -- e.g. core/room's `{kind:"room", path: roomPath}` -- passed through unchanged so the domain can inspect it (a room handler reads `.path` back out) without this module needing to know its shape. */
+  scope: Readonly<CapabilityScope>;
+  /** The peer device-id authenticated on the connection this request arrived over -- the requester, and so the future bearer of any token minted on acceptance. Same role as RoomRouterOptions.peerDevice / RoomJoinRequestEvent.requesterDevice. */
+  requesterDevice: DeviceId;
+  /** Resolves this request with the domain's decision. Settles the request's response exactly once: whichever of a real decide() call or the handler's own receiver-side timeout comes first wins, and the other is a no-op -- the same single-settle guarantee agent-comms' own PendingConnection timer/accept/reject/disconnect race already established (ported here, not reinvented). */
+  decide: (decision: Readonly<CapabilityGrantDecision>) => Promise<void>;
+}
+export interface CreateCapabilityRequestHandlerOptions {
+  /** The capability this handler grants. Checked against both the incoming request's own `params.capability` field (a mismatch is refused as malformed rather than trusted -- nothing about manage-command.verb structurally guarantees params.capability agrees with it) and used as the scope this handler is willing to act on at all; a caller wanting to grant several distinct capabilities over one session constructs one handler per capability, the same way core/room constructs one handler for `room:member` and nothing else. */
+  capability: string;
+  identity: IdentityPort;
+  clock: Clock;
+  /** The peer device-id authenticated on this session's own connection -- the requester, and so the future bearer of any token this handler mints. One handler is constructed per session for the same reason one RoomRouter is (RoomRouterOptions.peerDevice): MeshSession exposes no way for domain code to learn the authenticated peer independently. */
+  bearerDevice: DeviceId;
+  /** Receiver-side auto-reject window (wire-mesh#81): how long an incoming request may sit awaiting the domain's decision before this side responds with a real manage-error timeout rather than leaving the requester's own sendManageRequest hanging indefinitely. Ported from agent-comms' PendingConnection pattern (`wire-mesh-transport.ts`'s `pendingConnectionTimeoutMs` / `expirePendingConnection`): an unref'd timer so a stray one can never by itself keep the process alive, cleared the instant decide() is actually called so it can never fire after the request has already been answered. IncomingManageRequest exposes no requester-disconnect signal at this layer (unlike agent-comms' own transport, which owns the raw connection), so only the timeout half of that pattern is implemented here -- there is nothing to detect the requester giving up early honestly, so this module does not pretend to. */
+  timeoutMs: number;
+  /** Called once per incoming, not-yet-expired capability-request, for the domain to accept or reject via the event's own decide(). */
+  onRequest: (event: Readonly<CapabilityGrantRequestEvent>) => void;
+}
+/**
+ * Builds a reusable handler for one capability's incoming capability-requests. The returned function is the generic counterpart to room-client.ts's own (now capability-specific) handleRoomJoin: given one IncomingManageRequest, it refuses a request for the wrong capability or a malformed payload as `{result:"error", code:"malformed"}`, refuses an already-expired request (per its own `valid-until`, wire-mesh#82) as `{result:"error", code:"expired"}` without ever invoking onRequest, otherwise arms the receiver-side timeout described on CreateCapabilityRequestHandlerOptions.timeoutMs and calls onRequest so the domain can accept (minting a fresh token via mintCapabilityToken and responding `{result:"ok", "granted-token": token, ...extensions}`) or reject (an ordinary manage-error) via the event's own decide().
+ */
+export declare function createCapabilityRequestHandler(options: Readonly<CreateCapabilityRequestHandlerOptions>): (incoming: Readonly<IncomingManageRequest>) => Promise<void>;
+//#endregion