@palbase/backend 22.1.0 → 23.1.0

package/dist/{purchases/keys.cjs → stack.cjs}

@@ -13,7 +13,7 @@ var __copyProps = (to, from, except, desc) => {
 };
 var __toCommonJS = (mod) => __copyProps(__defProp({}, "__esModule", { value: true }), mod);
 
-// src/purchases/keys.ts
-var keys_exports = {};
-module.exports = __toCommonJS(keys_exports);
-//# sourceMappingURL=keys.cjs.map
+// src/stack.ts
+var stack_exports = {};
+module.exports = __toCommonJS(stack_exports);
+//# sourceMappingURL=stack.cjs.map

package/dist/stack.cjs.map

@@ -0,0 +1 @@
+{"version":3,"sources":["../src/stack.ts"],"sourcesContent":["/**\n * `@palbase/backend/stack` — the controlled global augmentation target for the\n * names the project's STACK holds.\n *\n * `Secrets.get(...)`, the Flags client's key parameters and `@Upload({ bucket })`\n * take these unions, never a raw string, so a name the stack does not hold is a\n * COMPILE error rather than a 500 in production — or, worse, a silent read of a\n * secret nobody set.\n *\n * Three interfaces in ONE module because the three share a source and a refresh\n * moment: they all come from the linked environment's stack, and any `palbase\n * secret set` / `flags add` / `storage add` moves them together. `@palbase/\n * backend/env` and `@palbase/backend/purchases` stay separate for the opposite\n * reason — their sources are the schema and the catalog.\n *\n * All three are EMPTY by default; the generated `palbase-stack.d.ts` augments\n * them with one member per name:\n *\n *   // palbase-stack.d.ts (generated — do not edit)\n *   declare module \"@palbase/backend/stack\" {\n *     interface Secrets { OPENAI_API_KEY: true }\n *     interface Flags { newCheckout: true }\n *     interface Buckets { avatars: true }\n *   }\n *\n * A project that has not generated the file therefore has NO valid names, and\n * every call fails to compile until it does. That is the intended behaviour,\n * not a rough edge: it is the ONLY shape in which the gate is not optional. A\n * permissive `string` fallback would make the check opt-in, and an opt-in gate\n * is the same as no gate — which is precisely the hole the retired\n * `config/secrets.ts` push-check used to paper over.\n *\n * THIS REPLACED A DECLARATION, and the direction matters. `config/secrets.ts`\n * asked the author to restate, in the repo, names the vault already held; the\n * deploy then compared the two lists. Here the stack is simply read and the\n * result is a type. There is no second list to drift.\n */\n\n/** The secret names this project's vault holds. EMPTY by default; filled by the\n * generated `palbase-stack.d.ts`. */\n// biome-ignore lint/suspicious/noEmptyInterface: augmentation target — filled by generated palbase-stack.d.ts.\nexport interface Secrets {}\n\n/** The flag keys this project's store defines. EMPTY by default; filled by the\n * generated `palbase-stack.d.ts`. */\n// biome-ignore lint/suspicious/noEmptyInterface: augmentation target — filled by generated palbase-stack.d.ts.\nexport interface Flags {}\n\n/**\n * One typed bucket: which renditions the stack declared for it.\n *\n * `variants` is a UNION of the declared names, so asking for one the bucket does\n * not have is a compile error rather than a 404 somebody finds in production.\n * The default `never` means a bucket with no variants accepts no variant name at\n * all, which is exactly right.\n *\n * THIS MOVED HERE FROM `db/env.ts` (2026-08-29). It lived there because\n * `config/storage.ts` fed it through `palbase-env.d.ts`, alongside the schema's\n * tables. Buckets do not come from the schema — they come from the STACK — so\n * they belong in the file generated off the stack. Two `Buckets` interfaces for\n * one concept is how `Storage.buckets.docs` and `@Upload({ bucket: \"docs\" })`\n * came to disagree about whether \"docs\" exists.\n */\nexport interface BucketTypes {\n  variants: string;\n}\n\n/** The buckets this project's storage carries, keyed by name. EMPTY by default;\n * filled by the generated `palbase-stack.d.ts`. Drives BOTH `Storage.buckets.*`\n * (through `EnvBuckets`) and `@Upload({ bucket })`. */\n// biome-ignore lint/suspicious/noEmptyInterface: augmentation target — filled by generated palbase-stack.d.ts.\nexport interface Buckets {}\n\n/** Every secret name the stack holds. */\nexport type PalbaseSecretName = keyof Secrets & string;\n\n/** Every flag key the stack defines. */\nexport type PalbaseFlagKey = keyof Flags & string;\n\n/** Every bucket the stack carries. */\nexport type PalbaseBucketName = keyof Buckets & string;\n"],"mappings":";;;;;;;;;;;;;;;;AAAA;AAAA;","names":[]}

