apiblaze 0.20.21 → 0.20.23

package/dist/index.js

@@ -1024,7 +1024,7 @@ var import_commander = require("commander");
 var import_chalk54 = __toESM(require("chalk"));
 
 // package.json
-var version = "0.20.21";
+var version = "0.20.23";
 
 // src/index.ts
 init_types();
@@ -3751,7 +3751,12 @@ async function openServerProxy(project) {
     proxyUrl: `https://${project.projectId}.abz.run/${version2}/${environment}`,
     anon: false,
     // Reusing an owned proxy: logged-in apichat doors default to invite-only.
-    access: "invite"
+    access: "invite",
+    // Identity domain — needed to authorize an external client's registration
+    // (and by anything else that acts on the tenant). Dropping these made the
+    // registration authorization silently skip.
+    tenant: tenant2,
+    teamId: project.teamId
   };
   const spinner = (0, import_ora4.default)("Preparing the chat\u2026").start();
   try {
@@ -3925,7 +3930,12 @@ async function noArgsMenu(opts) {
       proxyUrl: void 0,
       anon: a.anon,
       // Saved sessions predate the access field: mirror the provisioning default.
-      access: a.anon ? "open" : "invite"
+      access: a.anon ? "open" : "invite",
+      // The tenant we just re-derived above (and the owning team): without them
+      // the registration authorization can't name a tenant and silently skips.
+      tenant: savedTenant,
+      teamId: resumeTeamId,
+      endUserId: a.endUserId
     };
     return { p, messages };
   }
