@lotiai/composer 0.2.0

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Loti, LLC
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -0,0 +1,461 @@
+# @lotiai/composer
+
+[![CI](https://github.com/lotillc/composer/actions/workflows/ci.yml/badge.svg)](https://github.com/lotillc/composer/actions/workflows/ci.yml)
+[![npm version](https://img.shields.io/npm/v/@lotiai/composer.svg)](https://www.npmjs.com/package/@lotiai/composer)
+
+A framework for building type-safe, DAG-based workflows with optional Temporal integration.
+
+Composer lets you define steps with explicit inputs and outputs, compose them into workflows with automatic dependency resolution and parallel execution, and run them synchronously (in-process) or asynchronously (via [Temporal](https://temporal.io/)).
+
+> **Status:** pre-1.0. The public API may change between minor versions until 1.0.
+
+## Installation
+
+```bash
+pnpm add @lotiai/composer
+# or
+npm install @lotiai/composer
+```
+
+## Core Concepts
+
+### Bag
+
+The **bag** is a typed object that flows through a workflow. Each step declares which fields it reads from the bag (`needs`) and which fields it writes (`provides`). The bag type is defined once and shared across all steps and workflows.
+
+```typescript
+interface MyBag {
+  userId: string;
+  user: { name: string; email: string };
+  greeting: string;
+}
+```
+
+### Step
+
+A **step** is a single unit of work. Steps declare their dependencies and outputs, and the framework validates them at both compile-time and runtime.
+
+```typescript
+import { step } from "@lotiai/composer";
+
+// The double function call pattern lets TypeScript infer Needs/Provides from the definition.
+// The first call binds Bag and Context; the second binds the step shape.
+export const fetchUser = step<MyBag, MyContext>()({
+  name: "fetchUser",
+  needs: ["userId"],
+  provides: ["user"],
+  run: async (ctx, bag) => {
+    const user = await ctx.db.findUser(bag.userId);
+    return { user };
+  },
+});
+
+export const greet = step<MyBag, MyContext>()({
+  name: "greet",
+  needs: ["user"],
+  provides: ["greeting"],
+  run: async (_ctx, bag) => {
+    return { greeting: `Hello, ${bag.user.name}!` };
+  },
+});
+```
+
+**Type safety guarantees:**
+
+- Steps can only access fields declared in `needs`
+- Steps must return exactly the fields declared in `provides`
+- Return values must be JSON-serializable (enforced at compile-time and runtime)
+- Excess or missing return properties are caught at both compile-time and runtime
+
+### Workflow
+
+A **workflow** is a collection of steps with automatic dependency resolution. The framework builds a DAG, plans parallel execution batches, and validates all dependencies at compile-time.
+
+```typescript
+import { createWorkflow } from "@lotiai/composer";
+
+// Workflow without required initial data
+const simpleWorkflow = createWorkflow<MyBag>("simple")
+  .build([fetchUser, greet]);
+
+// Workflow requiring initial data at runtime
+const greetWorkflow = createWorkflow<MyBag>("greet-user")
+  .requires("userId")
+  .build([fetchUser, greet]);
+
+// Workflow with pre-configured values
+const configuredWorkflow = createWorkflow<MyBag>("configured")
+  .configure({ userId: "default-user" })
+  .build([fetchUser, greet]);
+
+// Configure + require (configure provides defaults, requires demands runtime values)
+const hybridWorkflow = createWorkflow<MyBag>("hybrid")
+  .configure({ someDefault: "value" })
+  .requires("userId")
+  .build([fetchUser, greet]);
+```
+
+**Compile-time dependency validation:** If a step needs a field that no prior step provides and it's not in initial/configured data, you get a clear compile error:
+
+```
+"WORKFLOW ERROR: A step needs user but it is not available. Available fields: [userId]
+ -> FIX: Add a step that provides user before the step that needs it"
+```
+
+### Workflow Composition
+
+Workflows can be composed into other workflows using the `use()` helper. Child workflow steps are flattened into the parent's DAG, enabling maximum parallelization while maintaining logical boundaries for observability.
+
+```typescript
+import { createWorkflow, use } from "@lotiai/composer";
+
+const authWorkflow = createWorkflow<MyBag>("auth")
+  .requires("userId")
+  .build([validateUser, checkPermissions]);
+
+const mainWorkflow = createWorkflow<MyBag>("main")
+  .requires("userId")
+  .build([
+    fetchData,
+    use(authWorkflow),   // Steps are flattened into parent DAG
+    processRequest,
+  ]);
+```
+
+Composed workflows:
+- Flatten steps for maximum parallelization across workflow boundaries
+- Auto-namespace step names (e.g. `auth.validateUser`) to prevent conflicts
+- Preserve observability via SubWorkflow spans in traces
+- Support arbitrary nesting depth
+
+### Execution Model
+
+Workflows execute using batch-based parallelism:
+
+1. **Dependency analysis** -- topological sort builds a DAG
+2. **Batch formation** -- groups steps that can run simultaneously
+3. **Parallel execution** -- each batch runs with `Promise.allSettled`
+4. **Progressive merge** -- successful outputs merge into the bag even if sibling steps fail
+
+```
+Given: stepA(needs:[]) -> stepB(needs:["x"]) -> stepC(needs:["x"]) -> stepD(needs:["y","z"])
+
+Batch 1: [stepA]           -- sequential (no deps)
+Batch 2: [stepB, stepC]    -- parallel (both need only "x")
+Batch 3: [stepD]           -- sequential (needs "y" and "z")
+```
+
+## Usage
+
+### Creating a Composer
+
+The `createComposer` function creates a configured instance that manages context lifecycle and execution:
+
+```typescript
+import { createComposer } from "@lotiai/composer";
+
+// Sync-only composer (no Temporal config)
+const syncComposer = createComposer({
+  contextProvider: {
+    beforeStep: async (stepName) => ({
+      db: await getDbConnection(),
+    }),
+    afterStep: async (ctx, error) => {
+      if (!error) await ctx.db.flush();
+      ctx.db.release();
+    },
+  },
+});
+
+// Full composer with Temporal support
+const composer = createComposer({
+  contextProvider: myContextProvider,
+  temporal: {
+    serverAddress: "localhost:7233",
+    namespace: "my-namespace",
+  },
+  // Optional settings:
+  logger: myPinoLogger,  // defaults to console
+  deepFreeze: true,      // freeze step outputs for immutability protection
+});
+```
+
+### Running Workflows
+
+```typescript
+// Synchronous execution (in-process)
+const { bag, error } = await composer.runSyncWorkflow(greetWorkflow, { userId: "u_123" });
+
+if (error) {
+  console.error("Workflow failed:", error);
+} else {
+  console.log(bag.greeting); // "Hello, Alice!"
+}
+
+// Asynchronous execution (via Temporal) -- requires temporal config
+const { bag: asyncBag, error: asyncError } = await composer.runAsyncWorkflow(greetWorkflow, { userId: "u_123" });
+```
+
+Workflows never throw. Errors are returned in `error`, and `bag` always contains any data produced by successful steps.
+
+### Checkpoints (Async Only)
+
+Checkpoints allow async workflows to return partial results early while continuing execution in the background:
+
+```typescript
+const workflow = createWorkflow<MyBag>("with-checkpoint")
+  .requires("userId")
+  .build([persistStep, processStep, finalizeStep])
+  .checkpoint("persisted", { afterStep: persistStep })
+  .checkpoint("processed", { afterStep: processStep, timeout: 60000 });
+
+// Get partial result after persistStep completes
+const { bag, error } = await composer.runAsyncWorkflow(workflow, data, {
+  awaitCheckpoint: "persisted",
+});
+// bag contains outputs up through the batch containing persistStep
+// The workflow continues running in the background
+```
+
+Checkpoint names are validated at compile-time -- using a name that doesn't exist on the workflow produces a type error.
+
+### Error Handling
+
+Attach an error handler to workflows for domain-specific error recovery:
+
+```typescript
+const workflow = createWorkflow<MyBag>("resilient")
+  .requires("userId")
+  .build([fetchUser, processData])
+  .onError(async (ctx, bag, error) => {
+    // Check error type
+    if (isExpectedError(error)) {
+      bag.result = getFallbackResult();
+      return undefined; // Error handled, error will be undefined in the result
+    }
+    return error; // Unknown error, propagate as-is
+  });
+```
+
+Error handler return values:
+- `undefined` -- error fully handled, `error` will be `undefined` in the result
+- `Error` -- propagate or transform the error into the result's `error`
+- Throwing -- `error` will be a `WorkflowErrorHandlerFailure` wrapping both the original error and the handler error
+
+### Context Provider
+
+The context provider manages per-step resources (e.g. database connections, loggers). It is configured once via `createComposer` and used automatically for every step execution.
+
+```typescript
+import { type StepContextProvider } from "@lotiai/composer";
+
+interface MyContext {
+  em: SqlEntityManager;
+}
+
+const contextProvider: StepContextProvider<MyContext> = {
+  beforeStep: async (stepName) => ({
+    em: await DatabaseConnection.getInstance().getForkedEntityManager(),
+  }),
+  afterStep: async (ctx, error) => {
+    if (!error) await ctx.em.flush();
+    ctx.em.clear();
+  },
+};
+```
+
+### Custom Logger
+
+Composer accepts any logger with `info`, `warn`, `error`, and `debug` methods. Compatible with `console`, `pino`, `winston`, and most logging libraries.
+
+```typescript
+import pino from "pino";
+
+const composer = createComposer({
+  contextProvider,
+  logger: {
+    info: (msg, meta) => pino().info(meta, msg),
+    warn: (msg, meta) => pino().warn(meta, msg),
+    error: (msg, meta) => pino().error(meta, msg),
+    debug: (msg, meta) => pino().debug(meta, msg),
+  },
+});
+```
+
+## CLI
+
+The package includes a CLI for building and managing Temporal workflow/activity bundles. It reads configuration from a `composer.build-config.ts` file in your package root.
+
+```bash
+npx @lotiai/composer build                  # Build bundles (fast unversioned flow)
+npx @lotiai/composer build --git-hash=abc   # Versioned build (vendor bundle + version copies + manifest)
+npx @lotiai/composer validate               # Validate config and definitions
+npx @lotiai/composer dev                    # Watch mode: compile, bundle, restart workers on changes
+npx @lotiai/composer dev --git-hash=abc     # Watch mode with versioned bundle flow
+npx @lotiai/composer dev:clean              # Remove versioned bundle artifacts
+npx @lotiai/composer dev:up                 # Start Temporal dev server (PostgreSQL + Temporal + UI)
+npx @lotiai/composer dev:down               # Stop Temporal dev server
+npx @lotiai/composer merge --git-hash=abc   # Merge versioned bundles into combined bundles for workers
+npx @lotiai/composer upload --git-hash=abc --type=versions  # Upload version bundles to S3
+npx @lotiai/composer upload --git-hash=abc --type=merged    # Upload merged bundles to S3
+npx @lotiai/composer cleanup                # Remove old versioned bundles (retention policy)
+```
+
+### Output Directory
+
+The CLI resolves the output directory automatically from your `tsconfig.json`'s `compilerOptions.outDir`. If `outDir` is not set in the `tsconfig.json` (sibling file to `composer.build-config.ts`), it falls back to `"dist"`. This means bundle output (workflow.js, activity.js, vendor bundles, version copies) is placed alongside your compiled TypeScript output without any extra configuration.
+
+### Build Configuration File
+
+Create a `composer.build-config.ts` in your package root:
+
+```typescript
+import { defineBuildConfig } from "@lotiai/composer/build-config";
+
+export default defineBuildConfig({
+  // Required: directories containing step and workflow definitions
+  stepsDir: "src/steps",
+  workflowsDir: "src/workflows",
+
+  // Optional: S3 config for bundle storage (required for upload/merge/cleanup commands)
+  s3: {
+    bucketName: "composer-bundles",
+    // Optional: provide a custom S3Client (e.g. for LocalStack or custom credentials)
+    // customClient: new S3Client({ region: "us-east-1", endpoint: "http://localhost:4566", forcePathStyle: true }),
+  },
+
+  // Optional: override worker profile defaults
+  workerProfiles: {
+    standard: {
+      cpu: 1024,
+      memory: 4096,
+      maxConcurrentActivities: 20,
+    },
+  },
+
+  // Optional: build settings
+  build: {
+    minify: true, // default: true
+  },
+
+  // Optional: dev command settings
+  dev: {
+    startAllWorkersJsScript: "dist/scripts/start-all-workers.js",
+    // watchPatterns: ["src/**/*.ts"],  // default: ["src/**/*.ts"]
+  },
+});
+```
+
+Note: Temporal connection config (`serverAddress`, `namespace`) is passed to `createComposer()` at runtime, not in `composer.build-config.ts`. The config file is for build and tooling concerns only.
+
+### Monorepo Consumers and Vendor Bundles
+
+When using versioned builds (`--git-hash`), the CLI creates a **vendor bundle** containing shared npm dependencies. In a monorepo, you typically want to exclude your own workspace packages from the vendor bundle (they contain business logic, not shared vendor deps) while still including their transitive npm dependencies.
+
+The CLI auto-detects which packages to exclude by looking for dependencies declared with pnpm's `workspace:` protocol in your `package.json`:
+
+```json
+{
+  "dependencies": {
+    "@myorg/shared-lib": "workspace:*",
+    "@myorg/db": "workspace:*",
+    "es-toolkit": "^1.43.0",
+    "uuid": "^11.1.0"
+  }
+}
+```
+
+In this example, `@myorg/shared-lib` and `@myorg/db` are excluded from the vendor bundle, but their transitive npm dependencies are still discovered and included. `es-toolkit` and `uuid` are included directly. Dependencies using pnpm's `catalog:` protocol are treated as normal npm dependencies and included in the vendor bundle.
+
+## Starting Temporal Workers
+
+For production or local development with Temporal, start workers using the helper functions:
+
+```typescript
+import { startAllWorkers } from "@lotiai/composer";
+import { composer } from "./my-app-composer";
+
+// Start both workflow and activity workers in one process (local dev)
+await startAllWorkers(composer, {
+  workflow: {
+    taskQueues: ["workflow-tasks"],
+    maxConcurrentWorkflowTaskExecutions: 100,
+  },
+  activity: {
+    taskQueues: ["standard-tasks"],
+    maxConcurrentActivityTaskExecutions: 15,
+  },
+});
+```
+
+For production, run workflow and activity workers in separate processes for independent scaling:
+
+```typescript
+import { startWorkflowWorker, startActivityWorker } from "@lotiai/composer";
+
+// In workflow worker process:
+await startWorkflowWorker(composer, {
+  taskQueues: ["workflow-tasks"],
+  maxConcurrentWorkflowTaskExecutions: 100,
+});
+
+// In activity worker process:
+await startActivityWorker(composer, {
+  taskQueues: ["standard-tasks"],
+  maxConcurrentActivityTaskExecutions: 15,
+});
+```
+
+## Worker Profiles
+
+Steps can declare a `workerProfile` to control which Temporal worker pool they run on. Currently, there is a single `"standard"` profile:
+
+| Profile    | Task Queue       | CPU     | Memory | Concurrent Activities |
+|------------|------------------|---------|--------|-----------------------|
+| `standard` | standard-tasks   | 0.5 vCPU| 2 GB   | 15                    |
+
+```typescript
+export const heavyStep = step<MyBag, MyContext>()({
+  name: "heavyComputation",
+  needs: ["input"],
+  provides: ["output"],
+  workerProfile: "standard", // default if omitted
+  run: async (ctx, bag) => { /* ... */ },
+});
+```
+
+Defaults can be overridden per-deployment via `workerProfiles` in `composer.build-config.ts`.
+
+## Exports
+
+### Main entry point (`@lotiai/composer`)
+
+| Export | Description |
+|--------|-------------|
+| `createComposer` | Create a configured Composer instance |
+| `createWorkflow` | Create a workflow with compile-time dependency validation |
+| `step` | Factory for creating type-safe steps |
+| `use` | Compose a child workflow into a parent |
+| `defineBuildConfig` | Type-safe build config helper (also available from `@lotiai/composer/build-config`) |
+| `startAllWorkers` | Start both Temporal workers in one process |
+| `startWorkflowWorker` | Start a Temporal workflow worker |
+| `startActivityWorker` | Start a Temporal activity worker |
+| `getAllTaskQueues` | Get all configured task queue names |
+| `getTaskQueueForProfile` | Get the task queue for a worker profile |
+| `WorkflowStepError` | Error class for step failures |
+| `WorkflowBatchError` | Error class for batch failures |
+| `WorkflowErrorHandlerFailure` | Error class for error handler failures |
+
+### Build config entry point (`@lotiai/composer/build-config`)
+
+Build configuration schema, loader, and `defineBuildConfig` helper for `composer.build-config.ts` files.
+
+## Deep Freeze (Immutability Protection)
+
+Enable `deepFreeze: true` in `createComposer` to freeze all step outputs before merging them into the bag. This catches mutation bugs that can cause non-deterministic behavior:
+
+- Parallel batch mutations (two steps mutating shared references)
+- Downstream mutations (a step modifying data from a previous step)
+- Post-return mutations (keeping a reference and mutating it later)
+
+Recommended for development and testing. The overhead (~0.5--10ms per output) is negligible for I/O-bound workflows.

package/bin/composer.js

@@ -0,0 +1,3 @@
+#!/usr/bin/env node
+
+require("../dist/cli/index.js");

package/docker-compose.temporal.yml

@@ -0,0 +1,144 @@
+# Temporal Server for local development
+#
+# temporalio/auto-setup was removed after 1.24.x. Local dev now uses
+# temporalio/admin-tools to initialise the schema, then starts the bare
+# temporalio/server image -- the same split used in production (ECS).
+#
+# Usage (from any directory):
+#   docker compose -f <path-to>/docker-compose.temporal.yml up -d
+
+services:
+  postgresql:
+    image: postgres:14
+    container_name: temporal-postgresql
+    environment:
+      POSTGRES_USER: temporal
+      POSTGRES_PASSWORD: temporal
+      POSTGRES_DB: temporal
+    ports:
+      # TEMPORAL_DB_PORT controls the host-side port only; containers always
+      # talk to postgresql:5432 over the Docker network.
+      - "${TEMPORAL_DB_PORT:-5432}:5432"
+    volumes:
+      - postgres-data:/var/lib/postgresql/data
+    networks:
+      - temporal-network
+    healthcheck:
+      test: ["CMD-SHELL", "pg_isready -U temporal"]
+      interval: 5s
+      timeout: 5s
+      retries: 5
+
+  # One-shot init container: creates the visibility database and runs
+  # schema setup for both the main and visibility databases, then exits.
+  temporal-schema-init:
+    image: temporalio/admin-tools:1.30.1
+    container_name: temporal-schema-init
+    depends_on:
+      postgresql:
+        condition: service_healthy
+    environment:
+      # temporal-sql-tool reads these env vars natively
+      - SQL_PLUGIN=postgres12
+      - SQL_HOST=postgresql
+      - SQL_PORT=5432
+      - SQL_USER=temporal
+      - SQL_PASSWORD=temporal
+    entrypoint: ["sh", "-c"]
+    command:
+      - |
+        set -eu
+
+        # Create the visibility database (the main 'temporal' db is created by PostgreSQL's POSTGRES_DB)
+        temporal-sql-tool --database temporal_visibility create-database || true
+
+        # Set up or update the main temporal database schema
+        temporal-sql-tool --database temporal setup-schema -v 0.0
+        temporal-sql-tool --database temporal \
+          update-schema -d /etc/temporal/schema/postgresql/v12/temporal/versioned
+
+        # Set up or update the visibility database schema
+        temporal-sql-tool --database temporal_visibility setup-schema -v 0.0
+        temporal-sql-tool --database temporal_visibility \
+          update-schema -d /etc/temporal/schema/postgresql/v12/visibility/versioned
+
+        echo "Temporal schema initialisation complete."
+    networks:
+      - temporal-network
+
+  temporal:
+    image: temporalio/server:1.30.1
+    container_name: temporal-dev
+    depends_on:
+      postgresql:
+        condition: service_healthy
+      temporal-schema-init:
+        condition: service_completed_successfully
+    ports:
+      - "7233:7233"  # Temporal Server (gRPC)
+    environment:
+      - DB=postgres12
+      - DB_PORT=5432
+      - POSTGRES_USER=temporal
+      - POSTGRES_PWD=temporal
+      - POSTGRES_SEEDS=postgresql
+    # The bare server image does not ship a dynamic config file but requires
+    # one to exist. Run as root so we can create it, then exec the entrypoint.
+    user: root
+    entrypoint: ["sh", "-c"]
+    command:
+      - |
+        mkdir -p /etc/temporal/config/dynamicconfig
+        echo '{}' > /etc/temporal/config/dynamicconfig/docker.yaml
+        exec /etc/temporal/entrypoint.sh
+    networks:
+      - temporal-network
+
+  temporal-namespace-init:
+    image: temporalio/admin-tools:1.30.1
+    container_name: temporal-namespace-init
+    depends_on:
+      - temporal
+    entrypoint: ["sh", "-c"]
+    # Uses the `temporal` CLI; `tctl` was removed from temporalio/admin-tools and would block forever in the health-wait loop.
+    command:
+      - |
+        set -eu
+
+        until temporal operator cluster health --address temporal:7233 >/dev/null 2>&1; do
+          sleep 2
+        done
+
+        # Keep local namespaces aligned with the canonical shared constants.
+        for namespace in interchange outpost josu; do
+          if temporal operator namespace describe -n "$namespace" --address temporal:7233 >/dev/null 2>&1; then
+            echo "Temporal namespace '$namespace' already exists."
+          else
+            temporal operator namespace create -n "$namespace" --retention 90d --address temporal:7233
+            echo "Temporal namespace '$namespace' created."
+          fi
+        done
+    networks:
+      - temporal-network
+
+  temporal-ui:
+    image: temporalio/ui:2.47.3
+    container_name: temporal-ui
+    depends_on:
+      - temporal
+      - temporal-namespace-init
+    ports:
+      - "8080:8080"  # Temporal Web UI
+    environment:
+      - TEMPORAL_ADDRESS=temporal:7233
+      - TEMPORAL_CORS_ORIGINS=http://localhost:3000
+    networks:
+      - temporal-network
+
+volumes:
+  postgres-data:
+    driver: local
+
+networks:
+  temporal-network:
+    driver: bridge

package/package.json

@@ -0,0 +1,99 @@
+{
+  "name": "@lotiai/composer",
+  "version": "0.2.0",
+  "description": "A framework for building type-safe, DAG-based workflows with optional Temporal integration.",
+  "license": "MIT",
+  "keywords": [
+    "temporal",
+    "workflow",
+    "dag",
+    "typescript",
+    "type-safe",
+    "orchestration"
+  ],
+  "homepage": "https://github.com/lotillc/composer#readme",
+  "bugs": {
+    "url": "https://github.com/lotillc/composer/issues"
+  },
+  "repository": {
+    "type": "git",
+    "url": "https://github.com/lotillc/composer.git"
+  },
+  "main": "dist/index.js",
+  "types": "dist/index.d.ts",
+  "bin": {
+    "composer": "bin/composer.js"
+  },
+  "files": [
+    "bin",
+    "dist",
+    "!dist/**/*.vitest.*",
+    "!dist/**/__tests__",
+    "docker-compose.temporal.yml"
+  ],
+  "exports": {
+    ".": {
+      "types": "./dist/index.d.ts",
+      "default": "./dist/index.js"
+    },
+    "./build-config": {
+      "types": "./dist/build-config/index.d.ts",
+      "default": "./dist/build-config/index.js"
+    },
+    "./temporal-naming": {
+      "types": "./dist/temporal-naming.d.ts",
+      "default": "./dist/temporal-naming.js"
+    },
+    "./schedule-sync": {
+      "types": "./dist/schedule-sync.d.ts",
+      "default": "./dist/schedule-sync.js"
+    }
+  },
+  "publishConfig": {
+    "access": "public",
+    "registry": "https://registry.npmjs.org"
+  },
+  "scripts": {
+    "compile": "tsc --build",
+    "clean": "rm -rf dist *.tsbuildinfo",
+    "test": "pnpm test:vitest",
+    "test:vitest": "vitest run --config vitest.config.mts --typecheck",
+    "test:vitest:watch": "vitest --config vitest.config.mts",
+    "test:watch": "pnpm test:vitest:watch",
+    "test:coverage": "vitest run --config vitest.config.mts --coverage",
+    "dev:temporal:up": "docker-compose -f docker-compose.temporal.yml up -d",
+    "dev:temporal:down": "docker-compose -f docker-compose.temporal.yml down",
+    "dev:temporal:logs": "docker-compose -f docker-compose.temporal.yml logs -f",
+    "cli": "node dist/cli/index.js",
+    "cli:dev": "node dist/cli/index.js dev"
+  },
+  "dependencies": {
+    "@aws-sdk/client-cloudwatch": "^3.946.0",
+    "@aws-sdk/client-lambda": "^3.658.1",
+    "@lifeomic/attempt": "^3.0.0",
+    "@opentelemetry/api": "^1.9.0",
+    "@temporalio/activity": "^1.15.0",
+    "@temporalio/client": "^1.15.0",
+    "@temporalio/common": "^1.15.0",
+    "@temporalio/worker": "^1.15.0",
+    "@temporalio/workflow": "^1.15.0",
+    "chokidar": "^3.5.3",
+    "es-toolkit": "^1.43.0",
+    "glob": "^13.0.0",
+    "jiti": "^2.6.1",
+    "long": "^5.0.0",
+    "typescript": "^5.9.2",
+    "uuid": "^11.1.0",
+    "yargs": "^17.7.2",
+    "zod": "^4.1.13"
+  },
+  "devDependencies": {
+    "@types/yargs": "^17.0.24",
+    "@vitest/coverage-v8": "^4.1.4",
+    "vitest": "^4.1.4"
+  },
+  "engines": {
+    "node": ">=22"
+  },
+  "packageManager": "pnpm@10.28.2"
+}