@devdogsuga/devtools 0.1.26 → 0.1.28

package/dist/env/selection.d.ts

@@ -1,105 +0,0 @@
-import { type VaultTarget } from "../bws/environments.js";
-export interface PushSelection {
-    push: Map<string, string>;
-    /**
-     * Public per-environment values, bound for Bitwarden and for GitHub
-     * *variables*. Plaintext at both ends, with no libsodium sealing, and
-     * readable back through the API, which is what lets `audit` compare them by
-     * value.
-     */
-    variables: Map<string, string>;
-    refused: string[];
-    /** Present in the file, declared by no manifest. Skipped, warned about. */
-    unknown: string[];
-    /**
-     * Left to the registry: the file still holds the declared derivation itself.
-     *
-     * Its own outcome rather than part of the skipped-and-unreported majority,
-     * because `env init --target` WRITES these lines, eight of them, and a push
-     * that said nothing about them would read as "your eight `$VAR` lines were
-     * stored". They were not, deliberately. See `selectForPush()`.
-     */
-    derived: string[];
-}
-/**
- * Public per-environment values: Bitwarden, and then GitHub *variables*.
- *
- * Symmetric with `neverStore()` and `minted()`: a set, read at call time,
- * refusing an empty registry. See `getEnvSync().variableKeys()` for why the set is narrower
- * than "every public key" and why the five `localStack` ones are still in it.
- */
-export declare function pushableVariables(): Set<string>;
-/**
- * Nothing to send: the committed and per-developer non-secrets, the minted
- * credentials, plus the apply-only ones outside production.
- *
- * ⚠️ This is `getEnvSync().neverSecretKeys()` MINUS the pushable variables, and the
- * subtraction is what gave 27 public, environment-scoped values a remote home.
- * They used to land here, as "not a secret, therefore uninteresting", which
- * conflated two different facts: that a value must not be a GitHub *secret*
- * (true of all of them) and that it goes nowhere (true only of the committed
- * and per-developer ones). Every consumer of this set reads it as the second,
- * so the first no longer belongs in it.
- *
- * The apply-only two exist to reshape production, so a copy in staging or
- * preflight is a second write-capable token to rotate for no benefit.
- *
- * Minted credentials are here because there is nothing to send: the value is
- * signed at deploy time and its only copy is on the Worker. Skipped rather
- * than refused, because "not pushed" is the ordinary state of one of these. A
- * refusal is for a credential somebody put in the file expecting it to sync,
- * and nobody has this one to put there.
- *
- * ⚠️ AND, for a target no app boots from, EVERYTHING THAT DID NOT OPT IN. This
- * is the one exclusion that inverts the default: a deployed target skips a
- * named few, `preflight` skips all but a named few. It inverts it because the
- * two questions are different. "Which keys does staging not want?" has a short
- * answer; "which credentials may a CI-only tier hold?" has the answer "the
- * ones deliberately narrowed for it, and nothing by omission". Until this
- * existed, `env push --target preflight` uploaded `SUPABASE_JWT_SIGNING_KEY`,
- * `SECRET_KEY` and `GH_APP_PRIVATE_KEY` into a project whose GitHub
- * environment is reachable from `main`. Both halves are derived, the target
- * from `deployEnv: false` and the keys from `EnvMeta.narrowed`, so neither is
- * a list to keep up to date.
- */
-export declare function ignoredFor(target: VaultTarget): Set<string>;
-export declare function neverStore(): Set<string>;
-/**
- * The keys a push for this target ROUTES: its two destinations, unioned.
- *
- * The complement of everything above, stated positively, because one consumer
- * needs the question the other way round. `env init --target staging` renders
- * a file whose whole purpose is to be filled in and pushed, so the keys it
- * should contain are exactly the keys a push for that target would carry
- * somewhere. Derived from `ignoredFor()` rather than re-listed, so the file
- * and the upload cannot disagree about which target a key belongs to. The
- * generated file used to be byte-identical for all three targets, which put
- * the apply-tier credentials in `.env.staging` where `ignoredFor()` refuses
- * them. The same derivation shrank `env init --target preflight` from 45 keys
- * to the narrowed ones: the exclusion is stated once, in `ignoredFor()`, and
- * the rendered file follows for free.
- *
- * The `neverStore()` subtraction is unreachable today (a never-store key is
- * neither `secrecy: "secret"` nor `"public"`, so neither selector returns it)
- * and is written down anyway: this set decides what gets an assignable line in
- * a file people fill in, and `BWS_ACCESS_TOKEN=` is the one line that must
- * never appear in one.
- */
-export declare function keysRoutedTo(target: VaultTarget): Set<string>;
-/**
- * Signed at deploy time; the deploy target holds the only copy.
- *
- * Passed to `audit` separately from `ignoredFor()` even though it is a subset,
- * because the audit needs the distinction: an ignored key is uninteresting
- * everywhere, whereas a minted one is CORRECT on Cloudflare (which is what
- * stops it being reported as an orphan and pruned) and WRONG in Bitwarden or
- * GitHub.
- */
-export declare function minted(): Set<string>;
-/**
- * `entries` is the ACTIVE assignments in the local `.env`, in file order.
- *
- * A commented-out line is not an assignment and never reaches here, which is
- * what makes commenting-out a safe way to retire a key.
- */
-export declare function selectForPush(entries: readonly (readonly [string, string])[], target: VaultTarget): PushSelection;

