@elevasis/sdk 1.29.0 → 1.30.1

package/reference/rules/ui.md

@@ -1,210 +1,210 @@
----
-description: UI shell, route structure, auth flow, API access, and template customization points for the ui/ surface
-paths:
-  - ui/**
----
+---
+description: UI shell, route structure, auth flow, API access, and template customization points for the ui/ surface
+paths:
+  - ui/**
+---
 <!-- @generated by packages/sdk/scripts/copy-reference-docs.mjs -- DO NOT EDIT -->
 <!-- Regenerate: pnpm scaffold:sync -->
 
-
-# UI Features
-
-**Status:** Stable
-
-## App Shell Overview
-
-The template frontend is a React 19 + TanStack Router app that composes a local dashboard shell with published System modules from `@elevasis/ui`.
-
-The main join points are:
-
-- `ui/src/main.tsx` -- boots the app with `ElevasisUIProvider`, query client, theme config, WorkOS AuthKit, notifications, and the generated route tree
-- `ui/src/routes/__root.tsx` -- composes the authenticated shell with `ElevasisSystemsProvider`, published System modules, app-local dashboard nav, shell runtime dependencies, and `SystemShell`
-- `ui/src/config/nav-items.ts` -- keeps the host-local dashboard entry separate from the published feature manifests
-- `core/config/organization-model.ts` -- is the template's semantic source of truth, adapting `@elevasis/core/organization-model` into the preserved branding, dashboard label, quick-access, System labels, resource descriptors, and shell helpers
-
-Published System modules mounted by the template shell:
-
-- `lead-gen`
-- `crm`
-- `delivery` at `/projects`
-- `operations`
-- `monitoring`
-- `settings`
-
-Important distinction:
-
-- shared modules gate on current org-model System keys such as `sales.lead-gen` and `projects`
-- template routes and local nav may still use legacy aliases such as `crm`, `lead-gen`, and `projects`
-- `core/config/organization-model.ts` and `ui/src/lib/hooks/useFeatureAccess.ts` are the bridge between those two vocabularies
-
-Dashboard remains a host-local route at `/`, not a shared feature manifest.
-
-This template should be treated as the downstream reference implementation for this composition:
-
-- `core/config/organization-model.ts` owns the organization/runtime semantics
-- `ui/src/config/nav-items.ts` preserves the host-local dashboard entry instead of pushing that concern into shared manifests
-- `ui/src/routes/__root.tsx` threads `canonicalOrganizationModel` from `@core/config/organization-model` into `ElevasisSystemsProvider` so the shared shell/runtime uses the same semantic source of truth as the local template helpers
-- host-local customizations still stay local: dashboard remains app-owned nav, branding stays in app config, and quick-access/dashboard UX stays in the template app
-
-## Auth and Initialization
-
-The app uses WorkOS AuthKit through `ElevasisUIProvider`. Authentication is enforced by the local `ProtectedRoute` wrapper in `ui/src/features/auth/ProtectedRoute.tsx`.
-
-**Sign-in flow:**
-
-1. Unauthenticated user hits a protected route -- `ProtectedRoute` redirects to `/login?returnTo=<path>`
-2. `/login` renders a sign-in card; user clicks Sign In, triggering `signIn({ returnTo })` from `useAuth()`
-3. User authenticates on the WorkOS-hosted sign-in page
-4. WorkOS redirects back to `/auth-redirect` -- `ui/src/routes/auth-redirect.tsx` waits for auth to complete, then navigates to the requested path or `/`
-5. User lands on the home page, fully authenticated
-
-**Route protection:**
-
-Wrap protected route components with the local `ProtectedRoute` from `@/features/auth`, which adds the full-screen loader and delegates to the shared guard from `@elevasis/ui/auth`:
-
-```tsx
-import { ProtectedRoute } from '@/features/auth'
-
-function HomePageGuarded() {
-  return (
-    <ProtectedRoute>
-      <HomePage />
-    </ProtectedRoute>
-  )
-}
-```
-
-**Initialization state:**
-
-Use `useInitialization()` from `@elevasis/ui/initialization` anywhere inside the app to read aggregated auth + org readiness:
-
-```ts
-const { allReady, userReady, isInitializing, error, retry, profile } = useInitialization()
-```
-
-**Organization context:**
-
-Use `useOrganization()` from `@elevasis/ui/organization` to access org-scoped IDs and memberships:
-
-```ts
-const { currentWorkOSOrganizationId, currentSupabaseOrganizationId, memberships, switchOrganization } = useOrganization()
-```
-
-## API and Streaming
-
-Use `useApiClient()` from `@/lib/hooks/useApiClient` in route components and feature hooks:
-
-```ts
-const { apiRequest, isOrganizationReady } = useApiClient()
-const data = await apiRequest('/executions', { method: 'GET' })
-```
-
-The template also re-exports `useApiClientContext()` and the shared API client types from `@/lib/hooks/useApiClient`.
-
-For real-time updates, feature surfaces use the local singleton wrapper:
-
-```ts
-import { sseConnectionManager } from '@/lib/sse/SSEConnectionManager'
-```
-
-**WorkOS config:**
-
-WorkOS `clientId`, `redirectUri`, and `signoutUri` are resolved in `ui/src/config/workos.ts` from `VITE_WORKOS_CLIENT_ID`, `VITE_WORKOS_REDIRECT_URI`, `VITE_WORKOS_SIGNOUT_URI`, and `VITE_APP_ORIGIN`, with localhost fallbacks so the template runs locally without production env vars. For deployed apps, set the production env vars in the hosting provider and allow the exact redirect and sign-out URLs in the WorkOS application dashboard:
-
-- Redirect URI: `https://your-production-domain/auth-redirect`
-- Sign-out redirect: `https://your-production-domain/login`
-- Configure CORS origin: `https://your-production-domain`; required for browser AuthKit calls to `api.workos.com`
-- App homepage origin: `https://your-production-domain`
-
-The dev server runs on port `4300` with Vite `strictPort: true`, so a second `pnpm -C ui dev` on the same machine fails fast instead of drifting.
-
-The API URL is centralized in `ui/src/lib/constants/api.ts`. In the current template it is hard-coded to `https://api.elevasis.io`, so if the bootstrap is repointed to another API target, that file is the source of truth.
-
-## Route Structure
-
-Current top-level app sections:
-
-- `/` -- host-local dashboard entrypoint with quick links derived from `organizationModel.navigation.quickAccessSurfaceIds`
-- `/lead-gen/*` -- lead generation pages (`lists`, `companies`, `contacts`)
-- `/crm/*` -- CRM overview, pipeline, and deals
-- `/projects/*` -- delivery feature pages (projects, milestones, tasks, notes)
-- `/operations/*` -- operations overview, resources, command queue, command view, sessions, task scheduler
-- `/monitoring/*` -- execution logs, execution health, activity log, cost analytics, notifications
-- `/settings/*` -- account, organization, credentials, API keys, deployments, webhooks, and appearance
-- `/login` and `/auth-redirect` -- auth entry/callback routes
-
-Section guards currently follow this pattern:
-
-- `ProtectedRoute` for all authenticated sections
-- `SystemGuard` on sections that should hard-stop when a System is disabled: `crm`, `lead-gen`, `projects`, `operations`, and `monitoring`
-- provider-level shell gating for shared System nav and sub-shell behavior
-
-The app shell in `__root.tsx` derives visible nav from `shellModel.systems` and `getSidebarLinks()`, filters admin-only entries locally using the signed-in profile, and passes `canonicalOrganizationModel` into `ElevasisSystemsProvider` so shared nav labels, paths, and graph runtime behavior resolve from the same organization-model semantic source.
-
-## Dashboard and Feature Areas
-
-**Dashboard**
-
-`ui/src/features/dashboard/components/Dashboard.tsx` is intentionally lightweight. It acts as the host-owned landing page and renders quick access cards for the most important organization surfaces instead of duplicating the shared operations overview.
-
-**Operations**
-
-The operations area is the richest shared shell in the template. It includes:
-
-- resource inventory and detail pages
-- command queue and command view
-- sessions screens
-- the shared operations overview at `/operations/`
-
-**Monitoring**
-
-Monitoring is scaffolded as a shared feature area with route files for:
-
-- activity log
-- cost analytics
-- execution health
-- execution logs
-- notifications
-
-## Customization Points
-
-The main template-owned customization surfaces are:
-
-- `ui/src/config/app-config.ts` -- brand name, logos, and app version
-- `ui/src/config/theme.ts` -- theme presets and defaults
-- `ui/src/config/background.tsx` -- shared background treatment
-- `ui/src/config/loader.tsx` -- global loader element
-- `ui/src/config/nav-items.ts` -- app-local nav entries, including the preserved dashboard/home entry
-- `core/config/organization-model.ts` -- product labels, System availability, resource descriptors, semantic surfaces, canonical-to-legacy surface aliases, and quick-access behavior
-- `ui/src/config/README.md` -- the deeper guide for those config files
-
-## Customizing System Sidebars
-
-The template demonstrates one override pattern in `ui/src/routes/__root.tsx`: it extends `CRM_ITEMS` with a template-owned Reports link and replaces `crmManifest` with `customCrmManifest` in the System module array. The backing route lives at `ui/src/routes/crm/reports.tsx` -- delete both the nav item and the route if you don't need them.
-
-Two customization layers are available for every shared System sidebar:
-
-1. **Nav-item shortcut (`items` prop)** -- when you just need to swap or extend the nav array, spread the published items constant and pass the result to `*SidebarMiddle`. The template's CRM customization uses this path.
-
-   ```tsx
-   import { crmManifest, CrmSidebar, CrmSidebarMiddle, CRM_ITEMS } from '@elevasis/ui/features/crm'
-   import type { NavItem } from '@elevasis/ui/layout'
-
-   const customItems: NavItem[] = [...CRM_ITEMS, { label: 'Reports', to: '/crm/reports', icon: IconFileText, exact: false }]
-   const CustomCrmSidebar = () => <CrmSidebar><CrmSidebarMiddle items={customItems} /></CrmSidebar>
-   const customCrmManifest = { ...crmManifest, sidebar: CustomCrmSidebar }
-   ```
-
-2. **Compose-primitives (structural changes)** -- when you need to inject panels, reorder sections, or add a new section, drop down to `CrmSidebarTop` + `SubshellNavList` + `SubshellSidebarSection` + published panels (`MyTasksPanel`, `QuickCreateActions`) and compose your own Middle.
-
-`manifest.sidebar` accepts any component, so arbitrary customization is always available. The `items` prop is an abstraction barrier for the common case, not a limit.
-
-See `node_modules/@elevasis/sdk/reference/scaffold/ui/customization.md` for the decision tree, page-wrapping pattern, and delivery's three-section variant. For broader CRM extension work across pages, hooks, actions, workflows, and org-model boundaries, start with `node_modules/@elevasis/sdk/reference/scaffold/recipes/extend-crm.md`. For broader lead-gen extension work across pages, hooks, list/member state, artifacts, workflows, and org-model boundaries, start with `node_modules/@elevasis/sdk/reference/scaffold/recipes/extend-lead-gen.md`. See `node_modules/@elevasis/sdk/reference/scaffold/reference/contracts.md` for `NavItem`, `SystemModule`, CRM platform primitives, Lead Gen platform primitives, and related TypeScript shapes.
-
-For CRM deal action buttons, read `node_modules/@elevasis/sdk/reference/scaffold/recipes/customize-crm-actions.md` before changing `crmActions`, `DealDetailPage`, `DealDrawer`, or custom workflow buttons. Start with the shared `crmActions` provider path for action visibility, labels, ordering, and render-time configuration. In v1, platform-known/default action endpoint behavior is server-constrained; use project-owned UI that calls the workflow directly when a custom key sits outside that server-dispatched set.
-
-## Notes
-
-- `ui/src/routeTree.gen.ts` is generated by TanStack Router tooling. Do not hand-edit it.
-- The template ships a broad route surface so downstream projects can trim or reshape features without having to re-derive the shared shell contract from scratch.
-- For package-export discovery, glob `node_modules/@elevasis/sdk/reference/` or `node_modules/@repo/ui/dist/` for the current SDK/UI package surface.
+
+# UI Features
+
+**Status:** Stable
+
+## App Shell Overview
+
+The template frontend is a React 19 + TanStack Router app that composes a local dashboard shell with published System modules from `@elevasis/ui`.
+
+The main join points are:
+
+- `ui/src/main.tsx` -- boots the app with `ElevasisUIProvider`, query client, theme config, WorkOS AuthKit, notifications, and the generated route tree
+- `ui/src/routes/__root.tsx` -- composes the authenticated shell with `ElevasisSystemsProvider`, published System modules, app-local dashboard nav, shell runtime dependencies, and `SystemShell`
+- `ui/src/config/nav-items.ts` -- keeps the host-local dashboard entry separate from the published feature manifests
+- `core/config/organization-model.ts` -- is the template's semantic source of truth, adapting `@elevasis/core/organization-model` into the preserved branding, dashboard label, quick-access, System labels, resource descriptors, and shell helpers
+
+Published System modules mounted by the template shell:
+
+- `lead-gen`
+- `crm`
+- `delivery` at `/projects`
+- `operations`
+- `monitoring`
+- `settings`
+
+Important distinction:
+
+- shared modules gate on current org-model System keys such as `sales.lead-gen` and `projects`
+- template routes and local nav may still use legacy aliases such as `crm`, `lead-gen`, and `projects`
+- `core/config/organization-model.ts` and `ui/src/lib/hooks/useFeatureAccess.ts` are the bridge between those two vocabularies
+
+Dashboard remains a host-local route at `/`, not a shared feature manifest.
+
+This template should be treated as the downstream reference implementation for this composition:
+
+- `core/config/organization-model.ts` owns the organization/runtime semantics
+- `ui/src/config/nav-items.ts` preserves the host-local dashboard entry instead of pushing that concern into shared manifests
+- `ui/src/routes/__root.tsx` threads `canonicalOrganizationModel` from `@core/config/organization-model` into `ElevasisSystemsProvider` so the shared shell/runtime uses the same semantic source of truth as the local template helpers
+- host-local customizations still stay local: dashboard remains app-owned nav, branding stays in app config, and quick-access/dashboard UX stays in the template app
+
+## Auth and Initialization
+
+The app uses WorkOS AuthKit through `ElevasisUIProvider`. Authentication is enforced by the local `ProtectedRoute` wrapper in `ui/src/features/auth/ProtectedRoute.tsx`.
+
+**Sign-in flow:**
+
+1. Unauthenticated user hits a protected route -- `ProtectedRoute` redirects to `/login?returnTo=<path>`
+2. `/login` renders a sign-in card; user clicks Sign In, triggering `signIn({ returnTo })` from `useAuth()`
+3. User authenticates on the WorkOS-hosted sign-in page
+4. WorkOS redirects back to `/auth-redirect` -- `ui/src/routes/auth-redirect.tsx` waits for auth to complete, then navigates to the requested path or `/`
+5. User lands on the home page, fully authenticated
+
+**Route protection:**
+
+Wrap protected route components with the local `ProtectedRoute` from `@/features/auth`, which adds the full-screen loader and delegates to the shared guard from `@elevasis/ui/auth`:
+
+```tsx
+import { ProtectedRoute } from '@/features/auth'
+
+function HomePageGuarded() {
+  return (
+    <ProtectedRoute>
+      <HomePage />
+    </ProtectedRoute>
+  )
+}
+```
+
+**Initialization state:**
+
+Use `useInitialization()` from `@elevasis/ui/initialization` anywhere inside the app to read aggregated auth + org readiness:
+
+```ts
+const { allReady, userReady, isInitializing, error, retry, profile } = useInitialization()
+```
+
+**Organization context:**
+
+Use `useOrganization()` from `@elevasis/ui/organization` to access org-scoped IDs and memberships:
+
+```ts
+const { currentWorkOSOrganizationId, currentSupabaseOrganizationId, memberships, switchOrganization } = useOrganization()
+```
+
+## API and Streaming
+
+Use `useApiClient()` from `@/lib/hooks/useApiClient` in route components and feature hooks:
+
+```ts
+const { apiRequest, isOrganizationReady } = useApiClient()
+const data = await apiRequest('/executions', { method: 'GET' })
+```
+
+The template also re-exports `useApiClientContext()` and the shared API client types from `@/lib/hooks/useApiClient`.
+
+For real-time updates, feature surfaces use the local singleton wrapper:
+
+```ts
+import { sseConnectionManager } from '@/lib/sse/SSEConnectionManager'
+```
+
+**WorkOS config:**
+
+WorkOS `clientId`, `redirectUri`, and `signoutUri` are resolved in `ui/src/config/workos.ts` from `VITE_WORKOS_CLIENT_ID`, `VITE_WORKOS_REDIRECT_URI`, `VITE_WORKOS_SIGNOUT_URI`, and `VITE_APP_ORIGIN`, with localhost fallbacks so the template runs locally without production env vars. For deployed apps, set the production env vars in the hosting provider and allow the exact redirect and sign-out URLs in the WorkOS application dashboard:
+
+- Redirect URI: `https://your-production-domain/auth-redirect`
+- Sign-out redirect: `https://your-production-domain/login`
+- Configure CORS origin: `https://your-production-domain`; required for browser AuthKit calls to `api.workos.com`
+- App homepage origin: `https://your-production-domain`
+
+The dev server runs on port `4300` with Vite `strictPort: true`, so a second `pnpm -C ui dev` on the same machine fails fast instead of drifting.
+
+The API URL is centralized in `ui/src/lib/constants/api.ts`. In the current template it is hard-coded to `https://api.elevasis.io`, so if the bootstrap is repointed to another API target, that file is the source of truth.
+
+## Route Structure
+
+Current top-level app sections:
+
+- `/` -- host-local dashboard entrypoint with quick links derived from `organizationModel.navigation.quickAccessSurfaceIds`
+- `/lead-gen/*` -- lead generation pages (`lists`, `companies`, `contacts`)
+- `/crm/*` -- CRM overview, pipeline, and deals
+- `/projects/*` -- delivery feature pages (projects, milestones, tasks, notes)
+- `/operations/*` -- operations overview, resources, command queue, command view, sessions, task scheduler
+- `/monitoring/*` -- execution logs, execution health, activity log, cost analytics, notifications
+- `/settings/*` -- account, organization, credentials, API keys, deployments, webhooks, and appearance
+- `/login` and `/auth-redirect` -- auth entry/callback routes
+
+Section guards currently follow this pattern:
+
+- `ProtectedRoute` for all authenticated sections
+- `SystemGuard` on sections that should hard-stop when a System is disabled: `crm`, `lead-gen`, `projects`, `operations`, and `monitoring`
+- provider-level shell gating for shared System nav and sub-shell behavior
+
+The app shell in `__root.tsx` derives visible nav from `shellModel.systems` and `getSidebarLinks()`, filters admin-only entries locally using the signed-in profile, and passes `canonicalOrganizationModel` into `ElevasisSystemsProvider` so shared nav labels, paths, and graph runtime behavior resolve from the same organization-model semantic source.
+
+## Dashboard and Feature Areas
+
+**Dashboard**
+
+`ui/src/features/dashboard/components/Dashboard.tsx` is intentionally lightweight. It acts as the host-owned landing page and renders quick access cards for the most important organization surfaces instead of duplicating the shared operations overview.
+
+**Operations**
+
+The operations area is the richest shared shell in the template. It includes:
+
+- resource inventory and detail pages
+- command queue and command view
+- sessions screens
+- the shared operations overview at `/operations/`
+
+**Monitoring**
+
+Monitoring is scaffolded as a shared feature area with route files for:
+
+- activity log
+- cost analytics
+- execution health
+- execution logs
+- notifications
+
+## Customization Points
+
+The main template-owned customization surfaces are:
+
+- `ui/src/config/app-config.ts` -- brand name, logos, and app version
+- `ui/src/config/theme.ts` -- theme presets and defaults
+- `ui/src/config/background.tsx` -- shared background treatment
+- `ui/src/config/loader.tsx` -- global loader element
+- `ui/src/config/nav-items.ts` -- app-local nav entries, including the preserved dashboard/home entry
+- `core/config/organization-model.ts` -- product labels, System availability, resource descriptors, semantic surfaces, canonical-to-legacy surface aliases, and quick-access behavior
+- `ui/src/config/README.md` -- the deeper guide for those config files
+
+## Customizing System Sidebars
+
+The template demonstrates one override pattern in `ui/src/routes/__root.tsx`: it extends `CRM_ITEMS` with a template-owned Reports link and replaces `crmManifest` with `customCrmManifest` in the System module array. The backing route lives at `ui/src/routes/crm/reports.tsx` -- delete both the nav item and the route if you don't need them.
+
+Two customization layers are available for every shared System sidebar:
+
+1. **Nav-item shortcut (`items` prop)** -- when you just need to swap or extend the nav array, spread the published items constant and pass the result to `*SidebarMiddle`. The template's CRM customization uses this path.
+
+   ```tsx
+   import { crmManifest, CrmSidebar, CrmSidebarMiddle, CRM_ITEMS } from '@elevasis/ui/features/crm'
+   import type { NavItem } from '@elevasis/ui/layout'
+
+   const customItems: NavItem[] = [...CRM_ITEMS, { label: 'Reports', to: '/crm/reports', icon: IconFileText, exact: false }]
+   const CustomCrmSidebar = () => <CrmSidebar><CrmSidebarMiddle items={customItems} /></CrmSidebar>
+   const customCrmManifest = { ...crmManifest, sidebar: CustomCrmSidebar }
+   ```
+
+2. **Compose-primitives (structural changes)** -- when you need to inject panels, reorder sections, or add a new section, drop down to `CrmSidebarTop` + `SubshellNavList` + `SubshellSidebarSection` + published panels (`MyTasksPanel`, `QuickCreateActions`) and compose your own Middle.
+
+`manifest.sidebar` accepts any component, so arbitrary customization is always available. The `items` prop is an abstraction barrier for the common case, not a limit.
+
+See `node_modules/@elevasis/sdk/reference/scaffold/ui/customization.md` for the decision tree, page-wrapping pattern, and delivery's three-section variant. For broader CRM extension work across pages, hooks, actions, workflows, and org-model boundaries, start with `node_modules/@elevasis/sdk/reference/scaffold/recipes/extend-crm.md`. For broader lead-gen extension work across pages, hooks, list/member state, artifacts, workflows, and org-model boundaries, start with `node_modules/@elevasis/sdk/reference/scaffold/recipes/extend-lead-gen.md`. See `node_modules/@elevasis/sdk/reference/scaffold/reference/contracts.md` for `NavItem`, `SystemModule`, CRM platform primitives, Lead Gen platform primitives, and related TypeScript shapes.
+
+For CRM deal action buttons, read `node_modules/@elevasis/sdk/reference/scaffold/recipes/customize-crm-actions.md` before changing `crmActions`, `DealDetailPage`, `DealDrawer`, or custom workflow buttons. Start with the shared `crmActions` provider path for action visibility, labels, ordering, and render-time configuration. In v1, platform-known/default action endpoint behavior is server-constrained; use project-owned UI that calls the workflow directly when a custom key sits outside that server-dispatched set.
+
+## Notes
+
+- `ui/src/routeTree.gen.ts` is generated by TanStack Router tooling. Do not hand-edit it.
+- The template ships a broad route surface so downstream projects can trim or reshape features without having to re-derive the shared shell contract from scratch.
+- For package-export discovery, glob `node_modules/@elevasis/sdk/reference/` or `node_modules/@repo/ui/dist/` for the current SDK/UI package surface.

package/reference/rules/vibe.md

@@ -1,5 +1,5 @@
 ---
-description: Ambient intent classifier -- routes natural-language input to 7 intent buckets without a slash command; Codify and Toggle delegate to /om
+description: Ambient intent classifier -- routes natural-language input to intent buckets without a slash command; Codify and Toggle delegate to /om, Operate delegates to /elevasis
 paths:
   - "**/*"
 ---
