@elevasis/sdk 1.56.0 → 1.57.0

package/reference/scaffold/recipes/extend-crm.md

@@ -23,7 +23,7 @@ CRM is a layered platform surface, not one component:
 - **Organization OS:** System access, sales pipeline semantics, quick access, and labels live in the organization model.
 - **Shared UI:** CRM pages, sidebars, workbench panels, overview widgets, and Kanban/detail components live in `@elevasis/ui`.
 - **Headless hooks:** deal, company, contact, note, task, list, transition, and action hooks live under `@elevasis/ui/hooks`.
-- **Action system:** `ActionDef`, `deriveActions`, and the caller-supplied provider-level `crmActions` catalog configure deal actions. The published `@elevasis/sdk` surface ships no default Elevasis action catalog -- projects supply their own `ActionDef[]`.
+- **Action system:** deal action buttons are authored as `actionTypes` records under the `sales.crm` System's ontology scope, compiled with `compileCrmActionCatalog` and handed to the provider as `crmActions`. The published `@elevasis/sdk` surface ships no default Elevasis action catalog -- every project's buttons come from its own organization model.
 - **Workflow adapters:** `crm` and `acqDb` from `@elevasis/sdk/worker` let workflows read and mutate CRM/acquisition data through platform tools.
 - **System API Interface:** `sales.crm` uses the flat `system.apiInterface` marker for its API-backed CRM boundary. Readiness is derived from scoped resources, ontology bindings, required catalogs, and scoped topology grants. Cross-system lead-gen handoff belongs in scoped topology, not a top-level Bridge Contract or a hand-authored handoff interface field. Generated contract docs expose the current CRM shapes in `operations/node_modules/@elevasis/sdk/reference/scaffold/reference/contracts.md`.
 
@@ -51,7 +51,7 @@ CRM is a layered platform surface, not one component:
 | `useDeals`, `useDealDetail`, `useTransitionItem`, `useExecuteAction`, `useDealNotes`, `useDealTasks` | `@elevasis/ui/hooks`        | Headless deal and task data access                   |
 | `useCompanies`, `useContacts`, `useLists`, `useBatchTelemetry`                                       | `@elevasis/ui/hooks`        | Acquisition substrate data access                    |
 | `ElevasisUIProvider`, `ElevasisCoreProvider`, `useElevasisServices`                                  | `@elevasis/ui/provider`     | Provider setup, API access, and organization context |
-| `ActionDef`, `deriveActions`                                                                         | `@elevasis/sdk`             | Deal action configuration and render-time derivation |
+| `compileCrmActionCatalog`, `deriveCompiledCrmActions`, `CompiledCrmAction`                           | `@elevasis/sdk`             | Deal action compilation and render-time derivation   |
 | `crm`, `acqDb`                                                                                       | `@elevasis/sdk/worker`      | Workflow-side CRM/acquisition platform adapters      |
 
 Read the generated contracts before changing typed boundaries:
@@ -241,6 +241,8 @@ For stage labels or stage sets, update the project model:
 Keep these boundaries straight:
 
 - Org-model sales pipelines describe business semantics.
+- Give every `sales.crm:catalog/crm.pipeline` entry a `semanticClass`. The platform treats entries marked `closed_won` / `closed_lost` as closed: they drive deal ownership, next-action suppression, the closed priority bucket, and won/lost counts in the deals summary. A catalog with no closed `semanticClass` has no closed stages; there is no fallback to stage keys named `closed_won` / `closed_lost`.
+- Deal priority and next-action defaults are authored on the `sales.crm` System as `config.rules`: `priority` (`enabled`, `staleAfterDays`, `bucketOrder`, `buckets`, `followUpAfterDaysByStateKey`) and `nextActions` (`mappings`, `ownershipUsFallback`), plus `staleAfterDaysByStageKey`, the days without an update before an open deal in that stage is reported stale by the deals summary (keys must be pipeline stage keys; an unlisted stage is never reported stale). Omitted fields use the platform's generic defaults, and organization overrides saved in CRM settings layer on top. Do not author `closedStageKeys` there; the pipeline catalog owns closed stages, and an invalid `config.rules` makes the CRM API report not-ready.
 - `DealStage` and platform action defaults describe the current shared platform deal state vocabulary.
 - UI wrappers can relabel and route around shared surfaces, but changing persisted platform stages requires coordinated core/API/UI updates.
 - Do not add `sales.actions` to the org model in v1. Deal action customization is covered by [customize-crm-actions.md](customize-crm-actions.md).