package/dist/env/selection.js

@@ -1,228 +0,0 @@
-import {} from "../bws/environments.js";
-import { assertRegistryLoaded } from "./discovery.js";
-import { getEnvSync } from "../repo/peers.js";
-// The key sets are DERIVED from the env manifests (see `discovery.ts`), not
-// hand-listed here, which is why every function below insists the registry is
-// loaded. An empty registry makes each selector return `[]`, and `[]` fails
-// open in the one direction that matters: nothing would be refused, so
-// `BWS_ACCESS_TOKEN` would upload.
-/**
- * Public per-environment values: Bitwarden, and then GitHub *variables*.
- *
- * Symmetric with `neverStore()` and `minted()`: a set, read at call time,
- * refusing an empty registry. See `getEnvSync().variableKeys()` for why the set is narrower
- * than "every public key" and why the five `localStack` ones are still in it.
- */
-export function pushableVariables() {
-    assertRegistryLoaded();
-    return new Set(getEnvSync().variableKeys());
-}
-/**
- * Nothing to send: the committed and per-developer non-secrets, the minted
- * credentials, plus the apply-only ones outside production.
- *
- * ⚠️ This is `getEnvSync().neverSecretKeys()` MINUS the pushable variables, and the
- * subtraction is what gave 27 public, environment-scoped values a remote home.
- * They used to land here, as "not a secret, therefore uninteresting", which
- * conflated two different facts: that a value must not be a GitHub *secret*
- * (true of all of them) and that it goes nowhere (true only of the committed
- * and per-developer ones). Every consumer of this set reads it as the second,
- * so the first no longer belongs in it.
- *
- * The apply-only two exist to reshape production, so a copy in staging or
- * preflight is a second write-capable token to rotate for no benefit.
- *
- * Minted credentials are here because there is nothing to send: the value is
- * signed at deploy time and its only copy is on the Worker. Skipped rather
- * than refused, because "not pushed" is the ordinary state of one of these. A
- * refusal is for a credential somebody put in the file expecting it to sync,
- * and nobody has this one to put there.
- *
- * ⚠️ AND, for a target no app boots from, EVERYTHING THAT DID NOT OPT IN. This
- * is the one exclusion that inverts the default: a deployed target skips a
- * named few, `preflight` skips all but a named few. It inverts it because the
- * two questions are different. "Which keys does staging not want?" has a short
- * answer; "which credentials may a CI-only tier hold?" has the answer "the
- * ones deliberately narrowed for it, and nothing by omission". Until this
- * existed, `env push --target preflight` uploaded `SUPABASE_JWT_SIGNING_KEY`,
- * `SECRET_KEY` and `GH_APP_PRIVATE_KEY` into a project whose GitHub
- * environment is reachable from `main`. Both halves are derived, the target
- * from `deployEnv: false` and the keys from `EnvMeta.narrowed`, so neither is
- * a list to keep up to date.
- */
-export function ignoredFor(target) {
-    assertRegistryLoaded();
-    const pushable = pushableVariables();
-    const skip = new Set(getEnvSync()
-        .neverSecretKeys()
-        .filter((key) => !pushable.has(key)));
-    for (const key of getEnvSync().mintedKeys())
-        skip.add(key);
-    if (target !== "production") {
-        for (const key of getEnvSync().applyOnlyKeys())
-            skip.add(key);
-    }
-    // Plan-tier keys are read by exactly two jobs: `main-plan` (preflight) and
-    // `production-plan` (production). Everywhere else, staging today, a copy is
-    // a credential nothing reads, so it is skipped the same way the apply-tier
-    // pair is. Preflight is NOT excluded here: the narrowed-only branch below
-    // already decides that target key by key, and a plan-tier key reaches it
-    // through its `narrowed` opt-in.
-    if (target !== "production" && !getEnvSync().holdsOnlyNarrowedKeys(target)) {
-        for (const key of getEnvSync().planOnlyKeys())
-            skip.add(key);
-    }
-    if (getEnvSync().holdsOnlyNarrowedKeys(target)) {
-        const narrow = new Set(getEnvSync().narrowedKeys());
-        // Over every DECLARED key, not over the routable ones: this set is also
-        // what `audit` treats as uninteresting and what `push` reports orphans
-        // against, and both want the full answer.
-        for (const key of getEnvSync().variables().keys()) {
-            if (!narrow.has(key))
-                skip.add(key);
-        }
-    }
-    return skip;
-}
-export function neverStore() {
-    assertRegistryLoaded();
-    return new Set(getEnvSync().neverStoreKeys());
-}
-/**
- * The keys a push for this target ROUTES: its two destinations, unioned.
- *
- * The complement of everything above, stated positively, because one consumer
- * needs the question the other way round. `env init --target staging` renders
- * a file whose whole purpose is to be filled in and pushed, so the keys it
- * should contain are exactly the keys a push for that target would carry
- * somewhere. Derived from `ignoredFor()` rather than re-listed, so the file
- * and the upload cannot disagree about which target a key belongs to. The
- * generated file used to be byte-identical for all three targets, which put
- * the apply-tier credentials in `.env.staging` where `ignoredFor()` refuses
- * them. The same derivation shrank `env init --target preflight` from 45 keys
- * to the narrowed ones: the exclusion is stated once, in `ignoredFor()`, and
- * the rendered file follows for free.
- *
- * The `neverStore()` subtraction is unreachable today (a never-store key is
- * neither `secrecy: "secret"` nor `"public"`, so neither selector returns it)
- * and is written down anyway: this set decides what gets an assignable line in
- * a file people fill in, and `BWS_ACCESS_TOKEN=` is the one line that must
- * never appear in one.
- */
-export function keysRoutedTo(target) {
-    assertRegistryLoaded();
-    const skip = ignoredFor(target);
-    const refuse = neverStore();
-    return new Set([...getEnvSync().storableKeys(), ...getEnvSync().variableKeys()].filter((key) => !skip.has(key) && !refuse.has(key)));
-}
-/**
- * Signed at deploy time; the deploy target holds the only copy.
- *
- * Passed to `audit` separately from `ignoredFor()` even though it is a subset,
- * because the audit needs the distinction: an ignored key is uninteresting
- * everywhere, whereas a minted one is CORRECT on Cloudflare (which is what
- * stops it being reported as an orphan and pruned) and WRONG in Bitwarden or
- * GitHub.
- */
-export function minted() {
-    assertRegistryLoaded();
-    return new Set(getEnvSync().mintedKeys());
-}
-/**
- * Whether the file's value is still, exactly, the derivation the registry
- * declares for this key.
- *
- * ⚠️ EXACT IDENTITY, and nothing looser. Not "looks like a formula", not
- * "contains a `$`", not "starts with the derivation". String equality with
- * what `getEnvSync().derivationOf()` returns. Everything else somebody could type is
- * deliberate input: a real value, obviously, but also a DIFFERENT derivation,
- * which is how a target says its value is built from something else. Widening
- * this predicate by one inch silently drops a credential on the floor: the
- * push reports success, the environment is missing a secret, and `env audit`
- * agrees with the file it came from.
- *
- * `some` rather than `every` across duplicate declarations, matching
- * `keysWhere()`: the safe reading is that a value matching ANY declared
- * derivation is that derivation. It cannot discard a credential either way,
- * since no usable credential is byte-identical to `$BASE_URL/auth/callback`.
- */
-function isDeclaredDerivation(entries, value) {
-    // `getEnvSync().derivationOf()` returns null for everything that is not a derivation, and
-    // `value` is non-empty by the time this is called, so null never matches.
-    return entries.some((entry) => getEnvSync().derivationOf(entry.meta) === value);
-}
-/**
- * `entries` is the ACTIVE assignments in the local `.env`, in file order.
- *
- * A commented-out line is not an assignment and never reaches here, which is
- * what makes commenting-out a safe way to retire a key.
- */
-export function selectForPush(entries, target) {
-    const skip = ignoredFor(target);
-    const refuse = neverStore();
-    const pushable = pushableVariables();
-    const declared = getEnvSync().variables();
-    const push = new Map();
-    const publicValues = new Map();
-    const refused = [];
-    const unknown = [];
-    const derived = [];
-    for (const [key, value] of entries) {
-        // Refusal is checked FIRST and independently of the value. A blank
-        // BWS_ACCESS_TOKEN is still a line somebody is about to fill in.
-        if (refuse.has(key)) {
-            if (value !== "")
-                refused.push(key);
-            continue;
-        }
-        // Undeclared means unclassified. Nothing says whether this is a secret,
-        // whose it is, or where it routes, so it does not leave the machine.
-        // Reported even when empty, because the problem is the missing
-        // declaration, not the value.
-        if (!declared.has(key)) {
-            unknown.push(key);
-            continue;
-        }
-        // Checked BEFORE the variable branch, so the exclusions about *this
-        // target* keep winning: an apply-only key outside production, or a minted
-        // one anywhere, is skipped whatever its secrecy. The two sets are disjoint
-        // today, and this ordering is what keeps a future overlap failing closed
-        // rather than open.
-        if (skip.has(key))
-            continue;
-        // An empty secret reads as "configured" to every consumer that checks for
-        // presence, which is worse than an absent one. Equally true of a variable:
-        // an empty `PROJECT_REF` builds a URL pointing at nothing.
-        if (value === "")
-            continue;
-        // Still the declared derivation, so there is no VALUE here, only the
-        // shape, which the registry already holds. Storing it is harmful rather
-        // than merely redundant: a stored value BEATS the registry when the
-        // deploy composes an env file, so the literal `https://$PROJECT_REF...`
-        // arrives as `from: "variable"`, is never expanded (only `from: "derived"`
-        // is), and is written single-quoted, which dotenvx takes as fully literal.
-        // The deployed app then resolves a host called `$PROJECT_REF.supabase.co`
-        // while `env audit` reports NO DRIFT, because the stored value does match
-        // the file.
-        //
-        // ⚠️ NOT expanded here and sent, which is the tempting alternative. That
-        // would make GitHub the source of truth for these eight shapes: changing
-        // `REST_URL` from `/rest/v1` to `/rest/v2` in the registry would then never
-        // take effect anywhere. Skipping is what lets the deploy's `fromRegistry()`
-        // run and expand at compose time.
-        if (isDeclaredDerivation(declared.get(key), value)) {
-            derived.push(key);
-            continue;
-        }
-        // Public and per-environment: a GitHub *variable*, not a secret. Routed
-        // here rather than dropped, because the value still has to reach CI, and
-        // still belongs in Bitwarden so that `pull` rebuilds a COMPLETE env file
-        // rather than the secret half of one.
-        if (pushable.has(key)) {
-            publicValues.set(key, value);
-            continue;
-        }
-        push.set(key, value);
-    }
-    return { push, variables: publicValues, refused, unknown, derived };
-}

