canopycms 0.0.67-int.90 → 0.0.67

package/dist/schema/meta-loader.js

@@ -26,17 +26,11 @@ const entryTypeMetaSchema = z.object({
     maxItems: z.number().int().positive().optional(),
 });
 /**
- * Zod schema for .collection.json files
- *
- * A collection folder can contain:
- * - entries: Array of entry types with their own schemas
- * - collections: Nested collections (discovered via their own .collection.json files)
- *
- * Note: We can't validate `schema` against entry schema registry keys at parse time because:
- * 1. Entry schema registry is passed at runtime (not available during Zod schema definition)
- * 2. Would create circular dependency (loader → services → config → loader)
- *
- * Validation of schema references happens in resolution functions with clear error messages.
+ * Zod schema for .collection.json files. `schema` can't be validated against
+ * the entry schema registry here — the registry is only available at
+ * runtime, and checking at parse time would create a loader → services →
+ * config → loader circular dependency — so schema references are checked in
+ * the resolution functions instead, with clear error messages.
  */
 const collectionMetaSchema = z
     .object({
@@ -58,31 +52,21 @@ const rootCollectionMetaSchema = z.object({
     entries: z.array(entryTypeMetaSchema).optional(),
     order: z.array(z.string()).optional(), // Embedded IDs for ordering items
 });
+/** Extracts the slug only — e.g. "post.hello-world.{id}.md" -> "hello-world" (the entry-type prefix and extension are dropped too, not just the ID). */
+function stripEmbeddedIdFromName(name) {
+    return extractSlugFromFilename(name);
+}
 /**
- * Recursively scans a directory for .collection.json files.
- *
- * Discovery Rules:
- * - Scans recursively from the base directory (content root)
- * - Each directory can have at most ONE .collection.json file
- * - Collection path is derived from the directory structure (e.g., "docs/api" for content/docs/api/)
- * - Collection name comes from the "name" field in .collection.json, NOT the directory name
- * - Directories without .collection.json are still scanned for nested collections
- * - Invalid .collection.json files cause the entire scan to fail with a descriptive error
+ * Recursively scans a directory for .collection.json files. Each directory
+ * has at most one; a directory without one is still scanned for nested
+ * collections beneath it. A collection's name comes from `.collection.json`'s
+ * "name" field, not the directory name. An invalid file fails the whole scan
+ * with a descriptive error.
  *
  * @param baseDir - The directory to scan (absolute path)
  * @param relativePath - Current path relative to content root (used for recursion)
  * @returns Array of collection metadata with resolved paths
  */
-/**
- * Strip embedded ID from a directory or file name, leaving the slug.
- * e.g., "docs.bChqT78gcaLd" -> "docs"
- * e.g., "post.hello-world.vh2WdhwAFiSL.md" -> "hello-world" (the SLUG, not the entry type)
- * e.g., "home.index.agfzDt2RLpSn.json" -> "index"
- */
-function stripEmbeddedIdFromName(name) {
-    // Use extractSlugFromFilename which handles the ID extraction logic
-    return extractSlugFromFilename(name);
-}
 async function scanForCollectionMeta(baseDir, relativePath = '') {
     const collections = [];
     try {
@@ -91,27 +75,22 @@ async function scanForCollectionMeta(baseDir, relativePath = '') {
             if (!entry.isDirectory())
                 continue;
             const folderName = entry.name;
-            // Strip embedded ID from folder name for logical path
-            // e.g., "docs.bChqT78gcaLd" -> "docs"
             const logicalName = stripEmbeddedIdFromName(folderName);
             // Extract embedded ContentId from directory name (e.g., "posts.a1b2c3d4e5f6" → "a1b2c3d4e5f6")
             const collectionContentId = extractIdFromFilename(folderName) ?? undefined;
             const folderPath = relativePath ? `${relativePath}/${logicalName}` : logicalName;
             const absolutePath = join(baseDir, folderName);
             const metaPath = join(absolutePath, '.collection.json');
-            // Try to load collection meta file
             try {
                 await fs.access(metaPath);
                 const content = await fs.readFile(metaPath, 'utf-8');
                 const parsed = JSON.parse(content);
-                // Validate with Zod
                 const meta = collectionMetaSchema.parse(parsed);
                 collections.push({
                     ...meta,
-                    path: folderPath, // Path derived from folder name
+                    path: folderPath,
                     contentId: collectionContentId,
                 });
-                // Recursively scan for nested collection folders (they'll have their own .collection.json files)
                 const nestedCollections = await scanForCollectionMeta(absolutePath, folderPath);
                 collections.push(...nestedCollections);
             }
@@ -138,11 +117,6 @@ async function scanForCollectionMeta(baseDir, relativePath = '') {
 /**
  * Loads all .collection.json meta files from contentRoot, including root.
  *
- * This function orchestrates the complete discovery process:
- * 1. Attempts to load the root .collection.json (contentRoot/.collection.json) - optional
- * 2. Recursively scans all subdirectories for .collection.json files
- * 3. Returns both root configuration and nested collections
- *
  * Meta File Structure:
  * - Root: contentRoot/.collection.json (optional, defines root-level entry types)
  * - Collections: contentRoot/[path]/.collection.json (defines collection in that directory)
@@ -152,14 +126,12 @@ async function scanForCollectionMeta(baseDir, relativePath = '') {
  * @throws Error if any .collection.json file is malformed or invalid
  */
 export async function loadCollectionMetaFiles(contentRoot) {
-    // Load root .collection.json (optional)
     let root = null;
     const rootMetaPath = join(contentRoot, '.collection.json');
     try {
         await fs.access(rootMetaPath);
     }
     catch (err) {
-        // No root .collection.json - that's okay
         if (err.code === 'ENOENT') {
             // File doesn't exist, that's fine
         }
@@ -167,7 +139,6 @@ export async function loadCollectionMetaFiles(contentRoot) {
             throw err;
         }
     }
-    // If file exists, try to read and parse it
     try {
         const content = await fs.readFile(rootMetaPath, 'utf-8');
         const parsed = JSON.parse(content);
@@ -180,13 +151,9 @@ export async function loadCollectionMetaFiles(contentRoot) {
             throw new Error(`Invalid root .collection.json`);
         }
     }
-    // Scan for collection folders
     const collections = await scanForCollectionMeta(contentRoot);
     return { root, collections };
 }
-/**
- * Resolve schema references for entry types
- */
 function resolveEntryTypes(entryTypes, entrySchemaRegistry, contextName) {
     return entryTypes.map((entryType) => {
         const resolvedSchema = entrySchemaRegistry[entryType.schema];
@@ -208,11 +175,7 @@ function resolveEntryTypes(entryTypes, entrySchemaRegistry, contextName) {
         };
     });
 }
-/**
- * Resolve schema references for a single collection
- */
 function resolveCollectionMeta(meta, entrySchemaRegistry, allCollections) {
-    // Resolve entry types
     const entries = meta.entries && meta.entries.length > 0
         ? resolveEntryTypes(meta.entries, entrySchemaRegistry, `collection "${meta.name}"`)
         : undefined;
@@ -240,11 +203,6 @@ function resolveCollectionMeta(meta, entrySchemaRegistry, allCollections) {
  * This function takes the loaded meta files (which contain string references like "postSchema")
  * and resolves them to actual EntrySchema arrays from the entry schema registry.
  *
- * Resolution Process:
- * 1. Root entry types: Resolve "schema" string to entry schema registry lookup
- * 2. Top-level collections: Resolve recursively, building nested tree structure
- * 3. Nested collections: Automatically grouped under their parent collections
- *
  * @param metaFiles - Loaded meta files from loadCollectionMetaFiles()
  * @param entrySchemaRegistry - Map of schema names to EntrySchema arrays
  * @returns Fully resolved root collection config ready for use by CanopyCMS
@@ -253,15 +211,12 @@ function resolveCollectionMeta(meta, entrySchemaRegistry, allCollections) {
 export function resolveCollectionReferences(metaFiles, entrySchemaRegistry) {
     // Build result object dynamically to avoid readonly conflicts
     const result = {};
-    // Pass through root label if present
     if (metaFiles.root?.label) {
         result.label = metaFiles.root.label;
     }
-    // Resolve root entry types
     if (metaFiles.root?.entries && metaFiles.root.entries.length > 0) {
         result.entries = resolveEntryTypes(metaFiles.root.entries, entrySchemaRegistry, 'root collection');
     }
-    // Pass through root order array (embedded IDs for sorting)
     if (metaFiles.root?.order) {
         result.order = metaFiles.root.order;
     }
@@ -272,9 +227,6 @@ export function resolveCollectionReferences(metaFiles, entrySchemaRegistry) {
     }
     return result;
 }
-/**
- * Watch for changes to .collection.json files
- */
 export function watchCollectionMetaFiles(contentRoot, onChange) {
     const watcher = chokidar.watch(`${contentRoot}/**/.collection.json`, {
         ignoreInitial: true,
@@ -284,6 +236,5 @@ export function watchCollectionMetaFiles(contentRoot, onChange) {
     watcher.on('unlink', onChange);
     // Handle watcher errors (e.g. inotify ENOSPC/EMFILE) so an unhandled 'error' event can't crash dev.
     watcher.on('error', (err) => canopyLogWarn(`CanopyCMS: .collection.json watcher error: ${getErrorMessage(err)}`));
-    // Return cleanup function
     return () => watcher.close();
 }

package/dist/schema/resolver.d.ts

@@ -12,10 +12,6 @@ import type { EntrySchemaRegistry, SchemaResolutionResult } from './types.js';
 /**
  * Resolve schema from .collection.json files.
  *
- * This is the primary entry point for loading schema configuration.
- * It discovers all .collection.json files in the content directory
- * and resolves schema references using the provided registry.
- *
  * @param contentRoot - Path to the content directory
  * @param entrySchemaRegistry - Map of entry schema names to field definitions
  * @returns Resolved schema configuration
@@ -27,6 +23,7 @@ export declare function resolveSchema(contentRoot: string, entrySchemaRegistry:
  *
  * @param contentRoot - Path to the content directory
  * @returns true if at least one .collection.json file exists
+ * @internal No importer; deletion candidate in knip-no-importer-deletion-candidates.md.
  */
 export declare function hasSchemaFiles(contentRoot: string): Promise<boolean>;
 /**

package/dist/schema/resolver.js

@@ -11,17 +11,12 @@ import { loadCollectionMetaFiles, resolveCollectionReferences } from './meta-loa
 /**
  * Resolve schema from .collection.json files.
  *
- * This is the primary entry point for loading schema configuration.
- * It discovers all .collection.json files in the content directory
- * and resolves schema references using the provided registry.
- *
  * @param contentRoot - Path to the content directory
  * @param entrySchemaRegistry - Map of entry schema names to field definitions
  * @returns Resolved schema configuration
  * @throws Error if schema references cannot be resolved
  */
 export async function resolveSchema(contentRoot, entrySchemaRegistry) {
-    // Load all .collection.json meta files
     const metaFiles = await loadCollectionMetaFiles(contentRoot);
     // Build source info for debugging
     const sources = [];
@@ -39,7 +34,6 @@ export async function resolveSchema(contentRoot, entrySchemaRegistry) {
             collections: [collection.name],
         });
     }
-    // Resolve schema references to actual field definitions
     const schema = resolveCollectionReferences(metaFiles, entrySchemaRegistry);
     return { schema, sources };
 }
@@ -48,6 +42,7 @@ export async function resolveSchema(contentRoot, entrySchemaRegistry) {
  *
  * @param contentRoot - Path to the content directory
  * @returns true if at least one .collection.json file exists
+ * @internal No importer; deletion candidate in knip-no-importer-deletion-candidates.md.
  */
 export async function hasSchemaFiles(contentRoot) {
     const metaFiles = await loadCollectionMetaFiles(contentRoot);

package/dist/schema/schema-store-types.d.ts

@@ -6,18 +6,12 @@
  */
 import type { ContentFormat } from '../config/index.js';
 import type { LogicalPath } from '../paths/types.js';
-/**
- * Input for creating a new collection
- */
 export interface CreateCollectionInput {
     name: string;
     label?: string;
     parentPath?: LogicalPath;
     entries: CreateEntryTypeInput[];
 }
-/**
- * Input for creating a new entry type
- */
 export interface CreateEntryTypeInput {
     name: string;
     label?: string;
@@ -26,18 +20,12 @@ export interface CreateEntryTypeInput {
     default?: boolean;
     maxItems?: number;
 }
-/**
- * Input for updating a collection
- */
 export interface UpdateCollectionInput {
     name?: string;
     label?: string;
     slug?: string;
     order?: string[];
 }
-/**
- * Input for updating an entry type
- */
 export interface UpdateEntryTypeInput {
     label?: string;
     format?: ContentFormat;

package/dist/schema/schema-store.d.ts

@@ -1,47 +1,32 @@
 /**
  * Schema Store - handles reading and writing .collection.json files.
- *
- * This module provides CRUD operations for collection schema metadata:
- * - Create/update/delete collections
- * - Add/update/remove entry types
- * - Update ordering of items within collections
- *
  * All mutations are branch-specific (like content edits).
  *
  * ## Concurrency
  *
- * `.collection.json` is read-modify-written by every mutator below, and is
- * mutated cross-host: two warm Lambda containers (or a Lambda + the EC2
- * worker) on EFS can both read the same pre-mutation file and have the
- * second write silently clobber the first. This deviates from the standard
- * 3-layer recipe in docs/concurrency.md in one deliberate way: NO OCC
- * `version`/`writeId` fields go into `.collection.json` itself, and no
- * lockfile lives in the content tree. Two reasons:
+ * `.collection.json` is read-modify-written by every mutator below and
+ * mutated cross-host — two warm Lambdas, or a Lambda + the EC2 worker, on
+ * EFS can both read the same pre-mutation file and clobber each other's
+ * write. This deviates from the standard 3-layer recipe in
+ * docs/concurrency.md: no OCC `version`/`writeId` field goes into
+ * `.collection.json` itself, and no lockfile lives in the content tree —
+ * both are adopter-visible, git-committed files, so a rebase would make a
+ * version counter meaningless and a crash-leftover lockfile would land in a
+ * commit an adopter reviews.
  *
- * - `.collection.json` is an adopter-visible, git-committed content file.
- *   Rebases rewrite it wholesale from upstream, so a `version` counter would
- *   be meaningless (and actively misleading) the moment a rebase lands.
- * - A lockfile crash-leftover inside the content tree would be swept into
- *   `git add .` at publish time — a `.lock` or `.tmp` file has no business
- *   ending up in a commit an adopter reviews.
+ * Protection is instead layer 1 ({@link withLock}) + layer 3
+ * ({@link withOccFileLock}) on one COARSE per-branch SURROGATE lock path
+ * OUTSIDE the content tree (`{branchRoot}/.canopy-meta/schema`, see
+ * `withSchemaLock`), covering every schema mutation on the branch including
+ * multi-file ones. Layer 2 (OCC read-back) is skipped, since there's no
+ * version field to check; layer 4 (generation marker) guards the schema
+ * CACHE separately, not this write path.
  *
- * Protection is instead: layer 1 ({@link withLock}) + layer 3
- * ({@link withOccFileLock}) on a single COARSE per-branch SURROGATE lock
- * path OUTSIDE the content tree — `{branchRoot}/.canopy-meta/schema` (see
- * `withSchemaLock`). One lock covers every schema mutation on the branch,
- * including multi-file mutations (`createCollection` writes the new child's
- * meta AND the parent's). Layer 2 (OCC read-back) is skipped entirely since
- * there is no version field to check; layer 4 (generation marker) is used
- * separately, for the schema CACHE, not for this write path.
- *
- * Accepted residual: `deleteBranch` does NOT take this lock before its
- * recursive `rm` — an in-flight schema write can race a concurrent branch
- * deletion (the write's `rm`/rename can hit ENOTEMPTY or land in a
- * half-deleted tree). This mirrors the same residual documented on
- * `BranchMetadataFileManager.save()` in branch-metadata.ts and is not closed
- * here either; see `withSchemaLock`'s doc comment for the phantom-guard that
- * IS in place for the common ordering (branch already gone before this call
- * ever starts).
+ * Accepted residual: `deleteBranch` does not take this lock before its
+ * recursive `rm`, so an in-flight write can race a concurrent branch
+ * deletion (mirrors the residual on `BranchMetadataFileManager.save()` in
+ * branch-metadata.ts) — see `withSchemaLock`'s doc for the phantom-guard
+ * covering the common ordering instead.
  */
 import { z } from 'zod';
 import type { ContentFormat } from '../config/index.js';
@@ -219,43 +204,35 @@ export declare class SchemaOps {
     constructor(contentRoot: string, entrySchemaRegistry: EntrySchemaRegistry, services?: CanopyServices | undefined, branchRoot?: string);
     /**
      * Serialize an entire read-modify-write schema mutation behind the coarse
-     * per-branch surrogate lock described in the module doc comment. Layers,
-     * outermost to innermost (same structure as
-     * `BranchMetadataFileManager.save()` — see branch-metadata.ts):
-     *
-     * 1. {@link withLock} — in-process FIFO mutex, deterministic same-process
-     *    serialization.
-     * 2. {@link withOccFileLock} — server-enforced, cross-process/cross-host
-     *    mutual exclusion (proper-lockfile, mkdir-based), immune to NFS client
-     *    dentry/attribute caching.
+     * per-branch surrogate lock described in the module doc comment: layer 1
+     * ({@link withLock}, in-process FIFO mutex) wraps layer 3
+     * ({@link withOccFileLock}, cross-process/cross-host mkdir-based mutual
+     * exclusion, immune to NFS attribute caching), same structure as
+     * `BranchMetadataFileManager.save()` in branch-metadata.ts.
      *
-     * NOT re-entrant: callers must never invoke this (directly or via a public
-     * mutator) from inside a callback already running under it — `withLock`
-     * would deadlock waiting on itself. This is why `updateOrderInner` calls
-     * `updateCollectionInner` directly instead of the public `updateCollection`.
+     * NOT re-entrant — callers must never invoke this from inside a callback
+     * already running under it, or `withLock` deadlocks waiting on itself;
+     * that's why `updateOrderInner` calls `updateCollectionInner` directly
+     * instead of the public `updateCollection`.
      *
      * Phantom-resurrection guard: `branchRoot` can be removed by a concurrent
      * `deleteBranch` between the caller resolving its BranchContext and this
-     * call reaching its own lock acquisition. `withOccFileLock`'s own
-     * `mkdir({recursive:true})` on the lock directory would otherwise silently
-     * recreate `.canopy-meta/` inside a directory tree that no longer exists
-     * anywhere else. Checking BEFORE the lock (not after) fails fast without
-     * paying for an acquisition on a doomed mutation.
-     *
-     * Residual window (accepted, same shape as branch-metadata.ts's): a call
-     * that passes this check can still race a `deleteBranch` `rm` that starts
-     * moments later and is still mid-flight when this call's write lands,
-     * resurrecting the tree. `deleteBranch` does not take this lock at all
-     * (see the module doc comment), so that race is not closed here either.
+     * call's own lock acquisition, which would otherwise let
+     * `withOccFileLock`'s `mkdir({recursive:true})` silently recreate
+     * `.canopy-meta/` in an otherwise-deleted tree. Checking BEFORE the lock
+     * fails fast instead. Residual (accepted, same shape as
+     * branch-metadata.ts's): a call that passes this check can still race a
+     * `deleteBranch` `rm` starting moments later — not closed here either,
+     * since `deleteBranch` never takes this lock (see the module doc comment).
      *
      * Translation happens ONLY at this boundary: inner code always sees the
-     * raw {@link OccWriteConflictError} bubble up to here (never catches or
-     * re-translates it itself).
+     * raw {@link OccWriteConflictError} bubble up here untranslated.
      */
     private withSchemaLock;
     /**
      * Invalidate schema cache for this branch after mutations, then eagerly
-     * re-resolve on THIS host.
+     * re-resolve on THIS host. Every mutator calls this after `withSchemaLock`
+     * has returned, never inside the critical section.
      *
      * The eager re-resolve is the durable-snapshot window-E mitigation (see
      * BranchSchemaCache's class docs): the mutating host's own scan is
@@ -296,92 +273,50 @@ export declare class SchemaOps {
     private invalidateContentIdIndexes;
     /**
      * The single normalisation boundary for logical collection paths entering
-     * this class. Every public method that accepts a logical collection path
-     * (or, for `createCollection`, `input.parentPath`) calls this exactly once
-     * before doing anything else with the path — that is the whole fix for the
-     * "Collection not found" bug: `flattenSchema` (branch-schema-cache.ts)
-     * produces content-root-prefixed logical paths (e.g. "content/posts", or
-     * "cms/content/posts" for a multi-segment `contentRoot: 'cms/content'`),
-     * the editor round-trips those straight back into every mutator
-     * (`CollectionEditor.tsx` passes `editingCollection.logicalPath` as-is),
-     * but `resolveCollectionPath(this.contentRoot, ...)` treats its second
-     * argument as relative to `this.contentRoot` — which already embeds the
-     * content-root segment(s). A prefixed path therefore resolved one level
-     * too deep and was reported as not found. `updateCollectionInner` used to
-     * strip the prefix itself (the only mutator that did); that bespoke strip
-     * is gone now that every entry point normalises here instead.
+     * this class. Every public method that accepts one calls this exactly
+     * once, before touching the path: `flattenSchema` (branch-schema-cache.ts)
+     * produces content-root-prefixed logical paths (e.g. "content/posts") that
+     * the editor round-trips straight back into every mutator, but
+     * `resolveCollectionPath` treats its path argument as already relative to
+     * `this.contentRoot` — without stripping, a prefixed path resolves one
+     * level too deep and is reported as not found.
      *
-     * Prefix-only: strips ONE leading `"{contentRootName}/"` if present (exact
-     * string match against the full, possibly multi-segment, `contentRootName`
-     * — never `path.basename()`, which would break a multi-segment root like
-     * "cms/content"), otherwise returns the path unchanged. So both prefixed
-     * (production/editor) and unprefixed (existing store tests, adopters
-     * calling SchemaOps directly) input work. Deliberately does NOT touch the
-     * bare root-collection sentinel (`collectionPath === this.contentRootName`,
-     * no trailing segment): that has no trailing "/" to match, so it passes
-     * through unchanged and the `=== this.contentRootName` checks in
+     * Strips ONE leading `"{contentRootName}/"` if present — exact string
+     * match against the full, possibly multi-segment, `contentRootName`, never
+     * `path.basename()` (which would break a root like "cms/content") —
+     * otherwise returns the path unchanged, so both prefixed and unprefixed
+     * callers work. Leaves the bare root-collection sentinel
+     * (`collectionPath === this.contentRootName`) untouched: it has no
+     * trailing "/" to strip, so the `=== this.contentRootName` checks in
      * `updateCollectionInner`/`updateOrderInner` keep working.
      *
-     * CALL EXACTLY ONCE PER ENTRY POINT — it is NOT idempotent, and an earlier
-     * version of this comment claimed it was. A sub-collection literally named
-     * after the content root defeats the "already normalised" reasoning: with
-     * `contentRoot: 'content'`, "content/content/x" normalises to "content/x"
-     * and again to "x", and "content/content" normalises to "content", which
-     * the `=== this.contentRootName` checks above then treat as the ROOT
-     * collection — so a second call mutates a DIFFERENT collection rather than
-     * reporting not-found. Every entry point calls this exactly once today, so
-     * the ambiguity is unreachable; removing it needs the editor to send an
-     * unambiguously-scoped path, tracked in
-     * .claude/future-tasks/collection-path-content-root-ambiguity.md.
-     *
-     * A future public method that accepts a logical collection path must call
-     * this first, and only once, the same way every existing one does — that is
-     * the "safe by construction" contract this boundary is meant to provide.
+     * NOT idempotent — a sub-collection literally named after the content
+     * root can re-normalise to the ROOT collection on a second call, mutating
+     * the wrong one instead of reporting not-found. Every entry point calls
+     * this exactly once today, so the ambiguity is unreachable; see
+     * .claude/future-tasks/collection-path-content-root-ambiguity.md. A future
+     * method that accepts a logical collection path must do the same.
      */
     private normalizeCollectionPath;
-    /**
-     * Validate that a schema reference exists in the registry
-     */
     validateSchemaReference(schemaKey: string): boolean;
-    /**
-     * Validate all schema references in entry types
-     */
     private validateEntryTypeSchemas;
     /**
      * Validate path to prevent traversal attacks
      */
     private validatePath;
-    /**
-     * Read a collection's .collection.json file
-     */
     readCollectionMeta(collectionPath: LogicalPath): Promise<CollectionMetaFile | null>;
-    /**
-     * Read root collection meta (content/.collection.json)
-     */
     readRootCollectionMeta(): Promise<RootCollectionMetaFile | null>;
     /**
      * Check if a collection is empty (has no content files or child collections)
      */
     isCollectionEmpty(collectionPath: LogicalPath): Promise<boolean>;
-    /**
-     * Write a collection's .collection.json file
-     */
     private writeCollectionMeta;
-    /**
-     * Write root collection meta
-     */
     private writeRootCollectionMeta;
-    /**
-     * Create a new collection
-     */
     createCollection(input: CreateCollectionInput): Promise<{
         collectionPath: LogicalPath;
         contentId: ContentId;
     }>;
     private createCollectionInner;
-    /**
-     * Update a collection's metadata
-     */
     updateCollection(collectionPath: LogicalPath, updates: UpdateCollectionInput): Promise<void>;
     /**
      * Body of updateCollection, holding the schema lock for its full
@@ -401,24 +336,15 @@ export declare class SchemaOps {
      */
     deleteCollection(collectionPath: LogicalPath): Promise<void>;
     private deleteCollectionInner;
-    /**
-     * Add an entry type to a collection
-     */
     addEntryType(collectionPath: LogicalPath, entryType: CreateEntryTypeInput): Promise<void>;
     private addEntryTypeInner;
-    /**
-     * Update an entry type in a collection
-     */
     updateEntryType(collectionPath: LogicalPath, entryTypeName: string, updates: UpdateEntryTypeInput): Promise<void>;
     private updateEntryTypeInner;
-    /**
-     * Remove an entry type from a collection
-     */
     removeEntryType(collectionPath: LogicalPath, entryTypeName: string): Promise<void>;
     private removeEntryTypeInner;
     /**
      * Count the number of entries using a specific entry type in a collection.
-     * This is used to prevent breaking changes to entry types that have existing content.
+     * Prevents breaking changes to entry types that have existing content.
      *
      * @param collectionPath - Logical path to the collection (e.g., "content/posts")
      * @param entryTypeName - Name of the entry type to count
@@ -433,9 +359,6 @@ export declare class SchemaOps {
      * ```
      */
     countEntriesUsingType(collectionPath: LogicalPath, entryTypeName: string): Promise<number>;
-    /**
-     * Update the order of items in a collection
-     */
     updateOrder(collectionPath: LogicalPath, order: string[]): Promise<void>;
     private updateOrderInner;
 }