@elevasis/sdk 1.8.3 → 1.10.0

package/reference/index.mdx

@@ -8,7 +8,7 @@ loadWhen: "First session or new to the SDK"
 
 Workflows are step-based automations with typed inputs and outputs. Agents are autonomous AI resources with access to platform tools. Both are defined in TypeScript, exported from a single entry point, and deployed with `elevasis-sdk deploy`. Resources appear in AI Studio immediately after a successful deploy.
 
-The SDK ships with a full CLI (`elevasis-sdk`) for validation, deployment, execution, 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.
+The SDK ships with a full CLI (`elevasis-sdk`) for validation, deployment, execution, inspection, and project-management operations. Platform tools expose 70+ tools across integration adapters and platform services -- Gmail, Stripe, Google Sheets, Attio, and more -- with credentials managed server-side so API keys never cross the execution boundary.
 
 ## Quick Start
 
@@ -25,7 +25,7 @@ After `pnpm dlx @elevasis/sdk init`, your project is scaffolded with a working e
 
 - **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.
 - **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.
-- **Feature-driven apps** -- The published `@elevasis/ui@2.7.0` surface includes manifest-backed shared features for Lead Gen, CRM, Projects, Operations, Monitoring, Settings, and SEO, plus dashboard-oriented compatibility components for host-owned shells. See [Provided Features](deployment/provided-features.mdx).
+- **Feature-driven apps** -- The published `@elevasis/ui` surface includes manifest-backed shared features for Lead Gen, CRM, Projects, Operations, Monitoring, Settings, and SEO, plus dashboard-oriented compatibility components for host-owned shells. See [Provided Features](deployment/provided-features.mdx).
 
 ## Platform Tools
 