package/dist/env-entry.d.ts

@@ -1,49 +0,0 @@
-import type { DeployEnvironment } from "@devdogsuga/env";
-import type { DevDatabase } from "@devdogsuga/env/load";
-import type * as EnvLoadModule from "@devdogsuga/env/load";
-import type * as EnvSessionModule from "@devdogsuga/env/session";
-import { type EnsureGeneratedEnvResult } from "./db/generated-env.js";
-export interface EnvEntryDeps {
-    envLoad: typeof EnvLoadModule;
-    envSession: typeof EnvSessionModule;
-    /**
-     * Regenerates `.env.generated` from a running local stack when this
-     * checkout's own copy is missing, right before the session's env files
-     * load — see this module's header and `db/generated-env.ts`. Required
-     * (not defaulted here) so every caller is explicit about it: `launch.ts`
-     * uses `realEnvEntryDeps` for the real wiring, tests inject a stub that
-     * never touches a real filesystem, Docker daemon, or the Supabase CLI.
-     */
-    ensureGeneratedEnv: (tier: DeployEnvironment, devDatabase: DevDatabase | undefined) => Promise<EnsureGeneratedEnvResult>;
-}
-/**
- * The production wiring for `EnvEntryDeps`, shared by both call sites in
- * `launch.ts`.
- */
-export declare function realEnvEntryDeps(envLoad: typeof EnvLoadModule, envSession: typeof EnvSessionModule): EnvEntryDeps;
-/**
- * Enters `tier` (and `devDatabase`'s overlay) for the current process,
- * handling `LocalStackOfflineError` (the TTY offer to start the local stack,
- * the `db`-exemption degraded-entry fallback) and `MissingEnvFileError` (the
- * clean-clone tolerance for `development`, fatal otherwise) exactly as
- * `launch.ts` always has. `dispatchCommand` is called exactly once, in every
- * non-fatal branch — including immediately, in place of any further entry
- * work, when a declined-then-accepted stack start already ran it — so its
- * return value is always this function's own return value.
- */
-export declare function enterSessionEnvironment<T>(tier: DeployEnvironment, devDatabase: DevDatabase | undefined, commandArgv: readonly string[], deps: EnvEntryDeps, dispatchCommand: () => Promise<T>): Promise<T>;
-/**
- * What `runMenu` calls, right before dispatching the chosen command, in
- * place of entering the environment itself — `commandArgv` is the chosen
- * leaf's argv, `dispatchCommand` is `runMenu`'s own injected dispatcher for
- * it. See this module's header for why a module-level slot rather than a
- * `runMenu` parameter.
- */
-export type MenuEnvHook = (commandArgv: readonly string[], dispatchCommand: () => Promise<string | null>) => Promise<string | null>;
-/** Set by `launch.ts` for a menu invocation; `undefined` for a typed command
- *  (which entered already) and for any test that drives `runMenu` directly
- *  without going through `launch.ts` at all. */
-export declare function setMenuEnvHook(hook: MenuEnvHook | undefined): void;
-/** Read by `runMenu`, then cleared — see this module's header on why a
- *  nested launcher must not inherit a stale hook. */
-export declare function takeMenuEnvHook(): MenuEnvHook | undefined;

