canopycms 0.0.67-int.90 → 0.0.67

package/dist/api/content.d.ts

@@ -2,7 +2,6 @@ import { z } from 'zod';
 import type { ApiResponse } from './types.js';
 import type { EntryValidationIssue } from '../config/index.js';
 import { type Slug } from '../paths/index.js';
-/** Response type for content read operations */
 export type ContentReadResponse = ApiResponse<{
     format: string;
     data: Record<string, unknown>;
@@ -10,7 +9,6 @@ export type ContentReadResponse = ApiResponse<{
     /** OCC version token: file mtime in ms. Pass back as `expectedVersion` on next write. */
     version?: number;
 }>;
-/** Response type for content write operations */
 export type ContentWriteResponse = ApiResponse<{
     format: string;
     data: Record<string, unknown>;
@@ -25,7 +23,6 @@ export type ContentWriteResponse = ApiResponse<{
      */
     validationWarnings?: EntryValidationIssue[];
 }>;
-/** Response type for reference validation */
 export type ReferenceValidationResponse = ApiResponse<{
     valid: boolean;
     errors?: Array<{
@@ -35,7 +32,6 @@ export type ReferenceValidationResponse = ApiResponse<{
         error: string;
     }>;
 }>;
-/** Response type for entry rename operations */
 export type RenameEntryResponse = ApiResponse<{
     newPath: string;
 }>;
@@ -58,8 +54,6 @@ export interface ValidateReferencesBody {
 export interface RenameEntryBody {
     newSlug: string;
 }
-/** Response type for reference options - re-exported for convenience */
-export type { ReferenceOptionsResponse } from './reference-options.js';
 /**
  * Exported routes for router registration
  */

package/dist/api/content.js

@@ -22,9 +22,7 @@ function parseApiPath(apiPath, contentRoot) {
  * sentence rather than a wall of paths.
  */
 const UNKNOWN_KEY_WARNING_LIMIT = 10;
-// ============================================================================
-// Zod Schemas for Validation
-// ============================================================================
+/** Re-exported for convenience. */
 const readContentParamsSchema = z.object({
     branch: branchNameSchema,
     path: logicalPathSchema,
@@ -78,10 +76,8 @@ const readContentHandler = async (gc, ctx, req, params) => {
     const store = new ContentStore(branchContext.branchRoot, flatSchema, {
         contentRootName: ctx.services.config.contentRoot || 'content',
     });
-    // Parse path segments: params.path is like "content/posts/hello"
     const contentRoot = ctx.services.config.contentRoot || 'content';
     const logicalPathSegments = parseApiPath(params.path, contentRoot);
-    // Use trivial path resolution
     let schemaItem;
     let slug;
     let relativePath;
@@ -117,10 +113,8 @@ const writeContentHandler = async (gc, ctx, req, params, body) => {
     const store = new ContentStore(branchContext.branchRoot, flatSchema, {
         contentRootName: ctx.services.config.contentRoot || 'content',
     });
-    // Parse path segments: params.path is like "content/posts/hello" or "posts/hello"
     const contentRoot = ctx.services.config.contentRoot || 'content';
     const logicalPathSegments = parseApiPath(params.path, contentRoot);
-    // Use trivial path resolution
     let schemaItem;
     let slug;
     let relativePath;
@@ -139,21 +133,15 @@ const writeContentHandler = async (gc, ctx, req, params, body) => {
     if (!access.allowed) {
         return { ok: false, status: 403, error: 'Forbidden' };
     }
-    // ------------------------------------------------------------------
-    // Authoritative schema validation at the write boundary (COMPOUND-2).
+    // Authoritative schema validation at the write boundary (COMPOUND-2): the server re-checks
+    // required fields, type/format correctness, and non-empty required references (rules shared
+    // with the editor via validation/entry-validator), plus reference EXISTENCE and
+    // EntryTypeConfig.maxItems (SCH-H3) — so a direct API call can't bypass what the editor's form
+    // enforces client-side.
     //
-    // The server rejects structurally invalid entry data even when the client
-    // is bypassed: required fields, type/format correctness, non-empty required
-    // references (pure rules shared with the editor via validation/entry-validator),
-    // plus reference EXISTENCE (server-only: reads the content ID index) and
-    // EntryTypeConfig.maxItems at the create boundary (SCH-H3).
-    //
-    // One narrow carve-out: the editor's create flow scaffolds a brand-new entry
-    // by writing entirely empty data (`{}` and an empty body) and only then lets
-    // the user fill the form — so a create scaffold (target file does not exist
-    // yet AND the payload is completely empty) skips field validation. Any write
-    // carrying actual data, and every write to an existing entry, is validated.
-    // ------------------------------------------------------------------
+    // Carve-out: a create scaffold (target doesn't exist yet, payload is entirely empty `{}`/no
+    // body) skips field validation, since the editor's create flow writes an empty scaffold before
+    // the user fills the form.
     // Resolve the entry-type config the store will write with (mirrors ContentStore.write)
     let entryTypeConfig;
     let fields = [];
@@ -182,7 +170,7 @@ const writeContentHandler = async (gc, ctx, req, params, body) => {
         // ContentStore.write() preserves it regardless of what's requested (see
         // buildPaths in content-store.ts) — so resolving from params.entryType
         // or the default here instead would let a direct API write validate a
-        // payload against the WRONG entry type's schema (post-review M2). The
+        // payload against the WRONG entry type's schema. The
         // editor always sends the entry's real entryType, so this only changes
         // behavior for non-editor callers.
         const existingEntryType = await store.getExistingEntryType(schemaItem.logicalPath, slug);
@@ -212,19 +200,12 @@ const writeContentHandler = async (gc, ctx, req, params, body) => {
     const isDataOnly = isDataOnlyFormat(body.format);
     try {
         const exists = await store.documentExists(schemaItem.logicalPath, slug);
-        // Create-intent guard (August 2026 baseline review, Critical finding): a
-        // create request (expectedVersion === null, "must not already exist")
-        // against a slug that already has content must never silently overwrite
-        // it. Without this, an entry type with no required fields passes field
-        // validation on the create path's empty payload and falls through to a
-        // blind store.write() — this short-circuits with an unambiguous 409
-        // before that validation (and the maxItems count below) even runs, so
-        // the error always names the real problem instead of a confusing
-        // "field is required" message or a bare conflict. store.write() also
-        // enforces this same guard itself, inside its per-entry lock against a
-        // fresh stat — that is the race-safe authoritative check; this early
-        // return is just a cheaper, clearer-messaged fast path for the common
-        // (non-racing) case.
+        // Create-intent guard: a create request (expectedVersion === null) against a slug that
+        // already has content must never silently overwrite it — short-circuit with 409 before field
+        // validation runs, so the error names the real problem instead of "field is required" or a
+        // bare conflict. store.write() re-enforces this itself inside its per-entry lock against a
+        // fresh stat (the race-safe authoritative check); this is just a cheaper fast path for the
+        // common case.
         if (body.expectedVersion === null && exists) {
             return {
                 ok: false,
@@ -232,18 +213,15 @@ const writeContentHandler = async (gc, ctx, req, params, body) => {
                 error: `An entry with slug "${slug}" already exists`,
             };
         }
-        // [SLUG] Create-only routability check. `writeContentParamsSchema.path` runs
-        // `parseLogicalPath`, which has no charset rule, and `ContentStore.resolvePath` casts the
-        // last segment to `Slug` with only `.toLowerCase()` — so nothing on the write chain applied
-        // `parseSlug` (only `renameEntry`'s `newSlug` did). A create with, say, `my_post` was
-        // accepted, and `assertRoutableSlugs` then failed the adopter's next production build over
-        // an entry that would 404 anyway. `store.write()` enforces this authoritatively inside its
-        // per-entry lock; this is the cheaper, clearer-messaged fast path — without it a create that
-        // is ALSO missing a required field reports the field, never the slug that is the real
-        // problem (same reasoning as the create-intent guard above).
+        // [SLUG] Create-only routability check: `writeContentParamsSchema.path`'s `parseLogicalPath`
+        // has no charset rule, and `ContentStore.resolvePath` only lowercases the slug — so this is
+        // the only place on the write chain that applies `parseSlug` (besides `renameEntry`'s
+        // `newSlug`). Without it, a non-routable slug like `my_post` would build and then 404 on
+        // every visit. `store.write()` re-enforces this inside its per-entry lock; this is the
+        // cheaper, clearer-messaged fast path.
         //
-        // Create-only on purpose: an entry that already carries a non-conforming slug must stay
-        // saveable and renameable, since renaming it is the only way to fix the build.
+        // Create-only: an entry with an existing non-conforming slug must stay saveable and
+        // renameable, since renaming it is the only way to fix the build.
         if (!exists) {
             const routable = parseSlug(slug);
             if (!routable.ok) {
@@ -255,11 +233,10 @@ const writeContentHandler = async (gc, ctx, req, params, body) => {
                 };
             }
         }
-        // SCH-H3: enforce maxItems server-side at the create boundary. The editor
-        // only gates its "Add" button; a direct API create could otherwise exceed
-        // the cap. Best-effort under concurrency: the count-then-create below is
-        // not atomic, so two simultaneous creates can still race past the cap —
-        // the guard's real target is the single-request direct-API bypass.
+        // SCH-H3: enforce maxItems server-side — the editor only gates its "Add" button, so a direct
+        // API create could otherwise exceed the cap. Best-effort under concurrency: count-then-create
+        // isn't atomic, so two simultaneous creates can still race past the cap; this guards the
+        // single-request bypass, not the race.
         if (!exists && maxItems !== undefined && entryTypeName) {
             const collectionPath = schemaItem.type === 'entry-type' ? schemaItem.parentPath : schemaItem.logicalPath;
             const count = await store.countEntriesOfType(collectionPath, entryTypeName);
@@ -308,45 +285,24 @@ const writeContentHandler = async (gc, ctx, req, params, body) => {
     // 'warning' issues are returned alongside the successful write.
     let validationWarnings;
     const validateEntry = ctx.services.config.validateEntry;
-    // Collapse resolved reference objects back to bare ID strings before PERSISTING, not just
-    // before validating (the reference validator gets its own normalized copy above).
-    //
-    // The editor round-trips whole documents: its GET reads through `store.read()`, whose
-    // `resolveReferences` defaults to TRUE, so form state holds `{...target data, id, slug,
-    // collection, urlPath}` for every reference field, and a save posts that straight back. Left
-    // unnormalized it lands in the content file verbatim — and because resolution only re-resolves
-    // a `typeof value === 'string'`, every later read passes the frozen snapshot through and every
-    // later save rewrites it. The reference is then permanently severed from its target: renaming
-    // or editing the target changes nothing, silently.
-    //
-    // The mechanism predates reference resolution reaching listings, but `includeBody` makes it
-    // materially worse — the snapshot now carries the target's entire prose — and `urlPath` adds a
-    // value that goes stale the moment the target is renamed. Normalizing here is schema-driven and
-    // idempotent: a payload that already holds ID strings is unchanged.
+    // Collapse resolved reference objects back to bare ID strings before persisting (the reference
+    // validator above gets its own copy). The editor's GET resolves references by default, so form
+    // state round-trips `{...target data, id, slug, collection, urlPath}` for each reference field;
+    // left unnormalized, a save would freeze that snapshot into the file (resolution only
+    // re-resolves plain ID strings), permanently severing the reference from its target. Idempotent:
+    // a payload that already holds ID strings is unchanged.
     const normalizedData = body.data === undefined ? undefined : normalizeReferenceValues(fields, body.data);
-    //
-    // Computed BEFORE the validateEntry hook and the entry-link scan, not just before the write,
-    // so every consumer of the payload agrees with the bytes that land on disk. Otherwise an
-    // adopter's hook inspecting a reference field saw a resolved object while the file got an ID
-    // string -- and saw it only when the post came from the editor, since a client posting bare
-    // IDs already gave the hook bare IDs. Normalizing first makes the hook's input deterministic
-    // regardless of caller.
-    // Keys with no counterpart in the schema. validateEntryData iterates the SCHEMA, so nothing
-    // reported the inverse: a renamed or reshaped field left its old key on disk forever (the
-    // editor round-trips the whole record, so every save rewrote it) and the only symptom was a
-    // component receiving `undefined`. Adopter request log item 29.
-    //
-    // Run against normalizedData -- the shape that will actually be persisted -- so the report
-    // matches the bytes, and so a resolved reference collapsed back to an ID string cannot be
-    // mistaken for anything. A warning, never a rejection: the key is still written (with its
-    // comments, see utils/content-serialize.ts), it is just not editable and nothing reads it.
-    //
-    // ONE issue, not one per key. The editor joins every warning into a single non-auto-closing
-    // notification (useEntryManager.ts), so one-per-key repeated the same explanatory sentence
-    // once per stale key, on every save, for a condition that is permanent until someone edits the
-    // schema. The keys are listed in the message instead, capped so a schema-wide rename cannot
-    // produce an unreadable wall of text. Worded for who can actually act: an editor cannot remove
-    // a key the form does not render, and cannot change the schema.
+    // Computed before the validateEntry hook and the entry-link scan too, not just the write, so
+    // every consumer agrees on the same bytes — otherwise an adopter's hook could see a resolved
+    // object while the file got an ID string, depending on whether the post came from the editor.
+    // Keys with no counterpart in the schema: validateEntryData iterates the SCHEMA, so it can't
+    // catch the inverse — a renamed/reshaped field whose old key lingers on disk forever, silently
+    // read back as `undefined`. Checked against normalizedData (the bytes that will actually be
+    // persisted) so a resolved reference collapsed to an ID string isn't mistaken for a stray key.
+    // A warning, never a rejection: the key is kept in the file, just unread and uneditable — an
+    // editor can't remove a key the form doesn't render or change the schema. One issue listing all
+    // stale keys (capped), not one per key, since the editor renders warnings as a single
+    // notification (useEntryManager.ts).
     if (normalizedData !== undefined) {
         const unknownKeys = findUnknownKeys(fields, normalizedData);
         if (unknownKeys.length > 0) {
@@ -420,8 +376,7 @@ const writeContentHandler = async (gc, ctx, req, params, body) => {
         // Reuses the entry-type fields resolved above for schema validation. Folded into
         // `validationWarnings` (not a separate `entryLinkWarnings` field) so the editor's one
         // save-warnings notification (useEntryManager.ts) is the single place any save-time
-        // warning surfaces -- a broken `entry:ID` link used to be computed and returned here
-        // with no consumer anywhere in the editor, so it was silently discarded.
+        // warning surfaces.
         const idIndex = await store.idIndex();
         const linkValidation = validateEntryLinks(normalizedData ?? {}, fields, idIndex, body.body);
         if (linkValidation.warnings.length > 0) {
@@ -436,39 +391,27 @@ const writeContentHandler = async (gc, ctx, req, params, body) => {
     }
     catch (err) {
         if (err instanceof ContentConflictError) {
-            // [SYNC-C1] Not an editor-vs-editor collision at all: the branch's
-            // working tree is being rebased. Usually the write was refused outright
-            // rather than acknowledged and then rolled back; the one exception is a
-            // lock compromised mid-write, where the write DID land but we can no
-            // longer prove it was exclusive. Each case carries its own message
-            // (retry vs. reload-then-decide), so pass it through -- checked first,
-            // since the generic branches below would otherwise blame another editor.
+            // [SYNC-C1] Not an editor collision: the branch is mid-rebase. Usually the write was
+            // refused outright, but a lock compromised mid-write can still land it — each case carries
+            // its own message, so pass `err.message` through rather than the generic conflict below.
             if (err instanceof BranchSyncingError) {
                 return { ok: false, status: 409, error: err.message };
             }
-            // [F1] Also not an editor-vs-editor collision: this entry's content ID
-            // is on two files (ContentIdIndex's duplicate-ID quarantine), so the
-            // save was refused rather than allowed to mutate an ambiguous target.
-            // Surface its own message — the generic one below would tell the editor
-            // to reload and retry, which cannot help and would have them hammering
-            // a save that stays refused until an admin runs repair-content-duplicates.
+            // [F1] Also not an editor collision: this content ID is quarantined on two files
+            // (ContentIdIndex's duplicate-ID detection). The generic message below would send the
+            // editor into a reload-and-retry loop that can't help until an admin runs
+            // repair-content-duplicates, so surface this error's own message instead.
             if (err instanceof DuplicateContentIdError) {
                 return { ok: false, status: 409, error: err.message };
             }
-            // [URL] Also not an editor-vs-editor collision, and critically NOT the
-            // same-slug case the branch below reports: no entry with this slug
-            // exists in this collection (the early `exists` check passed). What
-            // exists is a DIFFERENT entry claiming the same URL -- a sibling
-            // collection's index entry, or the parent entry this index entry would
-            // collide with. Falling through would tell the editor to look for an
-            // entry that is not there, and discard the one message that names the
-            // actual offender and what to do about it.
+            // [URL] Also not an editor collision, and not a same-slug conflict either — a DIFFERENT
+            // entry (a sibling collection's index entry, or this one's parent) claims the same URL.
+            // Surface its own message rather than telling the editor to look for an entry that exists.
             if (err instanceof UrlPathConflictError) {
                 return { ok: false, status: 409, error: err.message };
             }
-            // The early `exists` short-circuit above catches this in the common
-            // case; this is the race-safe fallback for a collision that landed
-            // between that check and store.write()'s in-lock stat.
+            // Race-safe fallback: the early `exists` check above catches the common case; this covers a
+            // collision that lands between that check and store.write()'s in-lock stat.
             if (body.expectedVersion === null) {
                 return {
                     ok: false,
@@ -482,12 +425,9 @@ const writeContentHandler = async (gc, ctx, req, params, body) => {
                 error: 'Content conflict: entry was modified by another editor',
             };
         }
-        // C2: a ContentStoreError is a known/expected client fault (validation,
-        // bad slug, etc.) and keeps its existing 400. Anything else - ENOSPC,
-        // EACCES, a bug - is a genuine server fault and must not be mislabeled
-        // as the client's mistake; rethrow so it surfaces as a 500 (see
-        // readContentHandler's store.read() catch above, which already follows
-        // this same pattern).
+        // C2: a ContentStoreError is an expected client fault (bad slug, validation, etc.) and keeps
+        // its 400. Anything else — ENOSPC, EACCES, a bug — is a genuine server fault and must not be
+        // mislabeled as the client's mistake; rethrow so it surfaces as a 500.
         if (err instanceof ContentStoreError) {
             return { ok: false, status: 400, error: sanitizeErrorMessage(err.message) };
         }
@@ -500,7 +440,6 @@ const validateReferencesHandler = async (gc, ctx, req, params, body) => {
     const store = new ContentStore(branchContext.branchRoot, flatSchema, {
         contentRootName: ctx.services.config.contentRoot || 'content',
     });
-    // Parse path segments to get collection/schema info
     const contentRoot = ctx.services.config.contentRoot || 'content';
     const logicalPathSegments = parseApiPath(params.path, contentRoot);
     let schemaItem;
@@ -522,7 +461,6 @@ const validateReferencesHandler = async (gc, ctx, req, params, body) => {
     }
     // Get ID index (automatically loads if needed)
     const idIndex = await store.idIndex();
-    // Resolve fields from entry type schema
     let fields = [];
     if (schemaItem.type === 'entry-type') {
         fields = schemaItem.schema;
@@ -551,7 +489,6 @@ const validateReferencesHandler = async (gc, ctx, req, params, body) => {
         }
         fields = entryTypeConfig.schema || [];
     }
-    // Validate references
     const validator = new ReferenceValidator(idIndex, fields, (name) => store.resolveCollectionItem(name)?.logicalPath);
     const result = await validator.validate(body.data);
     return {
@@ -569,10 +506,8 @@ const renameEntryHandler = async (gc, ctx, req, params, body) => {
     const store = new ContentStore(branchContext.branchRoot, flatSchema, {
         contentRootName: ctx.services.config.contentRoot || 'content',
     });
-    // Parse path segments
     const contentRoot = ctx.services.config.contentRoot || 'content';
     const logicalPathSegments = parseApiPath(params.path, contentRoot);
-    // Resolve to collection and slug
     let schemaItem;
     let currentSlug;
     let relativePath;
@@ -587,25 +522,19 @@ const renameEntryHandler = async (gc, ctx, req, params, body) => {
         const message = err instanceof ContentStoreError ? err.message : 'Invalid content request';
         return { ok: false, status: 400, error: sanitizeErrorMessage(message) };
     }
-    // Check edit permission on current path
     const access = await ctx.services.checkContentAccess(branchContext, branchContext.branchRoot, relativePath, req.user, 'edit');
     if (!access.allowed) {
         return { ok: false, status: 403, error: 'Forbidden' };
     }
-    // Rename the entry
     try {
         const result = await store.renameEntry(schemaItem.logicalPath, currentSlug, body.newSlug);
         return { ok: true, status: 200, data: { newPath: result.newPath } };
     }
     catch (err) {
-        // [SYNC-C1] The rename was refused because the branch is mid-rebase, not
-        // because the request was bad -- 409 + retry, never a 400.
+        // [SYNC-C1] Mid-rebase, not a bad request -- 409 + retry, never 400.
         if (err instanceof ContentConflictError) {
-            // [URL] A contested-URL refusal must carry its own message. The generic
-            // one below tells the editor to reload and retry, which cannot succeed
-            // here -- the rename stays refused until they pick a different slug or
-            // remove the other claimant -- which is exactly the loop
-            // UrlPathConflictError's doc comment exists to prevent.
+            // [URL] A contested-URL refusal needs its own message: the generic one below tells the
+            // editor to reload and retry, which can't succeed until they pick a different slug.
             const passThrough = err instanceof BranchSyncingError || err instanceof UrlPathConflictError;
             return {
                 ok: false,
@@ -613,19 +542,14 @@ const renameEntryHandler = async (gc, ctx, req, params, body) => {
                 error: passThrough ? err.message : 'Content conflict: entry was modified by another editor',
             };
         }
-        // C2: same distinction as writeContentHandler above - a ContentStoreError
-        // is an expected client fault and keeps its 400; anything else is a
-        // genuine server fault and must surface as a 500, not get mislabeled as
-        // "Rename failed" (the client's mistake).
+        // C2: same rule as writeContentHandler's catch above (ContentStoreError -> 400, everything
+        // else -> 500).
         if (err instanceof ContentStoreError) {
             return { ok: false, status: 400, error: sanitizeErrorMessage(err.message) };
         }
         throw err;
     }
 };
-// ============================================================================
-// Route Definitions with defineEndpoint
-// ============================================================================
 /**
  * Read content using path-based routing
  * GET /:branch/content/:path*

package/dist/api/entries-constants.d.ts

@@ -1,15 +1,11 @@
 /**
- * Pagination constants for the entries list endpoint.
- *
- * Kept in a dependency-free module (no server-only imports) so the editor's
- * browser bundle can import the page-size cap without pulling in `entries.ts`
- * and its `node:fs`-backed transitive deps. `entries.ts` re-exports these for
- * API-surface discoverability.
+ * Pagination constants for the entries list endpoint. Kept dependency-free (no server-only
+ * imports) so the editor's browser bundle can import the page-size cap without pulling in
+ * `entries.ts` and its `node:fs`-backed deps; `entries.ts` re-exports these for API discoverability.
  */
 /**
- * Maximum entries the list endpoint returns per request. Larger `limit` values
- * are clamped to this. Paginating clients request this page size so they never
- * silently drift from the server's cap.
+ * Maximum entries the list endpoint returns per request; larger `limit` values are clamped to
+ * this so paginating clients never silently drift from the server's cap.
  */
 export declare const MAX_ENTRIES_PER_PAGE = 200;
 /** Default page size when a request omits `limit`. */

package/dist/api/entries-constants.js

@@ -1,15 +1,11 @@
 /**
- * Pagination constants for the entries list endpoint.
- *
- * Kept in a dependency-free module (no server-only imports) so the editor's
- * browser bundle can import the page-size cap without pulling in `entries.ts`
- * and its `node:fs`-backed transitive deps. `entries.ts` re-exports these for
- * API-surface discoverability.
+ * Pagination constants for the entries list endpoint. Kept dependency-free (no server-only
+ * imports) so the editor's browser bundle can import the page-size cap without pulling in
+ * `entries.ts` and its `node:fs`-backed deps; `entries.ts` re-exports these for API discoverability.
  */
 /**
- * Maximum entries the list endpoint returns per request. Larger `limit` values
- * are clamped to this. Paginating clients request this page size so they never
- * silently drift from the server's cap.
+ * Maximum entries the list endpoint returns per request; larger `limit` values are clamped to
+ * this so paginating clients never silently drift from the server's cap.
  */
 export const MAX_ENTRIES_PER_PAGE = 200;
 /** Default page size when a request omits `limit`. */

package/dist/api/entries.d.ts

@@ -2,10 +2,10 @@ import { z } from 'zod';
 import type { ContentFormat } from '../config/index.js';
 import type { ApiResponse } from './types.js';
 import type { LogicalPath, PhysicalPath, Slug, ContentId } from '../paths/types.js';
-export { MAX_ENTRIES_PER_PAGE, DEFAULT_ENTRIES_LIMIT } from './entries-constants.js';
 /**
  * Summary of an entry type for client display.
  * Simplified from EntryTypeConfig - doesn't include full field definitions.
+ * @internal No importer; deletion candidate in knip-no-importer-deletion-candidates.md.
  */
 export interface EntryTypeSummary {
     name: string;
@@ -28,6 +28,7 @@ export interface CollectionItem {
     exists?: boolean;
     canEdit?: boolean;
 }
+/** @internal No importer; deletion candidate in knip-no-importer-deletion-candidates.md. */
 export interface ListEntriesParams {
     branch: string;
     collection?: LogicalPath;
@@ -49,6 +50,7 @@ export type EntriesResponse = ApiResponse<ListEntriesResponse>;
 /**
  * List entries for a branch
  * GET /:branch/entries
+ * @internal Exported for tests.
  */
 export declare const listEntries: import("./route-builder.js").RouteDefinition<z.ZodObject<{
     branch: z.ZodType<import("../paths/index.js").BranchName, z.ZodTypeDef, import("../paths/index.js").BranchName>;
@@ -81,21 +83,14 @@ export type DeleteEntryResponse = ApiResponse<{
     deleted: boolean;
     contentId?: string;
     /**
-     * Set when the entry itself was deleted successfully but the collection's
-     * order array could not be updated afterward (C6: order cleanup is
-     * best-effort hygiene that runs AFTER the delete, so its failure must not
-     * present as a failed delete - see content.ts's `validationWarnings` for
-     * the same "warn, don't fail" precedent on the write path). The order
-     * array still contains the now-nonexistent id until a later schema
-     * mutation cleans it up.
+     * Set when the entry deleted successfully but the collection's order array couldn't be updated
+     * afterward (C6: best-effort hygiene after the delete, so its failure must not present as a
+     * failed delete — see content.ts's `validationWarnings`). The order array keeps the
+     * now-nonexistent id until the next schema mutation cleans it up.
      */
     warning?: string;
 }>;
-/**
- * Delete an entry
- * DELETE /:branch/entries/...entryPath
- * Note: Uses catch-all to support paths with slashes (e.g., content/posts/hello-world)
- */
+/** @internal Exported for tests. */
 export declare const deleteEntry: import("./route-builder.js").RouteDefinition<z.ZodObject<{
     branch: z.ZodType<import("../paths/index.js").BranchName, z.ZodTypeDef, import("../paths/index.js").BranchName>;
     entryPath: z.ZodType<LogicalPath, z.ZodTypeDef, LogicalPath>;