canopycms 0.0.67-int.89 → 0.0.67-int.90

package/dist/ai/resolve-branch.d.ts

@@ -6,8 +6,8 @@ import type { CanopyConfig } from '../config/index.js';
 /**
  * Resolve the branch root directory for reading content.
  *
- * - Static deployment: current working directory (content is in the checkout)
- * - Server (prod/dev): load or create the default active branch workspace
+ * - Static deployment, or any build: current working directory (content is in the checkout)
+ * - Server (prod/dev) at run time: load or create the default active branch workspace
  *
  * Branch resolution priority (mirrors createActiveBranchDetector in services.ts):
  * 1. Explicit `defaultActiveBranch` in config

package/dist/ai/resolve-branch.js

@@ -3,13 +3,13 @@
  * Used by both the route handler and build utility.
  */
 import { loadOrCreateBranchContext } from '../branch-workspace.js';
-import { isDeployedStatic } from '../build-mode.js';
+import { readsFromCheckout } from '../build-mode.js';
 import { detectHeadBranch } from '../utils/git.js';
 /**
  * Resolve the branch root directory for reading content.
  *
- * - Static deployment: current working directory (content is in the checkout)
- * - Server (prod/dev): load or create the default active branch workspace
+ * - Static deployment, or any build: current working directory (content is in the checkout)
+ * - Server (prod/dev) at run time: load or create the default active branch workspace
  *
  * Branch resolution priority (mirrors createActiveBranchDetector in services.ts):
  * 1. Explicit `defaultActiveBranch` in config
@@ -17,8 +17,8 @@ import { detectHeadBranch } from '../utils/git.js';
  * 3. Fall back to `defaultBaseBranch` or 'main'
  */
 export async function resolveBranchRoot(config) {
-    // Static deployments read content directly from the checkout — no branch workspace needed
-    if (isDeployedStatic(config)) {
+    // Static deployments and builds read content directly from the checkout — no branch workspace needed
+    if (readsFromCheckout(config)) {
         return process.cwd();
     }
     let activeBranch;

package/dist/api/assets.js

@@ -232,7 +232,7 @@ const deleteAssetHandler = async (ctx, req, params) => {
 /** Cache-Control applied to every transform output this route writes/serves - matches finalize.ts's PUBLIC_CACHE_CONTROL for static public objects. */
 const TRANSFORM_CACHE_CONTROL = 'public, max-age=31536000, immutable';
 /**
- * Lazy dev-mode emulation of the prod transform Lambda (PR 7 reuses
+ * Lazy dev-mode emulation of the prod transform Lambda (which reuses
  * `parseTransformPath`/`formatDirectives`/`applyTransform` unchanged): parse
  * the request, load the original, transform it, write the result back under
  * its CANONICAL key (so a non-canonically-ordered directive string still

package/dist/api/branch.js

@@ -106,8 +106,9 @@ export const createBranchHandler = async (ctx, req, body) => {
         // reserved canopycms-settings- prefix, and the remote-mirror check
         // further down) apply ONLY to this user-facing creation path.
         // http/handler.ts's auto-create (base/active/settings branches) and
-        // branch-workspace.ts's loadOrCreateBranchContext (reached from content
-        // reads and the AI pipeline) provision system/known branch names, not
+        // branch-workspace.ts's loadOrCreateBranchContext (reached from run-time
+        // content reads and the AI pipeline; build-time reads return the checkout
+        // and never provision) provision system/known branch names, not
         // user-chosen ones, and deliberately stay uncovered -- intentional, not
         // an oversight.
         // Prevent git branch name collision with the settings branch. Settings

package/dist/assets/pipeline.d.ts

@@ -6,9 +6,10 @@
  *
  * Server-only - never import this module from client/editor code. It pulls
  * in `file-type`, `image-size`, and the SVG sanitizer, none of which belong
- * in a browser bundle. `sharp` is loaded dynamically (see
- * `rasterIsDecodable` below) rather than statically imported, but is just as
- * server-only - it is never reachable from a browser bundle either way.
+ * in a browser bundle. `sharp` is loaded on first use through `loadSharp()`
+ * (sharp-loader.ts; see `rasterIsDecodable` below) rather than statically
+ * imported, but is just as server-only - it is never reachable from a browser
+ * bundle either way.
  */
 import type { AssetMeta } from './types.js';
 /** Client-declared content types accepted at presign time (UX only - never trusted at finalize). */

package/dist/assets/pipeline.js

@@ -6,15 +6,17 @@
  *
  * Server-only - never import this module from client/editor code. It pulls
  * in `file-type`, `image-size`, and the SVG sanitizer, none of which belong
- * in a browser bundle. `sharp` is loaded dynamically (see
- * `rasterIsDecodable` below) rather than statically imported, but is just as
- * server-only - it is never reachable from a browser bundle either way.
+ * in a browser bundle. `sharp` is loaded on first use through `loadSharp()`
+ * (sharp-loader.ts; see `rasterIsDecodable` below) rather than statically
+ * imported, but is just as server-only - it is never reachable from a browser
+ * bundle either way.
  */
 import { fileTypeFromBuffer } from 'file-type';
 import { imageSize } from 'image-size';
 import { create as createContentDisposition } from 'content-disposition';
 import { getErrorMessage } from '../utils/error.js';
 import { hashBytes, publicKey, slugifyFilename } from './keys.js';
+import { loadSharp } from './sharp-loader.js';
 import { sanitizeSvg } from './svg-sanitizer.js';
 import { MAX_ANIMATED_FRAMES, MAX_INPUT_PIXELS } from './transform-directives.js';
 const RASTER_MIME_TYPES = new Set(['image/png', 'image/jpeg', 'image/webp', 'image/gif']);
@@ -175,26 +177,20 @@ const UNDECODABLE_RASTER_ERROR = 'This image could not be decoded - it may be co
  *   same bytes from its own probe with the same 422.
  */
 async function rasterIsDecodable(data) {
-    // Typed as the whole module (not just its callable default export) and
-    // dereferenced via `.default` below - sharp's own types ship an
-    // `export const sharp: SharpConstructor; export default sharp;` pair for
-    // the ESM entry point resolved by `import()`, so `typeof import('sharp')`
-    // is the two-property namespace object, not the callable itself.
-    let sharpModule;
+    // `loadSharp()` has already logged the load failure once for the process;
+    // this warning is per upload, and names what the failure costs here.
+    let sharp;
     try {
-        sharpModule = await import('sharp');
+        sharp = await loadSharp();
     }
     catch (err) {
         console.warn(`[canopycms] sharp could not be loaded - skipping raster decode validation at finalize: ${getErrorMessage(err)}`);
         return true;
     }
     try {
-        const probeMeta = await sharpModule
-            .default(data, { limitInputPixels: MAX_INPUT_PIXELS })
-            .metadata();
+        const probeMeta = await sharp(data, { limitInputPixels: MAX_INPUT_PIXELS }).metadata();
         const pagesToRead = Math.min(probeMeta.pages ?? 1, MAX_ANIMATED_FRAMES);
-        await sharpModule
-            .default(data, { pages: pagesToRead, limitInputPixels: MAX_INPUT_PIXELS })
+        await sharp(data, { pages: pagesToRead, limitInputPixels: MAX_INPUT_PIXELS })
             .resize({ width: DECODE_CHECK_SIZE, height: DECODE_CHECK_SIZE, fit: 'fill' })
             .toBuffer();
         return true;

package/dist/assets/sharp-loader.d.ts

@@ -0,0 +1,28 @@
+/**
+ * The one place this package loads `sharp` at runtime. Everything else
+ * reaches it through `loadSharp()` and imports only its types:
+ * `@typescript-eslint/no-restricted-imports` in eslint.config.mjs rejects a
+ * static value import of `sharp` anywhere under `src/` outside tests.
+ *
+ * Why lazily. sharp is a native addon, and loading it dlopens libvips. A
+ * static `import sharp from 'sharp'` makes importing the MODULE GRAPH load
+ * libvips. With sharp external, as in an adopter's Next 16 standalone build,
+ * Turbopack wraps it in an async module that awaits the load when the graph is
+ * evaluated (cms-image-build-epic.md in `.claude/future-tasks/`, "Every route
+ * loads sharp"). transform.ts is reachable from `canopycms/server` and, through
+ * api/assets.ts, from `canopycms/http` and so from `canopycms-next`, which a
+ * host app's root layout can import (that adopter's did). When the libvips
+ * `.so` was missing from its standalone output, that one static import turned
+ * it into a 500 on every on-demand route, 404s included, and defeated
+ * pipeline.ts's deliberate fail-open. Loaded on first use, a missing binary
+ * affects only the image operations that need it.
+ *
+ * Memoized INCLUDING a rejection: a failed dlopen does not heal inside a
+ * running process, so a retry would only pay for the failure again and log
+ * it again. The failure is logged once, here, and every later caller gets the
+ * same rejected promise to handle as its operation requires: transform.ts
+ * lets it propagate as a server error, pipeline.ts fails open.
+ */
+import type { SharpConstructor } from 'sharp';
+/** Resolve sharp's callable constructor, loading the native module on the first call only. */
+export declare function loadSharp(): Promise<SharpConstructor>;

package/dist/assets/sharp-loader.js

@@ -0,0 +1,44 @@
+/**
+ * The one place this package loads `sharp` at runtime. Everything else
+ * reaches it through `loadSharp()` and imports only its types:
+ * `@typescript-eslint/no-restricted-imports` in eslint.config.mjs rejects a
+ * static value import of `sharp` anywhere under `src/` outside tests.
+ *
+ * Why lazily. sharp is a native addon, and loading it dlopens libvips. A
+ * static `import sharp from 'sharp'` makes importing the MODULE GRAPH load
+ * libvips. With sharp external, as in an adopter's Next 16 standalone build,
+ * Turbopack wraps it in an async module that awaits the load when the graph is
+ * evaluated (cms-image-build-epic.md in `.claude/future-tasks/`, "Every route
+ * loads sharp"). transform.ts is reachable from `canopycms/server` and, through
+ * api/assets.ts, from `canopycms/http` and so from `canopycms-next`, which a
+ * host app's root layout can import (that adopter's did). When the libvips
+ * `.so` was missing from its standalone output, that one static import turned
+ * it into a 500 on every on-demand route, 404s included, and defeated
+ * pipeline.ts's deliberate fail-open. Loaded on first use, a missing binary
+ * affects only the image operations that need it.
+ *
+ * Memoized INCLUDING a rejection: a failed dlopen does not heal inside a
+ * running process, so a retry would only pay for the failure again and log
+ * it again. The failure is logged once, here, and every later caller gets the
+ * same rejected promise to handle as its operation requires: transform.ts
+ * lets it propagate as a server error, pipeline.ts fails open.
+ */
+import { getErrorMessage } from '../utils/error.js';
+import { canopyLogError } from '../utils/logger.js';
+let loading;
+/** Resolve sharp's callable constructor, loading the native module on the first call only. */
+export function loadSharp() {
+    if (!loading) {
+        loading = import('sharp').then((mod) => mod.default, (err) => {
+            canopyLogError(`[canopycms] sharp failed to load - image transforms and upload decode validation are unavailable in this process: ${getErrorMessage(err)}`);
+            throw err;
+        });
+        // Marks the stored promise handled; every caller still gets the rejection.
+        // Without it, a caller that does not await - a warm-up `void loadSharp()` -
+        // leaves a rejected promise with no handler, which Node treats as fatal by
+        // default: a whole-process outage, the shape this module exists to prevent.
+        // The failure is already logged above.
+        loading.catch(() => undefined);
+    }
+    return loading;
+}

package/dist/assets/transform-directives.d.ts

@@ -4,7 +4,7 @@
  * NO imports (not even other files in this directory) so it can be imported
  * from client bundles (via `assetUrl`/`assetSrcSet` in asset-url.ts, exported
  * off the package's main entry) as well as from the server-only transform
- * engine (transform.ts) and the future prod transform Lambda (PR 7), without
+ * engine (transform.ts) and the prod transform Lambda, without
  * ever pulling in node:crypto, sharp, or any other server-only dependency.
  *
  * `{directives}` is either the literal identity token (`orig`) or a

package/dist/assets/transform-directives.js

@@ -4,7 +4,7 @@
  * NO imports (not even other files in this directory) so it can be imported
  * from client bundles (via `assetUrl`/`assetSrcSet` in asset-url.ts, exported
  * off the package's main entry) as well as from the server-only transform
- * engine (transform.ts) and the future prod transform Lambda (PR 7), without
+ * engine (transform.ts) and the prod transform Lambda, without
  * ever pulling in node:crypto, sharp, or any other server-only dependency.
  *
  * `{directives}` is either the literal identity token (`orig`) or a

package/dist/assets/transform.d.ts

@@ -3,8 +3,15 @@
  * source image bytes with sharp. Server-only - never import this from
  * client/editor code (this is why it lives in its own file, separate from
  * the dependency-free transform-directives.ts). Used by the dev-mode lazy
- * `/assets/t/*` emulation in api/assets.ts today, and will be reused
- * unchanged by the prod transform Lambda (PR 7).
+ * `/assets/t/*` emulation in api/assets.ts and, unchanged, by the prod
+ * transform Lambda (packages/canopycms-cdk/lambda/asset-transform).
+ *
+ * sharp is imported for its TYPES only and loaded on first use through
+ * `loadSharp()` (sharp-loader.ts), so importing this module never loads
+ * libvips. That matters because this module sits in the import graph of
+ * `canopycms/server` and `canopycms/http`: see sharp-loader.ts for the
+ * adopter outage a static import caused, and eslint.config.mjs for the rule
+ * that keeps it from coming back.
  *
  * Pipeline: a cheap metadata-only probe (`limitInputPixels: MAX_INPUT_PIXELS`,
  * decompression-bomb defense #1) learns the real page count, so animated
@@ -47,4 +54,9 @@ export interface TransformRejection {
     error: string;
 }
 export type TransformResult = TransformSuccess | TransformRejection;
+/**
+ * Resolves a `TransformRejection` for anything wrong with the input or the
+ * output. REJECTS (throws) when sharp itself cannot be loaded in this process
+ * - see the comment at the `loadSharp()` call below.
+ */
 export declare function applyTransform(input: ApplyTransformInput, directives: TransformDirectives): Promise<TransformResult>;

package/dist/assets/transform.js

@@ -3,8 +3,15 @@
  * source image bytes with sharp. Server-only - never import this from
  * client/editor code (this is why it lives in its own file, separate from
  * the dependency-free transform-directives.ts). Used by the dev-mode lazy
- * `/assets/t/*` emulation in api/assets.ts today, and will be reused
- * unchanged by the prod transform Lambda (PR 7).
+ * `/assets/t/*` emulation in api/assets.ts and, unchanged, by the prod
+ * transform Lambda (packages/canopycms-cdk/lambda/asset-transform).
+ *
+ * sharp is imported for its TYPES only and loaded on first use through
+ * `loadSharp()` (sharp-loader.ts), so importing this module never loads
+ * libvips. That matters because this module sits in the import graph of
+ * `canopycms/server` and `canopycms/http`: see sharp-loader.ts for the
+ * adopter outage a static import caused, and eslint.config.mjs for the rule
+ * that keeps it from coming back.
  *
  * Pipeline: a cheap metadata-only probe (`limitInputPixels: MAX_INPUT_PIXELS`,
  * decompression-bomb defense #1) learns the real page count, so animated
@@ -28,8 +35,8 @@
  * path with no extra native dependency) purely for pipeline uniformity, not
  * because GIF needs stripping.
  */
-import sharp from 'sharp';
 import { getErrorMessage } from '../utils/error.js';
+import { loadSharp } from './sharp-loader.js';
 import { MAX_ANIMATED_FRAMES, MAX_INPUT_PIXELS, } from './transform-directives.js';
 /** Raster formats the transform engine accepts as input. svg/pdf never reach here - they're served statically. */
 const ALLOWED_INPUT_EXTS = new Set(['png', 'jpg', 'jpeg', 'webp', 'gif']);
@@ -126,6 +133,11 @@ function encodeSourceFormat(pipeline, sourceExt, quality) {
             return pipeline.png(options);
     }
 }
+/**
+ * Resolves a `TransformRejection` for anything wrong with the input or the
+ * output. REJECTS (throws) when sharp itself cannot be loaded in this process
+ * - see the comment at the `loadSharp()` call below.
+ */
 export async function applyTransform(input, directives) {
     const sourceExt = input.ext.toLowerCase();
     if (!ALLOWED_INPUT_EXTS.has(sourceExt)) {
@@ -135,6 +147,14 @@ export async function applyTransform(input, directives) {
             error: `Unsupported input format for transform: '${sourceExt}'`,
         };
     }
+    // After the format check and OUTSIDE the try below, both on purpose. A load
+    // failure is a fault in this environment (the native binary is missing or
+    // built for another platform), not a fact about these bytes, so it must
+    // reach the caller as a thrown error - a 500 from http/handler.ts's
+    // top-level catch or from the transform Lambda's - and never the 422 the
+    // catch below means "sharp could not process this input". The 400 above
+    // needs no decoder, so it keeps working where sharp cannot load.
+    const sharp = await loadSharp();
     const resize = directives.identity ? undefined : directives;
     const format = resize?.format;
     const quality = resize?.quality;

package/dist/auth/plugin.js

@@ -22,6 +22,6 @@ export function assertAuthPluginAllowedForMode(plugin, mode) {
             '`verifiesCredentials: true`. This plugin performs no real credential verification, ' +
             'so anyone could impersonate any user (including admins). Configure a verifying auth ' +
             "plugin for production (e.g. createClerkAuthPlugin from 'canopycms-auth-clerk' with " +
-            "CLERK_SECRET_KEY set), or run with mode: 'dev' for local development.");
+            "CLERK_JWT_KEY set), or run with mode: 'dev' for local development.");
     }
 }

package/dist/branch-workspace.d.ts

@@ -25,8 +25,10 @@ export { loadBranchContext } from './branch-metadata.js';
 /**
  * Load an existing branch context, or create the workspace if it doesn't exist yet.
  *
- * Static deployments skip all git/branch workspace operations and return
- * a synthetic context pointing at the current working directory.
+ * When content is read from the checkout (`readsFromCheckout`: a static
+ * deployment, or any build) this skips every git and branch-workspace
+ * operation and returns a synthetic context rooted at the current working
+ * directory. `branchName` is echoed back on that context but selects nothing.
  */
 export declare function loadOrCreateBranchContext(options: {
     config: CanopyConfig;

package/dist/branch-workspace.js

@@ -1,7 +1,7 @@
 import path from 'node:path';
 import { ensureBranchRoot } from './paths/index.js';
 import { getBranchMetadataFileManager, loadBranchContext } from './branch-metadata.js';
-import { isDeployedStatic } from './build-mode.js';
+import { readsFromCheckout } from './build-mode.js';
 import { operatingStrategy } from './operating-mode/index.js';
 import { GitManager } from './git-manager.js';
 import { createDebugLogger } from './utils/debug.js';
@@ -28,11 +28,15 @@ export class BranchWorkspaceManager {
             }
             // Create new lock promise
             const lockPromise = (async () => {
-                // The in-memory lock above only serializes within one process. Parallel
-                // build workers (separate processes) could otherwise both clone into the
-                // same branch workspace ("destination path already exists"), so guard the
-                // workspace init with a cross-process lock too. initializeWorkspace is
-                // idempotent, so the waiter simply finds the workspace already cloned.
+                // The in-memory lock above only serializes within one process. Separate
+                // processes can provision the same branch workspace at once -- several
+                // Lambda containers sharing one EFS workspace root in prod, or the dev
+                // server beside a content-reading script run outside a build in dev --
+                // and would otherwise both clone into it ("destination path already
+                // exists"), so guard the workspace init with a cross-process lock too.
+                // initializeWorkspace is idempotent, so the waiter simply finds the
+                // workspace already cloned. (A build's content reads never get here:
+                // loadOrCreateBranchContext returns the checkout before provisioning.)
                 let releaseLock;
                 try {
                     log.debug('workspace', 'Ensuring git workspace', {
@@ -122,12 +126,14 @@ export { loadBranchContext } from './branch-metadata.js';
 /**
  * Load an existing branch context, or create the workspace if it doesn't exist yet.
  *
- * Static deployments skip all git/branch workspace operations and return
- * a synthetic context pointing at the current working directory.
+ * When content is read from the checkout (`readsFromCheckout`: a static
+ * deployment, or any build) this skips every git and branch-workspace
+ * operation and returns a synthetic context rooted at the current working
+ * directory. `branchName` is echoed back on that context but selects nothing.
  */
 export async function loadOrCreateBranchContext(options) {
-    // Static deployments read content directly from the checkout — no git ops needed
-    if (isDeployedStatic(options.config)) {
+    // Static deployments and builds read content directly from the checkout — no git ops
+    if (readsFromCheckout(options.config)) {
         const cwd = process.cwd();
         return {
             branch: {

package/dist/build-mode.d.ts

@@ -8,12 +8,40 @@ export declare const isDeployedStatic: (config: {
     deployedAs?: string;
 }) => boolean;
 /**
- * Safety net: detect build phase where auth is unavailable.
- * Covers edge cases like getCanopy() called from generateStaticParams
- * in server deployments. For static deployments, isDeployedStatic()
- * is the primary check.
+ * Detect a build, where there is no request and no auth.
+ *
+ * Under Next.js this is `NEXT_PHASE === 'phase-production-build'`, which
+ * `next build` sets itself: after compiling, and immediately before it creates
+ * the static worker that collects page data and prerenders, whose processes
+ * inherit it. So it is true in page modules, `generateStaticParams` and
+ * prerendering, but NOT yet set when `next build` loads `next.config.*`, which
+ * it does first. `next dev`, `next start` and the standalone server never set
+ * it. Verified in Next 15.5.21 and 16.1.7, where `build/index.js` (in both
+ * `dist/` and `dist/esm/`) holds the only assignment -- re-check on every Next
+ * major.
+ *
+ * `CANOPY_BUILD_MODE=true` is the framework-neutral switch: for builds Next
+ * does not drive, and for scripts run alongside one (the generated
+ * `Dockerfile.cms` sets it in its builder stage, ahead of the build command).
  */
 export declare const isBuildMode: () => boolean;
+/**
+ * Is content read straight from the checkout, rather than from a branch
+ * workspace?
+ *
+ * This decides WHERE content is read. `isDeployedStatic` and `isBuildMode`
+ * used on their own decide WHO reads it (`STATIC_DEPLOY_USER`, no ACLs).
+ *
+ * True for a static deployment, and for every build in either mode and either
+ * deployment type. A build reads the working tree at `process.cwd()` and
+ * never touches git, `.canopy-dev` or a branch clone: CI builds exactly the
+ * checked-out commit, and a local build reads what is on disk, uncommitted
+ * files included. Editor saves not yet copied out of `.canopy-dev`
+ * (`canopycms sync pull`) are not part of a build.
+ */
+export declare const readsFromCheckout: (config: {
+    deployedAs?: string;
+}) => boolean;
 /**
  * Synthetic user with full access for static deployments and build phase.
  * Has Admin privileges — all content is readable, permissions are skipped.

package/dist/build-mode.js

@@ -7,10 +7,21 @@ export const isDeployedStatic = (config) => {
     return config.deployedAs === 'static';
 };
 /**
- * Safety net: detect build phase where auth is unavailable.
- * Covers edge cases like getCanopy() called from generateStaticParams
- * in server deployments. For static deployments, isDeployedStatic()
- * is the primary check.
+ * Detect a build, where there is no request and no auth.
+ *
+ * Under Next.js this is `NEXT_PHASE === 'phase-production-build'`, which
+ * `next build` sets itself: after compiling, and immediately before it creates
+ * the static worker that collects page data and prerenders, whose processes
+ * inherit it. So it is true in page modules, `generateStaticParams` and
+ * prerendering, but NOT yet set when `next build` loads `next.config.*`, which
+ * it does first. `next dev`, `next start` and the standalone server never set
+ * it. Verified in Next 15.5.21 and 16.1.7, where `build/index.js` (in both
+ * `dist/` and `dist/esm/`) holds the only assignment -- re-check on every Next
+ * major.
+ *
+ * `CANOPY_BUILD_MODE=true` is the framework-neutral switch: for builds Next
+ * does not drive, and for scripts run alongside one (the generated
+ * `Dockerfile.cms` sets it in its builder stage, ahead of the build command).
  */
 export const isBuildMode = () => {
     // Next.js build phase
@@ -21,6 +32,23 @@ export const isBuildMode = () => {
         return true;
     return false;
 };
+/**
+ * Is content read straight from the checkout, rather than from a branch
+ * workspace?
+ *
+ * This decides WHERE content is read. `isDeployedStatic` and `isBuildMode`
+ * used on their own decide WHO reads it (`STATIC_DEPLOY_USER`, no ACLs).
+ *
+ * True for a static deployment, and for every build in either mode and either
+ * deployment type. A build reads the working tree at `process.cwd()` and
+ * never touches git, `.canopy-dev` or a branch clone: CI builds exactly the
+ * checked-out commit, and a local build reads what is on disk, uncommitted
+ * files included. Editor saves not yet copied out of `.canopy-dev`
+ * (`canopycms sync pull`) are not part of a build.
+ */
+export const readsFromCheckout = (config) => {
+    return isDeployedStatic(config) || isBuildMode();
+};
 /**
  * Synthetic user with full access for static deployments and build phase.
  * Has Admin privileges — all content is readable, permissions are skipped.

package/dist/cli/cli.d.ts

@@ -3,7 +3,7 @@
  * CanopyCMS CLI entrypoint.
  *
  * Routes commands to their implementations:
- *   init, init-deploy, worker, generate-ai-content, sync, migrate
+ *   init, init-deploy, init-github-app, worker, generate-ai-content, sync, migrate
  *
  * Command implementations live in separate files (init.ts, sync.ts, etc.)
  * and are dynamically imported to keep startup fast.
@@ -16,6 +16,16 @@ export declare function parseArgs(rawArgs: string[]): {
     flags: Record<string, string | boolean>;
     command: string | undefined;
 };
+/**
+ * The argv after a literal `--`, as a real string array.
+ *
+ * minimist types its parsed object with an `any` index signature, so reading
+ * `argv['--']` directly would hand an `any` straight to spawn(). Narrowed here
+ * through `unknown` instead, and returned as `[]` when absent so callers can
+ * treat "no passthrough" and "empty passthrough" the same way. Exported for
+ * testing.
+ */
+export declare function passthroughArgs(argv: Record<string, unknown>): string[];
 /**
  * Validate the --auth flag value for `init`. Returns undefined when the flag
  * was not provided (caller should fall through to interactive prompt / default).