@fleetless/contracts 5.3.0-next.1 → 6.0.0-next.2

package/dist/identity.d.ts

@@ -7,9 +7,10 @@ import { z } from 'zod';
  * 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.
+ *   console. Email globally unique, tier `owner | developer`, sign-in through
+ *   the auth portal by a code mailed to them or by a passkey — **no
+ *   password** — with an optional second factor the organisation may require.
+ *   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.
@@ -24,25 +25,31 @@ import { z } from 'zod';
  * the two populations have different lifecycles, and every joining mechanism
  * 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.
+ * What did **not** change: the session and token shapes, and the
+ * enumeration-oracle reasoning. Neither was ever a statement about which space
+ * a person lived in.
+ *
+ * **Developers have no password any more.** They sign in with a six-digit
+ * code mailed to them, or with a passkey, which proves possession and user
+ * verification at once and so completes a sign-in on its own. After a code,
+ * a developer with a second factor — a passkey or an authenticator app —
+ * gives it; ten recovery codes are the fallback. The password sign-in, the
+ * password change, the reset pages and `POST /api/auth/signup` are gone: the
+ * portal's sign-up (email, code, organisation) is the one door 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.
+ * one address is exactly one Fleetless user in exactly one org. A bare address
+ * 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.
+ * App users only: Fleetless users sign in by emailed code or passkey and hold
+ * no password.
  */
 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. */
@@ -70,6 +77,7 @@ export type OrgAdminTier = z.infer<typeof orgAdminTier>;
 export declare const org: z.ZodObject<{
     id: z.ZodUUID;
     name: z.ZodString;
+    require_two_factor: z.ZodBoolean;
     created_at: z.ZodISODateTime;
 }, z.core.$strip>;
 export type Org = z.infer<typeof org>;
@@ -78,13 +86,14 @@ export declare const patchOrgResponse: z.ZodObject<{
     org: z.ZodObject<{
         id: z.ZodUUID;
         name: z.ZodString;
+        require_two_factor: z.ZodBoolean;
         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.
+ * **A member of the org's team.** Console access, a tier, a sign-in by
+ * emailed code or passkey, 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
@@ -95,10 +104,10 @@ export type PatchOrgResponse = z.infer<typeof patchOrgResponse>;
  * 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, which removes the
- * IdP-lockout class entirely, so a field reporting whether the credential
- * exists would have exactly one value forever.
+ * provider and hold no Fleetless credential. Every Fleetless user signs in by
+ * a code mailed to their address, so the console has no federated door and
+ * no IdP-lockout class, and a field about a password would describe nothing.
+ * What varies is the second factor, which `two_factor` reports.
  */
 export declare const fleetlessUser: z.ZodObject<{
     id: z.ZodUUID;
@@ -109,6 +118,10 @@ export declare const fleetlessUser: z.ZodObject<{
         owner: "owner";
         developer: "developer";
     }>;
+    two_factor: z.ZodObject<{
+        passkeys: z.ZodNumber;
+        authenticator: z.ZodBoolean;
+    }, z.core.$strip>;
     created_at: z.ZodISODateTime;
 }, z.core.$strip>;
 export type FleetlessUser = z.infer<typeof fleetlessUser>;
@@ -123,6 +136,10 @@ export declare const fleetlessUserListResponse: z.ZodObject<{
             owner: "owner";
             developer: "developer";
         }>;
+        two_factor: z.ZodObject<{
+            passkeys: z.ZodNumber;
+            authenticator: z.ZodBoolean;
+        }, z.core.$strip>;
         created_at: z.ZodISODateTime;
     }, z.core.$strip>>;
 }, z.core.$strip>;
@@ -146,48 +163,35 @@ export declare const refreshRequest: z.ZodObject<{
 }, z.core.$strip>;
 export type RefreshRequest = z.infer<typeof refreshRequest>;
 /**
- * Registering an org creates the org and its first owner in one step: whoever
- * registers the organisation is the owner.
+ * **A six-digit code**: the emailed sign-in code (valid ten minutes, five
+ * wrong attempts) and an authenticator's time-based code alike. Exactly six
+ * digits on the wire, leading zeros included — the portal and hosted forms
+ * strip spaces before they send it, the JSON API does not.
  */
-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>;
+export declare const loginCode: z.ZodString;
+/** An authenticator app's code (TOTP, RFC 6238: SHA-1, six digits, thirty-second steps). The same shape as `loginCode`. */
+export declare const totpCode: z.ZodString;
 /**
- * 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.
+ * **A recovery code as typed**: two groups of five base32 characters,
+ * `xxxxx-xxxxx`, in either case — the cloud lower-cases before it compares.
+ * Single use.
  */
