@elevasis/sdk 1.44.3 → 1.45.0

package/reference/sdk/templates/web-scraper.mdx

@@ -1,135 +1,139 @@
----
-title: "Template: Web Scraper"
-description: "Apify-based web scraper that stores results in Supabase -- fetch structured data from any website via Apify actors"
-loadWhen: "Applying the web-scraper workflow template"
----
-
-**Category:** Data Collection
-
-**Platform Tools:** `apify` (run actor), `supabase` (insert results)
-
-**Credentials Required:**
-
-- `apify` -- Apify API token (bearer type)
-- `my-database` -- Supabase project URL and service role key
-
----
-
-## What This Workflow Does
-
-Runs an Apify actor to scrape structured data from a URL, then stores the scraped results in a Supabase table. The actor and table names are configurable. Suitable for extracting product listings, job postings, contact information, or any structured web content.
-
----
-
-## Input Schema
-
-```typescript
-z.object({
-  actorId: z.string(),          // Apify actor ID (e.g., 'apify/web-scraper')
-  startUrls: z.array(z.string()), // URLs to scrape
-  tableName: z.string(),        // Supabase table to store results in
-  maxItems: z.number().optional(), // Maximum number of items to collect (default: 100)
-})
-```
-
-## Output Schema
-
-```typescript
-z.object({
-  itemsScraped: z.number(),     // Total items scraped
-  itemsInserted: z.number(),    // Items successfully inserted into Supabase
-  runId: z.string(),            // Apify run ID for reference
-})
-```
-
----
-
-## Workflow Code Pattern
-
-```typescript
-import type { WorkflowDefinition } from '@elevasis/sdk'
-import { StepType } from '@elevasis/sdk'
-import { platform, PlatformToolError } from '@elevasis/sdk/worker'
-import { z } from 'zod'
-
-const inputSchema = z.object({
-  actorId: z.string(),
-  startUrls: z.array(z.string()),
-  tableName: z.string(),
-  maxItems: z.number().optional(),
-})
-const outputSchema = z.object({
-  itemsScraped: z.number(),
-  itemsInserted: z.number(),
-  runId: z.string(),
-})
-
-type Input = z.infer<typeof inputSchema>
-
-export const webScraper: WorkflowDefinition = {
-  config: {
-    resourceId: 'web-scraper',
-    name: 'Web Scraper',
-    type: 'workflow',
-    description: 'Scrapes structured data via Apify and stores in Supabase',
-    version: '1.0.0',
-    status: 'dev',
-  },
-  contract: { inputSchema, outputSchema },
-  steps: {
-    scrape: {
-      id: 'scrape',
-      name: 'Run Apify Actor',
-      description: 'Execute the Apify actor and collect results',
-      inputSchema,
-      outputSchema: z.object({ items: z.array(z.unknown()), runId: z.string() }),
-      handler: async (input) => {
-        const { actorId, startUrls, maxItems } = input as Input
-        const result = await platform.call({
-          tool: 'apify',
-          method: 'runActor',
-          credential: 'apify',
-          params: { actorId, input: { startUrls: startUrls.map(url => ({ url })), maxItems: maxItems ?? 100 } },
-        }) as { items: unknown[]; runId: string }
-        return { items: result.items, runId: result.runId }
-      },
-      next: { type: StepType.LINEAR, target: 'store' },
-    },
-    store: {
-      id: 'store',
-      name: 'Store Results',
-      description: 'Insert scraped items into Supabase',
-      inputSchema: z.object({ items: z.array(z.unknown()), runId: z.string(), tableName: z.string() }),
-      outputSchema,
-      handler: async (input, context) => {
-        const { items, runId, tableName } = input as { items: unknown[]; runId: string; tableName: string }
-        const data = items.map(item => ({ ...(item as Record<string, unknown>), scraped_at: new Date().toISOString() }))
-        await platform.call({
-          tool: 'supabase',
-          method: 'insert',
-          credential: 'my-database',
-          params: { table: tableName, data },
-        })
-        context.logger.info('Stored scraped items', { count: data.length, table: tableName })
-        return { itemsScraped: items.length, itemsInserted: data.length, runId }
-      },
-      next: null,
-    },
-  },
-  entryPoint: 'scrape',
-}
-```
-
----
-
-## Adaptation Notes
-
-- **Credential names:** Replace `'apify'` and `'my-database'` with the credential names the user configured in the command center.
-- **Table schema:** Ensure the Supabase table exists and has columns that match the scraped data fields. The agent should check `data/schema.ts` if it exists.
-- **Actor selection:** Apify has hundreds of public actors. Common choices: `apify/web-scraper` (generic), `apify/cheerio-scraper` (fast HTML parsing), specialized actors for LinkedIn, Amazon, etc.
-- **Error handling:** Add try/catch for `PlatformToolError` if partial failure tolerance is needed.
-- **Skill adaptation:** For beginners, explain what Apify is and walk through actor selection before generating code.
-
----
-
-**Last Updated:** 2026-02-26
+---
+title: "Template: Web Scraper"
+description: "Apify-based web scraper that stores results in Supabase -- fetch structured data from any website via Apify actors"
+loadWhen: "Applying the web-scraper workflow template"
+---
+
+**Category:** Data Collection
+
+**Platform Tools:** `apify` (run actor), `supabase` (insert results)
+
+**Credentials Required:**
+
+- `apify` -- Apify API token (bearer type)
+- `my-database` -- Supabase project URL and service role key
+
+---
+
+## What This Workflow Does
+
+Runs an Apify actor to scrape structured data from a URL, then stores the scraped results in a Supabase table. The actor and table names are configurable. Suitable for extracting product listings, job postings, contact information, or any structured web content.
+
+---
+
+## Input Schema
+
+{/* doc-snippet:skip: illustrative excerpt -- shows the schema shape in isolation, omits the `import { z } from 'zod'` shown in Workflow Code Pattern below */}
+
+```typescript
+z.object({
+  actorId: z.string(),          // Apify actor ID (e.g., 'apify/web-scraper')
+  startUrls: z.array(z.string()), // URLs to scrape
+  tableName: z.string(),        // Supabase table to store results in
+  maxItems: z.number().optional(), // Maximum number of items to collect (default: 100)
+})
+```
+
+## Output Schema
+
+{/* doc-snippet:skip: illustrative excerpt -- shows the schema shape in isolation, omits the `import { z } from 'zod'` shown in Workflow Code Pattern below */}
+
+```typescript
+z.object({
+  itemsScraped: z.number(),     // Total items scraped
+  itemsInserted: z.number(),    // Items successfully inserted into Supabase
+  runId: z.string(),            // Apify run ID for reference
+})
+```
+
+---
+
+## Workflow Code Pattern
+
+```typescript
+import type { WorkflowDefinition } from '@elevasis/sdk'
+import { StepType } from '@elevasis/sdk'
+import { platform, PlatformToolError } from '@elevasis/sdk/worker'
+import { z } from 'zod'
+
+const inputSchema = z.object({
+  actorId: z.string(),
+  startUrls: z.array(z.string()),
+  tableName: z.string(),
+  maxItems: z.number().optional(),
+})
+const outputSchema = z.object({
+  itemsScraped: z.number(),
+  itemsInserted: z.number(),
+  runId: z.string(),
+})
+
+type Input = z.infer<typeof inputSchema>
+
+export const webScraper: WorkflowDefinition = {
+  config: {
+    resourceId: 'web-scraper',
+    name: 'Web Scraper',
+    type: 'workflow',
+    description: 'Scrapes structured data via Apify and stores in Supabase',
+    version: '1.0.0',
+    status: 'dev',
+  },
+  contract: { inputSchema, outputSchema },
+  steps: {
+    scrape: {
+      id: 'scrape',
+      name: 'Run Apify Actor',
+      description: 'Execute the Apify actor and collect results',
+      inputSchema,
+      outputSchema: z.object({ items: z.array(z.unknown()), runId: z.string() }),
+      handler: async (input) => {
+        const { actorId, startUrls, maxItems } = input as Input
+        const result = await platform.call({
+          tool: 'apify',
+          method: 'runActor',
+          credential: 'apify',
+          params: { actorId, input: { startUrls: startUrls.map(url => ({ url })), maxItems: maxItems ?? 100 } },
+        }) as { items: unknown[]; runId: string }
+        return { items: result.items, runId: result.runId }
+      },
+      next: { type: StepType.LINEAR, target: 'store' },
+    },
+    store: {
+      id: 'store',
+      name: 'Store Results',
+      description: 'Insert scraped items into Supabase',
+      inputSchema: z.object({ items: z.array(z.unknown()), runId: z.string(), tableName: z.string() }),
+      outputSchema,
+      handler: async (input, context) => {
+        const { items, runId, tableName } = input as { items: unknown[]; runId: string; tableName: string }
+        const data = items.map(item => ({ ...(item as Record<string, unknown>), scraped_at: new Date().toISOString() }))
+        await platform.call({
+          tool: 'supabase',
+          method: 'insert',
+          credential: 'my-database',
+          params: { table: tableName, data },
+        })
+        context.logger.info(`Stored ${data.length} scraped items in ${tableName}`)
+        return { itemsScraped: items.length, itemsInserted: data.length, runId }
+      },
+      next: null,
+    },
+  },
+  entryPoint: 'scrape',
+}
+```
+
+---
+
+## Adaptation Notes
+
+- **Credential names:** Replace `'apify'` and `'my-database'` with the credential names the user configured in the command center.
+- **Table schema:** Ensure the Supabase table exists and has columns that match the scraped data fields. The agent should check `data/schema.ts` if it exists.
+- **Actor selection:** Apify has hundreds of public actors. Common choices: `apify/web-scraper` (generic), `apify/cheerio-scraper` (fast HTML parsing), specialized actors for LinkedIn, Amazon, etc.
+- **Error handling:** Add try/catch for `PlatformToolError` if partial failure tolerance is needed.
+- **Skill adaptation:** For beginners, explain what Apify is and walk through actor selection before generating code.
+
+---
+
+**Last Updated:** 2026-02-26

