@neondatabase/env 0.15.0 → 1.0.0

package/README.md

@@ -12,14 +12,13 @@ npm install @neon/env
 
 > **Requirements:** Node.js >= 20.19.
 
-## Two entry points
+## What's in it
 
-| Import | What it holds |
-| --- | --- |
-| `@neon/env` | The pure half: `fetchEnv` asks the Neon API for a branch's env, `parseEnv` reads what was already injected. Neither touches the filesystem or reads an env source. This is what an app, a build script, or a `neon.ts` policy needs. |
-| `@neon/env/runtime` | The stateful half: `fetchEnvReusingSecrets`, for tools that resolve the same branch repeatedly and must not re-mint a credential each time. It reads an env source and can mint and revoke credentials. Import it from a CLI or CI, never from an app bootstrap. |
+Everything is on `@neon/env`, and none of it has side effects: `fetchEnv` asks the Neon API for a branch's env, `parseEnv` validates what was already injected into `process.env`, `toEntries` projects a resolved env into `{ KEY: value }`. Nothing here writes a file, mutates `process.env`, or creates or destroys anything on your Neon project — so importing this package from an app, a build script, or a `neon.ts` policy can't surprise you.
+
+> **`@neon/env/runtime` was removed in 0.16.0.** It held `fetchEnvReusingSecrets`, which reads an env source and can mint and revoke branch credentials — implementation shared with the `neon` CLI, not something to hand an application. If you were importing it, the [`neon` CLI](../cli) (`neon env pull`, `neon dev`) does the same job; if you need to do it yourself, [The branch credential](#the-branch-credential) says what the hard part actually is.
 
-The split mirrors [`@neon/config`](../config) vs [`@neon/config-runtime`](../config-runtime), for the same reason: side effects should be something you opt into by import path. Contributing to either half? See [`CONTRIBUTING.md`](./CONTRIBUTING.md).
+Contributing? See [`CONTRIBUTING.md`](./CONTRIBUTING.md).
 
 ## Functions
 
@@ -55,7 +54,6 @@ Both return the same namespaced `NeonEnv` shape: `postgres` is always present; `
 | Function | Description |
 | --- | --- |
 | `fetchEnv(config, { projectId, branch, ... })` | Async. Calls the Neon API for the given project + branch and returns live connection strings (and Auth/Data API values when enabled). `projectId` and `branch` are required; `branch` accepts a branch **name** (e.g. `main`) or a `br-…` id. (The legacy id-only `branchId` option still works.) Pass `keys` to fetch only some vars — see [Fetching a subset](#fetching-a-subset). Reads nothing from `process.env` or disk. |
-| `fetchEnvReusingSecrets(config, { projectId, branch, env })` | Async, from **`@neon/env/runtime`**. `fetchEnv` plus reuse of one-time secrets you already hold: verifies them against the branch, keeps what's valid, mints and revokes only when it must. Returns `{ vars, credential }`. Takes an optional `revokeSuperseded`, which keeps the replaced credential live when your call resolves only part of the branch. Use this rather than `fetchEnv` anywhere the same branch is resolved repeatedly — see [The branch credential](#the-branch-credential). |
 | `parseEnv(config)` / `parseEnv(config, slug)` / `parseEnv(config, keys)` | Sync. Reads/validates the Neon env vars already present in `process.env` against the static policy toggles. With a function `slug`, also returns a typed `function` namespace of that function's declared env keys. With a `keys` array (e.g. `["DATABASE_URL"]`), only those vars are required and returned, as a narrowed namespaced shape — the keys are typesafe against the policy. Throws `PlatformError(EnvNotInjected)` listing missing vars when the env isn't populated. |
 | `toEntries(env)` | Project a resolved `NeonEnv` into `{ KEY: value }` pairs for cross-process transport (named after the web `.entries()` convention; returns a `Record`). |
 
@@ -135,30 +133,11 @@ These are the OS-level vars `fetchEnv` / `parseEnv` read and `toEntries` (so `ne
 
 Object storage and the AI Gateway are backed by one branch credential, and the Neon API returns its secrets (`s3_secret_access_key`, `api_token`) **once**, at mint time — they aren't stored server-side, and the list endpoint returns metadata only. So there is nothing to *fetch*: `fetchEnv` mints. Call it on every `neon dev` start and you leave a live credential behind each time.
 
-`fetchEnvReusingSecrets`, from the **`@neon/env/runtime`** entry point, is the wrapper that avoids that. It checks what you already hold, keeps what is still valid, and asks `fetchEnv` for only the rest:
-
-```ts
-import { fetchEnvReusingSecrets } from "@neon/env/runtime";
-
-const { vars, credential } = await fetchEnvReusingSecrets(config, {
-    projectId,
-    branch: "main",
-    env: { ...process.env, ...readEnvFile(".env") },
-});
-
-// vars: { DATABASE_URL: "…", AWS_ACCESS_KEY_ID: "…", … } — ready to write or inject
-if (credential.issued) {
-    console.log(`new values for ${credential.keys.join(", ")}`);
-    // credential.revoked    — ids it replaced and revoked
-    // credential.superseded — ids it replaced but left live (`revokeSuperseded: false`)
-}
-```
-
-The check is a real verification, not a presence test. A persisted secret is kept only when it names a credential that still exists on the branch, isn't revoked or expired, and carries every scope the policy needs. A `.env.example` placeholder, a credential revoked in the console, one copied from another branch, or one predating a newly-enabled feature all fail that check and get replaced — and the credential being replaced is revoked, so a branch doesn't accumulate one per call.
+Handling that is the caller's problem, and it is not just "cache the secret": a persisted secret is only reusable if it still names a live credential on that branch — unrevoked, unexpired, and carrying every scope the policy needs. A presence check cannot tell a real secret from a `.env.example` placeholder.
 
-No local bookkeeping backs this: `AWS_ACCESS_KEY_ID` **is** the credential's token id, and the AI Gateway token is minted as `nt_live_<tokenIdShort>_<secret>`, so the persisted secrets already name the credential that issued them.
+No local bookkeeping is needed to do it, because the secrets carry their own credential id: `AWS_ACCESS_KEY_ID` **is** the credential's token id, and the AI Gateway token is minted as `nt_live_<tokenIdShort>_<secret>`. So the `.env` you are about to rewrite already records which credential issued it.
 
-Revoking is only safe because the call resolves everything the policy enables. Pass `revokeSuperseded: false` when yours resolves a **subset** — the credential your persisted secrets name may also back a service you are not resolving, and revoking it would break that service while its vars, which you are not rewriting, stay in place. The cost is an orphaned credential, which is the safer of the two failures, and `credential.superseded` names it so you can report it rather than leave it invisible. `neon env pull --service` is the caller this exists for.
+The [`neon` CLI](../cli) does all of this — `neon env pull` and `neon dev` reuse a branch credential rather than issuing one per run. If you are calling `fetchEnv` on a loop yourself, `credentialScopesSatisfied` and `deriveCredentialScopes` from `@neon/config/v1`, plus `listCredentials` / `createCredential` / `revokeCredential` on a `NeonApi`, are the pieces you need.
 
 ### Fetching a subset
 

package/dist/_shared/auth_selection.d.ts

@@ -0,0 +1,95 @@
+//#region src/_shared/auth_selection.d.ts
+/**
+ * # Which credential an invocation authenticates with
+ *
+ * Four inputs can each answer "who am I": the `--api-key` flag, `NEON_API_KEY`, the
+ * `--profile` flag, and `NEON_PROFILE`. This module decides between them, and it is pure so
+ * the decision can be tested without a filesystem, a network, or a config directory.
+ *
+ * ## The rule
+ *
+ * **An explicit flag beats an ambient environment variable.** That single rule fixes the bug
+ * this module exists for: before it, any API key — including one merely exported into the
+ * shell — silently voided `--profile`, so `neon --profile work …` would quietly run as
+ * whoever `NEON_API_KEY` belonged to and say nothing about it.
+ *
+ * | Given | What runs |
+ * | --- | --- |
+ * | `--api-key` and `--profile` | neither: contradictory explicit flags, so this throws |
+ * | `--api-key` and `NEON_PROFILE` | the flag's key |
+ * | `--profile` and `NEON_API_KEY` | the profile |
+ * | `NEON_API_KEY` and `NEON_PROFILE` | the key, and the ignored profile is named in a warning |
+ * | `--profile` or `NEON_PROFILE` alone | that profile |
+ * | nothing | `DEFAULT` |
+ *
+ * Two explicit flags throw rather than picking a winner. They express different intents —
+ * `--api-key` supplies a credential, `--profile` selects a stored one — so there is no
+ * reading of the command that makes both true, and guessing is how the original bug behaved.
+ *
+ * When both are merely ambient, the key wins. That keeps CI exactly as it was: a pipeline
+ * that injects `NEON_API_KEY` must not change behaviour because a `NEON_PROFILE` leaked into
+ * the environment. It warns instead of staying silent, because a disregarded account
+ * selection is precisely what nobody noticed last time.
+ *
+ * `auth` and the `profile` subcommands do not use any of this. They read the same flags with
+ * different meanings — `neon auth --profile work` names where to *write* a credential, and
+ * `neon profile create work --api-key …` names one to *store* — so their callers skip
+ * selection entirely rather than passing exemptions down here.
+ */
+type CredentialSelection = /** `--api-key`. Used as given; no profile is consulted and no stored file is touched. */
+{
+  source: "explicit-api-key";
+  apiKey: string;
+}
+/** `NEON_API_KEY`, with the profile it displaced when there was one. */ | {
+  source: "ambient-api-key";
+  apiKey: string;
+  ignoredProfile?: string;
+}
+/** A profile, whose file decides whether that means an API key or OAuth. */ | {
+  source: "profile";
+  profile: string;
+  explicit: boolean;
+};
+type SelectionInput = {
+  /** The `--api-key` flag, before any environment fallback has been folded into it. */
+  apiKeyFlag?: string;
+  /** The `--profile` flag. */
+  profileFlag?: string;
+  /** `NEON_API_KEY`. */
+  apiKeyEnv?: string;
+  /** `NEON_PROFILE`. */
+  profileEnv?: string;
+};
+/**
+ * What the four credential inputs were for this invocation, captured by
+ * `resolveApiKeyFromEnv` — which is the one place that reads the environment.
+ *
+ * Two reasons this is module state rather than fields on the parsed arguments, the same two
+ * that put `auth_context` here: an extra key on `args` is rejected by every command calling
+ * `.strict()`, and a hidden option to carry it would be a second undocumented way to pass a
+ * credential. One process is one invocation, so there is nothing to get out of step.
+ *
+ * Capturing the environment here rather than reading it inside {@link selectCredential} keeps
+ * the selection a function of its arguments. That is not tidiness: `ensureAuth` is called
+ * directly by tests, and reading `process.env` down in the decision made those tests depend on
+ * whether the developer running them happened to have `NEON_API_KEY` exported.
+ */
+type CredentialInputs = {
+  apiKeyFlag: string;
+  apiKeyEnv: string;
+  profileEnv: string;
+};
+declare const recordCredentialInputs: (recorded: CredentialInputs) => void;
+declare const credentialInputs: () => CredentialInputs;
+declare const selectCredential: ({
+  apiKeyFlag,
+  profileFlag,
+  apiKeyEnv,
+  profileEnv
+}: SelectionInput) => CredentialSelection;
+/** The warning for an ambient key that displaced an ambient profile, or `null`. */
+declare const displacedProfileWarning: (selection: CredentialSelection) => string | null;
+//#endregion
+export { CredentialInputs, CredentialSelection, SelectionInput, credentialInputs, displacedProfileWarning, recordCredentialInputs, selectCredential };
+//# sourceMappingURL=auth_selection.d.ts.map

package/dist/_shared/auth_selection.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"auth_selection.d.ts","names":[],"sources":["../../src/_shared/auth_selection.ts"],"mappings":";;AAwCA;AAQA;AAyBA;AAcA;AAIA;AAEA;AAuCC;AAvCgC;AAAA;AAAA;AAAA;AAK9B;AAAiB;AAkCnB;AAGD;;;;;;;;;;;;;;;;;;;;;;KA/FY,mBAAA;;;;;;;;;;;;;;;KAQA,cAAA;;;;;;;;;;;;;;;;;;;;;;;;KAyBA,gBAAA;;;;;cAcC,mCAAoC;cAIpC,wBAAuB;cAEvB;;;;;GAKV,mBAAiB;;cAqCP,qCACD"}