@@ -41,7 +41,7 @@ await scheduler.createSchedule({ ... })
 const result = await llm.generate({ messages: [...] })
 ```
 
-The platform exposes 70+ tools across 12 integration adapters -- Gmail, Stripe, Google Sheets, Attio, and more. Credentials are managed server-side; API keys never cross the execution boundary.
+The platform exposes 70+ tools across integration adapters and platform services -- Gmail, Stripe, Google Sheets, Attio, and more. Credentials are managed server-side; API keys never cross the execution boundary.
 
 See [Platform Tools](platform-tools/index.mdx) for the full catalog.
 
@@ -72,7 +72,7 @@ See [Platform Tools](platform-tools/index.mdx) for the full catalog.
 
 ### Typed Adapters
 
-- [Integration Adapters](platform-tools/adapters-integration.mdx) - All 12 integration adapters: Attio, Stripe, Google Sheets, Resend, and more
+- [Integration Adapters](platform-tools/adapters-integration.mdx) - Integration adapter catalog for Attio, Stripe, Google Sheets, Resend, and more
 - [Platform Adapters](platform-tools/adapters-platform.mdx) - All 9 platform service adapters: scheduler, storage, llm, pdf, approval, and more
 
 ### Framework
@@ -94,6 +94,7 @@ See [Platform Tools](platform-tools/index.mdx) for the full catalog.
 - [Command Center](deployment/command-center.mdx) - Resource graph, relationships, node types, and post-deployment UI reference
 - [Provided Features](deployment/provided-features.mdx) - Manifest-backed shared features, compatibility components, and host shell wiring
 - [Execution API](deployment/api.mdx) - REST endpoints for executing resources and managing deployments
+- [UI Execution](deployment/ui-execution.mdx) - Custom React execution dialogs, forms, and hooks built with `@elevasis/ui`
 
 ### More
 
@@ -102,4 +103,4 @@ See [Platform Tools](platform-tools/index.mdx) for the full catalog.
 
 ---
 
-**Last Updated:** 2026-04-16
+**Last Updated:** 2026-04-23

package/reference/packages/core/src/test-utils/README.md

@@ -2,12 +2,14 @@
 
 Published test helpers for downstream consumers of `@elevasis/core`.
 
-The public `@elevasis/core/test-utils` subpath is intentionally narrow. It exposes:
+The public `@elevasis/core/test-utils` subpath exposes:
 
 - `RLSTestContext` for dev-database RLS integration tests
 - `setupMatchMedia`, `setupResizeObserver`, and `setupBrowserMocks` for jsdom/browser test setup
-
-Internal monorepo fixtures and Vitest-specific mocks still exist under `packages/core/src/test-utils/`, but they are not part of the published package contract.
+- `TEST_USERS`, `TEST_ORGS`, `TEST_MEMBERSHIPS`, and related fixture factories
+- `createMockSupabaseClient`, `createMockWorkOSClient`, and related mocks
+- base entity factories such as `makeProject`, `makeDeal`, and `makeTask`
+- organization model/profile builders such as `makeOrganizationModel`, `makeInitializationState`, and `makeUserProfile`
 
 ## Published Usage
 
@@ -33,10 +35,3 @@ const ctx = new RLSTestContext()
 - `SUPABASE_ANON_KEY`
 - `SUPABASE_SERVICE_KEY`
 - `SUPABASE_JWT_SECRET`
-
-## Internal Scope
-
-The following folders remain implementation detail for the monorepo and are not published:
-
-- `fixtures/`
-- `mocks/`

package/reference/packages/ui/src/test-utils/README.md

@@ -0,0 +1,5 @@
+# UI Test Utilities
+
+Published test helpers for consumers that test Elevasis UI composition.
+
+Use `@elevasis/ui/test-utils` for provider-aware React rendering, WorkOS auth mocks, MSW handlers, and test query clients. Use `@elevasis/ui/test-utils/setup` or `@elevasis/ui/test-utils/setup-integration` from Vitest `setupFiles` when a consumer wants the shared browser and auth mocks.

package/reference/scaffold/operations/workflow-recipes.md

@@ -433,4 +433,97 @@ export const agents: never[] = []
 3. Import the group barrel in `operations/src/index.ts` and spread into `workflows`/`agents`.
 4. Run `pnpm -C operations check` to validate, then `pnpm -C operations deploy` to publish.
 
-**Note:** Use `.js` extensions in imports even though the source is TypeScript. The TypeScript compiler and esbuild bundler both require this for ESM interoperability.
+**Note:** Use `.js` extensions in imports even though the source is TypeScript. The TypeScript compiler and esbuild bundler both require this for ESM interoperability.
+
+---
+
+## 5. Testing Custom Workflows And UI
+
+Package-owned test helpers are the stable way to test custom downstream code. Do not copy template-only tests into a project unless the project owns the matching workflow, route, or component.
+
+After the bundled package release lands, use these public subpaths:
+
+```typescript
+import { makeProject } from '@elevasis/core/test-utils'
+import { renderWithProviders, mockAuthenticatedUser } from '@elevasis/ui/test-utils'
+import { assertResourceRegistry, mockNotifications, runWorkflow } from '@elevasis/sdk/test-utils'
+```
+
+### Workflow Smoke Test
+
+Use `runWorkflow` for project-owned workflows. This tests the workflow contract, step execution, and parsed output without deploying.
+
+```typescript
+import { describe, expect, it } from 'vitest'
+import { runWorkflow, mockNotifications } from '@elevasis/sdk/test-utils'
+import { emailNotification } from './index'
+import type { EmailNotificationOutput } from '@foundation/types'
+
+describe('emailNotification workflow', () => {
+  it('runs the notify step with a mocked notification adapter', async () => {
+    const notifications = mockNotifications({
+      create: { id: 'notification-1' }
+    })
+
+    const result = await runWorkflow<EmailNotificationOutput>(
+      emailNotification,
+      {
+        recipientEmail: 'jane@example.com',
+        recipientName: 'Jane',
+        subject: 'Action ready',
+        body: 'Your request has been processed.'
+      },
+      { adapters: { notification: notifications } }
+    )
+
+    expect(result.output.delivered).toBe(true)
+    expect(result.stepEvents.map((event) => event.stepId)).toContain('notify')
+  })
+})
+```
+
+### Registry Smoke Test
+
+Use `assertResourceRegistry` for a project-owned `operations/src/index.ts` manifest. Keep assertions generic unless the project intentionally owns a fixed workflow list.
+
+```typescript
+import { describe, expect, it } from 'vitest'
+import { assertResourceRegistry } from '@elevasis/sdk/test-utils'
+import org from './index'
+
+describe('operations registry', () => {
+  it('registers a valid operations manifest', () => {
+    const spec = assertResourceRegistry(org, { organizationName: 'Example Project' })
+    const workflows = spec.workflows ?? []
+
+    expect(workflows.length + (spec.agents?.length ?? 0)).toBeGreaterThan(0)
+    expect(new Set(workflows.map((workflow) => workflow.config.resourceId)).size).toBe(workflows.length)
+  })
+})
+```
+
+### UI And Core Fixtures
+
+Use `@elevasis/ui/test-utils` for route/component tests and `@elevasis/core/test-utils` for schema-compatible fixtures.
+
+```tsx
+import { describe, expect, it } from 'vitest'
+import { screen } from '@testing-library/react'
+import { makeProject } from '@elevasis/core/test-utils'
+import { mockAuthenticatedUser, renderWithProviders } from '@elevasis/ui/test-utils'
+import { ProjectCard } from './ProjectCard'
+
+describe('ProjectCard', () => {
+  it('renders a project fixture for an authenticated user', () => {
+    const project = makeProject({ name: 'Website Refresh' })
+
+    renderWithProviders(<ProjectCard project={project} />, {
+      auth: mockAuthenticatedUser()
+    })
+
+    expect(screen.getByText('Website Refresh')).toBeInTheDocument()
+  })
+})
+```
+
+Template tests are examples and smoke coverage. Downstream projects should keep custom tests close to the feature they validate, then consume these package helpers instead of copying scaffold internals.

package/reference/scaffold/recipes/add-a-feature.md

@@ -16,7 +16,7 @@ See [glossary.md](../reference/glossary.md) for term disambiguation throughout t
 A shell feature requires a `feature.id` in the org model's `features[]` array to gate it. You have two options:
 
 - **Reuse an existing feature** (e.g., `operations`, `monitoring`). The new shell module shares the on/off toggle with the existing feature entry. Fine for sub-modules within the same product area.
-- **Add a new feature object** -- add an entry to the `features[]` array in `foundations/config/organization-model.ts`. This is always a template-local change; no core package change is required.
+- **Add a new feature object** -- add an entry to the `features[]` array in `core/config/organization-model.ts`. This is always a template-local change; no core package change is required.
 
 For a genuinely new capability (e.g., `analytics`), you add a feature object to the defaults array and author a matching manifest.
 
@@ -26,7 +26,7 @@ See [glossary.md](../reference/glossary.md) under **Feature** (three contexts).
 
 ## 2. Update the organization model
 
-File: `foundations/config/organization-model.ts`
+File: `core/config/organization-model.ts`
 
 Add a new feature object to the `features[]` array passed to `defineOrganizationModel`.
 
@@ -63,7 +63,7 @@ Each field of the feature object:
 
 No domain entry or separate key resolver is needed. The `features[]` array is the sole source of truth.
 
-**Two-step pattern:** in a template-derived project, the `defineOrganizationModel` output is passed to `createFoundationOrganizationModel(override)` in `foundations/config/organization-model.ts`. The result exposes `.model`, `.canonical`, and `.homeLabel`. See `external/_template/foundations/config/organization-model.ts` for the canonical two-step example.
+**Two-step pattern:** in a template-derived project, the `defineOrganizationModel` output is passed to `createFoundationOrganizationModel(override)` in `core/config/organization-model.ts`. The result exposes `.model`, `.canonical`, and `.homeLabel`. See `external/_template/core/config/organization-model.ts` for the canonical two-step example.
 
 ---
 
@@ -154,5 +154,5 @@ pnpm -C ui dev
 
 - Feature appears in the nav sidebar.
 - Route is accessible and the subshell sidebar renders.
-- Toggle `features.enabled.analytics` to `false` in `foundations/config/organization-model.ts` and confirm the nav item disappears and the route redirects.
+- Toggle `features.enabled.analytics` to `false` in `core/config/organization-model.ts` and confirm the nav item disappears and the route redirects.
 - Check `FeatureGuard` by navigating directly to `/analytics` with the feature disabled.

package/reference/scaffold/recipes/add-a-resource.md

@@ -115,7 +115,7 @@ Full relationship and checkpoint types are defined in `@elevasis/sdk` (`Deployme
 
 ## 4. (Optional) Map to a domain
 