package/reference/spine/spine-primer.md

@@ -1,99 +1,138 @@
----
-title: Spine Primer
-description: Tenant-facing primer for using an Organization Model catalog as the shared coordination spine between workflow producers, runtime state, API filters, and UI projections.
----
+---
+title: Spine Primer
+description: Tenant-facing primer for using an Organization Model ontology catalog as the shared coordination spine between workflow producers, runtime state, API filters, and UI projections.
+---
 <!-- @generated by packages/sdk/scripts/copy-reference-docs.mjs -- DO NOT EDIT -->
 <!-- Regenerate: pnpm scaffold:sync -->
 
-
-# Spine Primer
-
-Use this primer when a tenant domain has a closed set of stages, statuses, or catalog keys that multiple surfaces must share. A spine is the tenant Organization Model vocabulary that coordinates workflows, runtime state, API reads, and UI rendering without forcing those surfaces to import from each other.
-
-The lead-generation pattern is the reference shape: `organizationModel.prospecting.stages` defines the stage vocabulary, workflow templates reference those stages, workflow factories validate stage keys before running, entity state stores sparse per-stage progress, and UI views render progress from the same vocabulary.
-
-## What The Spine Owns
-
-A spine owns the shared vocabulary for one domain. The vocabulary is not just a list of strings. Each key should carry enough metadata for consumers to derive behavior consistently:
-
-- `key` identifies the stage or catalog member.
-- `label` gives a human-readable name.
-- `description` explains the business meaning.
-- `order` gives stable display and workflow ordering.
-- `entity` identifies which tenant entity the stage updates.
-
-The same keys then appear in four places:
-
-| Role | Tenant-facing shape |
-| --- | --- |
-| Vocabulary | `organizationModel.prospecting.stages` |
-| Process | workflow templates and build steps that reference stage keys |
-| Runtime state | entity state maps such as `{ [stageKey]: { status, updatedAt, data } }` |
-| Consumer projection | API filters, progress summaries, and UI step rendering |
-
-## Layering
-
-```text
-tenant Organization Model
-- prospecting stages
-- workflow templates
-- capability bindings
-        |
-        +--> workflow factory
-        |    - validates stage keys
-        |    - runs producers
-        |    - dispatches entity-tagged results
-        |
-        +--> API and query helpers
-        |    - filter pending entities by stage key
-        |    - aggregate progress from state maps
-        |
-        +--> UI projections
-             - render labels and order from the catalog
-             - distinguish known and unknown state keys
-
-entity runtime state
-{ [stageKey]: { status, updatedAt, data } }
-```
-
-The important boundary is that producers and consumers coordinate through the Organization Model vocabulary plus runtime state. They do not coordinate through direct imports, duplicated string constants, or workflow-specific side channels.
-
-## Invariants
-
-1. **The vocabulary is closed and validated.** Workflow factories should reject stage keys that are not present in the tenant Organization Model.
-
-2. **The vocabulary carries metadata.** Labels, descriptions, ordering, and entity ownership should come from the catalog rather than being copied into each consumer.
-
-3. **Runtime state is sparse and additive.** New stages appear in entity state when reached. Adding a catalog member should not require backfilling every entity.
-
-4. **Producers return entity-tagged results.** Workflow steps should return which entity changed, its identifier, status, and optional data. The factory owns writing those results to the correct state map.
-
-5. **Capability binding is separate from stage naming.** Workflow templates should point at capability keys, and the tenant environment can bind those capabilities to concrete workflow resources.
-
-## Applying The Pattern
-
-Use this checklist when adding or changing a tenant domain spine:
-
-1. Define the domain catalog in the tenant Organization Model.
-2. Include labels, descriptions, ordering, and entity ownership in each catalog entry.
-3. Make workflow templates reference catalog keys instead of free-form strings.
-4. Validate template stage keys when constructing workflow factories.
-5. Store progress in sparse entity state maps keyed by catalog member.
-6. Return entity-tagged workflow results and let the factory dispatch state updates.
-7. Read progress through query helpers that use the same catalog keys.
-8. Render UI labels, order, and status from the catalog plus state map.
-
-Promote a vocabulary to a spine when the same catalog coordinates all three surfaces: at least one process definition, at least one workflow producer, and at least one independent consumer such as an API query or UI view.
-
-## Counter-Patterns
-
-Avoid these patterns in spine-governed domains:
-
-- Free-form stage strings in workflow inputs.
-- Duplicated UI-only labels or ordering.
-- Per-workflow skip logic that bypasses the shared pending and progress contract.
-- State writes from individual steps instead of the workflow factory.
-- Hidden side channels for progress, such as ad hoc context keys.
-- Direct coupling between producer code and consumer UI code.
-
-When in doubt, update the Organization Model vocabulary first, then let workflow templates, factories, queries, and views project from it.
+
+# Spine Primer
+
+Use this primer when a tenant domain has a closed set of stages, statuses, or catalog keys that multiple surfaces must share. A spine is a tenant `System.ontology.catalogTypes` entry that coordinates workflows, runtime state, API reads, and UI rendering without forcing those surfaces to import from each other.
+
+The lead-generation pattern is the reference shape: a `System.ontology.catalogTypes` entry (kind `'stage'`, `appliesTo` the owning object type) defines the stage vocabulary, workflow templates reference those stage keys, workflow factories validate stage keys before running, entity state stores sparse per-stage progress, and UI views render progress from the same vocabulary.
+
+## What The Spine Owns
+
+A spine owns the shared vocabulary for one domain, authored as a catalog entry under a System's `ontology.catalogTypes`:
+
+<!-- doc-snippet:skip: illustrative excerpt, not a standalone compilable file -->
+
+```ts
+systems: {
+  sales: {
+    id: 'sales',
+    order: 20,
+    label: 'Sales',
+    lifecycle: 'active',
+    systems: {
+      'lead-gen': {
+        id: 'sales.lead-gen',
+        order: 10,
+        label: 'Lead Gen',
+        parentSystemId: 'sales',
+        lifecycle: 'active',
+        ontology: {
+          catalogTypes: {
+            'sales.lead-gen:catalog/company-stage': {
+              id: 'sales.lead-gen:catalog/company-stage',
+              label: 'Company Stages',
+              ownerSystemId: 'sales.lead-gen',
+              kind: 'stage',
+              appliesTo: 'sales.lead-gen:object/company',
+              entries: {
+                scraped: { label: 'Scraped', description: 'Company was scraped from a source directory.', order: 1 },
+                qualified: { label: 'Qualified', description: 'Company passed fit scoring.', order: 2 }
+              }
+            }
+          }
+        }
+      }
+    }
+  }
+}
+```
+
+The catalog record carries `id`, `label`, `ownerSystemId`, `kind` (a free-form label such as `'stage'`, `'pipeline'`, or `'template'`), and `appliesTo` (the ontology object-type ID this catalog governs). `entries` is a record keyed by stage/catalog member key; each entry is a JSON-serializable object. The vocabulary is not just a list of strings -- give each entry enough metadata for consumers to derive behavior consistently:
+
+- the entry key identifies the stage or catalog member (e.g. `scraped`, `qualified`).
+- `label` gives a human-readable name.
+- `description` explains the business meaning.
+- `order` gives stable display and workflow ordering.
+- Consumers that need to know which tenant entity a stage updates carry that as an additional entry field (e.g. `entity: 'company'`) -- the schema does not require a fixed shape beyond `label`/`description`/`order` by convention.
+
+The same keys then appear in four places:
+
+| Role                | Tenant-facing shape                                                     |
+| ------------------- | ----------------------------------------------------------------------- |
+| Vocabulary          | `System.ontology.catalogTypes['<system.path>:catalog/<name>'].entries`  |
+| Process             | workflow templates and build steps that reference catalog entry keys    |
+| Runtime state       | entity state maps such as `{ [entryKey]: { status, updatedAt, data } }` |
+| Consumer projection | API filters, progress summaries, and UI step rendering                  |
+
+## Layering
+
+```text
+tenant Organization Model
+- System.ontology.catalogTypes (stage/pipeline/template catalogs)
+- workflow templates
+- capability bindings
+        |
+        +--> workflow factory
+        |    - validates catalog entry keys
+        |    - runs producers
+        |    - dispatches entity-tagged results
+        |
+        +--> API and query helpers
+        |    - filter pending entities by catalog entry key
+        |    - aggregate progress from state maps
+        |
+        +--> UI projections
+             - render labels and order from the catalog
+             - distinguish known and unknown state keys
+
+entity runtime state
+{ [entryKey]: { status, updatedAt, data } }
+```
+
+The important boundary is that producers and consumers coordinate through the `System.ontology.catalogTypes` vocabulary plus runtime state. They do not coordinate through direct imports, duplicated string constants, or workflow-specific side channels.
+
+## Invariants
+
+1. **The vocabulary is closed and validated.** Workflow factories should reject catalog entry keys that are not present in the tenant catalog record.
+
+2. **The vocabulary carries metadata.** Labels, descriptions, and ordering should come from the catalog rather than being copied into each consumer.
+
+3. **Runtime state is sparse and additive.** New entries appear in entity state when reached. Adding a catalog member should not require backfilling every entity.
+
+4. **Producers return entity-tagged results.** Workflow steps should return which entity changed, its identifier, status, and optional data. The factory owns writing those results to the correct state map.
+
+5. **Capability binding is separate from stage naming.** Workflow templates should point at capability keys, and the tenant environment can bind those capabilities to concrete workflow resources.
+
+## Applying The Pattern
+
+Use this checklist when adding or changing a tenant domain spine:
+
+1. Define the domain catalog under the owning System's `ontology.catalogTypes` in the tenant Organization Model.
+2. Include labels, descriptions, and ordering in each catalog entry.
+3. Make workflow templates reference catalog entry keys instead of free-form strings.
+4. Validate template entry keys when constructing workflow factories.
+5. Store progress in sparse entity state maps keyed by catalog entry key.
+6. Return entity-tagged workflow results and let the factory dispatch state updates.
+7. Read progress through query helpers that use the same catalog keys.
+8. Render UI labels, order, and status from the catalog plus state map.
+
+Promote a vocabulary to a spine when the same catalog coordinates all three surfaces: at least one process definition, at least one workflow producer, and at least one independent consumer such as an API query or UI view.
+
+## Counter-Patterns
+
+Avoid these patterns in spine-governed domains:
+
+- Free-form stage strings in workflow inputs.
+- Duplicated UI-only labels or ordering.
+- Per-workflow skip logic that bypasses the shared pending and progress contract.
+- State writes from individual steps instead of the workflow factory.
+- Hidden side channels for progress, such as ad hoc context keys.
+- Direct coupling between producer code and consumer UI code.
+
+When in doubt, update the `System.ontology.catalogTypes` vocabulary first, then let workflow templates, factories, queries, and views project from it.