package/dist/env-entry.js

@@ -1,204 +0,0 @@
-/**
- * Entering a resolved deploy tier's environment — the part of `launch.ts`
- * that actually loads `.env.<tier>` (and its `DEV_DB` overlay) onto
- * `process.env`, with the two recoverable failures `enterEnvironment` can
- * throw handled the same way everywhere it is called from.
- *
- * ## Why this is its own module
- *
- * A typed command line enters its tier at launch, before `cli.ts` is even
- * imported — see `launch.ts`'s header. A menu invocation cannot: the whole
- * point of the wizard is to show a contributor what is possible before they
- * have chosen anything, and loading env files (and possibly offering to
- * start the local stack) before that first question is answered means
- * whatever changed in another terminal while they were deciding — the stack
- * coming up, `.env.generated` being rewritten — is missed. So a menu
- * invocation defers this exact block until `menu.ts`'s `runMenu` is about to
- * dispatch the ONE command the reader chose, right before it runs.
- *
- * `enterSessionEnvironment` is the block both callers share, generic over
- * what "dispatch the command" means to each: `launch.ts` imports `cli.ts`
- * fresh and calls its `main()`, `runMenu` already holds the dispatcher
- * `cli.ts` injected into it. `commandArgv` is the argv the caller is about to
- * dispatch — used for the two `LocalStackOfflineError` exemptions (a `db`
- * lifecycle command, and an empty argv) exactly as `launch.ts` used `rest`
- * for them before this was extracted.
- *
- * ## The hook `runMenu` calls
- *
- * `setMenuEnvHook`/`takeMenuEnvHook` are a module-level slot shared by
- * `launch.ts` and `menu.ts`: `cli.ts` calls `runMenu` with a fixed signature
- * that has no room for a per-invocation callback. `launch.ts` sets the hook
- * for a menu invocation before handing off to `cli.ts`; `runMenu` takes it
- * (reading clears it) right before its own dispatch, so a nested launcher
- * never inherits a stale one.
- *
- * ## Regenerating `.env.generated` before entry
- *
- * Before either caller's `enterEnvironment` call, this also gives a running
- * local stack a chance to fix its own absence: `deps.ensureGeneratedEnv`
- * (`db/generated-env.ts`'s `ensureGeneratedEnvFile`, wired by
- * `realEnvEntryDeps`) writes `.env.generated` from `supabase status -o env`
- * when the port is listening but the file is missing — the common shape of
- * a local stack another workspace started, sharing this repo's
- * `project_id` — so the entry below usually just succeeds instead of
- * throwing `LocalStackOfflineError` or warning about a file nobody wrote.
- * A `"foreign"` result (the stack on the port belongs to a DIFFERENT
- * project) prints its own hint and then falls through to the unchanged
- * error handling below, since the file is still missing either way.
- */
-import { confirm } from "@clack/prompts";
-import { ensureGeneratedEnvFile, realEnsureGeneratedEnvDeps, } from "./db/generated-env.js";
-import { unwrap } from "./ui.js";
-/**
- * The production wiring for `EnvEntryDeps`, shared by both call sites in
- * `launch.ts`.
- */
-export function realEnvEntryDeps(envLoad, envSession) {
-    return {
-        envLoad,
-        envSession,
-        ensureGeneratedEnv: (tier, devDatabase) => ensureGeneratedEnvFile(tier, devDatabase, realEnsureGeneratedEnvDeps(envLoad.probeLocalStack)),
-    };
-}
-/**
- * Enters `tier` (and `devDatabase`'s overlay) for the current process,
- * handling `LocalStackOfflineError` (the TTY offer to start the local stack,
- * the `db`-exemption degraded-entry fallback) and `MissingEnvFileError` (the
- * clean-clone tolerance for `development`, fatal otherwise) exactly as
- * `launch.ts` always has. `dispatchCommand` is called exactly once, in every
- * non-fatal branch — including immediately, in place of any further entry
- * work, when a declined-then-accepted stack start already ran it — so its
- * return value is always this function's own return value.
- */
-export async function enterSessionEnvironment(tier, devDatabase, commandArgv, deps, dispatchCommand) {
-    const { envLoad, envSession } = deps;
-    const generated = await deps.ensureGeneratedEnv(tier, devDatabase);
-    if (generated.outcome === "wrote" || generated.outcome === "foreign") {
-        process.stderr.write(`${generated.line}\n`);
-    }
-    // Mandatory, not chattiness: which database a command is about to touch
-    // must never be a guess. Names the QUALIFIED session (`development:local`)
-    // when one was resolved. See `session.ts`'s and `load.ts`'s own headers.
-    const reportEntered = (files, label) => {
-        process.stderr.write(`devtools: loaded ${files.length > 0 ? files.join(", ") : "no env files"} (${label})\n`);
-    };
-    const sessionLabel = devDatabase === undefined ? tier : `${tier}:${devDatabase}`;
-    try {
-        // `override: false` — see `launch.ts`'s former header comment on this
-        // same call, reproduced here since this IS that call now.
-        const entered = await envSession.enterEnvironment(tier, {
-            override: false,
-            devDatabase,
-        });
-        for (const warning of entered.warnings) {
-            process.stderr.write(`devtools: ${warning}\n`);
-        }
-        reportEntered(entered.files, sessionLabel);
-    }
-    catch (err) {
-        if (err instanceof envLoad.LocalStackOfflineError) {
-            // The session explicitly means the local database and the stack is not
-            // reachable.
-            process.stderr.write(`devtools: ${err.message}\n`);
-            // Offer to bring the stack up right here and then carry on with the
-            // command about to dispatch. Only on a TTY, and not when the command is
-            // ITSELF a stack lifecycle command — `db start`/`stop`/`restart` do
-            // this on their own, and `db stop` against an already-down stack must
-            // not be interrupted by an offer to start it. An empty `commandArgv`
-            // (nothing chosen yet) is likewise left alone.
-            const lifecycle = commandArgv[0] === "db" &&
-                (commandArgv[1] === "start" ||
-                    commandArgv[1] === "stop" ||
-                    commandArgv[1] === "restart");
-            if (process.stdin.isTTY === true &&
-                commandArgv.length !== 0 &&
-                !lifecycle) {
-                const start = unwrap(await confirm({
-                    message: "Start the local Supabase stack now?",
-                }));
-                if (start) {
-                    // Keep the session's local qualifier set so the env refresh that
-                    // `runStackCommand("start")` performs on success re-applies the
-                    // overlay under it, and the command dispatched next resolves the
-                    // freshly-started local database.
-                    if (devDatabase !== undefined)
-                        process.env.DEV_DB = devDatabase;
-                    const { runStackCommand } = await import("./stack.js");
-                    const { code, lines } = await runStackCommand("start", null);
-                    for (const line of lines) {
-                        process.stderr.write(`devtools: ${line}\n`);
-                    }
-                    if (code === 0) {
-                        return await dispatchCommand();
-                    }
-                    process.stderr.write("devtools: the stack did not start — see the Supabase CLI output " +
-                        "above.\n");
-                    process.exit(1);
-                }
-            }
-            // Declined, or nobody to ask. `db` (whose `start` is the fix, and whose
-            // data commands re-check the connection themselves) and an empty argv
-            // (the road to `db start` — the bare menu, when nothing has deferred
-            // this far, or the menu resumed on `db` itself) may continue in a
-            // degraded, unqualified entry; anything else stops here, with the
-            // error's own troubleshooting, instead of failing later against
-            // whatever `.env` happens to name.
-            if (commandArgv.length !== 0 && commandArgv[0] !== "db") {
-                process.exit(1);
-            }
-            process.stderr.write("devtools: continuing without the overlay so `db start` can fix this.\n");
-            const inherited = process.env.DEV_DB;
-            delete process.env.DEV_DB;
-            const entered = await envSession.enterEnvironment(tier, {
-                override: false,
-            });
-            if (devDatabase !== undefined) {
-                // Children spawned AFTER `db start` succeeds should still inherit
-                // the session's answer; the refresh that follows a successful start
-                // re-applies the overlay under this same variable.
-                process.env.DEV_DB = devDatabase;
-            }
-            else if (inherited !== undefined) {
-                process.env.DEV_DB = inherited;
-            }
-            for (const warning of entered.warnings) {
-                process.stderr.write(`devtools: ${warning}\n`);
-            }
-            reportEntered(entered.files, tier);
-            return await dispatchCommand();
-        }
-        if (!(err instanceof envLoad.MissingEnvFileError))
-            throw err;
-        if (tier === "development") {
-            // The clean-clone path: a fresh checkout has no `.env` at all, and
-            // `pnpm devtools setup` is how one gets created — `MissingEnvFileError`
-            // names it. Reporting and continuing here, rather than refusing, is
-            // what lets `setup` itself run through this same entry point. See
-            // `load.ts`'s `MissingEnvFileError` for the message this prints.
-            process.stderr.write(`devtools: ${err.message}\n`);
-        }
-        else {
-            // An EXPLICITLY selected staging/production tier with no env file is
-            // not a first run — it is a real problem, and `env pull` is the fix
-            // `MissingEnvFileError`'s own message already names. Fatal.
-            process.stderr.write(`devtools: ${err.message}\n`);
-            process.exit(1);
-        }
-    }
-    return await dispatchCommand();
-}
-let menuEnvHook;
-/** Set by `launch.ts` for a menu invocation; `undefined` for a typed command
- *  (which entered already) and for any test that drives `runMenu` directly
- *  without going through `launch.ts` at all. */
-export function setMenuEnvHook(hook) {
-    menuEnvHook = hook;
-}
-/** Read by `runMenu`, then cleared — see this module's header on why a
- *  nested launcher must not inherit a stale hook. */
-export function takeMenuEnvHook() {
-    const hook = menuEnvHook;
-    menuEnvHook = undefined;
-    return hook;
-}