@@ -19,7 +19,7 @@ Vibe is the translation layer between the user's natural language and the correc
 
 Vibe coders (non-technical builders) are the primary audience. They build by describing. They never memorize commands, IDs, or schema. The ambient layer closes the gap between what they say and what the system can act on.
 
-## The Seven Intent Types
+## Intent Types
 
 ### 1. Capture
 
@@ -29,14 +29,15 @@ The user wants to record something new -- a task, a note, a piece of information
 
 **Fixture examples:**
 
-| Input                                             | Why it's Capture                            |
-| ------------------------------------------------- | ------------------------------------------- |
-| "Add a task to follow up with the Shopify client" | Explicit "add a task" with a described item |
-| "Remember to run the campaign report on Friday"   | "Remember to" signals something to persist  |
-| "Run the campaign report every Friday at 9am"     | Repeating schedule vocabulary to persist    |
-| "Track this conversation as a deal note"          | Explicit "track" with a described artifact  |
+| Input                                               | Why it's Capture                             |
+| --------------------------------------------------- | -------------------------------------------- |
+| "Add a task to follow up with the Shopify client"   | Explicit "add a task" with a described item  |
+| "Remember to run the campaign report on Friday"     | "Remember to" signals something to persist   |
+| "Run the campaign report every Friday at 9am"       | Repeating schedule vocabulary to persist     |
+| "Track this conversation as a deal note"            | Explicit "track" with a described artifact   |
+| "Note for myself: the client prefers morning calls" | "Note for myself" = personal note to persist |
 