package/reference/ui/index.mdx

@@ -1,9 +1,9 @@
 ---
 title: "@elevasis/ui"
-description: The shared React 19 feature-shell and manifest-backed feature modules for Elevasis — Lead Gen, CRM, Projects, Operations, Monitoring, Settings, SEO, and more. Embeds into any host UI via ElevasisProvider.
+description: The shared React 19 feature-shell and manifest-backed feature modules for Elevasis — Lead Gen, CRM, Projects, Operations, Monitoring, Settings, SEO, and more. Embeds into any host UI via ElevasisCoreProvider and ElevasisSystemsProvider.
 ---
 
-`@elevasis/ui` is the shared React feature-shell for the Elevasis platform. It provides an `ElevasisProvider` and a set of manifest-backed feature modules that a host UI embeds and composes. The model is: your shell owns the layout and routing; Elevasis features plug in as self-contained modules.
+`@elevasis/ui` is the shared React feature-shell for the Elevasis platform. It provides `ElevasisCoreProvider` / `ElevasisSystemsProvider` and a set of manifest-backed feature modules that a host UI embeds and composes. The model is: your shell owns the layout and routing; Elevasis features plug in as self-contained modules.
 
 ## Install
 
@@ -27,20 +27,27 @@ Many peer dependencies are optional. Pull only the peers that the features you u
 
 ## Provider and Feature-Shell Model
 
