@rebasepro/cli 0.13.0 → 0.13.1-canary.g06dbe5b

package/dist/bundle.d.ts

@@ -136,10 +136,11 @@ export declare function normalizeEsmSpecifiers(outDir: string): {
  * deployed green, and answered 404 on every one of them, with the file still
  * sitting in the repository looking exactly like the server.
  *
- * A project that means to keep its own entrypoint runs `rebase eject`, which
- * writes the entrypoint, a Dockerfile and a compose file together and flips the
+ * A project that means to own its server process runs `rebase eject`, which
+ * writes an entrypoint, a Dockerfile and a compose file together and flips the
  * backend to `runtime: "custom"`. The warning names that route rather than
- * implying the file is a mistake.
+ * implying the file is a mistake — but eject writes *its* entrypoint, so the
+ * warning must not read as "eject will keep what you wrote here".
  */
 export declare function findUnusedServerEntry(projectRoot: string, functionsDir: string): string | undefined;
 /**

package/dist/commands/api-keys.d.ts

@@ -1 +1,52 @@
 export declare function apiKeysCommand(subcommand: string | undefined, rawArgs: string[]): Promise<void>;
+/** The flags `rebase api-keys create` takes. */
+export declare const CREATE_KEY_FLAGS: {
+    readonly "--name": StringConstructor;
+    readonly "--permissions": StringConstructor;
+    readonly "--full-access": BooleanConstructor;
+    readonly "--admin": BooleanConstructor;
+    readonly "--rate-limit": NumberConstructor;
+    readonly "--expires": StringConstructor;
+    readonly "-n": "--name";
+};
+/**
+ * What this invocation asks to be created.
+ *
+ * The name may be given either way — `--name "My Key"` or as the single
+ * positional — and under the old permissive parse an undeclared flag became
+ * that positional: `rebase api-keys create --debug --full-access` created a
+ * key called `--debug` with read/write/delete on every collection, and
+ * `--debug` is what the CLI prints after every failure as the thing to re-run
+ * with. Strict parsing makes the flag an error instead of a name.
+ *
+ * Exported so its tests can drive the real parser rather than a copy of it.
+ */
+export declare function resolveCreateKeyArgs(rawArgs: string[]): {
+    flags: import("arg").Result<{
+        readonly "--name": StringConstructor;
+        readonly "--permissions": StringConstructor;
+        readonly "--full-access": BooleanConstructor;
+        readonly "--admin": BooleanConstructor;
+        readonly "--rate-limit": NumberConstructor;
+        readonly "--expires": StringConstructor;
+        readonly "-n": "--name";
+    }>;
+    name: string;
+};
+/** The flags `rebase api-keys revoke` takes. */
+export declare const REVOKE_KEY_FLAGS: {
+    readonly "--id": StringConstructor;
+};
+/**
+ * Which key this invocation names.
+ *
+ * The id is a positional, so the permissive parse handed one straight to the
+ * DELETE: `rebase api-keys revoke --foo` sent
+ * `DELETE /api/admin/api-keys/--foo`, and `rebase --debug api-keys revoke <id>`
+ * shifted the words along and revoked the key named `revoke`.
+ *
+ * Exported so its tests can drive the real parser rather than a copy of it.
+ */
+export declare function resolveRevokeKeyArgs(rawArgs: string[]): {
+    id?: string;
+};

package/dist/commands/auth.d.ts

@@ -1 +1,63 @@
+/** A user as the admin API returns it, reduced to what this command needs. */
+export interface ResolvedUser {
+    id: string;
+    email: string;
+}
+/**
+ * Pick the user with exactly this email out of a search response.
+ *
+ * `/api/admin/users?search=` is an `ILIKE '%…%'` over email **or display
+ * name**, ordered by role count descending. This used to take row `[0]` and
+ * reset it, then print the email it had been *given* as confirmation — so two
+ * ordinary situations ended in a successful-looking reset of somebody else's
+ * account:
+ *
+ *   - a substring collision: `bob@example.com` also matches
+ *     `robert.bob@example.com`;
+ *   - a display name, which is user-controlled and accepted up to 255
+ *     characters with no constraint on its content, containing an address
+ *     belonging to someone else.
+ *
+ * The ordering makes it worse rather than better — `array_length(roles) DESC
+ * NULLS LAST` puts the most privileged match first, so the account most likely
+ * to be reset by mistake is an admin's.
+ *
+ * Returns `undefined` when nothing matched exactly, which the caller reports
+ * rather than falling through to a guess. The direct-database fallback below
+ * has always matched with `eq(usersTable.email, email)`; this is the same
+ * definition, so the command no longer resets different accounts depending on
+ * whether the backend happened to be running.
+ */
+export declare function selectUserForEmail(payload: unknown, email: string): ResolvedUser | undefined;
 export declare function authCommand(subcommand: string | undefined, rawArgs: string[]): Promise<void>;
+/**
+ * The flags `rebase auth reset-password` takes.
+ *
+ * `-p` was advertised in this command's own help and never declared here, so
+ * `arg` — running permissively — pushed it into the positionals and the value
+ * *after* it shifted out of reach: anyone following the help set the account's
+ * password to the two-character string `-p`. Declared now, and `auth.test.ts`
+ * asserts that the help and this spec list the same aliases.
+ */
+export declare const RESET_PASSWORD_FLAGS: {
+    readonly "--email": StringConstructor;
+    readonly "--password": StringConstructor;
+    readonly "-e": "--email";
+    readonly "-p": "--password";
+};
+/**
+ * Which account, and which password, this invocation names.
+ *
+ * Both may still be absent — the caller reports a missing email — but neither
+ * can be a flag. `parseCommandArgs` parses the whole line strictly, so an
+ * undeclared flag is an error rather than a positional. That is what stops
+ * `rebase auth reset-password bob@example.com --debug` from setting Bob's
+ * password to `--debug`, which is the flag the CLI itself prints after every
+ * failure as the thing to re-run with.
+ *
+ * Exported so its tests can drive the real parser rather than a copy of it.
+ */
+export declare function resolveResetPasswordArgs(rawArgs: string[]): {
+    email?: string;
+    password?: string;
+};

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

@@ -1,3 +1,4 @@
+import arg from "arg";
 import { createRebaseClient } from "@rebasepro/client";
 /** Project-local link file: <project>/.rebase/cloud.json */
 export declare function projectLinkPath(cwd?: string): string;
@@ -227,15 +228,63 @@ export declare function confirmDestructive(opts: {
     prompt: string;
 }): Promise<void>;
 /**
- * Positional tokens after `rebase cloud` — `[group, action, arg1, …]`.
+ * Resolve one cloud command's flags and ARGUMENTS from the full `process.argv`.
  *
- * Deliberately NOT `arg({}, { permissive: true })._`: in permissive mode `arg`
- * pushes UNKNOWN FLAGS onto `_` too, so `rollback --yes --json` would report
- * `--yes` as the deployment id. Operand extraction must see operands only, so
- * anything starting with `-` is dropped — the same filter the db backup handler
- * has always used.
+ * This replaces `cloudPositionals`, which was `rawArgs.slice(3).filter(a =>
+ * !a.startsWith("-"))`. Dropping `-`-prefixed tokens looks like it solves the
+ * permissive-parse problem and does not: a flag that takes a VALUE leaves the
+ * value behind, an ordinary word in the argument position that no filter can
+ * tell from a real one. `--project` is the flag every one of these commands
+ * documents, so the failure was reachable from the help page:
+ *
+ *   rebase cloud env unset -p acme            → removed the variable "acme"
+ *   rebase cloud env set KEY -p acme          → stored the value "acme"
+ *   rebase cloud domains add -p acme          → registered the domain "acme"
+ *   rebase cloud webhooks delete -p acme 42   → deleted webhook "acme", not 42
+ *   rebase cloud cancel -p acme               → cancelled deployment id "acme"
+ *
+ * The filter's other half is quieter. A flag nobody declared *is* dropped by
+ * it — but only from the operands, never from the run: nothing rejects it, so
+ * the command proceeds with the argument missing or defaulted. `db backup
+ * --dry-run` listed backups, `domains remove --dry-run` detached the domain,
+ * and `env set KEY=v --secrett` stored the value as an ordinary variable that
+ * `env reveal` will hand back. The one place an undeclared flag became the
+ * argument outright is `projects info|delete`, which resolved its id through
+ * `positionals()` instead — that skips only LEADING `-` tokens, so `projects
+ * delete --force` looked up a project named "--force".
+ *
+ * So: parse the whole line strictly, through the same `parseCommandArgs` the
+ * non-cloud commands use — `arg` then consumes each declared flag *with its
+ * value* wherever it appears, and rejects the undeclared, leaving `_` holding
+ * the command words followed by the real arguments. `commandWords` counts from
+ * `cloud` itself (`cloud env set` ⇒ 3), and is applied to the parsed
+ * positionals, so a flag written before the group shifts nothing.
+ *
+ * Two things this adds over calling `parseCommandArgs` directly, and the reason
+ * it is worth a wrapper:
+ *
+ *  - `GLOBAL_CLOUD_FLAGS` is merged in. `--json`, `--yes` and `--project` may
+ *    appear anywhere on a cloud line including before the group, so a strict
+ *    parse that did not declare them would reject the CLI's own documented
+ *    usage. (`parseCommandArgs` adds `--debug`/`--help` on top of that.)
+ *  - A parse error is reported through `fail`, not thrown. A throw reaches
+ *    `bin/rebase.js`, which prints `✗ …` to stderr — which is right for every
+ *    other command and wrong here: `rebase cloud` is in JSON mode whenever
+ *    stdout is not a TTY, i.e. always for the agents this family is built for,
+ *    and it promises them exactly one JSON value. `fail` keeps that promise,
+ *    with the same `usage` code the other refusals in this family use.
  */
-export declare function cloudPositionals(rawArgs: string[]): string[];
+export declare function parseCloudArgs<S extends arg.Spec>(opts: {
+    spec: S;
+    rawArgs: string[];
+    commandWords: number;
+    /** Names the command in errors, e.g. `cloud env set` (no leading `rebase`). */
+    command: string;
+    maxPositionals?: number;
+}): {
+    flags: arg.Result<S & typeof GLOBAL_CLOUD_FLAGS>;
+    positionals: string[];
+};
 export declare function success(message: string): void;
 /** Colorize a deployment / resource status token. */
 export declare function colorStatus(status: string | undefined): string;

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

@@ -1 +1,40 @@
+/**
+ * `rebase cloud db` — database + backup management for a project.
+ *
+ *   db list                List databases attached to the project
+ *   db create              Attach a managed or bring-your-own database
+ *   db test                Test connectivity to the project's database
+ *   db backup list|create|restore
+ */
+import arg from "arg";
 export declare function dbCommand(subcommand: string | undefined, rawArgs: string[]): Promise<void>;
+/**
+ * `db backup [action] [filename]`, resolved in one strict parse.
+ *
+ * Both halves were reachable by the old operand filter, and both are
+ * destructive: `rebase cloud db backup -p acme` read `--project`'s value as the
+ * ACTION (falling through to a list, so the flag silently changed what ran),
+ * and `db backup restore -p acme` read it as the FILENAME — a restore staged
+ * over the live database, named after the project slug. An undeclared flag was
+ * dropped instead of refused, which is the same failure one step quieter: `db
+ * backup --dry-run` ran a list, having silently discarded the flag that was
+ * supposed to change what it did.
+ *
+ * Exported so its tests drive the real parser.
+ */
+export declare function resolveBackupArgs(rawArgs: string[]): {
+    flags: arg.Result<{
+        "--yes": BooleanConstructor;
+    } & {
+        readonly "--json": BooleanConstructor;
+        readonly "--yes": BooleanConstructor;
+        readonly "--help": BooleanConstructor;
+        readonly "--project": StringConstructor;
+        readonly "-p": "--project";
+        readonly "-y": "--yes";
+        readonly "-h": "--help";
+    }>;
+    action: string;
+    filename: string;
+};
+export declare function printDbHelp(): void;

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

@@ -115,3 +115,4 @@ export declare function formatDuration(seconds: number): string;
  */
 export declare function parseSince(input: string | undefined): number | null;
 export declare function debugCommand(action: string | undefined, rawArgs: string[]): Promise<void>;
+export declare function printDebugHelp(): void;

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

@@ -50,5 +50,27 @@ export declare const DEFAULT_DEPLOYMENTS_LIMIT = 20;
 /** `--limit N`, bounded. A garbage value is a refusal, never a silent default. */
 export declare function parseDeploymentsLimit(raw: number | undefined): number;
 export declare function deploymentsListCommand(rawArgs: string[]): Promise<void>;
+/**
+ * The deployment id `rollback`/`cancel` was given, if any.
+ *
+ * Both take an optional id, which is what made the old operand filter so easy
+ * to trip: `rebase cloud rollback -p acme` — the documented way to act on an
+ * unlinked project — read `--project`'s value as the id and refused with
+ * "Deployment acme not found", and `cancel -p acme` sent "acme" to the server
+ * as the deployment to cancel. Strict parsing consumes the flag with its value,
+ * so an id given as a flag value is never mistaken for an argument.
+ */
+export declare function resolveDeploymentIdArg(rawArgs: string[], command: string): {
+    flags: import("arg").Result<{
+        readonly "--json": BooleanConstructor;
+        readonly "--yes": BooleanConstructor;
+        readonly "--help": BooleanConstructor;
+        readonly "--project": StringConstructor;
+        readonly "-p": "--project";
+        readonly "-y": "--yes";
+        readonly "-h": "--help";
+    }>;
+    id: string;
+};
 export declare function rollbackCommand(rawArgs: string[]): Promise<void>;
 export declare function cancelCommand(rawArgs: string[]): Promise<void>;

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

@@ -1 +1,11 @@
 export declare function domainsCommand(action: string | undefined, rawArgs: string[]): Promise<void>;
+/**
+ * The domain `domains add` was asked to register.
+ *
+ * Exported so its tests drive the real parser. Under the old operand filter
+ * `rebase cloud domains add -p acme` registered a domain called "acme" — the
+ * project slug, read out of `--project`'s own value — and a registered domain
+ * is a project-record write, not a no-op.
+ */
+export declare function resolveDomainArg(rawArgs: string[]): string | undefined;
+export declare function printDomainsHelp(): void;

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

@@ -6,3 +6,54 @@ export declare function parseEnvAssignment(operands: string[]): {
 } | null;
 /** The prefix that makes `key` a build-time variable, or undefined. */
 export declare function buildTimeEnvPrefix(key: string): string | undefined;
+/** The flags `rebase cloud env set` takes, on top of the global cloud ones. */
+export declare const ENV_SET_FLAGS: {
+    readonly "--secret": BooleanConstructor;
+    readonly "--force": BooleanConstructor;
+};
+/**
+ * What `env set` was asked to store.
+ *
+ * The sharp one in this family: the old operand filter left `--project`'s value
+ * in the operand list, so `rebase cloud env set KEY -p acme` parsed as the
+ * `KEY VALUE` form and stored the project slug as KEY's value — a write that
+ * succeeds, reports success, and is wrong. Strict parsing consumes `-p` with
+ * its value, leaving `["KEY"]` and the documented empty value.
+ *
+ * A value beginning with `-` must use the `KEY=-v` form; the bare `KEY -v` form
+ * is refused rather than guessed at, as everywhere else strict parsing is used.
+ *
+ * Exported so its tests drive the real parser rather than a copy of it.
+ */
+export declare function resolveEnvSetArgs(rawArgs: string[]): {
+    flags: import("arg").Result<{
+        readonly "--secret": BooleanConstructor;
+        readonly "--force": BooleanConstructor;
+    } & {
+        readonly "--json": BooleanConstructor;
+        readonly "--yes": BooleanConstructor;
+        readonly "--help": BooleanConstructor;
+        readonly "--project": StringConstructor;
+        readonly "-p": "--project";
+        readonly "-y": "--yes";
+        readonly "-h": "--help";
+    }>;
+    assignment: {
+        key: string;
+        value: string;
+    } | null;
+};
+/**
+ * The variable `env unset` / `env reveal` names.
+ *
+ * `unset` is a delete, and the operand filter aimed it at the wrong variable:
+ * `rebase cloud env unset -p acme` removed a variable called "acme" from the
+ * linked project instead of reporting a missing KEY, and `env unset -p acme
+ * KEY` removed "acme" instead of KEY. Both read `--project`'s value as the
+ * operand — a plain word in the right position that no flag filter can catch.
+ *
+ * `action` is the word the caller used (`unset`, `rm`, `delete`, `reveal`); the
+ * count of command words is the same for all of them.
+ */
+export declare function resolveEnvKeyArg(rawArgs: string[], action: string): string | undefined;
+export declare function printEnvHelp(): void;

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

@@ -1,3 +1,24 @@
 /** The identifier CREATE EXTENSION takes. `pgvector` is a common alias. */
 export declare function resolveExtensionAlias(name: string): string;
 export declare function extensionsCommand(action: string | undefined, rawArgs: string[]): Promise<void>;
+/**
+ * The extension `enable`/`disable` names, plus the flags that gate it.
+ *
+ * Under the old operand filter `rebase cloud extensions enable -p acme` read
+ * `--project`'s value as the extension name and asked the server to install one
+ * called "acme"; `extensions disable -p acme vector` dropped "acme" rather than
+ * vector. Strict parsing consumes the flag with its value.
+ */
+export declare function resolveExtensionArgs(rawArgs: string[], action: "enable" | "disable"): {
+    flags: import("arg").Result<{
+        readonly "--json": BooleanConstructor;
+        readonly "--yes": BooleanConstructor;
+        readonly "--help": BooleanConstructor;
+        readonly "--project": StringConstructor;
+        readonly "-p": "--project";
+        readonly "-y": "--yes";
+        readonly "-h": "--help";
+    }>;
+    name: string;
+};
+export declare function printExtensionsHelp(): void;

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

@@ -1 +1,2 @@
 export declare function orgsCommand(subcommand: string | undefined, rawArgs: string[]): Promise<void>;
+export declare function printOrgsHelp(): void;

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

@@ -31,7 +31,36 @@ export declare function chooseRequestedTarget(requested: string | undefined, tar
     provider: string;
     region?: string;
 } | null;
+/** The flags `rebase cloud projects create` takes. */
+export declare const CREATE_PROJECT_FLAGS: {
+    readonly "--name": StringConstructor;
+    readonly "--subdomain": StringConstructor;
+    readonly "--repo": StringConstructor;
+    readonly "--branch": StringConstructor;
+    readonly "--provider": StringConstructor;
+    readonly "--region": StringConstructor;
+    readonly "--vm-size": StringConstructor;
+    readonly "--org": StringConstructor;
+    readonly "--link": BooleanConstructor;
+    readonly "-n": "--name";
+};
 export declare function createProject(rawArgs: string[]): Promise<void>;
+/**
+ * Which project `projects info` / `projects delete` acts on.
+ *
+ * The id is optional — omitted, it falls back to `--project` or the link file —
+ * and the dispatcher used to read it off `positionals()`, which skips only
+ * LEADING `-` tokens and declares only the global cloud flags. So an undeclared
+ * flag written after the action became the id: `rebase cloud projects delete
+ * --force` looked up a project named "--force" and reported it missing, rather
+ * than saying there is no such flag. Benign next to the deletes and writes the
+ * rest of this family aimed at the wrong resource, but the same mistake, and
+ * `positionals()` has no spec with which to do better — the handler's own
+ * module does.
+ *
+ * Exported so its tests drive the real parser rather than a copy of it.
+ */
+export declare function resolveProjectArg(rawArgs: string[], action: "info" | "delete"): string;
 export declare function projectInfo(rawArgs: string[], projectRef: string): Promise<void>;
 export declare function deleteProject(rawArgs: string[], projectRef: string): Promise<void>;
 export declare function firstRow(client: CloudClient, collection: string, projectId: string): Promise<Record<string, unknown> | undefined>;

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

@@ -57,8 +57,22 @@ export declare function describeRuntime(project: {
 }): string;
 export declare function statusCommand(rawArgs: string[]): Promise<void>;
 export declare function metricsCommand(rawArgs: string[]): Promise<void>;
+/**
+ * The webhook `webhooks delete` names.
+ *
+ * The worst instance of the operand-filter bug in this family, because the
+ * argument is consumed by a DELETE and the wrong value looks entirely
+ * plausible: `rebase cloud webhooks delete --project acme 42` filtered out
+ * `--project` and kept "acme", so the id it deleted was the project slug rather
+ * than the 42 the caller wrote. Strict parsing consumes the flag with its
+ * value, leaving `["42"]`.
+ *
+ * Exported so its tests drive the real parser.
+ */
+export declare function resolveWebhookIdArg(rawArgs: string[]): string | undefined;
 export declare function webhooksCommand(subcommand: string | undefined, rawArgs: string[]): Promise<void>;
 export declare function storageCommand(action: string | undefined, rawArgs: string[]): Promise<void>;
+export declare function printStorageHelp(): void;
 export declare function clustersCommand(rawArgs: string[]): Promise<void>;
 export declare function billingCommand(rawArgs: string[]): Promise<void>;
 export {};

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

@@ -6,3 +6,4 @@ export declare function buildSettingsPatch(args: {
     repo?: string;
     branch?: string;
 }): Record<string, string>;
+export declare function printSettingsHelp(): void;

package/dist/commands/dev.d.ts

@@ -6,12 +6,23 @@ export declare const DEV_PORT_FILENAME = ".rebase-dev-port";
  * Two different project directories will almost always get different ports.
  */
 export declare function getProjectPort(projectRoot: string): number;
+export declare function resolveStartPort(projectRoot: string, explicitPort?: number): number;
 /**
- * Resolve the best starting port for this project:
- * 1. Explicit --port flag (highest priority)
- * 2. PORT env var
- * 3. Previously used port from .rebase-dev-port (port affinity across restarts)
- * 4. Deterministic hash from project path (unique per project)
+ * The flags `rebase dev` takes.
+ *
+ * Exported so `dev.test.ts` can assert that every short alias the help
+ * advertises is declared here: the help said `--port, -p` while the spec has
+ * only ever declared `-P`, so `rebase dev -p 4000` typed straight off the help
+ * page passed `4000` as a positional and started on the default port.
  */
-export declare function resolveStartPort(projectRoot: string, explicitPort?: number): number;
+export declare const DEV_FLAGS: {
+    readonly "--backend-only": BooleanConstructor;
+    readonly "--frontend-only": BooleanConstructor;
+    readonly "--port": NumberConstructor;
+    readonly "--generate": BooleanConstructor;
+    readonly "-b": "--backend-only";
+    readonly "-f": "--frontend-only";
+    readonly "-P": "--port";
+    readonly "-g": "--generate";
+};
 export declare function devCommand(rawArgs: string[]): Promise<void>;

package/dist/commands/eject.d.ts

@@ -1 +1,43 @@
+/**
+ * The two ways one project's payload differs from another's.
+ *
+ * Neither is a flag: both were decided at `rebase init` time. `--headless`
+ * deletes `config/collections`, `backend/src/schema.generated.ts` and
+ * `frontend/`, so a payload that assumes them emits an entrypoint importing
+ * three files that are not there and a Dockerfile whose first `COPY` fails.
+ */
+interface ProjectShape {
+    /**
+     * Collections declared in code, under `<config>/collections`. Without them
+     * the server derives its API from the live database instead — the same
+     * signal `rebase build` reads.
+     */
+    collections: boolean;
+    /** A `frontend` workspace for the image to build and the entrypoint to serve. */
+    frontend: boolean;
+}
+/**
+ * Render one payload file for this project.
+ *
+ * The payload is one set of files rather than one per flavour, because the
+ * flavours differ by about a dozen lines and two copies of a 230-line
+ * entrypoint are how copies drift — the payload had already drifted from
+ * `app/backend/src/index.ts` over `cronsDir`, which silently stopped every cron
+ * job in an ejected project. So both branches live in the file, marked with
+ * lines that are comments in TypeScript, YAML and Dockerfiles alike:
+ *
+ *     // {{#collections}}
+ *     import { tables } from "./schema.generated.js";
+ *     // {{/collections}}
+ *     // {{^collections}}
+ *     // No schema module: this project introspects the database.
+ *     // {{/collections}}
+ *
+ * `{{#name}}` keeps its block when the flag is on, `{{^name}}` when it is off,
+ * and the marker lines themselves never reach the user. The template stays
+ * valid TypeScript with every marker line removed, which is the flavour a
+ * typechecker would see.
+ */
+export declare function renderPayload(contents: string, shape: ProjectShape, projectName: string): string;
 export declare function ejectCommand(rawArgs?: string[]): Promise<void>;
+export {};

package/dist/commands/init.d.ts

@@ -68,4 +68,71 @@ export declare function formatCdTarget(cwd: string, targetDirectory: string): st
  * triggering the non-TTY error. */
 export declare function printInitHelp(): void;
 export declare function createRebaseApp(rawArgs: string[]): Promise<void>;
+/** The flags `rebase init` takes. */
+export declare const INIT_FLAGS: {
+    readonly "--git": BooleanConstructor;
+    readonly "--install": BooleanConstructor;
+    readonly "--database-url": StringConstructor;
+    readonly "--introspect": BooleanConstructor;
+    readonly "--template": StringConstructor;
+    readonly "--headless": BooleanConstructor;
+    readonly "--project": StringConstructor;
+    readonly "--setup-key": StringConstructor;
+    readonly "--yes": BooleanConstructor;
+    readonly "-g": "--git";
+    readonly "-i": "--install";
+    readonly "-t": "--template";
+    readonly "-y": "--yes";
+};
+/**
+ * Whether `port` is free — on the wildcard address *and* on both loopback addresses.
+ *
+ * All three, because on macOS/BSD a successful bind does not mean the port is
+ * unused. Sockets carry `SO_REUSEADDR` (Node sets it), under which a wildcard
+ * bind and a specific-address bind on the same port do not conflict — in either
+ * direction. So each probe alone has a blind spot, and they are different ones:
+ *
+ * - **Wildcard only** (what this used to do) misses a server bound to
+ *   `127.0.0.1` and `[::1]` — a Homebrew or Postgres.app install, i.e. most
+ *   developer machines. 5432 was reported free while it was already serving
+ *   another project's database. Docker then published `*:5432` for the same
+ *   reason and the container started cleanly, with no "port already allocated"
+ *   error anywhere to hint at the collision. `DATABASE_URL` pointed at
+ *   `localhost:5432`, `localhost` resolves to `::1` first, and every command
+ *   reported success while reading and writing the *pre-existing* database — a
+ *   `db push` would have created tables, roles and RLS policies inside it.
+ *
+ * - **Loopback only** misses the opposite case: Docker Desktop publishes a
+ *   container's port on `*`, and a specific-address bind succeeds right past it.
+ *   That port is free to probe and unusable to publish, so `docker compose up -d
+ *   db` fails on "Bind for 0.0.0.0:PORT failed: port is already allocated" —
+ *   loudly, but only after the project has been generated around the bad port.
+ *
+ * Requiring all three costs three sockets and leaves neither gap. The wildcard
+ * bind is the one the container itself has to make; the loopback binds are the
+ * addresses `DATABASE_URL` will actually name.
+ */
+export declare function isPortAvailable(port: number): Promise<boolean>;
+/**
+ * The runtime image tag to pin, given the version of the CLI doing the scaffolding.
+ *
+ * Only a stable release publishes `rebasepro/server` — a multi-arch build on
+ * every push to main would cost minutes per commit for an image nobody pulls.
+ * So pinning a prerelease CLI's own version writes a tag that cannot exist, and
+ * `docker compose up` fails on `manifest unknown`, which is the same dead end
+ * as the missing-repository bug this pinning was added to prevent.
+ *
+ * A prerelease therefore falls back to `latest`, which is correct rather than
+ * merely available: a bundle's manifest declares the runtime range it needs
+ * (`^1`), the image supplies only `@rebasepro/server`, and the framework a
+ * bundle runs is installed from its own `deps.declared` at boot. The current
+ * stable runtime boots a canary bundle by design.
+ *
+ * A floating tag is a real cost — it is what pinning exists to avoid — so say
+ * so in the file rather than leaving a reader to discover it.
+ */
+export declare function resolveRuntimeImageTag(cliVersion: string): {
+    tag: string;
+    note?: string;
+};
 export declare function configureEnvFile(targetDirectory: string, databaseUrl?: string): Promise<void>;