@elevasis/sdk 1.1.0 → 1.3.0
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.
- package/dist/cli.cjs +74 -515
- package/dist/index.d.ts +1067 -613
- package/dist/types/worker/adapters/index.d.ts +1 -0
- package/dist/types/worker/adapters/lead.d.ts +1 -1
- package/dist/types/worker/adapters/list.d.ts +9 -0
- package/dist/worker/index.js +20 -3
- package/package.json +6 -4
- package/reference/_navigation.md +6 -55
- package/reference/_reference-manifest.json +437 -0
- package/reference/cli.mdx +75 -3
- package/reference/deployment/index.mdx +2 -1
- package/reference/deployment/provided-features.mdx +259 -0
- package/reference/deployment/ui-execution.mdx +251 -0
- package/reference/index.mdx +5 -3
- package/reference/platform-tools/adapters-platform.mdx +93 -36
- package/reference/resources/patterns.mdx +48 -0
package/reference/cli.mdx
CHANGED
|
@@ -1,10 +1,10 @@
|
|
|
1
1
|
---
|
|
2
2
|
title: CLI Reference
|
|
3
|
-
description: Full reference for every elevasis-sdk CLI command -- validate, deploy, execute, and
|
|
3
|
+
description: Full reference for every elevasis-sdk CLI command -- validate, deploy, execute, inspect resources, and operate project-management surfaces
|
|
4
4
|
loadWhen: "Running CLI operations"
|
|
5
5
|
---
|
|
6
6
|
|
|
7
|
-
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,
|
|
7
|
+
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, inspect execution history, and work with the shared project-management API surfaces.
|
|
8
8
|
|
|
9
9
|
**Installation:**
|
|
10
10
|
|
|
@@ -503,6 +503,78 @@ elevasis-sdk rename ist-upload-workflow --to ist-upload-contacts-workflow --exec
|
|
|
503
503
|
|
|
504
504
|
---
|
|
505
505
|
|
|
506
|
+
## elevasis-sdk project:*
|
|
507
|
+
|
|
508
|
+
Project-management commands operate on the shared delivery system used by packaged Projects pages and task-oriented agent workflows.
|
|
509
|
+
|
|
510
|
+
### Projects
|
|
511
|
+
|
|
512
|
+
```bash
|
|
513
|
+
elevasis-sdk project:list
|
|
514
|
+
elevasis-sdk project:get <id>
|
|
515
|
+
elevasis-sdk project:create --name "Website Refresh" --kind client_engagement
|
|
516
|
+
elevasis-sdk project:update <id> --status completed
|
|
517
|
+
elevasis-sdk project:delete <id>
|
|
518
|
+
```
|
|
519
|
+
|
|
520
|
+
**Behavior:**
|
|
521
|
+
|
|
522
|
+
- `project:list` filters by `--kind` and `--status`
|
|
523
|
+
- `project:get` returns a single project
|
|
524
|
+
- `project:create` and `project:update` operate on `/api/external/projects`
|
|
525
|
+
|
|
526
|
+
### Milestones
|
|
527
|
+
|
|
528
|
+
```bash
|
|
529
|
+
elevasis-sdk project:milestone:list --project <id>
|
|
530
|
+
elevasis-sdk project:milestone:create --project <id> --name "Phase 1"
|
|
531
|
+
elevasis-sdk project:milestone:update <id> --status completed
|
|
532
|
+
elevasis-sdk project:milestone:delete <id>
|
|
533
|
+
```
|
|
534
|
+
|
|
535
|
+
### Tasks
|
|
536
|
+
|
|
537
|
+
```bash
|
|
538
|
+
elevasis-sdk project:task:list --project <id>
|
|
539
|
+
elevasis-sdk project:task:get <id>
|
|
540
|
+
elevasis-sdk project:task:create --project <id> --title "Implement API"
|
|
541
|
+
elevasis-sdk project:task:update <id> --status in_progress
|
|
542
|
+
elevasis-sdk project:task:delete <id>
|
|
543
|
+
```
|
|
544
|
+
|
|
545
|
+
Task commands also expose agent-oriented resume state:
|
|
546
|
+
|
|
547
|
+
```bash
|
|
548
|
+
elevasis-sdk project:task:resume <id> --pretty
|
|
549
|
+
elevasis-sdk project:task:save <id> --current-state "Implemented the route layer"
|
|
550
|
+
```
|
|
551
|
+
|
|
552
|
+
- `project:task:resume` reads the task's `resume_context`
|
|
553
|
+
- `project:task:save` merges fields into `resume_context`
|
|
554
|
+
- these commands are the CLI counterpart to `/work resume` and `/work save` style flows
|
|
555
|
+
|
|
556
|
+
### Notes
|
|
557
|
+
|
|
558
|
+
```bash
|
|
559
|
+
elevasis-sdk project:note:list --project <id>
|
|
560
|
+
elevasis-sdk project:note:create --project <id> --content "Client approved scope"
|
|
561
|
+
elevasis-sdk project:note:update <id> --content "Updated status"
|
|
562
|
+
elevasis-sdk project:note:delete <id>
|
|
563
|
+
```
|
|
564
|
+
|
|
565
|
+
### Shared Flags
|
|
566
|
+
|
|
567
|
+
Most `project:*` commands support:
|
|
568
|
+
|
|
569
|
+
| Flag | Description |
|
|
570
|
+
| ---- | ----------- |
|
|
571
|
+
| `--pretty` | Human-readable terminal output instead of raw JSON |
|
|
572
|
+
| `--api-url <url>` | Override the API base URL |
|
|
573
|
+
|
|
574
|
+
For exact required flags and accepted enum values, see the command source under `packages/sdk/src/cli/commands/project/`.
|
|
575
|
+
|
|
576
|
+
---
|
|
577
|
+
|
|
506
578
|
## Global Flags
|
|
507
579
|
|
|
508
580
|
These flags are accepted by all commands:
|
|
@@ -521,4 +593,4 @@ These flags are accepted by all commands:
|
|
|
521
593
|
|
|
522
594
|
---
|
|
523
595
|
|
|
524
|
-
**Last Updated:** 2026-
|
|
596
|
+
**Last Updated:** 2026-04-15
|
|
@@ -151,8 +151,9 @@ The bundle is stored on the platform for durability and restart recovery. If the
|
|
|
151
151
|
## Documentation
|
|
152
152
|
|
|
153
153
|
- [Command Center](command-center.mdx) - Resource graph, relationships, node types, and post-deployment UI reference
|
|
154
|
+
- [Provided Features](provided-features.mdx) - Shared Lead Gen, CRM, Projects, and feature-shell surfaces for downstream apps and agents
|
|
154
155
|
- [Execution API](api.mdx) - REST endpoints for executing resources and managing deployments
|
|
155
156
|
|
|
156
157
|
---
|
|
157
158
|
|
|
158
|
-
**Last Updated:** 2026-
|
|
159
|
+
**Last Updated:** 2026-04-15
|
|
@@ -0,0 +1,259 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: Provided Features
|
|
3
|
+
description: Shared UI and API surfaces for packaged business systems like Lead Gen, CRM, and Projects via @elevasis/ui/features/* and the SDK CLI
|
|
4
|
+
loadWhen: "Building against packaged app features, list-oriented lead gen, CRM, or project-management surfaces"
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
The SDK now covers more than raw workflow execution. `@elevasis/ui` publishes packaged business surfaces through `@elevasis/ui/features/<name>`, while `@elevasis/ui/components` stays available for generic UI primitives and short-lived compatibility aliases during the rollout. `elevasis-sdk` still exposes CLI commands for project-management surfaces that user agents can operate directly.
|
|
8
|
+
|
|
9
|
+
Use this page when you need to understand how the shared feature system is wired, which routes and hooks back each area, and which API or CLI surface to reach for.
|
|
10
|
+
|
|
11
|
+
---
|
|
12
|
+
|
|
13
|
+
## Feature Shell
|
|
14
|
+
|
|
15
|
+
Shared application features are mounted through `@elevasis/ui/provider` and feature manifests exported from `@elevasis/ui/features/<name>`.
|
|
16
|
+
|
|
17
|
+
```tsx
|
|
18
|
+
import { Outlet } from '@tanstack/react-router'
|
|
19
|
+
import { ElevasisFeaturesProvider, FeatureShell } from '@elevasis/ui/provider'
|
|
20
|
+
import { leadGenManifest } from '@elevasis/ui/features/lead-gen'
|
|
21
|
+
import { crmManifest } from '@elevasis/ui/features/crm'
|
|
22
|
+
import { deliveryManifest } from '@elevasis/ui/features/delivery'
|
|
23
|
+
|
|
24
|
+
const features = [leadGenManifest, crmManifest, deliveryManifest]
|
|
25
|
+
|
|
26
|
+
export function AppShell() {
|
|
27
|
+
return (
|
|
28
|
+
<ElevasisFeaturesProvider features={features}>
|
|
29
|
+
<FeatureShell>
|
|
30
|
+
<Outlet />
|
|
31
|
+
</FeatureShell>
|
|
32
|
+
</ElevasisFeaturesProvider>
|
|
33
|
+
)
|
|
34
|
+
}
|
|
35
|
+
```
|
|
36
|
+
|
|
37
|
+
What this gives you:
|
|
38
|
+
|
|
39
|
+
- feature-gated top-level nav entries
|
|
40
|
+
- automatic subshell sidebar dispatch by route prefix
|
|
41
|
+
- shared pages and hooks without copying route/sidebar boilerplate into each app
|
|
42
|
+
|
|
43
|
+
Current packaged feature subpaths include Lead Gen, CRM, Projects, Operations, Monitoring, Dashboard, Settings, and SEO. During rollout, some symbols may still be aliased from `@elevasis/ui/components`, but new imports should prefer `@elevasis/ui/features/<name>`.
|
|
44
|
+
|
|
45
|
+
---
|
|
46
|
+
|
|
47
|
+
## Contract Matrix
|
|
48
|
+
|
|
49
|
+
This is the actual contract split today, not an idealized one:
|
|
50
|
+
|
|
51
|
+
| System | Primary UI import | API | SDK CLI | Runtime tools |
|
|
52
|
+
| ------ | ----------------- | --- | ------- | ------------- |
|
|
53
|
+
| Lead Gen | `@elevasis/ui/features/lead-gen` | Yes | No first-class `elevasis-sdk` surface | Yes |
|
|
54
|
+
| CRM | `@elevasis/ui/features/crm` | Yes, but thinner than Lead Gen and Projects | No | Indirectly, through acquisition/deal surfaces |
|
|
55
|
+
| Projects | `@elevasis/ui/features/delivery` | Yes | Yes | No dedicated runtime adapter |
|
|
56
|
+
|
|
57
|
+
Projects is currently the only one with a first-class `elevasis-sdk project:*` CLI family. Lead Gen and CRM are still primarily UI + API + workflow/runtime surfaces.
|
|
58
|
+
|
|
59
|
+
## System Map
|
|
60
|
+
|
|
61
|
+
| System | Primary route space | Shared UI surface | Main data surface | Best SDK entry point |
|
|
62
|
+
| ------ | ------------------- | ----------------- | ----------------- | -------------------- |
|
|
63
|
+
| Lead Gen | `/lead-gen/*` | Lead Gen pages, sidebars, list detail page, run dialogs | Acquisition list APIs + list/acqDb platform tools | `@elevasis/ui/features/lead-gen`, `@elevasis/ui/hooks`, `@elevasis/sdk/worker` |
|
|
64
|
+
| CRM | `/crm/*` | CRM sidebar, overview widgets, deal/detail pages, workbench panels | Deal APIs, recent-activity API, and acquisition-backed hooks | `@elevasis/ui/features/crm`, `@elevasis/ui/hooks` |
|
|
65
|
+
| Projects | `/projects/*` | Projects list page, milestones/tasks/notes sidebars and pages | Project, milestone, task, note REST endpoints + CLI | `@elevasis/ui/features/delivery`, `@elevasis/ui/hooks/delivery`, `elevasis-sdk project:*` |
|
|
66
|
+
|
|
67
|
+
---
|
|
68
|
+
|
|
69
|
+
## Lead Gen
|
|
70
|
+
|
|
71
|
+
Lead Gen is now list-oriented. The operational unit is a list, not a batch. Each list owns its own pipeline config and execution history.
|
|
72
|
+
|
|
73
|
+
### Shared UI Surface
|
|
74
|
+
|
|
75
|
+
`@elevasis/ui/features/lead-gen` exports the main Lead Gen building blocks:
|
|
76
|
+
|
|
77
|
+
- `LeadGenSidebar`
|
|
78
|
+
- `LeadGenOverviewPage`
|
|
79
|
+
- `LeadGenListsPage`
|
|
80
|
+
- `LeadGenListDetailPage`
|
|
81
|
+
- `LeadGenCompaniesPage`
|
|
82
|
+
- `LeadGenContactsPage`
|
|
83
|
+
- `LIST_TEMPLATE_OPTIONS`
|
|
84
|
+
- `buildListConfig`
|
|
85
|
+
|
|
86
|
+
The most important page for downstream agents is `LeadGenListDetailPage`. It combines:
|
|
87
|
+
|
|
88
|
+
- list config editing
|
|
89
|
+
- live progress and funnel views
|
|
90
|
+
- execution history
|
|
91
|
+
- per-step run actions via `ResourceExecuteDialog`
|
|
92
|
+
|
|
93
|
+
### Shared UI Hooks
|
|
94
|
+
|
|
95
|
+
`@elevasis/ui/hooks` exposes list-aware hooks backed by the acquisition API:
|
|
96
|
+
|
|
97
|
+
| Hook | HTTP path |
|
|
98
|
+
| ---- | --------- |
|
|
99
|
+
| `useLists()` | `GET /acquisition/lists` |
|
|
100
|
+
| `useList(listId)` | `GET /acquisition/lists/:listId` |
|
|
101
|
+
| `useListsTelemetry()` | `GET /acquisition/lists/telemetry` |
|
|
102
|
+
| `useListProgress(listId)` | `GET /acquisition/lists/:listId/progress` |
|
|
103
|
+
| `useListExecutions(listId)` | `GET /acquisition/lists/:listId/executions` |
|
|
104
|
+
| `useCreateList()` | `POST /acquisition/lists` |
|
|
105
|
+
| `useUpdateList(listId)` | `PATCH /acquisition/lists/:listId` |
|
|
106
|
+
| `useUpdateListConfig(listId)` | `PATCH /acquisition/lists/:listId/config` |
|
|
107
|
+
| `useDeleteList()` | `DELETE /acquisition/lists/:listId` |
|
|
108
|
+
|
|
109
|
+
Lead Gen also sits on broader acquisition endpoints for companies and contacts:
|
|
110
|
+
|
|
111
|
+
- `GET /acquisition/companies`
|
|
112
|
+
- `POST /acquisition/companies`
|
|
113
|
+
- `GET /acquisition/contacts`
|
|
114
|
+
- `POST /acquisition/contacts`
|
|
115
|
+
|
|
116
|
+
### Workflow Runtime Surface
|
|
117
|
+
|
|
118
|
+
Inside workflows and agents, there are two relevant platform adapters:
|
|
119
|
+
|
|
120
|
+
- `acqDb` for broad acquisition CRUD
|
|
121
|
+
- `list` for focused list execution and stage-tracking operations
|
|
122
|
+
|
|
123
|
+
```ts
|
|
124
|
+
import { acqDb, list } from '@elevasis/sdk/worker'
|
|
125
|
+
|
|
126
|
+
const config = await list.getConfig({ listId })
|
|
127
|
+
|
|
128
|
+
await list.recordExecution({
|
|
129
|
+
listId,
|
|
130
|
+
executionId: context.executionId,
|
|
131
|
+
payload: { resourceId: context.resourceId },
|
|
132
|
+
})
|
|
133
|
+
|
|
134
|
+
await list.updateCompanyStage({
|
|
135
|
+
listId,
|
|
136
|
+
companyId,
|
|
137
|
+
stage: 'qualified',
|
|
138
|
+
})
|
|
139
|
+
```
|
|
140
|
+
|
|
141
|
+
Use `list` when the workflow is scoped to a list run. Use `acqDb` when you need broader company, contact, or deal CRUD.
|
|
142
|
+
|
|
143
|
+
### CLI Status
|
|
144
|
+
|
|
145
|
+
There is no dedicated downstream `elevasis-sdk lead-gen:*` family today.
|
|
146
|
+
|
|
147
|
+
- In this monorepo there is platform-side lead-gen operational tooling, but that is not the same thing as a published downstream SDK CLI contract.
|
|
148
|
+
- For downstream SDK users, the contract is currently UI + HTTP API + workflow/runtime adapters.
|
|
149
|
+
|
|
150
|
+
---
|
|
151
|
+
|
|
152
|
+
## CRM
|
|
153
|
+
|
|
154
|
+
CRM is packaged as a shared feature module rather than a one-off app implementation.
|
|
155
|
+
|
|
156
|
+
### Shared UI Surface
|
|
157
|
+
|
|
158
|
+
`@elevasis/ui/features/crm` exports:
|
|
159
|
+
|
|
160
|
+
- `CrmSidebar`
|
|
161
|
+
- `CrmOverview`
|
|
162
|
+
- `DealsListPage`
|
|
163
|
+
- `DealDetailPage`
|
|
164
|
+
- `PipelineFunnelWidget`
|
|
165
|
+
- `TasksDueWidget`
|
|
166
|
+
- `ActivityFeedWidget`
|
|
167
|
+
- `MetricsStrip`
|
|
168
|
+
- `MyTasksPanel`
|
|
169
|
+
- `SavedViewsPanel`
|
|
170
|
+
- `QuickCreateActions`
|
|
171
|
+
|
|
172
|
+
The CRM manifest is `crmManifest`, with the route prefix `/crm` and feature-key alignment to the acquisition feature set.
|
|
173
|
+
|
|
174
|
+
### API Surface
|
|
175
|
+
|
|
176
|
+
CRM is not CLI-first today, but it does have real API-backed behavior.
|
|
177
|
+
|
|
178
|
+
Shared CRM pages and hooks currently rely on:
|
|
179
|
+
|
|
180
|
+
- deal list/detail surfaces through the acquisition/deal APIs
|
|
181
|
+
- `GET /crm/recent-activity` for the overview activity feed
|
|
182
|
+
|
|
183
|
+
That means downstream users can build against CRM with shared UI and API contracts, but there is not yet a dedicated `elevasis-sdk crm:*` CLI family.
|
|
184
|
+
|
|
185
|
+
### Practical Guidance
|
|
186
|
+
|
|
187
|
+
- Use the shared CRM pages first; do not rebuild sidebar and overview chrome locally unless the app truly diverges.
|
|
188
|
+
- Treat CRM overview/workbench components as the canonical packaged surface for downstream apps.
|
|
189
|
+
- When CRM actions depend on acquisition or delivery state, keep the route shell local and compose the shared packaged widgets inside it.
|
|
190
|
+
- Treat CRM as UI + API today, not UI + API + CLI.
|
|
191
|
+
|
|
192
|
+
---
|
|
193
|
+
|
|
194
|
+
## Projects
|
|
195
|
+
|
|
196
|
+
Projects is the packaged delivery/project-management system. It has both a shared UI surface and a first-class CLI surface in `elevasis-sdk`.
|
|
197
|
+
|
|
198
|
+
### Shared UI Surface
|
|
199
|
+
|
|
200
|
+
`@elevasis/ui/features/delivery` exports:
|
|
201
|
+
|
|
202
|
+
- `ProjectsListPage`
|
|
203
|
+
- `ProjectsSidebar`
|
|
204
|
+
- `ProjectsSidebarMiddle`
|
|
205
|
+
- milestone, task, and note status helpers
|
|
206
|
+
- `deliveryManifest`
|
|
207
|
+
|
|
208
|
+
### Shared UI Hooks
|
|
209
|
+
|
|
210
|
+
`@elevasis/ui/hooks/delivery` talks to the project-management API:
|
|
211
|
+
|
|
212
|
+
| Hook | HTTP path |
|
|
213
|
+
| ---- | --------- |
|
|
214
|
+
| `useProjects()` | `GET /projects` |
|
|
215
|
+
| `useProject(id)` | `GET /projects/:id` |
|
|
216
|
+
| `useTasks({ projectId })` | `GET /projects/:projectId/tasks` |
|
|
217
|
+
| `useMilestones({ projectId })` | `GET /projects/:projectId/milestones` |
|
|
218
|
+
| `useProjectNotes({ projectId })` | `GET /projects/:projectId/notes` |
|
|
219
|
+
| `useCreateTask()` | `POST /project-tasks` |
|
|
220
|
+
| `useUpdateTask()` | `PATCH /project-tasks/:id` |
|
|
221
|
+
| `useCreateNote()` | `POST /project-notes` |
|
|
222
|
+
|
|
223
|
+
### CLI Surface
|
|
224
|
+
|
|
225
|
+
The SDK CLI now exposes project-management commands:
|
|
226
|
+
|
|
227
|
+
```bash
|
|
228
|
+
elevasis-sdk project:list
|
|
229
|
+
elevasis-sdk project:get <id>
|
|
230
|
+
elevasis-sdk project:create --name "Website Refresh" --kind client_engagement
|
|
231
|
+
|
|
232
|
+
elevasis-sdk project:milestone:list --project <id>
|
|
233
|
+
elevasis-sdk project:task:list --project <id>
|
|
234
|
+
elevasis-sdk project:note:list --project <id>
|
|
235
|
+
|
|
236
|
+
elevasis-sdk project:task:resume <task-id> --pretty
|
|
237
|
+
elevasis-sdk project:task:save <task-id> --current-state "Implemented the API slice"
|
|
238
|
+
```
|
|
239
|
+
|
|
240
|
+
This matters for downstream user agents because project tasks now have a resumable machine-readable surface. `project:task:resume` returns `resume_context`, and `project:task:save` updates it.
|
|
241
|
+
|
|
242
|
+
---
|
|
243
|
+
|
|
244
|
+
## Choosing The Right Surface
|
|
245
|
+
|
|
246
|
+
- Need packaged app navigation or subshell routing? Use `ElevasisFeaturesProvider`, `FeatureShell`, and manifests from `@elevasis/ui/features/<name>`.
|
|
247
|
+
- Need list-scoped lead-gen runtime behavior? Use the `list` adapter, then `acqDb` for broader acquisition CRUD.
|
|
248
|
+
- Need a custom React page against an existing system? Start with the shared `@elevasis/ui` pages and hooks before writing app-local fetch logic.
|
|
249
|
+
- Need project/task automation from an agent or terminal workflow? Use `elevasis-sdk project:*`.
|
|
250
|
+
|
|
251
|
+
---
|
|
252
|
+
|
|
253
|
+
## Related
|
|
254
|
+
|
|
255
|
+
- [Deployment](index.mdx) - Deploy lifecycle and bundle behavior
|
|
256
|
+
- [Command Center](command-center.mdx) - Managed platform UI after deploy
|
|
257
|
+
- [UI Execution](ui-execution.mdx) - `ResourceExecuteDialog`, execution hooks, and custom run flows
|
|
258
|
+
- [Platform Adapters](../platform-tools/adapters-platform.mdx) - `acqDb`, `list`, `execution`, and other platform services
|
|
259
|
+
- [CLI Reference](../cli.mdx) - Full command catalog, now including project-management commands
|
|
@@ -0,0 +1,251 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: UI Execution
|
|
3
|
+
description: Trigger workflow and agent executions from a custom React UI -- Run buttons, input forms, and result displays via @elevasis/ui
|
|
4
|
+
loadWhen: "Building a custom UI that triggers resource executions (Run buttons, input forms)"
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
`@elevasis/ui` ships a set of components and hooks that let your custom React pages trigger workflow and agent executions without wiring up API calls manually. This page is for template users building interactive resource pages in `external/_template` who want to add Run buttons, input forms, and execution result displays.
|
|
8
|
+
|
|
9
|
+
The API comes in three tiers: a convenience one-tag component that handles everything, a controlled form primitive for custom modal chrome, and low-level hooks for fully custom rendering. Most template pages need only the first tier.
|
|
10
|
+
|
|
11
|
+
---
|
|
12
|
+
|
|
13
|
+
## Quick Start -- `ResourceExecuteDialog`
|
|
14
|
+
|
|
15
|
+
`ResourceExecuteDialog` combines a modal shell, an input form, mutation state, and result display into a single component. Drop it next to a Button and you have a working Run dialog in about fifteen lines.
|
|
16
|
+
|
|
17
|
+
```tsx
|
|
18
|
+
import { useState } from 'react'
|
|
19
|
+
import { Button } from '@mantine/core'
|
|
20
|
+
import { ResourceExecuteDialog } from '@elevasis/ui/features/operations'
|
|
21
|
+
import { useNavigate } from '@tanstack/react-router'
|
|
22
|
+
|
|
23
|
+
const resource = {
|
|
24
|
+
resourceId: 'qualify-lead-workflow',
|
|
25
|
+
resourceType: 'workflow' as const,
|
|
26
|
+
name: 'Qualify Lead',
|
|
27
|
+
formSchema: {
|
|
28
|
+
fields: [
|
|
29
|
+
{ name: 'email', label: 'Lead email', type: 'text', required: true },
|
|
30
|
+
{ name: 'company', label: 'Company', type: 'text', required: false },
|
|
31
|
+
],
|
|
32
|
+
},
|
|
33
|
+
}
|
|
34
|
+
|
|
35
|
+
export function QualifyLeadPage() {
|
|
36
|
+
const [opened, setOpened] = useState(false)
|
|
37
|
+
const navigate = useNavigate()
|
|
38
|
+
|
|
39
|
+
return (
|
|
40
|
+
<>
|
|
41
|
+
<Button onClick={() => setOpened(true)}>Run</Button>
|
|
42
|
+
|
|
43
|
+
<ResourceExecuteDialog
|
|
44
|
+
opened={opened}
|
|
45
|
+
onClose={() => setOpened(false)}
|
|
46
|
+
resource={resource}
|
|
47
|
+
onViewExecution={(executionId) =>
|
|
48
|
+
navigate({ to: '/logs/$executionId', params: { executionId } })
|
|
49
|
+
}
|
|
50
|
+
/>
|
|
51
|
+
</>
|
|
52
|
+
)
|
|
53
|
+
}
|
|
54
|
+
```
|
|
55
|
+
|
|
56
|
+
What the user sees when they click Run:
|
|
57
|
+
|
|
58
|
+
- A modal opens titled "Run workflow" with the resource ID displayed.
|
|
59
|
+
- The form renders one field per entry in `formSchema.fields`. Required fields show validation errors on submit.
|
|
60
|
+
- On submit, a loading overlay appears while the POST is in flight.
|
|
61
|
+
- On success, a teal confirmation card shows the execution ID. A "View execution" button calls `onViewExecution` with that ID.
|
|
62
|
+
- On error, a red alert shows the error message with a "Try again" option.
|
|
63
|
+
|
|
64
|
+
If `formSchema` is omitted or has no fields, the form skips to a single "Run" button with the message "This workflow takes no input."
|
|
65
|
+
|
|
66
|
+
---
|
|
67
|
+
|
|
68
|
+
## The Three-Tier API
|
|
69
|
+
|
|
70
|
+
| Tier | Component / Hook | Use case |
|
|
71
|
+
| --------------- | ------------------------------------------ | ----------------------------------------------------------------------------------------------- |
|
|
72
|
+
| Convenience | `ResourceExecuteDialog` | One-tag Run button + modal + form. Parent only manages `opened` state. |
|
|
73
|
+
| Controlled form | `ResourceExecuteForm` | Custom modal chrome; parent owns the mutation and decides where to show results. |
|
|
74
|
+
| Low-level | `ExecuteWorkflowModal` + `useExecuteAsync` | Fully custom rendering, non-standard modal behavior, or composing execution into a larger flow. |
|
|
75
|
+
|
|
76
|
+
Start with `ResourceExecuteDialog`. Move down the tiers only when you need something the convenience component cannot do.
|
|
77
|
+
|
|
78
|
+
---
|
|
79
|
+
|
|
80
|
+
## Controlled Usage with `ResourceExecuteForm`
|
|
81
|
+
|
|
82
|
+
Use `ResourceExecuteForm` when you want to own the modal or display the result somewhere outside the dialog -- for example, rendering the execution ID inline on the page after submission.
|
|
83
|
+
|
|
84
|
+
`ResourceExecuteForm` accepts `onSubmit` and `isPending` from the parent. The parent calls `useExecuteAsync()` directly and passes `mutateAsync` as the submit handler.
|
|
85
|
+
|
|
86
|
+
```tsx
|
|
87
|
+
import { useState } from 'react'
|
|
88
|
+
import { Modal, Button, Text } from '@mantine/core'
|
|
89
|
+
import { ResourceExecuteForm } from '@elevasis/ui/features/operations'
|
|
90
|
+
import { useExecuteAsync } from '@elevasis/ui/hooks'
|
|
91
|
+
import type { SerializedExecutionFormSchema } from '@elevasis/ui/hooks'
|
|
92
|
+
|
|
93
|
+
const formSchema: SerializedExecutionFormSchema = {
|
|
94
|
+
fields: [
|
|
95
|
+
{ name: 'topic', label: 'Topic', type: 'text', required: true },
|
|
96
|
+
],
|
|
97
|
+
}
|
|
98
|
+
|
|
99
|
+
export function CustomRunPanel() {
|
|
100
|
+
const [opened, setOpened] = useState(false)
|
|
101
|
+
const mutation = useExecuteAsync()
|
|
102
|
+
|
|
103
|
+
const handleSubmit = async (input: Record<string, unknown>) => {
|
|
104
|
+
await mutation.mutateAsync({
|
|
105
|
+
resourceId: 'research-agent',
|
|
106
|
+
resourceType: 'agent',
|
|
107
|
+
input,
|
|
108
|
+
})
|
|
109
|
+
}
|
|
110
|
+
|
|
111
|
+
return (
|
|
112
|
+
<>
|
|
113
|
+
<Button onClick={() => setOpened(true)}>Run agent</Button>
|
|
114
|
+
|
|
115
|
+
{mutation.data && (
|
|
116
|
+
<Text size="sm">Started: {mutation.data.executionId}</Text>
|
|
117
|
+
)}
|
|
118
|
+
|
|
119
|
+
<Modal opened={opened} onClose={() => setOpened(false)} title="Run research agent">
|
|
120
|
+
<ResourceExecuteForm
|
|
121
|
+
formSchema={formSchema}
|
|
122
|
+
onSubmit={handleSubmit}
|
|
123
|
+
isPending={mutation.isPending}
|
|
124
|
+
disabled={mutation.isPending}
|
|
125
|
+
submitLabel="Start research"
|
|
126
|
+
/>
|
|
127
|
+
</Modal>
|
|
128
|
+
</>
|
|
129
|
+
)
|
|
130
|
+
}
|
|
131
|
+
```
|
|
132
|
+
|
|
133
|
+
`ResourceExecuteForm` props:
|
|
134
|
+
|
|
135
|
+
| Prop | Type | Default | Notes |
|
|
136
|
+
| ------------- | ------------------------------------ | -------- | ------------------------------------ |
|
|
137
|
+
| `formSchema` | `SerializedExecutionFormSchema` | required | Drives field rendering |
|
|
138
|
+
| `onSubmit` | `(input) => void | Promise<void>` | required | Called with mapped field values |
|
|
139
|
+
| `isPending` | `boolean` | `false` | Shows loading state on submit button |
|
|
140
|
+
| `disabled` | `boolean` | `false` | Disables all fields and button |
|
|
141
|
+
| `submitLabel` | `string` | `'Run'` | Button label when not pending |
|
|
142
|
+
|
|
143
|
+
---
|
|
144
|
+
|
|
145
|
+
## Low-Level: Hooks and `ExecuteWorkflowModal`
|
|
146
|
+
|
|
147
|
+
For complete rendering control, use `useExecuteAsync` and `ExecuteWorkflowModal` independently. `ExecuteWorkflowModal` is a Mantine Modal pre-wired with a loading overlay, a success card (execution ID + "View execution" button), and an error alert. You pass `children` for the input area.
|
|
148
|
+
|
|
149
|
+
```tsx
|
|
150
|
+
import { ExecuteWorkflowModal } from '@elevasis/ui/features/operations'
|
|
151
|
+
import { useExecuteAsync } from '@elevasis/ui/hooks'
|
|
152
|
+
|
|
153
|
+
const { mutateAsync, isPending, error, data, reset } = useExecuteAsync()
|
|
154
|
+
|
|
155
|
+
<ExecuteWorkflowModal
|
|
156
|
+
opened={opened}
|
|
157
|
+
onClose={() => setOpened(false)}
|
|
158
|
+
resource={{ resourceId: 'my-workflow', resourceType: 'workflow', name: 'My Workflow' }}
|
|
159
|
+
isPending={isPending}
|
|
160
|
+
error={error}
|
|
161
|
+
result={data ?? null}
|
|
162
|
+
onViewExecution={handleViewExecution}
|
|
163
|
+
onReset={reset}
|
|
164
|
+
>
|
|
165
|
+
{/* your custom form or content here */}
|
|
166
|
+
</ExecuteWorkflowModal>
|
|
167
|
+
```
|
|
168
|
+
|
|
169
|
+
The modal locks close interactions (click-outside, Escape, close button) while `isPending` is true, preventing accidental dismissal mid-execution.
|
|
170
|
+
|
|
171
|
+
Source: `packages/ui/src/features/operations/executions/ExecuteWorkflowModal.tsx`, `packages/ui/src/hooks/executions/useExecuteAsync.ts`
|
|
172
|
+
|
|
173
|
+
---
|
|
174
|
+
|
|
175
|
+
## Zod-Validated Execution with `useExecuteWorkflow`
|
|
176
|
+
|
|
177
|
+
`useExecuteWorkflow` wraps `useExecuteAsync` with a Zod parse step before the POST. Use it when you are constructing input programmatically (not from a form) and want to catch schema mismatches before they reach the API.
|
|
178
|
+
|
|
179
|
+
```tsx
|
|
180
|
+
import { z } from 'zod'
|
|
181
|
+
import { useExecuteWorkflow } from '@elevasis/ui/hooks'
|
|
182
|
+
|
|
183
|
+
const inputSchema = z.object({
|
|
184
|
+
email: z.string().email(),
|
|
185
|
+
score: z.number().min(0).max(100),
|
|
186
|
+
})
|
|
187
|
+
|
|
188
|
+
function useScoredExecution() {
|
|
189
|
+
return useExecuteWorkflow({ schema: inputSchema })
|
|
190
|
+
}
|
|
191
|
+
|
|
192
|
+
// In a component:
|
|
193
|
+
const { execute, isPending, data, error } = useScoredExecution()
|
|
194
|
+
|
|
195
|
+
await execute({
|
|
196
|
+
resourceId: 'score-lead-workflow',
|
|
197
|
+
resourceType: 'workflow',
|
|
198
|
+
input: { email: 'lead@example.com', score: 72 },
|
|
199
|
+
})
|
|
200
|
+
```
|
|
201
|
+
|
|
202
|
+
If `input` fails the Zod parse, `execute` throws synchronously with the message `"Invalid workflow input: ..."` before making any network request. The `mutation` object on the return value is the underlying `useExecuteAsync` mutation, giving you full TanStack Query state if needed.
|
|
203
|
+
|
|
204
|
+
Prefer `useExecuteWorkflow` over raw `useExecuteAsync` when:
|
|
205
|
+
|
|
206
|
+
- Input is assembled from multiple sources (not a single form submit).
|
|
207
|
+
- You want TypeScript inference on the input shape via `z.infer`.
|
|
208
|
+
- You want a clear validation error message rather than a 400 from the API.
|
|
209
|
+
|
|
210
|
+
Source: `packages/ui/src/hooks/executions/useExecuteWorkflow.ts`
|
|
211
|
+
|
|
212
|
+
---
|
|
213
|
+
|
|
214
|
+
## Input Forms
|
|
215
|
+
|
|
216
|
+
`ResourceExecuteDialog` and `ResourceExecuteForm` auto-render form fields from `formSchema.fields`. Each field is a `SerializedFormField` with at minimum `name`, `label`, and `type`.
|
|
217
|
+
|
|
218
|
+
Supported field types:
|
|
219
|
+
|
|
220
|
+
- `text` -- single-line text input
|
|
221
|
+
- `textarea` -- multi-line text input
|
|
222
|
+
- `number` -- numeric input
|
|
223
|
+
- `select` -- dropdown with `options` array
|
|
224
|
+
- `checkbox` -- boolean toggle; defaults to `false`
|
|
225
|
+
- `radio` -- radio group with `options` array
|
|
226
|
+
- `richtext` -- rich text editor
|
|
227
|
+
|
|
228
|
+
Required fields (`required: true`) are validated on submit. Custom field-to-input-key remapping is supported via `formSchema.fieldMappings` -- a `Record<string, string>` that renames field values before they are passed to `onSubmit`.
|
|
229
|
+
|
|
230
|
+
If `formSchema` is undefined, an empty object, or has `fields: []`, the form skips rendering fields entirely and shows "This workflow takes no input." with a single Run button.
|
|
231
|
+
|
|
232
|
+
---
|
|
233
|
+
|
|
234
|
+
## Error and Result Handling
|
|
235
|
+
|
|
236
|
+
Mutation state flows automatically into the modal chrome when using `ResourceExecuteDialog` or `ExecuteWorkflowModal`:
|
|
237
|
+
|
|
238
|
+
- **Success** -- a teal alert card displays the execution ID from `result.executionId`. If `onViewExecution` is provided, a "View execution" button calls it with the ID. This is the recommended way to deep-link to the Execution Logs page.
|
|
239
|
+
- **Error** -- a red alert displays `error.message`. A "Try again" button calls `onReset`, which clears the mutation state and re-shows the form.
|
|
240
|
+
- **Pending** -- a blur overlay covers the form area while the POST is in flight. The modal cannot be dismissed during this state.
|
|
241
|
+
|
|
242
|
+
`useExecuteAsync` also invalidates the executions list query on success (keyed by `organizationId` + `resourceId`), so any `useExecutions` query on the page refreshes automatically.
|
|
243
|
+
|
|
244
|
+
---
|
|
245
|
+
|
|
246
|
+
## Related
|
|
247
|
+
|
|
248
|
+
- [REST API](api.mdx) -- trigger executions directly over HTTP, without React
|
|
249
|
+
- [Command Center](command-center.mdx) -- built-in managed UI; includes Run buttons for all deployed resources
|
|
250
|
+
- [Resource Patterns](../resources/patterns.mdx) -- HITL approval patterns and `approval.create()`
|
|
251
|
+
- [Platform Adapters](../platform-tools/adapters-platform.mdx) -- `approval.create()` reference
|
package/reference/index.mdx
CHANGED
|
@@ -8,7 +8,7 @@ loadWhen: "First session or new to the SDK"
|
|
|
8
8
|
|
|
9
9
|
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.
|
|
10
10
|
|
|
11
|
-
The SDK ships with a full CLI (`elevasis-sdk`) for validation, deployment, execution, and
|
|
11
|
+
The SDK ships with a full CLI (`elevasis-sdk`) for validation, deployment, execution, inspection, and project-management operations. 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.
|
|
12
12
|
|
|
13
13
|
## Quick Start
|
|
14
14
|
|
|
@@ -25,6 +25,7 @@ After `pnpm dlx @elevasis/sdk init`, your project is scaffolded with a working e
|
|
|
25
25
|
|
|
26
26
|
- **Workflows** -- Step-based automation with typed inputs and outputs. Steps can be linear, conditional, or branching. Each step is a plain async function. See [Resources](resources/index.mdx) for the complete definition API.
|
|
27
27
|
- **Agents** -- Autonomous AI resources with access to platform tools. Agents run in the worker runtime with full LLM access and platform tool support. Use `--async` when executing agents to avoid HTTP timeout limits on long-running runs.
|
|
28
|
+
- **Feature-driven apps** -- Shared Lead Gen, CRM, Projects, Operations, Monitoring, Dashboard, and Settings surfaces are available through `@elevasis/ui`. See [Provided Features](deployment/provided-features.mdx).
|
|
28
29
|
|
|
29
30
|
## Platform Tools
|
|
30
31
|
|
|
@@ -65,7 +66,7 @@ See [Platform Tools](platform-tools/index.mdx) for the full catalog.
|
|
|
65
66
|
|
|
66
67
|
- [Concepts](concepts.mdx) - Plain-English concept explanations, glossary, Zod guide, execution model, and common errors
|
|
67
68
|
- [Templates](templates/index.mdx) - 7 workflow templates: web-scraper, data-enrichment, email-sender, lead-scorer, and more
|
|
68
|
-
- [CLI Reference](cli.mdx) - All CLI commands: check, deploy, exec, resources, executions, env, and more
|
|
69
|
+
- [CLI Reference](cli.mdx) - All CLI commands: check, deploy, exec, resources, executions, env, `project:*`, and more
|
|
69
70
|
- [Deployment](deployment/index.mdx) - Deploy pipeline, versioning, bundle upload, and registry registration
|
|
70
71
|
- [Runtime](runtime.mdx) - Worker execution model, concurrency, timeouts, cancellation, resource limits, and v1 limitations
|
|
71
72
|
|
|
@@ -91,6 +92,7 @@ See [Platform Tools](platform-tools/index.mdx) for the full catalog.
|
|
|
91
92
|
### Deployment Subpages
|
|
92
93
|
|
|
93
94
|
- [Command Center](deployment/command-center.mdx) - Resource graph, relationships, node types, and post-deployment UI reference
|
|
95
|
+
- [Provided Features](deployment/provided-features.mdx) - Shared Lead Gen, CRM, Projects, feature manifests, and downstream app wiring
|
|
94
96
|
- [Execution API](deployment/api.mdx) - REST endpoints for executing resources and managing deployments
|
|
95
97
|
|
|
96
98
|
### More
|
|
@@ -100,4 +102,4 @@ See [Platform Tools](platform-tools/index.mdx) for the full catalog.
|
|
|
100
102
|
|
|
101
103
|
---
|
|
102
104
|
|
|
103
|
-
**Last Updated:** 2026-04-
|
|
105
|
+
**Last Updated:** 2026-04-15
|