-To make the resource referenceable from the org model (so the Operations graph and Command View can link to it), add an entry to `resourceMappings` in `foundations/config/organization-model.ts`:
+To make the resource referenceable from the org model (so the Operations graph and Command View can link to it), add an entry to `resourceMappings` in `core/config/organization-model.ts`:
 
 ```ts
 resourceMappings: [

package/reference/scaffold/recipes/customize-organization-model.md

@@ -5,7 +5,7 @@ description: Annotated walkthrough for customizing the organization model in tem
 
 # Customize organization-model.ts
 
-`foundations/config/organization-model.ts` is the semantic contract between your UI runtime
+`core/config/organization-model.ts` is the semantic contract between your UI runtime
 and your platform operations. Every feature your users can access, every nav surface they can
 navigate to, and every resource backed by a workflow is declared here. The provider reads this
 contract at startup; everything downstream -- routing, gating, nav rendering -- derives from it.
@@ -366,7 +366,7 @@ Both sides must be consistent (schema validates bidirectionality):
 
 The organization model flows through the runtime in one direction:
 
-1. `foundations/config/organization-model.ts` calls `resolveOrganizationModel` at module load.
+1. `core/config/organization-model.ts` calls `resolveOrganizationModel` at module load.
    The resolved `canonicalOrganizationModel` is exported.
 2. `ui/src/routes/__root.tsx` imports `canonicalOrganizationModel` and passes it to
    `ElevasisFeaturesProvider` along with the `FEATURE_MANIFESTS` array.

package/reference/scaffold/recipes/gate-by-feature-or-admin.md

@@ -27,7 +27,7 @@ Do not substitute one for the other. `FeatureGuard` reads feature flags; `AdminG
 
 ## 2. Feature gate -- org level
 
