@elevasis/sdk 1.48.0 → 1.50.0

package/reference/sdk/framework/project-structure.mdx

@@ -22,7 +22,7 @@ The scaffold is a workspace with `ui/`, `operations/`, and `core/` packages plus
 ├── .env / .env.example   # ELEVASIS_PLATFORM_KEY and other root-level environment values
 ├── .gitattributes        # Line-ending normalization
 ├── .gitignore            # Excludes node_modules, dist, .env, .tanstack, and more
-├── .npmrc                # auto-install-peers = true (Zod is a peer dependency)
+├── .npmrc                # ignore-workspace-root-check + auto-install-peers (Zod is a peer dependency)
 ├── CLAUDE.md              # Project-owned identity and preferences (never overwritten by sync)
 ├── CONNECTIONS.md         # Tenant-owned production wiring values (never overwritten)
 ├── OPERATIONS.md          # Tenant-owned operational quirks (never overwritten, outranks generic guidance)
@@ -43,11 +43,17 @@ Cross-runtime types, schemas, constants, and organization-model configuration sh
 ```
 core/
 ├── config/
-│   ├── organization-model.ts                 # Canonical model + resource descriptor resolvers
+│   ├── organization-model.ts                 # Entry barrel -- assembly, public exports, knowledge wiring
+│   ├── organization-model/
+│   │   ├── profile.ts                          # defineOrganizationModel() body (/om codify target)
+│   │   ├── systems.ts                          # Operational graph, resource descriptors, governance model
+│   │   └── navigation.ts                       # Sidebar tree, projectTemplateNavigationSurfaces
 │   ├── organization-model.test.ts
 │   ├── organization-model.contract.test.ts
-│   ├── extensions/                            # Project-specific model extensions
-│   ├── knowledge/                              # Knowledge graph nodes
+│   ├── extensions/                            # Project-specific model extensions (deal-ecom.ts.example, index.ts)
+│   ├── knowledge/
+│   │   ├── nodes/                                # Hand-authored knowledge node MDX (welcome.mdx)
+│   │   └── _generated/                           # Compiled knowledge bodies and search index -- do not edit
 │   └── README.md
 ├── test-utils/
 │   └── core-contract-factories.ts
@@ -63,7 +69,7 @@ core/
 
 ### `core/config/organization-model.ts`
 
-Defines and resolves the canonical organization model (`canonicalOrganizationModel`) plus the resource-descriptor getters (`getTemplateWorkflowResourceDescriptor`, `getTemplateAgentResourceDescriptor`) that `operations/src/index.ts` imports. Direct edits are discouraged -- the file's own resolver (`resolveOrganizationModel()`) runs Zod cross-reference validation that a syntactically valid edit can still fail. All edits go through `/om`.
+The entry file for the organization model, split into a thin assembly barrel plus three sibling files under `core/config/organization-model/`: `profile.ts` (the `/om` codify target -- identity, customers, offerings, roles, goals), `systems.ts` (the operational graph: Systems, resources, the resource-descriptor getters `getTemplateWorkflowResourceDescriptor` and `getTemplateAgentResourceDescriptor`, and governance model), and `navigation.ts` (the sidebar tree). `organization-model.ts` resolves the canonical model (`canonicalOrganizationModel`, via `resolveOrganizationModel()`) and re-exports every public symbol from the split files so `operations/src/index.ts` and other consumers keep importing from the single entry path. Direct edits to any of these files are discouraged -- the resolver runs Zod cross-reference validation that a syntactically valid edit can still fail. All edits go through `/om`.
 
 ### `core/types/index.ts`
 
@@ -86,13 +92,18 @@ operations/
 │   ├── metadata.ts                    # Trigger/integration/human-checkpoint metadata (starts empty)
 │   ├── resource-registry.test.ts
 │   ├── README.md
+│   ├── __tests__/
+│   │   └── sdk-test-utils.compat.ts   # Shared test helpers -- assertResourceRegistry, runWorkflow
 │   ├── example/
 │   │   ├── echo.ts                    # Starter workflow
+│   │   ├── echo.test.ts
 │   │   ├── example-agent.ts           # Starter agent
+│   │   ├── example-agent.test.ts
 │   │   └── index.ts                   # Domain barrel (exports workflows + agents)
 │   ├── email-notification/
 │   │   ├── exports.ts                 # Domain barrel
 │   │   ├── index.ts                   # Multi-step workflow using the notifications adapter
+│   │   ├── email-notification.test.ts
 │   │   └── adapter-contract.test.ts
 │   └── shared/                        # Empty by default (.gitkeep) -- code shared across domains
 ├── elevasis.config.ts                 # Project-level SDK config
@@ -111,7 +122,7 @@ Convention seed for deployment mechanics that are not resource identity: trigger
 
 ### `operations/src/example/echo.ts`
 
-The starter workflow: one workflow per file with its own `config`, Zod `contract`, `steps` map, and `entryPoint`. Replace this domain with your own when ready. `operations/src/example/example-agent.ts` is the equivalent starter for an agent resource.
+The starter workflow: one workflow per file with its own `config`, Zod `contract`, `steps` map, and `entryPoint`. Replace this domain with your own when ready. `operations/src/example/example-agent.ts` is the equivalent starter for an agent resource -- a minimal single-shot (non-session) `AgentDefinition` with no tools and no memory. Each has a matching `*.test.ts` file exercising it through the shared test helpers in `operations/src/__tests__/sdk-test-utils.compat.ts`.
 
 ### `operations/src/email-notification/index.ts`
 
@@ -173,7 +184,7 @@ The `.claude/` directory and `CLAUDE.md` give Claude Code full awareness of the
 ├── hooks/            # post-edit-validate.mjs, scaffold-registry-reminder.mjs, tool-failure-recovery.mjs
 ├── skills/           # One directory per slash command, each with a SKILL.md
 ├── rules/            # Path-scoped pointers to rule bodies bundled with @elevasis/sdk
-├── registries/       # Scaffold, skill-coverage, and knowledge registry data
+├── registries/       # Skill-coverage and knowledge registry data (skill-coverage.json, graph-skills.json, knowledge-flags.json)
 └── logs/             # Hook-written runtime state
 ```
 