@@ -4157,10 +4167,15 @@ async function authorizeClientRegistration(p, cliLabel) {
   if (!p.consumerAuth) return;
   const teamId = p.teamId ?? loadCredentials()?.teamId;
   const tenant2 = p.tenant;
-  if (!teamId || !tenant2) return;
+  if (!teamId || !tenant2) {
+    console.log(import_chalk14.default.dim(`  (Can't pre-authorize ${cliLabel}'s registration \u2014 tenant unknown for this proxy. If sign-in says the app needs verifying: apiblaze allowoauthregistration --tenant <slug>, then retry.)`));
+    return;
+  }
   const ok = await openRegistrationAuthorization(teamId, tenant2, 600);
   if (ok) {
     console.log(import_chalk14.default.dim(`  Authorized ${cliLabel}'s sign-in registration on tenant ${import_chalk14.default.bold(tenant2)} (single use).`));
+  } else {
+    console.log(import_chalk14.default.yellow(`  Could not pre-authorize the registration on ${tenant2} \u2014 if sign-in says the app needs verifying, run: apiblaze allowoauthregistration --tenant ${tenant2}`));
   }
 }
 async function ensureInstallableDoor(p, opts) {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "apiblaze",
-  "version": "0.20.21",
+  "version": "0.20.23",
   "description": "APIblaze CLI — Chat with your APIs, Manage your API keys, users and groups with the APIblaze serverless proxy",
   "keywords": [
     "apiblaze",

package/dist/react/index.d.mts

@@ -1,205 +0,0 @@
-import * as React from 'react';
-
-/**
- * apiblaze/react — <UsersGroupsWidget/>. Drop it into your site next to (or
- * instead of) <ApiKeyWidget/>; it talks ONLY to your own backend route (which
- * holds the same one CP widget key, mounted via createApiblazeGroups().handler).
- *
- *   import { UsersGroupsWidget } from 'apiblaze/react';
- *   <UsersGroupsWidget theme={{ accent: '#e11d48' }} />
- *
- * Who sees what: apiblaze authorizes the LOGGED-IN USER server-side — only a
- * tenant admin (an email on the tenant's admin-emails allowlist) can manage.
- * Anyone else gets the "admin access pending" panel; nothing in this component
- * (or your page) can elevate them.
- *
- * Default view = flat groups + members (the right ceiling for a handful of
- * admins). Delegation (per-group admins) and nesting (subgroups) are there,
- * one level down. Strictly users + groups — no authorization-rule authoring.
- *
- * `endpoint` defaults to /api/apiblaze/groups.
- */
-
-type UsersGroupsWidgetTheme = ApiKeyWidgetTheme;
-interface UsersGroupsWidgetProps {
-    endpoint?: string;
-    theme?: UsersGroupsWidgetTheme;
-    /** Heading text. Default "Users & groups". */
-    title?: string;
-    /** Auto-expand the group with this NAME on first load (if it exists) — e.g.
-     *  a demo landing the user on the group it just talked about. One-shot: the
-     *  user can still collapse it; later refreshes don't force it back open. */
-    defaultOpenGroup?: string;
-    className?: string;
-}
-interface UsersGroupsWidgetHandle {
-    refresh: () => void;
-}
-declare const UsersGroupsWidget: React.ForwardRefExoticComponent<UsersGroupsWidgetProps & React.RefAttributes<UsersGroupsWidgetHandle>>;
-
-/**
- * apiblaze/react — <ChatWidget/>. The third widget face (with <ApiKeyWidget/>
- * and <UsersGroupsWidget/>): a drop-in AI chat window for an API proxied
- * through APIblaze, speaking the AI SDK UI Message Stream wire protocol
- * (specs/chatwidget/sse/wire-compatibility-with-AI-SDK-UI.MD).
- *
- * Two integration modes (chatwidget_prd.md):
- *
- *   MODE 1 — direct (JWT-door proxy; zero backend code). The end user is
- *   already logged into YOUR site; pass their session token and the proxy
- *   verifies it against the issuer you registered (iam_v2 §4.4):
- *
- *     <ChatWidget project="ninopizza" getToken={() => session.token} />
- *
- *   MODE 2 — relay (api_key-door proxy). Mount createApiblazeChat() from
- *   apiblaze/server (it holds the key server-side) and point the widget at it:
- *
- *     <ChatWidget endpoint="/api/apiblaze/chat" />
- *
- * Zero runtime dependencies, inline styles, white-label through `theme` tokens —
- * the same packaging discipline as the other two widgets. Producers who want a
- * fully custom UI don't need this component at all: the endpoint speaks the
- * standard protocol, so assistant-ui / useChat work directly against it.
- *
- * Safety properties this component RELIES ON (and never re-implements):
- * tool calls execute server-side with the caller's own credential (OpenFGA
- * applies), funding/quotas are the proxy's chat_sponsorship, and the system
- * prompt (+ producer steering) is server-owned — nothing here can change it.
- */
-
-interface ChatWidgetTheme {
-    /** Accent / primary action color (send button, launcher). */
-    accent?: string;
-    /** Text/icon color ON accent surfaces. Default #fff. */
-    accentText?: string;
-    /** Panel body color. */
-    surface?: string;
-    /** Header strip color. Defaults to `surface`. */
-    headerBackground?: string;
-    /** Primary text color. */
-    text?: string;
-    /** Secondary / muted text color. */
-    muted?: string;
-    /** Border + divider color. */
-    border?: string;
-    /** User bubble background / text. */
-    userBubble?: string;
-    userBubbleText?: string;
-    /** Assistant bubble background / text. */
-    assistantBubble?: string;
-    assistantBubbleText?: string;
-    /** Floating launcher colors (bubble mode). */
-    launcherBackground?: string;
-    launcherIcon?: string;
-    /** Corner radius of the panel, e.g. "16px". */
-    radius?: string;
-    /** Body font stack. */
-    fontFamily?: string;
-    /** Monospace stack for code. */
-    monoFontFamily?: string;
-}
-interface ChatWidgetProps {
-    /** MODE 2: your mounted createApiblazeChat() route. */
-    endpoint?: string;
-    /** MODE 1: project handle — the widget talks straight to {project}.mcp.{host}. */
-    project?: string;
-    /** MODE 1: returns the end user's CURRENT session JWT (your own issuer,
-     *  registered on the proxy). Called per message so refreshed tokens win. */
-    getToken?: () => string | Promise<string>;
-    /** MODE 1 extras. */
-    apiVersion?: string;
-    environment?: string;
-    host?: string;
-    /** 'bubble' = floating launcher (default) · 'inline' = a card in your layout. */
-    mode?: 'bubble' | 'inline';
-    /** Heading. Default "Chat". */
-    title?: string;
-    /** Emoji/short avatar in the header + launcher. Default "💬". */
-    avatar?: string;
-    /** First assistant message shown before any exchange. */
-    welcome?: string;
-    /** Suggested prompt chips (≤4 shown). */
-    suggestions?: string[];
-    /** Inline mode panel height. Default 560. */
-    height?: number;
-    /** Bubble mode: offset from the viewport edge, px. Default 20. */
-    offset?: number;
-    /** Bubble mode: z-index of launcher+panel. Default 2147483000. */
-    zIndex?: number;
-    /** Show the "powered by APIblaze" footer credit. Default true. */
-    branding?: boolean;
-    theme?: ChatWidgetTheme;
-    className?: string;
-    /** sessionStorage key override. DEFAULT derives from project/endpoint ONLY —
-     *  on a shared machine that lets the next signed-in user read the previous
-     *  user's transcript in the same tab, so pass a PER-USER key (e.g.
-     *  `apiblaze-chat:myapp:${user.id}`) whenever your page has logins. Two
-     *  widgets with the same key share (and clobber) one transcript. */
-    storageKey?: string;
-    /** Client-side per-message length hint (server enforces its own cap). Default 2000. */
-    maxMessageLength?: number;
-}
-interface ChatWidgetHandle {
-    open: () => void;
-    close: () => void;
-    clear: () => void;
-}
-declare const ChatWidget: React.ForwardRefExoticComponent<ChatWidgetProps & React.RefAttributes<ChatWidgetHandle>>;
-
-/**
- * apiblaze/react — <ApiKeyWidget/>. Drop it into your site (e.g. resiresi.com);
- * it talks ONLY to your own backend route (which holds the CP key). Shows the
- * logged-in user their API keys as a simple list with one always-visible
- * "Create key" action, plus per-key show / rotate / revoke.
- *
- *   import { ApiKeyWidget } from 'apiblaze/react';
- *   <ApiKeyWidget theme={{ accent: '#e11d48' }} />
- *
- * Fully white-labelable through `theme` alone — every font and color is a token,
- * so you can match your brand (including a dark "codebox" look) without forking
- * the component. See ApiKeyWidgetTheme.
- *
- * `endpoint` defaults to /api/apiblaze/keys (where you mounted createApiblazeKeys().handler).
- */
-
-interface ApiKeyWidgetTheme {
-    /** Accent / primary action color. */
-    accent?: string;
-    /** Text/icon color ON accent buttons. Default #fff. */
-    accentText?: string;
-    /** Page color behind the card. Default transparent. */
-    background?: string;
-    /** Card body color. */
-    surface?: string;
-    /** Header strip color. Defaults to `surface` when unset. */
-    headerBackground?: string;
-    /** Primary text color. */
-    text?: string;
-    /** Secondary / muted text color. */
-    muted?: string;
-    /** Border + divider color. */
-    border?: string;
-    /** Destructive (revoke) color. */
-    danger?: string;
-    /** Positive (copied) color. */
-    success?: string;
-    /** Corner radius of the card, e.g. "12px". */
-    radius?: string;
-    /** Body font stack. */
-    fontFamily?: string;
-    /** Monospace font stack for keys and secrets. */
-    monoFontFamily?: string;
-}
-interface ApiKeyWidgetProps {
-    endpoint?: string;
-    theme?: ApiKeyWidgetTheme;
-    /** Heading text. Default "Your API keys". */
-    title?: string;
-    className?: string;
-}
-interface ApiKeyWidgetHandle {
-    refresh: () => void;
-}
-declare const ApiKeyWidget: React.ForwardRefExoticComponent<ApiKeyWidgetProps & React.RefAttributes<ApiKeyWidgetHandle>>;
-
-export { ApiKeyWidget, type ApiKeyWidgetHandle, type ApiKeyWidgetProps, type ApiKeyWidgetTheme, ChatWidget, type ChatWidgetHandle, type ChatWidgetProps, type ChatWidgetTheme, UsersGroupsWidget, type UsersGroupsWidgetHandle, type UsersGroupsWidgetProps, type UsersGroupsWidgetTheme, ApiKeyWidget as default };

package/dist/react/index.d.ts

@@ -1,205 +0,0 @@
-import * as React from 'react';
-
-/**
- * apiblaze/react — <UsersGroupsWidget/>. Drop it into your site next to (or
- * instead of) <ApiKeyWidget/>; it talks ONLY to your own backend route (which
- * holds the same one CP widget key, mounted via createApiblazeGroups().handler).
- *
- *   import { UsersGroupsWidget } from 'apiblaze/react';
- *   <UsersGroupsWidget theme={{ accent: '#e11d48' }} />
- *
- * Who sees what: apiblaze authorizes the LOGGED-IN USER server-side — only a
- * tenant admin (an email on the tenant's admin-emails allowlist) can manage.
- * Anyone else gets the "admin access pending" panel; nothing in this component
- * (or your page) can elevate them.
- *
- * Default view = flat groups + members (the right ceiling for a handful of
- * admins). Delegation (per-group admins) and nesting (subgroups) are there,
- * one level down. Strictly users + groups — no authorization-rule authoring.
- *
- * `endpoint` defaults to /api/apiblaze/groups.
- */
-
-type UsersGroupsWidgetTheme = ApiKeyWidgetTheme;
-interface UsersGroupsWidgetProps {
-    endpoint?: string;
-    theme?: UsersGroupsWidgetTheme;
-    /** Heading text. Default "Users & groups". */
-    title?: string;
-    /** Auto-expand the group with this NAME on first load (if it exists) — e.g.
-     *  a demo landing the user on the group it just talked about. One-shot: the
-     *  user can still collapse it; later refreshes don't force it back open. */
-    defaultOpenGroup?: string;
-    className?: string;
-}
-interface UsersGroupsWidgetHandle {
-    refresh: () => void;
-}
-declare const UsersGroupsWidget: React.ForwardRefExoticComponent<UsersGroupsWidgetProps & React.RefAttributes<UsersGroupsWidgetHandle>>;
-
-/**
- * apiblaze/react — <ChatWidget/>. The third widget face (with <ApiKeyWidget/>
- * and <UsersGroupsWidget/>): a drop-in AI chat window for an API proxied
- * through APIblaze, speaking the AI SDK UI Message Stream wire protocol
- * (specs/chatwidget/sse/wire-compatibility-with-AI-SDK-UI.MD).
- *
- * Two integration modes (chatwidget_prd.md):
- *
- *   MODE 1 — direct (JWT-door proxy; zero backend code). The end user is
- *   already logged into YOUR site; pass their session token and the proxy
- *   verifies it against the issuer you registered (iam_v2 §4.4):
- *
- *     <ChatWidget project="ninopizza" getToken={() => session.token} />
- *
- *   MODE 2 — relay (api_key-door proxy). Mount createApiblazeChat() from
- *   apiblaze/server (it holds the key server-side) and point the widget at it:
- *
- *     <ChatWidget endpoint="/api/apiblaze/chat" />
- *
- * Zero runtime dependencies, inline styles, white-label through `theme` tokens —
- * the same packaging discipline as the other two widgets. Producers who want a
- * fully custom UI don't need this component at all: the endpoint speaks the
- * standard protocol, so assistant-ui / useChat work directly against it.
- *
- * Safety properties this component RELIES ON (and never re-implements):
- * tool calls execute server-side with the caller's own credential (OpenFGA
- * applies), funding/quotas are the proxy's chat_sponsorship, and the system
- * prompt (+ producer steering) is server-owned — nothing here can change it.
- */
-
-interface ChatWidgetTheme {
-    /** Accent / primary action color (send button, launcher). */
-    accent?: string;
-    /** Text/icon color ON accent surfaces. Default #fff. */
-    accentText?: string;
-    /** Panel body color. */
-    surface?: string;
-    /** Header strip color. Defaults to `surface`. */
-    headerBackground?: string;
-    /** Primary text color. */
-    text?: string;
-    /** Secondary / muted text color. */
-    muted?: string;
-    /** Border + divider color. */
-    border?: string;
-    /** User bubble background / text. */
-    userBubble?: string;
-    userBubbleText?: string;
-    /** Assistant bubble background / text. */
-    assistantBubble?: string;
-    assistantBubbleText?: string;
-    /** Floating launcher colors (bubble mode). */
-    launcherBackground?: string;
-    launcherIcon?: string;
-    /** Corner radius of the panel, e.g. "16px". */
-    radius?: string;
-    /** Body font stack. */
-    fontFamily?: string;
-    /** Monospace stack for code. */
-    monoFontFamily?: string;
-}
-interface ChatWidgetProps {
-    /** MODE 2: your mounted createApiblazeChat() route. */
-    endpoint?: string;
-    /** MODE 1: project handle — the widget talks straight to {project}.mcp.{host}. */
-    project?: string;
-    /** MODE 1: returns the end user's CURRENT session JWT (your own issuer,
-     *  registered on the proxy). Called per message so refreshed tokens win. */
-    getToken?: () => string | Promise<string>;
-    /** MODE 1 extras. */
-    apiVersion?: string;
-    environment?: string;
-    host?: string;
-    /** 'bubble' = floating launcher (default) · 'inline' = a card in your layout. */
-    mode?: 'bubble' | 'inline';
-    /** Heading. Default "Chat". */
-    title?: string;
-    /** Emoji/short avatar in the header + launcher. Default "💬". */
-    avatar?: string;
-    /** First assistant message shown before any exchange. */
-    welcome?: string;
-    /** Suggested prompt chips (≤4 shown). */
-    suggestions?: string[];
-    /** Inline mode panel height. Default 560. */
-    height?: number;
-    /** Bubble mode: offset from the viewport edge, px. Default 20. */
-    offset?: number;
-    /** Bubble mode: z-index of launcher+panel. Default 2147483000. */
-    zIndex?: number;
-    /** Show the "powered by APIblaze" footer credit. Default true. */
-    branding?: boolean;
-    theme?: ChatWidgetTheme;
-    className?: string;
-    /** sessionStorage key override. DEFAULT derives from project/endpoint ONLY —
-     *  on a shared machine that lets the next signed-in user read the previous
-     *  user's transcript in the same tab, so pass a PER-USER key (e.g.
-     *  `apiblaze-chat:myapp:${user.id}`) whenever your page has logins. Two
-     *  widgets with the same key share (and clobber) one transcript. */
-    storageKey?: string;
-    /** Client-side per-message length hint (server enforces its own cap). Default 2000. */
-    maxMessageLength?: number;
-}
-interface ChatWidgetHandle {
-    open: () => void;
-    close: () => void;
-    clear: () => void;
-}
-declare const ChatWidget: React.ForwardRefExoticComponent<ChatWidgetProps & React.RefAttributes<ChatWidgetHandle>>;
-
-/**
- * apiblaze/react — <ApiKeyWidget/>. Drop it into your site (e.g. resiresi.com);
- * it talks ONLY to your own backend route (which holds the CP key). Shows the
- * logged-in user their API keys as a simple list with one always-visible
- * "Create key" action, plus per-key show / rotate / revoke.
- *
- *   import { ApiKeyWidget } from 'apiblaze/react';
- *   <ApiKeyWidget theme={{ accent: '#e11d48' }} />
- *
- * Fully white-labelable through `theme` alone — every font and color is a token,
- * so you can match your brand (including a dark "codebox" look) without forking
- * the component. See ApiKeyWidgetTheme.
- *
- * `endpoint` defaults to /api/apiblaze/keys (where you mounted createApiblazeKeys().handler).
- */
-
-interface ApiKeyWidgetTheme {
-    /** Accent / primary action color. */
-    accent?: string;
-    /** Text/icon color ON accent buttons. Default #fff. */
-    accentText?: string;
-    /** Page color behind the card. Default transparent. */
-    background?: string;
-    /** Card body color. */
-    surface?: string;
-    /** Header strip color. Defaults to `surface` when unset. */
-    headerBackground?: string;
-    /** Primary text color. */
-    text?: string;
-    /** Secondary / muted text color. */
-    muted?: string;
-    /** Border + divider color. */
-    border?: string;
-    /** Destructive (revoke) color. */
-    danger?: string;
-    /** Positive (copied) color. */
-    success?: string;
-    /** Corner radius of the card, e.g. "12px". */
-    radius?: string;
-    /** Body font stack. */
-    fontFamily?: string;
-    /** Monospace font stack for keys and secrets. */
-    monoFontFamily?: string;
-}
-interface ApiKeyWidgetProps {
-    endpoint?: string;
-    theme?: ApiKeyWidgetTheme;
-    /** Heading text. Default "Your API keys". */
-    title?: string;
-    className?: string;
-}
-interface ApiKeyWidgetHandle {
-    refresh: () => void;
-}
-declare const ApiKeyWidget: React.ForwardRefExoticComponent<ApiKeyWidgetProps & React.RefAttributes<ApiKeyWidgetHandle>>;
-
-export { ApiKeyWidget, type ApiKeyWidgetHandle, type ApiKeyWidgetProps, type ApiKeyWidgetTheme, ChatWidget, type ChatWidgetHandle, type ChatWidgetProps, type ChatWidgetTheme, UsersGroupsWidget, type UsersGroupsWidgetHandle, type UsersGroupsWidgetProps, type UsersGroupsWidgetTheme, ApiKeyWidget as default };

package/dist/server/index.d.mts

@@ -1,309 +0,0 @@
-/**
- * apiblaze/server — SHARED widget-server substrate.
- *
- * One CP credential, one getUser contract, one ensure-tenant/ensure-user path —
- * consumed by BOTH widget faces (`createApiblazeKeys` and `createApiblazeGroups`).
- * Factored per iam_toolkit_spec ("share, don't fork" — copy-forking this
- * bootstrap is a spec failure).
- *
- * Trust model: the CP key stays server-side and vouches for the CHANNEL; the
- * acting end-user rides X-End-User-Id / X-End-User-Email. On the apikeys plane
- * the end-user header only narrows (self-scoped key ops); on the iam plane it
- * IS the principal (iam-worker independently checks the resolved user's
- * apiblaze_admins membership before any group op).
- */
-interface AppUser {
-    /** The producer's stable id for the consumer COMPANY — becomes the tenant (isolation). */
-    tenant: string;
-    /** The producer's stable id for the PERSON — the acting end-user. */
-    userId: string;
-    /** Optional; REQUIRED in practice for the groups widget — tenant-admin status
-     *  is granted by email (the tenant's admin-emails allowlist). */
-    email?: string;
-    /** Optional display name (cosmetic). */
-    label?: string;
-    /** Key-widget eligibility (see createApiblazeKeys). Ignored by the groups widget. */
-    keyTypes?: string[] | false;
-    /** Any extra fields your eligibility logic wants (e.g. isEngineer). */
-    [k: string]: unknown;
-}
-declare class PlaneError extends Error {
-    status: number;
-    detail: string;
-    constructor(status: number, detail: string);
-}
-
-/**
- * createApiblazeGroups — the server-side half of the Users & Groups widget
- * (<UsersGroupsWidget/>), riding the SAME shared substrate (core.ts) and the
- * SAME one CP widget credential as the API-key widget.
- *
- * Usage (Next.js App Router — app/api/apiblaze/groups/route.ts):
- *
- *   import { createApiblazeGroups } from 'apiblaze/server';
- *   const groups = createApiblazeGroups({
- *     cpKey: process.env.APIBLAZE_CP_KEY!,   // the SAME key the key widget uses
- *     getUser: async () => { ...same contract... return { tenant, userId, email } },
- *   });
- *   export const GET = groups.handler;
- *   export const POST = groups.handler;
- *
- * AUTHORIZATION MODEL (iam_toolkit_spec): unlike key ops (self-scoped), group
- * admin ops are tenant-wide — so the acting END-USER IS THE PRINCIPAL. This
- * server forwards the session user via X-End-User-Id/-Email; apiblaze's iam
- * plane independently verifies that user is a TENANT ADMIN (apiblaze_admins
- * member, granted via the tenant's admin-emails allowlist) before any op. A
- * non-admin gets `access: 'pending'` — nothing here can elevate them, and no
- * producer-side flag can either. The CP key is only the channel.
- *
- * Strictly users + groups — NO authorization-rule authoring (that stays in
- * `apiblaze authz` / the dashboard).
- */
-
-interface ApiblazeGroupsConfig {
-    /** The producer CP key — the SAME widget key the API-key widget uses. Server-only. */
-    cpKey: string;
-    /** Return the logged-in user from the request/session, or null if unauthenticated.
-     *  `email` is how tenant-admin status is granted (admin-emails allowlist) — pass it. */
-    getUser: (req: Request) => Promise<AppUser | null> | AppUser | null;
-    /** Override the apikeys plane base (tenant/user provisioning). Default https://apikeys.apiblaze.com */
-    base?: string;
-    /** Override the iam plane base. Default https://iam.apiblaze.com */
-    iamBase?: string;
-}
-type GroupsAction = {
-    action: 'snapshot';
-} | {
-    action: 'list-groups';
-    offset?: number;
-    q?: string;
-} | {
-    action: 'search-users';
-    q?: string;
-    limit?: number;
-    offset?: number;
-} | {
-    action: 'list-observed';
-    offset?: number;
-    q?: string;
-} | {
-    action: 'group-members';
-    groupId: string;
-    offset?: number;
-} | {
-    action: 'create-group';
-    name: string;
-    description?: string;
-} | {
-    action: 'rename-group';
-    groupId: string;
-    name?: string;
-    description?: string;
-} | {
-    action: 'delete-group';
-    groupId: string;
-} | {
-    action: 'add-member';
-    groupId: string;
-    abzSub: string;
-    role?: 'member' | 'admin';
-} | {
-    action: 'change-role';
-    groupId: string;
-    abzSub: string;
-    role: 'member' | 'admin';
-} | {
-    action: 'remove-member';
-    groupId: string;
-    abzSub: string;
-} | {
-    action: 'add-subgroup';
-    groupId: string;
-    childGroupId: string;
-} | {
-    action: 'remove-subgroup';
-    groupId: string;
-    childGroupId: string;
-} | {
-    action: 'group-detail';
-    groupId: string;
-} | {
-    action: 'provision-observed';
-    consumerUserId: string;
-    email?: string;
-    displayName?: string;
-    groups?: string[];
-} | {
-    action: 'create-user';
-    ref: string;
-    displayName?: string;
-} | {
-    action: 'list-admins';
-} | {
-    action: 'add-admin';
-    email: string;
-} | {
-    action: 'remove-admin';
-    email: string;
-};
-declare function createApiblazeGroups(cfg: ApiblazeGroupsConfig): {
-    handler: (req: Request) => Promise<Response>;
-    run: (user: AppUser, op: GroupsAction) => Promise<{
-        status: number;
-        data: unknown;
-    }>;
-};
-
-/**
- * createApiblazeChat — the server-side half of <ChatWidget/> for API-KEY-door
- * proxies (chatwidget_prd.md, Mode 2 "relay"). JWT-door proxies don't need this
- * file at all: the widget sends the end user's own session token straight to
- * the proxy (Mode 1) and per-person quotas/authorization fall out for free.
- *
- * What the relay does — and ALL it does:
- *   1. resolves YOUR user from YOUR session (the same getUser contract as
- *      createApiblazeKeys / createApiblazeGroups),
- *   2. attaches the producer DP key (server-only) + X-End-User-Id,
- *   3. PIPES the SSE stream through untouched (streams pass through Next.js
- *      route handlers natively — never buffer, never re-frame).
- *
- * DOCUMENTED TRADEOFFS (say them, don't bury them): behind ONE relay key,
- *   · the proxy's chat quota meters ALL your end users into ONE daily bucket;
- *   · tool calls carry that key's authority (specs/chat_funding.MD: metering
- *     keys on the credential; the asserted X-End-User-Id proves nothing);
- *   · chat is ONE TURN AT A TIME site-wide — the anti-burst in-flight lock is
- *     per credential, so while one user's turn streams (seconds), another
- *     user's send is politely refused ("a previous message is still being
- *     processed"). Fine for a demo or a low-traffic page; NOT for a busy site.
- * Want per-person buckets, per-person authorization, and real concurrency?
- * Use Mode 1 (register your issuer on the proxy — the user's own JWT is the
- * credential), or mint per-user keys via the key-widget plane.
- *
- *   // app/api/apiblaze/chat/route.ts
- *   import { createApiblazeChat } from 'apiblaze/server';
- *   const chat = createApiblazeChat({
- *     project: 'ninopizza',
- *     apiKey: process.env.APIBLAZE_DP_KEY!,   // a DP key for that proxy — server-only
- *     getUser: async (req) => ({ userId: (await session(req)).userId }),
- *   });
- *   export const POST = chat.handler;
- */
-interface ChatRelayUser {
-    /** Your stable id for the PERSON — forwarded as X-End-User-Id so the proxy's
-     *  identity gates (identified_traffic_only / pre-approval) and the upstream's
-     *  x-end-user-id contract see it. */
-    userId: string;
-    /** Optional display email/label — NOT forwarded; reserved for future use. */
-    email?: string;
-}
-interface ApiblazeChatConfig {
-    /** Project handle (the proxy's subdomain). */
-    project: string;
-    /** A DP api key for that proxy. SERVER-ONLY — never expose it to the browser;
-     *  the whole point of this relay is that the browser never holds it. */
-    apiKey: string;
-    /** Resolve the acting end user from YOUR request/session. Return null when
-     *  nobody is signed in (the relay then answers 401 rather than letting an
-     *  anonymous visitor chat on your key). Return {userId: ''} to explicitly
-     *  allow UNIDENTIFIED chat (the proxy must not require identification). */
-    getUser: (req: Request) => Promise<ChatRelayUser | null> | ChatRelayUser | null;
-    /** Defaults: '1.0.0' / 'prod' / 'abz.run'. */
-    apiVersion?: string;
-    environment?: string;
-    host?: string;
-    /** Cap on the request body we relay, bytes (default 262144 = the proxy's own
-     *  non-BYO cap — reject junk before spending upstream bandwidth on it). */
-    maxBodyBytes?: number;
-}
-declare function createApiblazeChat(cfg: ApiblazeChatConfig): {
-    handler: (req: Request) => Promise<Response>;
-    upstream: string;
-};
-
-/**
- * apiblaze/server — the server-side half of the apiblaze widgets.
- *
- * Holds the producer's CP key (server-only, never shipped to the browser) and turns
- * a logged-in user into apiblaze operations. The browser widgets (`apiblaze/react`)
- * talk ONLY to your own backend; your backend talks to apiblaze — so there are no
- * cross-domain cookies, no secrets in the client, and no auth wiring beyond
- * "read my session."
- *
- * TWO faces over ONE shared substrate (core.ts — one CP credential, one
- * ensure-tenant/ensure-user path):
- *   - createApiblazeKeys   → API-key management  (<ApiKeyWidget/>)
- *   - createApiblazeGroups → users & groups IAM  (<UsersGroupsWidget/>)
- *
- * Usage (Next.js App Router — app/api/apiblaze/keys/route.ts):
- *
- *   import { createApiblazeKeys } from 'apiblaze/server';
- *   import { auth } from '@/auth';                       // NextAuth, Clerk, anything
- *
- *   const keys = createApiblazeKeys({
- *     cpKey: process.env.APIBLAZE_CP_KEY!,
- *     getUser: async () => {
- *       const s = await auth();
- *       if (!s?.user) return null;
- *       return {
- *         tenant: s.user.orgId ?? s.user.id,
- *         userId: s.user.id,
- *         email: s.user.email ?? undefined,
- *         // Which key types this person may create. Omit → ['call-only'].
- *         // false → no API access. A list of 2+ → the widget shows a picker.
- *         keyTypes: s.user.isEngineer ? ['manager', 'call-only'] : undefined,
- *       };
- *     },
- *   });
- *   export const GET = keys.handler;
- *   export const POST = keys.handler;
- *
- * SECURITY: eligibility is decided HERE, on your server, from your session —
- * never from the browser. When a user is eligible for more than one type the
- * browser sends its pick, but this handler only honors it if it's in the user's
- * allowed set; otherwise it's rejected. `keyTypes: false` is enforced server-side
- * (403) before anything is provisioned, not merely hidden in the UI.
- */
-
-interface ApiblazeKeysConfig {
-    /** The producer CP key from the apiblaze dashboard Developers section. Server-only.
-     *  Use a purpose-built "widget" key (not a full admin key) so the platform's own
-     *  subset rule is a real backstop under your eligibility logic. */
-    cpKey: string;
-    /** Return the logged-in user from the request/session, or null if unauthenticated. */
-    getUser: (req: Request) => Promise<AppUser | null> | AppUser | null;
-    /** Optional override for eligibility, if you'd rather compute it here than inline
-     *  in getUser. Same contract as AppUser.keyTypes (undefined → default, false/[] → deny).
-     *  Takes precedence over user.keyTypes when provided. */
-    resolveKeyTypes?: (user: AppUser) => (string[] | false) | Promise<string[] | false>;
-    /** Key lifetime in seconds. Omit for a DURABLE key (no expiry) — the right
-     *  default for a production API key a developer embeds, so it never silently
-     *  stops working. A durable key is shown ONCE at creation (not re-revealable);
-     *  set an expiry if you want keys that stay revealable until they expire. */
-    keyExpiresInSeconds?: number;
-    /** Override the apiblaze base (tests/self-host). Default https://apikeys.apiblaze.com */
-    base?: string;
-}
-type Action = {
-    action: 'list';
-} | {
-    action: 'create';
-    keyType?: string;
-} | {
-    action: 'reveal';
-    keyId: string;
-} | {
-    action: 'rotate';
-    keyId: string;
-} | {
-    action: 'revoke';
-    keyId: string;
-};
-declare function createApiblazeKeys(cfg: ApiblazeKeysConfig): {
-    handler: (req: Request) => Promise<Response>;
-    run: (user: AppUser, op: Action) => Promise<{
-        status: number;
-        data: unknown;
-    }>;
-};
-
-export { type ApiblazeChatConfig, type ApiblazeGroupsConfig, type ApiblazeKeysConfig, type AppUser, type ChatRelayUser, type GroupsAction, PlaneError, createApiblazeChat, createApiblazeGroups, createApiblazeKeys };

package/dist/server/index.d.ts

@@ -1,309 +0,0 @@
-/**
- * apiblaze/server — SHARED widget-server substrate.
- *
- * One CP credential, one getUser contract, one ensure-tenant/ensure-user path —
- * consumed by BOTH widget faces (`createApiblazeKeys` and `createApiblazeGroups`).
- * Factored per iam_toolkit_spec ("share, don't fork" — copy-forking this
- * bootstrap is a spec failure).
- *
- * Trust model: the CP key stays server-side and vouches for the CHANNEL; the
- * acting end-user rides X-End-User-Id / X-End-User-Email. On the apikeys plane
- * the end-user header only narrows (self-scoped key ops); on the iam plane it
- * IS the principal (iam-worker independently checks the resolved user's
- * apiblaze_admins membership before any group op).
- */
-interface AppUser {
-    /** The producer's stable id for the consumer COMPANY — becomes the tenant (isolation). */
-    tenant: string;
-    /** The producer's stable id for the PERSON — the acting end-user. */
-    userId: string;
-    /** Optional; REQUIRED in practice for the groups widget — tenant-admin status
-     *  is granted by email (the tenant's admin-emails allowlist). */
-    email?: string;
-    /** Optional display name (cosmetic). */
-    label?: string;
-    /** Key-widget eligibility (see createApiblazeKeys). Ignored by the groups widget. */
-    keyTypes?: string[] | false;
-    /** Any extra fields your eligibility logic wants (e.g. isEngineer). */
-    [k: string]: unknown;
-}
-declare class PlaneError extends Error {
-    status: number;
-    detail: string;
-    constructor(status: number, detail: string);
-}
-
-/**
- * createApiblazeGroups — the server-side half of the Users & Groups widget
- * (<UsersGroupsWidget/>), riding the SAME shared substrate (core.ts) and the
- * SAME one CP widget credential as the API-key widget.
- *
- * Usage (Next.js App Router — app/api/apiblaze/groups/route.ts):
- *
- *   import { createApiblazeGroups } from 'apiblaze/server';
- *   const groups = createApiblazeGroups({
- *     cpKey: process.env.APIBLAZE_CP_KEY!,   // the SAME key the key widget uses
- *     getUser: async () => { ...same contract... return { tenant, userId, email } },
- *   });
- *   export const GET = groups.handler;
- *   export const POST = groups.handler;
- *
- * AUTHORIZATION MODEL (iam_toolkit_spec): unlike key ops (self-scoped), group
- * admin ops are tenant-wide — so the acting END-USER IS THE PRINCIPAL. This
- * server forwards the session user via X-End-User-Id/-Email; apiblaze's iam
- * plane independently verifies that user is a TENANT ADMIN (apiblaze_admins
- * member, granted via the tenant's admin-emails allowlist) before any op. A
- * non-admin gets `access: 'pending'` — nothing here can elevate them, and no
- * producer-side flag can either. The CP key is only the channel.
- *
- * Strictly users + groups — NO authorization-rule authoring (that stays in
- * `apiblaze authz` / the dashboard).
- */
-
-interface ApiblazeGroupsConfig {
-    /** The producer CP key — the SAME widget key the API-key widget uses. Server-only. */
-    cpKey: string;
-    /** Return the logged-in user from the request/session, or null if unauthenticated.
-     *  `email` is how tenant-admin status is granted (admin-emails allowlist) — pass it. */
-    getUser: (req: Request) => Promise<AppUser | null> | AppUser | null;
-    /** Override the apikeys plane base (tenant/user provisioning). Default https://apikeys.apiblaze.com */
-    base?: string;
-    /** Override the iam plane base. Default https://iam.apiblaze.com */
-    iamBase?: string;
-}
-type GroupsAction = {
-    action: 'snapshot';
-} | {
-    action: 'list-groups';
-    offset?: number;
-    q?: string;
-} | {
-    action: 'search-users';
-    q?: string;
-    limit?: number;
-    offset?: number;
-} | {
-    action: 'list-observed';
-    offset?: number;
-    q?: string;
-} | {
-    action: 'group-members';
-    groupId: string;
-    offset?: number;
-} | {
-    action: 'create-group';
-    name: string;
-    description?: string;
-} | {
-    action: 'rename-group';
-    groupId: string;
-    name?: string;
-    description?: string;
-} | {
-    action: 'delete-group';
-    groupId: string;
-} | {
-    action: 'add-member';
-    groupId: string;
-    abzSub: string;
-    role?: 'member' | 'admin';
-} | {
-    action: 'change-role';
-    groupId: string;
-    abzSub: string;
-    role: 'member' | 'admin';
-} | {
-    action: 'remove-member';
-    groupId: string;
-    abzSub: string;
-} | {
-    action: 'add-subgroup';
-    groupId: string;
-    childGroupId: string;
-} | {
-    action: 'remove-subgroup';
-    groupId: string;
-    childGroupId: string;
-} | {
-    action: 'group-detail';
-    groupId: string;
-} | {
-    action: 'provision-observed';
-    consumerUserId: string;
-    email?: string;
-    displayName?: string;
-    groups?: string[];
-} | {
-    action: 'create-user';
-    ref: string;
-    displayName?: string;
-} | {
-    action: 'list-admins';
-} | {
-    action: 'add-admin';
-    email: string;
-} | {
-    action: 'remove-admin';
-    email: string;
-};
-declare function createApiblazeGroups(cfg: ApiblazeGroupsConfig): {
-    handler: (req: Request) => Promise<Response>;
-    run: (user: AppUser, op: GroupsAction) => Promise<{
-        status: number;
-        data: unknown;
-    }>;
-};
-
-/**
- * createApiblazeChat — the server-side half of <ChatWidget/> for API-KEY-door
- * proxies (chatwidget_prd.md, Mode 2 "relay"). JWT-door proxies don't need this
- * file at all: the widget sends the end user's own session token straight to
- * the proxy (Mode 1) and per-person quotas/authorization fall out for free.
- *
- * What the relay does — and ALL it does:
- *   1. resolves YOUR user from YOUR session (the same getUser contract as
- *      createApiblazeKeys / createApiblazeGroups),
- *   2. attaches the producer DP key (server-only) + X-End-User-Id,
- *   3. PIPES the SSE stream through untouched (streams pass through Next.js
- *      route handlers natively — never buffer, never re-frame).
- *
- * DOCUMENTED TRADEOFFS (say them, don't bury them): behind ONE relay key,
- *   · the proxy's chat quota meters ALL your end users into ONE daily bucket;
- *   · tool calls carry that key's authority (specs/chat_funding.MD: metering
- *     keys on the credential; the asserted X-End-User-Id proves nothing);
- *   · chat is ONE TURN AT A TIME site-wide — the anti-burst in-flight lock is
- *     per credential, so while one user's turn streams (seconds), another
- *     user's send is politely refused ("a previous message is still being
- *     processed"). Fine for a demo or a low-traffic page; NOT for a busy site.
- * Want per-person buckets, per-person authorization, and real concurrency?
- * Use Mode 1 (register your issuer on the proxy — the user's own JWT is the
- * credential), or mint per-user keys via the key-widget plane.
- *
- *   // app/api/apiblaze/chat/route.ts
- *   import { createApiblazeChat } from 'apiblaze/server';
- *   const chat = createApiblazeChat({
- *     project: 'ninopizza',
- *     apiKey: process.env.APIBLAZE_DP_KEY!,   // a DP key for that proxy — server-only
- *     getUser: async (req) => ({ userId: (await session(req)).userId }),
- *   });
- *   export const POST = chat.handler;
- */
-interface ChatRelayUser {
-    /** Your stable id for the PERSON — forwarded as X-End-User-Id so the proxy's
-     *  identity gates (identified_traffic_only / pre-approval) and the upstream's
-     *  x-end-user-id contract see it. */
-    userId: string;
-    /** Optional display email/label — NOT forwarded; reserved for future use. */
-    email?: string;
-}
-interface ApiblazeChatConfig {
-    /** Project handle (the proxy's subdomain). */
-    project: string;
-    /** A DP api key for that proxy. SERVER-ONLY — never expose it to the browser;
-     *  the whole point of this relay is that the browser never holds it. */
-    apiKey: string;
-    /** Resolve the acting end user from YOUR request/session. Return null when
-     *  nobody is signed in (the relay then answers 401 rather than letting an
-     *  anonymous visitor chat on your key). Return {userId: ''} to explicitly
-     *  allow UNIDENTIFIED chat (the proxy must not require identification). */
-    getUser: (req: Request) => Promise<ChatRelayUser | null> | ChatRelayUser | null;
-    /** Defaults: '1.0.0' / 'prod' / 'abz.run'. */
-    apiVersion?: string;
-    environment?: string;
-    host?: string;
-    /** Cap on the request body we relay, bytes (default 262144 = the proxy's own
-     *  non-BYO cap — reject junk before spending upstream bandwidth on it). */
-    maxBodyBytes?: number;
-}
-declare function createApiblazeChat(cfg: ApiblazeChatConfig): {
-    handler: (req: Request) => Promise<Response>;
-    upstream: string;
-};
-
-/**
- * apiblaze/server — the server-side half of the apiblaze widgets.
- *
- * Holds the producer's CP key (server-only, never shipped to the browser) and turns
- * a logged-in user into apiblaze operations. The browser widgets (`apiblaze/react`)
- * talk ONLY to your own backend; your backend talks to apiblaze — so there are no
- * cross-domain cookies, no secrets in the client, and no auth wiring beyond
- * "read my session."
- *
- * TWO faces over ONE shared substrate (core.ts — one CP credential, one
- * ensure-tenant/ensure-user path):
- *   - createApiblazeKeys   → API-key management  (<ApiKeyWidget/>)
- *   - createApiblazeGroups → users & groups IAM  (<UsersGroupsWidget/>)
- *
- * Usage (Next.js App Router — app/api/apiblaze/keys/route.ts):
- *
- *   import { createApiblazeKeys } from 'apiblaze/server';
- *   import { auth } from '@/auth';                       // NextAuth, Clerk, anything
- *
- *   const keys = createApiblazeKeys({
- *     cpKey: process.env.APIBLAZE_CP_KEY!,
- *     getUser: async () => {
- *       const s = await auth();
- *       if (!s?.user) return null;
- *       return {
- *         tenant: s.user.orgId ?? s.user.id,
- *         userId: s.user.id,
- *         email: s.user.email ?? undefined,
- *         // Which key types this person may create. Omit → ['call-only'].
- *         // false → no API access. A list of 2+ → the widget shows a picker.
- *         keyTypes: s.user.isEngineer ? ['manager', 'call-only'] : undefined,
- *       };
- *     },
- *   });
- *   export const GET = keys.handler;
- *   export const POST = keys.handler;
- *
- * SECURITY: eligibility is decided HERE, on your server, from your session —
- * never from the browser. When a user is eligible for more than one type the
- * browser sends its pick, but this handler only honors it if it's in the user's
- * allowed set; otherwise it's rejected. `keyTypes: false` is enforced server-side
- * (403) before anything is provisioned, not merely hidden in the UI.
- */
-
-interface ApiblazeKeysConfig {
-    /** The producer CP key from the apiblaze dashboard Developers section. Server-only.
-     *  Use a purpose-built "widget" key (not a full admin key) so the platform's own
-     *  subset rule is a real backstop under your eligibility logic. */
-    cpKey: string;
-    /** Return the logged-in user from the request/session, or null if unauthenticated. */
-    getUser: (req: Request) => Promise<AppUser | null> | AppUser | null;
-    /** Optional override for eligibility, if you'd rather compute it here than inline
-     *  in getUser. Same contract as AppUser.keyTypes (undefined → default, false/[] → deny).
-     *  Takes precedence over user.keyTypes when provided. */
-    resolveKeyTypes?: (user: AppUser) => (string[] | false) | Promise<string[] | false>;
-    /** Key lifetime in seconds. Omit for a DURABLE key (no expiry) — the right
-     *  default for a production API key a developer embeds, so it never silently
-     *  stops working. A durable key is shown ONCE at creation (not re-revealable);
-     *  set an expiry if you want keys that stay revealable until they expire. */
-    keyExpiresInSeconds?: number;
-    /** Override the apiblaze base (tests/self-host). Default https://apikeys.apiblaze.com */
-    base?: string;
-}
-type Action = {
-    action: 'list';
-} | {
-    action: 'create';
-    keyType?: string;
-} | {
-    action: 'reveal';
-    keyId: string;
-} | {
-    action: 'rotate';
-    keyId: string;
-} | {
-    action: 'revoke';
-    keyId: string;
-};
-declare function createApiblazeKeys(cfg: ApiblazeKeysConfig): {
-    handler: (req: Request) => Promise<Response>;
-    run: (user: AppUser, op: Action) => Promise<{
-        status: number;
-        data: unknown;
-    }>;
-};
-
-export { type ApiblazeChatConfig, type ApiblazeGroupsConfig, type ApiblazeKeysConfig, type AppUser, type ChatRelayUser, type GroupsAction, PlaneError, createApiblazeChat, createApiblazeGroups, createApiblazeKeys };

package/dist/sidecar/index.d.mts

@@ -1,30 +0,0 @@
-/**
- * apiblaze/sidecar — the egress sidecar (observe → approve model).
- * Spec: specs/sidecar/apiblaze-sidecar-spec.md §3.
- *
- *   // instrumentation.ts
- *   import { register as apiblaze } from "apiblaze/sidecar";
- *   export function register() { apiblaze(); }
- *
- * At boot it loads the team's APPROVED origins (GET sidecar.abz.run/routes) into
- * an in-memory map. Per request: if the origin is approved it routes through that
- * origin's proxy (carrying the call's own auth); otherwise it goes DIRECT,
- * untouched, and reports the origin once as a candidate. Reads only APIBLAZE_TOKEN.
- * Fail-open: any error → direct. Never breaks the app.
- */
-interface SidecarOptions {
-    token?: string;
-    exclude?: string[];
-    include?: string[];
-    quiet?: boolean;
-    /** Explicit on/off. Overrides the APIBLAZE_SIDECAR env toggle when set. */
-    enabled?: boolean;
-}
-declare function register(opts?: SidecarOptions): void;
-declare function withApiblaze<T extends Record<string, unknown>>(nextConfig?: T): T;
-declare const _default: {
-    register: typeof register;
-    withApiblaze: typeof withApiblaze;
-};
-
-export { type SidecarOptions, _default as default, register, withApiblaze };

package/dist/sidecar/index.d.ts

@@ -1,30 +0,0 @@
-/**
- * apiblaze/sidecar — the egress sidecar (observe → approve model).
- * Spec: specs/sidecar/apiblaze-sidecar-spec.md §3.
- *
- *   // instrumentation.ts
- *   import { register as apiblaze } from "apiblaze/sidecar";
- *   export function register() { apiblaze(); }
- *
- * At boot it loads the team's APPROVED origins (GET sidecar.abz.run/routes) into
- * an in-memory map. Per request: if the origin is approved it routes through that
- * origin's proxy (carrying the call's own auth); otherwise it goes DIRECT,
- * untouched, and reports the origin once as a candidate. Reads only APIBLAZE_TOKEN.
- * Fail-open: any error → direct. Never breaks the app.
- */
-interface SidecarOptions {
-    token?: string;
-    exclude?: string[];
-    include?: string[];
-    quiet?: boolean;
-    /** Explicit on/off. Overrides the APIBLAZE_SIDECAR env toggle when set. */
-    enabled?: boolean;
-}
-declare function register(opts?: SidecarOptions): void;
-declare function withApiblaze<T extends Record<string, unknown>>(nextConfig?: T): T;
-declare const _default: {
-    register: typeof register;
-    withApiblaze: typeof withApiblaze;
-};
-
-export { type SidecarOptions, _default as default, register, withApiblaze };