@elevasis/sdk 1.0.1 → 1.1.0

package/dist/types/worker/index.d.ts

@@ -26,8 +26,8 @@
  *   Worker -> Parent:  { type: 'credential-request', id, name }
  *   Parent -> Worker:  { type: 'credential-result', id, provider?, credentials?, error?, code? }
  */
-import type { OrganizationResources } from '../index.js';
+import type { DeploymentSpec } from '../index.js';
 export { platform, PlatformToolError } from './platform.js';
 export type { PlatformCredential } from './platform.js';
 export * from './adapters/index.js';
-export declare function startWorker(org: OrganizationResources): void;
+export declare function startWorker(org: DeploymentSpec): void;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@elevasis/sdk",
-  "version": "1.0.1",
+  "version": "1.1.0",
   "description": "SDK for building Elevasis organization resources",
   "type": "module",
   "bin": {
@@ -14,10 +14,6 @@
     "./worker": {
       "types": "./dist/types/worker/index.d.ts",
       "import": "./dist/worker/index.js"
-    },
-    "./templates": {
-      "types": "./dist/types/templates.d.ts",
-      "import": "./dist/templates.js"
     }
   },
   "files": [
@@ -28,8 +24,6 @@
     "dist/types/worker/platform.d.ts",
     "dist/types/worker/adapters/",
     "dist/cli.cjs",
-    "dist/templates.js",
-    "dist/types/templates.d.ts",
     "reference/"
   ],
   "dependencies": {
@@ -50,8 +44,8 @@
     "tsup": "^8.0.0",
     "typescript": "5.9.2",
     "zod": "^4.1.0",
-    "@repo/typescript-config": "0.0.0",
-    "@repo/core": "0.0.0"
+    "@repo/core": "0.0.0",
+    "@repo/typescript-config": "0.0.0"
   },
   "scripts": {
     "build": "node -e \"require('fs').rmSync('dist',{recursive:true,force:true})\" && tsc -p tsconfig.core-dts.json && tsc -p tsconfig.build.json && tsup && rollup -c rollup.dts.config.mjs && esbuild src/cli/index.ts --bundle --platform=node --outfile=dist/cli.cjs --format=cjs --external:esbuild --banner:js=\"#!/usr/bin/env node\" && node scripts/copy-reference-docs.mjs && node scripts/generate-navigation.mjs",

package/reference/_navigation.md

@@ -8,7 +8,7 @@ All paths are relative to `node_modules/@elevasis/sdk/reference/`.
 
 | Resource | Location | Description | When to Load |
 | --- | --- | --- | --- |
-| CLI Reference | `cli.mdx` | Full reference for every elevasis-sdk CLI command -- scaffold, validate, deploy, execute, and inspect resources | Running CLI operations |
+| CLI Reference | `cli.mdx` | Full reference for every elevasis-sdk CLI command -- validate, deploy, execute, and inspect resources | Running CLI operations |
 | Concepts Reference | `concepts.mdx` | Plain-English explanations of Elevasis SDK concepts -- glossary, workflow analogies, Zod schemas, execution model, platform tools, common errors, and design decisions | User asks what is or needs conceptual grounding |
 | Getting Started | `getting-started.mdx` | Install the Elevasis SDK, scaffold a project, and run your first deployment | Setting up a new project or onboarding |
 | Elevasis SDK | `index.mdx` | Build and deploy workflows, agents, and resources with the Elevasis SDK | First session or new to the SDK |
@@ -48,7 +48,7 @@ All paths are relative to `node_modules/@elevasis/sdk/reference/`.
 
 | Resource | Location | Description | When to Load |
 | --- | --- | --- | --- |
-| Writing Resources | `resources/index.mdx` | Guide to creating workflows and agents using WorkflowDefinition, AgentDefinition, and OrganizationResources with the Elevasis SDK | Building or modifying a workflow |
+| Writing Resources | `resources/index.mdx` | Guide to creating workflows and agents using WorkflowDefinition, AgentDefinition, and DeploymentSpec with the Elevasis SDK | Building or modifying a workflow |
 | Common Patterns | `resources/patterns.mdx` | Common resource patterns for Elevasis SDK developers -- sequential steps, conditional branching, platform tools, error handling, and resource status management | Building or modifying a workflow |
 | SDK Types | `resources/types.mdx` | Complete type reference for @elevasis/sdk -- package exports, re-exported platform types, ElevasConfig interface, StepHandler context, and runtime values | Looking up type signatures or SDK exports |
 

package/reference/cli.mdx

@@ -1,10 +1,10 @@
 ---
 title: CLI Reference
-description: Full reference for every elevasis-sdk CLI command -- scaffold, validate, deploy, execute, and inspect resources
+description: Full reference for every elevasis-sdk CLI command -- validate, deploy, execute, and inspect resources
 loadWhen: "Running CLI operations"
 ---
 
-The `elevasis-sdk` CLI is the primary interface for working with your Elevasis SDK project. Install it as part of `@elevasis/sdk` and use it to scaffold projects, validate resource definitions, deploy to the platform, and inspect execution history.
+The `elevasis-sdk` CLI is the primary interface for working with your Elevasis SDK project. Install it as part of `@elevasis/sdk` and use it to validate resource definitions, deploy to the platform, and inspect execution history.
 
 **Installation:**
 
@@ -16,117 +16,6 @@ After installation, the `elevasis-sdk` binary is available in your project's `no
 
 ---
 
-## elevasis-sdk init
-
-Scaffold a new Elevasis SDK project in the specified directory.
-
-**Synopsis:**
-
-```
-elevasis-sdk init [directory]
-```
-
-**Behavior:**
-
-- Derives the organization slug from the directory name
-- Checks for file conflicts before writing any files
-- Scaffolds project structure including `src/index.ts`, `elevasis.config.ts`, `package.json`, `tsconfig.json`, and a `CLAUDE.md` with CLI reference and SDK patterns
-- Non-interactive: all values are derived automatically
-
-**Flags:**
-
-| Flag   | Description                                       |
-| ------ | ------------------------------------------------- |
-| (none) | Uses current directory if no argument is provided |
-
-**Example:**
-
-```bash
-elevasis-sdk init my-project
-```
-
-You can also run `init` without a global install using `pnpm dlx`:
-
-```bash
-pnpm dlx @elevasis/sdk init my-project
-```
-
-```
-  Scaffolding my-project/...
-
-  Created 30 files.
-
-  Next steps:
-    cd my-project
-    pnpm install
-    elevasis-sdk check
-```
-
----
-
-## elevasis-sdk update
-
-Update managed project files to the latest template version.
-
-**Synopsis:**
-
-```
-elevasis-sdk update [--ui]
-```
-
-**Behavior:**
-
-- Reads `elevasis.config.ts` to get the current `templateVersion` and compares it against the latest template version
-- If already up to date (and no `--ui` flag), exits early with a success message
-- For each managed file:
-  - Missing files are written directly
-  - `.gitignore` uses append-only merge -- new entries are added, existing entries are never removed
-  - `elevasis.config.ts` gets only its `templateVersion` field updated
-  - `CLAUDE.md` uses section-aware merge -- SDK-owned sections are replaced with the latest template, user-added sections are preserved
-  - All other managed files are compared against the template and flagged for review if they differ
-- Pass `--ui` to scaffold a Vite + React UI app in `ui/` (can be combined with a version update or run independently)
-
-**Flags:**
-
-| Flag   | Description                             |
-| ------ | --------------------------------------- |
-| `--ui` | Add a Vite + React UI scaffold in `ui/` |
-
-**Example output (version update):**
-
-```
-$ elevasis-sdk update
-
-  Updated @elevasis/sdk template v24 -> v27
-
-  Added:
-    .env.example
-
-  Appended to .gitignore:
-    ui/dist
-
-  Needs agent review:
-    tsconfig.json (differs from template)
-
-  CLAUDE.md sections:
-    updated: Commands
-    updated: Skills
-    preserved: Custom Workflows
-
-  Run /meta update in Claude Code to merge flagged files.
-  Or run /meta fix to verify and repair the full framework.
-```
-
-**Example output (already up to date):**
-
-```
-$ elevasis-sdk update
-
-  Project is up to date (template version 27)
-```
-
----
-
 ## elevasis-sdk check
 
 Validate all resource definitions in your project without deploying.

package/reference/deployment/command-center.mdx

@@ -23,7 +23,7 @@ The Command Center is the browser UI for interacting with deployed resources. Af
 
 ## Command View
 
-The Command View is a visual graph of your deployed resources. Each node is a resource (workflow, agent, trigger, integration). Edges are the relationships you declared in `OrganizationResources`.
+The Command View is a visual graph of your deployed resources. Each node is a resource (workflow, agent, trigger, integration). Edges are the relationships you declared in `DeploymentSpec`.
 
 **What you can do here:**
 
@@ -54,10 +54,10 @@ Every resource you deploy becomes a node in the graph. Some nodes are executable
 
 ### Relationships
 
-Relationships are edges in the graph. Declare them in `OrganizationResources`:
+Relationships are edges in the graph. Declare them in `DeploymentSpec`:
 
 ```typescript
-const org: OrganizationResources = {
+const org: DeploymentSpec = {
   workflows: [scoreLeadWorkflow, sendProposalWorkflow],
   relationships: {
     'score-lead': {
@@ -98,7 +98,7 @@ Keep relationships in sync with your handler code. When you add an `execution.tr
 `elevasis-sdk deploy` and `elevasis-sdk check` both validate:
 
 - Duplicate resource IDs
-- Relationship targets must exist in the same `OrganizationResources`
+- Relationship targets must exist in the same `DeploymentSpec`
 - Agent model params (provider, model name, temperature bounds)
 - Workflow step chains (`next.target` must point to existing step names)
 
@@ -106,14 +106,14 @@ Keep relationships in sync with your handler code. When you add an `execution.tr
 
 ```
 ERROR  Relationship target 'send-proposal' not found in organization resources
-ERROR  Duplicate resource ID 'score-lead' in organization
+ERROR  Duplicate resource ID 'score-lead' in deployment
 ```
 
 ### Graph Serialization
 
 The platform converts your definitions into `CommandViewNode` (one per resource) and `CommandViewEdge` (one per relationship) structures. `buildEdges()` reads your `relationships` declarations and produces edges as a pure transformation -- no runtime behavior is inferred.
 
-> **SDK takeaway:** Declare relationships in `OrganizationResources` to keep the Command View accurate as your system grows. Update declarations whenever you add or remove `execution.trigger()` calls.
+> **SDK takeaway:** Declare relationships in `DeploymentSpec` to keep the Command View accurate as your system grows. Update declarations whenever you add or remove `execution.trigger()` calls.
 
 ---
 

package/reference/deployment/index.mdx

@@ -107,7 +107,7 @@ The CLI also accepts a `--api-url` flag on every command, which takes priority o
 ELEVASIS_PLATFORM_KEY=sk_***
 ```
 
-Place `.env` in your project root. The CLI reads it automatically. Never commit this file.
+Place `.env` in your project root. The CLI walks up directories to find it, so running from subdirectories like `operations/` works automatically. Never commit this file.
 
 ---
 

package/reference/framework/index.mdx

@@ -179,4 +179,14 @@ Section templates by doc type:
 
 ---
 
+## Documentation
+
+- [Project Structure](project-structure.mdx) - File-by-file walkthrough of every scaffolded file and its purpose
+- [Agent System](agent.mdx) - CLAUDE.md sections, slash commands, developer profile, and adaptive guidance tiers
+- [Memory System](memory.mdx) - Architecture, error tracking format, scaling rules, and maintenance guidelines
+- [Interaction Guidance](interaction-guidance.mdx) - Dimensional adaptation rules per skill axis with growth tracking protocol
+- [Tutorial System](tutorial-system.mdx) - 21-item tutorial menu, skill-adaptive lesson variants, and progress tracking
+
+---
+
 **Last Updated:** 2026-03-06

package/reference/framework/project-structure.mdx

@@ -12,14 +12,14 @@ loadWhen: "Understanding scaffolded files or project layout"
 
 ### `src/index.ts`
 
-The registry entry point for your workspace. This file aggregates resources from domain barrel files and re-exports them as an `OrganizationResources` default export. It does not contain workflow logic itself -- its sole job is aggregation:
+The registry entry point for your workspace. This file aggregates resources from domain barrel files and re-exports them as a `DeploymentSpec` default export. It does not contain workflow logic itself -- its sole job is aggregation:
 
 ```ts
-import type { OrganizationResources } from '@elevasis/sdk'
+import type { DeploymentSpec } from '@elevasis/sdk'
 import * as operations from './operations/index.js'
 import * as example from './example/index.js'
 
-const org: OrganizationResources = {
+const org: DeploymentSpec = {
   workflows: [
     ...operations.workflows,
     ...example.workflows,
@@ -48,19 +48,18 @@ Cross-domain shared types and utilities. This directory starts empty (`.gitkeep`
 
 ### `elevasis.config.ts`
 
-Project-level configuration. The scaffolded file includes `templateVersion`, which tracks which template generation your project uses, plus commented-out options (`defaultStatus`, `dev.port`) so you can discover available settings without looking them up:
+Project-level configuration. The scaffolded file includes commented-out options (`defaultStatus`, `dev.port`) so you can discover available settings without looking them up:
 
 ```ts
 import type { ElevasConfig } from '@elevasis/sdk'
 
 export default {
-  templateVersion: 28,
   // defaultStatus: 'dev',     // Default status for new resources ('dev' | 'prod')
   // dev: { port: 5170 },      // Local API port (internal development only)
 } satisfies ElevasConfig
 ```
 
-Leave this file minimal -- the platform provides sensible defaults. Do not remove `templateVersion`; it is read by `elevasis-sdk update` to determine which template changes need to be applied to your project.
+Leave this file minimal -- the platform provides sensible defaults.
 
 ---
 
@@ -187,7 +186,7 @@ The most important file for AI-assisted development. It provides Claude Code wit
 
 - **Project orientation** -- what an Elevasis SDK project is and how it works
 - **Project structure** -- which files contain resources, documentation, and configuration
-- **SDK patterns** -- working code examples for resource definitions, Zod schemas, and the `OrganizationResources` export
+- **SDK patterns** -- working code examples for resource definitions, Zod schemas, and the `DeploymentSpec` export
 - **CLI reference** -- all commands with flags (`check`, `deploy`, `exec`, `resources`, `executions`, `execution`, `deployments`, `env list/set/remove`)
 - **Development rules** -- conventions the agent should enforce (source in `src/`, docs in `docs/`, use `@elevasis/sdk` types only)
 

package/reference/framework/tutorial-system.mdx

@@ -3,7 +3,7 @@ title: Tutorial System
 description: Reference for the SDK tutorial system -- 21-item menu across 4 sections, skill-level adaptation rules, progress tracking format, and per-lesson module contents
 ---
 
-The tutorial system is available via the `/tutorial` slash command in Claude Code. It is scaffolded by `elevasis-sdk init` and updated by `elevasis-sdk update`.
+The tutorial system is available via the `/tutorial` slash command in Claude Code. It is included in the external template project scaffold.
 
 ---
 
@@ -179,7 +179,7 @@ Modules are available any time -- no core path prerequisite. After completing a
 
 - `none` -- "SDK releases automatically update your workspace." Explain `/meta fix` as the update command.
 - `low-code` -- Explain MANAGED vs INIT_ONLY file types. Show how `/meta fix` handles conflicts.
-- `custom` -- Full template lifecycle: init (writes all files), update (applies MANAGED changes, flags conflicts, preserves INIT_ONLY), fix (drift repair + SDK upgrade offer). Conflict resolution reads current + template from `@elevasis/sdk/templates`, merges preserving customizations.
+- `custom` -- Full template lifecycle: the external template handles initial project creation. `/meta fix` performs drift repair and SDK upgrade. Conflict resolution merges current files against the template, preserving customizations in INIT_ONLY files.
 
 ---
 

package/reference/getting-started.mdx

@@ -57,7 +57,7 @@ my-project/
 │   ├── index.mdx                   # Starter documentation page
 │   └── in-progress/
 │       └── .gitkeep                # Work-in-progress docs directory
-├── elevasis.config.ts              # Config with templateVersion and options
+├── 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
@@ -66,16 +66,6 @@ my-project/
 └── .gitignore                      # Excludes worker temp file, claude files
 ```
 
-The scaffolded `elevasis.config.ts` includes a `templateVersion` field that tracks which template generation your project uses. Leave it as-is -- it is managed automatically by `elevasis-sdk update`:
-
-```ts
-import type { ElevasConfig } from '@elevasis/sdk'
-
-export default {
-  templateVersion: 27,
-} satisfies ElevasConfig
-```
-
 ### Set Up Your API Key
 
 Open `.env` and set your API key:

package/reference/index.mdx

@@ -8,6 +8,8 @@ loadWhen: "First session or new to the SDK"
 
 Workflows are step-based automations with typed inputs and outputs. Agents are autonomous AI resources with access to platform tools. Both are defined in TypeScript, exported from a single entry point, and deployed with `elevasis-sdk deploy`. Resources appear in AI Studio immediately after a successful deploy.
 
+The SDK ships with a full CLI (`elevasis-sdk`) for validation, deployment, execution, and inspection. Platform tools expose 70+ integrations across 12 adapters -- Gmail, Stripe, Google Sheets, Attio, and more -- with credentials managed server-side so API keys never cross the execution boundary.
+
 ## Quick Start
 
 ```bash
@@ -75,9 +77,22 @@ See [Platform Tools](platform-tools/index.mdx) for the full catalog.
 ### Framework
 
 - [Development Framework](framework/index.mdx) - How Claude Code helps you build: project structure, agent integration, memory, and documentation
+- [Project Structure](framework/project-structure.mdx) - Scaffolded file layout, domain barrels, src/index.ts entry point, and config files
+- [Agent Configuration](framework/agent.mdx) - Agent capabilities, tool access, model config, and Claude Code integration patterns
+- [Memory](framework/memory.mdx) - Agent memory system, session state, developer profiles, and workspace conventions
 - [Interaction Guidance](framework/interaction-guidance.mdx) - Skill dimension adaptation rules for platform navigation, API integration, and automation concepts
 - [Tutorial System](framework/tutorial-system.mdx) - 21-item tutorial menu, skill-adaptive lesson variants, progress tracking, and module contents
 
+### Resources Subpages
+
+- [SDK Types](resources/types.mdx) - Complete type reference for `@elevasis/sdk` exports, config fields, and step handler context
+- [Common Patterns](resources/patterns.mdx) - Sequential steps, conditional branching, error handling, and resource status patterns
+
+### Deployment Subpages
+
+- [Command Center](deployment/command-center.mdx) - Resource graph, relationships, node types, and post-deployment UI reference
+- [Execution API](deployment/api.mdx) - REST endpoints for executing resources and managing deployments
+
 ### More
 
 - [Troubleshooting](troubleshooting.mdx) - Static error catalog for CLI, deployment, schema, and runtime failures
@@ -85,4 +100,4 @@ See [Platform Tools](platform-tools/index.mdx) for the full catalog.
 
 ---
 
-**Last Updated:** 2026-03-19
+**Last Updated:** 2026-04-05

package/reference/platform-tools/index.mdx

@@ -40,7 +40,7 @@ Both patterns return a Promise that resolves with the tool result or rejects wit
 
 ## Integration Adapters
 
-Twelve integration adapters give you access to 58+ tool methods covering third-party APIs. Pass the credential name once at adapter creation. Supabase is listed separately under [Database Access](#database-access) below.
+Ten integration adapters give you access to 50+ tool methods covering third-party APIs. Pass the credential name once at adapter creation. Supabase is listed separately under [Database Access](#database-access) below.
 
 | Adapter       | Tools                         | Credential Shape         |
 | ------------- | ----------------------------- | ------------------------ |
@@ -54,7 +54,6 @@ Twelve integration adapters give you access to 58+ tool methods covering third-p
 | Resend        | 2 (send/get email)            | `{ apiKey }`             |
 | Dropbox       | 2 (upload/folder)             | `{ accessToken }`        |
 | Apify         | 1 (run actor)                 | `{ token }`              |
-| Mailso        | 1 (verify email)              | `{ apiKey }`             |
 
 ## Credential Security
 
@@ -209,8 +208,9 @@ const qualified = await platform.call({
 
 ## Documentation
 
-- [Integration Adapters](adapters-integration.mdx) - All 12 integration adapters with method tables and code examples
+- [Integration Adapters](adapters-integration.mdx) - All 10 integration adapters with method tables and code examples
 - [Platform Adapters](adapters-platform.mdx) - All 9 platform service adapters with method tables and code examples
+- [Adapter Type Safety](type-safety.mdx) - Required fields, discriminated unions, and intentionally loose adapter types
 
 ---
 

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

@@ -25,9 +25,9 @@ await llm.generate({
 })
 ```
 
-### Email Adapter — `domain` (AnyMailFinder)
+### Tomba Adapter — `domain` and `email`
 
-`domain` is required on `FindCompanyEmailParams` and `FindPersonEmailParams`. Previously all params were optional, allowing `findCompanyEmail({})` to compile but fail at runtime. The type change enforces the one field that is always necessary for email discovery.
+`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.
 
 ---
 

package/reference/resources/index.mdx

@@ -1,12 +1,12 @@
 ---
 title: Writing Resources
-description: Guide to creating workflows and agents using WorkflowDefinition, AgentDefinition, and OrganizationResources with the Elevasis SDK
+description: Guide to creating workflows and agents using WorkflowDefinition, AgentDefinition, and DeploymentSpec with the Elevasis SDK
 loadWhen: "Building or modifying a workflow"
 ---
 
 Resources are the building blocks of your Elevasis project. A resource is a workflow or agent definition that the platform can execute on your behalf. You define them in TypeScript, export them from a single entry point, and the platform handles scheduling, retries, logging, and execution.
 
-This page covers how to structure your resources, write step handlers, and export everything through `OrganizationResources`.
+This page covers how to structure your resources, write step handlers, and export everything through `DeploymentSpec`.
 
 ## WorkflowDefinition
 
@@ -289,14 +289,14 @@ const myAgent: AgentDefinition = {
 
 ---
 
-## OrganizationResources
+## DeploymentSpec
 
-All resources must be exported through an `OrganizationResources` default export from `src/index.ts`. This is the entry point the platform reads when you deploy.
+All resources must be exported through a `DeploymentSpec` default export from `src/index.ts`. This is the entry point the platform reads when you deploy.
 
 ```typescript
-import type { OrganizationResources } from '@elevasis/sdk';
+import type { DeploymentSpec } from '@elevasis/sdk';
 
-const org: OrganizationResources = {
+const org: DeploymentSpec = {
   workflows: [echoWorkflow, pipeline],
   agents: [
     // myAgent,

package/reference/resources/patterns.mdx

@@ -330,11 +330,11 @@ export const workflows = [sendInvoice];
 export const agents = [];
 
 // src/index.ts
-import type { OrganizationResources } from '@elevasis/sdk';
+import type { DeploymentSpec } from '@elevasis/sdk';
 import * as orders from './orders/index.js';
 import * as billing from './billing/index.js';
 
-const org: OrganizationResources = {
+const org: DeploymentSpec = {
   workflows: [
     ...orders.workflows,
     ...billing.workflows,

package/reference/resources/types.mdx

@@ -45,7 +45,7 @@ All types come from the platform core. The SDK re-exports them grouped by source
 | `ResourceStatus`        | Enum: `'dev' | 'prod'`                         |
 | `ResourceDomain`        | Domain classification for a resource            |
 | `DomainDefinition`      | Structure for grouping resources by domain      |
-| `OrganizationResources` | Top-level export shape: `{ workflows, agents }` |
+| `DeploymentSpec`        | Top-level export shape: `{ workflows, agents }` |
 | `TriggerDefinition`     | Base for trigger configuration                  |
 | `IntegrationDefinition` | Integration configuration structure             |
 | `WebhookProviderType`   | Supported webhook providers                     |

package/reference/runtime.mdx

@@ -109,7 +109,7 @@ v1 versioning is intentionally simple:
 
 ### Deletion
 
-- **Via CLI:** Remove the resource from your `OrganizationResources` export and run `elevasis-sdk deploy`. Resources absent from the new bundle are automatically deregistered from the platform.
+- **Via CLI:** Remove the resource from your `DeploymentSpec` export and run `elevasis-sdk deploy`. Resources absent from the new bundle are automatically deregistered from the platform.
 - **Via AI Studio:** The delete button unregisters the resource immediately and marks the deployment stopped.
 - **In-flight executions:** Workers already running complete normally. Deletion affects only new execution attempts.
 - **Data retention:** Execution logs and history for a deleted resource are retained for 30 days, then purged.

package/reference/templates/index.mdx

@@ -11,17 +11,17 @@ All templates are available for any organization. Credentials specific to each t
 
 ## Documentation
 
-### Data Collection
+### 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
+### 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
+### 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

package/reference/troubleshooting.mdx

@@ -1,6 +1,6 @@
 ---
-title: "Common Errors"
-description: "Static SDK-level error catalog -- CLI errors, deployment errors, schema validation, platform tool failures, and runtime errors with diagnostic steps"
+title: Common Errors
+description: Static SDK-level error catalog -- CLI errors, deployment errors, schema validation, platform tool failures, and runtime errors with diagnostic steps
 loadWhen: "Debugging an unknown error not found in workspace memory"
 ---
 
@@ -16,9 +16,9 @@ This is the static SDK-level error catalog. Check `.claude/memory/errors/` first
 
 **Fix:**
 
-1. Check that `.env` exists in the workspace root
+1. Check that `.env` exists in the project root (or any parent directory)
 2. Confirm it contains `ELEVASIS_PLATFORM_KEY=sk_...`
-3. Make sure you are running the CLI from the workspace directory (where `.env` is located)
+3. The CLI walks up directories to find `.env`, so running from subdirectories like `operations/` works automatically
 4. If the file exists with the right content, run `elevasis-sdk check` again
 
 ### Cannot connect to API