@sublay/js 7.7.1 → 7.9.0

package/dist/interfaces/Workspace.d.ts

@@ -60,6 +60,29 @@ export interface WorkspaceInvitation {
 export interface WorkspaceRosterReason {
     type: "owner" | "member" | "ancestor-owner" | "reach-holder" | "descendant-member";
     rank?: number;
+    /**
+     * The SAME ladder position, expressed as an offset from the CALLER: `1` = one
+     * rung below you, `0` = your peer, `-3` = three rungs above you. The caller's
+     * own anchor is their member row on this workspace if they hold one, and apex
+     * (one step above rank 0) if they do not — so a rank-0 member reads back as
+     * `relativeRank: 1` for an owner.
+     *
+     * Authority-bearing and fenced WITH `rank`, never beside it: it is `rank`
+     * minus a number the caller already knows, so leaking it leaks `rank` exactly.
+     *
+     * Present on same-node `member` reasons only. `descendant-member` entries
+     * carry `rank` but NEVER `relativeRank` — rank is per-workspace, so an offset
+     * measured against your standing on THIS node would be arithmetic across two
+     * different ladders. Use their absolute `rank` there.
+     *
+     * Note the deliberate asymmetry with the fence described above: the FENCE is
+     * per node (a descendant row may or may not carry `rank` depending on your
+     * standing there), but PRESENCE of `relativeRank` is not — it is absent on
+     * every `descendant-member` row, unconditionally, however much authority you
+     * hold. A field that appears and disappears by who is asking is worse to
+     * consume than one that is uniformly absent.
+     */
+    relativeRank?: number;
     capabilities?: WorkspaceCapability[];
     permissions?: string[];
     title?: string | null;
@@ -99,6 +122,13 @@ export interface WorkspaceMemberStanding {
     capabilities?: WorkspaceCapability[];
     permissions?: string[];
     rank?: number | null;
+    /**
+     * `rank` expressed as an offset from the CALLER (negative = senior to you).
+     * `null` exactly when `rank` is `null` — a target with no direct member row
+     * here sits outside the ladder and has no position to measure. Fenced with
+     * `rank`: absent (not null) for a caller who may not see it.
+     */
+    relativeRank?: number | null;
     title: string | null;
     metadata: Record<string, any>;
 }

package/dist/modules/auth/changePassword.d.ts

@@ -1,11 +1,34 @@
 import { SublayHttpClient } from "../../core/client";
+import { PushDeviceIdentifier } from "../../interfaces/Push";
 export interface ChangePasswordProps {
     /** The user's current password (verified before the change). */
     password: string;
     newPassword: string;
+    /**
+     * Optional. The physical device making this call.
+     *
+     * A password change also deletes every push binding the user holds, so an
+     * intruder's device stops receiving notification content. Naming this device
+     * keeps ITS binding — nothing re-binds a device from its live session, so
+     * without this the handset the user just changed their password on goes
+     * quiet until the app cold-starts or switches accounts.
+     *
+     * Same value passed to `push.register` / `auth.signOut`. Omit it and every
+     * binding for the user goes, this device included.
+     */
+    pushDevice?: PushDeviceIdentifier;
 }
 export interface ChangePasswordResponse {
     success: boolean;
     message: string;
 }
+/**
+ * Change the signed-in user's password.
+ *
+ * Ends every OTHER session for that user — every other device must sign in
+ * again with the new password — while the session making this call survives.
+ * The server identifies that session from the access token this request is
+ * already authenticated with, so nothing about the caller's session has to be
+ * sent.
+ */
 export declare function changePassword(client: SublayHttpClient, data: ChangePasswordProps): Promise<ChangePasswordResponse>;

package/dist/modules/auth/signOut.d.ts

@@ -1,9 +1,103 @@
 import { SublayHttpClient } from "../../core/client";
+import { PushDeviceIdentifier } from "../../interfaces/Push";
 export interface SignOutProps {
     /**
      * Defaults to the SDK's stored refresh token (SDK-managed mode). Pass it
      * explicitly in host-managed mode, where the SDK holds no refresh token.
      */
     refreshToken?: string;
+    /**
+     * Optional. When supplied — and the project has the `push` bundle — the
+     * server deletes this user's push binding for that device in the SAME
+     * transaction as the token-family destroy: signing out unbinds the device's
+     * push, or nothing happens at all.
+     *
+     * **Needs a refresh token to have any effect.** The unbind is scoped to the
+     * `sub` of the refresh token, which is what stops one account removing
+     * another account's binding on a shared device — so with no token there is no
+     * user to scope it to and the server answers `204` before it ever looks at
+     * `pushDevice`. When none can be resolved the field is DROPPED from the
+     * request rather than sent into that silent no-op, the sign-out proceeds
+     * normally, and the returned `pushUnbindSkipped` says so. Watch for it in
+     * **host-managed mode**: such a client is built with `getToken` and no
+     * `initialTokens`, and its `setTokens` is inert, so it starts with no refresh
+     * token and can never acquire one. Pass `refreshToken` explicitly alongside
+     * `pushDevice` there.
+     *
+     * If the unbind fails the request fails (HTTP 500, code
+     * `auth/device-deregistration-failed` or `auth/sign-out-failed`) and NOTHING
+     * is committed — the session survives so the caller can retry, and this call
+     * rethrows WITHOUT clearing the SDK's local tokens, so the credential that
+     * retry needs is still there.
+     *
+     * That is the ONLY failure that leaves you signed in. Every other one — a
+     * `429` from the rate limiter or a quota gate, a `423`, a `503`, a `400` on
+     * the body, a dropped connection — never touched a push binding, so it
+     * clears the local tokens and RESOLVES: a user must always be able to sign
+     * out. See `UNBIND_FAILURE_CODES`.
+     *
+     * Omit it and the request is byte-identical to before this field existed.
+     */
+    pushDevice?: PushDeviceIdentifier;
+}
+/**
+ * Why the unbind did not happen. Present only when `pushUnbindSkipped` is
+ * `true`, and it exists because THE TWO SKIPS ARE RECOVERED DIFFERENTLY — a
+ * caller that cannot tell them apart can only ever pick the wrong remedy for
+ * one of them:
+ *
+ * - `no-refresh-token` — this SDK never asked. Nothing was destroyed either:
+ *   with no token the server has no session to end, so the account, its
+ *   credential and its binding are all still there. **Retryable**: re-issue
+ *   the sign-out with an explicit `refreshToken` and the unbind happens.
+ * - `push-unbind-status-unknown` — the server was asked and could not answer.
+ *   The sign-out itself DID commit, so the credential that would have driven a
+ *   retry is gone; re-issuing achieves nothing. The binding clears when that
+ *   account next registers on this device, or when the server prunes the token
+ *   as undeliverable.
+ */
+export type PushUnbindSkipReason = "no-refresh-token" | "push-unbind-status-unknown";
+export interface SignOutResult {
+    /**
+     * `true` whenever a `pushDevice` was supplied and the unbind did NOT happen,
+     * so this device's push binding for that account may still be live. Either
+     * the SDK declined to ask (no refresh token to scope the unbind to) or the
+     * server could not answer whether a binding exists; `pushUnbindSkipReason`
+     * says which, and the two are recovered differently.
+     *
+     * `false` means NO SKIP WAS REPORTED — by this SDK or by the server. It is
+     * not a promise that no skip happened, and the difference is not academic:
+     * the server declines the unbind for several reasons it answers with a plain
+     * `204`, and every one of them reads `false` here.
+     *
+     *   - The refresh token is authentic but expired beyond the server's unbind
+     *     window (90 days past `exp`), so there is no subject to scope the unbind
+     *     to. Reachable from this SDK by passing an old `refreshToken` explicitly
+     *     alongside `pushDevice`.
+     *   - The refresh token is malformed or fails signature verification.
+     *   - The project has no `push` bundle, so no binding can exist.
+     *   - The unbind ran and matched zero rows — the binding was already gone, or
+     *     was never registered under this device key.
+     *
+     * The server logs each of those under its own reason; only the case where it
+     * could not determine whether a binding exists is reported in the response,
+     * because that is the one where the binding may still be LIVE and nobody
+     * looked. The rest either prove there was nothing to remove or leave a device
+     * key the server cannot attribute to a user, and neither gives the caller
+     * anything to act on beyond what it already knows.
+     *
+     * A request that failed short of an unbind attempt reads `false` too — a
+     * gate's `429` or `423`, a `503`, a `400`, a dropped connection. Those clear
+     * the local tokens and resolve rather than reject (see `UNBIND_FAILURE_CODES`
+     * for why), and none of them is a REPORTED skip; they are logged with a
+     * warning instead.
+     *
+     * The sign-out itself is unaffected by the flag in both directions: a user
+     * must always be able to sign out, so a skipped unbind never fails the call
+     * and never leaves the local tokens in place.
+     */
+    pushUnbindSkipped: boolean;
+    /** Set only when `pushUnbindSkipped` is `true`. See `PushUnbindSkipReason`. */
+    pushUnbindSkipReason?: PushUnbindSkipReason;
 }
-export declare function signOut(client: SublayHttpClient, data?: SignOutProps): Promise<void>;
+export declare function signOut(client: SublayHttpClient, data?: SignOutProps): Promise<SignOutResult>;

package/dist/modules/chat/getMessage.d.ts

@@ -4,5 +4,10 @@ import { SpaceReputationContextParams } from "../../interfaces/SpaceReputation";
 export interface GetMessageProps extends SpaceReputationContextParams {
     conversationId: string;
     messageId: string;
+    /**
+     * Comma-separated associations to populate. Only `"grants"` is supported
+     * here — it attaches the message's reputation-grant summary.
+     */
+    include?: string;
 }
 export declare function getMessage(client: SublayHttpClient, data: GetMessageProps): Promise<ChatMessage>;

package/dist/modules/chat/listMessages.d.ts

@@ -20,7 +20,11 @@ export interface ListMessagesProps extends SpaceReputationContextParams {
     /** Page size (default 50, max 100). */
     limit?: number;
     sort?: "asc" | "desc";
-    /** Comma-separated associations to populate, e.g. "files". */
+    /**
+     * Comma-separated associations to populate: `"files"` (message
+     * attachments) and `"grants"` (the reputation-grant summary). Combine
+     * them as `"files,grants"` — the server splits and trims this itself.
+     */
     include?: string;
     /** Optional filters, e.g. `{ hasReplies: true }`. */
     filters?: MessageFilters;

package/dist/modules/reputation/createGrant.d.ts

@@ -0,0 +1,45 @@
+import { SublayHttpClient } from "../../core/client";
+import { ReputationGrant, ReputationGrantTargetFilter } from "../../interfaces/ReputationGrant";
+interface CreateGrantBaseProps {
+    /** The user receiving the reputation. Cannot be the logged-in user. */
+    recipientId: string;
+    /**
+     * Positive integer. A user transfer can never mint (negatives) nor be a
+     * no-op (zero) — minting is service-key-only and lives in `@sublay/node`.
+     */
+    amount: number;
+    /** The bucket both legs move in. Omitted/null = the project-general bucket. */
+    spaceId?: string | null;
+    /**
+     * Free-text reason. Trimmed and capped at 2000 characters server-side.
+     * Genuinely nullable — an explicit `null` is accepted and means "no note".
+     */
+    note?: string | null;
+    /**
+     * Arbitrary JSON, capped at 1 MB server-side.
+     *
+     * NOT nullable — deliberately asymmetric with `note` directly above, not a
+     * typo. The server's shared `metadataSchema` is `z.record(...).optional()`
+     * with no `.nullable()`, so an explicit `metadata: null` is rejected with
+     * `400 reputation-grant/invalid-body`. Omit the key to mean "no metadata".
+     */
+    metadata?: Record<string, any>;
+}
+/**
+ * `targetType` and `targetId` are supplied together or not at all — the
+ * both-or-neither pair is carried by {@link ReputationGrantTargetFilter}, which
+ * makes the half-filled shape a compile error instead of a
+ * `400 reputation-grant/invalid-body`.
+ */
+export type CreateGrantProps = CreateGrantBaseProps & ReputationGrantTargetFilter;
+/**
+ * Transfers reputation from the logged-in user to another user — a **debited
+ * transfer**: the amount leaves the sender's bucket and lands in the
+ * recipient's bucket in the same space. Nothing is created.
+ *
+ * There is no actor field: the sender is always the user the token belongs to.
+ * Naming somebody else as the sender requires a service key, which this SDK
+ * never holds.
+ */
+export declare function createGrant(client: SublayHttpClient, data: CreateGrantProps): Promise<ReputationGrant>;
+export {};

package/dist/modules/reputation/index.d.ts

@@ -0,0 +1,2 @@
+export { createGrant } from "./createGrant";
+export { listGrants } from "./listGrants";

package/dist/modules/reputation/listGrants.d.ts

@@ -0,0 +1,45 @@
+import { SublayHttpClient } from "../../core/client";
+import { GrantSummary, ReputationGrant, ReputationGrantTargetFilter } from "../../interfaces/ReputationGrant";
+import { PaginatedResponse } from "../../interfaces/IPaginatedResponse";
+import { SpaceReputationContextParams } from "../../interfaces/SpaceReputation";
+interface ListGrantsBaseProps extends SpaceReputationContextParams {
+    page?: number;
+    limit?: number;
+    /** What this user received. */
+    recipientId?: string;
+    /** What this user sent. */
+    senderId?: string;
+    /** Associations to expand. Only `"user"` is supported (hydrates both parties). */
+    include?: string;
+}
+/**
+ * The third filter shape — "who rewarded this item" — is the
+ * {@link ReputationGrantTargetFilter} pair, so a half-filled target is a
+ * compile error rather than a `400 reputation-grant/invalid-filter`.
+ *
+ * Mutual exclusivity between the three shapes is NOT expressed in the type: a
+ * three-way exclusive union would multiply out across every pagination and
+ * space-reputation field and make the props unreadable, for a rule the server
+ * reports clearly. Only the both-or-neither pairing is typed.
+ */
+export type ListGrantsProps = ListGrantsBaseProps & ReputationGrantTargetFilter;
+/**
+ * The `summary` block rides alongside the page envelope, and only on the
+ * target filter shape.
+ */
+export interface ListGrantsResponse extends PaginatedResponse<ReputationGrant> {
+    summary?: GrantSummary;
+}
+/**
+ * Lists reputation grants.
+ *
+ * Exactly one filter shape per request — `recipientId`, `senderId`, or
+ * `targetType` + `targetId`. Supplying none or combining two is a `400`; the
+ * shapes are not AND-ed, which is what keeps the `summary` block reconcilable
+ * with the rows beneath it.
+ *
+ * Only positive grants are ever returned. Negative grants are app moderation
+ * deductions and are unreadable from every public surface.
+ */
+export declare function listGrants(client: SublayHttpClient, data: ListGrantsProps): Promise<ListGrantsResponse>;
+export {};

package/dist/modules/workspaces/createWorkspaceInvite.d.ts

@@ -7,11 +7,60 @@ export interface CreateWorkspaceInviteProps {
     username?: string;
     capabilities?: WorkspaceCapability[];
     permissions?: string[];
-    rank: number;
+    /**
+     * The invited rank, ABSOLUTE — a position on this workspace's ladder (smaller
+     * = more senior). The escape hatch, and what tier-constant apps want, since
+     * they compute the number anyway.
+     *
+     * Optional, and mutually exclusive with `relativeRank` — sending both is a
+     * 400. Sending NEITHER defaults to `relativeRank: 1`, one rung below the
+     * inviter, which is well defined for every actor and can never fail the rank
+     * floor.
+     *
+     * ⚠️ That default is for a NEW invitation. Re-inviting a target who already
+     * has a live pending invite updates it in place, and there omitting both rank
+     * fields PRESERVES the stored rank instead of re-defaulting it. See the
+     * function doc below.
+     */
+    rank?: number;
+    /**
+     * The invited rank, RELATIVE to the inviter: `1` = one rung below me, `2` =
+     * two rungs below, and so on. The documented happy path — every governance
+     * rule about rank is relative, so this is what callers usually mean.
+     *
+     * Must be `>= 1` on a write. `0` would mean "a peer", which the assign rule
+     * forbids (you cannot clone your own authority), and a negative offset would
+     * mint someone senior to you; both are a 400. Both rank fields are also capped at `2147483647` (int4), and the RESOLVED sum is bounded too — an in-range anchor plus an in-range offset can still overflow, which is a 400 rather than a 500.
+     *
+     * The anchor is the inviter's OWN rank if they hold a member row on this
+     * workspace, and apex (one step above rank 0) if they do not — so an owner's
+     * `relativeRank: 1` lands on rank 0, while a rank-3 member's lands on rank 4.
+     *
+     * ⚠️ A SNAPSHOT, not a live link: the offset is resolved to an absolute rank
+     * once, at invite time, and frozen. It does not track the inviter's later
+     * promotions or demotions.
+     */
+    relativeRank?: number;
     title?: string | null;
 }
 /**
  * Create an invitation (requires the `invite` capability on the workspace). The
  * inviter is the bearer-token user.
+ *
+ * The invited rank comes in either coordinate — `rank` (absolute) or
+ * `relativeRank` (an offset from the inviter) — never both. Omitting both
+ * defaults to `relativeRank: 1`, one rung below the inviter, which is the
+ * documented happy path and can never fail the rank floor.
+ *
+ * ⚠️ This route doubles as an UPSERT, and the default above applies only to a
+ * NEW invitation. Re-inviting a target who already holds a live pending invite
+ * refreshes THAT invitation in place — same id, expiry reset — and on that
+ * branch an omitted grant field is PRESERVED, not re-defaulted or blanked:
+ * `rank`, `capabilities`, `permissions` and `title` all keep their stored
+ * values. A "Resend invitation" button that posts only the address therefore
+ * cannot silently re-rank the invitee to one below whoever clicked it. An
+ * explicit value still overwrites, and an explicit `relativeRank` re-resolves
+ * against the CURRENT caller. Full semantics:
+ * https://docs.sublay.io/api-reference/workspaces/invitations/create-invite
  */
 export declare function createWorkspaceInvite(client: SublayHttpClient, data: CreateWorkspaceInviteProps): Promise<WorkspaceInvitation>;

package/dist/modules/workspaces/deleteWorkspace.d.ts

@@ -7,7 +7,7 @@ export interface DeleteWorkspaceResponse {
 }
 /**
  * Owner-only delete (own owner or an ancestor owner). Cascades the whole
- * subtree transactionally. The actor is the bearer-token user — no `userId`
- * body is sent.
+ * subtree transactionally. The actor is the bearer-token user — no actor
+ * field is sent.
  */
 export declare function deleteWorkspace(client: SublayHttpClient, data: DeleteWorkspaceProps): Promise<DeleteWorkspaceResponse>;

package/dist/modules/workspaces/fetchManyWorkspaces.d.ts

@@ -8,6 +8,10 @@ export interface FetchManyWorkspacesProps {
 }
 /**
  * List the bearer-token user's direct-membership + owned workspaces. The actor
- * is derived from the token — no `userId` is sent.
+ * is derived from the token — no actor field is sent.
+ *
+ * ⚠️ Only the fields declared above are accepted. The workspaces endpoints
+ * refuse any undeclared top-level field with a 400 rather than ignoring it, so
+ * do not spread an unrelated object into `data`.
  */
 export declare function fetchManyWorkspaces(client: SublayHttpClient, data?: FetchManyWorkspacesProps): Promise<PaginatedResponse<Workspace>>;

package/dist/modules/workspaces/fetchWorkspaceAuthority.d.ts

@@ -7,5 +7,10 @@ export interface FetchWorkspaceAuthorityProps {
  * Authority-as-a-service read — the bearer-token user's resolved standing
  * (`{ reasons, capabilities, permissions, rank }`) on the workspace. A
  * permission check is a one-line `.includes()` on the result.
+ *
+ * ⚠️ No `relativeRank` on this read. It is an offset from the caller, and here
+ * the caller IS the subject — so it could only ever be `0`. `rank` is the only
+ * rank coordinate this endpoint exposes. `relativeRank` is meaningful on the
+ * roster and member-standing reads, where the subject is somebody else.
  */
 export declare function fetchWorkspaceAuthority(client: SublayHttpClient, data: FetchWorkspaceAuthorityProps): Promise<WorkspaceAuthority>;

package/dist/modules/workspaces/fetchWorkspaceMemberStanding.d.ts

@@ -6,6 +6,10 @@ export interface FetchWorkspaceMemberStandingProps {
 }
 /**
  * Read one user's resolved standing on a workspace (`reasons`, `capabilities`,
- * `permissions`, `rank`, `title`, `metadata`).
+ * `permissions`, `rank`, `relativeRank`, `title`, `metadata`).
+ *
+ * `relativeRank` is the target's `rank` as an offset from YOU (negative =
+ * senior to you), and is fenced with `rank`: both are absent, not null, for a
+ * caller who may not see the target's authority.
  */
 export declare function fetchWorkspaceMemberStanding(client: SublayHttpClient, data: FetchWorkspaceMemberStandingProps): Promise<WorkspaceMemberStanding>;

package/dist/modules/workspaces/fetchWorkspaceMembers.d.ts

@@ -9,5 +9,10 @@ export interface FetchWorkspaceMembersProps {
  * Unified roster read — one entry per distinct user, each with a `reasons`
  * array. Always returned in full (never paginated). With `countOnly=true` the
  * shape is `WorkspaceRosterCountsResponse` instead. Actor from the token.
+ *
+ * Same-node `member` reasons carry both rank coordinates: absolute `rank` and
+ * `relativeRank`, the offset from you (`1` = one rung below you, `-3` = three
+ * above). Both are fenced together and both are absent for a caller who does
+ * not operate people here. `descendant-member` reasons carry `rank` only.
  */
 export declare function fetchWorkspaceMembers(client: SublayHttpClient, data: FetchWorkspaceMembersProps): Promise<WorkspaceRosterResponse | WorkspaceRosterCountsResponse>;

package/dist/modules/workspaces/leaveWorkspace.d.ts

@@ -5,7 +5,8 @@ export interface LeaveWorkspaceProps {
 /**
  * The bearer-token user leaves this workspace — removes THEIR OWN direct
  * membership on THIS node only (owning a child is unaffected). An owner cannot
- * leave (409 `workspace/sole-owner`); transfer or delete first. No `userId` is
- * sent — the server derives the leaver from the token.
+ * leave (409 `workspace/sole-owner`) — transfer ownership or remove the
+ * workspace first. No actor field is sent; the server derives the leaver from
+ * the token.
  */
 export declare function leaveWorkspace(client: SublayHttpClient, data: LeaveWorkspaceProps): Promise<void>;

package/dist/modules/workspaces/removeWorkspaceMember.d.ts

@@ -6,7 +6,7 @@ export interface RemoveWorkspaceMemberProps {
 /**
  * Remove a member from this workspace. Requires the `remove-member` capability
  * and is rank-bounded. The workspace owner cannot be removed (409
- * `workspace/sole-owner`) — transfer ownership first. No `userId` body is sent;
+ * `workspace/sole-owner`) — transfer ownership first. No actor field is sent;
  * the actor comes from the token.
  */
 export declare function removeWorkspaceMember(client: SublayHttpClient, data: RemoveWorkspaceMemberProps): Promise<void>;

package/dist/modules/workspaces/transferWorkspaceOwnership.d.ts

@@ -9,7 +9,7 @@ export interface TransferWorkspaceOwnershipProps {
 }
 /**
  * Hand the workspace to a new owner. Owner-only (own owner or an ancestor
- * owner). The actor is the bearer-token user — no `userId` is sent;
+ * owner). The actor is the bearer-token user — no actor field is sent;
  * `newOwnerId` addresses the TARGET, not the actor.
  */
 export declare function transferWorkspaceOwnership(client: SublayHttpClient, data: TransferWorkspaceOwnershipProps): Promise<Workspace>;

package/dist/modules/workspaces/updateWorkspace.d.ts

@@ -7,6 +7,6 @@ export interface UpdateWorkspaceProps {
 }
 /**
  * Edit a workspace's name / metadata. Requires the `edit-workspace` capability
- * (or ownership). The actor is the bearer-token user — no `userId` is sent.
+ * (or ownership). The actor is the bearer-token user — no actor field is sent.
  */
 export declare function updateWorkspace(client: SublayHttpClient, data: UpdateWorkspaceProps): Promise<Workspace>;

package/dist/modules/workspaces/updateWorkspaceInheritFlag.d.ts

@@ -8,6 +8,6 @@ export interface UpdateWorkspaceInheritFlagProps {
  * Flip whether capabilities held on an ancestor "reach" into this workspace.
  * Owner-only in both directions (own owner or an ancestor owner), and blocked
  * (403 `workspace/inherit-enforced`) when the project enforces its default.
- * The actor is the bearer-token user — no `userId` is sent.
+ * The actor is the bearer-token user — no actor field is sent.
  */
 export declare function updateWorkspaceInheritFlag(client: SublayHttpClient, data: UpdateWorkspaceInheritFlagProps): Promise<Workspace>;

package/dist/modules/workspaces/updateWorkspaceMember.d.ts

@@ -6,12 +6,30 @@ export interface UpdateWorkspaceMemberProps {
     capabilities?: WorkspaceCapability[];
     permissions?: string[];
     rank?: number;
+    /**
+     * `rank`'s relative twin: an offset from the ACTOR (`1` = one rung below me),
+     * resolved to an absolute rank at write time and stored absolute. Must be
+     * `>= 1`; mutually exclusive with `rank` (sending both is a 400). Both rank fields are also capped at `2147483647` (int4), and the RESOLVED sum is bounded too — an in-range anchor plus an in-range offset can still overflow, which is a 400 rather than a 500.
+     *
+     * The anchor is the actor's own rank if they hold a member row on this
+     * workspace, apex otherwise. A SNAPSHOT — frozen at write time, it does not
+     * follow the actor's own rank afterwards.
+     *
+     * Unlike invite, edit has NO default: omitting BOTH still means "rank
+     * unchanged", so editing someone's capabilities never moves them on the
+     * ladder.
+     */
+    relativeRank?: number;
     title?: string | null;
     metadata?: Record<string, any>;
 }
 /**
  * Edit a member's grant / profile. Powerful fields need `edit-member-access`
  * plus rank + no-escalation rules; cosmetic fields need only
- * `edit-member-profile`. No `userId` is sent — the actor comes from the token.
+ * `edit-member-profile`. No actor field is sent — the actor comes from the token.
+ *
+ * Rank moves in either coordinate — `rank` (absolute) or `relativeRank` (an
+ * offset from the actor) — never both. Omitting both leaves rank UNCHANGED;
+ * unlike invite, edit has no value default.
  */
 export declare function updateWorkspaceMember(client: SublayHttpClient, data: UpdateWorkspaceMemberProps): Promise<WorkspaceMember>;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sublay/js",
-  "version": "7.7.1",
+  "version": "7.9.0",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",
   "files": [