@elevasis/sdk 0.5.12 → 0.5.14

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (37) hide show
  1. package/dist/cli.cjs +144 -118
  2. package/dist/index.d.ts +19 -253
  3. package/dist/index.js +20 -9
  4. package/dist/templates.js +62 -59
  5. package/dist/types/worker/adapters/index.d.ts +0 -1
  6. package/dist/worker/index.js +47 -53
  7. package/package.json +1 -1
  8. package/reference/_navigation.md +13 -57
  9. package/reference/{cli/index.mdx → cli.mdx} +568 -505
  10. package/reference/concepts.mdx +164 -0
  11. package/reference/deployment/api.mdx +297 -297
  12. package/reference/deployment/command-center.mdx +226 -0
  13. package/reference/deployment/index.mdx +158 -153
  14. package/reference/framework/agent.mdx +156 -151
  15. package/reference/framework/index.mdx +182 -103
  16. package/reference/{developer → framework}/interaction-guidance.mdx +182 -182
  17. package/reference/framework/memory.mdx +326 -347
  18. package/reference/framework/project-structure.mdx +277 -298
  19. package/reference/framework/tutorial-system.mdx +222 -0
  20. package/reference/{getting-started/index.mdx → getting-started.mdx} +152 -148
  21. package/reference/index.mdx +131 -114
  22. package/reference/platform-tools/adapters.mdx +868 -929
  23. package/reference/platform-tools/index.mdx +354 -195
  24. package/reference/resources/index.mdx +339 -336
  25. package/reference/resources/patterns.mdx +355 -354
  26. package/reference/resources/types.mdx +207 -207
  27. package/reference/{roadmap/index.mdx → roadmap.mdx} +163 -147
  28. package/reference/{runtime/index.mdx → runtime.mdx} +173 -141
  29. package/reference/{troubleshooting/common-errors.mdx → troubleshooting.mdx} +223 -210
  30. package/dist/types/worker/adapters/trello.d.ts +0 -14
  31. package/reference/concepts/index.mdx +0 -203
  32. package/reference/deployment/command-center-ui.mdx +0 -151
  33. package/reference/deployment/command-view.mdx +0 -154
  34. package/reference/framework/documentation.mdx +0 -92
  35. package/reference/platform-tools/examples.mdx +0 -170
  36. package/reference/runtime/limits.mdx +0 -75
  37. package/reference/security/credentials.mdx +0 -141
