@elevasis/sdk 1.48.0 → 1.49.0

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` | 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',

package/reference/sdk/templates/pdf-generator.mdx

@@ -1,6 +1,6 @@
 ---
 title: "Template: PDF Generator"
-description: "PDF generation from structured data with platform storage upload -- render a PDF from a template and upload to platform storage"
+description: "PDF generation from structured data with platform storage upload -- render a PDF from typed content blocks and upload to platform storage"
 loadWhen: "Applying the pdf-generator workflow template"
 ---
 
@@ -16,7 +16,9 @@ loadWhen: "Applying the pdf-generator workflow template"
 
 ## What This Workflow Does
 
-Receives structured data, renders a PDF using an HTML template, uploads the result to platform storage, and returns a signed URL for download. Suitable for invoices, reports, certificates, contracts, and any document that needs to be generated on demand and delivered as a downloadable file.
+Receives structured content (a title, body text, and an optional data table), renders it to a PDF using the platform's declarative document builder, uploads the result to platform storage, and returns a signed URL for download. Suitable for invoices, reports, certificates, contracts, and any document that needs to be generated on demand and delivered as a downloadable file.
+
+The platform's `pdf` tool does not accept raw HTML -- it renders a JSON document tree of typed content blocks (`text`, `metric`, `list`, `table`, `card`, `columns`). This template covers the common `text` + `table` case; adapt the `sections` array for other block types.
 
 ---
 
@@ -26,8 +28,10 @@ Receives structured data, renders a PDF using an HTML template, uploads the resu
 
 ```typescript
 z.object({
-  templateHtml: z.string(),          // HTML template with {variable} placeholders
-  data: z.record(z.string(), z.unknown()),        // Data to inject into the template
+  title: z.string(),                  // Document title, rendered as the page heading
+  bodyText: z.string(),               // Main body paragraph
+  tableHeaders: z.array(z.string()).optional(), // Optional data table column headers
+  tableRows: z.array(z.array(z.string())).optional(), // Optional data table rows
   filename: z.string(),               // Output filename (without .pdf extension)
   expiresInSeconds: z.number().optional(), // Signed URL expiry (default: 3600)
 })
@@ -56,8 +60,10 @@ import { platform } from '@elevasis/sdk/worker'
 import { z } from 'zod'
 
 const inputSchema = z.object({
-  templateHtml: z.string(),
-  data: z.record(z.string(), z.unknown()),
+  title: z.string(),
+  bodyText: z.string(),
+  tableHeaders: z.array(z.string()).optional(),
+  tableRows: z.array(z.array(z.string())).optional(),
   filename: z.string(),
   expiresInSeconds: z.number().optional(),
 })
@@ -69,16 +75,12 @@ const outputSchema = z.object({
 
 type Input = z.infer<typeof inputSchema>
 
-function renderTemplate(html: string, data: Record<string, unknown>): string {
-  return html.replace(/\{(\w+)\}/g, (_, key) => String(data[key] ?? ''))
-}
-
 export const pdfGenerator: WorkflowDefinition = {
   config: {
-    resourceId: 'pdf-generator',
+    resourceId: 'pdf-generator-workflow',
     name: 'PDF Generator',
     type: 'workflow',
-    description: 'Generates a PDF from HTML template and uploads to storage',
+    description: 'Generates a PDF from structured content blocks and uploads to storage',
     version: '1.0.0',
     status: 'dev',
   },
@@ -87,17 +89,30 @@ export const pdfGenerator: WorkflowDefinition = {
     render: {
       id: 'render',
       name: 'Render PDF',
-      description: 'Render HTML template to PDF buffer',
+      description: 'Render a structured document to a PDF buffer',
       inputSchema,
       outputSchema: z.object({ buffer: z.string(), filename: z.string(), expiresInSeconds: z.number() }),
       handler: async (input) => {
-        const { templateHtml, data, filename, expiresInSeconds } = input as Input
-        const html = renderTemplate(templateHtml, data)
+        const { title, bodyText, tableHeaders, tableRows, filename, expiresInSeconds } = input as Input
+
+        const document = {
+          pages: [
+            {
+              sections: [
+                { type: 'text' as const, content: title, variant: 'title' as const },
+                { type: 'text' as const, content: bodyText, variant: 'body' as const },
+                ...(tableHeaders && tableRows
+                  ? [{ type: 'table' as const, headers: tableHeaders, rows: tableRows }]
+                  : []),
+              ],
+            },
+          ],
+        }
 
         const result = await platform.call({
           tool: 'pdf',
           method: 'renderToBuffer',
-          params: { html },
+          params: { document },
         }) as { buffer: string } // base64-encoded buffer
 
         return { buffer: result.buffer, filename, expiresInSeconds: expiresInSeconds ?? 3600 }
@@ -112,13 +127,15 @@ export const pdfGenerator: WorkflowDefinition = {
       outputSchema,
       handler: async (input, context) => {
         const { buffer, filename, expiresInSeconds } = input as { buffer: string; filename: string; expiresInSeconds: number }
-        const key = `documents/${filename}-${Date.now()}.pdf`
+        const bucket = 'documents'
+        const path = `${filename}-${Date.now()}.pdf`
 
         await platform.call({
           tool: 'storage',
           method: 'upload',
           params: {
-            key,
+            bucket,
+            path,
             content: buffer,
             contentType: 'application/pdf',
           },
@@ -127,11 +144,11 @@ export const pdfGenerator: WorkflowDefinition = {
         const urlResult = await platform.call({
           tool: 'storage',
           method: 'createSignedUrl',
-          params: { key, expiresIn: expiresInSeconds },
+          params: { bucket, path, expiresIn: expiresInSeconds },
         }) as { signedUrl: string; expiresAt: string }
 
-        context.logger.info(`PDF generated and uploaded: ${filename} at ${key}`)
-        return { downloadUrl: urlResult.signedUrl, storageKey: key, expiresAt: urlResult.expiresAt }
+        context.logger.info(`PDF generated and uploaded: ${filename} at ${bucket}/${path}`)
+        return { downloadUrl: urlResult.signedUrl, storageKey: `${bucket}/${path}`, expiresAt: urlResult.expiresAt }
       },
       next: null,
     },
@@ -144,11 +161,12 @@ export const pdfGenerator: WorkflowDefinition = {
 
 ## Adaptation Notes
 
-- **Template format:** The simple `{variable}` placeholder system handles most cases. For complex documents, suggest the user write a more complete HTML template with inline CSS.
+- **Content blocks:** The `pdf` tool renders a JSON document tree, not HTML. This template covers `text` and `table` blocks; add `metric`, `list`, `card`, or `columns` blocks to `sections` for richer layouts.
+- **Storage bucket:** The template hardcodes `bucket = 'documents'`. Ask the user what bucket name their organization's platform storage is configured to use.
 - **Filename:** The template appends a timestamp to avoid collisions. Adapt naming to the user's convention (e.g., `invoice-{invoiceId}`).
 - **Expiry:** Default is 1 hour. For document delivery workflows, increase to 24-72 hours.
-- **Data structure:** Ask the user what fields their document needs before defining the `data` schema. For typed use cases (invoices, reports), define a stricter input schema.
-- **Skill adaptation:** For beginners, show a complete example HTML template and explain what "template variables" are.
+- **Data structure:** Ask the user what fields their document needs before defining the input schema and mapping it into `sections`. For typed use cases (invoices, reports), add more input fields and a matching table row or card per field group.
+- **Skill adaptation:** For beginners, walk through the difference between a JSON document tree and an HTML template before generating code.
 
 ---