@cosmoops/connect-sdk 0.1.0

package/dist/types/client/components/apps-grid.d.ts

@@ -0,0 +1,20 @@
+export interface ConnectAppsGridProps {
+    /** Extra classes on the trigger button. */
+    className?: string;
+    /** Trigger label for screen readers. */
+    label?: string;
+}
+/**
+ * The Google-style app launcher: a grid icon in your top bar that opens a
+ * modal of every Connect service this organization can actually open.
+ *
+ * Only launchable apps appear, so no tile is a dead end - a paused
+ * subscription still shows, badged, because a dunning cycle should not make a
+ * product look deleted. The current app is pinned first and marked, rather
+ * than filtered out, so the grid never has a hole where "you are here" should
+ * be.
+ *
+ * Renders nothing when signed out: a launcher with nothing to launch is just a
+ * button that opens an empty box.
+ */
+export declare function ConnectAppsGrid({ className, label }: ConnectAppsGridProps): import("react").JSX.Element | null;

package/dist/types/client/components/auth-buttons.d.ts

@@ -0,0 +1,31 @@
+import { Button } from "@heroui/react";
+import type { ComponentProps, ReactNode } from "react";
+type ButtonProps = ComponentProps<typeof Button>;
+export interface ConnectAuthButtonProps extends Omit<ButtonProps, "onPress" | "children"> {
+    /** Defaults to "Continue with Connect" / "Sign up with Connect". */
+    children?: ReactNode;
+}
+/**
+ * "Continue with Connect" - the federated sign-in button, in the shape people
+ * already know from Google and GitHub: neutral surface, brand mark on the
+ * left, one line of text.
+ *
+ * `variant="secondary"` by default rather than `primary`, on purpose. A
+ * federated button that outshouts the host app's own primary action reads as
+ * an ad; every mature identity button is quiet. Pass `variant` to override if
+ * Connect *is* the primary path in your flow.
+ *
+ * Hidden while a session is still loading, so a signed-in user never sees a
+ * Login button flash before their avatar resolves.
+ */
+export declare function ConnectLoginButton({ children, ...props }: ConnectAuthButtonProps): import("react").JSX.Element | null;
+/**
+ * The same button pointed at registration (`prompt=create`).
+ *
+ * Only the starting screen differs - each screen links to the other carrying
+ * the same in-flight request, and anyone who already has a Connect session
+ * skips straight to consent either way. So shipping both buttons costs nothing
+ * and matches what users expect from a "Sign up" / "Log in" pair.
+ */
+export declare function ConnectRegisterButton({ children, ...props }: ConnectAuthButtonProps): import("react").JSX.Element | null;
+export {};

package/dist/types/client/components/feature-gate.d.ts

@@ -0,0 +1,57 @@
+import type { ReactNode } from "react";
+/**
+ * Whether the live subscription unlocks a plan feature.
+ *
+ * The browser twin of `client.entitlements.hasFeature` on the server, and the
+ * same posture: `false` rather than a throw when there is no subscription at
+ * all, because "not entitled" is the same answer either way and a feature check
+ * should not need a try/catch around it.
+ *
+ * `isLoading` is returned separately and matters: `false` while the first read
+ * is in flight means "we don't know yet", not "no". Gate on `isEntitled` for
+ * what to render and on `isLoading` for whether to render anything at all -
+ * `ConnectFeatureGate` does exactly that.
+ */
+export declare function useConnectFeature(feature: string): {
+    isEntitled: boolean;
+    isLoading: boolean;
+    /** Every feature key the current plan unlocks - for a settings page listing what's included. */
+    features: string[];
+};
+export interface ConnectFeatureGateProps {
+    /** The feature key, as it appears in `plan.features`. */
+    feature: string;
+    children: ReactNode;
+    /**
+     * Rendered when the plan does not include `feature`. Defaults to an upsell
+     * card pointing at your plans page - pass `null` to hide the module silently
+     * instead.
+     */
+    fallback?: ReactNode;
+    /** Shown while the first read is in flight. Defaults to nothing. */
+    loading?: ReactNode;
+    /** Where your plan catalogue is mounted, for the default upsell. */
+    plansHref?: string;
+    /** Headline for the default upsell - name the feature, not the plan. */
+    title?: string;
+    description?: string;
+    className?: string;
+}
+/**
+ * Renders `children` only when the workspace's plan includes `feature`.
+ *
+ * ```tsx
+ * <ConnectFeatureGate feature="advanced_reports" title="Reports are on Growth">
+ *   <Reports />
+ * </ConnectFeatureGate>
+ * ```
+ *
+ * Like every gate in this package, it is a **UX gate, not a security
+ * boundary**: the entitlement is read through your own origin and the browser
+ * can ignore it. Check `client.entitlements.hasFeature(orgId, feature)` on the
+ * server before doing the thing the feature unlocks.
+ *
+ * Renders `loading` - not `fallback` - while the answer is unknown, so a paying
+ * customer never sees an upsell for something they already have.
+ */
+export declare function ConnectFeatureGate({ feature, children, fallback, loading, plansHref, title, description, className, }: ConnectFeatureGateProps): import("react").JSX.Element;