package/dist/environment-doctor.d.ts

@@ -1,45 +0,0 @@
-import { validateSessionPoolerUrl } from "./db/pooler.js";
-export type CheckStatus = "ok" | "warn" | "skip";
-export interface DoctorCheck {
-    id: string;
-    status: CheckStatus;
-    summary: string;
-    /** How to fix it, when `status !== "ok"`. */
-    fix?: string;
-    faqId?: string;
-}
-/** The floor is 22.12: pnpm 11 needs `node:sqlite`, stable there. `.nvmrc`
- * pins 24, which is what a `fnm use` picks up; a machine below the floor is
- * a WARN, not an error — plenty of contributors' shells still resolve an
- * old global `node` first. */
-export declare function checkNodeVersion(nodeVersion: string): DoctorCheck;
-export declare function checkFnmHookPresent(shellProfile: string | null): DoctorCheck;
-export declare function checkPnpmVersion(pnpmVersion: string | null, pinned: string): DoctorCheck;
-/** `git config core.autocrlf` — `input` or `false` is correct on every
- * platform this repo documents (WSL2, native Windows, macOS, Linux); `true`
- * rewrites LF to CRLF on checkout and breaks anything that shells out to a
- * script with a shebang. */
-export declare function checkAutocrlf(value: string | null): DoctorCheck;
-/** WSL2's own filesystem, never `/mnt/c/...` — a Windows-drive checkout
- * makes every file operation cross the 9p boundary and Docker bind mounts
- * silently fail to see edits. */
-export declare function checkRepoUnderMntC(repoRoot: string): DoctorCheck;
-/** Windows only. `RemoteSigned` (or looser) is what lets fnm's PowerShell
- * hook and pnpm's shims actually run. */
-export declare function checkPowerShellExecutionPolicy(policy: string | null): DoctorCheck;
-/**
- * The checkout's development env the way every other command loads it:
- * `.env.generated` (the local stack's connection block, written by `db
- * start`) first and winning, then `.env`. Reading `.env` alone reported a
- * working local-Docker checkout as missing PUBLISHABLE_KEY, and took the
- * blank hosted template's `https://$PROJECT_REF.supabase.co` for a real
- * hosted project that "did not respond".
- */
-export declare function readCheckoutEnv(repoRoot: string): Record<string, string | undefined>;
-export declare function checkEnvKeysPresent(env: Record<string, string | undefined>, keys: string[]): DoctorCheck;
-export { validateSessionPoolerUrl };
-export interface RunDoctorOptions {
-    app?: string;
-    report?: boolean;
-}
-export declare function runEnvironmentDoctor(opts: RunDoctorOptions): Promise<void>;