@eifi1/ui-kit 0.54.0 → 0.56.0

package/src/billing/billing-lock.ts

@@ -1,108 +0,0 @@
-import type { ReactNode } from "react";
-
-import type { LabelOverride } from "../i18n/kit-labels";
-import type { WriteLockHold, WriteLockKind } from "../components/write-lock";
-import { useBillingLabels } from "./billing-labels";
-import type { BillingLabels } from "./billing-labels";
-
-/** One reason an app may lock writing: whether it locks now, its one sentence, and what
- *  kind of lock it is. */
-export interface WriteLockSource {
-  locked: boolean;
-  /** The sentence a locked commit shows ("Not possible in the demo."). */
-  reason?: ReactNode;
-  /**
-   * `"demo"`, `"billing"`, or the app's own (§12.36): a control's `commit` may be exempt
-   * from a kind — `COMMIT_EXCEPT_BILLING`. Left out, no control can be exempt from it.
-   */
-  kind?: WriteLockKind;
-}
-
-/** What {@link combineWriteLocks} answers: the props of one `WriteLockProvider`. */
-export interface CombinedWriteLock {
-  locked: boolean;
-  /** The first locked source's reason; `undefined` while nothing locks. */
-  reason: ReactNode | undefined;
-  /** EVERY locked source, kind and reason, in the order given (§12.36) — so a control
-   *  exempt from billing under the demo's lock and billing's still finds the demo's. */
-  holds: WriteLockHold[];
-}
-
-/**
- * Several reasons to lock writing, as ONE `WriteLockProvider` (docs/billing-harmonization.md
- * §12.6): the demo's read-only data and billing's read-only lapse, in keksdose's case on
- * the same budget page.
- *
- *     const demo = useDemoLabels();
- *     const billingReason = useBillingLockReason({ guest: !isOwner, item: budget.name });
- *     <WriteLockProvider {...combineWriteLocks([
- *       { locked: demoReadOnly, reason: demo.writeLocked },
- *       { locked: budget.locked === "billing", reason: billingReason },
- *     ])}>
- *
- * WHY NOT TWO NESTED PROVIDERS: the nearest provider wins (write-lock.tsx), and an inner
- * `locked={false}` REOPENS an outer lock on purpose — a viewer's own notes on a shared
- * curve. So `<Demo locked><Billing locked={false}>` would unlock the demo's data, and an
- * app would have to mount the inner provider only while it locks. One provider fed by
- * this function has no such order to get wrong.
- *
- * Locked when any source is; the reason is the FIRST locked source's, so list them in the
- * order the server refuses them (§12.3): the demo's 403 before billing's 402. One sentence,
- * not two joined: a tooltip answers "why can't I?" once, and in practice one source locks
- * at a time — demo users have no subscription row and are never gated (§12.7). `null`,
- * `undefined` and `false` entries are skipped, for `cond && { … }`.
- *
- * 0.33 (§12.36): name each source's `kind` — `{ locked, reason, kind: "demo" }`,
- * {@link useBillingWriteLock} for billing — and `holds` carries every locked one, in
- * order, so the kit's parts that a lapsed plan still allows (removing access, the
- * account's own settings, an operator's plan change) reopen under billing by themselves
- * while the demo's lock still holds them.
- */
-export function combineWriteLocks(
-  sources: ReadonlyArray<WriteLockSource | null | undefined | false>,
-): CombinedWriteLock {
-  const holds: WriteLockHold[] = [];
-  for (const source of sources) {
-    if (source && source.locked) holds.push({ kind: source.kind, reason: source.reason });
-  }
-  return { locked: holds.length > 0, reason: holds[0]?.reason, holds };
-}
-
-export interface BillingLockReasonOptions {
-  /**
-   * The reader is a GUEST in someone else's item (§12.6): the reason never says why
-   * beyond "for now", because the owner's payment status is the owner's personal data —
-   * "This budget is read-only for now; its owner can lift that." Default false: the
-   * reader is the payer, "Your plan has ended. Choose a plan to make changes again."
-   */
-  guest?: boolean;
-  /** A guest's item, by its own name ("Household 2026"). Ignored for the payer. */
-  item?: string;
-  labels?: LabelOverride<BillingLabels>;
-}
-
-/**
- * The billing lock's sentence for a `WriteLockProvider` (§3.3), in the `billing` words of
- * the nearest provider: the payer's `lockReason`, or a guest's `guestReadOnly`. Feed it
- * to {@link combineWriteLocks} beside the demo's.
- */
-export function useBillingLockReason(options: BillingLockReasonOptions = {}): string {
-  const labels = useBillingLabels(options.labels);
-  return options.guest ? labels.guestReadOnly(options.item) : labels.lockReason;
-}
-
-/**
- * Billing's lock as one source for {@link combineWriteLocks}: `{ locked, reason, kind:
- * "billing" }`, the reason the payer's or a guest's as {@link useBillingLockReason} says
- * it (§12.36). The kind is what lets the kit's parts that §3.3 and §12.13 allow stay live
- * under it.
- *
- *     <WriteLockProvider {...combineWriteLocks([
- *       { locked: demoReadOnly, reason: demo.writeLocked, kind: "demo" },
- *       useBillingWriteLock(budget.locked === "billing", { guest: !isOwner, item: budget.name }),
- *     ])}>
- */
-export function useBillingWriteLock(locked: boolean, options: BillingLockReasonOptions = {}): WriteLockSource {
-  const reason = useBillingLockReason(options);
-  return { locked, reason, kind: "billing" };
-}