package/reference/scaffold/recipes/extend-lead-gen.md

@@ -525,9 +525,9 @@ The helper throws at declaration time on the failure modes the literal lets thro
 
 `readinessContract.requiredObjects` and `requiredCatalogs` are arrays of ontology IDs owned by this system. The platform validates that each declared object type exists in the OM and that each declared catalog type has at least one entry. `requiredCatalogs` must declare at least one entry — an empty contract asserts nothing and is rejected.
 
-Built-in profile ids (`sales.lead-gen.api`, etc.) derive their requirements from platform code. **A `readinessContract` declared alongside a built-in profile is ignored outright — not merely unnecessary.** The readiness engine branches on the profile: a registered built-in runs its own validator, and the authored contract is read only on the `else` branch, so anything you declare next to a built-in profile validates nothing and silently drifts from what the platform actually enforces. Real projects have shipped full contracts this way believing they were enforced.
+Built-in profile ids (`sales.lead-gen.api`, etc.) derive their requirements from platform code, evaluated by the API at request time and never copied into your deployed model. **A `readinessContract` declared alongside a built-in profile is an error.** The readiness check never reads it, so it would validate nothing and drift from what the platform enforces. `defineSystemApiInterface` throws on it, and deploy preflight and `om:doctor` report a hand-written one as `readiness-contract-on-built-in-profile`. Delete it. To see what the platform checks for, read `requiredObjects` / `requiredCatalogs` from `defineLeadGenSystem` or `defineCrmSystem`.
 
-Note that the determinant is the **profile**, not the system. A custom system using a built-in profile still gets the built-in's requirements and still ignores an authored contract; a custom profile id is what makes `readinessContract` required (and it is required — a custom profile without one fails readiness with `missing-readiness-contract`).
+Note that the determinant is the **profile**, not the system. A custom system using a built-in profile still gets the built-in's requirements and still may not declare a contract; a custom profile id is what makes `readinessContract` required (and it is required — a custom profile without one fails readiness with `missing-readiness-contract`).
 
 The `lookupReadinessProfile`, `registerReadinessProfile`, and `isBuiltInReadinessProfile` functions are exported from `@elevasis/sdk` alongside the `SystemApiInterfaceReadinessContract`, `ReadinessProfileKind`, and `ReadinessProfileEntry` types. `registerReadinessProfile(profileId)` only acknowledges a custom id for introspection (`lookupReadinessProfile` then resolves it as `kind: 'custom'` instead of `undefined`) — it cannot make `isBuiltInReadinessProfile` return `true` and it is never a substitute for a `readinessContract`. The actual extension point for platform-code-driven readiness (no `readinessContract` needed) is `registerBuiltInReadinessProfile`, exported from `@elevasis/core/organization-model/readiness` — it takes real structural validation logic, not just an id.
 

package/reference/scaffold/recipes/index.md

@@ -35,7 +35,7 @@ You want to build on the shared lead-gen system without forking it: add lead-gen
 You want to build on the shared content system without forking it: add a pipeline, produce a step from a workflow, customize the review screen, store rules documents, or track distributions. Covers the catalog-driven pipeline model (a pipeline is data, not code), the `content:catalog/{pipeline}-steps` binding, attempt authoring with `stepKey`, artifacts as versioned governing documents with their two silent write constraints, review-page slots and primitives, and the `apiInterface` readiness rules.
 
 **[Customize CRM Actions](customize-crm-actions.md)**
-You want to add, hide, or replace CRM deal action buttons, configure the shared `crmActions` provider path, or call a project-owned workflow from custom UI when server-side action dispatch constraints require it. Covers `ActionDef`, the caller-supplied `crmActions` catalog, provider wiring, and the current v1 boundary for custom action dispatch.
+You want to add, hide, reorder, or re-implement CRM deal action buttons, configure the shared `crmActions` provider path, or call a project-owned workflow from custom UI. Covers authoring actions as `sales.crm` ontology `actionTypes` records, the `availableFrom` conditions that decide when a button appears, `compileCrmActionCatalog` and provider wiring, server-side dispatch, and why payload schemas are platform-registered rather than authored in the model.
 
 **[Customize Knowledge Browser](customize-knowledge-browser.md)**
 You want to mount, extend, or replace the default Knowledge Browser. Covers the three customization tiers (default manifest mount, sidebar composition via `KnowledgeSidebarMiddle` + `KNOWLEDGE_ITEMS`, and direct query access via `@elevasis/core/knowledge`), the one-line `vite.config.ts` plugin add (`knowledgePlugin()` from `@elevasis/ui/vite-plugin-knowledge`), and the CSS import requirement.
