@elevasis/sdk 1.44.2 → 1.45.0

package/reference/sdk/define-builders.mdx

@@ -0,0 +1,76 @@
+---
+title: When to Reach for the define* Builders
+description: defineWorkflow, defineStep, defineContract, defineResource, and defineTopology exist for two different reasons -- this page teaches which reason applies before you pick a builder over a plain object literal.
+---
+
+`@elevasis/sdk`'s root export includes a family of `define*` functions: `defineWorkflow`, `defineStep`, `defineContract`, `defineWorkflowConfig`, `defineResource`, `defineResources`, `defineResourceOntology`, `defineTopology`, `defineTopologyRelationship`, plus the `topologyRelationship` / `topologyRef` helpers. Every existing recipe in this bundle teaches the plain object-literal shape instead (a `WorkflowDefinition` written out by hand with a `: WorkflowDefinition` annotation), which is completely valid TypeScript -- but it means the builders are never actually demonstrated, so there is nothing here to tell you when reaching for one buys you something real versus when it is just a different way to write the same object. This page is that judgment call. For the full list of what `@elevasis/sdk` exports, see the [Export Catalog](exports.mdx).
+
+The family splits into two groups that do genuinely different things, and the judgment call is different for each.
+
+## Group 1: Workflow Builders Are Type Inference, Not Validation
+
+`defineWorkflow`, `defineStep`, and `defineContract` do nothing at runtime. Their entire implementation is an identity function constrained by a generic:
+
+{/* doc-snippet:skip: source excerpt (WorkflowDefinition intentionally unimported), not a standalone compilable file */}
+
+```typescript
+export function defineWorkflow<TWorkflow extends WorkflowDefinition>(workflow: TWorkflow): TWorkflow {
+  return workflow
+}
+```
+
+`defineStep` and `defineContract` are the same three lines against `WorkflowStep` and `Contract`. Calling one of these does not validate, transform, or check anything beyond what TypeScript's structural typing already does on the argument you pass it.
+
+What it buys you is narrower inference. Annotate a literal `const echo: WorkflowDefinition = { ... }` and TypeScript widens every field to the interface's declared type -- `config.resourceId` becomes `string`, not `'echo'`. Pass the same object to `defineWorkflow({ ... })` with no annotation and `TWorkflow` is inferred from the literal you wrote, so `defineWorkflow(...).config.resourceId` keeps the literal type `'echo'`. That distinction only matters if something downstream reads the value back and wants the narrower type -- a test asserting on `resourceId`, a lookup table keyed by it, a second resource that imports the first and needs its literal id. A workflow file that is only ever consumed by the deploy pipeline, which just needs it to satisfy `WorkflowDefinition`, gets nothing extra from the wrapper.
+
+That is a real, but narrow, upside -- and it is honestly reflected in what ships. The scaffolded template's own workflow files (`echo.ts`, `email-notification.ts`) use the plain annotated-literal form, not `defineWorkflow`. The builder is real, exported, and demonstrated in the SDK's own test fixtures with exactly the calling convention above -- it is simply not the house style the template ships with. Use the annotated literal by default, matching what a scaffolded project already contains; reach for `defineWorkflow` / `defineStep` / `defineContract` specifically when you want the object's literal types preserved past its own definition.
+
+`defineWorkflowConfig` is a different kind of helper in this same group -- it derives `config` fields from an Organization Model resource descriptor instead of preserving literal types. It has its own page: see [The Deployment Spec Pattern](project-deployment-spec.mdx#defineworkflowconfig-deriving-config-from-one-om-descriptor).
+
+## Group 2: Resource and Topology Builders Do Real Work
+
+`defineResource`, `defineResources`, `defineResourceOntology`, `defineTopology`, and `defineTopologyRelationship` are a different animal entirely -- each one calls a Zod schema's `.parse()` on its way out:
+
+{/* doc-snippet:skip: source excerpt (ResourceEntry/ResourceEntrySchema intentionally unimported), not a standalone compilable file */}
+
+```typescript
+export function defineResource<const TResource extends ResourceEntry>(resource: TResource): TResource {
+  return ResourceEntrySchema.parse(resource) as TResource
+}
+```
+
+A hand-typed object that satisfies the `ResourceEntry` TypeScript interface skips that check entirely at the point you write it. It is not unvalidated forever -- the whole Organization Model gets parsed eventually -- but a mistake surfaces later, at whole-model validation, as a less specific error than the one `defineResource` would have raised on the exact line that defined the bad resource.
+
+`defineTopology` and `defineTopologyRelationship` go a step further: they compile human-authored references into the canonical shape the graph actually stores. A relationship's `from` / `to` can be written as an already-typed node ref, or as a resource descriptor object handed to you by another part of the model -- `compileTopologyNodeRef` resolves either into the canonical `{ kind, id }` form. This is not something a plain object literal can replicate without reimplementing that resolution step by hand:
+
+{/* doc-snippet:skip: illustrative excerpt (someWorkflowResourceDescriptor intentionally undefined), not a standalone compilable file */}
+
+```typescript
+import { defineTopology, topologyRef, topologyRelationship } from '@elevasis/sdk'
+
+const topology = defineTopology({
+  'trigger-handles-webhook': topologyRelationship.triggers(
+    topologyRef.trigger('inbound-webhook'),
+    someWorkflowResourceDescriptor, // a resource object, resolved for you
+    { systemPath: 'sales.lead-gen', required: true }
+  )
+})
+```
+
+For this group, reaching for the builder is not a style preference -- it is the only path that gets you both the validation and the reference compilation. Do not hand-author the parsed topology shape (`{ from: { kind: 'resource', id: '...' }, to: ... }`) directly; author against the helpers and let them produce it.
+
+**Tenant caveat:** these builders live in the Organization Model authoring layer. In a template-based project, `core/config/organization-model.ts` and its split sibling files are edited through the `/om` command, not by hand -- so day to day you are unlikely to call `defineResource` or `defineTopology` yourself even though they are part of the published surface. Understanding what they do is still useful: it is why hand-editing those files instead of going through `/om` is risky, since you would be reproducing Zod validation and reference compilation by hand and likely getting one of them wrong.
+
+## Quick Decision Guide
+
+- Writing a workflow, step, or contract, and nothing downstream needs the literal types back -- use the plain annotated object literal. This is what the scaffolded template ships.
+- Writing a workflow, step, or contract, and something downstream reads the value back and needs its literal types preserved -- wrap it in `defineWorkflow` / `defineStep` / `defineContract`.
+- Deriving a workflow's `config` from an OM resource descriptor that already has `ontology.primaryAction` set -- use `defineWorkflowConfig`.
+- Authoring an Organization Model resource, resource ontology binding, or topology relationship directly (Elevasis's own workspace-internal model, or inside the tooling `/om` itself runs) -- always use `defineResource` / `defineResourceOntology` / `defineTopology` / `defineTopologyRelationship`, never the raw parsed shape.
+- Authoring a tenant project's own Organization Model -- go through `/om`; you generally will not call the Group 2 builders yourself.
+
+## Documentation
+
+- [Export Catalog](exports.mdx) -- the generated, per-subpath inventory of everything `@elevasis/sdk` exports
+- [Resources](resources/index.mdx) -- the `WorkflowDefinition` / `AgentDefinition` shape these builders wrap
+- [The Deployment Spec Pattern](project-deployment-spec.mdx) -- `defineWorkflowConfig` and `projectDeploymentSpec` in context

package/reference/sdk/deployment/command-center.mdx

@@ -54,6 +54,8 @@ Every resource you deploy becomes a node in the graph. Some nodes are executable
 
 Relationships are edges in the graph. Declare them in `DeploymentSpec`:
 
+{/* doc-snippet:skip: illustrative excerpt -- DeploymentSpec, scoreLeadWorkflow, sendProposalWorkflow are shown as already-defined resources from elsewhere in the project, not a standalone compilable file */}
+
 ```typescript
 const org: DeploymentSpec = {
   workflows: [scoreLeadWorkflow, sendProposalWorkflow],
@@ -126,7 +128,9 @@ The Command Queue surfaces all pending Human-in-the-Loop (HITL) approval request
 - Approve or reject with an optional comment
 - See the history of past decisions
 
-**How it connects to your code:** Approval requests appear when a workflow step calls `approval.create()`. The workflow pauses at that step and waits for a decision.
+**How it connects to your code:** Approval requests appear when a workflow step calls `approval.create()`. The step then **completes normally — the workflow does not pause.** Resolving the request later triggers a **new** execution of whichever resource the selected action's `target` names. Structure the work accordingly: everything that must happen after the decision belongs in that target resource, not in later steps of the workflow that raised the request.
+
+{/* doc-snippet:skip: illustrative excerpt -- dealId/proposalUrl are shorthand for values from the enclosing step handler's input, not a standalone compilable file */}
 
 ```typescript
 import { approval } from '@elevasis/sdk/worker'
@@ -141,7 +145,7 @@ const task = await approval.create({
 })
 ```
 
-> **SDK takeaway:** Use `approval.create()` to create approval gates. Provide rich `context` so reviewers have what they need to decide.
+> **SDK takeaway:** Use `approval.create()` to raise an approval request, and put the post-decision work in the resource each action targets. Provide rich `context` so reviewers have what they need to decide. See [Human-in-the-Loop Workflows](../human-in-the-loop.mdx) for the full path from workflow to checkpoint to queue resolution.
 
 ---
 

package/reference/sdk/deployment/execution-reference.mdx

@@ -290,227 +290,105 @@ The SDK CLI wraps all execution endpoints. Use these commands instead of calling
 
 ## UI Execution
 
-`@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 section is for template users building interactive resource pages in `external/_template` who want to add Run buttons, input forms, and execution result displays.
+`@elevasis/ui` ships components and hooks that let your custom React pages trigger workflow and agent executions without wiring up API calls manually. This section is for template users building interactive resource pages who want to add Run buttons, input forms, and execution result displays.
 
-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.
+Two published pieces cover triggering: `useExecuteAsync` (the mutation) and `ExecuteWorkflowModal` (the modal chrome). You supply the input UI -- there is no built-in form renderer. `@elevasis/ui/features/operations` also publishes ready-made panels (`ExecutionPanel`, `WorkflowExecutionPanel`, `AgentExecutionPanel`) for when you want an execution history view rather than a trigger.
 
-### Quick Start -- `ResourceExecuteDialog`
+### `useExecuteAsync`
 
-`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.
+`useExecuteAsync()` is a TanStack Query mutation that POSTs to the execution engine and resolves to `{ executionId, status, resourceId }`.
 
 ```tsx
-import { useState } from 'react'
-import { Button } from '@mantine/core'
-import { ResourceExecuteDialog } from '@elevasis/ui/features/operations'
-import { useNavigate } from '@tanstack/react-router'
-
-const resource = {
-  resourceId: 'qualify-lead-workflow',
-  resourceType: 'workflow' as const,
-  name: 'Qualify Lead',
-  formSchema: {
-    fields: [
-      { name: 'email', label: 'Lead email', type: 'text', required: true },
-      { name: 'company', label: 'Company', type: 'text', required: false },
-    ],
-  },
-}
-
-export function QualifyLeadPage() {
-  const [opened, setOpened] = useState(false)
-  const navigate = useNavigate()
+import { useExecuteAsync } from '@elevasis/ui/hooks'
 
-  return (
-    <>
-      <Button onClick={() => setOpened(true)}>Run</Button>
+const { mutateAsync, mutate, isPending, error, data, reset } = useExecuteAsync()
 
-      <ResourceExecuteDialog
-        opened={opened}
-        onClose={() => setOpened(false)}
-        resource={resource}
-        onViewExecution={(executionId) =>
-          navigate({ to: '/logs/$executionId', params: { executionId } })
-        }
-      />
-    </>
-  )
-}
+await mutateAsync({
+  resourceId: 'qualify-lead-workflow',
+  resourceType: 'workflow',
+  input: { email: 'lead@example.com' }
+})
 ```
 
-What the user sees when they click Run:
-
-- A modal opens titled "Run workflow" with the resource ID displayed.
-- The form renders one field per entry in `formSchema.fields`. Required fields show validation errors on submit.
-- On submit, a loading overlay appears while the POST is in flight.
-- On success, a teal confirmation card shows the execution ID. A "View execution" button calls `onViewExecution` with that ID.
-- On error, a red alert shows the error message with a "Try again" option.
+`ExecuteAsyncParams`:
 
-If `formSchema` is omitted or has no fields, the form skips to a single "Run" button with the message "This workflow takes no input."
+| Field          | Type           | Notes                                                    |
+| -------------- | -------------- | -------------------------------------------------------- |
+| `resourceId`   | `string`       | Deployed resource ID                                     |
+| `resourceType` | `ResourceType` | `'workflow'` or `'agent'`                                |
+| `input`        | `unknown`      | Passed through to the resource's input schema            |
+| `listId`       | `string`       | Optional; also attaches the execution to a lead-gen list |
 
-### The Three-Tier API
+On success it invalidates the executions list query keyed by organization plus `resourceId`, so any `useExecutions` query on the page refreshes automatically.
 
-| Tier            | Component / Hook                           | Use case                                                                                        |
-| --------------- | ------------------------------------------ | ----------------------------------------------------------------------------------------------- |
-| Convenience     | `ResourceExecuteDialog`                    | One-tag Run button + modal + form. Parent only manages `opened` state.                          |
-| Controlled form | `ResourceExecuteForm`                      | Custom modal chrome; parent owns the mutation and decides where to show results.                |
-| Low-level       | `ExecuteWorkflowModal` + `useExecuteAsync` | Fully custom rendering, non-standard modal behavior, or composing execution into a larger flow. |
+### `ExecuteWorkflowModal`
 
-Start with `ResourceExecuteDialog`. Move down the tiers only when you need something the convenience component cannot do.
-
-### Controlled Usage with `ResourceExecuteForm`
-
-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.
-
-`ResourceExecuteForm` accepts `onSubmit` and `isPending` from the parent. The parent calls `useExecuteAsync()` directly and passes `mutateAsync` as the submit handler.
+`ExecuteWorkflowModal` is a Mantine Modal pre-wired with a loading overlay, a success card (execution ID plus a "View execution" button), and an error alert. Pass your input UI as `children`.
 
 ```tsx
 import { useState } from 'react'
-import { Modal, Button, Text } from '@mantine/core'
-import { ResourceExecuteForm } from '@elevasis/ui/features/operations'
+import { Button, TextInput } from '@mantine/core'
+import { ExecuteWorkflowModal } from '@elevasis/ui/features/operations'
 import { useExecuteAsync } from '@elevasis/ui/hooks'
+import { useNavigate } from '@tanstack/react-router'
 
-const formSchema = {
-  fields: [
-    { name: 'topic', label: 'Topic', type: 'text', required: true },
-  ],
-}
-
-export function CustomRunPanel() {
+export function QualifyLeadPage() {
   const [opened, setOpened] = useState(false)
-  const mutation = useExecuteAsync()
-
-  const handleSubmit = async (input: Record<string, unknown>) => {
-    await mutation.mutateAsync({
-      resourceId: 'research-agent',
-      resourceType: 'agent',
-      input,
-    })
-  }
+  const [email, setEmail] = useState('')
+  const navigate = useNavigate()
+  const { mutateAsync, isPending, error, data, reset } = useExecuteAsync()
 
   return (
     <>
-      <Button onClick={() => setOpened(true)}>Run agent</Button>
-
-      {mutation.data && (
-        <Text size="sm">Started: {mutation.data.executionId}</Text>
-      )}
-
-      <Modal opened={opened} onClose={() => setOpened(false)} title="Run research agent">
-        <ResourceExecuteForm
-          formSchema={formSchema}
-          onSubmit={handleSubmit}
-          isPending={mutation.isPending}
-          disabled={mutation.isPending}
-          submitLabel="Start research"
-        />
-      </Modal>
+      <Button onClick={() => setOpened(true)}>Run</Button>
+
+      <ExecuteWorkflowModal
+        opened={opened}
+        onClose={() => setOpened(false)}
+        resource={{ resourceId: 'qualify-lead-workflow', resourceType: 'workflow', name: 'Qualify Lead' }}
+        isPending={isPending}
+        error={error}
+        result={data ?? null}
+        onReset={reset}
+        onViewExecution={(executionId) => navigate({ to: '/logs/$executionId', params: { executionId } })}
+      >
+        <TextInput label="Lead email" value={email} onChange={(e) => setEmail(e.currentTarget.value)} />
+        <Button
+          mt="md"
+          loading={isPending}
+          onClick={() => mutateAsync({ resourceId: 'qualify-lead-workflow', resourceType: 'workflow', input: { email } })}
+        >
+          Run
+        </Button>
+      </ExecuteWorkflowModal>
     </>
   )
 }
 ```
 
-`ResourceExecuteForm` props:
-
-| Prop          | Type                                 | Default  | Notes                                |
-| ------------- | ------------------------------------ | -------- | ------------------------------------ |
-| `formSchema`  | `SerializedExecutionFormSchema`      | required | Drives field rendering               |
-| `onSubmit`    | `(input) => void | Promise<void>` | required | Called with mapped field values      |
-| `isPending`   | `boolean`                            | `false`  | Shows loading state on submit button |
-| `disabled`    | `boolean`                            | `false`  | Disables all fields and button       |
-| `submitLabel` | `string`                             | `'Run'`  | Button label when not pending        |
-
-### Low-Level: Hooks and `ExecuteWorkflowModal`
-
-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.
-
-```tsx
-import { ExecuteWorkflowModal } from '@elevasis/ui/features/operations'
-import { useExecuteAsync } from '@elevasis/ui/hooks'
+`ExecuteWorkflowModalProps`:
 
-const { mutateAsync, isPending, error, data, reset } = useExecuteAsync()
-
-<ExecuteWorkflowModal
-  opened={opened}
-  onClose={() => setOpened(false)}
-  resource={{ resourceId: 'my-workflow', resourceType: 'workflow', name: 'My Workflow' }}
-  isPending={isPending}
-  error={error}
-  result={data ?? null}
-  onViewExecution={handleViewExecution}
-  onReset={reset}
->
-  {/* your custom form or content here */}
-</ExecuteWorkflowModal>
-```
+| Prop              | Type                            | Default  | Notes                                                |
+| ----------------- | ------------------------------- | -------- | ---------------------------------------------------- |
+| `opened`          | `boolean`                       | required | Modal visibility                                     |
+| `onClose`         | `() => void`                    | required | Ignored while `isPending`                            |
+| `resource`        | `ExecuteWorkflowModalResource`  | required | `{ resourceId, resourceType, name? }`                |
+| `isPending`       | `boolean`                       | `false`  | Shows the loading overlay and locks dismissal        |
+| `error`           | `Error | null`                 | --       | Renders the error alert                              |
+| `result`          | `ExecuteAsyncResult | null`    | --       | Renders the success card                             |
+| `onViewExecution` | `(executionId: string) => void` | --       | Adds the "View execution" button to the success card |
+| `onReset`         | `() => void`                    | --       | Backs the "Try again" action                         |
+| `children`        | `ReactNode`                     | --       | Your input UI                                        |
 
 The modal locks close interactions (click-outside, Escape, close button) while `isPending` is true, preventing accidental dismissal mid-execution.
 
-Source: `packages/ui/src/features/operations/executions/ExecuteWorkflowModal.tsx`, `packages/ui/src/hooks/executions/useExecuteAsync.ts`
-
-### Zod-Validated Execution with `useExecuteWorkflow`
-
-`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.
-
-```tsx
-import { z } from 'zod'
-import { useExecuteWorkflow } from '@elevasis/ui/hooks'
-
-const inputSchema = z.object({
-  email: z.string().email(),
-  score: z.number().min(0).max(100),
-})
-
-function useScoredExecution() {
-  return useExecuteWorkflow({ schema: inputSchema })
-}
-
-// In a component:
-const { execute, isPending, data, error } = useScoredExecution()
-
-await execute({
-  resourceId: 'score-lead-workflow',
-  resourceType: 'workflow',
-  input: { email: 'lead@example.com', score: 72 },
-})
-```
-
-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.
-
-Prefer `useExecuteWorkflow` over raw `useExecuteAsync` when:
-
-- Input is assembled from multiple sources (not a single form submit).
-- You want TypeScript inference on the input shape via `z.infer`.
-- You want a clear validation error message rather than a 400 from the API.
-
-Source: `packages/ui/src/hooks/executions/useExecuteWorkflow.ts`
-
-### Input Forms
-
-`ResourceExecuteDialog` and `ResourceExecuteForm` auto-render form fields from `formSchema.fields`. Each field is a `SerializedFormField` with at minimum `name`, `label`, and `type`.
-
-Supported field types:
-
-- `text` -- single-line text input
-- `textarea` -- multi-line text input
-- `number` -- numeric input
-- `select` -- dropdown with `options` array
-- `checkbox` -- boolean toggle; defaults to `false`
-- `radio` -- radio group with `options` array
-- `richtext` -- rich text editor
-
-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`.
-
-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.
-
 ### Error and Result Handling
 
-Mutation state flows automatically into the modal chrome when using `ResourceExecuteDialog` or `ExecuteWorkflowModal`:
+Mutation state flows into the modal chrome automatically:
 
 - **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.
-- **Error** -- a red alert displays `error.message`. A "Try again" button calls `onReset`, which clears the mutation state and re-shows the form.
-- **Pending** -- a blur overlay covers the form area while the POST is in flight. The modal cannot be dismissed during this state.
-
-`useExecuteAsync` also invalidates the executions list query on success (keyed by `organizationId` + `resourceId`), so any `useExecutions` query on the page refreshes automatically.
+- **Error** -- a red alert displays `error.message`. A "Try again" button calls `onReset`, which clears the mutation state and re-shows the children.
+- **Pending** -- a blur overlay covers the content area while the POST is in flight. The modal cannot be dismissed during this state.
 
 ---
 

package/reference/sdk/deployment/index.mdx

@@ -248,6 +248,8 @@ Host apps still own TanStack route registration, topbar behavior, branding, auth
 
 Manifest `systemId` values must match Organization Model System IDs. Sidebar placement is authored in the Organization Model navigation domain:
 
+{/* doc-snippet:skip: illustrative excerpt, not a standalone compilable file */}
+
 ```ts
 systems: {
   dashboard: { id: 'dashboard', order: 10, label: 'Dashboard', lifecycle: 'active' },

package/reference/sdk/exports.mdx

@@ -8,7 +8,7 @@ description: "Auto-generated catalog of all published @elevasis/sdk subpath expo
 
 | Import | Title | Group | Description |
 | --- | --- | --- | --- |
-| `@elevasis/sdk` | SDK | Getting Started | Root SDK types, config, runtime errors, and registry surface. |
-| `@elevasis/sdk/worker` | Worker Runtime | Runtime | Worker runtime entrypoint, adapters, and platform execution surface. |
-| `@elevasis/sdk/test-utils` | Test Utils | Testing | Workflow runner, registry assertion, and typed adapter mocks for SDK consumers. |
-| `@elevasis/sdk/node` | Node Build Tooling | Tooling | Node-only build helpers: knowledge codegen and other fs/path/process utilities. Not browser-safe. |
+| `@elevasis/sdk` | SDK | Getting Started |  |
+| `@elevasis/sdk/worker` | Worker Runtime | Runtime |  |
+| `@elevasis/sdk/test-utils` | Test Utils | Testing |  |
+| `@elevasis/sdk/node` | Node Build Tooling | Tooling |  |