canopycms 0.0.67-int.90 → 0.0.67

package/dist/worker/worker-context.d.ts

@@ -1,49 +1,25 @@
 import type { Octokit } from '@octokit/rest';
 import type { SanitizedBranchName } from '../paths/types.js';
-import type { Task, TaskQueueLogger } from './task-queue.js';
+import type { Task, TaskQueueLogger } from '../task-queue/cms-task-queue.js';
 import type { WorkerStatusReport } from '../types.js';
 /**
  * The slice of {@link import('./cms-worker.js').CmsWorker} that its extracted
- * clusters (task-runner.ts, git-sync.ts, rebase.ts, history-rewrite.ts) are
- * allowed to reach.
+ * clusters (task-runner.ts, git-sync.ts, rebase.ts, history-rewrite.ts) may
+ * reach — the ONLY channel between the class and that code. Each module narrows
+ * it further with a `Pick<WorkerContext, ...>` alias, so a function's signature
+ * names its real dependency set rather than the union.
  *
- * `CmsWorker` used to be 2,949 lines holding four disjoint call trees under one
- * entry point, sharing six helper methods and a 16-field config. The clusters
- * now live in their own modules as free functions taking this context, and the
- * class keeps thin delegating methods. This interface is what makes the sharing
- * explicit: it is the ONLY channel between the class and the extracted code, so
- * "what does the rebase loop actually need from the worker?" has an answer you
- * can read, rather than being whatever `this.` happens to resolve to.
- *
- * Each module narrows it further with a `Pick<WorkerContext, ...>` alias, so a
- * function's signature names its real dependency set rather than the union.
- *
- * ## Why the second group are FUNCTIONS, not fields
- *
- * Everything below the divider is resolved by CALLING back onto the live
- * `CmsWorker` instance, never snapshotted into the context object. That is
- * load-bearing, not stylistic. The worker's ten `cms-worker*.test.ts` files drive it by
- * reaching through the instance:
- *
- * - `cms-worker.test.ts` and `cms-worker-sync-reconcile.test.ts` REPLACE
- *   `buildGitHubUrl` on the instance to redirect pushes at a local fixture repo
- *   instead of github.com;
- * - `cms-worker-merge-poll.test.ts` and `cms-worker.test.ts` ASSIGN a mock over
- *   the `octokit` field;
- * - `cms-worker.test.ts` REPLACES `executeTask` (to drive the retry/timeout
- *   paths without real work) and `pushBranchToGitHub` (to exercise the PR
- *   actions with no git remote), then asserts on the replacement;
- * - several set `running` directly instead of calling `start()`;
- * - `cms-worker-content-lock.test.ts` SUBCLASSES `CmsWorker` to override the two
- *   `afterConflictDetectedForTesting`/`afterRebaseCompletedForTesting` hooks.
- *
- * A context built with `octokit: this.octokit` would capture the real Octokit
- * before the test ever installs its mock, and a captured `buildGitHubUrl` string
- * would send a test's push to github.com for real. Writing them as functions
- * (`ctx.octokit()`, `ctx.buildGitHubUrl()`) makes the late binding visible at
- * every call site, which a getter would hide. `CmsWorker.ctx()` builds a fresh
- * context per call for the same reason — there is no long-lived object for a
- * stale reference to hide in.
+ * INVARIANT: everything below the divider is a FUNCTION, resolved by CALLING
+ * back onto the live instance and never snapshotted, and `CmsWorker.ctx()`
+ * builds a fresh context per call. That is load-bearing, not stylistic. The
+ * `cms-worker*.test.ts` files drive the class by reaching through the instance:
+ * they REPLACE `buildGitHubUrl` (aiming pushes at a local fixture repo rather
+ * than github.com), `executeTask` and `pushBranchToGitHub`, ASSIGN a mock over
+ * the `octokit` field, set `running` directly, and SUBCLASS to override the two
+ * rebase test hooks. A context that captured any of those at construction would
+ * hand the extracted code the pre-test value — which for `buildGitHubUrl` means
+ * a test's push going to github.com for real. Functions (`ctx.octokit()`) make
+ * the late binding visible at every call site, which a getter would hide.
  */
 export interface WorkerContext {
     /** GitHub owner, e.g. 'safeinsights'. */
@@ -56,8 +32,8 @@ export interface WorkerContext {
      */
     readonly baseBranch: string;
     /**
-     * The base branch's workspace DIRECTORY name. Computed once so every
-     * filesystem call site agrees instead of re-deriving it and risking drift.
+     * The base branch's workspace DIRECTORY name, computed once so every
+     * filesystem call site agrees instead of re-deriving it.
      */
     readonly sanitizedBaseBranch: SanitizedBranchName;
     /** `{workspacePath}/.tasks` — the task queue and worker-status.json. */
@@ -80,34 +56,24 @@ export interface WorkerContext {
     octokit(): Octokit;
     /**
      * The tokenized GitHub clone URL, resolved at call time (tests replace this
-     * method to point at a local fixture repo).
+     * method to point at a local fixture repo). Async because under GitHub App
+     * auth the credential is minted on demand and lasts about an hour (see
+     * worker/github-auth.ts); the token path resolves immediately.
      *
-     * Async because the credential need not be something the worker already
-     * holds: a credential that has to be fetched or minted cannot be assembled
-     * synchronously out of config. Under GitHub App auth it is minted on
-     * demand and lasts about an hour (see worker/github-auth.ts); the personal
-     * access token path still resolves immediately.
-     *
-     * A caller that needs the URL more than once must resolve it ONCE into a
-     * local and reuse that, rather than calling again per push -- see
-     * pushBranchToGitHub, where a second resolution inside the stale-lease catch
-     * block would replace the very error being classified.
-     *
-     * Anything derived from it can embed the bot token, so a message that reaches
-     * worker-status.json, branch.json or a task file must go through
-     * `redactCredentials` first.
+     * A caller that needs the URL more than once resolves it ONCE into a local --
+     * see pushBranchToGitHub, where a second resolution inside the stale-lease
+     * catch would replace the very error being classified. Anything derived from
+     * it can embed the bot token, so a message reaching worker-status.json,
+     * branch.json or a task file goes through `redactCredentials` first.
      */
     buildGitHubUrl(): Promise<string>;
     /**
      * Re-read the GitHub credential because an operation that used it just
-     * failed, read at call time.
-     *
-     * Best-effort and NEVER throws: a failed read, or one that does not settle
-     * within `taskTimeoutMs`, is logged and swallowed, because every caller is
-     * already handling a failure and that failure is the one to report. Once it
-     * resolves, the next `buildGitHubUrl()` or `octokit()` call sees any rotated
-     * value. See `CmsWorker.refreshGitHubCredential` for the two call sites and
-     * why neither is gated on the error's shape.
+     * failed, read at call time. Best-effort and NEVER throws: a failed read, or
+     * one that does not settle within `taskTimeoutMs`, is logged and swallowed,
+     * because every caller is already reporting the failure that matters. The
+     * next `buildGitHubUrl()`/`octokit()` sees any rotated value. See
+     * `CmsWorker.refreshGitHubCredential`.
      */
     refreshGitHubCredential(): Promise<void>;
     /**
@@ -116,23 +82,18 @@ export interface WorkerContext {
      */
     branchWorkspacePath(branchRefName: string): string;
     /**
-     * Run one task, read at call time.
-     *
-     * Routed back through the instance even though the implementation lives in
-     * task-runner.ts beside its only caller, because cms-worker.test.ts REPLACES
-     * this method on the instance to drive the retry and timeout paths without
-     * doing real work. `executeTaskWithTimeout` must therefore call
-     * `ctx.executeTask(...)`, never the module-level function directly -- doing
-     * the latter silently bypasses the stub and the tests go red.
+     * Run one task, read at call time. Routed back through the instance even
+     * though the implementation lives in task-runner.ts beside its only caller,
+     * because cms-worker.test.ts REPLACES this method on the instance:
+     * `executeTaskWithTimeout` must call `ctx.executeTask(...)`, never the
+     * module-level function, which would silently bypass the stub.
      */
     executeTask(task: Task, signal: AbortSignal): Promise<Record<string, unknown>>;
     /**
-     * Push a branch from remote.git to GitHub, read at call time.
-     *
-     * Routed through the instance for the same reason as `executeTask`:
-     * cms-worker.test.ts replaces it with a spy so the PR actions can be
-     * exercised with no git remote, and then asserts the spy was NOT called on
-     * the base-branch-refusal path.
+     * Push a branch from remote.git to GitHub, read at call time. Routed through
+     * the instance for the same reason as `executeTask`: cms-worker.test.ts
+     * replaces it with a spy and asserts the spy was NOT called on the
+     * base-branch-refusal path.
      */
     pushBranchToGitHub(branch: string): Promise<void>;
     /** Whether the worker is still running; both poll loops bail when false. */
@@ -143,8 +104,7 @@ export interface WorkerContext {
     ensureSettingsBranch(): string;
     /**
      * Test hook: fires when the rebase has reported conflicted files and is about
-     * to `checkout --theirs` them. No-op in production; overridden by a subclass
-     * in cms-worker-content-lock.test.ts.
+     * to `checkout --theirs` them. No-op in production.
      */
     afterConflictDetectedForTesting(): Promise<void>;
     /**

package/package.json

@@ -1,7 +1,7 @@
 {
   "//": "@codemirror/language, @lezer/highlight: workaround — @mdxeditor/editor uses cm6-theme-basic-light which peer-requires these but mdxeditor doesn't declare them as dependencies",
   "name": "canopycms",
-  "version": "0.0.67-int.90",
+  "version": "0.0.67",
   "description": "CanopyCMS core package: schema-driven content, branch-aware editing, and editor UI for Next.js.",
   "license": "MIT",
   "repository": {
@@ -53,9 +53,9 @@
       "require": "./dist/task-queue/index.js"
     },
     "./worker/task-queue": {
-      "types": "./dist/worker/task-queue.d.ts",
-      "import": "./dist/worker/task-queue.js",
-      "require": "./dist/worker/task-queue.js"
+      "types": "./dist/task-queue/cms-task-queue.d.ts",
+      "import": "./dist/task-queue/cms-task-queue.js",
+      "require": "./dist/task-queue/cms-task-queue.js"
     },
     "./worker/cms-worker": {
       "types": "./dist/worker/cms-worker.d.ts",

package/dist/cli/template-files/middleware-clerk.ts.template

@@ -1,37 +0,0 @@
-import { clerkMiddleware, createRouteMatcher } from '@clerk/nextjs/server'
-
-const isProtectedRoute = createRouteMatcher(['/edit(.*)', '/api/canopycms(.*)'])
-
-// This middleware is optional. CanopyCMS authenticates /api/canopycms without
-// it: createNextCanopyContext wraps the Clerk auth plugin in CachingAuthPlugin,
-// which verifies each request's Clerk token with CLERK_JWT_KEY alone and reads
-// user and group metadata from the auth cache. What this file adds is turning
-// signed-out requests to /edit and /api/canopycms away before they reach the
-// app. On a deployed CMS Lambda it costs two things:
-//   - CLERK_SECRET_KEY on the Lambda. clerkMiddleware throws on every request
-//     it matches unless it can resolve a secret key (jwtKey doesn't count),
-//     which breaks the public-keys-only Lambda that the Security Model in
-//     docs/deploying-to-aws.md describes.
-//   - One image per Clerk instance. It reads the publishable key inlined at
-//     image build (NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY), not the one your
-//     ClerkProvider receives, unless you pass it an options callback that
-//     reads both keys at run time.
-// To run without it, delete this file; docs/deploying-to-aws.md ("One image
-// for every Clerk tier") describes that shape.
-//
-// Without an explicit jwtKey, @clerk/nextjs fetches JWKS from api.clerk.com on
-// every cold verification -- the prod CMS Lambda has no internet and hangs.
-// With it, verification is a local PEM operation (the env var alone does
-// nothing; it appears only in Clerk error messages).
-export default clerkMiddleware(
-  async (auth, req) => {
-    if (isProtectedRoute(req)) {
-      await auth.protect()
-    }
-  },
-  { jwtKey: process.env.CLERK_JWT_KEY },
-)
-
-export const config = {
-  matcher: ['/edit(.*)', '/api/canopycms(.*)'],
-}

package/dist/worker/task-queue-config.d.ts

@@ -1,8 +0,0 @@
-import type { CanopyConfig } from '../config/index.js';
-/**
- * Get the task queue directory for async worker operations.
- *
- * In prod mode: {CANOPYCMS_WORKSPACE_ROOT}/.tasks
- * In dev mode: {cwd}/.canopy-dev/.tasks
- */
-export declare function getTaskQueueDir(config: Pick<CanopyConfig, 'mode'>): string;

package/dist/worker/task-queue.js

@@ -1,19 +0,0 @@
-/**
- * CanopyCMS task queue — re-exports from the generic task-queue module
- * with CMS-specific action types and a WorkerTask alias.
- */
-import { createDebugLogger } from '../utils/debug.js';
-// ============================================================================
-// Shared logger instance for CMS task queue operations
-// ============================================================================
-const debugLogger = createDebugLogger({ prefix: 'TaskQueue' });
-export const cmsTaskQueueLogger = {
-    debug(message, data) {
-        debugLogger.debug('task', message, data);
-    },
-};
-// ============================================================================
-// Re-exports from generic task-queue module
-// ============================================================================
-export { enqueueTask, dequeueTask, completeTask, failTask, retryTask, requeueFailedTask, recoverOrphanedTasks, cleanupOldTasks, getTask, getTask as getTaskResult, // backward-compatible alias
-listTasks, getQueueStats, listCorruptTaskFiles, } from '../task-queue/index.js';

package/dist/worker/worker-status.d.ts

@@ -1,47 +0,0 @@
-/**
- * worker-status.json: the CmsWorker daemon's self-reported liveness/health
- * snapshot (PR-W1), written under the task queue directory
- * (`{taskDir}/worker-status.json`, i.e. `.tasks/worker-status.json`) and
- * read tolerantly by the admin API (api/admin.ts's `readWorkerStatus`).
- * Wire shape: `WorkerStatusReport` in ../types.
- *
- * Single-writer file: only the lock-holding CmsWorker (see cms-worker.ts's
- * `acquireLock`, DEP-C2) ever writes it. Every write is a FULL regeneration
- * of the whole report, never a partial merge -- there is no read-modify-write
- * step, so last-write-wins is trivially correct: whichever write lands last
- * (via the atomic rename below) is a complete, self-consistent snapshot.
- * Readers (the Lambda admin endpoint, typically on a different host) are
- * stale-tolerant by design: this file is a liveness signal, not
- * authoritative state, and NFS/EFS attribute-cache staleness (see
- * docs/concurrency.md) means a reader can see a snapshot up to the cache
- * window old regardless of how carefully the write itself is done.
- *
- * Honest caveat: after a lock compromise (`onCompromised` in
- * `acquireLock`), the old holder's `stop()` drains in-flight operations for
- * up to `taskTimeoutMs` (default 60s) before the lock is actually released,
- * while a new holder may already be running against the same workspace. For
- * that window, both the old and new holder can call `writeWorkerStatus`
- * concurrently. This is harmless: every write is an atomic full-snapshot
- * rename (temp file + `rename()`, see utils/atomic-write.ts), never a
- * read-modify-write, so the result is always exactly one writer's complete
- * snapshot -- whichever lands last -- never a corrupt or interleaved mix of
- * both writers' data.
- */
-import type { WorkerStatusReport } from '../types.js';
-export declare const WORKER_STATUS_FILE = "worker-status.json";
-/**
- * Write the worker's status report to `{taskDir}/worker-status.json`.
- *
- * Full-file regeneration via the shared atomic write util (temp file +
- * rename) -- never a partial update, so callers should pass the complete
- * report they want persisted, not a delta. Stamps/overwrites `updatedAt`
- * with the current time; every other field is the caller's responsibility.
- *
- * Throws on failure rather than swallowing it: callers that can't afford a
- * status-write failure to break their own operation (a git sync cycle, a
- * task-queue poll) wrap this call in best-effort handling at the call site
- * -- see cms-worker.ts's `syncGit`/`processTaskQueue`/`start()`. Any call
- * site that doesn't wrap it falls back on scheduleLoop's existing per-cycle
- * catch, which logs and continues.
- */
-export declare function writeWorkerStatus(taskDir: string, report: WorkerStatusReport): Promise<void>;

package/dist/worker/worker-status.js

@@ -1,52 +0,0 @@
-/**
- * worker-status.json: the CmsWorker daemon's self-reported liveness/health
- * snapshot (PR-W1), written under the task queue directory
- * (`{taskDir}/worker-status.json`, i.e. `.tasks/worker-status.json`) and
- * read tolerantly by the admin API (api/admin.ts's `readWorkerStatus`).
- * Wire shape: `WorkerStatusReport` in ../types.
- *
- * Single-writer file: only the lock-holding CmsWorker (see cms-worker.ts's
- * `acquireLock`, DEP-C2) ever writes it. Every write is a FULL regeneration
- * of the whole report, never a partial merge -- there is no read-modify-write
- * step, so last-write-wins is trivially correct: whichever write lands last
- * (via the atomic rename below) is a complete, self-consistent snapshot.
- * Readers (the Lambda admin endpoint, typically on a different host) are
- * stale-tolerant by design: this file is a liveness signal, not
- * authoritative state, and NFS/EFS attribute-cache staleness (see
- * docs/concurrency.md) means a reader can see a snapshot up to the cache
- * window old regardless of how carefully the write itself is done.
- *
- * Honest caveat: after a lock compromise (`onCompromised` in
- * `acquireLock`), the old holder's `stop()` drains in-flight operations for
- * up to `taskTimeoutMs` (default 60s) before the lock is actually released,
- * while a new holder may already be running against the same workspace. For
- * that window, both the old and new holder can call `writeWorkerStatus`
- * concurrently. This is harmless: every write is an atomic full-snapshot
- * rename (temp file + `rename()`, see utils/atomic-write.ts), never a
- * read-modify-write, so the result is always exactly one writer's complete
- * snapshot -- whichever lands last -- never a corrupt or interleaved mix of
- * both writers' data.
- */
-import path from 'node:path';
-import { atomicWriteFile } from '../utils/atomic-write.js';
-export const WORKER_STATUS_FILE = 'worker-status.json';
-/**
- * Write the worker's status report to `{taskDir}/worker-status.json`.
- *
- * Full-file regeneration via the shared atomic write util (temp file +
- * rename) -- never a partial update, so callers should pass the complete
- * report they want persisted, not a delta. Stamps/overwrites `updatedAt`
- * with the current time; every other field is the caller's responsibility.
- *
- * Throws on failure rather than swallowing it: callers that can't afford a
- * status-write failure to break their own operation (a git sync cycle, a
- * task-queue poll) wrap this call in best-effort handling at the call site
- * -- see cms-worker.ts's `syncGit`/`processTaskQueue`/`start()`. Any call
- * site that doesn't wrap it falls back on scheduleLoop's existing per-cycle
- * catch, which logs and continues.
- */
-export async function writeWorkerStatus(taskDir, report) {
-    const filePath = path.join(taskDir, WORKER_STATUS_FILE);
-    const stamped = { ...report, updatedAt: new Date().toISOString() };
-    await atomicWriteFile(filePath, JSON.stringify(stamped, null, 2));
-}