package/dist/types/client/components/link-button.d.ts

@@ -0,0 +1,20 @@
+import { type ButtonProps } from "@heroui/react";
+export type ConnectLinkButtonProps = Omit<ButtonProps, "render"> & {
+    href: string;
+};
+/**
+ * A HeroUI `Button` that renders a real `<a>`.
+ *
+ * A plain anchor, deliberately not a router link: this package imports nothing
+ * from `next` (see the `./next` entry's doc comment for why that is a hard
+ * rule), so it cannot know which router - if any - the host app uses. An
+ * `<a href>` navigates under all of them, and a host that wants client-side
+ * routing can pass its own element via `render` on the underlying `Button`.
+ *
+ * The cast is the same one HeroUI's own "Render Function" example needs:
+ * `render` types its argument as the props of the element `Button` would have
+ * emitted, which is a `<button>` - including a `ref` typed to
+ * `HTMLButtonElement`. Spreading that onto an anchor is sound at runtime and
+ * unrepresentable in the type, which is exactly what a cast is for.
+ */
+export declare function ConnectLinkButton({ href, ...props }: Readonly<ConnectLinkButtonProps>): import("react").JSX.Element;

package/dist/types/client/components/logo.d.ts

@@ -0,0 +1,35 @@
+import type { ReactNode } from "react";
+export interface ConnectLogoProps {
+    /**
+     * This service's name - rendered as the sub-brand beneath the `cosmo·ops`
+     * wordmark, in the house `cosmo·ops VOICE` treatment.
+     */
+    name: string;
+    /**
+     * This service's own glyph, drawn inside the accent badge. Any node - a
+     * `lucide-react` icon, an `<img>`, an inline `<svg>`. Paint it with
+     * `currentColor` and it inherits `--accent-foreground` from the badge, so it
+     * stays legible when a host app changes the accent.
+     *
+     * Falls back to the Connect rings when omitted.
+     */
+    icon?: ReactNode;
+    /** Mark only, no wordmark - for a collapsed sidebar or a favicon-sized slot. */
+    collapsed?: boolean;
+    className?: string;
+}
+/**
+ * The shared platform lockup: a service's own glyph on the CosmoOps badge,
+ * `cosmo·ops` beside it, and the service name underneath.
+ *
+ * This is what makes a family of service platforms look like one product. Each
+ * platform passes only what differs - its `name` and its `icon` - and inherits
+ * the mark geometry, the wordmark treatment, the separator, and the accent from
+ * one place. Change the lockup here and every platform follows.
+ *
+ * Sizes are `em`-based throughout, so the whole lockup scales from the
+ * wrapper's font size: `className="text-base"` renders it half again as large
+ * as `text-sm`, with the badge, gap and tracking all in proportion. That is
+ * why there is no `size` prop.
+ */
+export declare function ConnectLogo({ name, icon, collapsed, className }: ConnectLogoProps): import("react").JSX.Element;

package/dist/types/client/components/plan-pricing.d.ts

