@checkbox-site/node 0.2.2 → 0.2.4

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.2";
+    static readonly VERSION = "0.2.4";
     static readonly API_VERSION = "2026-10-30";
     static readonly errors: typeof errors;
     static readonly webhooks: Webhooks;

package/dist/generated/operations.d.ts

@@ -3082,7 +3082,7 @@ export declare class ChecksResource extends Resource {
     /**
      * Check Stripe Checkout Session params.
      *
-     * Pass exactly the object your code gives stripe.checkout.sessions.create (plus merchant.merchant_name and merchant.cancel_url, and merchant.price/interval when line_items use a Price id). Checkbox models the Stripe-hosted page those params render and returns findings plus `correction`: a JSON Patch (RFC 6902) and the full corrected params (custom_text.submit with the renewal terms, consent_collection.terms_of_service = "required", custom_text.terms_of_service_acceptance as the consent label), verified by the engine. Stripe's own small grey styling keeps "clear and conspicuous" at needs_review on any Stripe-hosted page; also show the terms on your page before redirecting. 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.
+     * Body: `{ params, merchant }` (or `{ params, site }`). `params` is exactly the object your code gives stripe.checkout.sessions.create; `merchant` adds merchant_name, cancel_url, and price/interval when line_items use a Price id. Checkbox models the Stripe-hosted page those params render and returns findings plus `correction`: a JSON Patch (RFC 6902) and the full corrected params (custom_text.submit with the renewal terms, consent_collection.terms_of_service = "required", custom_text.terms_of_service_acceptance as the consent label), verified by the engine. Stripe's own small grey styling keeps "clear and conspicuous" at needs_review on any Stripe-hosted page; also show the terms on your page before redirecting. 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/stripe_checkout_session (operation `checkStripeCheckoutSession`, scope `checks:read`)
      */
@@ -3356,7 +3356,7 @@ export declare class StripeCheckoutConfigsResource extends Resource {
     /**
      * Register the Checkout Session params your code uses.
      *
-     * Registers exactly the object your code passes to stripe.checkout.sessions.create (customer, URLs and secrets are not needed and are ignored; `warnings` says what was not stored). It is judged exactly like checkStripeCheckoutSession, discounts included. A config with the same name, or for the same Price ids, replaces the older one (`replaced`). Test runs mirror it into Stripe test mode; when it matches your latest live checkout, the scanned test page counts as an observation of your live checkout. Re-register after changing your checkout code, then call createTestRun.
+     * Registers exactly the object your code passes to stripe.checkout.sessions.create, as `params` (that object sent alone as the body is accepted too; customer, URLs and secrets are not needed and are ignored; `warnings` says what was not stored). It is judged exactly like checkStripeCheckoutSession, discounts included. A config with the same name, or for the same Price ids, replaces the older one (`replaced`). Test runs mirror it into Stripe test mode; when it matches your latest live checkout, the scanned test page counts as an observation of your live checkout. Re-register after changing your checkout code, then call createTestRun.
      *
      * @param site Unique identifier of the site (site_…).
      * @see POST /v1/sites/{site}/stripe_checkout_configs (operation `createStripeCheckoutConfig`, scope `test_runs:write`)
@@ -3412,7 +3412,7 @@ export declare class TestRunsResource extends Resource {
     /**
      * Start a lifecycle test run.
      *
-     * Starts a synthetic test subscription in TEST mode and returns it queued. Stripe runs mirror your checkout into a test-mode Checkout Session, subscribe a test customer (card 4242) whose email is a Checkbox inbox, wait for your acknowledgment, advance a test clock through every legal notice window before trial end and renewal, cancel online in the customer portal and wait for the confirmation; then delete the test clock. Usually takes 2-4 minutes (longer when your own emails are slow to arrive): poll retrieveTestRun (next_action says when) or listen for test_run.completed. Each step reports observations, check results and agent-readable fixes; apply them and run again to verify.
+     * Starts a synthetic test subscription in TEST mode and returns it queued. Stripe runs mirror your checkout into a test-mode Checkout Session, subscribe a test customer (card 4242) whose email is a Checkbox inbox, wait for your acknowledgment, advance a test clock through every legal notice window before trial end and renewal, cancel online in the customer portal and wait for the confirmation; then delete the test clock. Usually takes 1-2 minutes; a real_checkout run a few minutes (longer when your own emails are slow to arrive): poll retrieveTestRun (next_action says when) or listen for test_run.completed. Each step reports observations, check results and agent-readable fixes; apply them and run again to verify.
      *
      * @param site Unique identifier of the site (site_…).
      * @see POST /v1/sites/{site}/test_runs (operation `createTestRun`, scope `test_runs:write`, live mode needs an activated account)

package/dist/generated/operations.js

@@ -2602,7 +2602,7 @@ export class ChecksResource extends Resource {
     /**
      * Check Stripe Checkout Session params.
      *
-     * Pass exactly the object your code gives stripe.checkout.sessions.create (plus merchant.merchant_name and merchant.cancel_url, and merchant.price/interval when line_items use a Price id). Checkbox models the Stripe-hosted page those params render and returns findings plus `correction`: a JSON Patch (RFC 6902) and the full corrected params (custom_text.submit with the renewal terms, consent_collection.terms_of_service = "required", custom_text.terms_of_service_acceptance as the consent label), verified by the engine. Stripe's own small grey styling keeps "clear and conspicuous" at needs_review on any Stripe-hosted page; also show the terms on your page before redirecting. 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.
+     * Body: `{ params, merchant }` (or `{ params, site }`). `params` is exactly the object your code gives stripe.checkout.sessions.create; `merchant` adds merchant_name, cancel_url, and price/interval when line_items use a Price id. Checkbox models the Stripe-hosted page those params render and returns findings plus `correction`: a JSON Patch (RFC 6902) and the full corrected params (custom_text.submit with the renewal terms, consent_collection.terms_of_service = "required", custom_text.terms_of_service_acceptance as the consent label), verified by the engine. Stripe's own small grey styling keeps "clear and conspicuous" at needs_review on any Stripe-hosted page; also show the terms on your page before redirecting. 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/stripe_checkout_session (operation `checkStripeCheckoutSession`, scope `checks:read`)
      */
@@ -2936,7 +2936,7 @@ export class StripeCheckoutConfigsResource extends Resource {
     /**
      * Register the Checkout Session params your code uses.
      *
-     * Registers exactly the object your code passes to stripe.checkout.sessions.create (customer, URLs and secrets are not needed and are ignored; `warnings` says what was not stored). It is judged exactly like checkStripeCheckoutSession, discounts included. A config with the same name, or for the same Price ids, replaces the older one (`replaced`). Test runs mirror it into Stripe test mode; when it matches your latest live checkout, the scanned test page counts as an observation of your live checkout. Re-register after changing your checkout code, then call createTestRun.
+     * Registers exactly the object your code passes to stripe.checkout.sessions.create, as `params` (that object sent alone as the body is accepted too; customer, URLs and secrets are not needed and are ignored; `warnings` says what was not stored). It is judged exactly like checkStripeCheckoutSession, discounts included. A config with the same name, or for the same Price ids, replaces the older one (`replaced`). Test runs mirror it into Stripe test mode; when it matches your latest live checkout, the scanned test page counts as an observation of your live checkout. Re-register after changing your checkout code, then call createTestRun.
      *
      * @param site Unique identifier of the site (site_…).
      * @see POST /v1/sites/{site}/stripe_checkout_configs (operation `createStripeCheckoutConfig`, scope `test_runs:write`)
@@ -3006,7 +3006,7 @@ export class TestRunsResource extends Resource {
     /**
      * Start a lifecycle test run.
      *
-     * Starts a synthetic test subscription in TEST mode and returns it queued. Stripe runs mirror your checkout into a test-mode Checkout Session, subscribe a test customer (card 4242) whose email is a Checkbox inbox, wait for your acknowledgment, advance a test clock through every legal notice window before trial end and renewal, cancel online in the customer portal and wait for the confirmation; then delete the test clock. Usually takes 2-4 minutes (longer when your own emails are slow to arrive): poll retrieveTestRun (next_action says when) or listen for test_run.completed. Each step reports observations, check results and agent-readable fixes; apply them and run again to verify.
+     * Starts a synthetic test subscription in TEST mode and returns it queued. Stripe runs mirror your checkout into a test-mode Checkout Session, subscribe a test customer (card 4242) whose email is a Checkbox inbox, wait for your acknowledgment, advance a test clock through every legal notice window before trial end and renewal, cancel online in the customer portal and wait for the confirmation; then delete the test clock. Usually takes 1-2 minutes; a real_checkout run a few minutes (longer when your own emails are slow to arrive): poll retrieveTestRun (next_action says when) or listen for test_run.completed. Each step reports observations, check results and agent-readable fixes; apply them and run again to verify.
      *
      * @param site Unique identifier of the site (site_…).
      * @see POST /v1/sites/{site}/test_runs (operation `createTestRun`, scope `test_runs:write`, live mode needs an activated account)

package/dist/generated/types.d.ts

@@ -129,7 +129,7 @@ export interface DeviceAuthorizationParams {
     merchant_name?: string;
     /** Also ask for live-mode keys (live mode activates after domain verification). */
     live?: boolean;
-    /** A HINT of the Stripe TEST key found in the project, never the key. Format: "sk_test_" or "rk_test_", the ellipsis character "…" (U+2026), then the key's last 4 characters, e.g. "sk_test_…a1b2". The human is asked once whether Checkbox may use it for synthetic test subscriptions. */
+    /** A HINT of the Stripe restricted TEST key found in the project, never the key. Format: "rk_test_", the ellipsis character "…" (U+2026), then the key's last 4 characters, e.g. "rk_test_…a1b2". The human is asked once whether Checkbox may use it. Agents may store restricted test keys (rk_test_) only: an "sk_test_" hint (sent by older CLIs) is accepted and ignored, because a full secret key is refused on every path. */
     stripe_test_key_hint?: string;
 }
 /** Keys issued after the human approved the device login. Returned exactly once. */
@@ -390,7 +390,7 @@ export interface SetupSession {
     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. */
         test_key_consent: boolean;
-        /** Hint of the key the CLI found (never the key). */
+        /** Hint of the restricted test key the CLI found (never the key). */
         test_key_hint: string | null;
         /** Whether a Stripe test-mode key is stored for test runs. */
         test_credential_stored: boolean;
@@ -402,7 +402,7 @@ export interface SetupSession {
             recommended: boolean;
             /** Why. */
             reason: string;
-            /** Where to create it. */
+            /** Stripe API keys page (Test mode); click "Create restricted key" there. */
             create_url: string;
             /** The one key checklist: every permission Checkbox uses (checks, fixes after the human approves, test runs). */
             permissions: Array<{
@@ -419,7 +419,7 @@ export interface SetupSession {
     test_run: {
         /** Unique identifier of the test run (run_…). */
         id: string;
-        /** queued, running, succeeded, failed or canceled. */
+        /** queued, running, succeeded, incomplete (no step failed, but a step could not finish), failed or canceled. */
         status: string;
         /** The result in plain words, as the test run says it ("Finished with 2 warnings to review"). succeeded with warnings is not a clean pass. */
         status_label?: string;
@@ -1766,7 +1766,7 @@ export interface CompliancePlan {
     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). */
     status: "action_required" | "verifying" | "compliant" | "blocked";
-    /** The plan status in words to show a person: action_required "Fixes needed", verifying "Checking your changes", compliant "Checks pass", blocked "Your call"; 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). */
+    /** 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). */
     evaluation: string | null;
@@ -1967,7 +1967,7 @@ export interface Verification {
     diff: Array<VerificationCheck>;
     /** Plan status after this verification (null while pending). */
     plan_status: "action_required" | "verifying" | "compliant" | "blocked" | null;
-    /** The plan status in words to show a person: action_required "Fixes needed", verifying "Checking your changes", compliant "Checks pass", blocked "Your call"; 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). */
+    /** 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). */
     plan_status_label?: string | null;
     next_action: PlanNextAction;
     /** When it was requested. Unix timestamp in seconds. */
@@ -1999,7 +1999,7 @@ export interface VerifyTaskParams {
     plan?: string;
     /** email_copy tasks: check the email against the plan with this Stripe Price id only. */
     price_id?: string;
-    /** Re-check a task that is already done (or declined) instead of returning its last result: Checkbox evaluates the site again now and queues a confirming scan, so a regression shows up (pilot: a cancel page switched to phone-only stayed "passed"). */
+    /** Kept for compatibility: a task that is already done (or declined) is always re-checked now (Stripe re-read, registered checkout configs judged again, a fresh evaluation or a confirming scan), never answered from its last result. A task closed without anything observed passing (superseded, no longer applicable, or a person's decision) answers not_checked: nothing to verify. */
     recheck?: boolean;
 }
 /** A page of verifications, newest first. */
@@ -4443,8 +4443,8 @@ 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 and no step failed (steps may still have warnings to review); failed means it stopped early, or finished with a failed step (see failure and steps[].fix). */
-    status: "queued" | "running" | "succeeded" | "failed" | "canceled";
+    /** 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). */
+    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;
     /** Internal phase (prepare, checkout, await_ack, advance, settle, cancel, await_cancel_email, finalize, done). */
@@ -4768,7 +4768,7 @@ export interface CompliancePlanSummary {
     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). */
     status: "action_required" | "verifying" | "compliant" | "blocked";
-    /** The plan status in words to show a person: action_required "Fixes needed", verifying "Checking your changes", compliant "Checks pass", blocked "Your call"; 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). */
+    /** 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;
     /** Two or three sentences for an LLM: where the site stands and what comes next. */
     summary: string;

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.2";
+export declare const SDK_VERSION = "0.2.4";

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.2';
+export const SDK_VERSION = '0.2.4';

package/package.json

@@ -1,11 +1,13 @@
 {
   "name": "@checkbox-site/node",
-  "version": "0.2.2",
-  "description": "Checkbox Node.js SDK: automatic-renewal-law compliance (ROSCA, California ARL, New York and other state laws) for subscription businesses. Zero dependencies. Published to npm as @checkbox-site/node.",
+  "version": "0.2.4",
+  "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",
     "subscription-compliance",
+    "subscription compliance",
     "auto-renewal",
+    "auto renewal",
     "autorenewal",
     "automatic-renewal",
     "compliance",