@rebasepro/cli 0.17.3-canary.gdd23447 → 0.18.0

package/dist/commands/cloud/databases.d.ts

@@ -71,8 +71,6 @@ export declare function waitForDatabase(client: CloudClient, opts: {
  */
 export declare function resolveBackupArgs(rawArgs: string[]): {
     flags: arg.Result<{
-        "--yes": BooleanConstructor;
-    } & {
         readonly "--json": BooleanConstructor;
         readonly "--yes": BooleanConstructor;
         readonly "--help": BooleanConstructor;

package/dist/commands/cloud/declared-resources.d.ts

@@ -0,0 +1,3 @@
+/** The action words `rebase cloud resources` dispatches. No word lists. */
+export declare const DECLARED_RESOURCES_ACTIONS: readonly ["list", "prune"];
+export declare function declaredResourcesCommand(action: string | undefined, rawArgs: string[]): Promise<void>;

package/dist/commands/cloud/deploy.d.ts

@@ -12,6 +12,7 @@
  * dangerous one — see `planBareDeploy`.
  */
 import arg from "arg";
+import { type CloudClient } from "./context.js";
 /** A project row, reduced to what says how it deploys (camel or snake columns). */
 export interface DeployProjectRow {
     runtimeMode?: string;
@@ -81,8 +82,8 @@ export interface EjectContext {
     managed: boolean;
     /** `--source` was passed: build this directory. */
     source: boolean;
-    /** `--force` was passed: eject on purpose. */
-    force: boolean;
+    /** `--eject` was passed: leave the managed runtime on purpose. */
+    eject: boolean;
 }
 /**
  * Why a container-image deploy of a managed project is refused — or `undefined`
@@ -91,7 +92,15 @@ export interface EjectContext {
  * Every path below this point builds a container image, and a successful one
  * sets `runtimeMode: "custom"` server-side. So the question is never "which flag
  * was used" but "did the caller ask to leave the managed runtime", and only
- * `--force` answers it.
+ * `--eject` answers it.
+ *
+ * The flag was `--force` until the 2026-09-06 sweep. `--force` means four
+ * different things across this CLI — overwrite a file, disconnect other
+ * Postgres sessions, set a build-time key anyway — and three of them are
+ * recoverable in a minute. This one moves a live project off the managed
+ * runtime, which is the least recoverable thing the CLI can be asked to do,
+ * and it had the same name as "overwrite this file". Renamed rather than
+ * aliased: an alias would leave the dangerous spelling working.
  *
  * `--source` used to be read as answering it too, on the theory that uploading a
  * build context is self-evidently a deliberate eject. It is not: `--source`
@@ -117,13 +126,49 @@ export declare function ejectRefusal(opts: EjectContext, projectRef: string): {
  *
  * The condition is just `managed`: anything reaching this point is a container
  * image build that `ejectRefusal` has already let through, and on a managed
- * project that is an eject however it was spelled. A caller who passed `--force`
+ * project that is an eject however it was spelled. A caller who passed `--eject`
  * knows — the warning is for the transcript and the payload, which is what
  * anyone reviewing the deploy afterwards actually reads.
  */
 export declare function deployWarnings(opts: EjectContext, projectRef: string): DeployWarning[];
 /** The warning half of a deploy's JSON payload — merged into whatever it emits. */
 export declare function warningPayload(warnings: DeployWarning[]): Record<string, unknown>;
+/**
+ * What the billing pre-check managed to learn about the organization paying for
+ * this project. `null` means "could not tell", and is never a refusal.
+ */
+export interface BillingState {
+    /** The billing account's plan, or null when the row could not be read. */
+    plan: string | null;
+    /** Whether the control plane reports a card on file, or null when it could not be asked. */
+    hasPaymentMethod: boolean | null;
+    /** The control plane has no Stripe configured — a local or staging control plane. */
+    simulated: boolean;
+}
+/**
+ * Whether a deploy should be refused here, before anything is built or uploaded.
+ *
+ * The server's gate (`ensureProjectComputeBilling`) is the authority and stays
+ * the authority; this only moves the same refusal earlier in the sequence. A
+ * managed deploy type-checks, builds a bundle, packs it and uploads it before it
+ * triggers anything, so a 402 arrived after several minutes of work whose only
+ * outcome was a discarded tarball.
+ *
+ * One direction only. A positive "no card" refuses; every other answer proceeds,
+ * including every answer we could not obtain. That asymmetry is the whole design:
+ * a pre-check that guesses wrong in the refusing direction blocks a deploy the
+ * platform would have accepted, and there are two states this client cannot see —
+ * an internal billing account (skipped server-side) and `REBASE_BYO_FREE` — so
+ * "unknown" has to mean "carry on and let the server decide".
+ */
+export declare function billingBlocksDeploy(state: BillingState): boolean;
+/**
+ * Ask the control plane whether the organization behind this project has a card.
+ *
+ * Best-effort throughout, for the reason above: every failure resolves to a
+ * state that {@link billingBlocksDeploy} lets through.
+ */
+export declare function readBillingState(client: CloudClient, projectId: string): Promise<BillingState>;
 /**
  * Every flag `rebase cloud deploy` accepts.
  *
@@ -141,7 +186,7 @@ export declare const DEPLOY_FLAGS: {
     readonly "--bundle": BooleanConstructor;
     readonly "--bundle-dir": StringConstructor;
     readonly "--skip-type-check": BooleanConstructor;
-    readonly "--force": BooleanConstructor;
+    readonly "--eject": BooleanConstructor;
     readonly "-m": "--message";
 };
 /**
@@ -176,7 +221,7 @@ export declare function resolveDeployArgs(rawArgs: string[]): {
         readonly "--bundle": BooleanConstructor;
         readonly "--bundle-dir": StringConstructor;
         readonly "--skip-type-check": BooleanConstructor;
-        readonly "--force": BooleanConstructor;
+        readonly "--eject": BooleanConstructor;
         readonly "-m": "--message";
     } & {
         readonly "--json": BooleanConstructor;
@@ -193,4 +238,29 @@ export declare function resolveDeployArgs(rawArgs: string[]): {
 export declare function deployCommand(rawArgs: string[], projectRef: string): Promise<void>;
 /** `--timeout <seconds>` for a deploy, or the 15-minute default. */
 export declare function resolveDeployTimeout(value: string | undefined): number;
+/**
+ * Poll a deployment record and print new log output as it arrives. Returns the
+ * terminal status; a non-success still exits non-zero, as it always has.
+ *
+ * `quiet` follows without printing — JSON mode, where the log stream would
+ * corrupt the one object the caller is parsing.
+ */
+/**
+ * The host a project answers on — the same one `cloud status` prints, resolved
+ * the same way, so the two commands cannot disagree about where the app is.
+ *
+ * `undefined` on any failure: the control plane may not report a base domain,
+ * and a deploy that just succeeded must not be reported as anything else
+ * because a cosmetic lookup did not.
+ */
+export declare function deployedUrl(client: CloudClient, opts: {
+    projectId?: string;
+    url?: string;
+}): Promise<string | undefined>;
+/** What `rebase cloud logs` parses. Its page pairs against this. */
+export declare const LOGS_FLAGS: {
+    readonly "--runtime": BooleanConstructor;
+    readonly "--follow": BooleanConstructor;
+    readonly "-f": "--follow";
+};
 export declare function logsCommand(rawArgs: string[], projectRef: string): Promise<void>;

package/dist/commands/cloud/deployments.d.ts

@@ -8,6 +8,8 @@ export interface DeploymentRow {
     finished_at?: string | Date;
     imageUrl?: string;
     image_url?: string;
+    bundleId?: string;
+    bundle_id?: string;
     rollbackOf?: string;
     rollback_of?: string;
     triggeredBy?: string;
@@ -24,8 +26,13 @@ export interface DeploymentRow {
     framework_version?: string;
 }
 /**
- * The backend's rule EXACTLY: a rollback is honoured only for a successful
- * deploy that recorded an image. Any other row 409s `deploy_not_rollbackable`.
+ * The backend's rule EXACTLY (`rollbackTargetOf`): a rollback is honoured only
+ * for a successful deploy that recorded an image or a bundle. Any other row
+ * 409s `deploy_not_rollbackable`.
+ *
+ * The bundle half was missing, and it took the whole managed tier with it: a
+ * managed deploy records no image, so `rebase cloud rollback` refused every
+ * managed project before it even asked the server.
  */
 export declare function isRollbackable(dep: DeploymentRow): boolean;
 /** finishedAt − createdAt in ms, or null (still running / missing / skewed). */

package/dist/commands/cloud/index.d.ts

@@ -1,3 +1,4 @@
+import { type HelpAction } from "./context.js";
 /**
  * Positional tokens after `rebase cloud` (group, action, …).
  *
@@ -21,4 +22,39 @@
  * as the real dispatcher was broken.
  */
 export declare function positionals(rawArgs: string[]): string[];
+/**
+ * The help page for each group, keyed by every alias the dispatch below accepts.
+ *
+ * Aliases are listed explicitly rather than normalised first, so a group that
+ * gains one and forgets it here degrades to the index page — wrong, but a page.
+ * `cloud-help.test.ts` asserts the two stay in step.
+ *
+ * A group absent from this map has no page of its own; the index lists it.
+ */
+/**
+ * The second spelling of a group, mapped to the one the pages are keyed on.
+ *
+ * The dispatch below accepts both (`case "db": case "database":`), so help has
+ * to as well, or half the spellings of a command have no page.
+ */
+export declare const GROUP_ALIASES: Record<string, string>;
+export declare const GROUP_HELP: Record<string, () => void>;
 export declare function cloudCommand(subcommand: string | undefined, rawArgs: string[]): Promise<void>;
+/**
+ * Every group `cloudCommand` dispatches, canonical name first, with the line the
+ * index page prints for it.
+ *
+ * One list, rendered twice. It used to be two: a bare array of words for the
+ * JSON form and a hand-formatted template literal for the terminal — which is
+ * how `clusters` came to be listed on the page twice, under two different
+ * descriptions, in the same section. The page is generated from this now, so a
+ * group appears exactly as often as it appears here, and `cloud-help.test.ts`
+ * holds the list to the dispatch switch and to the pages.
+ *
+ * Sub-actions are deliberately not here. Every group answers `--help` with its
+ * own page now, listing its actions, their arguments and their flags; repeating
+ * a subset of that on the index is the duplication this replaced.
+ */
+export declare const CLOUD_GROUPS: HelpAction[];
+/** The dispatch words alone — what `--help` routing and the tests iterate. */
+export declare const CLOUD_GROUP_NAMES: string[];

package/dist/commands/cloud/link.d.ts

@@ -1,5 +1,5 @@
 export declare function linkCommand(rawArgs: string[]): Promise<void>;
-export declare function unlinkCommand(): void;
+export declare function unlinkCommand(rawArgs: string[]): void;
 export declare function selectOrgCommand(rawArgs: string[]): Promise<void>;
 /** Open the Rebase Cloud dashboard (or the linked project) in a browser. */
 export declare function openCommand(rawArgs: string[]): void;

package/dist/commands/cloud/orgs.d.ts

@@ -1,2 +1,8 @@
 export declare function orgsCommand(subcommand: string | undefined, rawArgs: string[]): Promise<void>;
+/** What `rebase cloud orgs create` parses. Its page is the group's own. */
+export declare const CREATE_ORG_FLAGS: {
+    readonly "--name": StringConstructor;
+    readonly "--slug": StringConstructor;
+    readonly "-n": "--name";
+};
 export declare function printOrgsHelp(): void;

package/dist/commands/cloud/resources.d.ts

@@ -68,6 +68,7 @@ export declare function resolveBlockedState(input: {
     } | undefined;
     lastDeploy?: {
         status?: string | null;
+        logs?: string | null;
     } | undefined;
 }): BlockedState;
 /**
@@ -105,9 +106,15 @@ export declare function metricsCommand(rawArgs: string[]): Promise<void>;
  * Exported so its tests drive the real parser.
  */
 export declare function resolveWebhookIdArg(rawArgs: string[]): string | undefined;
+/** The action words `rebase cloud webhooks` dispatches. No word means `list`. */
+export declare const WEBHOOKS_ACTIONS: readonly ["list", "create", "delete"];
 export declare function webhooksCommand(subcommand: string | undefined, rawArgs: string[]): Promise<void>;
+/** The action words `rebase cloud storage` dispatches. No word means `list`. */
+export declare const STORAGE_ACTIONS: readonly ["list", "create", "attach"];
 export declare function storageCommand(action: string | undefined, rawArgs: string[]): Promise<void>;
 export declare function printStorageHelp(): void;
+/** The action words `rebase cloud clusters` dispatches. No word means `list`. */
+export declare const CLUSTERS_ACTIONS: readonly ["list", "add", "verify"];
 /**
  * `rebase cloud clusters` — list, register and verify the clusters tenants run on.
  *
@@ -148,9 +155,80 @@ export declare function resolveClusterVerifyArgs(rawArgs: string[]): {
     id?: string;
     baseline: boolean;
 };
+/**
+ * Register a cluster from a kubeconfig file.
+ *
+ * Verifies immediately rather than reporting a successful insert: a row that
+ * names an unreachable cluster is worse than no row, because a project pointed
+ * at it fails at deploy instead of at registration.
+ */
+/** The columns a `clusters` row is registered with. Exported for its test. */
+export interface ClusterAddArgs {
+    name: string;
+    provider: "gcp" | "aws" | "hetzner";
+    region: string;
+    kubeconfigPath: string;
+    baseDomain?: string;
+    ingressAddress?: string;
+    /** This is capacity we operate: projects placed in its region deploy here. */
+    platformCapacity: boolean;
+    backupBucket?: string;
+    backupEndpoint?: string;
+    backupAccessKeyId?: string;
+    backupSecretAccessKey?: string;
+}
+/**
+ * What `clusters add` was asked to register.
+ *
+ * Everything a row needs to serve tenants is settable HERE, at insert, because
+ * the control plane installs the cluster baseline on insert and reads the row
+ * to do it: the name is what the Hetzner load balancer is adopted by, the
+ * address is what the ingress is pinned to. Registering with the four
+ * required flags and patching the rest afterwards would install a baseline
+ * that knew neither.
+ *
+ * The backup fields travel together: a bucket with no key, or a key with no
+ * bucket, is a row `resolveBackupStore` deliberately treats as "no store" —
+ * so it is refused here, where the operator can still fix the command.
+ */
+export declare function resolveClusterAddArgs(rawArgs: string[]): ClusterAddArgs;
+/**
+ * The action words `rebase cloud billing` dispatches. No word at all is the
+ * account view, which is why it is not in the list.
+ *
+ * Exported because `action-help.test.ts` holds the page's usage line to it: the
+ * page said `cloud billing [portal|usage]` and the dispatch answered `setup` and
+ * `checkout`, so both documented words fell through to the default and printed
+ * the account — a help page describing a command that does not exist, and a typo
+ * exiting 0.
+ */
+export declare const BILLING_ACTIONS: readonly ["setup", "checkout"];
 export declare function billingCommand(rawArgs: string[]): Promise<void>;
 /**
- * `rebase cloud resources` — show what a project is given, and change it.
+ * The action words `rebase cloud compute` dispatches. No word, or `show`,
+ * prints the dials and the quote.
+ */
+export declare const COMPUTE_ACTIONS: readonly ["show", "set"];
+/**
+ * The flags `resources set` accepts, in the shape a spec is written in.
+ *
+ * Derived from `DIAL_FLAGS` rather than written out beside it: `action-help.ts`
+ * documents this command and `action-help.test.ts` pairs the page against this
+ * constant, so a dial added above is a dial the help page has to describe on the
+ * same commit. A hand-copied second list is how the page and the parser drift.
+ *
+ * `buildDialPatch` still scans `rawArgs` itself — it has to, because
+ * `--no-autoscale` is value-less and a dial's value may not be consumed as one
+ * — so this is a description of that line, not a second parser for it.
+ */
+export declare const COMPUTE_SET_FLAGS: Record<string, unknown>;
+/**
+ * `rebase cloud compute` — show what a project reserves, and change it.
+ *
+ * Named for what it shows — CPU, memory, replicas, the database's shape, and
+ * what those cost — because `rebase resources` already means the graph a
+ * project declares, and two commands called "resources" that show different
+ * things is a support ticket.
  *
  * ## Why nothing is validated here
  *
@@ -164,7 +242,7 @@ export declare function billingCommand(rawArgs: string[]): Promise<void>;
  * boundary refuses a raw PATCH and a console save, which is the property worth
  * having — a check in a client only covers the clients that run it.
  */
-export declare function resourcesCommand(action: string | undefined, rawArgs: string[]): Promise<void>;
+export declare function computeCommand(action: string | undefined, rawArgs: string[]): Promise<void>;
 /**
  * Turn `--cpu 500m --db-instances 2` into the patch to send.
  *
@@ -176,7 +254,7 @@ export declare function buildDialPatch(rawArgs: string[],
 /**
  * `requireOne: false` for `projects create`, where naming no dial is the
  * ordinary case — a new project takes the platform default. On
- * `resources set` a patch with nothing in it is a typo, and saying so beats
+ * `compute set` a patch with nothing in it is a typo, and saying so beats
  * a success message for a change nobody made.
  */
 opts?: {

package/dist/commands/cloud/settings.d.ts

@@ -6,4 +6,11 @@ export declare function buildSettingsPatch(args: {
     repo?: string;
     branch?: string;
 }): Record<string, string>;
+/** What `rebase cloud settings set` parses. Its page is the group's own. */
+export declare const SET_SETTINGS_FLAGS: {
+    readonly "--name": StringConstructor;
+    readonly "--subdomain": StringConstructor;
+    readonly "--repo": StringConstructor;
+    readonly "--branch": StringConstructor;
+};
 export declare function printSettingsHelp(): void;

package/dist/commands/db.d.ts

@@ -1,3 +1,22 @@
+import { type PreparedDatabase } from "../dev-db/prepare.js";
+import { type DevDatabase } from "../dev-db/resolve.js";
+/**
+ * The connection string a prepared database actually answers on.
+ *
+ * One function, because `db url` and `db pull` disagreed about it and the
+ * disagreement was a dead command: `prepareDatabaseEnv` returns `env: {}` for a
+ * plain external database — the connection string is already somewhere the
+ * child looks — so `db pull`'s `prepared.env.DATABASE_URL ?? process.env
+ * .DATABASE_URL` was empty for the standard `.env` configuration and answered
+ * `✗ No local database to pull into.` on a project whose `rebase db url` had
+ * just printed one. Exporting the same URL in the shell made it work, which is
+ * the shape of a bug nobody reports as one.
+ *
+ * `readEnvFile` is passed in rather than imported: this module loads
+ * `../utils/project` dynamically everywhere else, and the callers already have
+ * it open.
+ */
+export declare function databaseUrlOf(prepared: Pick<PreparedDatabase, "env" | "database">, envFile: Record<string, string>): string | undefined;
 /**
  * Rewrite local path arguments so they mean what the user typed.
  *
@@ -14,19 +33,110 @@
  */
 export declare function absolutizeLocalPathArgs(args: string[], cwd: string): string[];
 /**
- * Run a database subcommand through the active driver's CLI, throwing on
- * failure instead of exiting.
+ * A managed-database refusal, raised so the caller decides what it costs.
+ *
+ * These two guards used to `process.exit(1)` where they stood. That is right
+ * for `rebase db push`, typed by a person, and catastrophic for the same code
+ * reached from inside `rebase dev`: the dev server's first-boot schema push
+ * runs in-process, so an exit there took the whole dev server down — with a
+ * `try/catch` around it written expressly to prevent that, which could never
+ * run. The first `rebase dev --docker` of every scaffold died this way.
+ *
+ * So the refusal is a value now. It carries the block it wants printed rather
+ * than printing it, because who prints (and whether printing is even right) is
+ * the caller's question: `dbCommand` prints it and exits 1, and `rebase dev`
+ * keeps serving.
+ */
+export declare class ManagedDatabaseRefusal extends Error {
+    /** The lines to print, in order, already coloured. */
+    readonly lines: readonly string[];
+    constructor(summary: string, lines: readonly string[]);
+}
+/** Print a refusal exactly as the guards used to print it themselves. */
+export declare function printManagedDatabaseRefusal(refusal: ManagedDatabaseRefusal): void;
+/**
+ * Stop an Atlas-backed subcommand before it fails inside Atlas on the managed
+ * development database.
+ *
+ * **PGlite serves exactly one database.** `CREATE DATABASE "postgres_dev_diff"`
+ * against it reports success and creates nothing, so Atlas connects its dev-url
+ * straight back to the database it is meant to be comparing against, finds the
+ * project's own tables there, and stops with
+ * `connected database is not clean: found schema "public"`. Verified on a
+ * completely fresh scaffold, so this is not a leftover-state problem that a
+ * reset would fix — the model does not fit the engine.
+ *
+ * Before this guard the failure was worse than unhelpful. The first thing the
+ * reader hit was `pq: SSL is not enabled on the server`, whose remedy box said
+ * to append `sslmode=disable` to `DATABASE_URL` — a variable `rebase init`
+ * deliberately leaves unset, which is the very reason the managed database was
+ * in use. Two errors deep, about a variable that does not exist, for a command
+ * the quickstart told them to run.
+ *
+ * There is nothing to fix by trying harder here: Atlas's other dev-url option
+ * is `docker://`, and needing Docker is precisely what the managed database
+ * exists to avoid. So this says what the managed database can and cannot do,
+ * and names the two things that work.
+ */
+export declare function refuseAtlasOnManagedDatabase(rawArgs: string[], kind: string): void;
+/**
+ * Stop `rebase db branch` before it reports a branch that is not one.
  *
- * `dbCommand` below turns every failure into `process.exit(1)`, which is right
- * for a command the user invoked directly and wrong for a caller that has more
- * to do afterwards — `rebase dev` runs a schema push during start-up and must
- * survive it failing. Exiting is therefore the wrapper's job, not this
- * function's.
+ * **PGlite serves exactly one database**, and this is the second thing that
+ * follows from it. `CREATE DATABASE "rb_feature_x" TEMPLATE "postgres"` there
+ * writes a `pg_database` catalog row and nothing else. Nothing errors, so the
+ * whole feature reports success end to end:
  *
- * The database is resolved *here* rather than in the wrapper, so the schema
- * push `rebase dev` performs during start-up reaches the managed database too.
+ *     $ rebase db branch create feature_x
+ *       ✓ Branch "feature_x" created successfully.
+ *     $ rebase db branch list
+ *       ● feature_x (7.1 MB) — created just now
+ *
+ * `listBranches` joins `pg_database`, the catalog row is there, and
+ * `pg_database_size` answers with the one database's size — so the listing
+ * corroborates the lie. Then connecting to `rb_feature_x` reports
+ * `current_database()` = `postgres`, and a table created "in the branch" is
+ * visible in the parent immediately. Measured on a fresh `rebase init` scaffold.
+ *
+ * **The branch is the parent.** Every write made in the belief that it is
+ * sandboxed lands in the developer's real development database — which is the
+ * exact failure branching exists to prevent, announced as a success.
+ *
+ * So this refuses the whole `branch` domain rather than `create` alone: `list`
+ * on the managed database ends with "Create one with: rebase db branch create",
+ * an invitation to do the broken thing, and `info` would confirm a size for a
+ * database that was never made.
+ *
+ * `refuseAtlasOnManagedDatabase` above is the same shape for a different
+ * reason, and its comment named `branch` as one of the subcommands it does not
+ * cover. It does now.
+ */
+export declare function refuseBranchOnManagedDatabase(rawArgs: string[], kind: string): void;
+/**
+ * Run a `schema` subcommand through the active driver's CLI.
+ *
+ * Separate from {@link runDriverDbCommand} because it must NOT resolve a
+ * database. `rebase dev` calls this before the database exists, which is the
+ * whole point: the generated schema has to be right before anything reads it.
+ * Throws rather than exiting — the caller has more to do.
  */
+export declare function runDriverSchemaCommand(rawArgs: string[], options?: {
+    quiet?: boolean;
+}): Promise<void>;
 export declare function runDriverDbCommand(rawArgs: string[], options?: {
     quiet?: boolean;
 }): Promise<void>;
 export declare function dbCommand(subcommand: string | undefined, rawArgs: string[]): Promise<void>;
+/**
+ * The examples, which are not the same on the managed development database.
+ *
+ * Every one of the four the help used to lead with — `db push`, `db generate`,
+ * `db migrate`, `db branch` — is refused there, by guards in this same file
+ * that explain exactly why. So on the project the CLI had just scaffolded, the
+ * first thing `rebase db --help` offered was a command that answers with a
+ * refusal, and the reader's most likely conclusion is that their install is
+ * broken.
+ *
+ * Exported for its test.
+ */
+export declare function dbExamples(kind: DevDatabase["kind"] | null): string;