package/dist/stack.d.cts

@@ -0,0 +1,76 @@
+/**
+ * `@palbase/backend/stack` — the controlled global augmentation target for the
+ * names the project's STACK holds.
+ *
+ * `Secrets.get(...)`, the Flags client's key parameters and `@Upload({ bucket })`
+ * take these unions, never a raw string, so a name the stack does not hold is a
+ * COMPILE error rather than a 500 in production — or, worse, a silent read of a
+ * secret nobody set.
+ *
+ * Three interfaces in ONE module because the three share a source and a refresh
+ * moment: they all come from the linked environment's stack, and any `palbase
+ * secret set` / `flags add` / `storage add` moves them together. `@palbase/
+ * backend/env` and `@palbase/backend/purchases` stay separate for the opposite
+ * reason — their sources are the schema and the catalog.
+ *
+ * All three are EMPTY by default; the generated `palbase-stack.d.ts` augments
+ * them with one member per name:
+ *
+ *   // palbase-stack.d.ts (generated — do not edit)
+ *   declare module "@palbase/backend/stack" {
+ *     interface Secrets { OPENAI_API_KEY: true }
+ *     interface Flags { newCheckout: true }
+ *     interface Buckets { avatars: true }
+ *   }
+ *
+ * A project that has not generated the file therefore has NO valid names, and
+ * every call fails to compile until it does. That is the intended behaviour,
+ * not a rough edge: it is the ONLY shape in which the gate is not optional. A
+ * permissive `string` fallback would make the check opt-in, and an opt-in gate
+ * is the same as no gate — which is precisely the hole the retired
+ * `config/secrets.ts` push-check used to paper over.
+ *
+ * THIS REPLACED A DECLARATION, and the direction matters. `config/secrets.ts`
+ * asked the author to restate, in the repo, names the vault already held; the
+ * deploy then compared the two lists. Here the stack is simply read and the
+ * result is a type. There is no second list to drift.
+ */
+/** The secret names this project's vault holds. EMPTY by default; filled by the
+ * generated `palbase-stack.d.ts`. */
+interface Secrets {
+}
+/** The flag keys this project's store defines. EMPTY by default; filled by the
+ * generated `palbase-stack.d.ts`. */
+interface Flags {
+}
+/**
+ * One typed bucket: which renditions the stack declared for it.
+ *
+ * `variants` is a UNION of the declared names, so asking for one the bucket does
+ * not have is a compile error rather than a 404 somebody finds in production.
+ * The default `never` means a bucket with no variants accepts no variant name at
+ * all, which is exactly right.
+ *
+ * THIS MOVED HERE FROM `db/env.ts` (2026-08-29). It lived there because
+ * `config/storage.ts` fed it through `palbase-env.d.ts`, alongside the schema's
+ * tables. Buckets do not come from the schema — they come from the STACK — so
+ * they belong in the file generated off the stack. Two `Buckets` interfaces for
+ * one concept is how `Storage.buckets.docs` and `@Upload({ bucket: "docs" })`
+ * came to disagree about whether "docs" exists.
+ */
+interface BucketTypes {
+    variants: string;
+}
+/** The buckets this project's storage carries, keyed by name. EMPTY by default;
+ * filled by the generated `palbase-stack.d.ts`. Drives BOTH `Storage.buckets.*`
+ * (through `EnvBuckets`) and `@Upload({ bucket })`. */
+interface Buckets {
+}
+/** Every secret name the stack holds. */
+type PalbaseSecretName = keyof Secrets & string;
+/** Every flag key the stack defines. */
+type PalbaseFlagKey = keyof Flags & string;
+/** Every bucket the stack carries. */
+type PalbaseBucketName = keyof Buckets & string;
+
+export type { BucketTypes, Buckets, Flags, PalbaseBucketName, PalbaseFlagKey, PalbaseSecretName, Secrets };

