@checkbox-site/node 0.2.5 → 0.2.7

package/dist/client.d.ts

@@ -45,7 +45,7 @@ export interface Checkbox extends ResourceInstances {
  */
 export declare class Checkbox implements RequestSender {
     #private;
-    static readonly VERSION = "0.2.5";
+    static readonly VERSION = "0.2.7";
     static readonly API_VERSION = "2026-10-30";
     static readonly errors: typeof errors;
     static readonly webhooks: Webhooks;

package/dist/generated/operations.d.ts

@@ -3098,7 +3098,7 @@ export declare class ChecksResource extends Resource {
     /**
      * Check a subscription lifecycle email.
      *
-     * Checks the content of an acknowledgment (welcome) email, trial-ending reminder, renewal reminder, price-change notice, yearly terms reminder or cancellation confirmation against the requirements for that notice (renewal terms, amount, frequency, how to cancel, trial cancellation). The email is modelled as sent on time, so the verdict is about content; get send dates from checkNoticeSchedule. Prices are judged against what Stripe charges: with `site` (or, without it and without a price in terms, the account's one site with Stripe connected) the plan fields come from the site's plans and the email is matched to the plan it names ("Annual") first; a price that contradicts it fails, and `warnings` say which site and plan were used. Without `site`, a price you send in terms is judged as sent; when it differs from every plan of that site, the result is at most needs_review and Next is update_setup (update the site's plans first). Returns `required_by` (requirements that make the email mandatory for this plan) and a `template` that passes the checks, with {{merge_tags}}, verified by the engine. Stateless and deterministic: nothing is stored, the same input on the same as_of date gives the same verdicts. Every verdict comes from the Checkbox rules engine over the legal catalog (federal ROSCA / EFTA plus the state automatic-renewal laws); the response carries rules_version, catalog_version and a disclaimer (not legal advice). Read `verdict`, then `next_action`: it tells you exactly what to change and to call the check again until verdict is pass.
+     * Checks the content of an acknowledgment (welcome) email, trial-ending reminder, renewal reminder, price-change notice, yearly terms reminder or cancellation confirmation against the requirements for that notice (renewal terms, amount, frequency, how to cancel, trial cancellation). The email is modelled as sent on time, so the verdict is about content; get send dates from checkNoticeSchedule. Prices are judged against what Stripe charges: with `site` (or, without it and without a price in terms, the account's one site with Stripe connected) the plan fields come from the site's plans and the email is matched to the plan it names ("Annual") first; a price that contradicts it fails, and `warnings` say which site and plan were used. Without `site`, a price you send in terms is judged as sent; when it differs from every plan of that site, the verdict is still judged with the terms you sent and a `site_plans_differ` warning says to update the site's plans (update_setup) once the change is deployed. Returns `required_by` (requirements that make the email mandatory for this plan) and a `template` that passes the checks, with {{merge_tags}}, verified by the engine. Stateless and deterministic: nothing is stored, the same input on the same as_of date gives the same verdicts. Every verdict comes from the Checkbox rules engine over the legal catalog (federal ROSCA / EFTA plus the state automatic-renewal laws); the response carries rules_version, catalog_version and a disclaimer (not legal advice). Read `verdict`, then `next_action`: it tells you exactly what to change and to call the check again until verdict is pass.
      *
      * @see POST /v1/checks/email (operation `checkEmail`, scope `checks:read`)
      */
@@ -3323,7 +3323,7 @@ export declare class TestCredentialsResource extends Resource {
     /**
      * Store a billing test-mode key.
      *
-     * Stores the site's Stripe TEST-mode restricted key (rk_test_…), after checking it with Stripe the way the dashboard's Connect Stripe does. An agent may call this itself once the owner approved the setup; every store is logged on the site's setup timeline and Billing connection line, and the human can revoke it in one click. Live keys are refused (test_key_not_test_mode: a human adds live keys in the dashboard); the owner must have ticked "Let your agent store a Stripe test-mode key" on the approval page of the agent's sign-in or connection (else test_key_declined); a key whose Stripe account looks like another site's is refused with billing_account_mismatch (with confirm_account_mismatch: true the key is connected on hold until a person confirms the account in the dashboard; only a person can confirm it); secret keys (sk_test_…) are refused (test_key_not_restricted). On a test-mode site without a Stripe connection the key also becomes the site's Stripe connection: one key for checks, fixes (only after the human approves each) and test runs. The key's checklist: Customers: Write, Products: Read, Prices: Read, Coupons: Read, Subscriptions: Write, Test clocks: Write, Customer portal: Write, Checkout Sessions: Write, Payment Links: Write, Webhook Endpoints: Write. Replaces an existing key. Next: createTestRun.
+     * Stores the site's Stripe TEST-mode restricted key (rk_test_…), after checking it with Stripe the way the dashboard's Connect Stripe does. An agent may call this itself once the owner approved the setup; every store is logged on the site's setup timeline and Billing connection line, and the human can revoke it in one click. Live keys are refused (test_key_not_test_mode: a human adds live keys in the dashboard); the owner must have ticked the box “Let your agent store a Stripe test-mode restricted key for this project” (agent sign-in) or “Let this app store a Stripe test-mode restricted key for your sites” (app connection) (checkbox id consent-stripe-test-key) on the approval page of the agent's sign-in or connection (else test_key_declined); a key whose Stripe account looks like another site's is refused with billing_account_mismatch (with confirm_account_mismatch: true the key is connected on hold until a person confirms the account in the dashboard; only a person can confirm it); secret keys (sk_test_…) are refused (test_key_not_restricted). On a test-mode site without a Stripe connection the key also becomes the site's Stripe connection: one key for checks, fixes (only after the human approves each) and test runs. The key's checklist: Customers: Write, Products: Read, Prices: Read, Coupons: Read, Subscriptions: Write, Test clocks: Write, Customer portal: Write, Checkout Sessions: Write, Payment Links: Write, Webhook Endpoints: Write. Replaces an existing key. Next: createTestRun.
      *
      * @param site Unique identifier of the site (site_…).
      * @see POST /v1/sites/{site}/test_credentials (operation `createTestCredential`, scope `test_runs:write`)

package/dist/generated/operations.js

@@ -2622,7 +2622,7 @@ export class ChecksResource extends Resource {
     /**
      * Check a subscription lifecycle email.
      *
-     * Checks the content of an acknowledgment (welcome) email, trial-ending reminder, renewal reminder, price-change notice, yearly terms reminder or cancellation confirmation against the requirements for that notice (renewal terms, amount, frequency, how to cancel, trial cancellation). The email is modelled as sent on time, so the verdict is about content; get send dates from checkNoticeSchedule. Prices are judged against what Stripe charges: with `site` (or, without it and without a price in terms, the account's one site with Stripe connected) the plan fields come from the site's plans and the email is matched to the plan it names ("Annual") first; a price that contradicts it fails, and `warnings` say which site and plan were used. Without `site`, a price you send in terms is judged as sent; when it differs from every plan of that site, the result is at most needs_review and Next is update_setup (update the site's plans first). Returns `required_by` (requirements that make the email mandatory for this plan) and a `template` that passes the checks, with {{merge_tags}}, verified by the engine. Stateless and deterministic: nothing is stored, the same input on the same as_of date gives the same verdicts. Every verdict comes from the Checkbox rules engine over the legal catalog (federal ROSCA / EFTA plus the state automatic-renewal laws); the response carries rules_version, catalog_version and a disclaimer (not legal advice). Read `verdict`, then `next_action`: it tells you exactly what to change and to call the check again until verdict is pass.
+     * Checks the content of an acknowledgment (welcome) email, trial-ending reminder, renewal reminder, price-change notice, yearly terms reminder or cancellation confirmation against the requirements for that notice (renewal terms, amount, frequency, how to cancel, trial cancellation). The email is modelled as sent on time, so the verdict is about content; get send dates from checkNoticeSchedule. Prices are judged against what Stripe charges: with `site` (or, without it and without a price in terms, the account's one site with Stripe connected) the plan fields come from the site's plans and the email is matched to the plan it names ("Annual") first; a price that contradicts it fails, and `warnings` say which site and plan were used. Without `site`, a price you send in terms is judged as sent; when it differs from every plan of that site, the verdict is still judged with the terms you sent and a `site_plans_differ` warning says to update the site's plans (update_setup) once the change is deployed. Returns `required_by` (requirements that make the email mandatory for this plan) and a `template` that passes the checks, with {{merge_tags}}, verified by the engine. Stateless and deterministic: nothing is stored, the same input on the same as_of date gives the same verdicts. Every verdict comes from the Checkbox rules engine over the legal catalog (federal ROSCA / EFTA plus the state automatic-renewal laws); the response carries rules_version, catalog_version and a disclaimer (not legal advice). Read `verdict`, then `next_action`: it tells you exactly what to change and to call the check again until verdict is pass.
      *
      * @see POST /v1/checks/email (operation `checkEmail`, scope `checks:read`)
      */
@@ -2895,7 +2895,7 @@ export class TestCredentialsResource extends Resource {
     /**
      * Store a billing test-mode key.
      *
-     * Stores the site's Stripe TEST-mode restricted key (rk_test_…), after checking it with Stripe the way the dashboard's Connect Stripe does. An agent may call this itself once the owner approved the setup; every store is logged on the site's setup timeline and Billing connection line, and the human can revoke it in one click. Live keys are refused (test_key_not_test_mode: a human adds live keys in the dashboard); the owner must have ticked "Let your agent store a Stripe test-mode key" on the approval page of the agent's sign-in or connection (else test_key_declined); a key whose Stripe account looks like another site's is refused with billing_account_mismatch (with confirm_account_mismatch: true the key is connected on hold until a person confirms the account in the dashboard; only a person can confirm it); secret keys (sk_test_…) are refused (test_key_not_restricted). On a test-mode site without a Stripe connection the key also becomes the site's Stripe connection: one key for checks, fixes (only after the human approves each) and test runs. The key's checklist: Customers: Write, Products: Read, Prices: Read, Coupons: Read, Subscriptions: Write, Test clocks: Write, Customer portal: Write, Checkout Sessions: Write, Payment Links: Write, Webhook Endpoints: Write. Replaces an existing key. Next: createTestRun.
+     * Stores the site's Stripe TEST-mode restricted key (rk_test_…), after checking it with Stripe the way the dashboard's Connect Stripe does. An agent may call this itself once the owner approved the setup; every store is logged on the site's setup timeline and Billing connection line, and the human can revoke it in one click. Live keys are refused (test_key_not_test_mode: a human adds live keys in the dashboard); the owner must have ticked the box “Let your agent store a Stripe test-mode restricted key for this project” (agent sign-in) or “Let this app store a Stripe test-mode restricted key for your sites” (app connection) (checkbox id consent-stripe-test-key) on the approval page of the agent's sign-in or connection (else test_key_declined); a key whose Stripe account looks like another site's is refused with billing_account_mismatch (with confirm_account_mismatch: true the key is connected on hold until a person confirms the account in the dashboard; only a person can confirm it); secret keys (sk_test_…) are refused (test_key_not_restricted). On a test-mode site without a Stripe connection the key also becomes the site's Stripe connection: one key for checks, fixes (only after the human approves each) and test runs. The key's checklist: Customers: Write, Products: Read, Prices: Read, Coupons: Read, Subscriptions: Write, Test clocks: Write, Customer portal: Write, Checkout Sessions: Write, Payment Links: Write, Webhook Endpoints: Write. Replaces an existing key. Next: createTestRun.
      *
      * @param site Unique identifier of the site (site_…).
      * @see POST /v1/sites/{site}/test_credentials (operation `createTestCredential`, scope `test_runs:write`)

package/dist/generated/types.d.ts

@@ -266,7 +266,7 @@ export type GoLive = {
     /** The steps, in order. */
     steps: Array<{
         /** Stable step key. */
-        key: "verify_domain" | "stripe_terms_url" | "live_stripe_key" | "live_checkout" | "promote_site";
+        key: "verify_domain" | "stripe_terms_url" | "live_stripe_key" | "live_portal_cancel" | "live_checkout" | "deactivate_old_live_link" | "promote_site";
         /** Who takes the step: person (only the owner can: DNS, the Stripe Dashboard, live keys) or agent (a code change). */
         who: "person" | "agent";
         /** The step in plain words. */
@@ -410,7 +410,7 @@ export interface SetupSession {
     }>;
     /** Stripe test mode for lifecycle test runs. */
     stripe: {
-        /** Whether the human ticked “Let your agent store a Stripe test-mode key” on the approval page (device login or OAuth connection). False: the agent may not store one (createTestCredential answers test_key_declined); the human adds it in the dashboard. Sessions started with a key the human made in the dashboard: true. */
+        /** Whether the human ticked the box “Let your agent store a Stripe test-mode restricted key for this project” (agent sign-in) or “Let this app store a Stripe test-mode restricted key for your sites” (app connection) (checkbox id consent-stripe-test-key) on the approval page (device login or OAuth connection). False: the agent may not store one (createTestCredential answers test_key_declined); the human adds it in the dashboard. Sessions started with a key the human made in the dashboard: true. */
         test_key_consent: boolean;
         /** Hint of the restricted test key the CLI found (never the key). */
         test_key_hint: string | null;
@@ -478,8 +478,10 @@ export interface SetupSession {
     }>;
     /** Latest verdict of the test-mode site. */
     compliance: {
-        /** When it was evaluated. Unix timestamp in seconds. */
+        /** When it was evaluated (Unix seconds; a time, not a count). Unix timestamp in seconds. */
         evaluated: number;
+        /** The same time as evaluated, in ISO 8601. */
+        evaluated_at: string;
         /**
          * Deprecated: open failing findings (per check). Read `label` (counted in tasks) and `todo` instead.
          * @deprecated
@@ -603,8 +605,8 @@ export interface SetupSessionUpdate {
         /** Where the subscribe / pay buttons are rendered. */
         pay_buttons?: Array<SetupCodeRef>;
     };
-    /** File the snippet tag was added to. */
-    snippet_installed_in?: string;
+    /** File the snippet tag was added to, or a list of files (e.g. ["app/layout.tsx", "app/account/layout.tsx"]). */
+    snippet_installed_in?: string | Array<string>;
     /** File the API keys were written to (never committed). */
     env_written?: string;
     /** Live-mode site (site_…) you created with the live key, so the checklist tracks its domain verification. */
@@ -676,6 +678,58 @@ export interface SetupVerification {
         reason: string | null;
     } | null;
     next_action: SetupNextAction;
+    /** The same as setup_session.steps, at the top level: the setup checklist, in order. */
+    steps: Array<SetupStep>;
+    /** The same as setup_session.compliance, at the top level: the site's status label and to-do list after this re-check (null before the first evaluation). */
+    compliance: {
+        /** When it was evaluated (Unix seconds; a time, not a count). Unix timestamp in seconds. */
+        evaluated: number;
+        /** The same time as evaluated, in ISO 8601. */
+        evaluated_at: string;
+        /**
+         * Deprecated: open failing findings (per check). Read `label` (counted in tasks) and `todo` instead.
+         * @deprecated
+         */
+        failing: number;
+        /**
+         * Deprecated: open needs-review findings (per check). Read `label` (counted in tasks) and `todo` instead.
+         * @deprecated
+         */
+        needs_review: number;
+        /** The site roll-up label, the same everywhere (dashboard, plan, emails): "2 fixes needed · 1 your call", "Checks pass · 2 live checks pending". */
+        label: string | null;
+        /** The site roll-up status: needs_fix, your_call, incomplete, compliant or not_checked. */
+        status: string | null;
+        /**
+         * Deprecated: open findings (evidence). The to-do list is `todo` (the compliance plan's ordered open tasks).
+         * @deprecated
+         */
+        top_findings: Array<{
+            /** Unique identifier of the finding (fnd_…). */
+            id: string;
+            /** Check id. */
+            check_id: string;
+            /** fail or needs_review. */
+            status: string;
+            /** critical, high, medium or low. */
+            severity: string;
+            /** What is wrong. */
+            title: string;
+        }>;
+        /** The to-do list: the compliance plan's ordered open required tasks (same titles, order and counts as the dashboard, MCP get_site_status and the summary email). */
+        todo?: Array<{
+            /** Plan task id (task_…); its findings are the evidence. */
+            task: string;
+            /** Task key. */
+            key: string;
+            /** Task title, the same as in the plan. */
+            title: string;
+            /** The status the site roll-up counts the task under. */
+            status: "needs_fix" | "not_set_up" | "your_call" | "not_checked";
+            /** Needs a fix, Not set up yet, Your call or Not checked yet. */
+            label: string;
+        }>;
+    } | null;
     setup_session: SetupSession;
 }
 /** Account default retention (sites without their own setting use it). */
@@ -1196,8 +1250,8 @@ export interface SiteTestAccount {
     login_url: string;
     /** Test account email. */
     email: string;
-    /** Test account password (write-only; encrypted at rest). */
-    password: string;
+    /** Test account password (write-only; encrypted at rest). Leave it out for an email-only login (no password field); the stored password is kept when one was saved before. */
+    password?: string;
     /** Custom login steps. */
     login_steps?: Array<ScanStep>;
     /** Optional page on your site that RE-ACTIVATES the test subscription (a test-only route). The cancellation test really cancels the test account; the scanner opens this page after logging in, before cancelling, so every scan starts subscribed. Without it, a scan after a completed cancellation reports "not observed: the test account has no active subscription" (needs review). (Replaces reset_url, now a deprecated alias.) */
@@ -1790,8 +1844,10 @@ export interface CompliancePlan {
     livemode: boolean;
     /** The site. */
     site: string;
-    /** action_required (an agent can apply open tasks now), verifying (changes applied; waiting for confirming observations), compliant (every required check passes or only waits for a live check — an automated assessment, not a legal determination; see compliance.pending_live_checks and coverage), blocked (only human answers ("Your call") or declined critical tasks remain). */
+    /** action_required (an agent can apply open tasks now), verifying (changes applied; waiting for confirming observations), compliant (every required check passes or only waits for a live check — an automated assessment, not a legal determination; see compliance.pending_live_checks and coverage), blocked (only human answers ("Your call") or declined critical tasks remain). The value "compliant" is kept so published SDKs keep working; prefer checks_status ("checks_pass") and show status_label to people: never tell anyone the site "is compliant". */
     status: "action_required" | "verifying" | "compliant" | "blocked";
+    /** The same as status, with "checks_pass" in place of the older value "compliant" (every required check passes or only waits for a live check: an automated assessment, not a legal determination). Read this one in new code. */
+    checks_status?: "action_required" | "verifying" | "checks_pass" | "blocked";
     /** The plan status in words to show a person, from the same counts as the summary ("1 fix needed · 2 to set up", "1 decision for you"; else action_required "Fixes needed", blocked "Your call"), "Checks still running (N)" while checks are still running (verifying), compliant "Checks pass"; while an agent works the site and everything left waits for a deploy or the owner (next_action done_for_now): "Waiting on deploy and you" or "Waiting on deploy". Show this, never the machine value (`compliant` is a status name, not a legal conclusion). */
     status_label?: string;
     /** The evaluation the plan was built from (null before the first check). */
@@ -1947,8 +2003,8 @@ export interface Verification {
     task: string | null;
     /** One task or the whole site. */
     scope: "task" | "site";
-    /** pending (waiting for the confirming scan / re-evaluation), passed (Checkbox observed the expected result: every check passes or does not apply), passed_with_gaps (nothing observed fails, but some checks could not be observed: observed missing_data — not verified), passed_with_notes (nothing observed fails and the task counts as passing, but a check is still needs_review on a part that is not yours to change, such as Stripe's own page layout: see checks), not_checked (a task whose checks could only not be observed yet: nothing to change in the code; next_action says what evidence to provide), pending_live_check (an email whose content passes but that Checkbox has not seen sent for a real event yet: nothing to change; it completes on the first real send or a proof run), failed (it did not: see diff), superseded (this verification did not pass, but newer evidence, such as a test run or a later evaluation, settled the task since: see superseded and follow next_action; nothing to change for it). */
-    status: "pending" | "passed" | "passed_with_gaps" | "passed_with_notes" | "not_checked" | "pending_live_check" | "failed" | "superseded";
+    /** pending (waiting for the confirming scan / re-evaluation), passed (Checkbox observed the expected result: every check passes or does not apply), passed_with_gaps (nothing observed fails, but some checks could not be observed: observed missing_data — not verified), passed_with_notes (nothing observed fails and the task counts as passing, but a check is still needs_review on a part that is not yours to change, such as Stripe's own page layout: see checks), not_checked (a task whose checks could only not be observed yet: nothing to change in the code; next_action says what evidence to provide), pending_live_check (an email whose content passes but that Checkbox has not seen sent for a real event yet: nothing to change; it completes on the first real send or a proof run), needs_review (nothing observed fails, but a check is still undecided, e.g. a cancellation not tried yet or a styling estimate: not done; next_action says what decides it), failed (a check was observed failing: see diff), superseded (this verification did not pass, but newer evidence, such as a test run or a later evaluation, settled the task since: see superseded and follow next_action; nothing to change for it). */
+    status: "pending" | "passed" | "passed_with_gaps" | "passed_with_notes" | "not_checked" | "pending_live_check" | "needs_review" | "failed" | "superseded";
     /** Set when newer evidence settled the task after this verification finished (status superseded). */
     superseded?: {
         /** The task's status in the current plan. */
@@ -2848,13 +2904,13 @@ export interface DisclosureCheckParams {
     trial_days?: number;
     /** Intro / first-period price in major units ("$34.50 for your first box, then $69 every 2 weeks"). Or give `intro_amount` in minor units. */
     intro_price?: number | string;
-    /** Intro / first-period price in minor units. */
+    /** Intro / first-period price in minor units (999 = $9.99), like `amount`. Units never mix: price / intro_price are major units, amount / intro_amount / intro_amount_off are minor units; with `price` in major units, a value under 100 that reads like major units is refused with both ways to send it. */
     intro_amount?: number;
     /** How many billing periods the intro price lasts (default 1). */
     intro_periods?: number;
     /** Intro discount as a percentage off the recurring price (a Stripe coupon's percent_off: 20 for "20% off your first month"). Lasts `intro_periods` billing periods. Give one of intro_price / intro_amount, intro_percent_off or intro_amount_off. */
     intro_percent_off?: number;
-    /** Intro discount as an amount off in minor units (a Stripe coupon's amount_off: 200 for $2.00 off). Lasts `intro_periods` billing periods. */
+    /** Intro discount as an amount off in minor units (a Stripe coupon's amount_off: 200 for $2.00 off), like `amount`, even when the price is sent as `price` in major units. Lasts `intro_periods` billing periods. */
     intro_amount_off?: number;
     /** https URL where subscribers cancel online (used in generated text; a {{cancel_url}} placeholder otherwise). */
     cancel_url?: string;
@@ -2894,6 +2950,8 @@ export interface DisclosureCheckParams {
         /** The form cannot be submitted without ticking it (default true). */
         required?: boolean;
     };
+    /** Where the shopper pays: own_page (a form on this page), stripe_checkout or payment_link (a Stripe-hosted page that collects consent, so no checkbox is needed next to this text; consent is then left to that page and checked with checkStripeCheckoutSession / checkStripePaymentLink). With site, the site's checkout type is used when absent (declared, or Stripe Checkout when the site has a registered Stripe Checkout config). */
+    checkout_type?: "own_page" | "stripe_checkout" | "payment_link";
     /** Evaluate the law as of this date (YYYY-MM-DD, default today). */
     as_of?: string;
     /** Round 23: a site of yours (site_…): the disclosure is judged against the plan it states among the site's plans (the connected Stripe Prices win over plans typed in setup), with the site's merchant name, cancellation URL and jurisdictions, as verifyTask judges it. Plan fields you send are replaced by the plan's. "none" judges only what you send. */
@@ -3007,13 +3065,13 @@ export interface CheckPlanTerms {
     trial_days?: number;
     /** Intro / first-period price in major units ("$34.50 for your first box, then $69 every 2 weeks"). Or give `intro_amount` in minor units. */
     intro_price?: number | string;
-    /** Intro / first-period price in minor units. */
+    /** Intro / first-period price in minor units (999 = $9.99), like `amount`. Units never mix: price / intro_price are major units, amount / intro_amount / intro_amount_off are minor units; with `price` in major units, a value under 100 that reads like major units is refused with both ways to send it. */
     intro_amount?: number;
     /** How many billing periods the intro price lasts (default 1). */
     intro_periods?: number;
     /** Intro discount as a percentage off the recurring price (a Stripe coupon's percent_off: 20 for "20% off your first month"). Lasts `intro_periods` billing periods. Give one of intro_price / intro_amount, intro_percent_off or intro_amount_off. */
     intro_percent_off?: number;
-    /** Intro discount as an amount off in minor units (a Stripe coupon's amount_off: 200 for $2.00 off). Lasts `intro_periods` billing periods. */
+    /** Intro discount as an amount off in minor units (a Stripe coupon's amount_off: 200 for $2.00 off), like `amount`, even when the price is sent as `price` in major units. Lasts `intro_periods` billing periods. */
     intro_amount_off?: number;
     /** https URL where subscribers cancel online (used in generated text; a {{cancel_url}} placeholder otherwise). */
     cancel_url?: string;
@@ -4479,7 +4537,7 @@ export interface TestRun {
     type: "stripe" | "generic";
     /** Stripe runs: mirror (Checkbox mirrors your checkout into test mode and moves a test clock through trial and renewal) or real_checkout (the shopper buys through YOUR checkout on your test deployment, so your own webhook handlers and email code fire: the proof that your real system works). null for generic runs. */
     mode: "mirror" | "real_checkout" | null;
-    /** succeeded means the run finished every step and no step failed (steps may still have warnings to review); incomplete means no step failed, but a step could not finish what it set out to observe (for example the online cancellation could not be completed): not a pass; failed means it stopped early, or finished with a failed step (see failure and steps[].fix). */
+    /** succeeded means the run finished every step and no step failed (steps may still have warnings to review); incomplete means no step failed, but a step could not finish what it set out to observe (for example the online cancellation could not be completed, or a required email never arrived): not a pass; failed means it stopped early, or finished with a failed step (see failure and steps[].fix). */
     status: "queued" | "running" | "succeeded" | "incomplete" | "failed" | "canceled";
     /** The status in plain words, counting steps: "Finished with 6 warnings to review", "Finished with 1 failed step", "Finished: every observed step passed". succeeded with warnings is not a clean pass. */
     status_label: string;
@@ -4512,6 +4570,10 @@ export interface TestRun {
     started: number | null;
     /** When it finished. Unix timestamp in seconds. */
     finished: number | null;
+    /** The same as finished (the name verifications use): when the run finished; null while it runs. Unix timestamp in seconds. */
+    completed: number | null;
+    /** How long the run took, from started (or created) to finished, in seconds; null while it runs. */
+    duration_seconds: number | null;
     /** Lifecycle steps in order. */
     steps: Array<TestRunStep>;
     /** Why the run stopped (failed / canceled runs). */
@@ -4813,7 +4875,7 @@ export interface CompliancePlanSummary {
     livemode: boolean;
     /** The site. */
     site: string;
-    /** action_required (an agent can apply open tasks now), verifying (changes applied; waiting for confirming observations), compliant (every required check passes or only waits for a live check — an automated assessment, not a legal determination; see compliance.pending_live_checks and coverage), blocked (only human answers ("Your call") or declined critical tasks remain). */
+    /** action_required (an agent can apply open tasks now), verifying (changes applied; waiting for confirming observations), compliant (every required check passes or only waits for a live check — an automated assessment, not a legal determination; see compliance.pending_live_checks and coverage), blocked (only human answers ("Your call") or declined critical tasks remain). The value "compliant" is kept so published SDKs keep working; prefer checks_status ("checks_pass") and show status_label to people: never tell anyone the site "is compliant". */
     status: "action_required" | "verifying" | "compliant" | "blocked";
     /** The plan status in words to show a person, from the same counts as the summary ("1 fix needed · 2 to set up", "1 decision for you"; else action_required "Fixes needed", blocked "Your call"), "Checks still running (N)" while checks are still running (verifying), compliant "Checks pass"; while an agent works the site and everything left waits for a deploy or the owner (next_action done_for_now): "Waiting on deploy and you" or "Waiting on deploy". Show this, never the machine value (`compliant` is a status name, not a legal conclusion). */
     status_label?: string;
@@ -5600,7 +5662,7 @@ export declare const ERROR_CODES: {
     readonly test_key_declined: {
         readonly status: 403;
         readonly type: "permission_error";
-        readonly description: "The owner did not tick “Let your agent store a Stripe test-mode key” on the approval page of this agent's sign-in (device login) or connection (OAuth). Nothing was stored. Ask them to allow it on the approval page (sign in again) or to add the key themselves in the dashboard.";
+        readonly description: "The owner did not tick “Let your agent store a Stripe test-mode restricted key for this project” (agent sign-in, device login) or “Let this app store a Stripe test-mode restricted key for your sites” (app connection, OAuth) on the approval page (checkbox id consent-stripe-test-key). Nothing was stored. next_action.url is a one-click allow page for this agent or app (dashboard /allow-stripe-test-key, signed in, no new sign-in); or the human adds the key themselves in the dashboard.";
     };
     readonly test_key_rejected: {
         readonly status: 400;

package/dist/generated/types.js

@@ -21,7 +21,7 @@ export const ERROR_CODES = {
     test_key_missing: { status: 400, type: "invalid_request_error", description: "A Stripe test run needs a Stripe TEST-mode key stored for the site: the agent stores the restricted test key (rk_test_…) with createTestCredential, or a person adds it in the dashboard." },
     test_key_not_test_mode: { status: 400, type: "invalid_request_error", description: "The billing key is a live-mode (or malformed) key. Agents only store TEST-mode restricted keys (rk_test_…); a human adds live keys in the Checkbox dashboard." },
     test_key_not_restricted: { status: 400, type: "invalid_request_error", description: "The key is a full Stripe secret key (sk_test_… or sk_live_…), which is refused on every connect path (createTestCredential, connectBillingPlatform, the dashboard). Use a restricted key (rk_test_…) with the permissions on Checkbox's key checklist instead; `message` lists them." },
-    test_key_declined: { status: 403, type: "permission_error", description: "The owner did not tick “Let your agent store a Stripe test-mode key” on the approval page of this agent's sign-in (device login) or connection (OAuth). Nothing was stored. Ask them to allow it on the approval page (sign in again) or to add the key themselves in the dashboard." },
+    test_key_declined: { status: 403, type: "permission_error", description: "The owner did not tick “Let your agent store a Stripe test-mode restricted key for this project” (agent sign-in, device login) or “Let this app store a Stripe test-mode restricted key for your sites” (app connection, OAuth) on the approval page (checkbox id consent-stripe-test-key). Nothing was stored. next_action.url is a one-click allow page for this agent or app (dashboard /allow-stripe-test-key, signed in, no new sign-in); or the human adds the key themselves in the dashboard." },
     test_key_rejected: { status: 400, type: "invalid_request_error", description: "Stripe rejected the test-mode key or it lacks a permission test runs need; `message` names it." },
     authorization_pending: { status: 400, type: "invalid_request_error", description: "Device login: the human has not approved yet. Keep polling createDeviceToken every `interval` seconds." },
     slow_down: { status: 400, type: "rate_limit_error", description: "Device login: polling too fast. Add 5 seconds to the interval and keep polling." },

package/dist/version.d.ts

@@ -1,2 +1,2 @@
 /** Version of this SDK (kept equal to packages/sdk-node/package.json "version"; a test checks it). */
-export declare const SDK_VERSION = "0.2.5";
+export declare const SDK_VERSION = "0.2.7";

package/dist/version.js

@@ -1,2 +1,2 @@
 /** Version of this SDK (kept equal to packages/sdk-node/package.json "version"; a test checks it). */
-export const SDK_VERSION = '0.2.5';
+export const SDK_VERSION = '0.2.7';

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@checkbox-site/node",
-  "version": "0.2.5",
+  "version": "0.2.7",
   "description": "Checkbox Node.js SDK: auto-renewal law and subscription compliance checks (FTC ROSCA, California ARL, New York and other state laws) for Stripe Checkout and other subscription checkouts. Zero dependencies. Published to npm as @checkbox-site/node.",
   "keywords": [
     "subscription",