@@ -183,7 +194,7 @@ The `.claude/` directory and `CLAUDE.md` give Claude Code full awareness of the
 
 ## `elevasis-sdk deploy` Scope
 
-`elevasis-sdk deploy` (run as `pnpm -C operations deploy` or `pnpm -C operations deploy:prod`) bundles `operations/src/` into a single file via esbuild and uploads it. There is no documentation-upload step in the current deploy path -- `ui/`, `core/`, and `.claude/` are not touched by deploy.
+`elevasis-sdk deploy` (run as `pnpm -C operations run deploy` or `pnpm -C operations run deploy:prod` -- the explicit `run` matters, because `pnpm -C operations deploy` without it invokes pnpm's own builtin `deploy` command instead of the project script) bundles `operations/src/` into a single file via esbuild and uploads it. There is no documentation-upload step in the current deploy path -- `ui/`, `core/`, and `.claude/` are not touched by deploy.
 
 ---
 
@@ -199,29 +210,29 @@ Contains `ELEVASIS_PLATFORM_KEY` (and optionally `ELEVASIS_PLATFORM_KEY_DEV`). G
 
 ### `.npmrc`
 
-Sets `auto-install-peers = true`. The SDK uses Zod as a peer dependency, so this ensures Zod installs automatically.
+Sets `ignore-workspace-root-check=true` (isolates this project so pnpm does not walk up and find the monorepo's `pnpm-workspace.yaml`) and `auto-install-peers=true` (the SDK uses Zod as a peer dependency, so this ensures Zod installs automatically).
 
 ### `.gitignore`
 
-Excludes `node_modules/`, `dist/`, `*.tsbuildinfo`, `.tanstack/`, `.env` and `.env.*` (except `.env.example`), `*.log`, `.claude/settings.local.json`, hook-written state in `.claude/logs/*.state.json`, `operations/dist/`, `operations/__elevasis_worker.ts` (a temporary file generated during deployment), and `tmp/*` (except `.gitkeep`).
+Excludes `node_modules/`, `dist/`, `*.tsbuildinfo`, `.tanstack/`, `.env` and `.env.*` (except `.env.example`), `*.log`, `.DS_Store`, `.claude/settings.local.json`, hook-written state in `.claude/logs/*.state.json`, `operations/dist/`, `operations/__elevasis_worker.ts` (a temporary file generated during deployment), `tmp/*` (except `.gitkeep`), and `.vercel`.
 
 ---
 
 ## File Reference
 
-| File / Directory                    | When You Edit It                                                       |
-| ----------------------------------- | ---------------------------------------------------------------------- |
-| `operations/src/index.ts`           | Adding or removing resources, wiring a new domain                      |
-| `operations/src/<domain>/*.ts`      | Writing and modifying workflow or agent logic                          |
-| `operations/src/metadata.ts`        | Adding triggers, integrations, or human-checkpoint queue metadata      |
-| `core/types/index.ts`               | Defining or changing a workflow's Zod contract                         |
-| `core/config/organization-model.ts` | Never directly -- run `/om` instead                                    |
-| `operations/elevasis.config.ts`     | Changing project-level SDK settings (`defaultStatus`, `dev.port`)      |
-| `.elevasis`                         | Never manually -- updated by `/git-sync` and platform tooling          |
-| `.env`                              | Adding environment variables                                           |
-| `CLAUDE.md`                         | Rarely -- project identity and preferences, mostly written by `/setup` |
-| `.claude/skills/*/SKILL.md`         | Never in a derived project -- these arrive via `/git-sync`             |
+| File / Directory                                                            | When You Edit It                                                       |
+| --------------------------------------------------------------------------- | ---------------------------------------------------------------------- |
+| `operations/src/index.ts`                                                   | Adding or removing resources, wiring a new domain                      |
+| `operations/src/<domain>/*.ts`                                              | Writing and modifying workflow or agent logic                          |
+| `operations/src/metadata.ts`                                                | Adding triggers, integrations, or human-checkpoint queue metadata      |
+| `core/types/index.ts`                                                       | Defining or changing a workflow's Zod contract                         |
+| `core/config/organization-model.ts` and `core/config/organization-model/**` | Never directly -- run `/om` instead                                    |
+| `operations/elevasis.config.ts`                                             | Changing project-level SDK settings (`defaultStatus`, `dev.port`)      |
+| `.elevasis`                                                                 | Never manually -- updated by `/git-sync` and platform tooling          |
+| `.env`                                                                      | Adding environment variables                                           |
+| `CLAUDE.md`                                                                 | Rarely -- project identity and preferences, mostly written by `/setup` |
+| `.claude/skills/*/SKILL.md`                                                 | Never in a derived project -- these arrive via `/git-sync`             |
 
 ---
 
-**Last Updated:** 2026-08-06
+**Last Updated:** 2026-08-17

package/reference/sdk/framework/tutorial-system.mdx

@@ -82,7 +82,7 @@ SECTION C -- The Organization Model                     (3 items)
  10  Systems, actions, and labels                         [ ]
  11  Entity extensions -- BaseProject, BaseDeal          [ ]
 
-SECTION D -- Modules (load on demand)                   (~6 items)
+SECTION D -- Modules (load on demand)                   (6 items)
  12  HITL                                                [ ]
  13  Schedules                                           [ ]
  14  Notifications + integrations                        [ ]

package/reference/sdk/getting-started.mdx

@@ -15,56 +15,27 @@ cd my-project
 pnpm install
 ```
 
-After `pnpm install`, all `elevasis-sdk` commands work via the scripts in `package.json` or `pnpm exec elevasis-sdk <command>`.
+After `pnpm install`, the CLI is available from the project root as `pnpm elevasis-sdk <command>`, which the root `package.json` delegates into `operations/`. Inside `operations/` itself, run `pnpm exec elevasis-sdk <command>` directly.
 
-The project ships with 30 files covering configuration, source, documentation, and Claude Code integration:
+The project is a pnpm workspace containing three packages -- shared config and types, your platform resources, and your frontend:
 
 ```
 my-project/
-├── CLAUDE.md                       # Project instructions for Claude Code
-├── .claude/
-│   ├── settings.json               # autoCompact: false
-│   ├── commands/
-│   │   ├── docs.md                 # Documentation lifecycle
-│   │   ├── meta.md                 # Project lifecycle (init, fix, deploy, health)
-│   │   ├── tutorial.md             # Progressive learning
-│   │   └── work.md                 # Task tracking
-│   ├── hooks/
-│   │   └── enforce-sdk-boundary.mjs # Blocks file modifications outside project (auto-loaded)
-│   ├── scripts/
-│   │   └── statusline-command.js   # Dynamic status line script
-│   ├── skills/
-│   │   └── creds/SKILL.md          # Credential management (auto-triggers)
-│   └── rules/
-│       ├── sdk-patterns.md         # SDK imports, structure, runtime (auto-loaded)
-│       ├── docs-authoring.md       # MDX conventions (auto-loaded)
-│       ├── memory-conventions.md   # Memory system conventions (auto-loaded)
-│       ├── project-map.md          # Project map conventions (auto-loaded)
-│       ├── task-tracking.md        # Task tracking conventions (auto-loaded)
-│       └── workspace-patterns.md   # Project-specific patterns (you add these)
-├── src/
-│   ├── index.ts                    # Registry entry point (aggregates domain barrels)
-│   ├── operations/
-│   │   ├── index.ts                # Domain barrel (exports workflows + agents)
-│   │   └── platform-status.ts     # Platform status workflow (real API example)
-│   ├── example/
-│   │   ├── index.ts                # Domain barrel (exports workflows + agents)
-│   │   └── echo.ts                 # Starter workflow (replace with your own)
-│   └── shared/
-│       └── .gitkeep                # Cross-domain shared utilities
-├── docs/
-│   ├── index.mdx                   # Starter documentation page
-│   └── in-progress/
-│       └── .gitkeep                # Work-in-progress docs directory
-├── elevasis.config.ts              # Config with workspace options
-├── package.json                    # check-types + deploy scripts
-├── tsconfig.json                   # TypeScript config (app-focused)
-├── pnpm-workspace.yaml             # Standalone project workspace
-├── .env                            # API key only
-├── .npmrc                          # auto-install-peers
-└── .gitignore                      # Excludes worker temp file, claude files
+├── CLAUDE.md            # Project instructions for Claude Code
+├── .claude/             # Agent integration: rules, skills, hooks, registries
+├── core/                # Organization model, knowledge nodes, shared browser-safe types
+├── operations/          # Workflows, agents, and resource definitions -- what you deploy
+├── ui/                  # Frontend app shell and routes
+├── package.json         # Root scripts that delegate into the three packages
+├── pnpm-workspace.yaml  # Standalone project workspace
+├── tsconfig.json        # Shared TypeScript config
+├── .env                 # Platform API key
+├── .npmrc               # auto-install-peers, ignore-workspace-root-check
+└── .gitignore
 ```
 
+See [Project Structure](framework/project-structure.mdx) for the full tree, including what lives inside each package.
+
 ### Set Up Your API Key
 
 Open `.env` and set your API key:
@@ -81,7 +52,7 @@ The `.env` file is gitignored -- never commit it.
 
 After scaffolding, open the project in Claude Code. The agent detects that the project is new and automatically walks you through setup: installing dependencies, configuring `.env`, creating your developer profile in `.claude/memory/`, and optionally running your first deploy. No commands needed -- just answer the questions.
 
-If the automatic setup doesn't trigger, you can start it manually with `/meta init`.
+If the automatic setup doesn't trigger, you can start it manually with `/setup`.
 
 ---
 
@@ -90,13 +61,15 @@ If the automatic setup doesn't trigger, you can start it manually with `/meta in
 Validate your resources and deploy:
 
 ```bash
-elevasis-sdk check    # Validate resource definitions
-elevasis-sdk deploy   # Bundle and deploy to the platform
+pnpm check     # Validate resource definitions
+pnpm deploy    # Bundle and deploy to the platform
 ```
 
-`elevasis-sdk check` runs validation without deploying. Fix any errors it reports before running `elevasis-sdk deploy`.
+Both root scripts delegate into `operations/`, where the resource registry lives. You can also run `pnpm exec elevasis-sdk check` and `pnpm exec elevasis-sdk deploy` from inside `operations/` directly.
+
+`check` runs validation without deploying. Fix any errors it reports before deploying.
 
-`elevasis-sdk deploy` bundles your `src/` code and `docs/` documentation into a single deployment transaction. Both ship atomically -- there is no separate upload step for documentation.
+`deploy` bundles `operations/src/index.ts` and everything it imports into a single JavaScript bundle, then uploads and activates it as one transaction. Use `--entry` if your registry entry point is somewhere other than `./src/index.ts`.
 
 After a successful deploy, confirm the resources are live:
 
@@ -119,7 +92,7 @@ View the execution result:
 
 ```bash
 elevasis-sdk executions echo    # Execution history
-elevasis-sdk execution echo \<execution-id\>  # Full detail for one execution
+elevasis-sdk execution echo <execution-id>  # Full detail for one execution
 ```
 
 Replace `<execution-id>` with the ID returned from the executions list.
@@ -134,8 +107,8 @@ Replace `<execution-id>` with the ID returned from the executions list.
 - [CLI Reference](cli.mdx) -- Full command reference with flags
 - [Deployment](deployment/index.mdx) -- Deployment lifecycle and environment variables
 
-When a new SDK version is released, run `/meta fix` in Claude Code for an interactive upgrade that includes SDK update, drift repair, and documentation verification. To update the SDK package itself directly, run `pnpm update @elevasis/sdk`.
+When a new SDK version is released, the dependency baseline arrives with the upstream changes rather than through a manual package bump. Run `/git-sync` in Claude Code to pull the latest, install when the baseline moved, and run baseline verification. If packages feel stale or a cache is serving old code afterwards, `/sync` does a fresh reinstall and cache reset.
 
 ---
 
-**Last Updated:** 2026-02-27
+**Last Updated:** 2026-08-17

package/reference/sdk/index.mdx

@@ -1,5 +1,5 @@
 ---
-title: Elevasis SDK
+title: "@elevasis/sdk"
 description: Build and deploy workflows, agents, and resources with the Elevasis SDK
 ---
 
@@ -70,8 +70,8 @@ See [Platform Tools](platform-tools/index.mdx) for the full catalog, adapter ref
 
 - [Development Framework](framework/index.mdx) - How Claude Code helps you build: project structure, agent integration, and the skill surface
 - [Project Structure](framework/project-structure.mdx) - Scaffolded file layout, domain barrels, src/index.ts entry point, and config files
-- [Agent Configuration](framework/agent.mdx) - The shipped skill inventory, project context via `project:*`, upgrades via `/git-sync`, and the ambient vibe layer
-- [Tutorial System](framework/tutorial-system.mdx) - Two-track onboarding: 8 vibe-coder lessons and 19 technical lessons across 5 sections, with track choice persisted to `profile.md`
+- [Agent Configuration](framework/agent.mdx) - The shipped skill inventory, project context via `project:*`, upgrades via `/git-sync`, and ambient vibe layer
+- [Tutorial System](framework/tutorial-system.mdx) - Two-track onboarding: 8 vibe-coder lessons and 19 technical lessons across 5 sections
 
 ### Resources Subpages
 

package/reference/sdk/platform-tools/adapters-integration.mdx

@@ -13,7 +13,7 @@ Integration adapters use a factory pattern. Call `create*Adapter(credential)` wi
 | Attio | `createAttioAdapter(credential)` | `createRecord`, `updateRecord`, `listRecords`, `getRecord`, `deleteRecord`, `listObjects`, `listAttributes`, `createAttribute`, `updateAttribute`, `createNote`, `listNotes`, `deleteNote` | Attio CRM — create, read, update, delete records, objects, attributes, and notes. |
 | Apify | `createApifyAdapter(credential)` | `runActor`, `getDatasetItems`, `startActor` | Apify — run actors and retrieve dataset items from web scraping runs. |
 | ClickUp | `createClickUpAdapter(credential)` | `verify`, `createTask` | ClickUp — verify connection and create tasks in ClickUp lists. |
-| Dropbox | `createDropboxAdapter(credential)` | `uploadFile`, `createFolder` | Dropbox — upload files and create folders. |
+| Dropbox | `createDropboxAdapter(credential)` | `uploadFile`, `createFolder`, `listFolder`, `getMetadata`, `getTemporaryLink`, `createSharedLink`, `download`, `getThumbnail`, `getThumbnailBatch` | Dropbox — upload files and create folders. |
 | Gmail | `createGmailAdapter(credential)` | `sendEmail` | Gmail — send emails via a bound Gmail credential. |
 | GoogleSheets | `createGoogleSheetsAdapter(credential)` | `readSheet`, `writeSheet`, `appendRows`, `clearRange`, `getSpreadsheetMetadata`, `batchUpdate`, `getHeaders`, `getLastRow`, `getRowByValue`, `updateRowByValue`, `upsertRow`, `filterRows`, `deleteRowByValue` | Google Sheets — read, write, append, filter, and manage spreadsheet data. |
 | Instantly | `createInstantlyAdapter(credential)` | `sendReply`, `removeFromSubsequence`, `getEmails`, `updateInterestStatus`, `addToCampaign`, `listCampaigns`, `getCampaign`, `updateCampaign`, `pauseCampaign`, `activateCampaign`, `getCampaignAnalytics`, `getStepAnalytics`, `bulkAddLeads`, `getAccountHealth`, `createInboxTest`, `createCampaign`, `getDailyCampaignAnalytics`, `listLeads`, `bulkDeleteLeads`, `deleteCampaign`, `patchLead` | Instantly — manage email outreach campaigns, leads, analytics, and inbox health. |

package/reference/sdk/platform-tools/adapters-platform.mdx

@@ -23,4 +23,4 @@ Platform adapters are singletons — import them directly, no credential require
 | Execution | `execution` | `trigger`, `triggerAsync` | Execution — trigger other workflows or agents within the same organization. |
 | Email | `email` | `send` | Email — send platform emails (from notifications@elevasis.io) to organization members. |
 | Artifacts | `artifacts` | `listArtifacts`, `createArtifact`, `getActive` | Artifacts — org-scoped governing-document store, keyed by owner and kind, for acquisition's audits, proposals, and ICP docs. |
-| Content | `content` | `createItem`, `getItem`, `listItems`, `updateItem`, `createAttempt`, `listAttempts`, `updateAttempt`, `createSourceAsset`, `getSourceAsset`, `listSourceAssets`, `updateSourceAsset`, `createDistribution`, `updateDistribution` | Content — create, read, and update content_items/content_item_attempts/content_distributions/content_source_assets rows for the content pipeline. |
+| Content | `content` | `createItem`, `getItem`, `listItems`, `updateItem`, `addItemSourceAsset`, `removeItemSourceAsset`, `reorderItemSourceAssets`, `updateItemSourceAsset`, `createAttempt`, `listAttempts`, `updateAttempt`, `createSourceAsset`, `getSourceAsset`, `listSourceAssets`, `updateSourceAsset`, `getDistribution`, `listDistributions`, `createDistribution`, `updateDistribution`, `appendDistributionMetrics`, `listDistributionMetrics` | Content — create, read, and update content_items/content_item_attempts/content_distributions/content_source_assets rows for the content pipeline. |

package/reference/sdk/platform-tools/type-safety.mdx

@@ -29,7 +29,7 @@ await llm.generate({
 
 ### Tomba Adapter -- `domain` and `email`
 
-`domain` is required on `TombaDomainSearchParams` and `TombaEmailFinderParams`. `email` is required on `TombaEmailVerifierParams`. Previously all params were optional, allowing calls to compile but fail at runtime. The type change enforces the fields that are always necessary for email discovery and verification.
+`domain` is required on `DomainSearchParams` and `EmailFinderParams` (the `domainSearch` and `emailFinder` entries of `TombaToolMap`, defined in `packages/core/src/execution/engine/tools/integration/types/tomba.ts`). `email` is required on `EmailVerifierParams` (the `emailVerifier` entry). Previously all params were optional, allowing calls to compile but fail at runtime. The type change enforces the fields that are always necessary for email discovery and verification.
 
 ---
 

package/reference/sdk/resources/patterns.mdx

@@ -98,11 +98,11 @@ const scoreStep: WorkflowStep = {
     type: 'conditional',
     routes: [
       {
-        condition: (output) => output.score \>= 80,
+        condition: (output) => output.score >= 80,
         target: 'autoApprove',
       },
       {
-        condition: (output) => output.score \>= 40,
+        condition: (output) => output.score >= 40,
         target: 'manualReview',
       },
     ],
@@ -253,7 +253,7 @@ const validateStep = async (input) => {
   if (!input.userId) {
     throw new ExecutionError('userId is required', { code: 'MISSING_INPUT' });
   }
-  if (input.amount \<= 0) {
+  if (input.amount <= 0) {
     throw new ExecutionError('amount must be positive', { code: 'INVALID_AMOUNT' });
   }
   return { valid: true };
@@ -312,7 +312,7 @@ Avoid logging sensitive values (API keys, passwords, PII) since logs are stored
 
 ## Using the Execution Store
 
-`context.store` is a simple key-value store scoped to the current execution. Use it to pass data between steps without coupling step interfaces, or to checkpoint long-running work.
+`context.store` is a plain `Map<string, unknown>` scoped to the current execution. Use it to pass data between steps without coupling step interfaces, or to checkpoint long-running work.
 
 {/* doc-snippet:skip: illustrative excerpt -- fetchExpensiveData/transform are placeholder names for your own logic, not a standalone compilable file */}
 
@@ -324,20 +324,19 @@ const firstStep: StepHandler = async (input, context) => {
   const data = await fetchExpensiveData(id);
 
   // Save for use by later steps
-  await context.store.set('fetchedData', JSON.stringify(data));
+  context.store.set('fetchedData', data);
 
   return { fetched: true };
 };
 
 const secondStep: StepHandler = async (input, context) => {
-  const raw = await context.store.get('fetchedData');
-  const data = JSON.parse(raw ?? '{}');
+  const data = context.store.get('fetchedData');
 
   return { processed: transform(data) };
 };
 ```
 
-Store values are strings. Serialize objects with `JSON.stringify` and parse with `JSON.parse`.
+`.set()` / `.get()` are synchronous `Map` methods and accept any value directly -- no `JSON.stringify` / `JSON.parse` round-trip required.
 
 ---
 
@@ -381,19 +380,19 @@ config: {
 
 ### Global Default Status
 
-Set a project-wide default in `elevasis.config.ts` to keep all resources in `'dev'` mode during development without touching each resource file:
+`config.status` is a required field on every resource definition -- there is currently no CLI-enforced project-wide default. `elevasis.config.ts` declares a `defaultStatus` field on `ElevasConfig` for this purpose, but the CLI does not yet read `elevasis.config.ts` to apply it:
 
 ```typescript
 import type { ElevasConfig } from '@elevasis/sdk';
 
 const config: ElevasConfig = {
-  defaultStatus: 'dev',
+  defaultStatus: 'dev', // reserved for future use -- not currently applied
 };
 
 export default config;
 ```
 
-Individual resources that set their own `config.status` override this default.
+Until the CLI reads this file, set `config.status` explicitly on each resource.
 
 ---
 

package/reference/sdk/resources/types.mdx

@@ -17,20 +17,24 @@ Zod is a peer dependency.
 {
   "exports": {
     ".": { "types": "./dist/index.d.ts", "import": "./dist/index.js" },
-    "./worker": { "import": "./dist/worker/index.js" }
+    "./worker": { "types": "./dist/worker/index.d.ts", "import": "./dist/worker/index.js" },
+    "./test-utils": { "types": "./dist/test-utils/index.d.ts", "import": "./dist/test-utils/index.js" },
+    "./node": { "types": "./dist/node/index.d.ts", "import": "./dist/node/index.js" }
   }
 }
 ```
 
 - `@elevasis/sdk` -- resource, workflow, agent, trigger, deployment, and execution types plus runtime errors.
 - `@elevasis/sdk/worker` -- worker runtime module, platform adapters, and worker helpers.
+- `@elevasis/sdk/test-utils` -- in-memory registry and mock adapters for testing resources without a live deployment.
+- `@elevasis/sdk/node` -- knowledge codegen and other build-time helpers requiring Node built-ins (`fs`, `path`, `process`); not browser-safe.
 
 ## Platform Types
 
 | Type                    | Description                                                                                                                 |
 | ----------------------- | --------------------------------------------------------------------------------------------------------------------------- |
 | `ResourceDefinition`    | Base interface for resource definitions                                                                                     |
-| `ResourceType`          | Resource kind such as `workflow`, `agent`, `trigger`, `integration`, `external`, or `human_checkpoint`                      |
+| `ResourceType`          | Resource kind such as `workflow`, `agent`, `trigger`, `integration`, `external`, or `human`                                 |
 | `ResourceStatus`        | Resource lifecycle status such as `dev` or `prod`                                                                           |
 | `ResourceLink`          | Graph link `{ nodeId, kind }` binding a resource to an Organization Model node                                              |
 | `ResourceCategory`      | Operational category: `production`, `diagnostic`, `internal`, or `testing`                                                  |
@@ -64,9 +68,9 @@ config: {
 | Type                 | Description                                                                                                                                             |
 | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | `WorkflowDefinition` | Complete workflow definition including config, contract, steps, and entryPoint                                                                          |
-| `WorkflowStep`       | Individual step definition with type, handler, and next routing                                                                                         |
+| `WorkflowStep`       | Individual step definition with `handler`, `inputSchema`, `outputSchema`, and `next` routing -- no `type` field on the step itself                      |
 | `WorkflowConfig`     | Metadata block: name, description, status, links, category                                                                                              |
-| `StepHandler`        | Function type: `(input: unknown, context: StepContext) => Promise<unknown>`                                                                             |
+| `StepHandler`        | Function type: `(input: unknown, context: ExecutionContext) => Promise<unknown>`                                                                        |
 | `NextConfig`         | Union of `LinearNext` and `ConditionalNext`                                                                                                             |
 | `LinearNext`         | Fixed next step routing                                                                                                                                 |
 | `ConditionalNext`    | Branching step routing                                                                                                                                  |
@@ -87,10 +91,10 @@ export interface ElevasConfig {
 }
 ```
 
-| Field           | Type     | Default | Description                   |
-| --------------- | -------- | ------- | ----------------------------- | ---------------------------------------------------------------- |
-| `defaultStatus` | `'dev'   | 'prod'` | `'prod'`                      | Default status applied when resources do not set `config.status` |
-| `dev.port`      | `number` | `3001`  | Local worker development port |
+| Field           | Type              | Description                                                                                                                                                                        |
+| --------------- | ----------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `defaultStatus` | `'dev' | 'prod'` | Reserved for a project-wide default `config.status`. The CLI does not currently read `elevasis.config.ts` to apply it -- `config.status` is required on every resource definition. |
+| `dev.port`      | `number`          | Reserved for a local worker development port. Not currently read by the CLI.                                                                                                       |
 
 ## StepHandler Context
 
@@ -102,11 +106,13 @@ import type { StepHandler, ExecutionContext } from '@elevasis/sdk'
 const handler: StepHandler = async (input, context: ExecutionContext) => {
   context.logger.info(`Processing execution ${context.executionId} for resource ${context.resourceId}`)
 
-  await context.store.set('checkpoint', JSON.stringify({ step: 'started' }))
+  context.store.set('checkpoint', { step: 'started' })
   return { done: true }
 }
 ```
 
+`context.store` is a plain `Map<string, unknown>` scoped to the current execution -- `.set()` / `.get()` are synchronous and accept any value directly, no `JSON.stringify` / `JSON.parse` round-trip required.
+
 ## Runtime Values
 
 Runtime exports include:

package/reference/sdk/templates/data-enrichment.mdx

@@ -75,7 +75,7 @@ type Input = z.infer<typeof inputSchema>
 
 export const dataEnrichment: WorkflowDefinition = {
   config: {
-    resourceId: 'data-enrichment',
+    resourceId: 'data-enrichment-workflow',
     name: 'Data Enrichment',
     type: 'workflow',
     description: 'Enriches database records using an LLM',

package/reference/sdk/templates/email-sender.mdx

@@ -74,7 +74,7 @@ type Input = z.infer<typeof inputSchema>
 
 export const emailSender: WorkflowDefinition = {
   config: {
-    resourceId: 'email-sender',
+    resourceId: 'email-sender-workflow',
     name: 'Email Sender',
     type: 'workflow',
     description: 'Sends transactional email via Resend',

package/reference/sdk/templates/index.mdx

@@ -1,47 +1,47 @@
----
-title: Templates
-description: Ready-to-use workflow templates for common automation patterns -- web scraping, data enrichment, email sending, lead scoring, PDF generation, text classification, and recurring jobs
----
-
-Templates are pre-built workflow definitions covering the most common SDK automation patterns. Each template includes a complete `WorkflowDefinition` with Zod schemas, step handlers, and real platform tool usage. Scaffold any template through Claude Code (`/work` then describe the template) or adapt the code manually.
-
-Templates follow the same `WorkflowDefinition` structure as any custom resource -- they are reference implementations, not a special feature. The patterns demonstrated (multi-step chains, LLM structured output, Supabase CRUD, scheduler setup) apply directly to custom workflows you build.
-
-All templates are available for any organization. Credentials specific to each template (Supabase, Resend, Apify, etc.) must be created in the command center before running the workflow.
-
-## Documentation
-
-### Data Collection & Processing
-
-- [Web Scraper](web-scraper.mdx) - Apify actor runs web scrape, stores structured results in Supabase table
-- [Data Enrichment](data-enrichment.mdx) - Reads Supabase records, enriches each with LLM, writes results back; supports batching
-
-### Communication & CRM
-
-- [Email Sender](email-sender.mdx) - Transactional email via Resend with plain text and HTML support, single or multiple recipients
-- [Lead Scorer](lead-scorer.mdx) - Multi-criteria LLM lead scoring with configurable rubric and Supabase result storage
-
-### Documents & AI
-
-- [PDF Generator](pdf-generator.mdx) - Renders structured data to PDF, uploads to platform storage, returns signed download URL
-- [Text Classifier](text-classifier.mdx) - Multi-label text classification via LLM structured output, configurable categories and confidence scoring
-
-### Scheduling
-
-- [Recurring Job](recurring-job.mdx) - Two-workflow setup pattern: a setup workflow creates the schedule, the job workflow runs on each trigger; uses idempotency keys for safe re-registration
-
-## Platform Tools Used
-
-| Template        | Platform Tools      | Credentials Needed              |
-| --------------- | ------------------- | ------------------------------- |
-| Web Scraper     | `apify`, `supabase` | `apify`, `my-database`          |
-| Data Enrichment | `llm`, `supabase`   | `my-database` (LLM server-side) |
-| Email Sender    | `resend`            | `my-resend`                     |
-| Lead Scorer     | `llm`, `supabase`   | `my-database` (LLM server-side) |
-| PDF Generator   | `pdf`, `storage`    | None (platform services)        |
-| Text Classifier | `llm`               | None (LLM server-side)          |
-| Recurring Job   | `scheduler`         | None (platform service)         |
-
----
-
-**Last Updated:** 2026-03-19
+---
+title: Templates
+description: Ready-to-use workflow templates for common automation patterns -- web scraping, data enrichment, email sending, lead scoring, PDF generation, text classification, and recurring jobs
+---
+
+Templates are pre-built workflow definitions covering the most common SDK automation patterns. Each template includes a complete `WorkflowDefinition` with Zod schemas, step handlers, and real platform tool usage. Scaffold any template through Claude Code (`/work` then describe the template) or adapt the code manually.
+
+Templates follow the same `WorkflowDefinition` structure as any custom resource -- they are reference implementations, not a special feature. The patterns demonstrated (multi-step chains, LLM structured output, Supabase CRUD, scheduler setup) apply directly to custom workflows you build.
+
+All templates are available for any organization. Credentials specific to each template (Supabase, Resend, Apify, etc.) must be created in the command center before running the workflow.
+
+## Documentation
+
+### Data Collection & Processing
+
+- [Web Scraper](web-scraper.mdx) - Apify actor runs web scrape, stores structured results in Supabase table
+- [Data Enrichment](data-enrichment.mdx) - Reads Supabase records, enriches each with LLM, writes results back; supports batching
+
+### Communication & CRM
+
+- [Email Sender](email-sender.mdx) - Transactional email via Resend with plain text and HTML support, single or multiple recipients
+- [Lead Scorer](lead-scorer.mdx) - Multi-criteria LLM lead scoring with configurable rubric and Supabase result storage
+
+### Documents & AI
+
+- [PDF Generator](pdf-generator.mdx) - Renders structured data to PDF, uploads to platform storage, returns signed download URL
+- [Text Classifier](text-classifier.mdx) - Multi-label text classification via LLM structured output, configurable categories and confidence scoring
+
+### Scheduling
+
+- [Recurring Job](recurring-job.mdx) - Two-workflow setup pattern: a setup workflow creates the schedule, the job workflow runs on trigger
+
+## Platform Tools Used
+
+| Template        | Platform Tools      | Credentials Needed              |
+| --------------- | ------------------- | ------------------------------- |
+| Web Scraper     | `apify`, `supabase` | `apify`, `my-database`          |
+| Data Enrichment | `llm`, `supabase`   | `my-database` (LLM server-side) |
+| Email Sender    | `resend`            | `my-resend`                     |
+| Lead Scorer     | `llm`, `supabase`   | `my-database` (LLM server-side) |
+| PDF Generator   | `pdf`, `storage`    | None (platform services)        |
+| Text Classifier | `llm`               | None (LLM server-side)          |
+| Recurring Job   | `scheduler`         | None (platform service)         |
+
+---
+
+**Last Updated:** 2026-03-19

package/reference/sdk/templates/lead-scorer.mdx

@@ -90,7 +90,7 @@ type Input = z.infer<typeof inputSchema>
 
 export const leadScorer: WorkflowDefinition = {
   config: {
-    resourceId: 'lead-scorer',
+    resourceId: 'lead-scorer-workflow',
     name: 'Lead Scorer',
     type: 'workflow',
     description: 'Scores leads using an LLM and stores results in Supabase',