package/dist/stack.d.ts

@@ -0,0 +1,76 @@
+/**
+ * `@palbase/backend/stack` — the controlled global augmentation target for the
+ * names the project's STACK holds.
+ *
+ * `Secrets.get(...)`, the Flags client's key parameters and `@Upload({ bucket })`
+ * take these unions, never a raw string, so a name the stack does not hold is a
+ * COMPILE error rather than a 500 in production — or, worse, a silent read of a
+ * secret nobody set.
+ *
+ * Three interfaces in ONE module because the three share a source and a refresh
+ * moment: they all come from the linked environment's stack, and any `palbase
+ * secret set` / `flags add` / `storage add` moves them together. `@palbase/
+ * backend/env` and `@palbase/backend/purchases` stay separate for the opposite
+ * reason — their sources are the schema and the catalog.
+ *
+ * All three are EMPTY by default; the generated `palbase-stack.d.ts` augments
+ * them with one member per name:
+ *
+ *   // palbase-stack.d.ts (generated — do not edit)
+ *   declare module "@palbase/backend/stack" {
+ *     interface Secrets { OPENAI_API_KEY: true }
+ *     interface Flags { newCheckout: true }
+ *     interface Buckets { avatars: true }
+ *   }
+ *
+ * A project that has not generated the file therefore has NO valid names, and
+ * every call fails to compile until it does. That is the intended behaviour,
+ * not a rough edge: it is the ONLY shape in which the gate is not optional. A
+ * permissive `string` fallback would make the check opt-in, and an opt-in gate
+ * is the same as no gate — which is precisely the hole the retired
+ * `config/secrets.ts` push-check used to paper over.
+ *
+ * THIS REPLACED A DECLARATION, and the direction matters. `config/secrets.ts`
+ * asked the author to restate, in the repo, names the vault already held; the
+ * deploy then compared the two lists. Here the stack is simply read and the
+ * result is a type. There is no second list to drift.
+ */
+/** The secret names this project's vault holds. EMPTY by default; filled by the
+ * generated `palbase-stack.d.ts`. */
+interface Secrets {
+}
+/** The flag keys this project's store defines. EMPTY by default; filled by the
+ * generated `palbase-stack.d.ts`. */
+interface Flags {
+}
+/**
+ * One typed bucket: which renditions the stack declared for it.
+ *
+ * `variants` is a UNION of the declared names, so asking for one the bucket does
+ * not have is a compile error rather than a 404 somebody finds in production.
+ * The default `never` means a bucket with no variants accepts no variant name at
+ * all, which is exactly right.
+ *
+ * THIS MOVED HERE FROM `db/env.ts` (2026-08-29). It lived there because
+ * `config/storage.ts` fed it through `palbase-env.d.ts`, alongside the schema's
+ * tables. Buckets do not come from the schema — they come from the STACK — so
+ * they belong in the file generated off the stack. Two `Buckets` interfaces for
+ * one concept is how `Storage.buckets.docs` and `@Upload({ bucket: "docs" })`
+ * came to disagree about whether "docs" exists.
+ */
+interface BucketTypes {
+    variants: string;
+}
+/** The buckets this project's storage carries, keyed by name. EMPTY by default;
+ * filled by the generated `palbase-stack.d.ts`. Drives BOTH `Storage.buckets.*`
+ * (through `EnvBuckets`) and `@Upload({ bucket })`. */
+interface Buckets {
+}
+/** Every secret name the stack holds. */
+type PalbaseSecretName = keyof Secrets & string;
+/** Every flag key the stack defines. */
+type PalbaseFlagKey = keyof Flags & string;
+/** Every bucket the stack carries. */
+type PalbaseBucketName = keyof Buckets & string;
+
+export type { BucketTypes, Buckets, Flags, PalbaseBucketName, PalbaseFlagKey, PalbaseSecretName, Secrets };

package/dist/stack.js

@@ -0,0 +1 @@
+//# sourceMappingURL=stack.js.map