-The entry point is `ElevasisProvider`, imported from `@elevasis/ui/provider`. Wrap your application root with it to give all child feature modules access to the platform context, auth session, and manifest registry.
+The entry point is a pair of providers, both imported from `@elevasis/ui/provider`. `ElevasisCoreProvider` owns auth, the API client, theming, and the shared TanStack Query client. `ElevasisSystemsProvider` owns the System registry — it takes your `SystemModule` list plus the organization model and resolves the shell, sidebar, and topbar actions from them. Wrap your application root with both, core on the outside.
 
 ```tsx
-import { ElevasisProvider } from "@elevasis/ui/provider";
+import { ElevasisCoreProvider, ElevasisSystemsProvider } from "@elevasis/ui/provider";
 
 export function AppRoot() {
   return (
-    <ElevasisProvider config={elevasisConfig}>
-      {/* your shell and routes */}
-    </ElevasisProvider>
+    <ElevasisCoreProvider
+      auth={{ mode: "authkit", clientId: WORKOS_CLIENT_ID }}
+      apiUrl={API_URL}
+    >
+      <ElevasisSystemsProvider systems={systems} organizationModel={organizationModel}>
+        {/* your shell and routes */}
+      </ElevasisSystemsProvider>
+    </ElevasisCoreProvider>
   );
 }
 ```
 