@@ -0,0 +1,96 @@
+/**
+ * The pricing arithmetic the plan grid and its confirmation dialog have to
+ * agree on. Extracted so they cannot drift: a dialog that called an upgrade
+ * an upgrade while the card behind it said downgrade would be worse than
+ * either label being wrong on its own.
+ *
+ * Mirrors `packages/data/src/services/catalog.ts` and
+ * `packages/data/src/payments/plan-change.ts`, which are the copies Connect's
+ * own UI uses and which decide which use-case actually runs. The duplication
+ * is deliberate and load-bearing: this package carries no dependency on
+ * `@connect/data` so a partner's bundle never pulls Connect's internals, and
+ * `conformance.test.ts` type-checks the wire shapes against the server DTOs so
+ * the two can't drift silently.
+ *
+ * No React here - it is imported by both a client component and its dialog,
+ * and nothing in it needs to be.
+ */
+import type { AppliedDiscount, Plan, SubscriptionResponse } from "../../types.js";
+/** Paise are the wire unit everywhere in Connect; rupees are the display unit. */
+export declare function formatPrice(paise: number): string;
+/**
+ * An annual plan's price is 12 cycles of the same product, so any comparison
+ * across billing intervals has to normalise first - otherwise every annual
+ * plan reads as an upgrade over every monthly one.
+ */
+export declare function monthlyOf(price: number, billingInterval: Plan["billingInterval"]): number;
+export declare function discountLabel(discount: AppliedDiscount): string;
+/**
+ * The minimum a plan-like object has to expose to be grouped or compared -
+ * lets the dialog pass a `SubscribedPlan` (which carries no add-ons or
+ * features) wherever a comparison is wanted.
+ */
+export interface ComparablePlan {
+    name: string;
+    price: number;
+    billingInterval: Plan["billingInterval"];
+    planGroup?: string | null;
+}
+/**
+ * Falls back to a slug of the name for a Connect deployment predating
+ * `planGroup` on the wire, mirroring `resolvePlanGroup` server-side. Kept so
+ * an SDK upgrade doesn't require the partner's Connect instance to be
+ * upgraded in lockstep - an older server simply omits the field and the grid
+ * groups the way it always did.
+ */
+export declare function resolvePlanGroup(plan: ComparablePlan): string;
+/** One tier of the catalog: the product, and whichever cadences it is sold at. */
+export interface PlanTier {
+    planGroup: string;
+    name: string;
+    description: string;
+    monthly: Plan | null;
+    annual: Plan | null;
+    /** Whole-percent saving from paying annually, or `null` when this tier has no pair to compare. */
+    annualSavingPercent: number | null;
+}
+/**
+ * Collapses a flat plan list into one card per tier.
+ *
+ * This is the shape the grid wants and the old one didn't have. It used to
+ * filter the whole list down to the toggled interval, which meant a tier sold
+ * monthly-only simply vanished when a customer looked at annual pricing, and a
+ * catalog with no monthly plans at all rendered an empty grid on first paint.
+ * Grouping first means the toggle picks a *price inside a card*, and a card
+ * with only one cadence still shows.
+ *
+ * Ordered by the tier's cheapest monthly-equivalent price, so the grid reads
+ * left-to-right cheapest-first regardless of what order the API returned.
+ */
+export declare function groupPlansByTier(plans: readonly Plan[]): PlanTier[];
+/**
+ * Annual is quoted per year on the wire (`billingInterval: "annual"`), so a
+ * side-by-side grid has to normalise before it can compare. Showing the saving
+ * against 12x the monthly plan is the comparison a customer is actually making.
+ *
+ * **Call this with a matched pair from one tier.** It used to be handed the
+ * first monthly and the first annual plan in the whole response - two plans
+ * that were the same tier only by the accident of document order, and that
+ * produced one badge for a catalog where each tier discounts differently.
+ * `groupPlansByTier` now does the pairing.
+ */
+export declare function annualSaving(monthly: Plan | null | undefined, annual: Plan | null | undefined): number | null;
+/**
+ * What moving to `plan` would be, given what the org is on today.
+ *
+ * `switch-to-annual`/`switch-to-monthly` exist because a change of *cadence*
+ * is neither an upgrade nor a downgrade, and calling it one is not a wording
+ * problem. Connect picks the use-case that runs from the same classification
+ * (`classifyPlanChange` in `packages/data`), and a same-tier move to annual
+ * compares *cheaper* per month - so it used to be sent down the downgrade
+ * path, where the price delta across cadences is negative, floors to zero,
+ * and settles the whole switch for no money at all.
+ */
+export type PlanAction = "current" | "upgrade" | "downgrade" | "switch-to-annual" | "switch-to-monthly" | "subscribe";
+export declare function resolveAction(plan: Plan, current: SubscriptionResponse | null): PlanAction;
+export declare const ACTION_LABEL: Record<PlanAction, string>;