package/src/billing/billing-overview.ts

@@ -1,157 +0,0 @@
-import type { DateInput } from "../lib/format";
-import type { SubscriptionStatus } from "./billing-labels";
-import type { BillingCurrency, BillingInterval } from "./plan-price";
-
-/**
- * The billing API's shapes the kit's parts read (docs/billing-harmonization.md §4,
- * §14.5) — server-kit 0.7's schemas, field for field under their wire names, for an app
- * whose client is hand-written (kastlan's `features/billing/types.ts`, Kurvenschmiede's
- * `shared/types/billing.ts`, which no mirror test covers).
- */
-
-/** Where a row's current state came from (server-kit's `SubscriptionSource`, §3.2). */
-export type SubscriptionSource = "trial" | "provider" | "manual" | "beta";
-
-/** `GET /billing/overview` (§4): where the payer's subscription stands, what the plan
- *  allows and what is used. Only ever the payer's own (§12.6). */
-export interface BillingOverview {
-  /** The plan's code, lowercase (§3.1). */
-  plan: string;
-  status: SubscriptionStatus;
-  source: SubscriptionSource;
-  /** False: read-only (§3.3). */
-  in_good_standing: boolean;
-  trial_ends_at: DateInput;
-  /** When the free grant ends; null: no end. */
-  comped_until: DateInput;
-  current_period_end: DateInput;
-  cancel_at_period_end: boolean;
-  /** Dimension → limit; null for unlimited. */
-  limits: Record<string, number | null>;
-  /** What the payer has, per dimension (§12.15). */
-  usage: Record<string, number>;
-  currency: BillingCurrency;
-  /**
-   * 0.7 (§14.5): the provider has a customer for this payer, whatever the status or the
-   * source — `SubscriptionActions`' `atProvider`. False: "nothing to manage yet", and a
-   * portal request would answer `409 billing_not_at_provider`.
-   */
-  at_provider: boolean;
-  /**
-   * 0.39 (server-kit 0.12, §15.2.10): the price the payer pays at the provider — its
-   * plan, period and currency — or null with none (a trial, a grant without a purchase).
-   * Under a grant the row keeps the grant's plan, status and source (§12.11), so this
-   * is what shows that a switch landed; `checkoutFingerprint` reads it.
-   */
-  paid: PaidPrice | null;
-  /**
-   * 0.40 (server-kit 0.13, §15.2.10): a provider subscription runs — the server's own
-   * rule, the one its checkout (409 `billing_already_subscribed`) and switch (409
-   * `billing_not_subscribed`) routes apply, so exactly one of the two answers. While it
-   * is true a `PlanPicker` pick opens `PlanSwitchConfirm` (`POST /billing/plan/preview`,
-   * then `POST /billing/plan`); while false, the checkout (`POST /billing/checkout`).
-   * Read it instead of mirroring the rule on the client. Optional so an overview from
-   * server-kit before 0.13 still type-checks; absent, read it as false.
-   */
-  switching?: boolean;
-  /**
-   * 0.42 (server-kit 0.14, §16.3): who may open the provider's portal. `"buyer_only"`:
-   * the row has a buyer (`provider_payer_user_id`) and the viewer isn't them — every
-   * portal target would answer `403 billing_portal_buyer_only`, so "Payment and
-   * invoices" is a caption naming the buyer and "Cancel subscription" is the in-app
-   * cancel (`POST /billing/cancel`). `"open"`, or absent (server-kit before 0.14): as
-   * before. Pass it to `SubscriptionActions`' `portal`.
-   */
-  portal?: BillingPortalAccess;
-  /**
-   * 0.42 (§16.3, §16.7 G): the buyer's display name, for the caption under
-   * `"buyer_only"`; `null` when the buyer is gone or no longer a member of the company,
-   * and the words then say "the admin who bought the subscription".
-   */
-  buyer_name?: string | null;
-}
-
-/** 0.42 (§16.3): `BillingOverview.portal` and `BillingStanding.portal` — server-kit's
- *  `Literal["open", "buyer_only"]`. */
-export type BillingPortalAccess = "open" | "buyer_only";
-
-/**
- * 0.42 (§16.2 decision 5, §16.7 E): whether the payer's free grant runs WITHOUT AN END —
- * an operator's grant (`source: "manual"`) with `comped_until` empty. A purchase under
- * it leaves the row `comped` on the grant's plan (§12.11): only the paid price moves,
- * so the payer would pay for a plan that never applies. Pass it to `PlanPicker`'s and
- * `PlanSwitchConfirm`'s `permanentGrant`, which warn before the checkout or the switch.
- *
- * `source` is checked explicitly, not implied by the missing date: Kurvenschmiede's
- * pre-launch beta rows are `comped` with `comped_until` null too (their launch-plus-12-
- * months end isn't written yet, §3.2), and they are not permanent. A grant with an end
- * gets no warning either: the bought plan applies from that end on.
- */
-export function isPermanentGrant(
-  overview: Pick<BillingOverview, "status" | "source"> & { comped_until?: BillingOverview["comped_until"] },
-): boolean {
-  return overview.status === "comped" && overview.source === "manual" && overview.comped_until == null;
-}
-
-/** 0.39: what the payer pays at the provider (server-kit's `PaidPrice`, §15.2.10),
- *  read from the row's `provider_price_id`. */
-export interface PaidPrice {
-  /** The plan's code, lowercase. */
-  plan: string;
-  interval: BillingInterval;
-  currency: BillingCurrency;
-}
-
-/** 0.39: `POST /billing/plan/preview` and `POST /billing/plan`'s body (server-kit's
- *  `PlanSwitchRequest`, §15.2.10) — the plan and period to switch to. The currency stays
- *  the subscription's. */
-export interface PlanSwitchRequest {
-  plan: string;
-  interval: BillingInterval;
-}
-
-/**
- * 0.39: what a plan switch costs — or did (server-kit's `PlanSwitchPreview`, §15.2.10):
- * Paddle's preview, prorated at once, both routes' answer. `PlanSwitchConfirm` shows it
- * before the payer agrees.
- */
-export interface PlanSwitchPreview {
-  /** The subscription's currency. */
-  currency: BillingCurrency;
-  /** Charged at once, in minor units: an upgrade's prorated difference — or, negative, a
-   *  downgrade's credit to the customer's balance, which Paddle takes off the next
-   *  charges. */
-  now_minor: number;
-  /** The next regular charge, in minor units. */
-  next_minor?: number | null;
-  /** When it is charged; null when Paddle names no date. */
-  next_billed_at?: string | null;
-  /** The plan and period switched to. */
-  plan: string;
-  interval: BillingInterval;
-  /** The dimensions whose usage is over the new plan's limit (§3.4: a limit gates
-   *  creation only — the switch is allowed). */
-  over_limit: string[];
-  /** The new plan's limits; null for unlimited. */
-  limits: Record<string, number | null>;
-  /** What the payer has, per dimension. */
-  usage: Record<string, number>;
-}
-
-/**
- * Where in the provider's portal a request lands (server-kit's `PortalTarget`, §14.5):
- *
- * - `overview` — "Payment and invoices";
- * - `cancel` — "Cancel subscription": the subscription's cancel link (§12.26);
- * - `payment_method` — the payment-failed banner's "Update payment method".
- *
- * The server answers the overview where Paddle gives no such link (a paused or cancelled
- * subscription).
- */
-export type PortalTarget = "overview" | "cancel" | "payment_method";
-
-/** `POST /billing/portal`'s optional body (server-kit's `PortalRequest`, §14.5); left
- *  out, the overview. The answer is `{url}`, a fresh link that is never stored. */
-export interface PortalRequest {
-  target?: PortalTarget;
-}

