@elevasis/sdk 1.2.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/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 inspect resources
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, and inspect execution history.
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-03-08
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-02-25
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
@@ -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 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.
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-05
105
+ **Last Updated:** 2026-04-15