package/dist/types/client/components/plans-page.d.ts

@@ -0,0 +1,36 @@
+import { type ConnectPlansProps } from "./plans.js";
+export interface ConnectPlansPageProps extends ConnectPlansProps {
+    title?: string;
+    description?: string;
+    /**
+     * Show the current subscription above the grid. On by default - someone
+     * arriving at a pricing page while already subscribed is usually here to
+     * change something, and the first thing they need is what they are on now.
+     */
+    showCurrentSubscription?: boolean;
+}
+/**
+ * A complete `/plans` page, assembled from the pieces so the host app's route
+ * file is one line:
+ *
+ * ```tsx
+ * // app/plans/page.tsx
+ * "use client";
+ * export { ConnectPlansPage as default } from "@cosmoops/connect-sdk/client";
+ * ```
+ *
+ * The assembly is the value here, not the layout. Three things have to be on
+ * this page and are easy to leave off:
+ *
+ * 1. **The readiness banner, above the grid.** A workspace that still needs
+ *    KYC can press Subscribe all day and be refused at the last step. Saying so
+ *    before they pick is the difference between a page that works and one that
+ *    ends in a rejected charge.
+ * 2. **What they're on now**, so "Upgrade" on a card has something to mean.
+ * 3. **A signed-out state that is a login button**, not an empty grid - the
+ *    catalogue reads through the bridge, which needs a session.
+ *
+ * Every prop `ConnectPlans` takes passes straight through, and each piece is
+ * exported on its own for an app that wants a different arrangement.
+ */
+export declare function ConnectPlansPage({ title, description, showCurrentSubscription, ...plansProps }: ConnectPlansPageProps): import("react").JSX.Element;

package/dist/types/client/components/plans.d.ts

@@ -0,0 +1,34 @@
+export interface ConnectPlansProps {
+    /** Restrict the grid to these plan ids, in this order. Defaults to every active plan. */
+    planIds?: string[];
+    /** Hide the coupon field. */
+    hideCoupon?: boolean;
+    className?: string;
+}
+/**
+ * The plan table: monthly/annual toggle, features, add-ons, the discount
+ * actually in effect, and the subscribe / upgrade / downgrade flows.
+ *
+ * ## Where the flow runs, and where it finishes
+ *
+ * The *flow* is here: picking a plan, seeing what it costs with GST, being
+ * told what happens to the cycle you are part-way through, and confirming.
+ * The *payment* is not, and that is deliberate. A plan change is not one
+ * write - it re-runs the readiness gates, prices proration against
+ * accumulated credit, re-checks the RBI mandate ceiling for the new amount,
+ * and issues a GST invoice. Connect owns that sequence end to end; a
+ * partner-side "change plan" call would be a second implementation of it
+ * that drifts. It would also mean a browser holding the partner's
+ * credentials could move money, which is the one thing the bridge exists to
+ * prevent.
+ *
+ * So confirming opens Connect - on the *exact* confirmation screen for the
+ * plan just picked, via an intercepted parallel route, not a catalogue the
+ * customer has to search again - and this component watches `/entitlements`
+ * until the change lands, then repaints itself. See `useConnectCheckout`.
+ *
+ * Coupon codes work the same way: the field carries the code into Connect's
+ * checkout, where it is validated and applied against the real cart. Anything
+ * this component claimed about a code would be a guess it cannot honour.
+ */
+export declare function ConnectPlans({ planIds, hideCoupon, className }: ConnectPlansProps): import("react").JSX.Element;