-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>;
+export declare const recoveryCode: z.ZodString;
+/**
+ * **The ten recovery codes, as issued**: lowercase, shown once. Generating a
+ * new set voids the old one.
+ */
+export declare const recoveryCodesList: z.ZodArray<z.ZodString>;
+/**
+ * **An authenticator being set up**: the secret to type in, and the same
+ * secret as an `otpauth://` URL for a QR code. Nothing is stored as
+ * confirmed until a code from it is confirmed.
+ */
+export declare const twoFactorSetupResponse: z.ZodObject<{
+    secret: z.ZodString;
+    otpauth_url: z.ZodString;
 }, z.core.$strip>;
-export type SignUpResponse = z.infer<typeof signUpResponse>;
+export type TwoFactorSetupResponse = z.infer<typeof twoFactorSetupResponse>;
 /**
  * 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,25 +206,6 @@ 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, 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.
  *
@@ -235,11 +220,9 @@ export type DeveloperLoginRequest = z.infer<typeof developerLoginRequest>;
  *                      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
+ *                      (`send_mail: false`). **A fourth word rather than a
+ *                      reuse of `not_configured`**: the deployment's mailer
+ *                      is irrelevant there, 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.
@@ -341,10 +324,14 @@ export declare const pendingTeamInviteListResponse: z.ZodObject<{
     }, 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. */
+/**
+ * Accepting it: the token proves the invitation, and the mailed link proves
+ * the address, so accepting needs no code and takes **no password** — the
+ * new member signs in by emailed code from then on.
+ */
 export declare const acceptTeamInviteRequest: z.ZodObject<{
     token: z.ZodString;
-    password: z.ZodString;
+    display_name: z.ZodOptional<z.ZodNullable<z.ZodString>>;
 }, z.core.$strict>;
 export type AcceptTeamInviteRequest = z.infer<typeof acceptTeamInviteRequest>;
 /**
@@ -407,58 +394,20 @@ export declare const tierRequiredDetails: z.ZodObject<{
 }, z.core.$strip>;
 export type TierRequiredDetails = z.infer<typeof tierRequiredDetails>;
 /**
- * Changing your own password while logged in.
+ * An app user changing their own password while signed in
+ * (`POST /api/client/password/change`). Fleetless users have no password.
  *
  * `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
- * revealing 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.**
@@ -494,8 +443,8 @@ export type IdpIssuer = z.infer<typeof idpIssuer>;
  * 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. Fleetless users are password-only now, which deletes
- * group providers, so the flow that produced these codes cannot start; the
+ * only a group provider had. Fleetless users sign in by emailed code or
+ * passkey, with no 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
@@ -518,6 +467,7 @@ export declare const authMeResponse: z.ZodObject<{
     org: z.ZodObject<{
         id: z.ZodUUID;
         name: z.ZodString;
+        require_two_factor: z.ZodBoolean;
         created_at: z.ZodISODateTime;
     }, z.core.$strip>;
     user: z.ZodObject<{
@@ -529,13 +479,22 @@ export declare const authMeResponse: z.ZodObject<{
             owner: "owner";
             developer: "developer";
         }>;
+        two_factor: z.ZodObject<{
+            passkeys: z.ZodNumber;
+            authenticator: z.ZodBoolean;
+        }, z.core.$strip>;
         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`. */
+/**
+ * `PATCH /api/org` — rename the org, require two-factor for its members, or
+ * both. Owner only. At least one field: an empty patch is a refusal rather
+ * than a write that changed nothing.
+ */
 export declare const patchOrgRequest: z.ZodObject<{
-    name: z.ZodString;
+    name: z.ZodOptional<z.ZodString>;
+    require_two_factor: z.ZodOptional<z.ZodBoolean>;
 }, z.core.$strict>;
 export type PatchOrgRequest = z.infer<typeof patchOrgRequest>;
 /** `PATCH /api/auth/me` — the caller updates their own display name (null clears it). */
@@ -543,3 +502,91 @@ export declare const patchAuthMeRequest: z.ZodObject<{
     display_name: z.ZodNullable<z.ZodString>;
 }, z.core.$strict>;
 export type PatchAuthMeRequest = z.infer<typeof patchAuthMeRequest>;