package/src/billing/billing-standing.ts

@@ -1,80 +0,0 @@
-import { toDate } from "../lib/format";
-import type { DateInput } from "../lib/format";
-import type { SubscriptionStatus } from "./billing-labels";
-import type { BillingPortalAccess } from "./billing-overview";
-
-/**
- * What a device knows of the payer's standing — the fields of `GET /billing/overview`
- * (docs/billing-harmonization.md §4) that decide the read-only lock, under their wire
- * names. Pass the overview as it came; the other fields are ignored.
- */
-export interface BillingStanding {
-  status: SubscriptionStatus;
-  /** The server's answer at the time of the read (§3.3). */
-  in_good_standing: boolean;
-  /** When a trial ends (§3.2). Empty for a pure guest whose trial has not started (§12.9). */
-  trial_ends_at?: DateInput;
-  /** When a free grant ends: a beta user's 12 months, an operator's grant. Empty for a
-   *  grant without an end (§12.8). */
-  comped_until?: DateInput;
-  /** 0.42 (server-kit 0.14, §16.7 A): who may open the provider's portal, as the
-   *  overview's `portal` — `GET /billing/status` says it too, for the payment-failed
-   *  banner (`BillingBanner`'s `portal`). Absent: `"open"`. */
-  portal?: BillingPortalAccess;
-  /** 0.42 (§16.7 A): the buyer's display name, as the overview's `buyer_name`; `null`
-   *  when the buyer is gone or has left the company. */
-  buyer_name?: string | null;
-}
-
-/**
- * The moment this payer's data becomes read-only by itself, known IN ADVANCE — or `null`
- * when no date says so (docs/billing-harmonization.md §12.5).
- *
- * A device writes locally first and sends later (keksdose's outbox, an encrypted budget
- * always), so a lock that only arrives with the server's 402 comes after the UI already
- * said "saved" — keksdose's phantom save (dev#496). The two dates that end good standing
- * on a schedule are in the overview, so the device locks itself on time, offline too:
- * a trial at `trial_ends_at`, a grant at `comped_until`. Only `past_due` → `expired`
- * depends on the provider's retries and waits for the next sync.
- */
-export function billingLockAt(standing: BillingStanding): Date | null {
-  if (standing.status === "trialing") return toDate(standing.trial_ends_at ?? null);
-  if (standing.status === "comped") return toDate(standing.comped_until ?? null);
-  return null;
-}
-
-/**
- * Whether the payer's data is read-only at `now` (default: the present moment): the
- * server already said so (`in_good_standing: false`), or a date from
- * {@link billingLockAt} has passed since the overview was read. Mirror it into the app's
- * offline write gate and its `WriteLockProvider` (§3.3, §12.5).
- *
- * A GUEST's device cannot do this for the owner: the owner's dates are the owner's
- * personal data (§12.6). An item shared with a guest carries `locked: "billing" | null`,
- * which the guest's device mirrors as it comes.
- */
-export function isBillingReadOnly(standing: BillingStanding, now: number | Date = Date.now()): boolean {
-  if (!standing.in_good_standing) return true;
-  const at = billingLockAt(standing);
-  const instant = typeof now === "number" ? now : now.getTime();
-  return at !== null && at.getTime() <= instant;
-}
-
-const DAY = 86_400_000;
-
-/**
- * Whole calendar days from `now` to `endsAt`, in the device's time zone — 0 on the day
- * itself (and after it), 1 the day before — or `null` for no readable date. The count a
- * trial or grant banner says ("ends tomorrow", "ends in 5 days"), from the day a reader
- * lives in rather than from 24-hour blocks: a trial ending at 01:00 tomorrow ends
- * "tomorrow", not "today".
- */
-export function billingDaysLeft(endsAt: DateInput, now: number | Date = Date.now()): number | null {
-  const end = toDate(endsAt);
-  if (!end) return null;
-  const from = typeof now === "number" ? new Date(now) : now;
-  const endDay = new Date(end.getFullYear(), end.getMonth(), end.getDate()).getTime();
-  const fromDay = new Date(from.getFullYear(), from.getMonth(), from.getDate()).getTime();
-  // `round`, not `floor`: a day across a DST change is 23 or 25 hours long.
-  return Math.max(0, Math.round((endDay - fromDay) / DAY));
-}