package/dist/types/client/components/readiness.d.ts

@@ -0,0 +1,52 @@
+export interface ConnectReadinessBannerProps {
+    /** Show advisory blockers too. Off by default - they are not a reason to interrupt anyone mid-task. */
+    includeAdvisory?: boolean;
+    /** Render nothing at all once the workspace is ready. On by default. */
+    hideWhenReady?: boolean;
+    className?: string;
+}
+/**
+ * Every gate between this workspace and your service, with the way out of each.
+ *
+ * This is the component that keeps a blocked customer from staring at a broken
+ * app. `getReadiness` resolves subscription state, KYC/KYB, a chargeable
+ * payment method and seat headroom in one call, and **each blocker carries a
+ * `resolveUrl` into the exact Connect screen that fixes it** - so being blocked
+ * comes with somewhere to go rather than a refusal.
+ *
+ * Render it high on any page your service gates. It draws nothing at all when
+ * the workspace is ready, so it is safe to leave mounted permanently.
+ *
+ * Two deliberate refusals:
+ *
+ * - **Unrecognised codes are still shown, and still treated as blocking.**
+ *   Connect adds codes without a major version (see `ReadinessBlockerCode`), so
+ *   a switch that only knew today's codes would silently drop tomorrow's - the
+ *   one failure mode where a customer is locked out with no explanation.
+ * - **`message` is rendered, never parsed.** It is human-facing and subject to
+ *   rewording; branching on its text would break on a copy edit.
+ */
+export declare function ConnectReadinessBanner({ includeAdvisory, hideWhenReady, className, }: ConnectReadinessBannerProps): import("react").JSX.Element | null;
+export interface ConnectReadinessGateProps {
+    children: React.ReactNode;
+    /** Rendered instead of `children` while blocked. Defaults to the banner in a card. */
+    fallback?: React.ReactNode;
+    /** Shown while the first readiness read is in flight. */
+    loading?: React.ReactNode;
+    className?: string;
+}
+/**
+ * Renders `children` only once the workspace clears every blocking gate.
+ *
+ * The hard version of `ConnectReadinessBanner`, for a route that genuinely
+ * cannot function while blocked. Prefer the banner where the page still does
+ * something useful - a gate that hides a whole screen behind a verification
+ * notice is a worse experience than one that lets people look around while
+ * they sort it out.
+ *
+ * **This is a UX gate, not a security boundary.** The readiness read reaches
+ * your own origin and a determined browser can ignore whatever it says. The
+ * authoritative check is `client.entitlements.getReadiness` on your server,
+ * before you do the thing.
+ */
+export declare function ConnectReadinessGate({ children, fallback, loading, className, }: ConnectReadinessGateProps): import("react").JSX.Element;

package/dist/types/client/components/subscribe-dialog.d.ts

@@ -0,0 +1,34 @@
+import { type PlanAction } from "./plan-pricing.js";
+import type { Plan, SubscriptionResponse } from "../../types.js";
+export interface ConnectSubscribeDialogProps {
+    /** `null` closes it. The plan being subscribed to or moved to. */
+    plan: Plan | null;
+    /** Which of subscribe / upgrade / downgrade this is - decides the headline and what the notice says about money. */
+    action: PlanAction;
+    /** The org's live subscription, for the "from" side of a plan change. */
+    current: SubscriptionResponse | null;
+    /** Coupon typed into the plan grid, echoed here so it is visible before the hand-off carries it. */
+    coupon?: string;
+    /** Whether this org's `plan.trialDays` still applies is Connect's call, not this component's - see the notice below. */
+    onClose(): void;
+    onConfirm(): void;
+}
+/**
+ * The review step before a customer is sent to Connect.
+ *
+ * It exists because the hand-off is a context switch, and a context switch
+ * the customer did not expect reads as being dumped somewhere. So this says
+ * what they are about to buy, what it costs with GST, what happens to the
+ * cycle they are part-way through, and - plainly - that the payment itself
+ * happens on Connect. Then one button, which opens it.
+ *
+ * **Every number here is a preview, and deliberately never the last word.**
+ * The authoritative price is computed by Connect against the real cart:
+ * proration is priced against the actual cycle, a coupon is validated
+ * against the plan it is being applied to, trial eligibility depends on
+ * whether this organization has ever subscribed to this service before, and
+ * an accumulated credit is deducted. None of that is knowable from the
+ * partner's origin, so this component states the list price and says where
+ * the final figure comes from rather than quietly guessing at one.
+ */
+export declare function ConnectSubscribeDialog({ plan, action, current, coupon, onClose, onConfirm, }: Readonly<ConnectSubscribeDialogProps>): import("react").JSX.Element;