package/dist/_shared/auth_selection.js

@@ -37,6 +37,15 @@ import "./profiles.js";
 * `neon profile create work --api-key …` names one to *store* — so their callers skip
 * selection entirely rather than passing exemptions down here.
 */
+let inputs = {
+	apiKeyFlag: "",
+	apiKeyEnv: "",
+	profileEnv: ""
+};
+const recordCredentialInputs = (recorded) => {
+	inputs = recorded;
+};
+const credentialInputs = () => inputs;
 const selectCredential = ({ apiKeyFlag, profileFlag, apiKeyEnv, profileEnv }) => {
 	const flagKey = nonEmpty(apiKeyFlag);
 	const flagProfile = nonEmpty(profileFlag);
@@ -71,6 +80,6 @@ function nonEmpty(value) {
 	return trimmed === "" ? void 0 : trimmed;
 }
 //#endregion
-export { displacedProfileWarning, selectCredential };
+export { credentialInputs, displacedProfileWarning, recordCredentialInputs, selectCredential };
 
 //# sourceMappingURL=auth_selection.js.map

package/dist/_shared/auth_selection.js.map

@@ -1 +1 @@
-{"version":3,"file":"auth_selection.js","names":[],"sources":["../../src/_shared/auth_selection.ts"],"sourcesContent":["/**\n * # Which credential an invocation authenticates with\n *\n * Four inputs can each answer \"who am I\": the `--api-key` flag, `NEON_API_KEY`, the\n * `--profile` flag, and `NEON_PROFILE`. This module decides between them, and it is pure so\n * the decision can be tested without a filesystem, a network, or a config directory.\n *\n * ## The rule\n *\n * **An explicit flag beats an ambient environment variable.** That single rule fixes the bug\n * this module exists for: before it, any API key — including one merely exported into the\n * shell — silently voided `--profile`, so `neon --profile work …` would quietly run as\n * whoever `NEON_API_KEY` belonged to and say nothing about it.\n *\n * | Given | What runs |\n * | --- | --- |\n * | `--api-key` and `--profile` | neither: contradictory explicit flags, so this throws |\n * | `--api-key` and `NEON_PROFILE` | the flag's key |\n * | `--profile` and `NEON_API_KEY` | the profile |\n * | `NEON_API_KEY` and `NEON_PROFILE` | the key, and the ignored profile is named in a warning |\n * | `--profile` or `NEON_PROFILE` alone | that profile |\n * | nothing | `DEFAULT` |\n *\n * Two explicit flags throw rather than picking a winner. They express different intents —\n * `--api-key` supplies a credential, `--profile` selects a stored one — so there is no\n * reading of the command that makes both true, and guessing is how the original bug behaved.\n *\n * When both are merely ambient, the key wins. That keeps CI exactly as it was: a pipeline\n * that injects `NEON_API_KEY` must not change behaviour because a `NEON_PROFILE` leaked into\n * the environment. It warns instead of staying silent, because a disregarded account\n * selection is precisely what nobody noticed last time.\n *\n * `auth` and the `profile` subcommands do not use any of this. They read the same flags with\n * different meanings — `neon auth --profile work` names where to *write* a credential, and\n * `neon profile create work --api-key …` names one to *store* — so their callers skip\n * selection entirely rather than passing exemptions down here.\n */\n\nimport { DEFAULT_PROFILE } from \"./profiles.js\";\n\nexport type CredentialSelection =\n\t/** `--api-key`. Used as given; no profile is consulted and no stored file is touched. */\n\t| { source: \"explicit-api-key\"; apiKey: string }\n\t/** `NEON_API_KEY`, with the profile it displaced when there was one. */\n\t| { source: \"ambient-api-key\"; apiKey: string; ignoredProfile?: string }\n\t/** A profile, whose file decides whether that means an API key or OAuth. */\n\t| { source: \"profile\"; profile: string; explicit: boolean };\n\nexport type SelectionInput = {\n\t/** The `--api-key` flag, before any environment fallback has been folded into it. */\n\tapiKeyFlag?: string;\n\t/** The `--profile` flag. */\n\tprofileFlag?: string;\n\t/** `NEON_API_KEY`. */\n\tapiKeyEnv?: string;\n\t/** `NEON_PROFILE`. */\n\tprofileEnv?: string;\n};\n\n/**\n * What the four credential inputs were for this invocation, captured by\n * `resolveApiKeyFromEnv` — which is the one place that reads the environment.\n *\n * Two reasons this is module state rather than fields on the parsed arguments, the same two\n * that put `auth_context` here: an extra key on `args` is rejected by every command calling\n * `.strict()`, and a hidden option to carry it would be a second undocumented way to pass a\n * credential. One process is one invocation, so there is nothing to get out of step.\n *\n * Capturing the environment here rather than reading it inside {@link selectCredential} keeps\n * the selection a function of its arguments. That is not tidiness: `ensureAuth` is called\n * directly by tests, and reading `process.env` down in the decision made those tests depend on\n * whether the developer running them happened to have `NEON_API_KEY` exported.\n */\nexport type CredentialInputs = {\n\tapiKeyFlag: string;\n\tapiKeyEnv: string;\n\tprofileEnv: string;\n};\n\nconst NO_INPUTS: CredentialInputs = {\n\tapiKeyFlag: \"\",\n\tapiKeyEnv: \"\",\n\tprofileEnv: \"\",\n};\n\nlet inputs: CredentialInputs = NO_INPUTS;\n\nexport const recordCredentialInputs = (recorded: CredentialInputs): void => {\n\tinputs = recorded;\n};\n\nexport const credentialInputs = (): CredentialInputs => inputs;\n\nexport const selectCredential = ({\n\tapiKeyFlag,\n\tprofileFlag,\n\tapiKeyEnv,\n\tprofileEnv,\n}: SelectionInput): CredentialSelection => {\n\tconst flagKey = nonEmpty(apiKeyFlag);\n\tconst flagProfile = nonEmpty(profileFlag);\n\n\tif (flagKey !== undefined && flagProfile !== undefined) {\n\t\tthrow new Error(\n\t\t\t\"Pass either --api-key or --profile, not both. --api-key supplies a credential directly; --profile selects a stored one.\",\n\t\t);\n\t}\n\n\tif (flagKey !== undefined) {\n\t\treturn { source: \"explicit-api-key\", apiKey: flagKey };\n\t}\n\n\tif (flagProfile !== undefined) {\n\t\treturn { source: \"profile\", profile: flagProfile, explicit: true };\n\t}\n\n\tconst envKey = nonEmpty(apiKeyEnv);\n\tconst envProfile = nonEmpty(profileEnv);\n\n\tif (envKey !== undefined) {\n\t\treturn {\n\t\t\tsource: \"ambient-api-key\",\n\t\t\tapiKey: envKey,\n\t\t\t...(envProfile !== undefined ? { ignoredProfile: envProfile } : {}),\n\t\t};\n\t}\n\n\treturn {\n\t\tsource: \"profile\",\n\t\tprofile: envProfile ?? DEFAULT_PROFILE,\n\t\texplicit: envProfile !== undefined,\n\t};\n};\n\n/** The warning for an ambient key that displaced an ambient profile, or `null`. */\nexport const displacedProfileWarning = (\n\tselection: CredentialSelection,\n): string | null =>\n\tselection.source === \"ambient-api-key\" &&\n\tselection.ignoredProfile !== undefined\n\t\t? `NEON_API_KEY is set, so profile \"${selection.ignoredProfile}\" from NEON_PROFILE was ignored. Pass --profile ${selection.ignoredProfile} to use it instead.`\n\t\t: null;\n\nfunction nonEmpty(value: string | undefined): string | undefined {\n\tif (typeof value !== \"string\") return undefined;\n\tconst trimmed = value.trim();\n\treturn trimmed === \"\" ? undefined : trimmed;\n}\n"],"mappings":";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;AA6FA,MAAa,oBAAoB,EAChC,YACA,aACA,WACA,iBAC0C;CAC1C,MAAM,UAAU,SAAS,UAAU;CACnC,MAAM,cAAc,SAAS,WAAW;CAExC,IAAI,YAAY,KAAA,KAAa,gBAAgB,KAAA,GAC5C,MAAM,IAAI,MACT,yHACD;CAGD,IAAI,YAAY,KAAA,GACf,OAAO;EAAE,QAAQ;EAAoB,QAAQ;CAAQ;CAGtD,IAAI,gBAAgB,KAAA,GACnB,OAAO;EAAE,QAAQ;EAAW,SAAS;EAAa,UAAU;CAAK;CAGlE,MAAM,SAAS,SAAS,SAAS;CACjC,MAAM,aAAa,SAAS,UAAU;CAEtC,IAAI,WAAW,KAAA,GACd,OAAO;EACN,QAAQ;EACR,QAAQ;EACR,GAAI,eAAe,KAAA,IAAY,EAAE,gBAAgB,WAAW,IAAI,CAAC;CAClE;CAGD,OAAO;EACN,QAAQ;EACR,SAAS,cAAA;EACT,UAAU,eAAe,KAAA;CAC1B;AACD;;AAGA,MAAa,2BACZ,cAEA,UAAU,WAAW,qBACrB,UAAU,mBAAmB,KAAA,IAC1B,oCAAoC,UAAU,eAAe,kDAAkD,UAAU,eAAe,uBACxI;AAEJ,SAAS,SAAS,OAA+C;CAChE,IAAI,OAAO,UAAU,UAAU,OAAO,KAAA;CACtC,MAAM,UAAU,MAAM,KAAK;CAC3B,OAAO,YAAY,KAAK,KAAA,IAAY;AACrC"}
+{"version":3,"file":"auth_selection.js","names":[],"sources":["../../src/_shared/auth_selection.ts"],"sourcesContent":["/**\n * # Which credential an invocation authenticates with\n *\n * Four inputs can each answer \"who am I\": the `--api-key` flag, `NEON_API_KEY`, the\n * `--profile` flag, and `NEON_PROFILE`. This module decides between them, and it is pure so\n * the decision can be tested without a filesystem, a network, or a config directory.\n *\n * ## The rule\n *\n * **An explicit flag beats an ambient environment variable.** That single rule fixes the bug\n * this module exists for: before it, any API key — including one merely exported into the\n * shell — silently voided `--profile`, so `neon --profile work …` would quietly run as\n * whoever `NEON_API_KEY` belonged to and say nothing about it.\n *\n * | Given | What runs |\n * | --- | --- |\n * | `--api-key` and `--profile` | neither: contradictory explicit flags, so this throws |\n * | `--api-key` and `NEON_PROFILE` | the flag's key |\n * | `--profile` and `NEON_API_KEY` | the profile |\n * | `NEON_API_KEY` and `NEON_PROFILE` | the key, and the ignored profile is named in a warning |\n * | `--profile` or `NEON_PROFILE` alone | that profile |\n * | nothing | `DEFAULT` |\n *\n * Two explicit flags throw rather than picking a winner. They express different intents —\n * `--api-key` supplies a credential, `--profile` selects a stored one — so there is no\n * reading of the command that makes both true, and guessing is how the original bug behaved.\n *\n * When both are merely ambient, the key wins. That keeps CI exactly as it was: a pipeline\n * that injects `NEON_API_KEY` must not change behaviour because a `NEON_PROFILE` leaked into\n * the environment. It warns instead of staying silent, because a disregarded account\n * selection is precisely what nobody noticed last time.\n *\n * `auth` and the `profile` subcommands do not use any of this. They read the same flags with\n * different meanings — `neon auth --profile work` names where to *write* a credential, and\n * `neon profile create work --api-key …` names one to *store* — so their callers skip\n * selection entirely rather than passing exemptions down here.\n */\n\nimport { DEFAULT_PROFILE } from \"./profiles.js\";\n\nexport type CredentialSelection =\n\t/** `--api-key`. Used as given; no profile is consulted and no stored file is touched. */\n\t| { source: \"explicit-api-key\"; apiKey: string }\n\t/** `NEON_API_KEY`, with the profile it displaced when there was one. */\n\t| { source: \"ambient-api-key\"; apiKey: string; ignoredProfile?: string }\n\t/** A profile, whose file decides whether that means an API key or OAuth. */\n\t| { source: \"profile\"; profile: string; explicit: boolean };\n\nexport type SelectionInput = {\n\t/** The `--api-key` flag, before any environment fallback has been folded into it. */\n\tapiKeyFlag?: string;\n\t/** The `--profile` flag. */\n\tprofileFlag?: string;\n\t/** `NEON_API_KEY`. */\n\tapiKeyEnv?: string;\n\t/** `NEON_PROFILE`. */\n\tprofileEnv?: string;\n};\n\n/**\n * What the four credential inputs were for this invocation, captured by\n * `resolveApiKeyFromEnv` — which is the one place that reads the environment.\n *\n * Two reasons this is module state rather than fields on the parsed arguments, the same two\n * that put `auth_context` here: an extra key on `args` is rejected by every command calling\n * `.strict()`, and a hidden option to carry it would be a second undocumented way to pass a\n * credential. One process is one invocation, so there is nothing to get out of step.\n *\n * Capturing the environment here rather than reading it inside {@link selectCredential} keeps\n * the selection a function of its arguments. That is not tidiness: `ensureAuth` is called\n * directly by tests, and reading `process.env` down in the decision made those tests depend on\n * whether the developer running them happened to have `NEON_API_KEY` exported.\n */\nexport type CredentialInputs = {\n\tapiKeyFlag: string;\n\tapiKeyEnv: string;\n\tprofileEnv: string;\n};\n\nconst NO_INPUTS: CredentialInputs = {\n\tapiKeyFlag: \"\",\n\tapiKeyEnv: \"\",\n\tprofileEnv: \"\",\n};\n\nlet inputs: CredentialInputs = NO_INPUTS;\n\nexport const recordCredentialInputs = (recorded: CredentialInputs): void => {\n\tinputs = recorded;\n};\n\nexport const credentialInputs = (): CredentialInputs => inputs;\n\nexport const selectCredential = ({\n\tapiKeyFlag,\n\tprofileFlag,\n\tapiKeyEnv,\n\tprofileEnv,\n}: SelectionInput): CredentialSelection => {\n\tconst flagKey = nonEmpty(apiKeyFlag);\n\tconst flagProfile = nonEmpty(profileFlag);\n\n\tif (flagKey !== undefined && flagProfile !== undefined) {\n\t\tthrow new Error(\n\t\t\t\"Pass either --api-key or --profile, not both. --api-key supplies a credential directly; --profile selects a stored one.\",\n\t\t);\n\t}\n\n\tif (flagKey !== undefined) {\n\t\treturn { source: \"explicit-api-key\", apiKey: flagKey };\n\t}\n\n\tif (flagProfile !== undefined) {\n\t\treturn { source: \"profile\", profile: flagProfile, explicit: true };\n\t}\n\n\tconst envKey = nonEmpty(apiKeyEnv);\n\tconst envProfile = nonEmpty(profileEnv);\n\n\tif (envKey !== undefined) {\n\t\treturn {\n\t\t\tsource: \"ambient-api-key\",\n\t\t\tapiKey: envKey,\n\t\t\t...(envProfile !== undefined ? { ignoredProfile: envProfile } : {}),\n\t\t};\n\t}\n\n\treturn {\n\t\tsource: \"profile\",\n\t\tprofile: envProfile ?? DEFAULT_PROFILE,\n\t\texplicit: envProfile !== undefined,\n\t};\n};\n\n/** The warning for an ambient key that displaced an ambient profile, or `null`. */\nexport const displacedProfileWarning = (\n\tselection: CredentialSelection,\n): string | null =>\n\tselection.source === \"ambient-api-key\" &&\n\tselection.ignoredProfile !== undefined\n\t\t? `NEON_API_KEY is set, so profile \"${selection.ignoredProfile}\" from NEON_PROFILE was ignored. Pass --profile ${selection.ignoredProfile} to use it instead.`\n\t\t: null;\n\nfunction nonEmpty(value: string | undefined): string | undefined {\n\tif (typeof value !== \"string\") return undefined;\n\tconst trimmed = value.trim();\n\treturn trimmed === \"\" ? undefined : trimmed;\n}\n"],"mappings":";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;AAqFA,IAAI,SAA2B;CAL9B,YAAY;CACZ,WAAW;CACX,YAAY;AAG0B;AAEvC,MAAa,0BAA0B,aAAqC;CAC3E,SAAS;AACV;AAEA,MAAa,yBAA2C;AAExD,MAAa,oBAAoB,EAChC,YACA,aACA,WACA,iBAC0C;CAC1C,MAAM,UAAU,SAAS,UAAU;CACnC,MAAM,cAAc,SAAS,WAAW;CAExC,IAAI,YAAY,KAAA,KAAa,gBAAgB,KAAA,GAC5C,MAAM,IAAI,MACT,yHACD;CAGD,IAAI,YAAY,KAAA,GACf,OAAO;EAAE,QAAQ;EAAoB,QAAQ;CAAQ;CAGtD,IAAI,gBAAgB,KAAA,GACnB,OAAO;EAAE,QAAQ;EAAW,SAAS;EAAa,UAAU;CAAK;CAGlE,MAAM,SAAS,SAAS,SAAS;CACjC,MAAM,aAAa,SAAS,UAAU;CAEtC,IAAI,WAAW,KAAA,GACd,OAAO;EACN,QAAQ;EACR,QAAQ;EACR,GAAI,eAAe,KAAA,IAAY,EAAE,gBAAgB,WAAW,IAAI,CAAC;CAClE;CAGD,OAAO;EACN,QAAQ;EACR,SAAS,cAAA;EACT,UAAU,eAAe,KAAA;CAC1B;AACD;;AAGA,MAAa,2BACZ,cAEA,UAAU,WAAW,qBACrB,UAAU,mBAAmB,KAAA,IAC1B,oCAAoC,UAAU,eAAe,kDAAkD,UAAU,eAAe,uBACxI;AAEJ,SAAS,SAAS,OAA+C;CAChE,IAAI,OAAO,UAAU,UAAU,OAAO,KAAA;CACtC,MAAM,UAAU,MAAM,KAAK;CAC3B,OAAO,YAAY,KAAK,KAAA,IAAY;AACrC"}

package/dist/_shared/credentials.d.ts

@@ -0,0 +1,186 @@
+//#region src/_shared/credentials.d.ts
+/**
+ * # Stored credentials — one file per account, two kinds
+ *
+ * A profile points at exactly one credentials file (see `./profiles.ts`), and that file says
+ * what kind of credential it holds. Adding API-key support this way rather than adding a
+ * second pointer to `profiles.json` keeps a profile what it already was — one name, one path
+ * — and means `profiles.json` needs no schema change at all.
+ *
+ * ```json
+ * // oauth: every file written before this existed. An absent `type` means this.
+ * { "access_token": "…", "refresh_token": "…", "expires_at": 1786…, "user_id": "…" }
+ *
+ * // api_key, stored by `neon profile create --api-key`
+ * { "type": "api_key", "api_key": "napi_…", "user_id": "…" }
+ *
+ * // api_key minted by `--mint --org-id`, which records the scope it was issued at
+ * { "type": "api_key", "api_key": "napi_…", "key_id": 123, "org_id": "org-…" }
+ * ```
+ *
+ * ## One profile, one kind
+ *
+ * A credentials file holds an API key or an OAuth session, never both, and `type` states
+ * which. An earlier draft let the two coexist — the idea being that a key could keep the
+ * session it was minted from and so rotate without a browser. It did not survive review, for
+ * two reasons that are worth recording so nobody rebuilds it:
+ *
+ * 1. **It never worked.** The resolver returned the key without testing it, so a revoked key
+ *    failed to mint and never fell back to the session sitting beside it.
+ * 2. **It could mix accounts.** Nothing compared the identity of the credential being written
+ *    with the one already there, so a profile could hold one account's session and another's
+ *    key, told apart only by a single string. Flip or lose `type` and the profile silently
+ *    becomes a different person.
+ *
+ * Recovery from a dead key is therefore one browser login — `neon profile create <name>
+ * --mint --force` — which is what the retained session was supposed to save and never did.
+ *
+ * ## Older releases
+ *
+ * A CLI predating this reads the pointer, finds no `type` it understands, ignores it, and
+ * looks for `access_token`. An `api_key` profile has none, so an older release falls through
+ * to its browser login rather than crashing. That it does not crash is why `credentials`
+ * stays a required pointer: an entry without one makes 2.41 and 2.42 throw
+ * `ERR_INVALID_ARG_TYPE` from `resolveEntryPath`.
+ */
+declare const OAUTH = "oauth";
+declare const API_KEY = "api_key";
+type CredentialKind = typeof OAUTH | typeof API_KEY;
+/**
+ * The on-disk shape. Every field is optional because the two kinds overlap and because an
+ * OAuth token endpoint response carries more than we name here — the index signature keeps
+ * those extra fields on a round-trip rather than dropping them.
+ */
+type StoredCredentials = {
+  type?: string;
+  api_key?: string;
+  key_id?: number;
+  /** Set when the key was minted for an organization rather than the account. */
+  org_id?: string;
+  /** Set when the key was narrowed to a single project. Implies `org_id`. */
+  project_id?: string;
+  user_id?: string;
+  access_token?: string;
+  refresh_token?: string;
+  expires_at?: number;
+  [key: string]: unknown;
+};
+/**
+ * Where a credential lives, and which profile points at it.
+ *
+ * Both halves are needed to report a broken file: the path says which file to open, and the
+ * profile is what every recovery command takes as its argument. Carrying only the path is what
+ * produced errors telling the user to run `neon profile create <name> --force` with the
+ * placeholder intact — a command an agent will run verbatim and be told `Invalid profile name
+ * "<name>"`.
+ */
+type CredentialLocation = {
+  path: string;
+  profile: string;
+};
+/**
+ * Which credential in this file authenticates, by declaration alone.
+ *
+ * An unrecognised `type` throws rather than falling back to `oauth`. A file we cannot
+ * interpret is a misconfiguration the user has to see: treating it as OAuth would send them
+ * to a browser login that silently replaces a credential they meant to keep, and treating it
+ * as an API key would authenticate with whatever `api_key` happened to be there.
+ *
+ * This deliberately does not check that an `api_key` file has a key — `neon profile list`
+ * needs the kind of a file it is not about to authenticate with, and must be able to report a
+ * broken one rather than throwing halfway through a table.
+ */
+declare const credentialKind: (credentials: StoredCredentials, at: CredentialLocation) => CredentialKind;
+/** A credentials file resolved far enough to authenticate with. */
+type InterpretedCredentials = {
+  kind: typeof API_KEY;
+  apiKey: string;
+} | {
+  kind: typeof OAUTH;
+};
+/**
+ * Resolve what to authenticate with, validating that the declared kind is actually usable.
+ *
+ * An `api_key` file with no key is a hard error rather than a fall-through to OAuth: the user
+ * asked for a key, and quietly opening a browser instead would replace the credential they
+ * were trying to fix.
+ */
+declare const interpretCredentials: (credentials: StoredCredentials, at: CredentialLocation) => InterpretedCredentials;
+/**
+ * Read a credentials file, or `null` when there is nothing usable there.
+ *
+ * Missing and unparseable both return `null`, because both are recoverable by authenticating
+ * again and the callers already treat "no credentials" as "log in". A file that parses but
+ * contradicts itself is different — {@link credentialKind} throws for that, since re-running
+ * `auth` would paper over a mistake rather than fix it.
+ */
+type CredentialsRead = {
+  kind: "ok";
+  credentials: StoredCredentials;
+} | {
+  kind: "absent";
+}
+/** The file is there but cannot be understood. `reason` is safe to print. */ | {
+  kind: "unusable";
+  reason: string;
+};
+/**
+ * Read and classify a credentials file, without deciding what to do about it.
+ *
+ * A permission or I/O error still throws: there may be a perfectly good credential here that
+ * we cannot see, and treating that as absent would send the user to a browser login that
+ * overwrites it.
+ */
+declare const inspectCredentials: (path: string) => CredentialsRead;
+/**
+ * The credential at `path`, or `null` when the file is not there.
+ *
+ * A damaged file is an error, not an absence. Treating it as absent — which is what this used to
+ * do — meant any read-only command could repair it by starting a browser sign-in and overwriting
+ * it, **possibly as a different account**, with the user never having asked for a repair and no
+ * way back to whatever was in the file. Failing here costs one deliberate command; the message
+ * names it.
+ *
+ * `profile list` and telemetry use {@link inspectCredentials} instead, because describing a
+ * broken credential is not the same as using one.
+ */
+declare const readCredentials: (at: CredentialLocation) => StoredCredentials | null;
+declare const writeCredentials: (path: string, credentials: StoredCredentials) => void;
+/** The scope a minted key was issued at. Absent org means an account key. */
+type KeyScope = {
+  orgId?: string;
+  projectId?: string;
+};
+/**
+ * Build an `api_key` credentials object. Nothing from a previous credential is carried over.
+ *
+ * The scope is stored because it is not recoverable from the secret: `rotate-key` has to mint
+ * the replacement on the same endpoint, and an org or project key minted as an account key
+ * would silently widen what the profile reaches.
+ */
+declare const apiKeyCredentials: ({
+  apiKey,
+  keyId,
+  userId,
+  scope
+}: {
+  apiKey: string;
+  keyId?: number;
+  userId?: string;
+  scope?: KeyScope;
+}) => StoredCredentials;
+/** The scope recorded on a stored credential. */
+declare const scopeOf: (credentials: StoredCredentials) => KeyScope;
+/** How to describe a scope in output. */
+declare const describeScope: (scope: KeyScope) => string;
+/**
+ * Whether a stored credential is the same secret as the one about to replace it.
+ *
+ * Re-storing the key a profile already holds is a no-op, not a replacement — and retiring it
+ * would revoke the credential the command has just committed to. Trimmed on both sides, because
+ * a key read from a file or a pipe arrives with a trailing newline.
+ */
+declare const isSameCredential: (existingKey: string | undefined, replacementKey: string | undefined) => boolean;
+//#endregion
+export { API_KEY, CredentialKind, CredentialLocation, CredentialsRead, InterpretedCredentials, KeyScope, OAUTH, StoredCredentials, apiKeyCredentials, credentialKind, describeScope, inspectCredentials, interpretCredentials, isSameCredential, readCredentials, scopeOf, writeCredentials };
+//# sourceMappingURL=credentials.d.ts.map

package/dist/_shared/credentials.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"credentials.d.ts","names":[],"sources":["../../src/_shared/credentials.ts"],"mappings":";;AAgDA;AACA;AAEA;AAA0B;AAAU;AAAe;AAAO;AAO1D;AAwBA;AAiBA;AAaC;AAZa;AACT;AACF;AAUF;AAYD;AAAkC;AAChB;AACA;AAAK;AASvB;AAYC;AAXa;AACT;AACF;AASF;AAUD;AAaA;AAiDA;AAQC;AAPI;AACF;AAAiB;AAQpB;AAQA;AAYA;AAiBE;AAjBgC;AAAA;AAAA;AAAA;AASzB;AACL;AAOF,cA1NW,KAAA,GA0NX,OAAA;AAGW,cA5NA,OAAA,GAmOX,SAAA;AAAA,KAjOU,cAAA,GAiOV,OAjOkC,KAiOlC,GAAA,OAjOiD,OAiOjD;AAPmC;AAAoB;AAOvD;AAGF;AAmBA;KAhPY,iBAAA;;;;;;;;;;;;;;;;;;;;;;;KAwBA,kBAAA;;;;;;;;;;;;;;;;cAiBC,8BACC,uBACT,uBACF;;KAsBS,sBAAA;eACM;;;eACA;;;;;;;;;cASL,oCACC,uBACT,uBACF;;;;;;;;;KAmBS,eAAA;;eACkB;;;;;;;;;;;;;;;cAYjB,sCAAqC;;;;;;;;;;;;;cAiDrC,sBACR,uBACF;cAQU,8CAEC;;KAMF,QAAA;;;;;;;;;;;cAYC;;;;;;;;;UASJ;MACL;;cAUS,uBAAwB,sBAAoB;;cAU5C,uBAAwB;;;;;;;;cAmBxB"}