package/src/billing/cancel-request.ts

@@ -1,97 +0,0 @@
-import { useEffect, useState } from "react";
-
-/**
- * What the payer asked for in the app (0.43, kastlan `18bf4c0`): `"cancel"` after
- * `POST /billing/cancel` answered 204, `"resume"` after `POST /billing/resume` — while the
- * overview still shows the old `cancel_at_period_end`, until the provider's
- * `subscription.updated` has landed (§16.3). `null`: nothing asked, or the row has moved.
- */
-export type CancelRequested = "cancel" | "resume" | null;
-
-/** How long a request waits for the provider's webhook: `useCheckoutProcessing`'s bound. */
-const WAIT_FOR = 10 * 60_000;
-
-/** What the page shows for the row as read now — `CancelRequest.view(rowScheduled)`. */
-export interface CancelRequestView {
-  /** For `SubscriptionActions`' `cancelRequested`. */
-  requested: CancelRequested;
-  /** What the plan line says — the asked-for state until the row moves, then the row's:
-   *  "Cancels on …" at once after a cancel, "Renews on …" after "Keep subscription". */
-  cancelScheduled: boolean;
-  /** Call on the 204 of a cancel or of a resume. A cancel and its undo both asked before
-   *  the row moved cancel out. */
-  noteAsked: () => void;
-}
-
-export interface CancelRequest {
-  /** Read the overview again every few seconds while this is true — the overview query's
-   *  `waiting` (kastlan's `useBillingOverview({ waiting })`, a `refetchInterval` inside) —
-   *  so the page follows the provider. Needs no overview data: pass it to the query.
-   *  False again after `timeoutMs` with no move of the row. */
-  waiting: boolean;
-  /**
-   * The row as read now (the overview's `cancel_at_period_end`; `undefined` while it
-   * loads) → what the page shows. Call it during render, after the query: when the row
-   * has moved past what was asked, it drops the request (React's "adjust state while
-   * rendering" pattern), so `waiting` turns false and the query stops polling.
-   */
-  view: (rowScheduled: boolean | null | undefined) => CancelRequestView;
-}
-
-/**
- * The in-app cancel's follow-up (0.43, kastlan's derivation in `18bf4c0`): after "Cancel
- * subscription now" or "Keep subscription" the server answers 204 at once, but the row's
- * `cancel_at_period_end` only changes when the provider's webhook lands. Until then the
- * page shows what was asked for, and a second press would ask the provider again.
- *
- * The state lives in the hook and needs no overview at construction, so it goes BEFORE
- * the overview query, which reads `waiting`, and the view comes after it — the overview
- * read once (build review 0.43, kastlan B2; kastlan `subscription-section.tsx:74-92`):
- *
- *     const request = useCancelRequest();
- *     const { data } = useBillingOverview({ waiting: request.waiting });
- *     const view = request.view(data?.cancel_at_period_end);
- *     <p>{standingLine({ ...data, cancel_at_period_end: view.cancelScheduled })}</p>
- *     <SubscriptionActions
- *       cancelAtPeriodEnd={data.cancel_at_period_end}
- *       cancelRequested={view.requested}
- *       onResume={() => resume.mutate(undefined, { onSuccess: view.noteAsked })}
- *       …
- *     />
- *
- * **Bounded,** as `useCheckoutProcessing` is (FLW-6): after `timeoutMs` (10 minutes)
- * with no move of the row the request is dropped — the polling stops and the page shows
- * the row as it is. Unbounded, a webhook that never landed kept kastlan re-reading the
- * overview every 3 s for as long as the page was open, which also kept a Cloud Run
- * instance awake, and the plan line said "Cancels on …" for a row that never moved.
- */
-export function useCancelRequest({ timeoutMs = WAIT_FOR }: { timeoutMs?: number } = {}): CancelRequest {
-  // What was asked, kept with the row's state it was asked against and when.
-  const [asked, setAsked] = useState<{ scheduled: boolean; at: number } | null>(null);
-  useEffect(() => {
-    if (asked === null) return;
-    // Only THIS ask: one that a later ask or the row has replaced is not dropped twice.
-    const timer = setTimeout(
-      () => setAsked((current) => (current === asked ? null : current)),
-      Math.max(0, asked.at + timeoutMs - Date.now()),
-    );
-    return () => clearTimeout(timer);
-  }, [asked, timeoutMs]);
-  const view = (row: boolean | null | undefined): CancelRequestView => {
-    // Not read yet: nothing to show against, and nothing to drop.
-    if (row === undefined || row === null) return { requested: null, cancelScheduled: false, noteAsked: () => {} };
-    // The row has moved: it says the rest. Adjusted during render, React's pattern for
-    // state that follows a prop.
-    if (asked !== null && asked.scheduled !== row) setAsked(null);
-    const open = asked !== null && asked.scheduled === row;
-    return {
-      requested: open ? (row ? "resume" : "cancel") : null,
-      cancelScheduled: open ? !row : row,
-      noteAsked: () => {
-        const at = Date.now();
-        setAsked((a) => (a !== null && a.scheduled === row ? null : { scheduled: row, at }));
-      },
-    };
-  };
-  return { waiting: asked !== null, view };
-}