package/dist/types/client/components/subscription.d.ts

@@ -0,0 +1,123 @@
+import type { ReactNode } from "react";
+import type { SubscribedPlan, SubscriptionDetail, SubscriptionResponse } from "../../types.js";
+/**
+ * What a subscription is actually doing, collapsed to the five cases worth
+ * rendering differently.
+ *
+ * `status` alone cannot answer this. `"active"` covers both a paying customer
+ * and one still in a trial (`isTrialing` on the session block is what splits
+ * them), and it says nothing about a subscription winding down -
+ * `cancelAtPeriodEnd` is a separate field precisely so a cancelling
+ * subscription is not mistaken for a renewing one.
+ */
+export type ConnectSubscriptionState = "none" | "trialing" | "active" | "cancelling"
+/** `"created"`/`"authenticated"` - subscribed, but the first debit has not confirmed yet. */
+ | "pending"
+/** `"paused"` (dunning exhausted) or `"cancelled"` - access is gone or going. */
+ | "problem";
+export declare function resolveSubscriptionState(subscription: SubscriptionResponse | null, isTrialing: boolean): ConnectSubscriptionState;
+export interface ConnectNoSubscriptionCardProps {
+    /** Where your plan catalogue is mounted. Defaults to `/plans`. */
+    plansHref?: string;
+    /** Override the headline - "Upgrade to unlock reports", say, rather than the generic one. */
+    title?: string;
+    description?: string;
+    className?: string;
+}
+/**
+ * The "you are not on a plan yet" card.
+ *
+ * Points at your **own** `/plans` page rather than opening Connect, and that is
+ * the deliberate part: choosing a plan is browsing, it belongs in your product
+ * where your pricing story is, and only the final confirmation needs to happen
+ * on Connect. Sending someone straight out of the app to pick is a context
+ * switch two steps too early.
+ *
+ * Rendered on its own it is just a card; `ConnectSubscriptionGate` is the usual
+ * way in, since it picks this only when there is genuinely nothing to show.
+ */
+export declare function ConnectNoSubscriptionCard({ plansHref, title, description, className, }: ConnectNoSubscriptionCardProps): import("react").JSX.Element;
+export interface ConnectSubscriptionCardProps {
+    plansHref?: string;
+    className?: string;
+}
+/**
+ * The current subscription at a glance: plan, what it costs, what happens next,
+ * and one way into Connect to change it.
+ *
+ * The counterpart to `ConnectNoSubscriptionCard` - the same slot in the
+ * signed-up state - so an account or settings page can render this and get the
+ * right thing either way.
+ *
+ * Dates are formatted, never computed. "Renews on 3 Mar" is a fact from the
+ * wire; "renews in 12 days" would be a clock read during render, which is
+ * impure and re-renders wrong.
+ */
+export declare function ConnectSubscriptionCard({ plansHref, className }: ConnectSubscriptionCardProps): import("react").JSX.Element;
+/**
+ * Seats used against what the plan includes.
+ *
+ * Only meaningful for `"fixed"` and `"per-seat"` - `"unlimited"` has nothing to
+ * count against, so it renders nothing rather than a meter that is always
+ * empty. Under `"per-seat"` going over is billable rather than blocked, so it
+ * says what the extra costs instead of warning.
+ */
+export declare function ConnectSeatUsage({ plan, detail, className, }: Readonly<{
+    plan: SubscribedPlan;
+    detail: SubscriptionDetail;
+    className?: string;
+}>): import("react").JSX.Element | null;
+export interface ConnectTrialBannerProps {
+    plansHref?: string;
+    className?: string;
+}
+/**
+ * A trial that is running, and when it converts.
+ *
+ * Renders only while trialing, so it can live permanently in a layout. It says
+ * the charge date rather than a countdown for the same reason
+ * `ConnectSubscriptionCard` does - a countdown means reading the clock while
+ * rendering.
+ *
+ * The wire carries `isTrialing` but no trial *end* date; `nextBillingDate` on a
+ * trialing subscription is the first charge, which is the date a customer
+ * actually cares about anyway.
+ */
+export declare function ConnectTrialBanner({ plansHref, className }: ConnectTrialBannerProps): import("react").JSX.Element | null;
+export interface ConnectSubscriptionGateProps {
+    children: ReactNode;
+    /** Where your plan catalogue is mounted. Defaults to `/plans`. */
+    plansHref?: string;
+    /** Replaces the default "not on a plan yet" card. */
+    fallback?: ReactNode;
+    /** Shown while the first read is in flight. Defaults to a skeleton, never a fallback - see below. */
+    loading?: ReactNode;
+    /**
+     * Let a trialing subscription through. On by default: a trial is a
+     * subscription, and gating it out is how a customer gets sold a trial and
+     * then locked out of it.
+     */
+    allowTrialing?: boolean;
+    /**
+     * Let a subscription whose first debit hasn't confirmed through. On by
+     * default - the charge settles on a webhook and can take minutes, and the
+     * alternative is telling someone who just paid that they haven't.
+     */
+    allowPending?: boolean;
+    className?: string;
+}
+/**
+ * Renders `children` for a subscribed workspace, and the "pick a plan" card for
+ * everyone else.
+ *
+ * **Never renders the fallback while loading.** That flash - "you're not
+ * subscribed" for 200ms, then the real content - is the specific bug this
+ * component exists to make impossible, and it is what hand-rolled versions of
+ * it get wrong: the honest states are "still asking" and "asked, and the answer
+ * is no", and only the second one is a sales pitch.
+ *
+ * **This is a UX gate, not a security boundary** - same caveat as
+ * `ConnectReadinessGate`. Anything that must not happen without a subscription
+ * is checked on your server with `client.entitlements.hasFeature`.
+ */
+export declare function ConnectSubscriptionGate({ children, plansHref, fallback, loading, allowTrialing, allowPending, className, }: ConnectSubscriptionGateProps): import("react").JSX.Element;