@@ -48,6 +48,6 @@ You want to browse, inspect, or traverse the OrganizationModel knowledge graph f
 ## Reference docs these recipes link into
 
 - [glossary.md](../reference/glossary.md) -- term disambiguation for System, Resource, systemId, Topology, Settings asymmetry
-- [contracts.md](../reference/contracts.md) -- TypeScript shapes: `SystemModule`, `OrganizationModel`, CRM deal types, lead-gen list/member/artifact types, content item/attempt/distribution types, `CrmToolMap`, `LeadToolMap`, `ListToolMap`, `ContentToolMap`, `ActionDef`
+- [contracts.md](../reference/contracts.md) -- TypeScript shapes: `SystemModule`, `OrganizationModel`, CRM deal types, lead-gen list/member/artifact types, content item/attempt/distribution types, `CrmToolMap`, `LeadToolMap`, `ListToolMap`, `ContentToolMap`, `CompiledCrmAction`
 - [feature-flags-and-gating.md](../ui/feature-flags-and-gating.md) -- full three-concept gating model
 - [workflow-recipes.md](../operations/workflow-recipes.md) -- workflow anatomy, adapters, trigger patterns

package/reference/scaffold/reference/contracts.md

@@ -2089,22 +2089,50 @@ export const DealSchemas = {
 ### `Action`
 
 ```typescript
-export interface Action {
-  key: string
-  label: string
-  payloadSchema?: z.ZodTypeAny
+export interface Action {
+  key: string
+  label: string
+  payloadSchema?: z.ZodTypeAny
 }
 ```
 
-### `ActionDef`
+### `DealActionInput`
 
 ```typescript
-export interface ActionDef {
-  key: string
-  label: string
-  isAvailableFor: (deal: AcqDealRow) => boolean
-  workflowId: string
-  payloadSchema?: z.ZodTypeAny
+export type DealActionInput = AcqDealRow & {
+  ownership?: 'us' | 'them' | null
+  nextAction?: string | null
+}
+```
+
+### `CompiledCrmActionAvailability`
+
+```typescript
+/**
+ * When a deal action is selectable, authored by the tenant rather than hardcoded
+ * as a TypeScript predicate. `stageKeys` / `stateKeys` / `nextActionKeys` AND
+ * together; membership within one dimension is OR; an omitted dimension is
+ * unconstrained. Mirrors
+ * `OntologyActionAvailabilityCondition` (`organization-model/ontology.ts`)
+ * verbatim -- this is that schema's compiled/validated shape.
+ */
+export interface CompiledCrmActionAvailability {
+  stageKeys: string[]
+  stateKeys?: string[]
+  nextActionKeys?: string[]
+}
+```
+
+### `CompiledCrmAction`
+
+```typescript
+/** One CRM deal action, compiled from the OM's `sales.crm` ontology `actionTypes`. */
+export interface CompiledCrmAction {
+  key: string
+  label: string
+  availableFrom: CompiledCrmActionAvailability
+  resourceId: string
+  payloadSchema?: z.ZodTypeAny
 }
 ```
 
@@ -3177,7 +3205,7 @@ export type TransitionItem<T extends Stateful, TEvent extends ActivityEvent> = (
 ### `DeriveActions`
 
 ```typescript
-/** Generic action-derivation shape — concrete per-entity deriveActions implementations satisfy this. */
+/** Generic action-derivation shape — concrete per-entity action derivations satisfy this. */
 export type DeriveActions<T extends Stateful, TAction> = (item: T) => TAction[]
 ```
 

package/reference/scaffold/reference/system-interface-capabilities.md

@@ -12,7 +12,7 @@ System Interface profiles are a closed platform adoption handshake. This table i
 
 The catalog is closed because a `readinessProfile` names a capability the platform API gates a route on -- only the platform can mint one. `SystemInterfaceReadinessProfileSchema` accepts any non-empty string, but that is a property of the schema layer, not permission: an uncataloged id names no route, so the declaring System computes as **ready** and every call still fails, which is worse than the `missing-interface` a plain omission reports. Needing an uncataloged capability is a platform request (a route plus a catalog entry), not something to route around by inventing an id.
 
-Two validation modes appear below. A **built-in** profile has a validator registered in platform code, so the adopting System needs no `readinessContract`. A **contract-validated** profile is platform-served but its structural requirements differ per adopter, so the adopting System MUST declare a `readinessContract`. `registerBuiltInReadinessProfile` is platform-code-only and is not reachable from a project: it mutates an in-process registry, while the readiness assertion that gates the API runs in the API process.
+Two validation modes appear below. A **built-in** profile has a validator registered in platform code, so the platform owns its requirements and the adopting System must not declare a `readinessContract`. A **contract-validated** profile is platform-served but its structural requirements differ per adopter, so the adopting System MUST declare a `readinessContract`. `registerBuiltInReadinessProfile` is platform-code-only and is not reachable from a project: it mutates an in-process registry, while the readiness assertion that gates the API runs in the API process.
 
 | Profile | Required System path | Interface key | Validation | `readinessContract` |
 | --- | --- | --- | --- | --- |
@@ -25,7 +25,7 @@ Two validation modes appear below. A **built-in** profile has a validator regist
 
 - Required System path: `sales.lead-gen`
 - Interface key: `api`
-- Validation: **built-in** -- a platform-registered validator covers this profile; no `readinessContract` is required.
+- Validation: **built-in** -- a platform-registered validator covers this profile; do not declare a `readinessContract` (deploy preflight rejects one as `readiness-contract-on-built-in-profile`).
 - Derived-readiness requirements:
   - System Interface marker must be active and scope at least one active `sales.lead-gen` Resource.
   - Object types: `sales.lead-gen:object/list`, `sales.lead-gen:object/company`, `sales.lead-gen:object/contact`.
@@ -39,7 +39,7 @@ Two validation modes appear below. A **built-in** profile has a validator regist
 
 - Required System path: `sales.crm`
 - Interface key: `api`
-- Validation: **built-in** -- a platform-registered validator covers this profile; no `readinessContract` is required.
+- Validation: **built-in** -- a platform-registered validator covers this profile; do not declare a `readinessContract` (deploy preflight rejects one as `readiness-contract-on-built-in-profile`).
 - Derived-readiness requirements:
   - System Interface marker must be active and scope at least one active `sales.crm` Resource.
   - Catalog types with entries: `sales.crm:catalog/crm.pipeline`.
@@ -49,7 +49,7 @@ Two validation modes appear below. A **built-in** profile has a validator regist
 
 - Required System path: `sales.lead-gen`
 - Interface key: `crm-handoff`
-- Validation: **built-in** -- a platform-registered validator covers this profile; no `readinessContract` is required.
+- Validation: **built-in** -- a platform-registered validator covers this profile; do not declare a `readinessContract` (deploy preflight rejects one as `readiness-contract-on-built-in-profile`).
 - Derived-readiness requirements:
   - Derived handoff readiness is evaluated for `sales.lead-gen/crm-handoff`; it is not authored as a separate custom tenant API surface.
   - Lead-gen API readiness requirements must pass for `sales.lead-gen/api`.

package/reference/sdk/cli-management.mdx

@@ -1215,7 +1215,3 @@ A domain should meet all four criteria before gaining a `*:list` / `*:get` surfa
 2. External SDK tenants have a plausible read or operation need.
 3. Operators repeat the same query pattern often enough that ad-hoc DB reads are becoming workflow surface.
 4. There are at least three concrete use cases.
-
----
-
-**Last Updated:** 2026-08-17

package/reference/sdk/cli.mdx

@@ -768,7 +768,3 @@ These flags are accepted by all commands:
 - Development (`NODE_ENV=development`): `http://localhost:<port>`
 - Override: set `ELEVASIS_API_URL` or pass `--api-url`
 - Force production: pass `--prod` after the command name on any authenticated command (overrides `NODE_ENV=development`). Live as of `@elevasis/sdk` 1.45.0; `--api-url https://api.elevasis.io` is the equivalent form on older installs.
-
----
-
-**Last Updated:** 2026-08-17

package/reference/sdk/concepts.mdx

@@ -130,7 +130,3 @@ Use `StepType.CONDITIONAL` when different inputs should follow different process
 Example: score >= 80 goes to the approve path, score >= 50 goes to the review path, everything else goes to the reject path. Each path can have its own steps and logic.
 
 Always include a `default` fallback step for inputs that do not match any condition. Without a fallback, an unmatched execution will fail.
-
----
-
-**Last Updated:** 2026-02-26

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

@@ -206,7 +206,3 @@ The Deployments page shows the history of all deployments for your organization.
 **How it connects to your code:** Each `elevasis-sdk deploy` run creates a new deployment entry. The platform activates the new version atomically -- in-flight executions complete against the previous version while new executions start against the new one.
 
 > **SDK takeaway:** Check this page after `elevasis-sdk deploy` to confirm your resources are active.
-
----
-
-**Last Updated:** 2026-03-06

package/reference/sdk/framework/agent.mdx

@@ -87,7 +87,3 @@ External projects run an always-on natural-language intent classifier -- there i
 ## Template Version Tracking
 
 The scaffold's version marker is `templateVersion` in the project-root `.elevasis` file (a flat YAML-like marker file, not `elevasis.config.ts`). `elevasis.config.ts` (`operations/elevasis.config.ts`) only accepts `defaultStatus` and `dev.port` -- it has no version field. To pull a template update, run `/git-sync`, not `/meta fix` (which does not exist in this template).
-
----
-
-**Last Updated:** 2026-08-17

package/reference/sdk/framework/index.mdx

@@ -86,7 +86,3 @@ See [Tutorial System](tutorial-system.mdx) for the full lesson breakdown, track
 - [Project Structure](project-structure.mdx) - Directory-by-directory walkthrough of the scaffolded project's structure and layout
 - [Agent System](agent.mdx) - Skill inventory, rules layer, ambient vibe classifier, and session bootstrap
 - [Tutorial System](tutorial-system.mdx) - Two-track onboarding (8 vibe-coder + 19 technical lessons), track persistence, and progress tracking
-
----
-
-**Last Updated:** 2026-08-06

package/reference/sdk/framework/project-structure.mdx

@@ -230,7 +230,3 @@ Excludes `node_modules/`, `dist/`, `*.tsbuildinfo`, `.tanstack/`, `.env` and `.e
 | `.env`                                                                      | Adding environment variables                                           |
 | `CLAUDE.md`                                                                 | Rarely -- project identity and preferences, mostly written by `/setup` |
 | `.claude/skills/*/SKILL.md`                                                 | Never in a derived project -- these arrive via `/git-sync`             |
-
----
-
-**Last Updated:** 2026-08-17

package/reference/sdk/getting-started.mdx

@@ -108,7 +108,3 @@ Replace `<execution-id>` with the ID returned from the executions list.
 - [Deployment](deployment/index.mdx) -- Deployment lifecycle and environment variables
 
 When a new SDK version is released, the dependency baseline arrives with the upstream changes rather than through a manual package bump. Run `/git-sync` in Claude Code to pull the latest, install when the baseline moved, and run baseline verification. If packages feel stale or a cache is serving old code afterwards, `/sync` does a fresh reinstall and cache reset.
-
----
-
-**Last Updated:** 2026-08-17

package/reference/sdk/index.mdx

@@ -7,7 +7,7 @@ description: Build and deploy workflows, agents, and resources with the Elevasis
 
 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 25 adapters (13 integration + 12 platform) 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.
+The SDK ships with a full CLI (`elevasis-sdk`) for validation, deployment, execution, inspection, and project-management operations. Platform tools expose 28 adapters (14 integration + 14 platform) 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
 
@@ -28,7 +28,7 @@ After `pnpm dlx @elevasis/sdk init`, your project is scaffolded with a working e
 
 ## Platform Tools
 
-The platform exposes 25 adapters (13 integration + 12 platform) across integration adapters and platform services -- Gmail, Stripe, Google Sheets, Attio, and more. Import typed adapters from `@elevasis/sdk/worker` inside any workflow step or agent. Credentials are managed server-side; API keys never cross the execution boundary.
+The platform exposes 28 adapters (14 integration + 14 platform) across integration adapters and platform services -- Gmail, Stripe, Google Sheets, Attio, and more. Import typed adapters from `@elevasis/sdk/worker` inside any workflow step or agent. Credentials are managed server-side; API keys never cross the execution boundary.
 
 See [Platform Tools](platform-tools/index.mdx) for the full catalog, adapter reference, and credential setup.
 
@@ -46,7 +46,7 @@ See [Platform Tools](platform-tools/index.mdx) for the full catalog, adapter ref
 ### Core Concepts
 
 - [Resources](resources/index.mdx) - Workflow and agent definition patterns, Zod schemas, step types, and routing
-- [Platform Tools](platform-tools/index.mdx) - Full catalog of 25 adapters (13 integration + 12 platform), integration adapters, and credential management
+- [Platform Tools](platform-tools/index.mdx) - Full catalog of 28 adapters (14 integration + 14 platform), integration adapters, and credential management
 - [Credential Security](platform-tools/index.mdx#credential-security) - Three-layer credential model, HTTP tool patterns, and credential management
 - [Human-in-the-Loop Workflows](human-in-the-loop.mdx) - The full HITL story: approval adapter, checkpoint metadata, and queue resolution
 - [The Deployment Spec Pattern](project-deployment-spec.mdx) - projectDeploymentSpec and defineWorkflowConfig, the shape the template actually ships
@@ -64,7 +64,7 @@ See [Platform Tools](platform-tools/index.mdx) for the full catalog, adapter ref
 ### Typed Adapters
 
 - [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 12 platform service adapters: scheduler, storage, llm, pdf, approval, and more
+- [Platform Adapters](platform-tools/adapters-platform.mdx) - All 14 platform service adapters: scheduler, storage, llm, pdf, approval, and more
 
 ### Framework
 
@@ -87,7 +87,3 @@ See [Platform Tools](platform-tools/index.mdx) for the full catalog, adapter ref
 
 - [Export Catalog](exports.mdx) - Auto-generated catalog of all published @elevasis/sdk subpath exports
 - [Troubleshooting](troubleshooting.mdx) - Static error catalog for CLI, deployment, schema, and runtime failures
-
----
-
-**Last Updated:** 2026-05-19

package/reference/sdk/platform-tools/index.mdx

@@ -198,7 +198,3 @@ const qualified = await platform.call({
 - [Integration Adapters](adapters-integration.mdx) - All 14 integration adapters with method tables and code examples
 - [Platform Adapters](adapters-platform.mdx) - All 14 platform service adapters with method tables and code examples
 - [Adapter Type Safety](type-safety.mdx) - Required fields, discriminated unions, and intentionally loose adapter types
-
----
-
-**Last Updated:** 2026-03-06

package/reference/sdk/resources/index.mdx

@@ -393,7 +393,3 @@ export default config;
 
 - [SDK Types](types.mdx) - Complete type reference for `@elevasis/sdk` exports, config, and step handler context
 - [Common Patterns](patterns.mdx) - Sequential steps, conditional branching, error handling, and resource status patterns
-
----
-
-**Last Updated:** 2026-02-25

package/reference/sdk/resources/patterns.mdx

@@ -495,7 +495,3 @@ The Command Queue page in the Command Center surfaces all pending approval tasks
 Use these hooks to build a custom approval queue surface in your template UI. `useSubmitAction` accepts `taskId`, `actionId`, and optional `notes`, and optimistically marks the task as `processing` while the request is in flight.
 
 For triggering executions from custom pages (the other side of the workflow interaction), see [UI Execution](../deployment/execution-reference.mdx#ui-execution).
-
----
-
-**Last Updated:** 2026-02-25

package/reference/sdk/runtime.mdx

@@ -165,7 +165,3 @@ Hard limits to prevent abuse and ensure platform stability:
 ## Organization Provisioning
 
 Organization creation is currently admin-only. If you need a new organization provisioned for SDK access, contact the Elevasis team. Self-serve organization creation and API key generation is on the roadmap.
-
----
-
-**Last Updated:** 2026-03-06

package/reference/sdk/templates/data-enrichment.mdx

@@ -160,7 +160,3 @@ export const dataEnrichment: WorkflowDefinition = {
 - **Prompt template:** The `{value}` placeholder is replaced with the source field's value at runtime. Adapt the prompt for the user's specific enrichment task.
 - **Batch size:** Default limit is 20 rows. Increase for bulk processing, decrease for expensive LLM calls.
 - **Skill adaptation:** For beginners, explain what "enrichment" means and give concrete examples (adding a summary field, scoring, categorizing) before generating code.
-
----
-
-**Last Updated:** 2026-02-26

package/reference/sdk/templates/email-sender.mdx

@@ -133,7 +133,3 @@ export const emailSender: WorkflowDefinition = {
 - **HTML vs text:** For beginners, suggest writing plain text first and adding HTML later. For developers, show both.
 - **Error handling:** The template returns `{ sent: false, error }` on failure rather than throwing, suitable for non-critical emails. For critical notifications, change to `throw err` so the execution fails visibly.
 - **Multi-step context:** This template is a single step, but it can be used as the last step of a multi-step workflow (e.g., "process data then send summary email").
-
----
-
-**Last Updated:** 2026-02-26

package/reference/sdk/templates/index.mdx

@@ -41,7 +41,3 @@ All templates are available for any organization. Credentials specific to each t
 | PDF Generator   | `pdf`, `storage`    | None (platform services)        |
 | Text Classifier | `llm`               | None (LLM server-side)          |
 | Recurring Job   | `scheduler`         | None (platform service)         |
-
----
-
-**Last Updated:** 2026-03-19

package/reference/sdk/templates/lead-scorer.mdx

@@ -173,7 +173,3 @@ export const leadScorer: WorkflowDefinition = {
 - **Scoring criteria:** Customize `DEFAULT_CRITERIA` based on the user's ICP (ideal customer profile). Ask the user what matters most for their scoring.
 - **Table columns:** The template writes `score`, `tier`, `scoring_reasoning`, `scored_at`. Ensure these columns exist or adapt the field names.
 - **LLM model:** Default uses `gpt-5.4-mini`. For more nuanced scoring, suggest `gpt-5`.
-
----
-
-**Last Updated:** 2026-02-26

package/reference/sdk/templates/pdf-generator.mdx

@@ -167,7 +167,3 @@ export const pdfGenerator: WorkflowDefinition = {
 - **Expiry:** Default is 1 hour. For document delivery workflows, increase to 24-72 hours.
 - **Data structure:** Ask the user what fields their document needs before defining the input schema and mapping it into `sections`. For typed use cases (invoices, reports), add more input fields and a matching table row or card per field group.
 - **Skill adaptation:** For beginners, walk through the difference between a JSON document tree and an HTML template before generating code.
-
----
-
-**Last Updated:** 2026-02-26

package/reference/sdk/templates/recurring-job.mdx

@@ -194,7 +194,3 @@ export const recurringJob: WorkflowDefinition = {
 - **Timezone:** Always ask the user their preferred timezone. Defaults to UTC which may cause unexpected run times.
 - **`organizationId` in `createSchedule` params:** The platform always re-scopes this from the execution context server-side, so the value passed here is ignored -- it exists only because the field is required by the scheduler's type.
 - **Execution input on each run:** The job workflow receives `scheduleConfig.payload` as its input, with a `_scheduleMetadata` object (`scheduleId`, `scheduleName`, `scheduleStep`) merged in automatically. Extra fields are not part of the validated `inputSchema` and are silently dropped by Zod's default parsing.
-
----
-
-**Last Updated:** 2026-02-26

package/reference/sdk/templates/text-classifier.mdx

@@ -145,7 +145,3 @@ Return JSON with:
 - **Confidence routing:** Common pattern: use the output with `StepType.CONDITIONAL` routing. High confidence routes to automated processing; low confidence routes to human review.
 - **Model selection:** `gpt-5.4-mini` is fast and cost-effective for classification. For complex or nuanced categorization, suggest `gpt-5`.
 - **Skill adaptation:** For beginners, explain what "structured output" means and why the LLM returns JSON instead of free text.
-
----
-
-**Last Updated:** 2026-02-26

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

@@ -137,7 +137,3 @@ export const webScraper: WorkflowDefinition = {
 - **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/sdk/troubleshooting.mdx

@@ -287,7 +287,3 @@ When recording a new error in `.claude/memory/errors/`, use this table format:
 ```
 
 Status values: `Resolved` (fixed this session), `Recurring` (seen 2+ times), `Promoted` (3+ times, now in Rules).
-
----
-
-**Last Updated:** 2026-08-20