@happyvertical/smrt-core 0.51.31 → 0.51.33

package/dist/polymorphic-association.d.ts

@@ -1,4 +1,47 @@
-import { SmrtObject, SmrtObjectOptions } from './object';
+/**
+ * SmrtPolymorphicAssociation — base class for polymorphic association rows.
+ *
+ * A polymorphic association links an owner row to an arbitrary target
+ * SmrtObject identified by a `(metaType, metaId)` pair — `metaType` being the
+ * target's qualified class name (e.g. `@happyvertical/smrt-content:Article`)
+ * and `metaId` its row id. Pair that with a `role` discriminator and a
+ * `sortOrder`, and one join table can reference many different target types
+ * without a typed foreign key per type.
+ *
+ * Subclasses add their own "owner" side and decorate with `@smrt()`:
+ *
+ * ```typescript
+ * @smrt({ conflictColumns: ['asset_id', 'meta_type', 'meta_id', 'role'] })
+ * export class AssetAssociation extends SmrtPolymorphicAssociation {
+ *   @foreignKey('Asset', { required: true })
+ *   assetId = '';
+ * }
+ *
+ * const target = await association.hydrate(); // resolves metaType + loads metaId
+ * ```
+ *
+ * Convention: `metaId` is intentionally a bare string, NOT a typed
+ * `@foreignKey` / `@crossPackageRef` — it is polymorphic, so there is no
+ * single target table to point at. `metaType` carries the type information
+ * instead, resolved at runtime via `ObjectRegistry`.
+ *
+ * This is an abstract framework base in the same family as
+ * `SmrtHierarchical` and `SmrtJunction`: it has no `@smrt()` decorator and no
+ * table of its own. Its columns are merged into each concrete subclass's
+ * manifest by the scanner's `FRAMEWORK_BASE_CLASSES` /
+ * `FRAMEWORK_ABSTRACT_BASE_NAMES` wiring. Keep those two lists in sync when
+ * touching this class.
+ *
+ * @example
+ * ```typescript
+ * @smrt({ conflictColumns: ['owner_id', 'meta_type', 'meta_id', 'role'] })
+ * export class CommentAssociation extends SmrtPolymorphicAssociation {
+ *   @foreignKey('Comment', { required: true })
+ *   ownerId = '';
+ * }
+ * ```
+ */
+import { SmrtObject, type SmrtObjectOptions } from './object';
 /**
  * Options accepted by `SmrtPolymorphicAssociation` (and its subclasses)
  * covering the polymorphic right side of the join.

package/dist/postgres-permissions.d.ts

@@ -1,4 +1,4 @@
-import { DatabaseInterface } from '@happyvertical/sql';
+import type { DatabaseInterface } from '@happyvertical/sql';
 /** PostgreSQL ACLs only; this is not application authorization or RLS. */
 export interface PostgresPermissionContract {
     schema: string;

package/dist/prebuild/index.d.ts

@@ -1,4 +1,8 @@
-import { SmartObjectManifest } from '../scanner/types';
+/**
+ * Pre-build utilities for generating TypeScript declarations
+ * Solves virtual module resolution by creating physical .d.ts files
+ */
+import type { SmartObjectManifest } from '../scanner/types';
 export interface PrebuildOptions {
     /** Path to manifest file or manifest object */
     manifest: string | SmartObjectManifest;

package/dist/query-bounds.d.ts

@@ -1,3 +1,29 @@
+/**
+ * Query bounds for list surfaces (#2367).
+ *
+ * Every generated read surface — REST, SvelteKit routes, the MCP server and the
+ * MCP runtime bootstrap — takes `limit`/`offset` straight from untrusted input.
+ * Before this module each one parsed them by hand, and each got it wrong in a
+ * different way: `Number.parseInt('abc')` produced `LIMIT NaN` (a 500 from the
+ * driver, not a 400 from the API), `Number(x) || 50` silently turned `0` into
+ * `50`, and none of them capped the value, so `?limit=100000000` was a
+ * single-request table scan on every generated endpoint.
+ *
+ * This is the one parser they all share. It is deliberately strict on the input
+ * (a bound is a non-negative integer or it is a client error) and deliberately
+ * forgiving on magnitude (an oversized page is clamped, not rejected, so a
+ * caller paging with a too-large window still makes progress instead of
+ * receiving an error it cannot act on).
+ *
+ * The bounds themselves are also available to `SmrtCollection.list()` through
+ * the `defaultListLimit` / `maxListLimit` collection options. Those are opt-in:
+ * `list()` is the framework's own bulk-read primitive and dozens of internal
+ * callers (relationship loaders, junction hydration, `listByIds`) legitimately
+ * expect every matching row, so a framework-wide implicit default would
+ * silently truncate results rather than bound an attack surface. The bound
+ * belongs where untrusted input arrives, which is why the generated surfaces
+ * apply it unconditionally and direct programmatic callers opt in.
+ */
 import { ValidationError } from './errors';
 /**
  * Page size a generated list surface uses when the caller supplies none.

package/dist/registry/cache-config.d.ts

@@ -1,4 +1,13 @@
-import { CollectionCacheConfig } from '../collection-cache';
+/**
+ * Collection read-cache configuration resolution for the SMRT ObjectRegistry.
+ *
+ * Resolves the effective `@smrt({ cache })` config for a class, walking the
+ * inheritance chain so an STI base class opt-in covers its children while a
+ * child can still opt out with `cache: false`.
+ *
+ * @see https://github.com/happyvertical/smrt/issues/1498
+ */
+import type { CollectionCacheConfig } from '../collection-cache';
 /**
  * Resolve the effective collection cache config for a class.
  *

package/dist/registry/class-registration.d.ts

@@ -1,6 +1,14 @@
+/**
+ * Class registration module for the SMRT ObjectRegistry.
+ *
+ * Handles registering classes, collections, and manifest entries.
+ *
+ * Extracted from registry.ts as part of issue #1006.
+ * @see https://github.com/happyvertical/smrt/issues/1006
+ */
 import { SmrtObject } from '../object';
-import { SmartObjectDefinition } from '../scanner/types.js';
-import { RegisteredClass, RegisteredField, SmartObjectConfig } from './types.js';
+import type { SmartObjectDefinition } from '../scanner/types.js';
+import type { RegisteredClass, RegisteredField, SmartObjectConfig } from './types.js';
 /**
  * Shared bundled-context detector. Source files in these output
  * directories come from a bundler (Vite library mode, webpack, Next.js,

package/dist/registry/collection-resolution.d.ts

@@ -1,4 +1,4 @@
-import { RegisteredClass } from './types';
+import type { RegisteredClass } from './types';
 export interface CollectionRegistrationLookup {
     findClass: (name: string) => RegisteredClass | undefined;
     findClassInPackage?: (packageName: string, className: string) => RegisteredClass | undefined;

package/dist/registry/embedding-manager.d.ts

@@ -1,4 +1,12 @@
-import { ClassEmbeddingConfig, ProjectEmbeddingConfig, ResolvedEmbeddingConfig } from '../embeddings/types';
+/**
+ * Embedding configuration management for the SMRT ObjectRegistry.
+ *
+ * Handles class-level and project-level embedding config resolution.
+ *
+ * Extracted from registry.ts as part of issue #1006.
+ * @see https://github.com/happyvertical/smrt/issues/1006
+ */
+import type { ClassEmbeddingConfig, ProjectEmbeddingConfig, ResolvedEmbeddingConfig } from '../embeddings/types';
 /**
  * Get embedding configuration for a class.
  */

package/dist/registry/inheritance-resolver.d.ts

@@ -1,6 +1,11 @@
-import { SmrtObject } from '../object';
-import { MethodDefinition } from '../scanner/types.js';
-import { RegisteredField } from './types';
+/**
+ * Inheritance resolution module for the SMRT ObjectRegistry.
+ *
+ * Extracted from registry.ts as part of issue #1006.
+ */
+import type { SmrtObject } from '../object';
+import type { MethodDefinition } from '../scanner/types.js';
+import type { RegisteredField } from './types';
 /**
  * Runtime field shape merged across an inheritance chain.
  *

package/dist/registry/manifest-field-merge.d.ts

@@ -1,5 +1,5 @@
-import { FieldDefinition } from '../scanner/types.js';
-import { RegisteredField } from './types';
+import type { FieldDefinition } from '../scanner/types.js';
+import type { RegisteredField } from './types';
 /**
  * Manifest-sourced field input handled by the merge helpers.
  *

package/dist/registry/name-resolver.d.ts

@@ -1,5 +1,25 @@
-import { QualifiedClassName, SmrtVisibility } from '../scanner/types.js';
-import { RegisteredClass, SmrtObjectConstructor } from './types';
+/**
+ * Name resolution module for the SMRT ObjectRegistry.
+ *
+ * Handles class lookup, disambiguation, and qualified name resolution.
+ * All functions operate on the shared globalThis state.
+ *
+ * Release B (#1133): classNameMap is gone — the eagerly-maintained
+ * lowercase-simple-name → qualified-key[] index was removed in favor of
+ * on-demand iteration over the `classes` Map. Production SMRT apps carry
+ * a few hundred classes at most, so the linear scan is negligible and
+ * removes an entire class of cache-sync bugs (#584, #847, #951).
+ *
+ * #3047: hydration resolves names per row, so the scan now runs once per
+ * registry generation into a derived (never hand-maintained) index; see
+ * `getSimpleNameIndex()` and `registry/generation.ts`.
+ *
+ * Extracted from registry.ts as part of issue #1006.
+ * @see https://github.com/happyvertical/smrt/issues/1006
+ * @see https://github.com/happyvertical/smrt/issues/1133
+ */
+import type { QualifiedClassName, SmrtVisibility } from '../scanner/types.js';
+import type { RegisteredClass, SmrtObjectConstructor } from './types';
 /**
  * Check if a class is already registered (case-insensitive).
  * Returns the canonical name if found, undefined otherwise. Returns

package/dist/registry/relationship-graph.d.ts

@@ -1,4 +1,12 @@
-import { RelationshipMetadata } from './types';
+/**
+ * Relationship graph and dependency resolution module for the SMRT ObjectRegistry.
+ *
+ * Builds relationship maps and dependency graphs from registered class fields.
+ *
+ * Extracted from registry.ts as part of issue #1006.
+ * @see https://github.com/happyvertical/smrt/issues/1006
+ */
+import type { RelationshipMetadata } from './types';
 /** Canonical target of the field's declaring class, including inherited fields. */
 export declare function resolveRelationshipTarget(className: string, fieldName: string): string | null | undefined;
 /**

package/dist/registry/schema-builder.d.ts

@@ -1,6 +1,11 @@
-import { FieldDefinition } from '../scanner/types.js';
-import { DatabaseEngine } from '../schema/ddl/types.js';
-import { ColumnDefinition, SchemaDefinition, SQLDataType } from '../schema/types.js';
+/**
+ * Schema building logic for the SMRT ObjectRegistry.
+ *
+ * Extracted from registry.ts as part of issue #1006.
+ */
+import type { FieldDefinition } from '../scanner/types.js';
+import type { DatabaseEngine } from '../schema/ddl/types.js';
+import type { ColumnDefinition, SchemaDefinition, SQLDataType } from '../schema/types.js';
 /**
  * Get cached schema definition for a registered class
  *

package/dist/registry/shared-state.d.ts

@@ -1,6 +1,16 @@
-import { SmrtCollection } from '../collection';
+/**
+ * Shared state accessors for the SMRT ObjectRegistry.
+ *
+ * All registry sub-modules share state via globalThis to ensure
+ * cross-module consistency in monorepo environments.
+ *
+ * Extracted from registry.ts as part of issue #1006.
+ * @see https://github.com/happyvertical/smrt/issues/1006
+ * @see https://github.com/happyvertical/smrt/issues/543
+ */
+import type { SmrtCollection } from '../collection';
 import { LRUCache } from '../utils/lru-cache';
-import { RegisteredClass, SmrtObjectConstructor } from './types';
+import type { RegisteredClass, SmrtObjectConstructor } from './types';
 declare global {
     var __smrtRegistryClasses: Map<string, RegisteredClass> | undefined;
     var __smrtRegistryCollections: Map<string, typeof SmrtCollection> | undefined;

package/dist/registry/types.d.ts

@@ -1,10 +1,18 @@
-import { CapabilityEffect, DomainKnowledgeConfig } from '@happyvertical/smrt-types';
-import { SmrtCollection } from '../collection';
-import { CollectionCacheConfig } from '../collection-cache';
-import { FieldOptions } from '../decorators/index.js';
-import { SmrtObject } from '../object';
-import { FieldDefinition, FieldMeta, MethodDefinition, QualifiedClassName, SmartObjectManifest, SmrtVisibility, ValidationRule } from '../scanner/types.js';
-import { DeclaredIndexDefinition, SchemaDefinition } from '../schema/types.js';
+/**
+ * Type definitions for the SMRT ObjectRegistry.
+ *
+ * Extracted from registry.ts as part of issue #1006
+ * (Split ObjectRegistry into focused modules).
+ *
+ * @see https://github.com/happyvertical/smrt/issues/1006
+ */
+import type { CapabilityEffect, DomainKnowledgeConfig } from '@happyvertical/smrt-types';
+import type { SmrtCollection } from '../collection';
+import type { CollectionCacheConfig } from '../collection-cache';
+import type { FieldOptions } from '../decorators/index.js';
+import type { SmrtObject } from '../object';
+import type { FieldDefinition, FieldMeta, MethodDefinition, QualifiedClassName, SmartObjectManifest, SmrtVisibility, ValidationRule } from '../scanner/types.js';
+import type { DeclaredIndexDefinition, SchemaDefinition } from '../schema/types.js';
 /**
  * Type for any constructor function that extends SmrtObject.
  * Used for WeakMap keys where we need to accept any subclass constructor.

package/dist/registry/validator.d.ts

@@ -1,5 +1,13 @@
-import { FieldDefinition } from '../scanner/types.js';
-import { ValidatorFunction } from './types';
+/**
+ * Validator module for the SMRT ObjectRegistry.
+ *
+ * Compiles validation functions from field definitions for runtime use.
+ *
+ * Extracted from registry.ts as part of issue #1006.
+ * @see https://github.com/happyvertical/smrt/issues/1006
+ */
+import type { FieldDefinition } from '../scanner/types.js';
+import type { ValidatorFunction } from './types';
 export declare function isBatchSafeValidator(validator: ValidatorFunction): boolean;
 /**
  * Compile validation functions from field definitions.

package/dist/registry.d.ts

@@ -1,14 +1,43 @@
-import { SmrtCollection, SmrtCollectionOptions } from './collection';
-import { CollectionCacheConfig } from './collection-cache';
-import { FieldOptions, MethodOptions } from './decorators/index.js';
-import { ClassEmbeddingConfig, ProjectEmbeddingConfig, ResolvedEmbeddingConfig } from './embeddings/types';
-import { ValidationError } from './errors';
-import { SmrtObject } from './object';
-import { RegistryDiagnostic } from './registry/diagnostics';
-import { RegisteredClass, RegisteredField, RelationshipMetadata, SmartObjectConfig, SmrtObjectConstructor, ValidatorFunction } from './registry/types';
-import { MethodDefinition, QualifiedClassName, SmartObjectDefinition, SmartObjectManifest, SmrtVisibility, ValidationRule } from './scanner/types.js';
-import { DatabaseEngine } from './schema/ddl/types.js';
-import { SchemaDefinition } from './schema/types.js';
+/**
+ * Global object registry for SMRT classes
+ *
+ * Maintains a central registry of all @smrt decorated classes, enabling
+ * module awareness, automatic API generation, and runtime introspection.
+ * The registry tracks class definitions, field metadata, and configuration
+ * options for code generation and runtime operations.
+ *
+ * @example Registering a class manually
+ * ```typescript
+ * import { ObjectRegistry } from '@happyvertical/smrt-core';
+ *
+ * ObjectRegistry.register(MyClass, {
+ *   api: { exclude: ['delete'] },
+ *   cli: true
+ * });
+ * ```
+ *
+ * @example Using the decorator (recommended)
+ * ```typescript
+ * import { smrt, field } from '@happyvertical/smrt-core';
+ *
+ * @smrt({ api: { exclude: ['delete'] } })
+ * class Product extends SmrtObject {
+ *   @field({ required: true })
+ *   name: string = '';
+ * }
+ * ```
+ */
+import { SmrtCollection, type SmrtCollectionOptions } from './collection';
+import type { CollectionCacheConfig } from './collection-cache';
+import type { FieldOptions, MethodOptions } from './decorators/index.js';
+import type { ClassEmbeddingConfig, ProjectEmbeddingConfig, ResolvedEmbeddingConfig } from './embeddings/types';
+import type { ValidationError } from './errors';
+import type { SmrtObject } from './object';
+import { type RegistryDiagnostic } from './registry/diagnostics';
+import type { RegisteredClass, RegisteredField, RelationshipMetadata, SmartObjectConfig, SmrtObjectConstructor, ValidatorFunction } from './registry/types';
+import type { MethodDefinition, QualifiedClassName, SmartObjectDefinition, SmartObjectManifest, SmrtVisibility, ValidationRule } from './scanner/types.js';
+import type { DatabaseEngine } from './schema/ddl/types.js';
+import type { SchemaDefinition } from './schema/types.js';
 export { isSmrtCollectionExtendsName, SMRT_COLLECTION_BASE_NAMES, } from './registry/collection-resolution';
 export { isFrameworkBaseClass } from './registry/framework-base-classes';
 export type { RelationshipMetadata, RelationshipType, SmartObjectConfig, } from './registry/types';

package/dist/relationship-loader.d.ts

@@ -1,4 +1,4 @@
-import { RelationshipMetadata } from './registry';
+import { type RelationshipMetadata } from './registry';
 /** Resolve the identity used for I/O, never the public display-name alias. */
 export declare function resolveRelationshipTargetName(relationship: RelationshipMetadata): Promise<string>;
 /** One inverse selection contract for lazy, eager and joined readers. */

package/dist/run-once.d.ts

@@ -1,4 +1,113 @@
-import { DatabaseInterface } from '@happyvertical/sql';
+/**
+ * Idempotency seam: run an action exactly once per submission (#3080).
+ *
+ * Every consumer with a form, a retried request, or a double-tapped button
+ * needs the same guard: a claim row, insert-only against a UNIQUE column
+ * (`claim_key`) in the SAME transaction as the work it guards, so a retry
+ * either runs the work once or replays the first attempt's stored result.
+ * This module is that primitive. It is DB/transaction-level — it takes a
+ * `DatabaseInterface`, not a `SmrtObject`/`SmrtCollection` — so it works
+ * outside SvelteKit and outside the ORM: any caller with a database handle
+ * and a JSON-serializable work result can use it. The claim insert itself
+ * is raw SQL (`## Concurrent submissions` below explains why), not the
+ * ORM's `SmrtObject`-level `_insertOnly` option.
+ *
+ * ## Key derivation (not the token alone)
+ *
+ * The claim key is the sha256 hex digest of the sorted-key-JSON encoding of
+ * `[tenantId, actor, token, contentDigest]`, where `contentDigest` is itself
+ * the sha256 hex digest of the sorted-key-JSON encoding of `content`
+ * ({@link digestRunOnceContent}). Sorted-key JSON ({@link stableStringify},
+ * `./knowledge-graph.ts`) makes the digest stable regardless of property
+ * insertion order.
+ *
+ * The token alone is NOT the key. A first attempt at this exact problem
+ * (reported against #3080) keyed on the token alone and silently collapsed
+ * two genuinely different submissions that happened to reuse one form's
+ * token. Folding in the content digest means a retry of the SAME submission
+ * (same token, same content) replays; a DIFFERENT submission through the
+ * same token (edited content before a resubmit) runs as its own claim.
+ * Folding in `tenantId` and `actor` means two tenants or two actors can never
+ * collide on the same claim even if a token were somehow shared between them.
+ *
+ * Neither the raw token nor the raw content is ever persisted — only their
+ * digests — so the claims table (`_smrt_run_once_claims`,
+ * `./system/schema.ts`) cannot leak submitted business data.
+ *
+ * ## Atomicity
+ *
+ * `runOnce()` opens its own `db.transaction()` (or nests under the caller's,
+ * per `@happyvertical/sql`'s own SAVEPOINT/`NestedTransactionError` rules —
+ * see that package's `DatabaseInterface.transaction` doc) and, inside it:
+ *
+ * 1. Inserts the claim row (`status: 'in_progress'`).
+ * 2. Runs `work(tx)`, passing the SAME transaction-bound handle, so the
+ *    caller's writes and the claim insert commit or roll back together.
+ * 3. Updates the claim row to `status: 'completed'` with the JSON-serialized
+ *    result, still inside the same transaction.
+ *
+ * If `work()` throws, the callback throws, and `db.transaction()`'s own
+ * "commits on success, rolls back on error" contract undoes the claim insert
+ * along with whatever `work()` partially wrote — a claim is never stranded
+ * `'in_progress'` by a failed attempt, and a retry with the same key can
+ * always run again.
+ *
+ * ## Concurrent submissions
+ *
+ * The claim insert uses `INSERT ... ON CONFLICT (claim_key) DO NOTHING
+ * RETURNING claim_key` (the same portable idiom `_smrt_migrations` already
+ * uses in `system/bootstrap.ts`), not a plain `INSERT` caught for a
+ * classified `unique_violation`. This matters on PostgreSQL specifically: a
+ * statement that raises an error aborts the WHOLE transaction ("current
+ * transaction is aborted, commands ignored until end of transaction block"),
+ * so a plain `INSERT` failing on the claim key would make every subsequent
+ * statement in the same transaction — including the very `SELECT` this
+ * function needs to read the winner's stored result back — fail too.
+ * `DO NOTHING` never raises: it returns zero rows instead, which this
+ * function reads as "lost the race" without ever touching the transaction's
+ * error state. SQLite and DuckDB both support the same `ON CONFLICT ... DO
+ * NOTHING` / `RETURNING` syntax, so one query works on every adapter.
+ *
+ * `@happyvertical/sql`'s single-connection adapters (SQLite, DuckDB, JSON)
+ * serialize `transaction()` calls on one connection: a second, concurrent
+ * `runOnce()` call does not begin its own transaction until the first one
+ * ends. PostgreSQL pools, but this `INSERT`'s arbiter still has to check the
+ * unique index against another transaction's uncommitted row of the same
+ * PRIMARY KEY, and blocks until that transaction resolves, then either
+ * no-ops (committed — the row exists) or inserts (rolled back — no row).
+ * Either way, two concurrent callers with the same key never both run
+ * `work()`: exactly one does, and the loser's `INSERT` returns zero rows —
+ * never an error — at which point it reads the now-committed claim row back
+ * and replays its stored result.
+ *
+ * ## Typed answers for a claim that is not (yet) a definite result
+ *
+ * A `runOnce()` conflict is a *definite* decision — the row exists — but
+ * whether it is safe to hand back a result depends on `status`. This mirrors
+ * the "refused vs unknown outcome" distinction #2990 drew for AssistantDock
+ * actions (`./errors.ts#RunOnceClaimError` carries the two codes):
+ *
+ * - `status: 'completed'` — replay the stored `result`. No error.
+ * - `status` anything else (still `'in_progress'`) — some execution holds
+ *   this key right now. `RunOnceClaimError.inFlight()`. Under this module's
+ *   own transaction semantics this is normally unreachable through
+ *   `runOnce()`-to-`runOnce()` races alone (the losing transaction can only
+ *   ever observe a COMMITTED row, and this module only ever commits a row
+ *   once it is `'completed'`) — it is reachable if a claim row was inserted
+ *   outside this module's own completion discipline, and is kept as a
+ *   defined answer rather than an assumption.
+ * - the row cannot be read back at all after `DO NOTHING` reported zero
+ *   rows inserted — `RunOnceClaimError.outcomeUnknown()`. Also normally
+ *   unreachable (the zero-rows case only happens when a committed row
+ *   already exists); kept for adapters/drivers where that and a subsequent
+ *   read are not guaranteed to observe the same committed state.
+ *
+ * Both errors carry `claimKey` and are safe to retry with the SAME token and
+ * content; `runOnce()` never retries them itself.
+ *
+ * @module
+ */
+import type { DatabaseInterface } from '@happyvertical/sql';
 import { RUN_ONCE_CLAIMS_TABLE } from './system/schema.js';
 export { RUN_ONCE_CLAIMS_TABLE };
 /** Input identifying one submission for {@link runOnce}. */

package/dist/runtime/client.d.ts

@@ -1,4 +1,7 @@
-import { SmrtClientOptions } from './types';
+/**
+ * Runtime client implementation for SMRT auto-generated services
+ */
+import type { SmrtClientOptions } from './types';
 export declare class SmrtClient {
     private options;
     constructor(options?: SmrtClientOptions);

package/dist/runtime/server.d.ts

@@ -1,5 +1,8 @@
-import { default as http } from 'node:http';
-import { SmrtRequest, SmrtServerOptions } from './types';
+/**
+ * Runtime server implementation for SMRT auto-generated services
+ */
+import http from 'node:http';
+import type { SmrtRequest, SmrtServerOptions } from './types';
 /**
  * Express-style response object handed to RouteApp-compatibility handlers
  * (registered via {@link SmrtServer.get}/`post`/`put`/`delete`). It mirrors the

package/dist/scanner/import-scanner.d.ts

@@ -1,4 +1,4 @@
-import { ScannerModule } from '../utils/scanner-module.js';
+import type { ScannerModule } from '../utils/scanner-module.js';
 interface ImportScannerOptions {
     missingBuildInstruction: string;
 }

package/dist/scanner/manifest-generator.d.ts

@@ -1,4 +1,7 @@
-import { ScanResult, SmartObjectManifest, SmrtVisibility } from './types.js';
+/**
+ * Manifest generator for creating service manifests from AST scan results
+ */
+import type { ScanResult, SmartObjectManifest, SmrtVisibility } from './types.js';
 /** Package.json shape consumed for import-path and component discovery. */
 interface PackageJsonLike {
     name?: string;

package/dist/scanner/types.d.ts

@@ -1,4 +1,7 @@
-import { SmartObjectConfig } from '../registry.js';
+/**
+ * Type definitions for AST scanning and manifest generation
+ */
+import type { SmartObjectConfig } from '../registry.js';
 /**
  * Qualified class name in format "@package/name:ClassName"
  * Example: "@happyvertical/smrt-core:Product"

package/dist/schema/code-generator.d.ts

@@ -1,5 +1,9 @@
-import { SmartObjectDefinition } from '../scanner/types.js';
-import { SchemaDefinition } from './types.js';
+/**
+ * Code generator for SMRT schema methods
+ * Generates getSchema() static methods for SMRT objects
+ */
+import type { SmartObjectDefinition } from '../scanner/types.js';
+import type { SchemaDefinition } from './types.js';
 export declare class SchemaCodeGenerator {
     /**
      * Generate getSchema() method source code

package/dist/schema/column-data-probes.d.ts

@@ -1,5 +1,30 @@
-import { DatabaseInterface } from '@happyvertical/sql';
-import { DatabaseEngine } from './ddl/types.js';
+/**
+ * Shared live-data column probes (#2874, consolidated for #2878).
+ *
+ * `detectRenameDataPending()` exists in both `migrations/differ.ts` and
+ * `schema/live-parity.ts` — tracked as its own maintenance hazard by #2878,
+ * since the #2874 regression had to be fixed twice, in lockstep, in #2876
+ * (once per copy). Until now the two batched live-data probes that function
+ * depends on were duplicated right along with it: does a named column hold
+ * any non-empty value, and does every non-empty value in a named column
+ * look UUID-shaped? Both copies used the exact same shape —
+ * uncorrelated scalar subqueries, one per column, each with its own
+ * `LIMIT 1` early exit (#2874 review finding F1: never an aggregate over
+ * the whole table, which would force a full scan per probed column even
+ * when the very first row already answers it), and the same positional
+ * `c<index>` aliasing to sidestep PostgreSQL's 63-byte identifier
+ * truncation (#2874 review finding F2'). Extracted here so the two call
+ * sites can never drift out of lockstep again.
+ *
+ * Both functions fall back to isolated per-column probing when the batched
+ * statement itself fails, so one bad column (dropped concurrently, a `CAST`
+ * the engine rejects) withholds only that column's result rather than the
+ * whole table's (#2874 review finding F2). A column absent from the
+ * returned map means "could not be probed" — callers apply their own
+ * fail-closed default, not this module.
+ */
+import type { DatabaseInterface } from '@happyvertical/sql';
+import type { DatabaseEngine } from './ddl/types.js';
 /**
  * SQL predicate: a quoted column holds a non-null, non-empty value. Shared
  * by every probe below (single-table batch, single-column fallback, and

package/dist/schema/ddl/base-strategy.d.ts

@@ -1,5 +1,11 @@
-import { ColumnDefinition, IndexDefinition, SchemaDefinition, SQLDataType, TriggerDefinition } from '../types.js';
-import { DatabaseEngine, DDLStrategy } from './types.js';
+/**
+ * Base DDL Strategy - Shared logic for all database engines
+ *
+ * Provides common DDL generation logic that engine-specific strategies
+ * can override for their particular requirements.
+ */
+import type { ColumnDefinition, IndexDefinition, SchemaDefinition, SQLDataType, TriggerDefinition } from '../types.js';
+import type { DatabaseEngine, DDLStrategy } from './types.js';
 /**
  * Abstract base class for DDL strategies
  *

package/dist/schema/ddl/duckdb-strategy.d.ts

@@ -1,6 +1,18 @@
-import { SchemaDefinition, SQLDataType } from '../types.js';
+/**
+ * DuckDB DDL Strategy
+ *
+ * DuckDB-specific DDL generation with the following characteristics:
+ * - UNIQUE constraints MUST be inline for UPSERT to work (DuckDB issue #12684)
+ * - Supports CAST in DEFAULT values
+ * - Native BOOLEAN, JSON types
+ * - Does NOT support triggers
+ *
+ * CRITICAL: DuckDB's ON CONFLICT clause only works with inline UNIQUE constraints,
+ * not with separate UNIQUE indexes. This is a known DuckDB limitation.
+ */
+import type { SchemaDefinition, SQLDataType } from '../types.js';
 import { BaseDDLStrategy } from './base-strategy.js';
-import { DatabaseEngine } from './types.js';
+import type { DatabaseEngine } from './types.js';
 export declare class DuckDBStrategy extends BaseDDLStrategy {
     readonly engine: DatabaseEngine;
     generateCreateTable(schema: SchemaDefinition): string;

package/dist/schema/ddl/index.d.ts

@@ -1,5 +1,3 @@
-import { SchemaDefinition } from '../types.js';
-import { DatabaseEngine, DDLStrategy, EngineSpecificDDL, MultiEngineDDL } from './types.js';
 /**
  * DDL Generator Module
  *
@@ -12,6 +10,8 @@ export { JsonDuckDBStrategy } from './json-duckdb-strategy.js';
 export { PostgresStrategy } from './postgres-strategy.js';
 export { SQLiteStrategy } from './sqlite-strategy.js';
 export * from './types.js';
+import type { SchemaDefinition } from '../types.js';
+import type { DatabaseEngine, DDLStrategy, EngineSpecificDDL, MultiEngineDDL } from './types.js';
 /**
  * Get the DDL strategy for a specific database engine
  *