package/dist/types/client/components/usage-meter.d.ts

@@ -0,0 +1,24 @@
+export interface ConnectUsageMeterProps {
+    /** Restrict to these add-on ids, in this order. Defaults to every metered add-on. */
+    addonIds?: string[];
+    /** Render nothing when there is nothing to meter, instead of an empty-state card. On by default. */
+    hideWhenEmpty?: boolean;
+    title?: string;
+    className?: string;
+}
+/**
+ * How much of each consumable add-on this workspace has left.
+ *
+ * Reads the balance Connect actually debits, so the number here and the number
+ * `consumeAddon` enforces cannot disagree. Before the `addons:read` endpoint
+ * existed this component was impossible to write honestly: a service could
+ * spend an allowance down on every request and the only thing the API exposed
+ * was the list of add-on *ids* on the subscription.
+ *
+ * **It shows `balance` against `includedPerCycle`, and never a "used" figure.**
+ * With `carryForward` an unspent balance survives the cycle boundary, so
+ * `included - balance` can go negative - a meter that runs backwards. Real
+ * consumption for a cycle is a ledger question, and computing it from a
+ * balance would be a guess rendered as a fact.
+ */
+export declare function ConnectUsageMeter({ addonIds, hideWhenEmpty, title, className, }: ConnectUsageMeterProps): import("react").JSX.Element | null;

package/dist/types/client/components/user-menu.d.ts