+`apiUrl` is what activates the full service stack; omit it and `ElevasisCoreProvider` runs in theme-only mode with no service context. Read the resolved registry from `useElevasisSystems()`, or `useOptionalElevasisSystems()` when a component must also render outside the provider tree.
+
 Feature modules are imported from their own subpaths (e.g. `@elevasis/ui/features/lead-gen`, `@elevasis/ui/features/crm`) and rendered inside the provider tree. Each module is manifest-backed: it reads the platform manifest at runtime to know which resources and workflows are available, so no hard-coded resource IDs are needed in the host UI.
 
 ## Available Feature Modules

package/dist/types/worker/adapters/anymailfinder.d.ts

@@ -1,14 +0,0 @@
-/**
- * Anymailfinder Integration Adapter
- *
- * Typed wrapper over platform.call() for Anymailfinder email discovery operations.
- * Uses factory pattern -- credential is bound once at construction time.
- */
-import type { AnymailfinderToolMap } from '../../types/index.js';
-/**
- * Create a typed Anymailfinder adapter bound to a specific credential.
- *
- * @param credential - Credential name as configured in the command center
- * @returns Object with 4 typed methods for Anymailfinder email discovery operations
- */
-export declare function createAnymailfinderAdapter(credential: string): import("./create-adapter.js").TypedAdapter<AnymailfinderToolMap>;