-**Agent action:** draft the capture in plain language, confirm with the user, then execute via `elevasis-sdk project:*` commands for project records or `elevasis-sdk schedule:create` for recurring automation. Use repetition vocabulary ("every", "daily", "weekly", "monthly") for schedules; one-shot future reminders stay project tasks with due dates. Never write without confirmation.
+**Agent action:** draft the capture in plain language, confirm with the user, then execute via `elevasis-sdk project:*` commands for project records, `elevasis-sdk note:create` for personal user notes (the Command Center right panel), or `elevasis-sdk schedule:create` for recurring automation. Disambiguate note scope: a note tied to a deal/task/project is `project:note:create` (a `project:*` record); a standalone personal note is `note:create`. Use repetition vocabulary ("every", "daily", "weekly", "monthly") for schedules; one-shot future reminders stay project tasks with due dates. Never write without confirmation.
 
 ### 2. Query
 
@@ -122,6 +123,8 @@ The user describes organizational reality that is not yet expressed in the model
 
 **Recognize by:** declarative "we are" / "we use" / "we track" statements, repeated attribute mentions (second time the same attribute appears), or explicit "add a type / add a field / model X as Y" requests.
 
+**NOT Codify — do not over-propose on questions.** "What systems are on?", "tell me about deals", "explain the lead-gen Action" are Describe, not Codify. The discriminator is _asking about_ versus _asking to change_ the model. Read-shaped inputs ("what", "tell me", "explain", "show me", "where am I") stay in Describe even when they reference the same vocabulary Codify edits — narrate, do not propose codification. Only propose codification when the user declares new structure ("we're an X company", "we track Y as Z") or explicitly asks for a model change ("add a field…", "rename stage…").
+
 **Fixture examples:**
 
 | Input                                                                            | Why it's Codify                                          |