@@ -0,0 +1,164 @@
1
+ ---
2
+ title: Concepts Reference
3
+ description: Plain-English explanations of Elevasis SDK concepts -- glossary, workflow analogies, Zod schemas, execution model, platform tools, common errors, and design decisions
4
+ loadWhen: "User asks what is or needs conceptual grounding"
5
+ ---
6
+
7
+ This page covers core Elevasis concepts in plain English. It is the teaching vocabulary for the agent when helping you build workflows, and a reference you can return to whenever a term or behavior is unclear.
8
+
9
+ ## Glossary
10
+
11
+ | Term | Definition |
12
+ | ------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
13
+ | Workflow | A series of named steps that run one after another. Each step does one job. The workflow receives input data and produces output data. |
14
+ | Agent | An autonomous AI resource with access to platform tools. Agents can make decisions and call tools on their own. Run agents with `--async` to avoid HTTP timeout limits on long-running executions. |
15
+ | Resource | Anything you deploy to the platform -- a workflow or an agent. Each resource has a unique ID. |
16
+ | Step | One job inside a workflow. A step receives data, processes it, and passes data to the next step. |
17
+ | Schema | A description of what your data looks like. Schemas validate that input and output data has the right shape -- the right fields with the right types. |
18
+ | Credential | A saved API key or login for an external service (Gmail, Attio, Stripe). Stored securely on the platform, never in your code. |
19
+ | Execution | One run of a resource. Each time someone triggers your workflow, that is one execution. |
20
+ | Deployment | The act of uploading your code to the platform. After deploying, your resources are live and can be executed. |
21
+ | Platform Tool | A pre-built integration the platform provides. You call platform tools from your workflow steps using `platform.call()`. |
22
+ | Organization | Your team or company on the Elevasis platform. Resources, credentials, and executions belong to an organization. |
23
+ | Handler | The function inside a step that does the actual work. It receives input data and returns output data. |
24
+ | Entry Point | The first step that runs when a workflow is executed. Every workflow must have one. |
25
+ | Resource ID | A unique lowercase name for your resource (e.g., `lead-scorer`, `send-welcome-email`). Must be unique within your organization. |
26
+ | Workspace | Your Elevasis project directory. Contains resources (workflows and agents), documentation, and optionally a database connection and custom apps. Created by `elevasis-sdk init`. |
27
+ | Data Table | A table in your database (e.g., Supabase) that stores structured data your workflows can read and write. Defined in `data/schema.ts` as documentation for the agent. |
28
+
29
+ ---
30
+
31
+ ## What is a Workflow?
32
+
33
+ A workflow is a piece of automation that runs on the Elevasis platform. You define the steps in TypeScript; the platform handles running them, logging results, and retrying on failure.
34
+
35
+ ### Two Analogies
36
+
37
+ **Recipe analogy:** A recipe has ingredients (input), instructions (steps), and a finished dish (output). Each instruction is one step. You follow them in order. If a step fails (you burn the sauce), the recipe stops.
38
+
39
+ **Assembly line analogy:** Raw material goes in one end (input). Each station does one job (step). The finished product comes out the other end (output).
40
+
41
+ ### When to Use a Workflow
42
+
43
+ - Automating a repeatable task with defined input and output
44
+ - Chaining multiple actions together (fetch data, process it, send an email)
45
+ - When you need the platform to handle execution, retries, and logging
46
+
47
+ ### When NOT to Use a Workflow
48
+
49
+ - One-off tasks you will only do once
50
+ - Tasks that need constant human judgment at every step
51
+
52
+ ---
53
+
54
+ ## Understanding Schemas (Zod)
55
+
56
+ ### What Schemas Do
57
+
58
+ Schemas describe and validate the shape of data your workflow expects and produces. If someone sends the wrong data, the platform rejects it before your code runs. This prevents confusing errors deep inside your handler.
59
+
60
+ The Elevasis SDK uses [Zod](https://zod.dev) for schema definition. Zod is a TypeScript-first validation library. Every workflow has an `inputSchema` and an `outputSchema`.
61
+
62
+ ### Common Zod Types
63
+
64
+ | Zod Type | What It Means | Example |
65
+ | -------------------------------- | ------------------------------- | ----------------------------- |
66
+ | `z.string()` | Text | `"hello"`, `"user@email.com"` |
67
+ | `z.number()` | A number | `42`, `3.14` |
68
+ | `z.boolean()` | True or false | `true`, `false` |
69
+ | `z.array(z.string())` | A list of text values | `["a", "b", "c"]` |
70
+ | `z.object({ name: z.string() })` | A group of named fields | `{ "name": "Jane" }` |
71
+ | `z.string().optional()` | Text that might be missing | `"hello"` or not provided |
72
+ | `z.enum(['a', 'b', 'c'])` | One of a specific set of values | `"a"` |
73
+ | `z.string().email()` | Text that must be a valid email | `"user@example.com"` |
74
+
75
+ ### Why `z.infer` Exists
76
+
77
+ `z.infer` creates a TypeScript type from a schema so the type system can check your code. You define the schema once and get both runtime validation and compile-time checking. Without it, you would have to define the same shape twice -- once as a Zod schema and once as a TypeScript type.
78
+
79
+ ```ts
80
+ const myInput = z.object({ name: z.string(), age: z.number() });
81
+ type MyInput = z.infer<typeof myInput>;
82
+ // MyInput is now: { name: string; age: number }
83
+ ```
84
+
85
+ ### Common Schema Mistakes
86
+
87
+ - Forgetting `.optional()` on fields that might be missing -- the platform will reject valid input that omits those fields
88
+ - Returning data from a handler that does not match the output schema -- causes `outputSchema validation failed`
89
+ - Misspelling field names -- the schema says `companyName`, but the handler returns `company_name`
90
+
91
+ ---
92
+
93
+ ## The Execution Model
94
+
95
+ ### What Happens When You Run a Workflow
96
+
97
+ 1. A request arrives at the Elevasis platform (someone runs `elevasis-sdk exec` or a schedule triggers)
98
+ 2. The platform creates a temporary server just for this execution
99
+ 3. Your code runs on that server
100
+ 4. The result is sent back
101
+ 5. The temporary server is deleted
102
+
103
+ ### Practical Implications
104
+
105
+ | What You Might Expect | What Actually Happens | Why |
106
+ | --------------------------- | ------------------------------------- | ----------------------------- |
107
+ | Files I create persist | Files disappear after execution | The server is temporary |
108
+ | I can see logs in real-time | Logs appear after execution completes | No streaming from workers |
109
+ | My code runs on my computer | Your code runs on Elevasis servers | That is what "deploy" means |
110
+ | I can use unlimited memory | 256MB memory limit per execution | Prevents runaway processes |
111
+ | Executions share state | Each execution is independent | No shared memory between runs |
112
+ | I can call external APIs | Yes, outbound network is unrestricted | Workers have internet access |
113
+
114
+ ### What "completed" vs "failed" Means
115
+
116
+ - **completed** -- Your code ran successfully and returned output
117
+ - **failed** -- Something went wrong: your code threw an error, timed out (300s default), or ran out of memory
118
+
119
+ ---
120
+
121
+ ## Platform Tools Overview
122
+
123
+ Platform tools are pre-built integrations the platform provides. You call them from inside workflow steps using `platform.call()` or typed adapters without managing API keys in your code. The platform supports 70+ tools across 12 categories including CRM, email, payments, AI, storage, and more. Credentials are stored securely on the platform and injected at runtime -- they never appear in your code.
124
+
125
+ See [Platform Tools](platform-tools/index.mdx) for the complete catalog, credential setup, and code examples.
126
+
127
+ ---
128
+
129
+ ## Common Errors (Quick Reference)
130
+
131
+ | Error | How to Fix |
132
+ | ----------------------------------------- | ------------------------------------------------------------------------------- |
133
+ | `ELEVASIS_PLATFORM_KEY not set` | Add `ELEVASIS_PLATFORM_KEY=sk_...` to `.env` |
134
+ | `Schema validation failed` | Compare error field names to your schema. Check types and required vs optional. |
135
+ | `Cannot find module '@elevasis/sdk'` | Run `pnpm install` |
136
+ | `PlatformToolError: credential not found` | Check spelling and case in the command center UI |
137
+ | `Execution timeout (300s)` | Optimize handler or break into smaller steps |
138
+ | `Cannot find name 'z'` | Add `import { z } from 'zod'` |
139
+ | `outputSchema validation failed` | Check field names, types, and required fields against output schema |
140
+ | `NODE_ENV=development` in .env | Remove `NODE_ENV` from `.env` |
141
+
142
+ For the full error catalog with detailed diagnostic steps, see [Troubleshooting](troubleshooting.mdx).
143
+
144
+ ---
145
+
146
+ ## Design Decisions Guide
147
+
148
+ ### Single-Step vs Multi-Step
149
+
150
+ Use a single step when the workflow does one thing -- validate an email, format a message, call one API.
151
+
152
+ Use multiple steps when you have distinct phases (fetch data, process it, send a notification) or when you want separate error handling per phase. Each step failure is logged independently, making it easier to identify where something went wrong.
153
+
154
+ ### When to Use Conditional Routing
155
+
156
+ Use `StepType.CONDITIONAL` when different inputs should follow different processing paths.
157
+
158
+ Example: score >= 80 goes to the approve path, score >= 50 goes to the review path, everything else goes to the reject path. Each path can have its own steps and logic.
159
+
160
+ Always include a `default` fallback step for inputs that do not match any condition. Without a fallback, an unmatched execution will fail.
161
+
162
+ ---
163
+
164
+ **Last Updated:** 2026-02-26