package/src/billing/cancel-subscription.tsx

@@ -1,98 +0,0 @@
-import { useKitLabels } from "../i18n/kit-labels";
-import type { LabelOverride } from "../i18n/kit-labels";
-import { DEFAULT_COMMON_LABELS } from "../i18n/shared-labels";
-import { useDayFormatter } from "../lib/day-format";
-import type { DateInput } from "../lib/format";
-import { Button } from "../components/button";
-import { DialogFrame } from "../components/dialog-frame";
-import { COMMIT_EXCEPT_BILLING } from "../components/write-lock";
-import { useBillingLabels } from "./billing-labels";
-import type { BillingLabels } from "./billing-labels";
-
-export interface CancelSubscriptionConfirmProps {
-  open: boolean;
-  /** The admin dismissed it — Back, Escape, the backdrop. Confirm leaves it open: close it
-   *  once `POST /billing/cancel` answers. 0.52: every other kit dialog's `onClose`
-   *  (CONTRIBUTING §4; refactor audit 2026-10-30, API-5); required since 0.53 removed
-   *  `onOpenChange` (deprecated in 0.52). */
-  onClose: () => void;
-  /** The overview's `current_period_end`: the day the subscription ends, in a sentence —
-   *  the `<UiKitProvider formatDate>` (the app's date preference) when it set one, else the
-   *  kit's `formatDate`, `"medium"`, in the provider's locale and `timeZone` (0.52). */
-  periodEnd: DateInput;
-  /** Confirm: the app's `POST /billing/cancel` (server-kit 0.14, §16.3). */
-  onConfirm: () => void;
-  /** The cancel is under way: Confirm's spinner, no second press, and neither Escape,
-   *  the backdrop nor Back closes it. */
-  pending?: boolean;
-  /** The date's locale. Default: the provider's. */
-  locale?: string;
-  /** Prop > `<UiKitProvider labels={{ billing }}>` > English. */
-  labels?: LabelOverride<BillingLabels>;
-}
-
-/**
- * The in-app cancel's confirm (docs/billing-harmonization.md §16.2 decision 2, §16.4,
- * ui-kit 0.42): "Cancel subscription" for an admin the provider's portal doesn't open for
- * (`SubscriptionActions`' `portal="buyer_only"` → `onCancelInApp`). It names the day the
- * subscription ends — "Your subscription ends on 9 Nov 2026. Until then everything works
- * as before." — and its button reads "Cancel subscription now" (German "Jetzt kündigen",
- * the confirmation button of §312k BGB).
- *
- *     <CancelSubscriptionConfirm
- *       open={asking}
- *       onClose={() => setAsking(false)}
- *       periodEnd={overview.current_period_end}
- *       pending={cancel.isPending}
- *       onConfirm={() => cancel.mutate()}
- *     />
- *
- * The cancel is at the period's end (Paddle's `cancel`, not immediately); the row follows
- * by webhook (`cancel_at_period_end`), as after a cancel in the portal, and
- * `SubscriptionActions` then offers "Keep subscription" (`onResume`).
- *
- * It takes no billing lock (`COMMIT_EXCEPT_BILLING` built in, §3.3): a read-only payer
- * may always cancel. A demo lock still holds it, as the server's demo guard does. The kit
- * sends no request.
- */
-export function CancelSubscriptionConfirm({
-  open,
-  onClose,
-  periodEnd,
-  onConfirm,
-  pending = false,
-  locale: localeProp,
-  labels: labelsProp,
-}: CancelSubscriptionConfirmProps) {
-  const labels = useBillingLabels(labelsProp);
-  const common = useKitLabels("common", DEFAULT_COMMON_LABELS);
-  const day = useDayFormatter(undefined, localeProp);
-
-  return (
-    <DialogFrame
-      open={open}
-      title={labels.cancelConfirmTitle}
-      description={labels.cancelConfirmBody(day(periodEnd))}
-      onClose={onClose}
-      busy={pending}
-      data-cancel-subscription-confirm=""
-      actions={(close) => (
-        <>
-          <Button variant="secondary" onClick={close} disabled={pending}>
-            {common.back}
-          </Button>
-          <Button
-            variant="danger"
-            commit={COMMIT_EXCEPT_BILLING}
-            pending={pending}
-            onClick={() => {
-              if (!pending) onConfirm();
-            }}
-          >
-            {labels.cancelConfirmAction}
-          </Button>
-        </>
-      )}
-    />
-  );
-}