@@ -180,17 +183,48 @@ The user wants to enable or disable a System.
 
 **Agent action:** delegate to `/om systems`. The ceremony (confirm + edit `core/config/organization-model.ts` + typecheck) belongs to `/om`, not to the ambient rule.
 
+**Tenant-local only.** Toggle operates on the tenant's own `core/config/organization-model.ts` — the project's own Systems. Platform-level Systems (the Elevasis monorepo's `packages/elevasis-core/src/organization-model/`) are not in scope; tenants cannot toggle them and vibe must not pretend they can. If a user names a platform-only System, surface the boundary in plain language rather than attempting a toggle.
+
+### 8. Operate
+
+The user wants to run an already-deployed workflow or agent against the platform — kick off an execution, not change configuration.
+
+**Recognize by:** action verbs "run", "execute", "launch", "trigger", "kick off", "start" combined with a named deployed resource (a workflow id, agent name, or named pipeline). Distinguish from:
+
+- **Capture** — "remember to run X" is a persisted reminder/schedule, not an immediate execution.
+- **Transition** — "the run is done" is a status change on an existing execution, not a new run.
+- **Codify** — "add a workflow called X" is a model change, not an execution of an existing one.
+
+**Fixture examples:**
+
+| Input                                            | Why it's Operate                               |
+| ------------------------------------------------ | ---------------------------------------------- |
+| "Run the daily-digest workflow"                  | "Run" + named deployed resource                |
+| "Kick off the lead-gen pipeline for ZentaraHQ"   | "Kick off" + named resource + named scope      |
+| "Execute the campaign builder against this list" | "Execute" + deployed workflow + concrete input |
+| "Launch the apify-init agent now"                | "Launch" + named deployed agent                |
+
+**Agent action:** delegate to `/elevasis`. The describe-then-exec ceremony belongs to that skill, not to the ambient rule:
+
+1. `elevasis-sdk describe <resourceId>` to fetch the deployed resource's input contract.
+2. Draft the input payload from the user's natural-language phrasing.
+3. Confirm with the user (plain-language summary of payload + target).
+4. `elevasis-sdk exec <resourceId> --input '{…}'` to run it.
+
+**Runs already-deployed resources only.** Operate never deploys, never creates, never edits the workflow source. If the named resource is not deployed, surface that in plain language and offer to route to Codify (define it) or Capture (record a follow-up) — do not attempt to deploy from the ambient rule.
+
 ## Quick Reference Table
 
-| Intent     | Trigger signal                                                         | Routed to                                                               |
-| ---------- | ---------------------------------------------------------------------- | ----------------------------------------------------------------------- |
-| Capture    | "add", "remember", "track", "log" + a thing                            | Agent -- draft + confirm + `project:*` or `schedule:create` CLI         |
-| Query      | "what's next", "what's pending", "what failed", "what systems"         | Agent -- read with `project:*`, `queue:*`, or `schedule:*` + narrate    |
-| Describe   | "what is", "tell me about", "explain", "where am I"                    | Agent -- narrate from org model labels                                  |
-| Transition | "done", "stuck", "blocked", "finished", "complete", "approve", "pause" | Agent -- confirm + `project:task:save`, `queue:select`, or `schedule:*` |
-| Navigate   | "focus on", "switch to", "back to", "look at"                          | Agent -- update scope + narrate                                         |
-| Codify     | "we are X", "we track Y", repeated attribute, "add type/field"         | Delegate to `/om \<domain>`                                             |
-| Toggle     | "enable", "disable", "turn on/off" + system                            | Delegate to `/om systems`                                               |
+| Intent     | Trigger signal                                                                 | Routed to                                                                          |
+| ---------- | ------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------- |
+| Capture    | "add", "remember", "track", "log", "note for myself" + a thing                 | Agent -- draft + confirm + `project:*`, `note:create`, or `schedule:create` CLI    |
+| Query      | "what's next", "what's pending", "what failed", "what systems"                 | Agent -- read with `project:*`, `queue:*`, or `schedule:*` + narrate               |
+| Describe   | "what is", "tell me about", "explain", "where am I"                            | Agent -- narrate from org model labels                                             |
+| Transition | "done", "stuck", "blocked", "finished", "complete", "approve", "pause"         | Agent -- confirm + `project:task:save`, `queue:select`, or `schedule:*`            |
+| Navigate   | "focus on", "switch to", "back to", "look at"                                  | Agent -- update scope + narrate                                                    |
+| Codify     | "we are X", "we track Y", repeated attribute, "add type/field"                 | Delegate to `/om \<domain>`                                                        |
+| Toggle     | "enable", "disable", "turn on/off" + system                                    | Delegate to `/om systems` (tenant-local only)                                      |
+| Operate    | "run", "execute", "launch", "trigger", "kick off", "start" + deployed resource | Delegate to `/elevasis` -- `elevasis-sdk describe` + confirm + `elevasis-sdk exec` |
 
 ## Source of Truth for Plain Language
 

package/reference/scaffold/index.mdx

@@ -14,7 +14,7 @@ This scaffold reference contains universal documentation that applies to all Ele
 - **ui/** -- UI patterns, system shell architecture, composition, and customization
 - **core/** -- Organization model architecture, graph layer, and semantic contracts
 - **operations/** -- Workflow authoring patterns and adapter usage
-- **reference/** -- Glossary, auto-generated contracts, and system registry
+- **reference/** -- Glossary, auto-generated contracts, and system registry
 
 ## Quick Navigation
 
@@ -49,9 +49,10 @@ This scaffold reference contains universal documentation that applies to all Ele
 
 ### Reference
 
-- [Glossary](./reference/glossary.md) -- term definitions for Organization OS concepts
-- [Contracts](./reference/contracts.md) -- auto-generated TypeScript contract shapes
-- [System Registry](./reference/feature-registry.md) -- auto-generated system manifest catalog
+- [Glossary](./reference/glossary.md) -- term definitions for Organization OS concepts
+- [Contracts](./reference/contracts.md) -- auto-generated TypeScript contract shapes
+- [System Interface Capabilities](./reference/system-interface-capabilities.md) -- auto-generated catalog of supported System Interface profiles and readiness requirements
+- [System Registry](./reference/feature-registry.md) -- auto-generated system manifest catalog
 
 ## Source Locations
 
@@ -65,6 +66,7 @@ Content is co-located with its owning package and copied here during SDK build:
 | `scaffold/operations/scaffold-maintenance.md` | `packages/sdk/docs/scaffold/operations/`                  | SDK             |
 | `scaffold/ui/`                                | `packages/ui/src/scaffold/`                               | UI              |
 | `scaffold/core/`                              | `packages/core/src/organization-model/`                   | Core            |
-| `scaffold/reference/glossary.md`              | `packages/core/src/reference/glossary.md`                 | Core            |
-| `scaffold/reference/contracts.md`             | `packages/core/src/reference/_generated/contracts.md`     | Core (auto-gen) |
-| `scaffold/reference/feature-registry.md`      | `packages/ui/src/scaffold/_generated/feature-registry.md` | UI (auto-gen)   |
+| `scaffold/reference/glossary.md`              | `packages/core/src/reference/glossary.md`                 | Core            |
+| `scaffold/reference/contracts.md`             | `packages/core/src/reference/_generated/contracts.md`     | Core (auto-gen) |
+| `scaffold/reference/system-interface-capabilities.md` | `packages/core/src/reference/_generated/system-interface-capabilities.md` | Core (auto-gen) |
+| `scaffold/reference/feature-registry.md`      | `packages/ui/src/scaffold/_generated/feature-registry.md` | UI (auto-gen)   |

package/reference/scaffold/operations/scaffold-maintenance.md

@@ -29,9 +29,10 @@ Scaffold docs are co-located with their owning package and copied into the SDK r
 | --------------------------- | --------------------------------------------------------------- | --------------------------------------------- |
 | Organization Model          | `packages/core/src/organization-model/organization-model.mdx`   | `scaffold/core/organization-model.mdx`        |
 | Organization Graph          | `packages/core/src/organization-model/organization-graph.mdx`   | `scaffold/core/organization-graph.mdx`        |
-| Glossary                    | `packages/core/src/reference/glossary.md`                       | `scaffold/reference/glossary.md`              |
-| Contracts (auto-gen)        | `packages/core/src/reference/_generated/contracts.md`           | `scaffold/reference/contracts.md`             |
-| UI Recipes                  | `packages/ui/src/scaffold/recipes.md`                           | `scaffold/ui/recipes.md`                      |
+| Glossary                    | `packages/core/src/reference/glossary.md`                       | `scaffold/reference/glossary.md`              |
+| Contracts (auto-gen)        | `packages/core/src/reference/_generated/contracts.md`           | `scaffold/reference/contracts.md`             |
+| System Interface Capabilities (auto-gen) | `packages/core/src/reference/_generated/system-interface-capabilities.md` | `scaffold/reference/system-interface-capabilities.md` |
+| UI Recipes                  | `packages/ui/src/scaffold/recipes.md`                           | `scaffold/ui/recipes.md`                      |
 | System Flags & Gating       | `packages/ui/src/scaffold/feature-flags-and-gating.md`          | `scaffold/ui/feature-flags-and-gating.md`     |
 | Customization               | `packages/ui/src/scaffold/customization.md`                     | `scaffold/ui/customization.md`                |
 | System Shell                | `packages/ui/src/scaffold/feature-shell.mdx`                    | `scaffold/ui/feature-shell.mdx`               |
@@ -57,7 +58,16 @@ Generated by `scripts/monorepo/generate-scaffold-contracts.js` from TypeScript s
 - `packages/ui/src/features/registry/types.ts` -- System Registry
 - `packages/core/src/platform/registry/types.ts` -- Resource Registry, Deployment Spec
 
-Output: `packages/core/src/reference/_generated/contracts.md`
+Output: `packages/core/src/reference/_generated/contracts.md`
+
+### System Interface Capabilities (`system-interface-capabilities.md`)
+
+Generated by `scripts/monorepo/generate-scaffold-contracts.js` from:
+
+- `packages/core/src/organization-model/domains/systems.ts` -- `SYSTEM_INTERFACE_PROFILES`
+- `packages/core/src/business/acquisition/ontology-validation.ts` -- derived-readiness validation constants and checks
+
+Output: `packages/core/src/reference/_generated/system-interface-capabilities.md`
 
 ### System Registry (`feature-registry.md`)