package/dist/_shared/credentials.js

@@ -1,3 +1,4 @@
+import { writeSecretFile } from "./secure_file.js";
 import { readFileSync } from "node:fs";
 //#region src/_shared/credentials.ts
 /**
@@ -120,12 +121,70 @@ const inspectCredentials = (path) => {
 		credentials: parsed
 	};
 };
+/**
+* The credential at `path`, or `null` when the file is not there.
+*
+* A damaged file is an error, not an absence. Treating it as absent — which is what this used to
+* do — meant any read-only command could repair it by starting a browser sign-in and overwriting
+* it, **possibly as a different account**, with the user never having asked for a repair and no
+* way back to whatever was in the file. Failing here costs one deliberate command; the message
+* names it.
+*
+* `profile list` and telemetry use {@link inspectCredentials} instead, because describing a
+* broken credential is not the same as using one.
+*/
+const readCredentials = (at) => {
+	const read = inspectCredentials(at.path);
+	if (read.kind === "unusable") throw new Error(`${read.reason}. ${repair(at)}`);
+	return read.kind === "ok" ? read.credentials : null;
+};
+const writeCredentials = (path, credentials) => {
+	writeSecretFile(path, JSON.stringify(credentials));
+};
+/**
+* Build an `api_key` credentials object. Nothing from a previous credential is carried over.
+*
+* The scope is stored because it is not recoverable from the secret: `rotate-key` has to mint
+* the replacement on the same endpoint, and an org or project key minted as an account key
+* would silently widen what the profile reaches.
+*/
+const apiKeyCredentials = ({ apiKey, keyId, userId, scope }) => ({
+	type: API_KEY,
+	api_key: apiKey,
+	...keyId !== void 0 ? { key_id: keyId } : {},
+	...userId !== void 0 ? { user_id: userId } : {},
+	...scope?.orgId !== void 0 ? { org_id: scope.orgId } : {},
+	...scope?.projectId !== void 0 ? { project_id: scope.projectId } : {}
+});
+/** The scope recorded on a stored credential. */
+const scopeOf = (credentials) => ({
+	...typeof credentials.org_id === "string" ? { orgId: credentials.org_id } : {},
+	...typeof credentials.project_id === "string" ? { projectId: credentials.project_id } : {}
+});
+/** How to describe a scope in output. */
+const describeScope = (scope) => {
+	if (scope.projectId !== void 0) return `project ${scope.projectId}`;
+	if (scope.orgId !== void 0) return `org ${scope.orgId}`;
+	return "account";
+};
 function nonEmpty(value) {
 	if (typeof value !== "string") return void 0;
 	const trimmed = value.trim();
 	return trimmed === "" ? void 0 : trimmed;
 }