package/dist/types/worker/adapters/apify.d.ts

@@ -1,14 +0,0 @@
-/**
- * Apify Integration Adapter
- *
- * Typed wrapper over platform.call() for Apify actor operations.
- * Uses factory pattern -- credential is bound once at construction time.
- */
-import type { ApifyToolMap } from '../../types/index.js';
-/**
- * Create a typed Apify adapter bound to a specific credential.
- *
- * @param credential - Credential name as configured in the command center
- * @returns Object with 2 typed methods for Apify actor operations
- */
-export declare function createApifyAdapter(credential: string): import("./create-adapter.js").TypedAdapter<ApifyToolMap>;

package/dist/types/worker/adapters/approval.d.ts

@@ -1,23 +0,0 @@
-/**
- * Approval Platform Tool Adapter
- *
- * Typed wrapper over platform.call() for HITL (human-in-the-loop) tasks.
- * Singleton export -- no credential needed (platform tool).
- */
-import type { ApprovalToolMap } from '../../types/index.js';
-/**
- * Typed approval adapter for creating and managing HITL tasks.
- *
- * @example
- * ```ts
- * import { approval } from '@elevasis/sdk/worker'
- *
- * const task = await approval.create({
- *   actions: [{ id: 'approve', label: 'Approve', type: 'primary' }],
- *   context: { dealId: 'deal-123' },
- *   description: 'Review proposal for Acme Corp',
- *   humanCheckpoint: 'proposal-review',
- * })
- * ```
- */
-export declare const approval: import("./create-adapter.js").TypedAdapter<ApprovalToolMap>;