@fleetless/contracts 1.0.0

package/dist/identity.d.ts

@@ -0,0 +1,549 @@
+import { z } from 'zod';
+/**
+ * **Fleetless users: the org's team, and the only people who reach the
+ * console** (spec `2026-09-05-app-user-auth`, D1).
+ *
+ * There are two identity spaces now and **nothing joins them**:
+ *
+ * - *Fleetless users*, this file. The people who configure robots in the
+ *   console. Email globally unique, tier `owner | developer`, a Fleetless
+ *   password, login through the auth portal. They always have MCP access, at
+ *   the one central endpoint.
+ * - *app users*, `app-users.ts`. The people who use a developer's app. One app
+ *   each, email unique per app, authenticated through the JSON client-auth
+ *   API that the developer's own UI calls.
+ *
+ * A Fleetless user who wants to use an app registers or is invited like
+ * anybody else; there is no path from one space to the other.
+ *
+ * **What that deleted, with no successor** (D1): groups and the Org Admins
+ * group, app assignments, impersonation, the per-user MCP override and the
+ * org-level federation policy. The 2026-08-29 model had put developers and end
+ * users into one pool per org and connected them with all of the above; in use
+ * it turned out to model the wrong thing — the two populations have different
+ * lifecycles, and every mechanism joining them was cost without a product
+ * reason.
+ *
+ * What did **not** change: the password rules, the session and token shapes,
+ * and the enumeration-oracle reasoning on password reset. None of those was
+ * ever a statement about which space a person lived in.
+ *
+ * **Email is globally unique here** — `lower(email)` unique across all orgs, so
+ * one address is exactly one Fleetless user in exactly one org. Every shape
+ * that identifies a person by a bare address (`developerLoginRequest`,
+ * `passwordResetRequest`) therefore resolves to at most one account with no org
+ * context needed. App users are the opposite and say so on their own shape:
+ * unique **per app**, so one address may be several unrelated app accounts.
+ */
+/**
+ * The password rule, stated once so the cloud, the console and the SDK refuse
+ * the same inputs for the same reason. Length only: a rule a user cannot
+ * predict is a rule they work around.
+ *
+ * Shared by both identity spaces on purpose. A weaker rule for app users would
+ * be a second policy for one decision, and the weaker one always wins by
+ * accident.
+ */
+export declare const password: z.ZodString;
+/** The bound on a Fleetless user's display name; `APP_USER_DISPLAY_NAME_MAX` matches it, so a rename cannot be legal in one space and refused in the other. */
+export declare const USER_DISPLAY_NAME_MAX = 120;
+/**
+ * **The two tiers a Fleetless user can hold** (D1). Owner-exclusive: delete
+ * the org, edit org settings, promote to owner, and later billing. Everything
+ * else a Fleetless user may do, a `developer` may do.
+ *
+ * `member` was renamed to `developer` in the 2026-08-29 redesign and is **not**
+ * accepted as an alias anywhere — a wire that took both would leave two names
+ * for one tier in every log, every audit detail and every console fixture, and
+ * the older one would keep arriving forever.
+ *
+ * **Every Fleetless user has one.** It used to be optional, because the pool
+ * also held people who were not org admins and had no console powers to grade.
+ * That pool is gone: a Fleetless user *is* a member of the team, so the field
+ * is required and an absent one is a mapper bug rather than a state.
+ */
+export declare const orgAdminTier: z.ZodEnum<{
+    owner: "owner";
+    developer: "developer";
+}>;
+export type OrgAdminTier = z.infer<typeof orgAdminTier>;
+export declare const org: z.ZodObject<{
+    id: z.ZodUUID;
+    name: z.ZodString;
+    created_at: z.ZodISODateTime;
+}, z.core.$strip>;
+export type Org = z.infer<typeof org>;
+/** What `PATCH /api/org` answers: the org as it now stands. */
+export declare const patchOrgResponse: z.ZodObject<{
+    org: z.ZodObject<{
+        id: z.ZodUUID;
+        name: z.ZodString;
+        created_at: z.ZodISODateTime;
+    }, z.core.$strip>;
+}, z.core.$strip>;
+export type PatchOrgResponse = z.infer<typeof patchOrgResponse>;
+/**
+ * **A member of the org's team.** Console access, a tier, a Fleetless
+ * password, and no relationship whatsoever to any app's users.
+ *
+ * `email` is **globally unique** — `lower(email)` unique across every org, a
+ * constraint the cloud enforces in the database; a schema cannot see two rows
+ * at once and this one makes no claim to. One address is one Fleetless user:
+ * no two orgs may hold the same one.
+ *
+ * **What this shape lost with the two-space cut**: `group_id` (there are no
+ * groups), `mcp_access` (a Fleetless user always has MCP access, at the
+ * central endpoint), and `has_password`. The last is the interesting one — it
+ * existed because a pool user might have been provisioned by an identity
+ * provider and hold no Fleetless credential. A Fleetless user always holds
+ * one: the console is password-only by design (D1), which removes the
+ * IdP-lockout class entirely, so a field reporting whether the credential
+ * exists would have exactly one value forever.
+ */
+export declare const fleetlessUser: z.ZodObject<{
+    id: z.ZodUUID;
+    org_id: z.ZodUUID;
+    email: z.ZodEmail;
+    display_name: z.ZodNullable<z.ZodString>;
+    tier: z.ZodEnum<{
+        owner: "owner";
+        developer: "developer";
+    }>;
+    created_at: z.ZodISODateTime;
+}, z.core.$strip>;
+export type FleetlessUser = z.infer<typeof fleetlessUser>;
+/** `GET /api/org/users` — the whole team. Never null: an org always has at least its owner. */
+export declare const fleetlessUserListResponse: z.ZodObject<{
+    users: z.ZodArray<z.ZodObject<{
+        id: z.ZodUUID;
+        org_id: z.ZodUUID;
+        email: z.ZodEmail;
+        display_name: z.ZodNullable<z.ZodString>;
+        tier: z.ZodEnum<{
+            owner: "owner";
+            developer: "developer";
+        }>;
+        created_at: z.ZodISODateTime;
+    }, z.core.$strip>>;
+}, z.core.$strip>;
+export type FleetlessUserListResponse = z.infer<typeof fleetlessUserListResponse>;
+/**
+ * Access plus refresh (spec §3.4). The access token is short-lived; the
+ * refresh token rotates on every use, so a stolen one is detectable when the
+ * original is presented again.
+ *
+ * One shape for both identity spaces: a session is a session, and the claims
+ * inside the token are what differ.
+ */
+export declare const sessionTokens: z.ZodObject<{
+    access_token: z.ZodString;
+    refresh_token: z.ZodString;
+    expires_in: z.ZodNumber;
+}, z.core.$strip>;
+export type SessionTokens = z.infer<typeof sessionTokens>;
+export declare const refreshRequest: z.ZodObject<{
+    refresh_token: z.ZodString;
+}, z.core.$strip>;
+export type RefreshRequest = z.infer<typeof refreshRequest>;
+/**
+ * Registering an org creates the org and its first owner in one step
+ * (André, 2026-08-10): whoever registers the organisation is the owner.
+ */
+export declare const signUpRequest: z.ZodObject<{
+    org_name: z.ZodString;
+    email: z.ZodEmail;
+    password: z.ZodString;
+}, z.core.$strip>;
+export type SignUpRequest = z.infer<typeof signUpRequest>;
+/**
+ * Registering answers with the founding **Fleetless user**, tier `owner`.
+ *
+ * The key is `user` rather than `member` or `owner`, and it has stayed `user`
+ * through two identity redesigns deliberately: a renamed shape under a
+ * renamed key would typecheck in every consumer that reads `.user.id` and mean
+ * something subtly different, which is the quietest way for a cut like this to
+ * go wrong.
+ */
+export declare const signUpResponse: z.ZodObject<{
+    org: z.ZodObject<{
+        id: z.ZodUUID;
+        name: z.ZodString;
+        created_at: z.ZodISODateTime;
+    }, z.core.$strip>;
+    user: z.ZodObject<{
+        id: z.ZodUUID;
+        org_id: z.ZodUUID;
+        email: z.ZodEmail;
+        display_name: z.ZodNullable<z.ZodString>;
+        tier: z.ZodEnum<{
+            owner: "owner";
+            developer: "developer";
+        }>;
+        created_at: z.ZodISODateTime;
+    }, z.core.$strip>;
+    tokens: z.ZodObject<{
+        access_token: z.ZodString;
+        refresh_token: z.ZodString;
+        expires_in: z.ZodNumber;
+    }, z.core.$strip>;
+}, z.core.$strip>;
+export type SignUpResponse = z.infer<typeof signUpResponse>;
+/**
+ * The landing page's waiting list (public site, 2026-09-04): one address,
+ * posted from fleetless.dev while sign-up is closed. The route answers
+ * `202` whether or not the address was already listed.
+ *
+ * The address is bounded at 254 characters, the RFC 5321 forward-path limit.
+ * `z.email()` alone is length-unbounded, and `waitlist.email` carries a unique
+ * btree index, which raises above roughly 2704 bytes — so an unbounded address
+ * turns an unauthenticated public route into a `500`.
+ */
+export declare const waitlistRequest: z.ZodObject<{
+    email: z.ZodEmail;
+}, z.core.$strip>;
+export type WaitlistRequest = z.infer<typeof waitlistRequest>;
+/**
+ * Console login. Fleetless users only, always the Fleetless password — the
+ * console has no federated door at all (D1), which removes the IdP-lockout
+ * class entirely.
+ *
+ * This resolves a person by address alone, and a Fleetless user's email is
+ * **globally unique**, so a bare address names at most one account and no org
+ * context is needed to disambiguate. An org selector was never needed and
+ * would have told an unauthenticated caller which org an address belongs to.
+ *
+ * **It cannot be reached by an app user**, whatever their address: the two
+ * spaces have separate tables and separate routes, and a credential from one
+ * never authenticates the other.
+ */
+export declare const developerLoginRequest: z.ZodObject<{
+    email: z.ZodEmail;
+    password: z.ZodString;
+}, z.core.$strip>;
+export type DeveloperLoginRequest = z.infer<typeof developerLoginRequest>;
+/**
+ * What happened to the mail, in four words instead of one (W6c).
+ *
+ * `mail_sent: boolean` could not tell **"we have no SMTP configured"** from
+ * **"we tried and the server refused"**, so the console had to pick a sentence
+ * for a cause it could not know — and picked the reassuring one, because a
+ * link-only invitation is a normal outcome and a bounced one is not. The two
+ * need opposite actions from whoever reads them: configure a mail server, or
+ * go and look at why the existing one rejected the message.
+ *
+ * - `sent`           — the SMTP server accepted the message. Not "delivered":
+ *                      no sender can promise that, and this value must never
+ *                      be rendered as if it could.
+ * - `not_requested`  — no mail was attempted: the caller asked for none
+ *                      (`send_mail: false`), or there was no link for one to
+ *                      carry (the app has configured no `invite_url`, which
+ *                      the `null` `accept_url` beside it says). **A fourth
+ *                      word rather than a reuse of `not_configured`**: the
+ *                      deployment's mailer is irrelevant in both cases, and a
+ *                      console reading "mail server not configured" beside an
+ *                      invitation whose mail checkbox was off would send a
+ *                      developer to fix something that is not broken.
+ * - `not_configured` — no SMTP is set up. **An expected state, not a failure**
+ *                      (invitations work without mail; the link is the primary
+ *                      path). The console must not show it as an error.
+ * - `failed`         — SMTP was configured, was tried, and refused or was
+ *                      unreachable. This one is worth someone's attention.
+ *
+ * Shared with `appInvitation`, which answers the same four facts about the
+ * same mailer.
+ */
+export declare const mailStatus: z.ZodEnum<{
+    sent: "sent";
+    not_requested: "not_requested";
+    not_configured: "not_configured";
+    failed: "failed";
+}>;
+export type MailStatus = z.infer<typeof mailStatus>;
+/**
+ * **Inviting somebody onto the team** — the only way a Fleetless user appears.
+ *
+ * `tier` is **required**, and that is the one decision this shape exists to
+ * force. An optional tier would make *"I did not think about it"* and *"I meant
+ * developer"* the same request, on the field that decides who can remove whom.
+ * Inviting an owner is owner-only, checked by the route: the response hands
+ * back the accept link, so an owner-tier invitation is a promotion with one
+ * extra step.
+ */
+export declare const createTeamInviteRequest: z.ZodObject<{
+    email: z.ZodEmail;
+    display_name: z.ZodOptional<z.ZodNullable<z.ZodString>>;
+    tier: z.ZodEnum<{
+        owner: "owner";
+        developer: "developer";
+    }>;
+    send_mail: z.ZodBoolean;
+}, z.core.$strict>;
+export type CreateTeamInviteRequest = z.infer<typeof createTeamInviteRequest>;
+/**
+ * The invitation as issued. The **link is the primary path** and mail is the
+ * second, so this is complete and usable with `mail: 'not_configured'` — a
+ * deployment with no SMTP still issues invitations, it just cannot send them
+ * and says so.
+ */
+export declare const teamInvite: z.ZodObject<{
+    id: z.ZodUUID;
+    email: z.ZodEmail;
+    tier: z.ZodEnum<{
+        owner: "owner";
+        developer: "developer";
+    }>;
+    expires_at: z.ZodISODateTime;
+    accept_url: z.ZodURL;
+    mail: z.ZodEnum<{
+        sent: "sent";
+        not_requested: "not_requested";
+        not_configured: "not_configured";
+        failed: "failed";
+    }>;
+}, z.core.$strip>;
+export type TeamInvite = z.infer<typeof teamInvite>;
+/**
+ * A pending invitation as the team sees it in the list — **without its
+ * `accept_url`**, and that omission is the point.
+ *
+ * The list exists so a team can see what is outstanding and revoke it. Neither
+ * needs the token, and a list that carries it turns every screenshot, every log
+ * line and every browser history entry of that page into live credentials for
+ * somebody else's account. It is the same rule `auditEvent.details` already
+ * states — never credentials, never tokens — applied to a read surface.
+ *
+ * There is no escalation either way: an owner can already create an invitation
+ * for any address. The reason to withhold it is not what an owner could do with
+ * it, but that a page nobody thinks of as sensitive stops being sensitive.
+ *
+ * `mail` is omitted for a duller reason: it described what happened at creation
+ * time, and re-serving it in a list invites a reader to take it as current.
+ */
+export declare const pendingTeamInvite: z.ZodObject<{
+    id: z.ZodUUID;
+    email: z.ZodEmail;
+    tier: z.ZodEnum<{
+        owner: "owner";
+        developer: "developer";
+    }>;
+    expires_at: z.ZodISODateTime;
+}, z.core.$strip>;
+export type PendingTeamInvite = z.infer<typeof pendingTeamInvite>;
+export declare const pendingTeamInviteListResponse: z.ZodObject<{
+    invitations: z.ZodArray<z.ZodObject<{
+        id: z.ZodUUID;
+        email: z.ZodEmail;
+        tier: z.ZodEnum<{
+            owner: "owner";
+            developer: "developer";
+        }>;
+        expires_at: z.ZodISODateTime;
+    }, z.core.$strip>>;
+}, z.core.$strip>;
+export type PendingTeamInviteListResponse = z.infer<typeof pendingTeamInviteListResponse>;
+/** Accepting it: the token proves the invitation, the password creates the login. */
+export declare const acceptTeamInviteRequest: z.ZodObject<{
+    token: z.ZodString;
+    password: z.ZodString;
+}, z.core.$strict>;
+export type AcceptTeamInviteRequest = z.infer<typeof acceptTeamInviteRequest>;
+/**
+ * `PATCH /api/org/users/:id` — **what an admin may change about a team member,
+ * and the two things that are absent rather than merely un-required.**
+ *
+ * `email` is not here. It is the identifier of the account, the value every
+ * invitation, reset link and audit line names, and a PATCH that could change it
+ * is both an account-takeover surface and a uniqueness race. *Immutable after
+ * create* is a sentence a strict schema can actually keep: offering `email` is
+ * a refusal, not a silently ignored field — which is the failure mode this
+ * project has already paid for once (`toHaveBeenCalledWith` could not tell
+ * *field sent* from *field missing*).
+ *
+ * `tier` is not here either. A tier change is owner-only with a last-owner
+ * guard (`tierChangeRequest`), and merging it in would give one route two
+ * refusal reasons and one audit event.
+ *
+ * So exactly one field remains, and the shape is kept rather than collapsed
+ * into a bare string: the next thing a team member gains will be optional here,
+ * and a route whose body is a naked value has nowhere to put it.
+ */
+export declare const patchFleetlessUserRequest: z.ZodObject<{
+    display_name: z.ZodOptional<z.ZodNullable<z.ZodString>>;
+}, z.core.$strict>;
+export type PatchFleetlessUserRequest = z.infer<typeof patchFleetlessUserRequest>;
+/**
+ * `PUT /api/org/users/:id/tier` — **owner-only, and the last owner is
+ * neither demotable nor deletable** (refused with 409 `last_owner`).
+ *
+ * `tier_required` keeps its exact semantics — it says what the *caller's* tier
+ * is and what was needed, and nothing about the target.
+ */
+export declare const tierChangeRequest: z.ZodObject<{
+    tier: z.ZodEnum<{
+        owner: "owner";
+        developer: "developer";
+    }>;
+}, z.core.$strict>;
+export type TierChangeRequest = z.infer<typeof tierChangeRequest>;
+/**
+ * What a `forbidden` refusal carries when the reason is the caller's **tier**
+ * rather than a missing grant (W6c).
+ *
+ * §3.3 makes `forbidden` deliberately silent about *existence*, and that stays
+ * true — this says nothing about what the target is. But "your role does not
+ * permit this" and "there is no such thing" are the same answer today, and a
+ * developer cannot tell *ask an owner* from *you have the wrong id*. Naming
+ * the required tier reveals only what the caller could read off the docs.
+ */
+export declare const tierRequiredDetails: z.ZodObject<{
+    required: z.ZodEnum<{
+        owner: "owner";
+        developer: "developer";
+    }>;
+    actual: z.ZodEnum<{
+        owner: "owner";
+        developer: "developer";
+    }>;
+}, z.core.$strip>;
+export type TierRequiredDetails = z.infer<typeof tierRequiredDetails>;
+/**
+ * Changing your own password while logged in.
+ *
+ * `current_password` is required even though the session already proves
+ * identity: it is what makes a stolen *session* insufficient to take the
+ * *account*. Every other session is revoked on success; the one that made the
+ * change survives, because logging someone out of the tab they just used is
+ * indistinguishable from the change having failed.
+ *
+ * Shared with the app-user surface (`POST /api/client/password/change`): the
+ * argument is about credentials and sessions, not about which space the person
+ * lives in.
+ */
+export declare const passwordChangeRequest: z.ZodObject<{
+    current_password: z.ZodString;
+    new_password: z.ZodString;
+}, z.core.$strip>;
+export type PasswordChangeRequest = z.infer<typeof passwordChangeRequest>;
+/**
+ * Asking for a reset link, **as a Fleetless user**.
+ *
+ * **The response never says whether the address exists.** It is unauthenticated
+ * and would otherwise be an account-enumeration oracle — the one place where
+ * §3.3's "reveal nothing about what exists" is not a preference but the whole
+ * point. So this answers the same way for a known and an unknown address, in
+ * status, body **and timing**, and any consumer that renders "no such account"
+ * from it has reintroduced the oracle.
+ *
+ * A bare address resolves to at most one account: a Fleetless user's email is
+ * **globally unique**, so the reset mails the one match, if any, with a token
+ * bound to that account.
+ *
+ * The app-user equivalent is `clientPasswordResetRequest` in `client-auth.ts`
+ * and carries an `app_identifier`, because on that surface a person is
+ * identified by app *and* address. Two shapes rather than one, because the two
+ * surfaces identify a person differently — not because the reasoning differs.
+ */
+export declare const passwordResetRequest: z.ZodObject<{
+    email: z.ZodEmail;
+}, z.core.$strip>;
+export type PasswordResetRequest = z.infer<typeof passwordResetRequest>;
+/**
+ * Using the link. The token is **single-use and expires**; spending it revokes
+ * every session of that subject, because a forgotten password is one of the
+ * two states where somebody else may be holding one. `token_spent` covers used
+ * and expired alike — telling them apart tells a stranger whether a token ever
+ * existed.
+ */
+export declare const passwordResetConfirm: z.ZodObject<{
+    token: z.ZodString;
+    new_password: z.ZodString;
+}, z.core.$strip>;
+export type PasswordResetConfirm = z.infer<typeof passwordResetConfirm>;
+/**
+ * An IdP issuer URL — **an attacker-supplied string that decides where the
+ * *server* connects.**
+ *
+ * `redirectUri` in `oauth.ts` got a parsed scheme check and an explicit
+ * loopback allow-list, with the reasoning written down, because it decides
+ * where a *credential* goes. This field got `z.url()` — in the same file, in
+ * the same wave. Argus-W7b found it and stored `file:///etc/passwd`,
+ * `http://169.254.169.254/latest/meta-data` and `http://infra-postgres-1:5432`
+ * through the app's IdP route, then caught the outbound discovery fetch on a
+ * listener he stood up. **That is this project's own question — which rules
+ * have we already written down, and where else do they apply — answered badly,
+ * one field over.**
+ *
+ * **What this shape can decide, it now decides:** http(s) only (so no `file:`,
+ * `gopher:`, `data:`), no credentials in the URL, no fragment, no query. RFC
+ * 8414 §3 builds the discovery URL from the issuer's path, so a query string
+ * there is meaningless and a `@` is a redirect trick.
+ *
+ * **What it cannot decide, stated rather than implied:** it cannot tell
+ * `http://localhost:8081/realms/fleetless-test` — the dev IdP this project
+ * ships — from `http://127.0.0.1:5432`. Both are loopback http. So **this is
+ * not the SSRF defence and must not be mistaken for one.** The defence belongs
+ * at the fetch, in the cloud: refuse loopback, link-local and private ranges
+ * unless something explicitly opts in for development, and it names DNS
+ * rebinding as its own residual. A schema that quietly looked sufficient here
+ * would be worse than one that says where the real check has to live.
+ *
+ * It lives in this file rather than beside its one consumer because it is a
+ * rule about URLs the server dereferences, and the next such field should find
+ * it already written down. `appOidcProvider` is that consumer today.
+ */
+export declare const idpIssuer: z.ZodURL;
+export type IdpIssuer = z.infer<typeof idpIssuer>;
+/**
+ * **The federated callback error vocabulary is deleted, with no successor
+ * here.** `oidcCallbackErrorCode` and `oidcCallbackError` described the page
+ * `GET /mcp/oauth/idp-callback` rendered when a group's identity provider sent
+ * a browser back — `jit_disabled` and `email_collision` name provisioning steps
+ * only a group provider had. D1 makes Fleetless users password-only and deletes
+ * group providers, so the flow that produced these codes cannot start; the
+ * route is gone from this manifest and from the cloud.
+ *
+ * The per-app OIDC vocabulary is `clientOidcErrorCode` in `client-auth.ts`: a
+ * different list, for a different flow, redirected to the developer's own page
+ * rather than rendered by Fleetless. Two callback error enums coexisting is how
+ * the wrong one gets picked up by the train that adds per-app OIDC, which is
+ * why this one is deleted rather than left standing for it.
+ */
+/**
+ * `GET /api/auth/me` — named so the console can validate it.
+ *
+ * `user` is a `fleetlessUser`, and its `tier` is required, so this response
+ * always states the caller's console powers. It used to be an `orgUser` whose
+ * tier was optional and *always present in practice on this route* — a
+ * guarantee the route made and the schema could not, which is exactly the kind
+ * of gap this file keeps finding. The two-space cut closed it by making the
+ * field required on the shape itself.
+ */
+export declare const authMeResponse: z.ZodObject<{
+    org: z.ZodObject<{
+        id: z.ZodUUID;
+        name: z.ZodString;
+        created_at: z.ZodISODateTime;
+    }, z.core.$strip>;
+    user: z.ZodObject<{
+        id: z.ZodUUID;
+        org_id: z.ZodUUID;
+        email: z.ZodEmail;
+        display_name: z.ZodNullable<z.ZodString>;
+        tier: z.ZodEnum<{
+            owner: "owner";
+            developer: "developer";
+        }>;
+        created_at: z.ZodISODateTime;
+    }, z.core.$strip>;
+}, z.core.$strip>;
+export type AuthMeResponse = z.infer<typeof authMeResponse>;
+/** `PATCH /api/org` — rename the org. Owner only. Same bounds as signup's `org_name`. */
+export declare const patchOrgRequest: z.ZodObject<{
+    name: z.ZodString;
+}, z.core.$strict>;
+export type PatchOrgRequest = z.infer<typeof patchOrgRequest>;
+/** `PATCH /api/auth/me` — the caller updates their own display name (null clears it). */
+export declare const patchAuthMeRequest: z.ZodObject<{
+    display_name: z.ZodNullable<z.ZodString>;
+}, z.core.$strict>;
+export type PatchAuthMeRequest = z.infer<typeof patchAuthMeRequest>;