+/**
+* Whether a stored credential is the same secret as the one about to replace it.
+*
+* Re-storing the key a profile already holds is a no-op, not a replacement — and retiring it
+* would revoke the credential the command has just committed to. Trimmed on both sides, because
+* a key read from a file or a pipe arrives with a trailing newline.
+*/
+const isSameCredential = (existingKey, replacementKey) => {
+	if (existingKey === void 0 || replacementKey === void 0) return false;
+	const trimmed = existingKey.trim();
+	return trimmed !== "" && trimmed === replacementKey.trim();
+};
 //#endregion
-export { API_KEY, OAUTH, credentialKind, inspectCredentials, interpretCredentials };
+export { API_KEY, OAUTH, apiKeyCredentials, credentialKind, describeScope, inspectCredentials, interpretCredentials, isSameCredential, readCredentials, scopeOf, writeCredentials };
 
 //# sourceMappingURL=credentials.js.map

package/dist/_shared/credentials.js.map

@@ -1 +1 @@
-{"version":3,"file":"credentials.js","names":[],"sources":["../../src/_shared/credentials.ts"],"sourcesContent":["/**\n * # Stored credentials — one file per account, two kinds\n *\n * A profile points at exactly one credentials file (see `./profiles.ts`), and that file says\n * what kind of credential it holds. Adding API-key support this way rather than adding a\n * second pointer to `profiles.json` keeps a profile what it already was — one name, one path\n * — and means `profiles.json` needs no schema change at all.\n *\n * ```json\n * // oauth: every file written before this existed. An absent `type` means this.\n * { \"access_token\": \"…\", \"refresh_token\": \"…\", \"expires_at\": 1786…, \"user_id\": \"…\" }\n *\n * // api_key, stored by `neon profile create --api-key`\n * { \"type\": \"api_key\", \"api_key\": \"napi_…\", \"user_id\": \"…\" }\n *\n * // api_key minted by `--mint --org-id`, which records the scope it was issued at\n * { \"type\": \"api_key\", \"api_key\": \"napi_…\", \"key_id\": 123, \"org_id\": \"org-…\" }\n * ```\n *\n * ## One profile, one kind\n *\n * A credentials file holds an API key or an OAuth session, never both, and `type` states\n * which. An earlier draft let the two coexist — the idea being that a key could keep the\n * session it was minted from and so rotate without a browser. It did not survive review, for\n * two reasons that are worth recording so nobody rebuilds it:\n *\n * 1. **It never worked.** The resolver returned the key without testing it, so a revoked key\n *    failed to mint and never fell back to the session sitting beside it.\n * 2. **It could mix accounts.** Nothing compared the identity of the credential being written\n *    with the one already there, so a profile could hold one account's session and another's\n *    key, told apart only by a single string. Flip or lose `type` and the profile silently\n *    becomes a different person.\n *\n * Recovery from a dead key is therefore one browser login — `neon profile create <name>\n * --mint --force` — which is what the retained session was supposed to save and never did.\n *\n * ## Older releases\n *\n * A CLI predating this reads the pointer, finds no `type` it understands, ignores it, and\n * looks for `access_token`. An `api_key` profile has none, so an older release falls through\n * to its browser login rather than crashing. That it does not crash is why `credentials`\n * stays a required pointer: an entry without one makes 2.41 and 2.42 throw\n * `ERR_INVALID_ARG_TYPE` from `resolveEntryPath`.\n */\n\nimport { readFileSync } from \"node:fs\";\nimport { writeSecretFile } from \"./secure_file.js\";\n\nexport const OAUTH = \"oauth\";\nexport const API_KEY = \"api_key\";\n\nexport type CredentialKind = typeof OAUTH | typeof API_KEY;\n\n/**\n * The on-disk shape. Every field is optional because the two kinds overlap and because an\n * OAuth token endpoint response carries more than we name here — the index signature keeps\n * those extra fields on a round-trip rather than dropping them.\n */\nexport type StoredCredentials = {\n\ttype?: string;\n\tapi_key?: string;\n\tkey_id?: number;\n\t/** Set when the key was minted for an organization rather than the account. */\n\torg_id?: string;\n\t/** Set when the key was narrowed to a single project. Implies `org_id`. */\n\tproject_id?: string;\n\tuser_id?: string;\n\taccess_token?: string;\n\trefresh_token?: string;\n\texpires_at?: number;\n\t[key: string]: unknown;\n};\n\n/**\n * Where a credential lives, and which profile points at it.\n *\n * Both halves are needed to report a broken file: the path says which file to open, and the\n * profile is what every recovery command takes as its argument. Carrying only the path is what\n * produced errors telling the user to run `neon profile create <name> --force` with the\n * placeholder intact — a command an agent will run verbatim and be told `Invalid profile name\n * \"<name>\"`.\n */\nexport type CredentialLocation = {\n\tpath: string;\n\tprofile: string;\n};\n\n/**\n * Which credential in this file authenticates, by declaration alone.\n *\n * An unrecognised `type` throws rather than falling back to `oauth`. A file we cannot\n * interpret is a misconfiguration the user has to see: treating it as OAuth would send them\n * to a browser login that silently replaces a credential they meant to keep, and treating it\n * as an API key would authenticate with whatever `api_key` happened to be there.\n *\n * This deliberately does not check that an `api_key` file has a key — `neon profile list`\n * needs the kind of a file it is not about to authenticate with, and must be able to report a\n * broken one rather than throwing halfway through a table.\n */\nexport const credentialKind = (\n\tcredentials: StoredCredentials,\n\tat: CredentialLocation,\n): CredentialKind => {\n\tconst declared = credentials.type;\n\tif (declared === undefined || declared === OAUTH) return OAUTH;\n\tif (declared === API_KEY) return API_KEY;\n\t// The value is not quoted back. Everything in this file is secret material, and a\n\t// corrupted or hand-edited file can put a key anywhere in it — including here. Naming the\n\t// file is enough to act on, and it cannot leak what the file holds.\n\tthrow new Error(\n\t\t`${at.path} declares a \"type\" this version does not understand. Expected \"${OAUTH}\" or \"${API_KEY}\". ${repair(at)}`,\n\t);\n};\n\n/**\n * The way out of a credentials file that cannot be read.\n *\n * One sentence, shared by every such error, because they all have the same two answers: write\n * a new credential over it, or delete it and start again.\n */\nconst repair = (at: CredentialLocation): string =>\n\t`Replace it deliberately with \\`neon profile create ${at.profile} --force\\`, or delete the file.`;\n\n/** A credentials file resolved far enough to authenticate with. */\nexport type InterpretedCredentials =\n\t| { kind: typeof API_KEY; apiKey: string }\n\t| { kind: typeof OAUTH };\n\n/**\n * Resolve what to authenticate with, validating that the declared kind is actually usable.\n *\n * An `api_key` file with no key is a hard error rather than a fall-through to OAuth: the user\n * asked for a key, and quietly opening a browser instead would replace the credential they\n * were trying to fix.\n */\nexport const interpretCredentials = (\n\tcredentials: StoredCredentials,\n\tat: CredentialLocation,\n): InterpretedCredentials => {\n\tif (credentialKind(credentials, at) === OAUTH) return { kind: OAUTH };\n\tconst apiKey = nonEmpty(credentials.api_key);\n\tif (apiKey === undefined) {\n\t\tthrow new Error(\n\t\t\t`${at.path} declares \"type\": \"${API_KEY}\" but has no \"api_key\" value. ${repair(at)}`,\n\t\t);\n\t}\n\treturn { kind: API_KEY, apiKey };\n};\n\n/**\n * Read a credentials file, or `null` when there is nothing usable there.\n *\n * Missing and unparseable both return `null`, because both are recoverable by authenticating\n * again and the callers already treat \"no credentials\" as \"log in\". A file that parses but\n * contradicts itself is different — {@link credentialKind} throws for that, since re-running\n * `auth` would paper over a mistake rather than fix it.\n */\nexport type CredentialsRead =\n\t| { kind: \"ok\"; credentials: StoredCredentials }\n\t| { kind: \"absent\" }\n\t/** The file is there but cannot be understood. `reason` is safe to print. */\n\t| { kind: \"unusable\"; reason: string };\n\n/**\n * Read and classify a credentials file, without deciding what to do about it.\n *\n * A permission or I/O error still throws: there may be a perfectly good credential here that\n * we cannot see, and treating that as absent would send the user to a browser login that\n * overwrites it.\n */\nexport const inspectCredentials = (path: string): CredentialsRead => {\n\tlet contents: string;\n\ttry {\n\t\tcontents = readFileSync(path, \"utf8\");\n\t} catch (err) {\n\t\tif ((err as NodeJS.ErrnoException).code === \"ENOENT\")\n\t\t\treturn { kind: \"absent\" };\n\t\tthrow err;\n\t}\n\n\tlet parsed: unknown;\n\ttry {\n\t\tparsed = JSON.parse(contents);\n\t} catch {\n\t\t// The parser's message is deliberately discarded. V8 quotes a window of the input\n\t\t// around the syntax error — on Node 24 a truncated credentials file produced\n\t\t// `Unexpected token 'a', ...\"api_key\":napi_SUPERS\"... is not valid JSON` — and this\n\t\t// reason is printed by `profile list` and by every failed authentication. A malformed\n\t\t// secret file is exactly when a diagnostic must say less, not more.\n\t\treturn {\n\t\t\tkind: \"unusable\",\n\t\t\treason: `${path} is not valid JSON, so the credential in it cannot be read`,\n\t\t};\n\t}\n\tif (\n\t\tparsed === null ||\n\t\ttypeof parsed !== \"object\" ||\n\t\tArray.isArray(parsed)\n\t) {\n\t\treturn {\n\t\t\tkind: \"unusable\",\n\t\t\treason: `${path} does not contain a credentials object`,\n\t\t};\n\t}\n\treturn { kind: \"ok\", credentials: parsed as StoredCredentials };\n};\n\n/**\n * The credential at `path`, or `null` when the file is not there.\n *\n * A damaged file is an error, not an absence. Treating it as absent — which is what this used to\n * do — meant any read-only command could repair it by starting a browser sign-in and overwriting\n * it, **possibly as a different account**, with the user never having asked for a repair and no\n * way back to whatever was in the file. Failing here costs one deliberate command; the message\n * names it.\n *\n * `profile list` and telemetry use {@link inspectCredentials} instead, because describing a\n * broken credential is not the same as using one.\n */\nexport const readCredentials = (\n\tat: CredentialLocation,\n): StoredCredentials | null => {\n\tconst read = inspectCredentials(at.path);\n\tif (read.kind === \"unusable\") {\n\t\tthrow new Error(`${read.reason}. ${repair(at)}`);\n\t}\n\treturn read.kind === \"ok\" ? read.credentials : null;\n};\n\nexport const writeCredentials = (\n\tpath: string,\n\tcredentials: StoredCredentials,\n): void => {\n\twriteSecretFile(path, JSON.stringify(credentials));\n};\n\n/** The scope a minted key was issued at. Absent org means an account key. */\nexport type KeyScope = {\n\torgId?: string;\n\tprojectId?: string;\n};\n\n/**\n * Build an `api_key` credentials object. Nothing from a previous credential is carried over.\n *\n * The scope is stored because it is not recoverable from the secret: `rotate-key` has to mint\n * the replacement on the same endpoint, and an org or project key minted as an account key\n * would silently widen what the profile reaches.\n */\nexport const apiKeyCredentials = ({\n\tapiKey,\n\tkeyId,\n\tuserId,\n\tscope,\n}: {\n\tapiKey: string;\n\tkeyId?: number;\n\tuserId?: string;\n\tscope?: KeyScope;\n}): StoredCredentials => ({\n\ttype: API_KEY,\n\tapi_key: apiKey,\n\t...(keyId !== undefined ? { key_id: keyId } : {}),\n\t...(userId !== undefined ? { user_id: userId } : {}),\n\t...(scope?.orgId !== undefined ? { org_id: scope.orgId } : {}),\n\t...(scope?.projectId !== undefined ? { project_id: scope.projectId } : {}),\n});\n\n/** The scope recorded on a stored credential. */\nexport const scopeOf = (credentials: StoredCredentials): KeyScope => ({\n\t...(typeof credentials.org_id === \"string\"\n\t\t? { orgId: credentials.org_id }\n\t\t: {}),\n\t...(typeof credentials.project_id === \"string\"\n\t\t? { projectId: credentials.project_id }\n\t\t: {}),\n});\n\n/** How to describe a scope in output. */\nexport const describeScope = (scope: KeyScope): string => {\n\tif (scope.projectId !== undefined) return `project ${scope.projectId}`;\n\tif (scope.orgId !== undefined) return `org ${scope.orgId}`;\n\treturn \"account\";\n};\n\nfunction nonEmpty(value: unknown): string | undefined {\n\tif (typeof value !== \"string\") return undefined;\n\tconst trimmed = value.trim();\n\treturn trimmed === \"\" ? undefined : trimmed;\n}\n\n/**\n * Whether a stored credential is the same secret as the one about to replace it.\n *\n * Re-storing the key a profile already holds is a no-op, not a replacement — and retiring it\n * would revoke the credential the command has just committed to. Trimmed on both sides, because\n * a key read from a file or a pipe arrives with a trailing newline.\n */\nexport const isSameCredential = (\n\texistingKey: string | undefined,\n\treplacementKey: string | undefined,\n): boolean => {\n\tif (existingKey === undefined || replacementKey === undefined) return false;\n\tconst trimmed = existingKey.trim();\n\treturn trimmed !== \"\" && trimmed === replacementKey.trim();\n};\n"],"mappings":";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;AAgDA,MAAa,QAAQ;AACrB,MAAa,UAAU;;;;;;;;;;;;;AAkDvB,MAAa,kBACZ,aACA,OACoB;CACpB,MAAM,WAAW,YAAY;CAC7B,IAAI,aAAa,KAAA,KAAa,aAAA,SAAoB,OAAO;CACzD,IAAI,aAAA,WAAsB,OAAO;CAIjC,MAAM,IAAI,MACT,GAAG,GAAG,KAAK,iEAAiE,MAAM,QAAQ,QAAQ,KAAK,OAAO,EAAE,GACjH;AACD;;;;;;;AAQA,MAAM,UAAU,OACf,sDAAsD,GAAG,QAAQ;;;;;;;;AAclE,MAAa,wBACZ,aACA,OAC4B;CAC5B,IAAI,eAAe,aAAa,EAAE,MAAA,SAAa,OAAO,EAAE,MAAM,MAAM;CACpE,MAAM,SAAS,SAAS,YAAY,OAAO;CAC3C,IAAI,WAAW,KAAA,GACd,MAAM,IAAI,MACT,GAAG,GAAG,KAAK,qBAAqB,QAAQ,gCAAgC,OAAO,EAAE,GAClF;CAED,OAAO;EAAE,MAAM;EAAS;CAAO;AAChC;;;;;;;;AAuBA,MAAa,sBAAsB,SAAkC;CACpE,IAAI;CACJ,IAAI;EACH,WAAW,aAAa,MAAM,MAAM;CACrC,SAAS,KAAK;EACb,IAAK,IAA8B,SAAS,UAC3C,OAAO,EAAE,MAAM,SAAS;EACzB,MAAM;CACP;CAEA,IAAI;CACJ,IAAI;EACH,SAAS,KAAK,MAAM,QAAQ;CAC7B,QAAQ;EAMP,OAAO;GACN,MAAM;GACN,QAAQ,GAAG,KAAK;EACjB;CACD;CACA,IACC,WAAW,QACX,OAAO,WAAW,YAClB,MAAM,QAAQ,MAAM,GAEpB,OAAO;EACN,MAAM;EACN,QAAQ,GAAG,KAAK;CACjB;CAED,OAAO;EAAE,MAAM;EAAM,aAAa;CAA4B;AAC/D;AAgFA,SAAS,SAAS,OAAoC;CACrD,IAAI,OAAO,UAAU,UAAU,OAAO,KAAA;CACtC,MAAM,UAAU,MAAM,KAAK;CAC3B,OAAO,YAAY,KAAK,KAAA,IAAY;AACrC"}
+{"version":3,"file":"credentials.js","names":[],"sources":["../../src/_shared/credentials.ts"],"sourcesContent":["/**\n * # Stored credentials — one file per account, two kinds\n *\n * A profile points at exactly one credentials file (see `./profiles.ts`), and that file says\n * what kind of credential it holds. Adding API-key support this way rather than adding a\n * second pointer to `profiles.json` keeps a profile what it already was — one name, one path\n * — and means `profiles.json` needs no schema change at all.\n *\n * ```json\n * // oauth: every file written before this existed. An absent `type` means this.\n * { \"access_token\": \"…\", \"refresh_token\": \"…\", \"expires_at\": 1786…, \"user_id\": \"…\" }\n *\n * // api_key, stored by `neon profile create --api-key`\n * { \"type\": \"api_key\", \"api_key\": \"napi_…\", \"user_id\": \"…\" }\n *\n * // api_key minted by `--mint --org-id`, which records the scope it was issued at\n * { \"type\": \"api_key\", \"api_key\": \"napi_…\", \"key_id\": 123, \"org_id\": \"org-…\" }\n * ```\n *\n * ## One profile, one kind\n *\n * A credentials file holds an API key or an OAuth session, never both, and `type` states\n * which. An earlier draft let the two coexist — the idea being that a key could keep the\n * session it was minted from and so rotate without a browser. It did not survive review, for\n * two reasons that are worth recording so nobody rebuilds it:\n *\n * 1. **It never worked.** The resolver returned the key without testing it, so a revoked key\n *    failed to mint and never fell back to the session sitting beside it.\n * 2. **It could mix accounts.** Nothing compared the identity of the credential being written\n *    with the one already there, so a profile could hold one account's session and another's\n *    key, told apart only by a single string. Flip or lose `type` and the profile silently\n *    becomes a different person.\n *\n * Recovery from a dead key is therefore one browser login — `neon profile create <name>\n * --mint --force` — which is what the retained session was supposed to save and never did.\n *\n * ## Older releases\n *\n * A CLI predating this reads the pointer, finds no `type` it understands, ignores it, and\n * looks for `access_token`. An `api_key` profile has none, so an older release falls through\n * to its browser login rather than crashing. That it does not crash is why `credentials`\n * stays a required pointer: an entry without one makes 2.41 and 2.42 throw\n * `ERR_INVALID_ARG_TYPE` from `resolveEntryPath`.\n */\n\nimport { readFileSync } from \"node:fs\";\nimport { writeSecretFile } from \"./secure_file.js\";\n\nexport const OAUTH = \"oauth\";\nexport const API_KEY = \"api_key\";\n\nexport type CredentialKind = typeof OAUTH | typeof API_KEY;\n\n/**\n * The on-disk shape. Every field is optional because the two kinds overlap and because an\n * OAuth token endpoint response carries more than we name here — the index signature keeps\n * those extra fields on a round-trip rather than dropping them.\n */\nexport type StoredCredentials = {\n\ttype?: string;\n\tapi_key?: string;\n\tkey_id?: number;\n\t/** Set when the key was minted for an organization rather than the account. */\n\torg_id?: string;\n\t/** Set when the key was narrowed to a single project. Implies `org_id`. */\n\tproject_id?: string;\n\tuser_id?: string;\n\taccess_token?: string;\n\trefresh_token?: string;\n\texpires_at?: number;\n\t[key: string]: unknown;\n};\n\n/**\n * Where a credential lives, and which profile points at it.\n *\n * Both halves are needed to report a broken file: the path says which file to open, and the\n * profile is what every recovery command takes as its argument. Carrying only the path is what\n * produced errors telling the user to run `neon profile create <name> --force` with the\n * placeholder intact — a command an agent will run verbatim and be told `Invalid profile name\n * \"<name>\"`.\n */\nexport type CredentialLocation = {\n\tpath: string;\n\tprofile: string;\n};\n\n/**\n * Which credential in this file authenticates, by declaration alone.\n *\n * An unrecognised `type` throws rather than falling back to `oauth`. A file we cannot\n * interpret is a misconfiguration the user has to see: treating it as OAuth would send them\n * to a browser login that silently replaces a credential they meant to keep, and treating it\n * as an API key would authenticate with whatever `api_key` happened to be there.\n *\n * This deliberately does not check that an `api_key` file has a key — `neon profile list`\n * needs the kind of a file it is not about to authenticate with, and must be able to report a\n * broken one rather than throwing halfway through a table.\n */\nexport const credentialKind = (\n\tcredentials: StoredCredentials,\n\tat: CredentialLocation,\n): CredentialKind => {\n\tconst declared = credentials.type;\n\tif (declared === undefined || declared === OAUTH) return OAUTH;\n\tif (declared === API_KEY) return API_KEY;\n\t// The value is not quoted back. Everything in this file is secret material, and a\n\t// corrupted or hand-edited file can put a key anywhere in it — including here. Naming the\n\t// file is enough to act on, and it cannot leak what the file holds.\n\tthrow new Error(\n\t\t`${at.path} declares a \"type\" this version does not understand. Expected \"${OAUTH}\" or \"${API_KEY}\". ${repair(at)}`,\n\t);\n};\n\n/**\n * The way out of a credentials file that cannot be read.\n *\n * One sentence, shared by every such error, because they all have the same two answers: write\n * a new credential over it, or delete it and start again.\n */\nconst repair = (at: CredentialLocation): string =>\n\t`Replace it deliberately with \\`neon profile create ${at.profile} --force\\`, or delete the file.`;\n\n/** A credentials file resolved far enough to authenticate with. */\nexport type InterpretedCredentials =\n\t| { kind: typeof API_KEY; apiKey: string }\n\t| { kind: typeof OAUTH };\n\n/**\n * Resolve what to authenticate with, validating that the declared kind is actually usable.\n *\n * An `api_key` file with no key is a hard error rather than a fall-through to OAuth: the user\n * asked for a key, and quietly opening a browser instead would replace the credential they\n * were trying to fix.\n */\nexport const interpretCredentials = (\n\tcredentials: StoredCredentials,\n\tat: CredentialLocation,\n): InterpretedCredentials => {\n\tif (credentialKind(credentials, at) === OAUTH) return { kind: OAUTH };\n\tconst apiKey = nonEmpty(credentials.api_key);\n\tif (apiKey === undefined) {\n\t\tthrow new Error(\n\t\t\t`${at.path} declares \"type\": \"${API_KEY}\" but has no \"api_key\" value. ${repair(at)}`,\n\t\t);\n\t}\n\treturn { kind: API_KEY, apiKey };\n};\n\n/**\n * Read a credentials file, or `null` when there is nothing usable there.\n *\n * Missing and unparseable both return `null`, because both are recoverable by authenticating\n * again and the callers already treat \"no credentials\" as \"log in\". A file that parses but\n * contradicts itself is different — {@link credentialKind} throws for that, since re-running\n * `auth` would paper over a mistake rather than fix it.\n */\nexport type CredentialsRead =\n\t| { kind: \"ok\"; credentials: StoredCredentials }\n\t| { kind: \"absent\" }\n\t/** The file is there but cannot be understood. `reason` is safe to print. */\n\t| { kind: \"unusable\"; reason: string };\n\n/**\n * Read and classify a credentials file, without deciding what to do about it.\n *\n * A permission or I/O error still throws: there may be a perfectly good credential here that\n * we cannot see, and treating that as absent would send the user to a browser login that\n * overwrites it.\n */\nexport const inspectCredentials = (path: string): CredentialsRead => {\n\tlet contents: string;\n\ttry {\n\t\tcontents = readFileSync(path, \"utf8\");\n\t} catch (err) {\n\t\tif ((err as NodeJS.ErrnoException).code === \"ENOENT\")\n\t\t\treturn { kind: \"absent\" };\n\t\tthrow err;\n\t}\n\n\tlet parsed: unknown;\n\ttry {\n\t\tparsed = JSON.parse(contents);\n\t} catch {\n\t\t// The parser's message is deliberately discarded. V8 quotes a window of the input\n\t\t// around the syntax error — on Node 24 a truncated credentials file produced\n\t\t// `Unexpected token 'a', ...\"api_key\":napi_SUPERS\"... is not valid JSON` — and this\n\t\t// reason is printed by `profile list` and by every failed authentication. A malformed\n\t\t// secret file is exactly when a diagnostic must say less, not more.\n\t\treturn {\n\t\t\tkind: \"unusable\",\n\t\t\treason: `${path} is not valid JSON, so the credential in it cannot be read`,\n\t\t};\n\t}\n\tif (\n\t\tparsed === null ||\n\t\ttypeof parsed !== \"object\" ||\n\t\tArray.isArray(parsed)\n\t) {\n\t\treturn {\n\t\t\tkind: \"unusable\",\n\t\t\treason: `${path} does not contain a credentials object`,\n\t\t};\n\t}\n\treturn { kind: \"ok\", credentials: parsed as StoredCredentials };\n};\n\n/**\n * The credential at `path`, or `null` when the file is not there.\n *\n * A damaged file is an error, not an absence. Treating it as absent — which is what this used to\n * do — meant any read-only command could repair it by starting a browser sign-in and overwriting\n * it, **possibly as a different account**, with the user never having asked for a repair and no\n * way back to whatever was in the file. Failing here costs one deliberate command; the message\n * names it.\n *\n * `profile list` and telemetry use {@link inspectCredentials} instead, because describing a\n * broken credential is not the same as using one.\n */\nexport const readCredentials = (\n\tat: CredentialLocation,\n): StoredCredentials | null => {\n\tconst read = inspectCredentials(at.path);\n\tif (read.kind === \"unusable\") {\n\t\tthrow new Error(`${read.reason}. ${repair(at)}`);\n\t}\n\treturn read.kind === \"ok\" ? read.credentials : null;\n};\n\nexport const writeCredentials = (\n\tpath: string,\n\tcredentials: StoredCredentials,\n): void => {\n\twriteSecretFile(path, JSON.stringify(credentials));\n};\n\n/** The scope a minted key was issued at. Absent org means an account key. */\nexport type KeyScope = {\n\torgId?: string;\n\tprojectId?: string;\n};\n\n/**\n * Build an `api_key` credentials object. Nothing from a previous credential is carried over.\n *\n * The scope is stored because it is not recoverable from the secret: `rotate-key` has to mint\n * the replacement on the same endpoint, and an org or project key minted as an account key\n * would silently widen what the profile reaches.\n */\nexport const apiKeyCredentials = ({\n\tapiKey,\n\tkeyId,\n\tuserId,\n\tscope,\n}: {\n\tapiKey: string;\n\tkeyId?: number;\n\tuserId?: string;\n\tscope?: KeyScope;\n}): StoredCredentials => ({\n\ttype: API_KEY,\n\tapi_key: apiKey,\n\t...(keyId !== undefined ? { key_id: keyId } : {}),\n\t...(userId !== undefined ? { user_id: userId } : {}),\n\t...(scope?.orgId !== undefined ? { org_id: scope.orgId } : {}),\n\t...(scope?.projectId !== undefined ? { project_id: scope.projectId } : {}),\n});\n\n/** The scope recorded on a stored credential. */\nexport const scopeOf = (credentials: StoredCredentials): KeyScope => ({\n\t...(typeof credentials.org_id === \"string\"\n\t\t? { orgId: credentials.org_id }\n\t\t: {}),\n\t...(typeof credentials.project_id === \"string\"\n\t\t? { projectId: credentials.project_id }\n\t\t: {}),\n});\n\n/** How to describe a scope in output. */\nexport const describeScope = (scope: KeyScope): string => {\n\tif (scope.projectId !== undefined) return `project ${scope.projectId}`;\n\tif (scope.orgId !== undefined) return `org ${scope.orgId}`;\n\treturn \"account\";\n};\n\nfunction nonEmpty(value: unknown): string | undefined {\n\tif (typeof value !== \"string\") return undefined;\n\tconst trimmed = value.trim();\n\treturn trimmed === \"\" ? undefined : trimmed;\n}\n\n/**\n * Whether a stored credential is the same secret as the one about to replace it.\n *\n * Re-storing the key a profile already holds is a no-op, not a replacement — and retiring it\n * would revoke the credential the command has just committed to. Trimmed on both sides, because\n * a key read from a file or a pipe arrives with a trailing newline.\n */\nexport const isSameCredential = (\n\texistingKey: string | undefined,\n\treplacementKey: string | undefined,\n): boolean => {\n\tif (existingKey === undefined || replacementKey === undefined) return false;\n\tconst trimmed = existingKey.trim();\n\treturn trimmed !== \"\" && trimmed === replacementKey.trim();\n};\n"],"mappings":";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;AAgDA,MAAa,QAAQ;AACrB,MAAa,UAAU;;;;;;;;;;;;;AAkDvB,MAAa,kBACZ,aACA,OACoB;CACpB,MAAM,WAAW,YAAY;CAC7B,IAAI,aAAa,KAAA,KAAa,aAAA,SAAoB,OAAO;CACzD,IAAI,aAAA,WAAsB,OAAO;CAIjC,MAAM,IAAI,MACT,GAAG,GAAG,KAAK,iEAAiE,MAAM,QAAQ,QAAQ,KAAK,OAAO,EAAE,GACjH;AACD;;;;;;;AAQA,MAAM,UAAU,OACf,sDAAsD,GAAG,QAAQ;;;;;;;;AAclE,MAAa,wBACZ,aACA,OAC4B;CAC5B,IAAI,eAAe,aAAa,EAAE,MAAA,SAAa,OAAO,EAAE,MAAM,MAAM;CACpE,MAAM,SAAS,SAAS,YAAY,OAAO;CAC3C,IAAI,WAAW,KAAA,GACd,MAAM,IAAI,MACT,GAAG,GAAG,KAAK,qBAAqB,QAAQ,gCAAgC,OAAO,EAAE,GAClF;CAED,OAAO;EAAE,MAAM;EAAS;CAAO;AAChC;;;;;;;;AAuBA,MAAa,sBAAsB,SAAkC;CACpE,IAAI;CACJ,IAAI;EACH,WAAW,aAAa,MAAM,MAAM;CACrC,SAAS,KAAK;EACb,IAAK,IAA8B,SAAS,UAC3C,OAAO,EAAE,MAAM,SAAS;EACzB,MAAM;CACP;CAEA,IAAI;CACJ,IAAI;EACH,SAAS,KAAK,MAAM,QAAQ;CAC7B,QAAQ;EAMP,OAAO;GACN,MAAM;GACN,QAAQ,GAAG,KAAK;EACjB;CACD;CACA,IACC,WAAW,QACX,OAAO,WAAW,YAClB,MAAM,QAAQ,MAAM,GAEpB,OAAO;EACN,MAAM;EACN,QAAQ,GAAG,KAAK;CACjB;CAED,OAAO;EAAE,MAAM;EAAM,aAAa;CAA4B;AAC/D;;;;;;;;;;;;;AAcA,MAAa,mBACZ,OAC8B;CAC9B,MAAM,OAAO,mBAAmB,GAAG,IAAI;CACvC,IAAI,KAAK,SAAS,YACjB,MAAM,IAAI,MAAM,GAAG,KAAK,OAAO,IAAI,OAAO,EAAE,GAAG;CAEhD,OAAO,KAAK,SAAS,OAAO,KAAK,cAAc;AAChD;AAEA,MAAa,oBACZ,MACA,gBACU;CACV,gBAAgB,MAAM,KAAK,UAAU,WAAW,CAAC;AAClD;;;;;;;;AAeA,MAAa,qBAAqB,EACjC,QACA,OACA,QACA,aAMyB;CACzB,MAAM;CACN,SAAS;CACT,GAAI,UAAU,KAAA,IAAY,EAAE,QAAQ,MAAM,IAAI,CAAC;CAC/C,GAAI,WAAW,KAAA,IAAY,EAAE,SAAS,OAAO,IAAI,CAAC;CAClD,GAAI,OAAO,UAAU,KAAA,IAAY,EAAE,QAAQ,MAAM,MAAM,IAAI,CAAC;CAC5D,GAAI,OAAO,cAAc,KAAA,IAAY,EAAE,YAAY,MAAM,UAAU,IAAI,CAAC;AACzE;;AAGA,MAAa,WAAW,iBAA8C;CACrE,GAAI,OAAO,YAAY,WAAW,WAC/B,EAAE,OAAO,YAAY,OAAO,IAC5B,CAAC;CACJ,GAAI,OAAO,YAAY,eAAe,WACnC,EAAE,WAAW,YAAY,WAAW,IACpC,CAAC;AACL;;AAGA,MAAa,iBAAiB,UAA4B;CACzD,IAAI,MAAM,cAAc,KAAA,GAAW,OAAO,WAAW,MAAM;CAC3D,IAAI,MAAM,UAAU,KAAA,GAAW,OAAO,OAAO,MAAM;CACnD,OAAO;AACR;AAEA,SAAS,SAAS,OAAoC;CACrD,IAAI,OAAO,UAAU,UAAU,OAAO,KAAA;CACtC,MAAM,UAAU,MAAM,KAAK;CAC3B,OAAO,YAAY,KAAK,KAAA,IAAY;AACrC;;;;;;;;AASA,MAAa,oBACZ,aACA,mBACa;CACb,IAAI,gBAAgB,KAAA,KAAa,mBAAmB,KAAA,GAAW,OAAO;CACtE,MAAM,UAAU,YAAY,KAAK;CACjC,OAAO,YAAY,MAAM,YAAY,eAAe,KAAK;AAC1D"}