@@ -0,0 +1,86 @@
+import type { ThemeMode } from "../../types.js";
+export interface ConnectUserMenuProps {
+    /** Hide the name beside the avatar - for a dense top bar. */
+    compact?: boolean;
+    /** Called after sign-out completes, e.g. to route home. */
+    onSignOut?: () => void;
+    className?: string;
+    /**
+     * Current theme, and where to send a change - the SDK has no theme
+     * provider of its own (no `next-themes` dependency), so this is entirely
+     * host-controlled. The Appearance section only renders when both are
+     * supplied; omit either to leave theme control out of the modal.
+     */
+    theme?: ThemeMode;
+    onThemeChange?: (theme: ThemeMode) => void;
+}
+/**
+ * Avatar and name in the trigger; an identity card, the three Connect
+ * destinations (Profile, Billing, Connect), an optional appearance control,
+ * this account's active sessions, and sign-out in the modal it opens.
+ *
+ * Profile/Billing/Connect open in a **new tab**, each marked with an
+ * external-link icon. They are a different application at a different
+ * origin, and navigating the host app away to reach them would lose
+ * whatever the user was doing here. Sign out is the only action that acts
+ * in place, which is why it sits alone in the footer rather than as a fourth
+ * item in the same list as three navigations.
+ *
+ * The session list is account-wide, not scoped to this service - see
+ * `ConnectUserSession`'s doc comment in `types.ts`. Appearance only renders
+ * when both `theme` and `onThemeChange` are supplied.
+ *
+ * Renders nothing when signed out - pair it with `<ConnectLoginButton>`, which
+ * renders nothing when signed *in*, and the two swap cleanly with no branch in
+ * your own layout.
+ *
+ * On the HeroUI shape: the trigger is a plain `<Button>` as a **direct child**
+ * of `<Modal>`, not wrapped in `<Modal.Trigger>`. `Dropdown.Trigger` (and by
+ * the same construction, `Modal.Trigger`) is itself a React Aria `Button`, so
+ * wrapping one produces a button inside a button - invalid markup, and press
+ * handling stops working. Kept uncontrolled (no `isOpen`/`onOpenChange`),
+ * matching `<ConnectAppsGrid>`'s own `<Modal>` - nothing here needs to close
+ * the modal programmatically; sign-out uses `slot="close"` instead.
+ */
+export declare function ConnectUserMenu({ compact, onSignOut, className, theme, onThemeChange, }: ConnectUserMenuProps): import("react").JSX.Element | null;
+/**
+ * The "Manage subscription" action on its own, for layouts that want it
+ * visible rather than buried in the account menu - a billing banner, an empty
+ * state, a settings page.
+ */
+export declare function ConnectManageSubscriptionButton({ className }: Readonly<{
+    className?: string;
+}>): import("react").JSX.Element;
+/**
+ * Invoices and payment history, on Connect.
+ *
+ * A deep link rather than a component that lists them, and that is not a
+ * placeholder: nothing in `/api/v1/service/*` exposes invoices, so an SDK-side
+ * list would have nothing to read. It is also the right answer regardless -
+ * a GST tax invoice is a legal document with a fixed format, downloadable and
+ * emailed from one place, and a partner-rendered copy of one would be a second
+ * version of a record that must have exactly one.
+ */
+export declare function ConnectInvoicesButton({ className }: Readonly<{
+    className?: string;
+}>): import("react").JSX.Element | null;
+/**
+ * The "Profile" action on its own - the third of the three Connect
+ * destinations, alongside `ConnectManageSubscriptionButton` (Billing) and
+ * `ConnectHomeButton`.
+ *
+ * It was reachable only from inside `ConnectUserMenu`, which meant an app that
+ * builds its own account menu had to hardcode `${appUrl}/profile` to offer it.
+ */
+export declare function ConnectProfileButton({ className }: Readonly<{
+    className?: string;
+}>): import("react").JSX.Element | null;
+/** A plain "Open Connect" button, for a footer or a help menu. */
+export declare function ConnectHomeButton({ className }: Readonly<{
+    className?: string;
+}>): import("react").JSX.Element;
+/** Sign out on its own, for a settings page that wants it as a destructive row. */
+export declare function ConnectSignOutButton({ onSignOut, className, }: Readonly<{
+    onSignOut?: () => void;
+    className?: string;
+}>): import("react").JSX.Element | null;