+/**
+ * **A WebAuthn JSON document, opaque here.** The `PublicKeyCredential*JSON`
+ * shapes of the WebAuthn Level 3 specification — creation and request options
+ * going out, the browser's credential coming back. The browser API and the
+ * server library define them; a second, hand-written copy here would be one
+ * that drifts.
+ */
+export declare const webauthnJson: z.ZodRecord<z.ZodString, z.ZodUnknown>;
+/**
+ * **Options for a WebAuthn ceremony**, to hand to the browser as they are.
+ * The relying party is `fleetless.dev`, so the auth portal and the console
+ * both accept the same passkey; user verification is required.
+ */
+export declare const webauthnOptionsResponse: z.ZodObject<{
+    options: z.ZodRecord<z.ZodString, z.ZodUnknown>;
+}, z.core.$strip>;
+export type WebauthnOptionsResponse = z.infer<typeof webauthnOptionsResponse>;
+/** **One registered passkey**, as Settings › Profile lists it. No key material travels here. */
+export declare const developerPasskey: z.ZodObject<{
+    id: z.ZodUUID;
+    name: z.ZodString;
+    created_at: z.ZodISODateTime;
+    last_used_at: z.ZodNullable<z.ZodISODateTime>;
+    synced: z.ZodNullable<z.ZodBoolean>;
+}, z.core.$strip>;
+export type DeveloperPasskey = z.infer<typeof developerPasskey>;
+/** **`GET /api/auth/two-factor`** — the caller's own second factors, in full. */
+export declare const developerTwoFactor: z.ZodObject<{
+    passkeys: z.ZodArray<z.ZodObject<{
+        id: z.ZodUUID;
+        name: z.ZodString;
+        created_at: z.ZodISODateTime;
+        last_used_at: z.ZodNullable<z.ZodISODateTime>;
+        synced: z.ZodNullable<z.ZodBoolean>;
+    }, z.core.$strip>>;
+    authenticator: z.ZodNullable<z.ZodObject<{
+        created_at: z.ZodISODateTime;
+    }, z.core.$strip>>;
+    recovery_codes_left: z.ZodNumber;
+    required_by_org: z.ZodBoolean;
+}, z.core.$strip>;
+export type DeveloperTwoFactor = z.infer<typeof developerTwoFactor>;
+/** **Registering a passkey**: the name, and the browser's answer to the creation options. */
+export declare const createPasskeyRequest: z.ZodObject<{
+    name: z.ZodString;
+    credential: z.ZodRecord<z.ZodString, z.ZodUnknown>;
+}, z.core.$strict>;
+export type CreatePasskeyRequest = z.infer<typeof createPasskeyRequest>;
+/**
+ * **The registered passkey**, and the ten recovery codes when it is the
+ * account's first second factor — `null` otherwise, since the existing codes
+ * stay valid.
+ */
+export declare const createPasskeyResponse: z.ZodObject<{
+    passkey: z.ZodObject<{
+        id: z.ZodUUID;
+        name: z.ZodString;
+        created_at: z.ZodISODateTime;
+        last_used_at: z.ZodNullable<z.ZodISODateTime>;
+        synced: z.ZodNullable<z.ZodBoolean>;
+    }, z.core.$strip>;
+    recovery_codes: z.ZodNullable<z.ZodArray<z.ZodString>>;
+}, z.core.$strip>;
+export type CreatePasskeyResponse = z.infer<typeof createPasskeyResponse>;
+/** **Renaming a passkey.** The name is the only thing about one that can change. */
+export declare const renamePasskeyRequest: z.ZodObject<{
+    name: z.ZodString;
+}, z.core.$strict>;
+export type RenamePasskeyRequest = z.infer<typeof renamePasskeyRequest>;
+/** **Confirming a new authenticator** with a code it shows now. */
+export declare const totpConfirmRequest: z.ZodObject<{
+    code: z.ZodString;
+}, z.core.$strict>;
+export type TotpConfirmRequest = z.infer<typeof totpConfirmRequest>;
+/**
+ * **The confirmed authenticator.** Ten recovery codes when it is the
+ * account's first second factor; `null` when it replaces an authenticator or
+ * joins passkeys, whose codes stay valid.
+ */
+export declare const totpConfirmResponse: z.ZodObject<{
+    recovery_codes: z.ZodNullable<z.ZodArray<z.ZodString>>;
+}, z.core.$strip>;
+export type TotpConfirmResponse = z.infer<typeof totpConfirmResponse>;
+/** **A fresh set of ten recovery codes**, shown once. The previous set stops working. */
+export declare const recoveryCodesResponse: z.ZodObject<{
+    recovery_codes: z.ZodArray<z.ZodString>;
+}, z.core.$strip>;
+export type RecoveryCodesResponse = z.infer<typeof recoveryCodesResponse>;