-Ensure a feature object with the matching `id` exists in the org model. File: `foundations/config/organization-model.ts`.
+Ensure a feature object with the matching `id` exists in the org model. File: `core/config/organization-model.ts`.
 
 ```ts
 import { defineOrganizationModel, OPERATIONS_FEATURE_ID, SALES_FEATURE_ID } from '@elevasis/core/organization-model'
@@ -155,4 +155,4 @@ State matrix -- confirm each combination:
 | true                | (absent)        | non-admin | Admin-gated route redirects, admin nav hidden |
 | true                | (absent)        | admin     | Admin-gated route accessible, nav visible     |
 
-Check each gate independently: feature toggle in `foundations/config/organization-model.ts`, membership config in `org_memberships.config`, and admin status in the user profile.
+Check each gate independently: feature toggle in `core/config/organization-model.ts`, membership config in `org_memberships.config`, and admin status in the user profile.

package/reference/claude-config/commands/submit-request.md

@@ -1,11 +0,0 @@
-# Submit Request
-
-**Usage:** `/submit-request [optional one-line description]`
-
-**Goal:** File a structured request report to the Elevasis platform after agent-driven pre-analysis.
-
-**EXECUTE:** `.claude/skills/submit-request/SKILL.md`
-
-## Env Requirements
-
-- `ELEVASIS_PLATFORM_KEY` (same key used by all `elevasis-sdk` commands — no extra setup if deploy already works)