@elevasis/ui 2.49.0 → 2.50.0

package/dist/{chunk-Y3HPUATG.js → chunk-SBNC3FRX.js}

@@ -1,17 +1,19 @@
 import { glassBase, mantineThemeOverride, createCssVariablesResolver, PresetsProvider, useAvailablePresets } from './chunk-NZ2F5RQ4.js';
 import { PRESETS, getPreset, AppBackground, generateShades } from './chunk-OJJK27GC.js';
 import { useSupabase } from './chunk-MKH2KOAO.js';
-import { StyledMarkdown, ChatHeader, ChatSidebar } from './chunk-GUKY77FJ.js';
+import { HTTP_HEADERS, ApiClientProvider, useApiClient } from './chunk-7Q5THR43.js';
+import { sidebarItemGap, sidebarSubLinkPaddingY, sidebarSubLinkPaddingX, sidebarSubLinkIndent, sidebarHoverDelay, sidebarTransitionDuration, sidebarCollapsedWidth, sidebarWidth, topbarHeight, sidebarToggleIconSize, sidebarSectionPadding, sidebarItemPadding, sidebarItemHeight, sidebarIconSize, sidebarIconStroke, sidebarIconInnerSize, sidebarBottomSectionHeight, SubshellNavItem, sidebarGroupChevronSize, SubshellSidebarSection } from './chunk-GMXGDO3I.js';
 import { CardHeader } from './chunk-S3XR4II4.js';
 import { useInitialization, InitializationContext, InitializationProvider } from './chunk-6DO4PE3O.js';
-import { HTTP_HEADERS, ApiClientProvider, useApiClient } from './chunk-OFLWSKSC.js';
 import { OrganizationContext, useOrganization } from './chunk-DD3CCMCZ.js';
-import { sidebarItemGap, sidebarSubLinkPaddingY, sidebarSubLinkPaddingX, sidebarSubLinkIndent, sidebarHoverDelay, sidebarTransitionDuration, sidebarCollapsedWidth, sidebarWidth, topbarHeight, sidebarToggleIconSize, sidebarSectionPadding, sidebarItemPadding, sidebarItemHeight, sidebarIconSize, sidebarIconStroke, sidebarIconInnerSize, sidebarBottomSectionHeight, SubshellNavItem, sidebarGroupChevronSize, SubshellSidebarSection } from './chunk-GMXGDO3I.js';
+import { SessionIdParamSchema, CreateSessionSchema, GetNotificationsQuerySchema, MarkAsReadParamsSchema, ExecutionIdParamsSchema, WebSocketSessionTurnSchema } from './chunk-EJL4U7OZ.js';
+import { StyledMarkdown, ChatHeader, ChatSidebar } from './chunk-GUKY77FJ.js';
 import { useRouterContext } from './chunk-Q7DJKLEN.js';
 import { Graph_module_css_default, useDirectedChainHighlighting, useNodeSelection, useFitViewTrigger, useGraphHighlighting, calculateGraphHeight, GRAPH_CONSTANTS } from './chunk-HENXLGVD.js';
 import { STATUS_COLORS, getStatusIcon, formatDuration, getStatusColors, AGENT_CONSTANTS, shouldAnimateEdge, TIMELINE_CONSTANTS, calculateBarPosition, CONTAINER_CONSTANTS, useExecutionPath, useUnifiedWorkflowLayout, WORKFLOW_CONSTANTS, useReactFlowAgent, getResourceStatusColor, useMergedExecution, useTimelineData, useAgentIterationData } from './chunk-7FPLLSHN.js';
 import { useProfile, useUserProfile, ProfileProvider } from './chunk-W2SFTXMT.js';
-import { LabelSchema, DescriptionSchema, PathSchema, ModelIdSchema, IconNameSchema, SystemLifecycleSchema, OntologyIdSchema, SystemPathSchema, ActionInvocationSchema, SystemIdSchema, NodeIdStringSchema, JsonValueSchema, SystemInterfaceRefSchema, EntitiesDomainSchema, ActionsDomainSchema, DEFAULT_ORGANIZATION_MODEL_ACTIONS, OntologyScopeSchema, DEFAULT_ONTOLOGY_SCOPE, SystemsDomainSchema, DEFAULT_ORGANIZATION_MODEL_SYSTEMS, defineEntities, defineActions, listAllSystems, listResolvedOntologyRecords, getErrorInfo, getErrorTitle, formatErrorMessage, getSystem, compileOrganizationOntology, isAPIClientError, getResourceIcon, formatTimeAgo, getTimeRangeLabel, getTimeRangeDates, formatBucketTime, PAGE_SIZE_DEFAULT, REFETCH_INTERVAL_DASHBOARD, STALE_TIME_MONITORING, REFETCH_INTERVAL_RUNNING, WS_MAX_RETRIES_BEFORE_ERROR, WS_RECONNECT_BASE_DELAY, WS_RECONNECT_MAX_DELAY, STALE_TIME_DEFAULT, STALE_TIME_ADMIN, APIClientError, GC_TIME_MEDIUM, GC_TIME_SHORT, formatDateTime, LEAD_GEN_API_INTERFACE, computeInterfaceReadiness, getAllBuildTemplates, getLeadGenStageCatalog, formatDate, formatRelativeTime, getResourcesForSystem, ontologyGraphNodeId, parseOntologyId, getAllProspectingStages, getAllPipelines, getAllProjectStatuses, debounce, OAUTH_FLOW_TIMEOUT, devOnlyFor, requiresAdminFor, topLevel, parentOf, ancestorsOf, childrenOf, findById, findByPath, getSystemAncestors, resolveSystemConfig, defaultPathFor } from './chunk-CDZB24OR.js';
+import { LabelSchema, DescriptionSchema, PathSchema, ModelIdSchema, IconNameSchema, SystemLifecycleSchema, OntologyIdSchema, SystemPathSchema, ActionInvocationSchema, SystemIdSchema, NodeIdStringSchema, JsonValueSchema, SystemInterfaceRefSchema, EntitiesDomainSchema, ActionsDomainSchema, DEFAULT_ORGANIZATION_MODEL_ACTIONS, OntologyScopeSchema, DEFAULT_ONTOLOGY_SCOPE, SystemsDomainSchema, DEFAULT_ORGANIZATION_MODEL_SYSTEMS, defineEntities, defineActions, listAllSystems, listResolvedOntologyRecords, getErrorInfo, getErrorTitle, formatErrorMessage, getSystem, compileOrganizationOntology, isAPIClientError, getResourceIcon, formatTimeAgo, PAGE_SIZE_DEFAULT, STALE_TIME_MONITORING, STALE_TIME_DEFAULT, STALE_TIME_ADMIN, APIClientError, GC_TIME_MEDIUM, GC_TIME_SHORT, formatDateTime, LEAD_GEN_API_INTERFACE, computeInterfaceReadiness, getAllBuildTemplates, getLeadGenStageCatalog, formatDate, formatRelativeTime, getResourcesForSystem, ontologyGraphNodeId, parseOntologyId, getAllProspectingStages, getAllPipelines, getAllProjectStatuses, OAUTH_FLOW_TIMEOUT, devOnlyFor, requiresAdminFor, topLevel, parentOf, ancestorsOf, childrenOf, findById, findByPath, getSystemAncestors, resolveSystemConfig, defaultPathFor } from './chunk-XOPLS4S6.js';
+import { getTimeRangeLabel, getTimeRangeDates, formatBucketTime, REFETCH_INTERVAL_DASHBOARD, REFETCH_INTERVAL_RUNNING, WS_MAX_RETRIES_BEFORE_ERROR, WS_RECONNECT_BASE_DELAY, WS_RECONNECT_MAX_DELAY, debounce } from './chunk-FVOMKZ7S.js';
 import { ResourceStatusColors, toWorkflowLogMessages } from './chunk-KRWALB24.js';
 import { useElevasisServices, ElevasisServiceContext, ElevasisServiceProvider } from './chunk-2FTX4WO2.js';
 import { brandSupabaseOrgId, brandWorkOsOrgId } from './chunk-MQZE7SUI.js';
@@ -2294,76 +2296,6 @@ z.object({
     })
   ).optional()
 });
-var SessionIdParamSchema = z.object({
-  sessionId: UuidSchema
-}).strict();
-var ExecutionIdParamsSchema = z.object({
-  sessionId: UuidSchema,
-  executionId: UuidSchema
-}).strict();
-var CreateSessionSchema = z.object({
-  resourceId: z.string().min(1).max(100),
-  userId: UuidSchema.optional(),
-  metadata: z.any().optional()
-}).strict();
-z.object({
-  input: z.unknown().refine(
-    (val) => {
-      let text;
-      if (typeof val === "string") {
-        text = val;
-      } else if (val && typeof val === "object" && "message" in val) {
-        text = String(val.message);
-      } else {
-        text = JSON.stringify(val);
-      }
-      return text.length > 0 && text.length <= 1e5;
-    },
-    { message: "Input must be between 1 and 100,000 characters" }
-  ),
-  metadata: z.any().optional()
-}).strict();
-z.object({
-  userId: UuidSchema.optional(),
-  resourceId: z.string().optional(),
-  limit: z.coerce.number().int().min(1).max(100).default(20)
-}).strict();
-var WebSocketSessionTurnSchema = z.object({
-  type: z.literal("session:turn"),
-  input: z.unknown().refine(
-    (val) => {
-      let text;
-      if (typeof val === "string") {
-        text = val;
-      } else if (val && typeof val === "object" && "message" in val) {
-        text = String(val.message);
-      } else {
-        text = JSON.stringify(val) || "";
-      }
-      return text && text.length > 0 && text.length <= 1e5;
-    },
-    { message: "Input must be between 1 and 100,000 characters" }
-  )
-}).strict();
-var NotificationCategorySchema = z.enum(["info", "queue", "alert", "error", "system"]);
-var GetNotificationsQuerySchema = z.object({
-  limit: z.coerce.number().int().min(1).max(100).default(50),
-  offset: z.coerce.number().int().min(0).default(0)
-});
-var MarkAsReadParamsSchema = z.object({
-  id: UuidSchema
-});
-z.object({
-  userId: UuidSchema,
-  organizationId: UuidSchema,
-  category: NotificationCategorySchema,
-  title: z.string().trim().min(1).max(200),
-  message: z.string().trim().min(1).max(1e3),
-  actionUrl: z.string().url().optional()
-}).strict();
-z.object({
-  ids: z.array(UuidSchema).min(1).max(500)
-}).strict();
 
 // ../core/src/business/acquisition/build-templates.ts
 function getProspectingBuildTemplateOptions(templates) {
@@ -11216,6 +11148,22 @@ function useCommandQueue({
     enabled: isReady
   });
 }
+function useCommandQueueTask(taskId) {
+  const { apiRequest, isReady, workOSOrganizationId } = useElevasisServices();
+  return useQuery({
+    queryKey: ["command-queue", "detail", workOSOrganizationId, taskId],
+    queryFn: async () => {
+      const response = await apiRequest(`/command-queue/${taskId}`);
+      return {
+        ...response.task,
+        createdAt: new Date(response.task.createdAt),
+        completedAt: response.task.completedAt ? new Date(response.task.completedAt) : void 0,
+        expiresAt: response.task.expiresAt ? new Date(response.task.expiresAt) : void 0
+      };
+    },
+    enabled: isReady && !!taskId
+  });
+}
 function useSubmitAction() {
   const { apiRequest } = useElevasisServices();
   const queryClient = useQueryClient();
@@ -19575,7 +19523,7 @@ function ResourceHeader({
           " running"
         ] }),
         onRun && /* @__PURE__ */ jsx(Button, { size: "xs", variant: "filled", leftSection: /* @__PURE__ */ jsx(IconPlayerPlay, { size: 16 }), onClick: onRun, children: "Run" }),
-        type === "agent" && sessionCapable && /* @__PURE__ */ jsx(Button, { size: "xs", variant: "light", leftSection: /* @__PURE__ */ jsx(IconMessage, { size: 16 }), onClick: handleGoToSessions, children: "Go to Sessions" }),
+        type === "agent" && sessionCapable && /* @__PURE__ */ jsx(Button, { size: "xs", variant: "light", leftSection: /* @__PURE__ */ jsx(IconMessage, { size: 16 }), onClick: handleGoToSessions, children: "Agent Sessions" }),
         /* @__PURE__ */ jsx(Button, { size: "xs", variant: "light", leftSection: /* @__PURE__ */ jsx(IconArrowLeft, { size: 16 }), onClick: handleGoToResources, children: "Resources" })
       ] })
     ] })
@@ -22681,7 +22629,7 @@ var mdxKnowledgeNodes = [
     "title": "Client CLI Overview",
     "summary": "Reference for the seven client:* SDK CLI commands -- list, get, status, resolve, create, update, and delete -- with drill-down recipes for navigating client lineage, org-wide rollups, and write operations.",
     "icon": "reference",
-    "body": '## Overview\r\n\r\nThe `client:*` commands expose the clients hub through the SDK CLI. Use them to paginate clients, inspect individual client lineage, check org-wide status rollups, resolve a fuzzy name to a client ID, and mutate clients with create, update, and delete operations.\r\n\r\nAll examples below use the canonical monorepo invocation pattern. Tenant projects inside their own `operations/` directory drop the `-C packages/elevasis-operations` prefix and run `pnpm exec elevasis-sdk <cmd>` directly.\r\n\r\n## client:list\r\n\r\nLists clients for the authenticated organization with optional filtering and pagination.\r\n\r\n**Purpose:** Paginate all clients or narrow by status or search term to find the right client ID before drilling in with `client:get`.\r\n\r\n**Monorepo invocation:**\r\n\r\n```bash\r\npnpm -C packages/elevasis-operations exec elevasis-sdk client:list\r\n```\r\n\r\n**Tenant invocation (from inside `operations/`):**\r\n\r\n```bash\r\npnpm exec elevasis-sdk client:list\r\n```\r\n\r\n**Key flags:**\r\n\r\n- `--status <value>` -- filter by client status (e.g. `active`, `inactive`, `prospect`)\r\n- `--search <term>` -- full-text search against client name\r\n- `--limit <n>` -- maximum rows to return (default varies by server)\r\n- `--offset <n>` -- pagination offset\r\n- `--pretty` -- pretty-print JSON output\r\n\r\n**Drill-down recipe:**\r\n\r\n1. Run `client:list --pretty` to scan names and IDs.\r\n2. Use `--search` to narrow when the list is long.\r\n3. Copy the `id` from a row and pass it to `client:get <id>` for the full lineage payload (linked deal, primary company, primary contact, projects).\r\n\r\n## client:get\r\n\r\nFetches a single client record with its full lineage payload.\r\n\r\n**Purpose:** Inspect one client in detail -- its associated deal, primary company, primary contact, and linked projects. Use this to confirm linkage after wiring a project to a client via `project:update --client`.\r\n\r\n**Monorepo invocation:**\r\n\r\n```bash\r\npnpm -C packages/elevasis-operations exec elevasis-sdk client:get <clientId>\r\n```\r\n\r\n**Tenant invocation:**\r\n\r\n```bash\r\npnpm exec elevasis-sdk client:get <clientId>\r\n```\r\n\r\n**Key flags:**\r\n\r\n- `--pretty` -- pretty-print JSON output\r\n\r\n**Drill-down recipe:**\r\n\r\n1. Obtain `<clientId>` from `client:list` or `client:resolve`.\r\n2. Run `client:get <clientId> --pretty`.\r\n3. Check `projects` array to confirm which projects are linked.\r\n4. If `projects` is empty and a linkage was expected, run `project:update <projectId> --client <clientId>` to attach it.\r\n5. Re-run `client:get` to verify the lineage updated.\r\n\r\n## client:status\r\n\r\nReturns an org-wide rollup of client counts grouped by status.\r\n\r\n**Purpose:** High-level health check -- how many clients are active, how many are in each pipeline stage -- without enumerating every record.\r\n\r\n**Monorepo invocation:**\r\n\r\n```bash\r\npnpm -C packages/elevasis-operations exec elevasis-sdk client:status\r\n```\r\n\r\n**Tenant invocation:**\r\n\r\n```bash\r\npnpm exec elevasis-sdk client:status\r\n```\r\n\r\n**Key flags:**\r\n\r\n- `--pretty` -- pretty-print JSON output\r\n\r\n**Drill-down recipe:**\r\n\r\n1. Run `client:status --pretty` to see counts per status bucket.\r\n2. If a bucket looks unexpectedly large or small, run `client:list --status <value>` to enumerate the records in that bucket.\r\n3. Use `client:get <id>` on specific records to investigate lineage gaps.\r\n\r\n## client:resolve\r\n\r\nFuzzy-resolves a client name to a client ID.\r\n\r\n**Purpose:** Convert a partial or approximate name to the canonical UUID before passing `--client` to project commands. Mirrors `project:resolve` in shape.\r\n\r\n**Monorepo invocation:**\r\n\r\n```bash\r\npnpm -C packages/elevasis-operations exec elevasis-sdk client:resolve "<query>"\r\n```\r\n\r\n**Tenant invocation:**\r\n\r\n```bash\r\npnpm exec elevasis-sdk client:resolve "<query>"\r\n```\r\n\r\n**Key flags:**\r\n\r\nNone beyond the positional `<query>` argument. Output is the resolved client ID (or a ranked list if multiple matches exist).\r\n\r\n**Drill-down recipe:**\r\n\r\n1. Run `client:resolve "partial name"` -- the command returns the best-match client ID.\r\n2. Pass the returned ID to `project:create --client <id>`, `project:update --client <id>`, or `project:list --client <id>`.\r\n3. If multiple matches are returned, refine the query or use `client:list --search "<term>"` to inspect candidates before committing.\r\n\r\n## client:create\r\n\r\nCreates a new client record for the authenticated organization.\r\n\r\n**Purpose:** Provision a client directly from the CLI -- useful for scripted onboarding or bulk imports where no source deal exists yet. The only required field is `--name`; all relationship IDs are optional and can be set later via `client:update`.\r\n\r\n**Monorepo invocation:**\r\n\r\n```bash\r\npnpm -C packages/elevasis-operations exec elevasis-sdk client:create --name "Acme Corp"\r\n```\r\n\r\n**Tenant invocation (from inside `operations/`):**\r\n\r\n```bash\r\npnpm exec elevasis-sdk client:create --name "Acme Corp"\r\n```\r\n\r\n**Key flags:**\r\n\r\n- `--name <name>` -- (required) client display name\r\n- `--status <value>` -- initial status: `active` | `onboarding` | `paused` | `completed` | `churned`\r\n- `--source-deal-id <uuid>` -- UUID of the originating deal\r\n- `--primary-company-id <uuid>` -- UUID of the primary company record\r\n- `--primary-contact-id <uuid>` -- UUID of the primary contact record\r\n- `--metadata <json>` -- arbitrary metadata as a JSON string (e.g. `\'{"tier":"enterprise"}\'`)\r\n- `--pretty` -- render a human-readable summary instead of raw JSON\r\n\r\n**Drill-down recipe:**\r\n\r\n1. Run `client:create --name "Acme Corp" --status onboarding --pretty` to create and confirm the new record.\r\n2. Copy the `ID` from the pretty output (or `id` from raw JSON) for subsequent commands.\r\n3. Run `client:get <id> --pretty` to verify the full lineage payload was initialized correctly.\r\n4. If a source deal exists, pass `--source-deal-id <uuid>` at create time or backfill with `client:update <id> --source-deal-id <uuid>`.\r\n\r\n## client:update\r\n\r\nUpdates one or more fields on an existing client. Accepts a UUID or fuzzy name as the `\\<id\\>` argument.\r\n\r\n**Purpose:** Rename a client, change its status, swap or clear relationship IDs, or patch arbitrary metadata -- without leaving the CLI. The command enforces a client-side "at-least-one-field" guard and rejects mutually exclusive flag pairs before making any API call.\r\n\r\n**Monorepo invocation:**\r\n\r\n```bash\r\npnpm -C packages/elevasis-operations exec elevasis-sdk client:update <id> --status active\r\n```\r\n\r\n**Tenant invocation:**\r\n\r\n```bash\r\npnpm exec elevasis-sdk client:update <id> --status active\r\n```\r\n\r\n**Key flags:**\r\n\r\n- `--name <name>` -- new client display name\r\n- `--status <value>` -- new status: `active` | `onboarding` | `paused` | `completed` | `churned`\r\n- `--source-deal-id <uuid>` -- set or replace the source deal link\r\n- `--clear-source-deal` -- remove the source deal link (sets `sourceDealId` to null; mutually exclusive with `--source-deal-id`)\r\n- `--primary-company-id <uuid>` -- set or replace the primary company\r\n- `--clear-primary-company` -- remove the primary company link (mutually exclusive with `--primary-company-id`)\r\n- `--primary-contact-id <uuid>` -- set or replace the primary contact\r\n- `--clear-primary-contact` -- remove the primary contact link (mutually exclusive with `--primary-contact-id`)\r\n- `--metadata <json>` -- replace metadata with the provided JSON string\r\n- `--pretty` -- render a human-readable summary instead of raw JSON\r\n\r\n**Drill-down recipe:**\r\n\r\n1. Obtain `\\<id\\>` from `client:list`, `client:resolve`, or the output of `client:create`.\r\n2. Pass only the fields to change -- the command patches rather than replaces the record.\r\n3. To unlink a relationship (e.g. remove the source deal), use `--clear-source-deal` rather than omitting the flag; omitting leaves the existing value unchanged.\r\n4. After update, run `client:get <id> --pretty` to confirm all fields reflect the expected state.\r\n5. If the command exits with `CONFLICTING_FLAGS` on stderr, you passed both a set flag and its `--clear-*` counterpart -- remove one and retry.\r\n\r\n## client:delete\r\n\r\nDeletes a client record. Accepts a UUID or fuzzy name as the `\\<id\\>` argument.\r\n\r\n**Purpose:** Remove a client that was created in error or is no longer relevant. The API enforces a 409 Conflict when the client has linked rows (deals, projects, companies, contacts). The CLI surfaces the API error message verbatim so you know which links to resolve first.\r\n\r\n**Monorepo invocation:**\r\n\r\n```bash\r\npnpm -C packages/elevasis-operations exec elevasis-sdk client:delete <id>\r\n```\r\n\r\n**Tenant invocation:**\r\n\r\n```bash\r\npnpm exec elevasis-sdk client:delete <id>\r\n```\r\n\r\n**Key flags:**\r\n\r\n- `--pretty` -- render a human-readable confirmation instead of raw JSON\r\n- `--api-url <url>` -- override the API base URL (advanced; rarely needed)\r\n\r\n**Drill-down recipe:**\r\n\r\n1. Run `client:get <id> --pretty` to confirm which projects and deal links are attached before attempting deletion.\r\n2. Run `client:delete <id> --pretty`.\r\n3. If the API returns a 409, the error message lists the linked record counts (deals, projects, companies, contacts). Unlink or reassign those records first:\r\n   - Projects: `project:update <projectId> --clear-client` (or reassign with `--client <otherId>`)\r\n   - Deals: handled via the acquisition domain; no dedicated CLI command today\r\n4. Retry `client:delete <id> --pretty` once all links are resolved.\r\n5. Confirm deletion with `client:list --search "<name>"` -- the record should no longer appear.\r\n\r\n## Typical Workflow\r\n\r\nA common session combining read and write commands:\r\n\r\n1. `client:status --pretty` -- check org-wide distribution.\r\n2. `client:resolve "Acme"` -- get the Acme client ID.\r\n3. `client:get <id> --pretty` -- confirm lineage (deal, company, contact, projects).\r\n4. `project:update <projectId> --client <id>` -- link a project if missing.\r\n5. `client:get <id> --pretty` -- verify the linkage appears in the projects array.\r\n6. `client:create --name "New Corp" --status onboarding --pretty` -- provision a new client.\r\n7. `client:update <id> --status active --pretty` -- transition a client to active.\r\n8. `client:delete <id> --pretty` -- remove a client (API rejects with 409 if linked rows exist).',
+    "body": '## Overview\n\nThe `client:*` commands expose the clients hub through the SDK CLI. Use them to paginate clients, inspect individual client lineage, check org-wide status rollups, resolve a fuzzy name to a client ID, and mutate clients with create, update, and delete operations.\n\nAll examples below use the canonical monorepo invocation pattern. Tenant projects inside their own `operations/` directory drop the `-C packages/elevasis-operations` prefix and run `pnpm exec elevasis-sdk <cmd>` directly.\n\n## client:list\n\nLists clients for the authenticated organization with optional filtering and pagination.\n\n**Purpose:** Paginate all clients or narrow by status or search term to find the right client ID before drilling in with `client:get`.\n\n**Monorepo invocation:**\n\n```bash\npnpm -C packages/elevasis-operations exec elevasis-sdk client:list\n```\n\n**Tenant invocation (from inside `operations/`):**\n\n```bash\npnpm exec elevasis-sdk client:list\n```\n\n**Key flags:**\n\n- `--status <value>` -- filter by client status (e.g. `active`, `inactive`, `prospect`)\n- `--search <term>` -- full-text search against client name\n- `--limit <n>` -- maximum rows to return (default varies by server)\n- `--offset <n>` -- pagination offset\n- `--pretty` -- pretty-print JSON output\n\n**Drill-down recipe:**\n\n1. Run `client:list --pretty` to scan names and IDs.\n2. Use `--search` to narrow when the list is long.\n3. Copy the `id` from a row and pass it to `client:get <id>` for the full lineage payload (linked deal, primary company, primary contact, projects).\n\n## client:get\n\nFetches a single client record with its full lineage payload.\n\n**Purpose:** Inspect one client in detail -- its associated deal, primary company, primary contact, and linked projects. Use this to confirm linkage after wiring a project to a client via `project:update --client`.\n\n**Monorepo invocation:**\n\n```bash\npnpm -C packages/elevasis-operations exec elevasis-sdk client:get <clientId>\n```\n\n**Tenant invocation:**\n\n```bash\npnpm exec elevasis-sdk client:get <clientId>\n```\n\n**Key flags:**\n\n- `--pretty` -- pretty-print JSON output\n\n**Drill-down recipe:**\n\n1. Obtain `<clientId>` from `client:list` or `client:resolve`.\n2. Run `client:get <clientId> --pretty`.\n3. Check `projects` array to confirm which projects are linked.\n4. If `projects` is empty and a linkage was expected, run `project:update <projectId> --client <clientId>` to attach it.\n5. Re-run `client:get` to verify the lineage updated.\n\n## client:status\n\nReturns an org-wide rollup of client counts grouped by status.\n\n**Purpose:** High-level health check -- how many clients are active, how many are in each pipeline stage -- without enumerating every record.\n\n**Monorepo invocation:**\n\n```bash\npnpm -C packages/elevasis-operations exec elevasis-sdk client:status\n```\n\n**Tenant invocation:**\n\n```bash\npnpm exec elevasis-sdk client:status\n```\n\n**Key flags:**\n\n- `--pretty` -- pretty-print JSON output\n\n**Drill-down recipe:**\n\n1. Run `client:status --pretty` to see counts per status bucket.\n2. If a bucket looks unexpectedly large or small, run `client:list --status <value>` to enumerate the records in that bucket.\n3. Use `client:get <id>` on specific records to investigate lineage gaps.\n\n## client:resolve\n\nFuzzy-resolves a client name to a client ID.\n\n**Purpose:** Convert a partial or approximate name to the canonical UUID before passing `--client` to project commands. Mirrors `project:resolve` in shape.\n\n**Monorepo invocation:**\n\n```bash\npnpm -C packages/elevasis-operations exec elevasis-sdk client:resolve "<query>"\n```\n\n**Tenant invocation:**\n\n```bash\npnpm exec elevasis-sdk client:resolve "<query>"\n```\n\n**Key flags:**\n\nNone beyond the positional `<query>` argument. Output is the resolved client ID (or a ranked list if multiple matches exist).\n\n**Drill-down recipe:**\n\n1. Run `client:resolve "partial name"` -- the command returns the best-match client ID.\n2. Pass the returned ID to `project:create --client <id>`, `project:update --client <id>`, or `project:list --client <id>`.\n3. If multiple matches are returned, refine the query or use `client:list --search "<term>"` to inspect candidates before committing.\n\n## client:create\n\nCreates a new client record for the authenticated organization.\n\n**Purpose:** Provision a client directly from the CLI -- useful for scripted onboarding or bulk imports where no source deal exists yet. The only required field is `--name`; all relationship IDs are optional and can be set later via `client:update`.\n\n**Monorepo invocation:**\n\n```bash\npnpm -C packages/elevasis-operations exec elevasis-sdk client:create --name "Acme Corp"\n```\n\n**Tenant invocation (from inside `operations/`):**\n\n```bash\npnpm exec elevasis-sdk client:create --name "Acme Corp"\n```\n\n**Key flags:**\n\n- `--name <name>` -- (required) client display name\n- `--status <value>` -- initial status: `active` | `onboarding` | `paused` | `completed` | `churned`\n- `--source-deal-id <uuid>` -- UUID of the originating deal\n- `--primary-company-id <uuid>` -- UUID of the primary company record\n- `--primary-contact-id <uuid>` -- UUID of the primary contact record\n- `--metadata <json>` -- arbitrary metadata as a JSON string (e.g. `\'{"tier":"enterprise"}\'`)\n- `--pretty` -- render a human-readable summary instead of raw JSON\n\n**Drill-down recipe:**\n\n1. Run `client:create --name "Acme Corp" --status onboarding --pretty` to create and confirm the new record.\n2. Copy the `ID` from the pretty output (or `id` from raw JSON) for subsequent commands.\n3. Run `client:get <id> --pretty` to verify the full lineage payload was initialized correctly.\n4. If a source deal exists, pass `--source-deal-id <uuid>` at create time or backfill with `client:update <id> --source-deal-id <uuid>`.\n\n## client:update\n\nUpdates one or more fields on an existing client. Accepts a UUID or fuzzy name as the `\\<id\\>` argument.\n\n**Purpose:** Rename a client, change its status, swap or clear relationship IDs, or patch arbitrary metadata -- without leaving the CLI. The command enforces a client-side "at-least-one-field" guard and rejects mutually exclusive flag pairs before making any API call.\n\n**Monorepo invocation:**\n\n```bash\npnpm -C packages/elevasis-operations exec elevasis-sdk client:update <id> --status active\n```\n\n**Tenant invocation:**\n\n```bash\npnpm exec elevasis-sdk client:update <id> --status active\n```\n\n**Key flags:**\n\n- `--name <name>` -- new client display name\n- `--status <value>` -- new status: `active` | `onboarding` | `paused` | `completed` | `churned`\n- `--source-deal-id <uuid>` -- set or replace the source deal link\n- `--clear-source-deal` -- remove the source deal link (sets `sourceDealId` to null; mutually exclusive with `--source-deal-id`)\n- `--primary-company-id <uuid>` -- set or replace the primary company\n- `--clear-primary-company` -- remove the primary company link (mutually exclusive with `--primary-company-id`)\n- `--primary-contact-id <uuid>` -- set or replace the primary contact\n- `--clear-primary-contact` -- remove the primary contact link (mutually exclusive with `--primary-contact-id`)\n- `--metadata <json>` -- replace metadata with the provided JSON string\n- `--pretty` -- render a human-readable summary instead of raw JSON\n\n**Drill-down recipe:**\n\n1. Obtain `\\<id\\>` from `client:list`, `client:resolve`, or the output of `client:create`.\n2. Pass only the fields to change -- the command patches rather than replaces the record.\n3. To unlink a relationship (e.g. remove the source deal), use `--clear-source-deal` rather than omitting the flag; omitting leaves the existing value unchanged.\n4. After update, run `client:get <id> --pretty` to confirm all fields reflect the expected state.\n5. If the command exits with `CONFLICTING_FLAGS` on stderr, you passed both a set flag and its `--clear-*` counterpart -- remove one and retry.\n\n## client:delete\n\nDeletes a client record. Accepts a UUID or fuzzy name as the `\\<id\\>` argument.\n\n**Purpose:** Remove a client that was created in error or is no longer relevant. The API enforces a 409 Conflict when the client has linked rows (deals, projects, companies, contacts). The CLI surfaces the API error message verbatim so you know which links to resolve first.\n\n**Monorepo invocation:**\n\n```bash\npnpm -C packages/elevasis-operations exec elevasis-sdk client:delete <id>\n```\n\n**Tenant invocation:**\n\n```bash\npnpm exec elevasis-sdk client:delete <id>\n```\n\n**Key flags:**\n\n- `--pretty` -- render a human-readable confirmation instead of raw JSON\n- `--api-url <url>` -- override the API base URL (advanced; rarely needed)\n\n**Drill-down recipe:**\n\n1. Run `client:get <id> --pretty` to confirm which projects and deal links are attached before attempting deletion.\n2. Run `client:delete <id> --pretty`.\n3. If the API returns a 409, the error message lists the linked record counts (deals, projects, companies, contacts). Unlink or reassign those records first:\n   - Projects: `project:update <projectId> --clear-client` (or reassign with `--client <otherId>`)\n   - Deals: handled via the acquisition domain; no dedicated CLI command today\n4. Retry `client:delete <id> --pretty` once all links are resolved.\n5. Confirm deletion with `client:list --search "<name>"` -- the record should no longer appear.\n\n## Typical Workflow\n\nA common session combining read and write commands:\n\n1. `client:status --pretty` -- check org-wide distribution.\n2. `client:resolve "Acme"` -- get the Acme client ID.\n3. `client:get <id> --pretty` -- confirm lineage (deal, company, contact, projects).\n4. `project:update <projectId> --client <id>` -- link a project if missing.\n5. `client:get <id> --pretty` -- verify the linkage appears in the projects array.\n6. `client:create --name "New Corp" --status onboarding --pretty` -- provision a new client.\n7. `client:update <id> --status active --pretty` -- transition a client to active.\n8. `client:delete <id> --pretty` -- remove a client (API rejects with 409 if linked rows exist).',
     "links": [
       {
         "target": {
@@ -22703,7 +22651,7 @@ var mdxKnowledgeNodes = [
     "title": "YouTube OBS Recording Setup",
     "summary": "Canonical OBS Studio recording setup for Elevasis YouTube production, covering 1080p60 screen capture, safe recording format, NVENC quality settings, audio routing, face-camera scenes, and pre-recording checks.",
     "icon": "playbook",
-    "body": '## Overview\r\n\r\nUse this setup for Elevasis YouTube recordings that combine a short face-camera intro with Command Center or workflow screen capture. The target output is a clean 1080p60 source file that YouTube can re-encode without avoidable motion, audio, or color artifacts.\r\n\r\nBaseline configuration:\r\n\r\n```text\r\nVideo:   1920x1080, 60fps, NV12, Rec. 709 Partial\r\nEncode:  NVENC H.264, CQP 18, P5 preset, High profile\r\nFormat:  MKV with automatic remux to MP4\r\nAudio:   48 kHz stereo, 320 kbps AAC, mixed plus mic-only tracks\r\nCamera:  Insta360 Link 2C at 1080p60 with circle mask\r\nScenes:  Face + Screen on F5, Screen Only on F6\r\n```\r\n\r\nPrefer 1080p60 over 4K30 for screen recordings. Smooth cursor motion, scrolling, typing, and app transitions matter more than pixel density, and most viewers watch at 1080p or below. 4K30 produces larger files, slower editing, and visibly choppier screen motion.\r\n\r\n## Recording Output\r\n\r\nRecord to MKV, not MP4. MKV writes continuously, so a crash usually leaves the file usable. MP4 writes its index at the end, so a crash can corrupt the recording.\r\n\r\nEnable automatic remux:\r\n\r\n```text\r\nSettings > Advanced > Recording > Automatically remux to mp4\r\n```\r\n\r\nAfter each recording, upload the remuxed MP4 and keep the MKV as the backup.\r\n\r\nUse the advanced recording output mode:\r\n\r\n```text\r\nSettings > Output > Output Mode: Advanced\r\nRecording Tab:\r\n  Type:                  Standard\r\n  Recording Format:      mkv\r\n  Encoder:               NVIDIA NVENC H.264\r\n  Rate Control:          CQP\r\n  CQ Level:              18\r\n  Keyframe Interval:     2\r\n  Preset:                P5 (Slow)\r\n  Profile:               high\r\n  Look-ahead:            checked\r\n  Psycho Visual Tuning:  checked\r\n  Max B-frames:          2\r\n```\r\n\r\nCQP 18 is the stable quality target for screen content. It is visually lossless for this use case and gives YouTube a high-quality source before its VP9 or AV1 re-encode.\r\n\r\nFallback encoders:\r\n\r\n- AMD GPU: use AMD HW H.264 (AMF) with equivalent CQP settings.\r\n- No dedicated GPU: use x264, CRF 18, CPU preset `slow`, or `medium` if the CPU struggles.\r\n\r\nSet audio bitrates:\r\n\r\n```text\r\nOutput > Advanced > Audio:\r\n  Track 1: 320 kbps\r\n  Track 2: 320 kbps\r\n```\r\n\r\n## Video Settings\r\n\r\nUse a 1080p canvas and output:\r\n\r\n```text\r\nSettings > Video:\r\n  Base (Canvas) Resolution:    1920x1080\r\n  Output (Scaled) Resolution:  1920x1080\r\n  Downscale Filter:            Lanczos (36 samples)\r\n  Common FPS Values:           60\r\n```\r\n\r\nUse Rec. 709 limited-range color:\r\n\r\n```text\r\nSettings > Advanced:\r\n  Color Format: NV12\r\n  Color Space:  709\r\n  Color Range:  Partial\r\n```\r\n\r\nYouTube expects Rec. 709 limited range. Full range can produce washed-out or overly contrasty results after processing.\r\n\r\nFor a 3440x1440 ultrawide monitor, crop the display capture to the center 16:9 region before it is downscaled:\r\n\r\n1. Add Display Capture for the primary monitor.\r\n2. Right-click the source and open `Transform > Edit Transform`.\r\n3. Set `Crop Left` to `440` and `Crop Right` to `440`.\r\n4. Right-click the source again and select `Transform > Fit to Screen`.\r\n\r\nThis crops the capture to the center 2560x1440 region. Keep recorded windows inside that center area. A Windows 11 FancyZones center 16:9 zone is useful for keeping Command Center, browser, and terminal windows inside the captured area.\r\n\r\nUse Window Capture only when the recording is limited to one browser window. Display Capture is better for tutorials that switch windows, show the taskbar, or tile terminal and browser views.\r\n\r\n## Audio Settings\r\n\r\nGlobal audio settings:\r\n\r\n```text\r\nSettings > Audio:\r\n  Sample Rate:           48 kHz\r\n  Channels:              Stereo\r\n  Desktop Audio:         Default\r\n  Mic/Auxiliary Audio:   Focusrite USB Audio (Scarlett 2i2)\r\n```\r\n\r\nSet the Focusrite input in Windows before recording:\r\n\r\n1. Open Windows Sound Settings.\r\n2. Select the Focusrite USB Audio input.\r\n3. Set format to 48000 Hz, 24-bit.\r\n\r\nPhysical Focusrite setup:\r\n\r\n- Turn 48V phantom power on for the Lewitt LCT 240 PRO condenser.\r\n- Start input gain at 12 o\'clock and adjust so peaks land around -12 dB.\r\n- Keep Direct Monitor off to avoid double-monitoring.\r\n\r\nApply OBS mic filters to the Mic/Aux source in this exact order:\r\n\r\n| Order | Filter            | Settings                                                                 |\r\n| ----- | ----------------- | ------------------------------------------------------------------------ |\r\n| 1     | Noise Suppression | RNNoise                                                                  |\r\n| 2     | Noise Gate        | Close -40 dB, Open -35 dB, Attack 10 ms, Hold 200 ms, Release 100 ms     |\r\n| 3     | Compressor        | Ratio 3:1, Threshold -18 dB, Attack 6 ms, Release 60 ms, Output Gain 6 dB |\r\n| 4     | Limiter           | Threshold -3 dB, Release 60 ms                                           |\r\n\r\nThis order removes steady noise first, gates silence-period noise second, evens speech dynamics third, and catches peaks last. Do not add a Gain filter unless the signal is still too quiet after setting the Scarlett gain.\r\n\r\n## Multi-Track Audio\r\n\r\nRecord mixed audio and isolated mic audio:\r\n\r\n```text\r\nSettings > Output > Advanced > Recording Tab:\r\n  Audio Track: check 1 and 2\r\n```\r\n\r\nRoute tracks in `Audio Mixer > Advanced Audio Properties`:\r\n\r\n| Source        | Track 1 | Track 2 |\r\n| ------------- | ------- | ------- |\r\n| Desktop Audio | checked | empty   |\r\n| Mic/Aux       | checked | checked |\r\n\r\nTrack 1 is YouTube-ready mixed audio. Track 2 is mic-only audio for cleanup or editing.\r\n\r\n## Scene Setup\r\n\r\nCreate two scenes.\r\n\r\n### Face + Screen\r\n\r\nUse this scene for the intro and occasional commentary call-ins.\r\n\r\nSources from bottom to top:\r\n\r\n1. Display Capture named `Screen`.\r\n2. Video Capture Device named `Facecam`.\r\n3. Optional image source for a circle border or glow.\r\n\r\nDisplay Capture settings:\r\n\r\n```text\r\nSource:          Display Capture\r\nDisplay:         Primary monitor\r\nCapture Method:  Windows 10 (1903 and later)\r\nCapture Cursor:  checked\r\n```\r\n\r\nApply the ultrawide crop to this source when recording from the 3440x1440 monitor.\r\n\r\nFacecam settings:\r\n\r\n```text\r\nDevice:        Insta360 Link 2C\r\nResolution:    1920x1080\r\nFPS:           60\r\nVideo Format:  MJPEG or default\r\n```\r\n\r\nCreate a 512x512 PNG with a white circle on a black background and store it permanently, for example:\r\n\r\n```text\r\nE:\\OBS\\circle-mask.png\r\n```\r\n\r\nApply it to the Facecam source:\r\n\r\n```text\r\nFilters > Image Mask/Blend:\r\n  Type: Alpha Mask (Colour Channel)\r\n  Path: E:\\OBS\\circle-mask.png\r\n```\r\n\r\nResize the facecam source to roughly 300-400 px diameter and place it in a lower corner.\r\n\r\n### Screen Only\r\n\r\nUse this scene for the main tutorial content.\r\n\r\nAdd the existing `Screen` source from the Face + Screen scene. Do not duplicate the display capture source.\r\n\r\nHotkeys:\r\n\r\n```text\r\nSettings > Hotkeys:\r\n  Switch to Scene "Face + Screen": F5\r\n  Switch to Scene "Screen Only":   F6\r\n  Start Recording:                 Ctrl+F9\r\n  Stop Recording:                  Ctrl+F10\r\n```\r\n\r\nAvoid hotkeys that collide with the app being recorded. If using F5 inside a browser-heavy recording, choose a different key because F5 refreshes the page.\r\n\r\nRecording flow:\r\n\r\n1. Start on `Face + Screen`.\r\n2. Press `Ctrl+F9`.\r\n3. Record a 15-30 second face-camera intro.\r\n4. Press `F6` for `Screen Only`.\r\n5. Record the screen walkthrough.\r\n6. Optionally press `F5` to bring face-camera back for commentary.\r\n7. Press `Ctrl+F10` to stop.\r\n\r\nFor a fade, set Scene Transitions to Fade with a 300 ms duration.\r\n\r\n## Windows 11 Checks\r\n\r\nBefore a recording session:\r\n\r\n- Disable Xbox Game Bar.\r\n- Leave GPU scheduling enabled.\r\n- Run OBS as Administrator if frame drops or black-screen capture occur.\r\n- Set OBS process priority to Above Normal if the recording drops frames.\r\n- Use the High Performance power plan during recording.\r\n\r\n## Upload Quality\r\n\r\nYouTube re-encodes every upload. The goal is to provide clean source material.\r\n\r\n- Do not upload at YouTube\'s minimum recommended bitrate.\r\n- Do not run the recording through HandBrake or another extra encode just to save space.\r\n- Upload the OBS-remuxed MP4 directly unless the video was edited.\r\n- If editing in DaVinci Resolve or Premiere, render H.264 at 50 Mbps CBR for 1080p60 or use the YouTube preset.\r\n\r\nThe OBS output should match YouTube\'s expected upload shape: MP4 container, H.264 video, AAC-LC audio, 48 kHz stereo, Rec. 709 limited range.\r\n\r\n## Pre-Recording Checklist\r\n\r\n- Scarlett 2i2 phantom power is on and voice peaks around -12 dB.\r\n- Correct OBS scene is selected, usually `Face + Screen`.\r\n- Insta360 Link Controller has AI tracking and HDR enabled when needed.\r\n- Door is closed, fan or AC is off, and the room is controlled.\r\n- OBS mic meter peaks in green or yellow, never red.\r\n- A 10-second test recording has been played back for audio, video quality, and facecam position.\r\n- The 12-minute warm-up from `knowledge.youtube-mental-prep` is complete when recording on camera.',
+    "body": '## Overview\n\nUse this setup for Elevasis YouTube recordings that combine a short face-camera intro with Command Center or workflow screen capture. The target output is a clean 1080p60 source file that YouTube can re-encode without avoidable motion, audio, or color artifacts.\n\nBaseline configuration:\n\n```text\nVideo:   1920x1080, 60fps, NV12, Rec. 709 Partial\nEncode:  NVENC H.264, CQP 18, P5 preset, High profile\nFormat:  MKV with automatic remux to MP4\nAudio:   48 kHz stereo, 320 kbps AAC, mixed plus mic-only tracks\nCamera:  Insta360 Link 2C at 1080p60 with circle mask\nScenes:  Face + Screen on F5, Screen Only on F6\n```\n\nPrefer 1080p60 over 4K30 for screen recordings. Smooth cursor motion, scrolling, typing, and app transitions matter more than pixel density, and most viewers watch at 1080p or below. 4K30 produces larger files, slower editing, and visibly choppier screen motion.\n\n## Recording Output\n\nRecord to MKV, not MP4. MKV writes continuously, so a crash usually leaves the file usable. MP4 writes its index at the end, so a crash can corrupt the recording.\n\nEnable automatic remux:\n\n```text\nSettings > Advanced > Recording > Automatically remux to mp4\n```\n\nAfter each recording, upload the remuxed MP4 and keep the MKV as the backup.\n\nUse the advanced recording output mode:\n\n```text\nSettings > Output > Output Mode: Advanced\nRecording Tab:\n  Type:                  Standard\n  Recording Format:      mkv\n  Encoder:               NVIDIA NVENC H.264\n  Rate Control:          CQP\n  CQ Level:              18\n  Keyframe Interval:     2\n  Preset:                P5 (Slow)\n  Profile:               high\n  Look-ahead:            checked\n  Psycho Visual Tuning:  checked\n  Max B-frames:          2\n```\n\nCQP 18 is the stable quality target for screen content. It is visually lossless for this use case and gives YouTube a high-quality source before its VP9 or AV1 re-encode.\n\nFallback encoders:\n\n- AMD GPU: use AMD HW H.264 (AMF) with equivalent CQP settings.\n- No dedicated GPU: use x264, CRF 18, CPU preset `slow`, or `medium` if the CPU struggles.\n\nSet audio bitrates:\n\n```text\nOutput > Advanced > Audio:\n  Track 1: 320 kbps\n  Track 2: 320 kbps\n```\n\n## Video Settings\n\nUse a 1080p canvas and output:\n\n```text\nSettings > Video:\n  Base (Canvas) Resolution:    1920x1080\n  Output (Scaled) Resolution:  1920x1080\n  Downscale Filter:            Lanczos (36 samples)\n  Common FPS Values:           60\n```\n\nUse Rec. 709 limited-range color:\n\n```text\nSettings > Advanced:\n  Color Format: NV12\n  Color Space:  709\n  Color Range:  Partial\n```\n\nYouTube expects Rec. 709 limited range. Full range can produce washed-out or overly contrasty results after processing.\n\nFor a 3440x1440 ultrawide monitor, crop the display capture to the center 16:9 region before it is downscaled:\n\n1. Add Display Capture for the primary monitor.\n2. Right-click the source and open `Transform > Edit Transform`.\n3. Set `Crop Left` to `440` and `Crop Right` to `440`.\n4. Right-click the source again and select `Transform > Fit to Screen`.\n\nThis crops the capture to the center 2560x1440 region. Keep recorded windows inside that center area. A Windows 11 FancyZones center 16:9 zone is useful for keeping Command Center, browser, and terminal windows inside the captured area.\n\nUse Window Capture only when the recording is limited to one browser window. Display Capture is better for tutorials that switch windows, show the taskbar, or tile terminal and browser views.\n\n## Audio Settings\n\nGlobal audio settings:\n\n```text\nSettings > Audio:\n  Sample Rate:           48 kHz\n  Channels:              Stereo\n  Desktop Audio:         Default\n  Mic/Auxiliary Audio:   Focusrite USB Audio (Scarlett 2i2)\n```\n\nSet the Focusrite input in Windows before recording:\n\n1. Open Windows Sound Settings.\n2. Select the Focusrite USB Audio input.\n3. Set format to 48000 Hz, 24-bit.\n\nPhysical Focusrite setup:\n\n- Turn 48V phantom power on for the Lewitt LCT 240 PRO condenser.\n- Start input gain at 12 o\'clock and adjust so peaks land around -12 dB.\n- Keep Direct Monitor off to avoid double-monitoring.\n\nApply OBS mic filters to the Mic/Aux source in this exact order:\n\n| Order | Filter            | Settings                                                                 |\n| ----- | ----------------- | ------------------------------------------------------------------------ |\n| 1     | Noise Suppression | RNNoise                                                                  |\n| 2     | Noise Gate        | Close -40 dB, Open -35 dB, Attack 10 ms, Hold 200 ms, Release 100 ms     |\n| 3     | Compressor        | Ratio 3:1, Threshold -18 dB, Attack 6 ms, Release 60 ms, Output Gain 6 dB |\n| 4     | Limiter           | Threshold -3 dB, Release 60 ms                                           |\n\nThis order removes steady noise first, gates silence-period noise second, evens speech dynamics third, and catches peaks last. Do not add a Gain filter unless the signal is still too quiet after setting the Scarlett gain.\n\n## Multi-Track Audio\n\nRecord mixed audio and isolated mic audio:\n\n```text\nSettings > Output > Advanced > Recording Tab:\n  Audio Track: check 1 and 2\n```\n\nRoute tracks in `Audio Mixer > Advanced Audio Properties`:\n\n| Source        | Track 1 | Track 2 |\n| ------------- | ------- | ------- |\n| Desktop Audio | checked | empty   |\n| Mic/Aux       | checked | checked |\n\nTrack 1 is YouTube-ready mixed audio. Track 2 is mic-only audio for cleanup or editing.\n\n## Scene Setup\n\nCreate two scenes.\n\n### Face + Screen\n\nUse this scene for the intro and occasional commentary call-ins.\n\nSources from bottom to top:\n\n1. Display Capture named `Screen`.\n2. Video Capture Device named `Facecam`.\n3. Optional image source for a circle border or glow.\n\nDisplay Capture settings:\n\n```text\nSource:          Display Capture\nDisplay:         Primary monitor\nCapture Method:  Windows 10 (1903 and later)\nCapture Cursor:  checked\n```\n\nApply the ultrawide crop to this source when recording from the 3440x1440 monitor.\n\nFacecam settings:\n\n```text\nDevice:        Insta360 Link 2C\nResolution:    1920x1080\nFPS:           60\nVideo Format:  MJPEG or default\n```\n\nCreate a 512x512 PNG with a white circle on a black background and store it permanently, for example:\n\n```text\nE:\\OBS\\circle-mask.png\n```\n\nApply it to the Facecam source:\n\n```text\nFilters > Image Mask/Blend:\n  Type: Alpha Mask (Colour Channel)\n  Path: E:\\OBS\\circle-mask.png\n```\n\nResize the facecam source to roughly 300-400 px diameter and place it in a lower corner.\n\n### Screen Only\n\nUse this scene for the main tutorial content.\n\nAdd the existing `Screen` source from the Face + Screen scene. Do not duplicate the display capture source.\n\nHotkeys:\n\n```text\nSettings > Hotkeys:\n  Switch to Scene "Face + Screen": F5\n  Switch to Scene "Screen Only":   F6\n  Start Recording:                 Ctrl+F9\n  Stop Recording:                  Ctrl+F10\n```\n\nAvoid hotkeys that collide with the app being recorded. If using F5 inside a browser-heavy recording, choose a different key because F5 refreshes the page.\n\nRecording flow:\n\n1. Start on `Face + Screen`.\n2. Press `Ctrl+F9`.\n3. Record a 15-30 second face-camera intro.\n4. Press `F6` for `Screen Only`.\n5. Record the screen walkthrough.\n6. Optionally press `F5` to bring face-camera back for commentary.\n7. Press `Ctrl+F10` to stop.\n\nFor a fade, set Scene Transitions to Fade with a 300 ms duration.\n\n## Windows 11 Checks\n\nBefore a recording session:\n\n- Disable Xbox Game Bar.\n- Leave GPU scheduling enabled.\n- Run OBS as Administrator if frame drops or black-screen capture occur.\n- Set OBS process priority to Above Normal if the recording drops frames.\n- Use the High Performance power plan during recording.\n\n## Upload Quality\n\nYouTube re-encodes every upload. The goal is to provide clean source material.\n\n- Do not upload at YouTube\'s minimum recommended bitrate.\n- Do not run the recording through HandBrake or another extra encode just to save space.\n- Upload the OBS-remuxed MP4 directly unless the video was edited.\n- If editing in DaVinci Resolve or Premiere, render H.264 at 50 Mbps CBR for 1080p60 or use the YouTube preset.\n\nThe OBS output should match YouTube\'s expected upload shape: MP4 container, H.264 video, AAC-LC audio, 48 kHz stereo, Rec. 709 limited range.\n\n## Pre-Recording Checklist\n\n- Scarlett 2i2 phantom power is on and voice peaks around -12 dB.\n- Correct OBS scene is selected, usually `Face + Screen`.\n- Insta360 Link Controller has AI tracking and HDR enabled when needed.\n- Door is closed, fan or AC is off, and the room is controlled.\n- OBS mic meter peaks in green or yellow, never red.\n- A 10-second test recording has been played back for audio, video quality, and facecam position.\n- The 12-minute warm-up from `knowledge.youtube-mental-prep` is complete when recording on camera.',
     "links": [
       {
         "target": {
@@ -22725,7 +22673,7 @@ var mdxKnowledgeNodes = [
     "title": "Finance Operations Playbook",
     "summary": "Operating playbook for Elevasis finance: Xero as the system of record, Stripe payment collection and payout reconciliation, invoicing and AR cadence, tax estimates, deductions, 1099s, and annual filing prep.",
     "icon": "playbook",
-    "body": "## Overview\r\n\r\nElevasis finance operations run through Xero, with Stripe handling payment collection. Xero is the single source of truth for financial records: business checking bank feeds, Stripe payouts, contractor payments, expenses, invoices, receivables, and year-end exports.\r\n\r\nThe finance loop has three connected parts:\r\n\r\n1. Invoicing captures client revenue through monthly retainers and Stripe Checkout.\r\n2. Accounting records and reconciles bank transactions, Stripe payouts, contractor payments, and operating expenses.\r\n3. Taxes use accurate Xero records for quarterly estimates, deductions, 1099s, and annual filing.\r\n\r\n## Accounting and Reconciliation\r\n\r\nReconcile bank transactions in Xero weekly. Match each bank feed entry to its real-world source before month end.\r\n\r\n- Stripe payouts should match against Stripe bank feed activity.\r\n- Contractor payments should match checking account transfers.\r\n- Software subscriptions such as Railway, Vercel, Supabase, WorkOS, and OpenAI should be categorized as operating expenses.\r\n- Unmatched or ambiguous transactions should be flagged for manual review before monthly close.\r\n\r\nMaintain the core chart of accounts around revenue, cost of sales, operating expenses, and owner draws. Revenue includes client retainers and one-time project fees. Cost of sales covers contractor labor directly tied to client work. Operating expenses cover SaaS tools, hosting, banking fees, and professional services. Owner draws track business distributions.\r\n\r\nConfigure Xero with the connected business checking account, the default tax rate for the business jurisdiction, and the correct financial year end in organization settings.\r\n\r\n## Invoicing and Accounts Receivable\r\n\r\nClient billing runs on a monthly retainer model. Create invoices in Xero at the start of each billing period, send them by Xero email or Stripe Checkout link, record payment after Stripe confirms checkout completion, and reconcile the Stripe payout in Xero.\r\n\r\nUse Xero repeating invoices for monthly retainers:\r\n\r\n- Frequency: monthly.\r\n- Start date: billing cycle start date.\r\n- Approval: automatic approval where the billing terms are stable.\r\n\r\nConfigure invoice reminders around the due date: a courtesy reminder 3 days before due date, an overdue notice 1 day after due date, and an escalation notice 7 days after due date.\r\n\r\nFor invoices more than 14 days overdue, contact the client directly through the active communication channel, pause active work pending payment confirmation, and resolve the balance before the next billing cycle.\r\n\r\n## Taxes\r\n\r\nTax work depends on accurate Xero records throughout the year. As a pass-through entity, Elevasis business income flows to the owner personal return, so quarterly estimates reduce underpayment risk and year-end exports should be clean enough for a CPA or tax preparer.\r\n\r\nQuarterly estimated payment targets:\r\n\r\n- Q1: April 15.\r\n- Q2: June 15.\r\n- Q3: September 15.\r\n- Q4: January 15 of the following year.\r\n\r\nEstimate payments as roughly 25-30% of net profit for the quarter and pay via IRS Direct Pay or EFTPS.\r\n\r\nTrack deductible expenses in Xero during the year: SaaS subscriptions, contractor payments, home office expenses where applicable, professional development, courses, and business banking fees. Keep digital receipts organized by year in the business records folder.\r\n\r\nIssue 1099-NEC forms to US-based contractors paid more than $600 in a calendar year. Collect a W-9 before first payment, track annual contractor totals in Xero, file 1099-NEC forms by January 31 of the following year, and file the 1096 summary with the IRS when required.\r\n\r\nAt year end, export the Xero profit and loss statement and balance sheet. Provide them to the CPA or tax preparer with issued 1099s, bank statements for the business year, mileage logs if applicable, and home office documentation if applicable.",
+    "body": "## Overview\n\nElevasis finance operations run through Xero, with Stripe handling payment collection. Xero is the single source of truth for financial records: business checking bank feeds, Stripe payouts, contractor payments, expenses, invoices, receivables, and year-end exports.\n\nThe finance loop has three connected parts:\n\n1. Invoicing captures client revenue through monthly retainers and Stripe Checkout.\n2. Accounting records and reconciles bank transactions, Stripe payouts, contractor payments, and operating expenses.\n3. Taxes use accurate Xero records for quarterly estimates, deductions, 1099s, and annual filing.\n\n## Accounting and Reconciliation\n\nReconcile bank transactions in Xero weekly. Match each bank feed entry to its real-world source before month end.\n\n- Stripe payouts should match against Stripe bank feed activity.\n- Contractor payments should match checking account transfers.\n- Software subscriptions such as Railway, Vercel, Supabase, WorkOS, and OpenAI should be categorized as operating expenses.\n- Unmatched or ambiguous transactions should be flagged for manual review before monthly close.\n\nMaintain the core chart of accounts around revenue, cost of sales, operating expenses, and owner draws. Revenue includes client retainers and one-time project fees. Cost of sales covers contractor labor directly tied to client work. Operating expenses cover SaaS tools, hosting, banking fees, and professional services. Owner draws track business distributions.\n\nConfigure Xero with the connected business checking account, the default tax rate for the business jurisdiction, and the correct financial year end in organization settings.\n\n## Invoicing and Accounts Receivable\n\nClient billing runs on a monthly retainer model. Create invoices in Xero at the start of each billing period, send them by Xero email or Stripe Checkout link, record payment after Stripe confirms checkout completion, and reconcile the Stripe payout in Xero.\n\nUse Xero repeating invoices for monthly retainers:\n\n- Frequency: monthly.\n- Start date: billing cycle start date.\n- Approval: automatic approval where the billing terms are stable.\n\nConfigure invoice reminders around the due date: a courtesy reminder 3 days before due date, an overdue notice 1 day after due date, and an escalation notice 7 days after due date.\n\nFor invoices more than 14 days overdue, contact the client directly through the active communication channel, pause active work pending payment confirmation, and resolve the balance before the next billing cycle.\n\n## Taxes\n\nTax work depends on accurate Xero records throughout the year. As a pass-through entity, Elevasis business income flows to the owner personal return, so quarterly estimates reduce underpayment risk and year-end exports should be clean enough for a CPA or tax preparer.\n\nQuarterly estimated payment targets:\n\n- Q1: April 15.\n- Q2: June 15.\n- Q3: September 15.\n- Q4: January 15 of the following year.\n\nEstimate payments as roughly 25-30% of net profit for the quarter and pay via IRS Direct Pay or EFTPS.\n\nTrack deductible expenses in Xero during the year: SaaS subscriptions, contractor payments, home office expenses where applicable, professional development, courses, and business banking fees. Keep digital receipts organized by year in the business records folder.\n\nIssue 1099-NEC forms to US-based contractors paid more than $600 in a calendar year. Collect a W-9 before first payment, track annual contractor totals in Xero, file 1099-NEC forms by January 31 of the following year, and file the 1096 summary with the IRS when required.\n\nAt year end, export the Xero profit and loss statement and balance sheet. Provide them to the CPA or tax preparer with issued 1099s, bank statements for the business year, mileage logs if applicable, and home office documentation if applicable.",
     "links": [
       {
         "target": {
@@ -22745,7 +22693,7 @@ var mdxKnowledgeNodes = [
     "title": "Organization Model Actions",
     "summary": "Actions are the invokable semantic layer of the Organization Model -- they map to resources, affect entities, bind to knowledge, and expose four invocation types.",
     "icon": "reference",
-    "body": "## Overview\r\n\r\nActions are the invokable semantic layer of the Organization Model. They declare what an organization can do: what resources implement them, which entities they affect, and how they can be called.\r\n\r\nActions are authored in the `OM.actions` domain map and projected as `action` graph nodes by `buildOrganizationGraph()`. Each action emits a `contains` edge from the organization root and optional `maps_to`, `affects`, and `triggers` edges based on its declared fields.\r\n\r\nSource schema: `packages/core/src/organization-model/domains/actions.ts`\r\n\r\n## What Actions Are\r\n\r\nAn action is a named, typed, invokable operation. It is not executable code -- it is a semantic declaration that says \"this operation exists, it can be called this way, it affects these business objects, and it is implemented by this resource.\"\r\n\r\nActions answer questions like:\r\n\r\n- What operations does the `sales.lead-gen` system expose?\r\n- Which workflow implements the `lead-gen.company.qualify` operation?\r\n- What entities does this action modify?\r\n- How can this action be invoked from the CLI, an API, or an MCP client?\r\n\r\n## ActionInvocation Kinds\r\n\r\nEach action can declare one or more invocations. An invocation describes how the action is called.\r\n\r\n| Kind               | Fields                                                     | Description                               |\r\n| ------------------ | ---------------------------------------------------------- | ----------------------------------------- |\r\n| `slash-command`    | `command` (must start with `/`), optional `toolFactory`    | Called from the CLI or agent tool surface |\r\n| `mcp-tool`         | `server`, `name`                                           | Exposed as an MCP tool on a named server  |\r\n| `api-endpoint`     | `method` (GET/POST/PATCH/DELETE), `path`, optional schemas | Called via HTTP API endpoint              |\r\n| `script-execution` | `resourceId`                                               | Executed by running a script resource     |\r\n\r\nMultiple invocations on one action mean the same semantic operation is reachable through multiple surfaces.\r\n\r\n## Scope\r\n\r\nActions are either global or domain-scoped.\r\n\r\n- **Global** (`scope: 'global'`): available across all systems.\r\n- **Domain-scoped** (`scope: { domain: '<modelId>' }`): associated with a specific OM domain such as `sales`.\r\n\r\nSystems reference actions through `ActionRef` entries on `system.actions[]`, with an `intent` of `exposes` (the system owns the action) or `consumes` (the system calls the action). This relationship emits a `uses` edge from the system to the action in the graph.\r\n\r\n## Affects and Knowledge Bindings\r\n\r\nActions can declare which entities they modify via the `affects` field (array of entity IDs). Each entry emits an `affects` edge from the action to the entity node.\r\n\r\nActions can also declare `knowledge` bindings (array of knowledge node IDs) that reference relevant reference material. These bindings are not graph edges; they associate documentation with the action for surfacing in the Knowledge Base.\r\n\r\n## Resource Mapping\r\n\r\nThe optional `resourceId` field links an action to its implementation resource. Setting `resourceId` emits a `maps_to` edge from the action node to the resource node. If the resource does not yet exist in `OM.resources`, the graph builder creates a stub resource node from the ID.\r\n\r\n## Lifecycle States\r\n\r\nActions follow a five-stage lifecycle: `draft`, `beta`, `active`, `deprecated`, `archived`. The default is `active`. Lifecycle state is authored on the action entry and is reflected in the graph node.",
+    "body": "## Overview\n\nActions are the invokable semantic layer of the Organization Model. They declare what an organization can do: what resources implement them, which entities they affect, and how they can be called.\n\nActions are authored in the `OM.actions` domain map and projected as `action` graph nodes by `buildOrganizationGraph()`. Each action emits a `contains` edge from the organization root and optional `maps_to`, `affects`, and `triggers` edges based on its declared fields.\n\nSource schema: `packages/core/src/organization-model/domains/actions.ts`\n\n## What Actions Are\n\nAn action is a named, typed, invokable operation. It is not executable code -- it is a semantic declaration that says \"this operation exists, it can be called this way, it affects these business objects, and it is implemented by this resource.\"\n\nActions answer questions like:\n\n- What operations does the `sales.lead-gen` system expose?\n- Which workflow implements the `lead-gen.company.qualify` operation?\n- What entities does this action modify?\n- How can this action be invoked from the CLI, an API, or an MCP client?\n\n## ActionInvocation Kinds\n\nEach action can declare one or more invocations. An invocation describes how the action is called.\n\n| Kind               | Fields                                                     | Description                               |\n| ------------------ | ---------------------------------------------------------- | ----------------------------------------- |\n| `slash-command`    | `command` (must start with `/`), optional `toolFactory`    | Called from the CLI or agent tool surface |\n| `mcp-tool`         | `server`, `name`                                           | Exposed as an MCP tool on a named server  |\n| `api-endpoint`     | `method` (GET/POST/PATCH/DELETE), `path`, optional schemas | Called via HTTP API endpoint              |\n| `script-execution` | `resourceId`                                               | Executed by running a script resource     |\n\nMultiple invocations on one action mean the same semantic operation is reachable through multiple surfaces.\n\n## Scope\n\nActions are either global or domain-scoped.\n\n- **Global** (`scope: 'global'`): available across all systems.\n- **Domain-scoped** (`scope: { domain: '<modelId>' }`): associated with a specific OM domain such as `sales`.\n\nSystems reference actions through `ActionRef` entries on `system.actions[]`, with an `intent` of `exposes` (the system owns the action) or `consumes` (the system calls the action). This relationship emits a `uses` edge from the system to the action in the graph.\n\n## Affects and Knowledge Bindings\n\nActions can declare which entities they modify via the `affects` field (array of entity IDs). Each entry emits an `affects` edge from the action to the entity node.\n\nActions can also declare `knowledge` bindings (array of knowledge node IDs) that reference relevant reference material. These bindings are not graph edges; they associate documentation with the action for surfacing in the Knowledge Base.\n\n## Resource Mapping\n\nThe optional `resourceId` field links an action to its implementation resource. Setting `resourceId` emits a `maps_to` edge from the action node to the resource node. If the resource does not yet exist in `OM.resources`, the graph builder creates a stub resource node from the ID.\n\n## Lifecycle States\n\nActions follow a five-stage lifecycle: `draft`, `beta`, `active`, `deprecated`, `archived`. The default is `active`. Lifecycle state is authored on the action entry and is reflected in the graph node.",
     "links": [
       {
         "target": {
@@ -22765,7 +22713,7 @@ var mdxKnowledgeNodes = [
     "title": "Organization Model Entities",
     "summary": "Entities model business objects owned by systems -- with table metadata, state catalogs, and typed entity links.",
     "icon": "reference",
-    "body": "## Overview\r\n\r\nEntities are the business objects of the Organization Model. Each entity is a named, typed object owned by a system -- it corresponds to a database table, optionally participates in a state catalog, and can declare typed relationships to other entities.\r\n\r\nEntities are authored in the `OM.entities` domain map and projected as `entity` graph nodes by `buildOrganizationGraph()`. Each entity emits a `contains` edge from its owning system node and optional `links` edges to related entities.\r\n\r\nSource schema: `packages/core/src/organization-model/domains/entities.ts`\r\n\r\n## What Entities Are\r\n\r\nAn entity declaration answers questions like:\r\n\r\n- What business objects does the `sales.crm` system own?\r\n- Which database table backs the `crm.deal` entity?\r\n- What states can a `leadgen.company` pass through?\r\n- How are `crm.deal` and `crm.contact` related?\r\n\r\nEntities are not executable. They are semantic declarations that describe the shape of business data: who owns it, where it lives, what states it can be in, and how it connects to other objects.\r\n\r\n## ownedBySystemId\r\n\r\nEvery entity must declare `ownedBySystemId` -- the ID of the system responsible for it. The graph builder emits a `contains` edge from `system:<ownedBySystemId>` to the entity node. An entity can only be owned by one system.\r\n\r\n## Table and Row Schema\r\n\r\nThe optional `table` field names the backing database table (e.g. `crm_deals`). The optional `rowSchema` field references a schema identifier that describes the row shape. These fields are informational references; they are not validated against the database at OM parse time.\r\n\r\n## stateCatalogId\r\n\r\nThe optional `stateCatalogId` field links the entity to a state catalog. The graph builder uses this to project event nodes for each state transition:\r\n\r\n- For `crm.pipeline`, the builder walks pipeline catalog records via the pipeline migration helper.\n- For `delivery.task`, the builder walks project task status catalog records via the project-status helper.\n- For `lead-gen.company` and `lead-gen.contact`, the builder walks the lead-gen stage catalog.\r\n- General status catalogs live in `System.ontology.catalogTypes`; direct `OM.statuses` reads are legacy.\n\r\nEach matching status or stage generates an `event` node with an `originates_from` edge pointing back to the entity.\r\n\r\n## Typed Entity Links\r\n\r\nThe `links` field declares typed relationships to other entities. Each link has:\r\n\r\n- `toEntity` -- the target entity ID.\r\n- `kind` -- one of `belongs-to`, `has-many`, `has-one`, or `many-to-many`.\r\n- `via` -- optional join key or junction table name.\r\n- `label` -- optional display label for the relationship.\r\n\r\nEach link emits a `links` edge from the entity node to the target entity node in the graph.\r\n\r\n## Example Entity Shape\r\n\r\nA `crm.deal` entity owned by `sales.crm`, backed by the `crm_deals` table, in the `crm.pipeline` state catalog, with a `has-many` link to `crm.contact` via the `deal_contacts` junction:\r\n\r\n- `id`: `crm.deal`\r\n- `ownedBySystemId`: `sales.crm`\r\n- `table`: `crm_deals`\r\n- `stateCatalogId`: `crm.pipeline`\r\n- `links`: `[{ toEntity: 'crm.contact', kind: 'has-many', via: 'deal_contacts' }]`",
+    "body": "## Overview\n\nEntities are the business objects of the Organization Model. Each entity is a named, typed object owned by a system -- it corresponds to a database table, optionally participates in a state catalog, and can declare typed relationships to other entities.\n\nEntities are authored in the `OM.entities` domain map and projected as `entity` graph nodes by `buildOrganizationGraph()`. Each entity emits a `contains` edge from its owning system node and optional `links` edges to related entities.\n\nSource schema: `packages/core/src/organization-model/domains/entities.ts`\n\n## What Entities Are\n\nAn entity declaration answers questions like:\n\n- What business objects does the `sales.crm` system own?\n- Which database table backs the `crm.deal` entity?\n- What states can a `leadgen.company` pass through?\n- How are `crm.deal` and `crm.contact` related?\n\nEntities are not executable. They are semantic declarations that describe the shape of business data: who owns it, where it lives, what states it can be in, and how it connects to other objects.\n\n## ownedBySystemId\n\nEvery entity must declare `ownedBySystemId` -- the ID of the system responsible for it. The graph builder emits a `contains` edge from `system:<ownedBySystemId>` to the entity node. An entity can only be owned by one system.\n\n## Table and Row Schema\n\nThe optional `table` field names the backing database table (e.g. `crm_deals`). The optional `rowSchema` field references a schema identifier that describes the row shape. These fields are informational references; they are not validated against the database at OM parse time.\n\n## stateCatalogId\n\nThe optional `stateCatalogId` field links the entity to a state catalog. The graph builder uses this to project event nodes for each state transition:\n\n- For `crm.pipeline`, the builder walks pipeline catalog records via the pipeline migration helper.\n- For `delivery.task`, the builder walks project task status catalog records via the project-status helper.\n- For `lead-gen.company` and `lead-gen.contact`, the builder walks the lead-gen stage catalog.\n- General status catalogs live in `System.ontology.catalogTypes`; direct `OM.statuses` reads are legacy.\n\nEach matching status or stage generates an `event` node with an `originates_from` edge pointing back to the entity.\n\n## Typed Entity Links\n\nThe `links` field declares typed relationships to other entities. Each link has:\n\n- `toEntity` -- the target entity ID.\n- `kind` -- one of `belongs-to`, `has-many`, `has-one`, or `many-to-many`.\n- `via` -- optional join key or junction table name.\n- `label` -- optional display label for the relationship.\n\nEach link emits a `links` edge from the entity node to the target entity node in the graph.\n\n## Example Entity Shape\n\nA `crm.deal` entity owned by `sales.crm`, backed by the `crm_deals` table, in the `crm.pipeline` state catalog, with a `has-many` link to `crm.contact` via the `deal_contacts` junction:\n\n- `id`: `crm.deal`\n- `ownedBySystemId`: `sales.crm`\n- `table`: `crm_deals`\n- `stateCatalogId`: `crm.pipeline`\n- `links`: `[{ toEntity: 'crm.contact', kind: 'has-many', via: 'deal_contacts' }]`",
     "links": [
       {
         "target": {
@@ -22785,7 +22733,7 @@ var mdxKnowledgeNodes = [
     "title": "Organization Model Events",
     "summary": "Events are projected signals -- the OM has no authored event domain. They emit from resources and originate from entity state catalogs.",
     "icon": "reference",
-    "body": "## Overview\r\n\r\nEvents are projected graph nodes. The Organization Model has no `OM.events` domain map that authors edit directly. Instead, events are derived by `buildOrganizationGraph()` from two sources: `EventEmissionDescriptor` entries on workflow and agent resources, and state catalog entries on entities.\r\n\r\nEvery event node carries a unique ID formed as `\\<ownerId\\>:\\<eventKey\\>`, a human-readable label, and an edge that connects it back to the node that produced it.\r\n\r\nProjection logic: `packages/core/src/organization-model/graph/build.ts`\r\n\r\n## Authored vs. Projected\r\n\r\nThe distinction matters because it determines where you change event data.\r\n\r\nEvents are **never** edited in a standalone events file. To change an event you must change its source:\r\n\r\n- To change a resource-emitted event, update the `emits` array on the workflow or agent entry in `OM.resources`.\r\n- To change an entity state-transition event, update the entity's `stateCatalogId` or the underlying ontology status/stage catalog on the owning System.\n\r\nThe graph builder projects these into `event` graph nodes automatically on the next call to `buildOrganizationGraph()`.\r\n\r\n## EventEmissionDescriptor on Resources\r\n\r\nWorkflow and agent resource entries can declare an `emits` array. Each element is an `EventEmissionDescriptor`:\r\n\r\n| Field           | Type            | Description                                                   |\r\n| --------------- | --------------- | ------------------------------------------------------------- |\r\n| `eventKey`      | `ModelIdSchema` | Short key scoped to the owner resource (e.g. `enrolled`)      |\r\n| `label`         | string          | Human-readable label for the event                            |\r\n| `payloadSchema` | `ModelIdSchema` | Optional reference to a schema that describes the payload     |\r\n| `lifecycle`     | lifecycle enum  | Optional: `draft`, `beta`, `active`, `deprecated`, `archived` |\r\n\r\nThe graph builder constructs the full `EventDescriptor` by combining `ownerId` (the resource ID), `ownerKind: 'resource'`, and the emission descriptor fields. The resulting event ID is `\\<resourceId\\>:\\<eventKey\\>`.\r\n\r\nAn `emits` edge is then projected from the resource node to the event node.\r\n\r\nOnly `workflow` and `agent` resource kinds support `emits`. `integration` and `script` resources do not.\r\n\r\n## originates_from Edges from Entity State Catalogs\r\n\r\nWhen an entity declares a `stateCatalogId`, the graph builder projects one event node per state transition available to that entity. These events use `ownerKind: 'entity'` and the resulting event ID is `\\<entityId\\>:\\<eventKey\\>`.\r\n\r\nA reversed `originates_from` edge is projected from the event node pointing back to the entity node. This edge direction is the opposite of `emits`: it signals that the event represents a state change that originates from the entity, not that the entity actively fires the event.\r\n\r\nThe builder resolves state catalogs as follows:\r\n\r\n- **General status catalogs**: status data lives in `System.ontology.catalogTypes`; direct `OM.statuses` reads are legacy.\n- **`crm.pipeline`**: walks pipeline catalog records via the pipeline migration helper.\n- **`delivery.task`**: walks project task status catalog records via the project-status helper.\n- **`lead-gen.company` and `lead-gen.contact`**: walks the `LEAD_GEN_STAGE_CATALOG` constant, filtering by entity type.\r\n\r\n## triggers Edges to Policies\r\n\r\nWhen a policy declares `trigger.kind: 'event'`, the graph builder looks up the projected event node by event ID and emits a `triggers` edge from the event node to the policy node. This edge is only emitted if the event node was already projected by the time the policy loop runs.\r\n\r\nPolicy triggers are the primary way events connect to downstream behavior. No `triggers` edge is emitted for events that no policy references.\r\n\r\n## EventDescriptor Full Shape\r\n\r\n`EventDescriptor` is the resolved type used internally by the graph builder. It extends `EventEmissionDescriptor` with identity fields:\r\n\r\n| Field           | Type                       | Description                                           |\r\n| --------------- | -------------------------- | ----------------------------------------------------- |\r\n| `id`            | `EventIdSchema`            | Composite: `\\<ownerId\\>:\\<eventKey\\>`                 |\r\n| `ownerId`       | resource ID or model ID    | ID of the resource or entity that is the event source |\r\n| `ownerKind`     | `'resource'` or `'entity'` | Discriminates between the two projection paths        |\r\n| `eventKey`      | `ModelIdSchema`            | Short key, unique within the owner                    |\r\n| `label`         | string                     | Human-readable label                                  |\r\n| `payloadSchema` | `ModelIdSchema` (opt)      | Schema reference for payload shape                    |\r\n| `lifecycle`     | lifecycle enum (opt)       | Lifecycle state from the emission descriptor          |\r\n\r\n`EventDescriptor` is not stored in the graph node itself -- it is used transiently during graph construction to build the node and emit edges. The graph node stores `id`, `kind: 'event'`, `label`, and `sourceId`.\r\n\r\n## Graph Summary\r\n\r\n| Edge kind         | Direction                   | When emitted                                 |\r\n| ----------------- | --------------------------- | -------------------------------------------- |\r\n| `emits`           | resource node -> event node | Resource `emits[]` array is non-empty        |\r\n| `originates_from` | event node -> entity node   | Entity has a `stateCatalogId`                |\r\n| `triggers`        | event node -> policy node   | Policy `trigger.kind === 'event'` matches ID |",
+    "body": "## Overview\n\nEvents are projected graph nodes. The Organization Model has no `OM.events` domain map that authors edit directly. Instead, events are derived by `buildOrganizationGraph()` from two sources: `EventEmissionDescriptor` entries on workflow and agent resources, and state catalog entries on entities.\n\nEvery event node carries a unique ID formed as `\\<ownerId\\>:\\<eventKey\\>`, a human-readable label, and an edge that connects it back to the node that produced it.\n\nProjection logic: `packages/core/src/organization-model/graph/build.ts`\n\n## Authored vs. Projected\n\nThe distinction matters because it determines where you change event data.\n\nEvents are **never** edited in a standalone events file. To change an event you must change its source:\n\n- To change a resource-emitted event, update the `emits` array on the workflow or agent entry in `OM.resources`.\n- To change an entity state-transition event, update the entity's `stateCatalogId` or the underlying ontology status/stage catalog on the owning System.\n\nThe graph builder projects these into `event` graph nodes automatically on the next call to `buildOrganizationGraph()`.\n\n## EventEmissionDescriptor on Resources\n\nWorkflow and agent resource entries can declare an `emits` array. Each element is an `EventEmissionDescriptor`:\n\n| Field           | Type            | Description                                                   |\n| --------------- | --------------- | ------------------------------------------------------------- |\n| `eventKey`      | `ModelIdSchema` | Short key scoped to the owner resource (e.g. `enrolled`)      |\n| `label`         | string          | Human-readable label for the event                            |\n| `payloadSchema` | `ModelIdSchema` | Optional reference to a schema that describes the payload     |\n| `lifecycle`     | lifecycle enum  | Optional: `draft`, `beta`, `active`, `deprecated`, `archived` |\n\nThe graph builder constructs the full `EventDescriptor` by combining `ownerId` (the resource ID), `ownerKind: 'resource'`, and the emission descriptor fields. The resulting event ID is `\\<resourceId\\>:\\<eventKey\\>`.\n\nAn `emits` edge is then projected from the resource node to the event node.\n\nOnly `workflow` and `agent` resource kinds support `emits`. `integration` and `script` resources do not.\n\n## originates_from Edges from Entity State Catalogs\n\nWhen an entity declares a `stateCatalogId`, the graph builder projects one event node per state transition available to that entity. These events use `ownerKind: 'entity'` and the resulting event ID is `\\<entityId\\>:\\<eventKey\\>`.\n\nA reversed `originates_from` edge is projected from the event node pointing back to the entity node. This edge direction is the opposite of `emits`: it signals that the event represents a state change that originates from the entity, not that the entity actively fires the event.\n\nThe builder resolves state catalogs as follows:\n\n- **General status catalogs**: status data lives in `System.ontology.catalogTypes`; direct `OM.statuses` reads are legacy.\n- **`crm.pipeline`**: walks pipeline catalog records via the pipeline migration helper.\n- **`delivery.task`**: walks project task status catalog records via the project-status helper.\n- **`lead-gen.company` and `lead-gen.contact`**: walks the `LEAD_GEN_STAGE_CATALOG` constant, filtering by entity type.\n\n## triggers Edges to Policies\n\nWhen a policy declares `trigger.kind: 'event'`, the graph builder looks up the projected event node by event ID and emits a `triggers` edge from the event node to the policy node. This edge is only emitted if the event node was already projected by the time the policy loop runs.\n\nPolicy triggers are the primary way events connect to downstream behavior. No `triggers` edge is emitted for events that no policy references.\n\n## EventDescriptor Full Shape\n\n`EventDescriptor` is the resolved type used internally by the graph builder. It extends `EventEmissionDescriptor` with identity fields:\n\n| Field           | Type                       | Description                                           |\n| --------------- | -------------------------- | ----------------------------------------------------- |\n| `id`            | `EventIdSchema`            | Composite: `\\<ownerId\\>:\\<eventKey\\>`                 |\n| `ownerId`       | resource ID or model ID    | ID of the resource or entity that is the event source |\n| `ownerKind`     | `'resource'` or `'entity'` | Discriminates between the two projection paths        |\n| `eventKey`      | `ModelIdSchema`            | Short key, unique within the owner                    |\n| `label`         | string                     | Human-readable label                                  |\n| `payloadSchema` | `ModelIdSchema` (opt)      | Schema reference for payload shape                    |\n| `lifecycle`     | lifecycle enum (opt)       | Lifecycle state from the emission descriptor          |\n\n`EventDescriptor` is not stored in the graph node itself -- it is used transiently during graph construction to build the node and emit edges. The graph node stores `id`, `kind: 'event'`, `label`, and `sourceId`.\n\n## Graph Summary\n\n| Edge kind         | Direction                   | When emitted                                 |\n| ----------------- | --------------------------- | -------------------------------------------- |\n| `emits`           | resource node -> event node | Resource `emits[]` array is non-empty        |\n| `originates_from` | event node -> entity node   | Entity has a `stateCatalogId`                |\n| `triggers`        | event node -> policy node   | Policy `trigger.kind === 'event'` matches ID |",
     "links": [
       {
         "target": {
@@ -22805,7 +22753,7 @@ var mdxKnowledgeNodes = [
     "title": "Organization Model Graph Contract",
     "summary": "The canonical graph node and edge contract -- authored and projected node kinds, edge kinds, and the resource-type overlay derived from the Organization Model.",
     "icon": "reference",
-    "body": "## Overview\r\n\r\nThe Organization Model graph contract defines the typed node and edge taxonomy emitted by `buildOrganizationGraph()`. Every surface that reads or visualizes the OM -- including Command View -- works against this contract.\r\n\r\nThe graph has two categories of nodes: **authored** nodes derived directly from OM domain maps, and **projected** nodes derived by the graph builder from authored content. Events and stages are projected; all other node kinds are authored.\r\n\r\nSource schema: `packages/core/src/organization-model/graph/schema.ts`\r\nProjection logic: `packages/core/src/organization-model/graph/build.ts`\r\n\r\n## Node Kinds\r\n\r\nThe graph vocabulary includes authored semantic nodes and projected operational/navigation nodes.\r\n\r\n| Kind           | Authored / Projected | Source                                                  |\r\n| -------------- | -------------------- | ------------------------------------------------------- |\r\n| `organization` | Projected            | Root node; always present; id is `organization-model`   |\r\n| `system`       | Authored             | `OM.systems` domain map                                 |\r\n| `role`         | Authored             | `OM.roles` domain map                                   |\r\n| `action`       | Authored             | `OM.actions` domain map                                 |\r\n| `entity`       | Authored             | `OM.entities` domain map                                |\r\n| `event`        | Projected            | Derived from resource `emits` and entity state catalogs |\r\n| `policy`       | Authored             | `OM.policies` domain map                                |\r\n| `stage`        | Projected            | Derived from ontology-backed stage catalog helpers |\n| `resource`     | Authored             | `OM.resources` domain map                               |\r\n| `knowledge`    | Authored             | `OM.knowledge` id-keyed map                             |\r\n| `customer-segment` | Authored         | `OM.customers` domain map                               |\r\n| `offering`     | Authored             | `OM.offerings` domain map                               |\r\n| `goal`         | Authored             | `OM.goals` domain map                                   |\r\n| `surface`      | Projected            | Routeable leaves from `OM.navigation.sidebar`           |\r\n| `navigation-group` | Projected        | Groups from `OM.navigation.sidebar`                     |\r\n\r\n## Edge Kinds\r\n\r\nTwelve edge kinds are valid in the graph.\r\n\r\n| Kind              | Direction                             | Meaning                                                       |\r\n| ----------------- | ------------------------------------- | ------------------------------------------------------------- |\r\n| `contains`        | parent -> child                       | Containment: organization to system, system to resource, etc. |\r\n| `references`      | source -> target                      | Cross-reference: role reports-to, agent invokes action        |\r\n| `maps_to`         | action -> resource                    | Action is implemented by a resource                           |\r\n| `uses`            | system -> action, stage -> action     | System or stage uses an action                                |\r\n| `governs`         | knowledge -> target, role -> system   | Knowledge node or role governs a target                       |\r\n| `links`           | entity -> entity                      | Typed entity relationship (belongs-to, has-many, etc.)        |\r\n| `affects`         | action -> entity                      | Action modifies or reads an entity                            |\r\n| `emits`           | resource -> event                     | Resource produces an observable event                         |\r\n| `originates_from` | event -> entity                       | Event originates from an entity state transition              |\r\n| `triggers`        | event -> policy, action -> policy     | Event or action invocation triggers a policy evaluation       |\r\n| `applies_to`      | policy -> system/action/resource/role | Policy governs the target                                     |\r\n| `effects`         | policy -> action/role                 | Policy effect invokes an action or notifies a role            |\r\n\r\n## Resource Type Overlay\r\n\r\nResource nodes carry an optional `resourceType` field that is a separate enum from `kind`. It is set by the graph builder from the OM resource `kind` field or from Command View data.\r\n\r\n| Value              | Description                       |\r\n| ------------------ | --------------------------------- |\r\n| `workflow`         | Deterministic automation pipeline |\r\n| `agent`            | LLM-driven reasoning resource     |\r\n| `trigger`          | Event-driven entry point          |\r\n| `integration`      | External service connector        |\r\n| `external`         | Third-party system reference      |\r\n| `human_checkpoint` | Human-in-the-loop review gate     |\r\n| `script`           | One-shot executable script        |\r\n\r\n## Authored vs. Projected Fields\r\n\r\n### Authored nodes\r\n\r\nSystem, role, action, entity, policy, resource, knowledge, customer-segment, offering, and goal nodes are authored in the OM domain maps. Ontology catalog nodes are authored inside `System.ontology.catalogTypes` and projected with ontology graph IDs. Their `id`, `label`, `description`, and domain-specific fields are set from OM source data.\n\r\n### Projected nodes\r\n\r\n- **Organization node**: always present; `id` is always `organization-model`.\r\n- **Event nodes**: derived from two sources. Resource events come from `resource.emits` declarations on workflow and agent resources. Entity events come from the entity's `stateCatalogId` -- the builder walks compatible pipeline, project-status, or lead-gen stage helpers to generate one event node per transition.\r\n- **Stage nodes**: derived from ontology-backed prospecting and lead-gen stage helpers.\n- **Surface and navigation-group nodes**: derived from `navigation.sidebar`.\r\n\r\nProjected nodes are never authored directly. To add an event, declare `emits` on a resource or assign `stateCatalogId` to an entity.\r\n\r\n## Graph Node Shape\r\n\r\nEach node has: `id` (graph-unique string), `kind` (one of the 10 kinds), `label` (display name), optional `sourceId` (OM domain ID), optional `description`, optional `icon`, optional `enabled` flag, and optional `resourceType` (resource nodes only).\r\n\r\nEach edge has: `id` (graph-unique string), `kind` (one of the 12 kinds), `sourceId`, `targetId`, optional `label`, and optional `relationshipType` (`triggers`, `uses`, or `approval`).",
+    "body": "## Overview\n\nThe Organization Model graph contract defines the typed node and edge taxonomy emitted by `buildOrganizationGraph()`. Every surface that reads or visualizes the OM -- including Command View -- works against this contract.\n\nThe graph has two categories of nodes: **authored** nodes derived directly from OM domain maps, and **projected** nodes derived by the graph builder from authored content. Events and stages are projected; all other node kinds are authored.\n\nSource schema: `packages/core/src/organization-model/graph/schema.ts`\nProjection logic: `packages/core/src/organization-model/graph/build.ts`\n\n## Node Kinds\n\nThe graph vocabulary includes authored semantic nodes and projected operational/navigation nodes.\n\n| Kind           | Authored / Projected | Source                                                  |\n| -------------- | -------------------- | ------------------------------------------------------- |\n| `organization` | Projected            | Root node; always present; id is `organization-model`   |\n| `system`       | Authored             | `OM.systems` domain map                                 |\n| `role`         | Authored             | `OM.roles` domain map                                   |\n| `action`       | Authored             | `OM.actions` domain map                                 |\n| `entity`       | Authored             | `OM.entities` domain map                                |\n| `event`        | Projected            | Derived from resource `emits` and entity state catalogs |\n| `policy`       | Authored             | `OM.policies` domain map                                |\n| `stage`        | Projected            | Derived from ontology-backed stage catalog helpers |\n| `resource`     | Authored             | `OM.resources` domain map                               |\n| `knowledge`    | Authored             | `OM.knowledge` id-keyed map                             |\n| `customer-segment` | Authored         | `OM.customers` domain map                               |\n| `offering`     | Authored             | `OM.offerings` domain map                               |\n| `goal`         | Authored             | `OM.goals` domain map                                   |\n| `surface`      | Projected            | Routeable leaves from `OM.navigation.sidebar`           |\n| `navigation-group` | Projected        | Groups from `OM.navigation.sidebar`                     |\n\n## Edge Kinds\n\nTwelve edge kinds are valid in the graph.\n\n| Kind              | Direction                             | Meaning                                                       |\n| ----------------- | ------------------------------------- | ------------------------------------------------------------- |\n| `contains`        | parent -> child                       | Containment: organization to system, system to resource, etc. |\n| `references`      | source -> target                      | Cross-reference: role reports-to, agent invokes action        |\n| `maps_to`         | action -> resource                    | Action is implemented by a resource                           |\n| `uses`            | system -> action, stage -> action     | System or stage uses an action                                |\n| `governs`         | knowledge -> target, role -> system   | Knowledge node or role governs a target                       |\n| `links`           | entity -> entity                      | Typed entity relationship (belongs-to, has-many, etc.)        |\n| `affects`         | action -> entity                      | Action modifies or reads an entity                            |\n| `emits`           | resource -> event                     | Resource produces an observable event                         |\n| `originates_from` | event -> entity                       | Event originates from an entity state transition              |\n| `triggers`        | event -> policy, action -> policy     | Event or action invocation triggers a policy evaluation       |\n| `applies_to`      | policy -> system/action/resource/role | Policy governs the target                                     |\n| `effects`         | policy -> action/role                 | Policy effect invokes an action or notifies a role            |\n\n## Resource Type Overlay\n\nResource nodes carry an optional `resourceType` field that is a separate enum from `kind`. It is set by the graph builder from the OM resource `kind` field or from Command View data.\n\n| Value              | Description                       |\n| ------------------ | --------------------------------- |\n| `workflow`         | Deterministic automation pipeline |\n| `agent`            | LLM-driven reasoning resource     |\n| `trigger`          | Event-driven entry point          |\n| `integration`      | External service connector        |\n| `external`         | Third-party system reference      |\n| `human_checkpoint` | Human-in-the-loop review gate     |\n| `script`           | One-shot executable script        |\n\n## Authored vs. Projected Fields\n\n### Authored nodes\n\nSystem, role, action, entity, policy, resource, knowledge, customer-segment, offering, and goal nodes are authored in the OM domain maps. Ontology catalog nodes are authored inside `System.ontology.catalogTypes` and projected with ontology graph IDs. Their `id`, `label`, `description`, and domain-specific fields are set from OM source data.\n\n### Projected nodes\n\n- **Organization node**: always present; `id` is always `organization-model`.\n- **Event nodes**: derived from two sources. Resource events come from `resource.emits` declarations on workflow and agent resources. Entity events come from the entity's `stateCatalogId` -- the builder walks compatible pipeline, project-status, or lead-gen stage helpers to generate one event node per transition.\n- **Stage nodes**: derived from ontology-backed prospecting and lead-gen stage helpers.\n- **Surface and navigation-group nodes**: derived from `navigation.sidebar`.\n\nProjected nodes are never authored directly. To add an event, declare `emits` on a resource or assign `stateCatalogId` to an entity.\n\n## Graph Node Shape\n\nEach node has: `id` (graph-unique string), `kind` (one of the 10 kinds), `label` (display name), optional `sourceId` (OM domain ID), optional `description`, optional `icon`, optional `enabled` flag, and optional `resourceType` (resource nodes only).\n\nEach edge has: `id` (graph-unique string), `kind` (one of the 12 kinds), `sourceId`, `targetId`, optional `label`, and optional `relationshipType` (`triggers`, `uses`, or `approval`).",
     "links": [
       {
         "target": {
@@ -22825,7 +22773,7 @@ var mdxKnowledgeNodes = [
     "title": "Organization Model Policies",
     "summary": "Policies govern systems, actions, resources, and roles -- with discriminated triggers, predicates, and effects.",
     "icon": "reference",
-    "body": "## Overview\r\n\r\nPolicies are cross-cutting governance rules in the Organization Model. They declare what should happen when a trigger fires, under what conditions, and with what effect. Policies are authored in the `OM.policies` domain map and projected as `policy` graph nodes by `buildOrganizationGraph()`.\r\n\r\nEvery policy emits a `contains` edge from the organization root and `applies_to` edges to each system, action, resource, or role it governs. When the trigger is event-based or action-based, an additional `triggers` edge connects the source node to the policy.\r\n\r\nSource schema: `packages/core/src/organization-model/domains/policies.ts`\r\n\r\n## PolicyTrigger\r\n\r\nThe trigger is a discriminated union on `kind` that defines what activates the policy.\r\n\r\n| Kind                | Required fields | Description                                               |\r\n| ------------------- | --------------- | --------------------------------------------------------- |\r\n| `event`             | `eventId`       | Fires when the referenced event is projected in the graph |\r\n| `action-invocation` | `actionId`      | Fires when the referenced action is invoked               |\r\n| `schedule`          | `cron`          | Fires on a cron schedule (max 120 chars)                  |\r\n| `manual`            | none            | Fires only when explicitly triggered by a user or process |\r\n\r\nFor `event` triggers, the graph builder looks up the projected event node by `eventId` and emits a `triggers` edge from that event node to the policy node. For `action-invocation` triggers, a `triggers` edge is emitted from the action node to the policy node. Schedule and manual triggers produce no additional graph edges.\r\n\r\n## PolicyPredicate\r\n\r\nThe predicate is a discriminated union on `kind` that defines the condition under which the policy effect is applied.\r\n\r\n| Kind         | Required fields                 | Description                                                |\r\n| ------------ | ------------------------------- | ---------------------------------------------------------- |\r\n| `always`     | none                            | Condition is unconditionally true; effect always fires     |\r\n| `expression` | `expression` (string, max 2000) | Arbitrary expression evaluated at runtime                  |\r\n| `threshold`  | `metric`, `operator`, `value`   | Numeric threshold check: `lt`, `lte`, `eq`, `gte`, or `gt` |\r\n\r\nThe default predicate if not specified is `{ kind: 'always' }`.\r\n\r\n## PolicyEffect\r\n\r\nThe `actions` field holds an ordered array of effects (`PolicyEffect[]`). At least one effect is required. Effects are a discriminated union on `kind`.\r\n\r\n| Kind               | Required fields     | Description                                                 |\r\n| ------------------ | ------------------- | ----------------------------------------------------------- |\r\n| `require-approval` | `roleId` (optional) | Blocks execution until a human approves; routes to the role |\r\n| `invoke-action`    | `actionId`          | Invokes the referenced action as a consequence              |\r\n| `notify-role`      | `roleId`            | Sends a notification to the specified role                  |\r\n| `block`            | none                | Stops execution entirely; no approval path                  |\r\n\r\nFor `invoke-action` effects, the graph builder emits an `effects` edge from the policy node to the referenced action node. For `notify-role` and `require-approval` effects that include a `roleId`, an `effects` edge is emitted from the policy node to the role node.\r\n\r\n## appliesTo\r\n\r\nThe `appliesTo` field declares which OM entities the policy governs. It contains four ID arrays, all defaulting to empty:\r\n\r\n| Field         | Target kind | Graph edge emitted                        |\r\n| ------------- | ----------- | ----------------------------------------- |\r\n| `systemIds`   | `system`    | `applies_to` from policy to system node   |\r\n| `actionIds`   | `action`    | `applies_to` from policy to action node   |\r\n| `resourceIds` | `resource`  | `applies_to` from policy to resource node |\r\n| `roleIds`     | `role`      | `applies_to` from policy to role node     |\r\n\r\nA policy can apply to any combination of these targets simultaneously. A policy with all four arrays empty is valid but produces no `applies_to` edges.\r\n\r\n## Lifecycle\r\n\r\nPolicies follow the same five-stage lifecycle as systems and actions: `draft`, `beta`, `active`, `deprecated`, `archived`. The default is `active`. Lifecycle is authored on the policy entry and is reflected in the graph node.\r\n\r\nThe `order` field controls domain-map iteration order. The convention is multiples of 10 (10, 20, 30, ...) to allow easy insertion between existing entries.\r\n\r\n## Graph Summary\r\n\r\n| Edge kind    | Direction                                  | When emitted                                                                       |\r\n| ------------ | ------------------------------------------ | ---------------------------------------------------------------------------------- |\r\n| `contains`   | organization root -> policy node           | Always; every policy is contained by the organization root                         |\r\n| `applies_to` | policy node -> system/action/resource/role | For each non-empty `appliesTo.*Ids` entry                                          |\r\n| `triggers`   | event or action node -> policy node        | When `trigger.kind` is `event` or `action-invocation`                              |\r\n| `effects`    | policy node -> action or role node         | For `invoke-action`, `notify-role`, and `require-approval` effects with a `roleId` |",
+    "body": "## Overview\n\nPolicies are cross-cutting governance rules in the Organization Model. They declare what should happen when a trigger fires, under what conditions, and with what effect. Policies are authored in the `OM.policies` domain map and projected as `policy` graph nodes by `buildOrganizationGraph()`.\n\nEvery policy emits a `contains` edge from the organization root and `applies_to` edges to each system, action, resource, or role it governs. When the trigger is event-based or action-based, an additional `triggers` edge connects the source node to the policy.\n\nSource schema: `packages/core/src/organization-model/domains/policies.ts`\n\n## PolicyTrigger\n\nThe trigger is a discriminated union on `kind` that defines what activates the policy.\n\n| Kind                | Required fields | Description                                               |\n| ------------------- | --------------- | --------------------------------------------------------- |\n| `event`             | `eventId`       | Fires when the referenced event is projected in the graph |\n| `action-invocation` | `actionId`      | Fires when the referenced action is invoked               |\n| `schedule`          | `cron`          | Fires on a cron schedule (max 120 chars)                  |\n| `manual`            | none            | Fires only when explicitly triggered by a user or process |\n\nFor `event` triggers, the graph builder looks up the projected event node by `eventId` and emits a `triggers` edge from that event node to the policy node. For `action-invocation` triggers, a `triggers` edge is emitted from the action node to the policy node. Schedule and manual triggers produce no additional graph edges.\n\n## PolicyPredicate\n\nThe predicate is a discriminated union on `kind` that defines the condition under which the policy effect is applied.\n\n| Kind         | Required fields                 | Description                                                |\n| ------------ | ------------------------------- | ---------------------------------------------------------- |\n| `always`     | none                            | Condition is unconditionally true; effect always fires     |\n| `expression` | `expression` (string, max 2000) | Arbitrary expression evaluated at runtime                  |\n| `threshold`  | `metric`, `operator`, `value`   | Numeric threshold check: `lt`, `lte`, `eq`, `gte`, or `gt` |\n\nThe default predicate if not specified is `{ kind: 'always' }`.\n\n## PolicyEffect\n\nThe `actions` field holds an ordered array of effects (`PolicyEffect[]`). At least one effect is required. Effects are a discriminated union on `kind`.\n\n| Kind               | Required fields     | Description                                                 |\n| ------------------ | ------------------- | ----------------------------------------------------------- |\n| `require-approval` | `roleId` (optional) | Blocks execution until a human approves; routes to the role |\n| `invoke-action`    | `actionId`          | Invokes the referenced action as a consequence              |\n| `notify-role`      | `roleId`            | Sends a notification to the specified role                  |\n| `block`            | none                | Stops execution entirely; no approval path                  |\n\nFor `invoke-action` effects, the graph builder emits an `effects` edge from the policy node to the referenced action node. For `notify-role` and `require-approval` effects that include a `roleId`, an `effects` edge is emitted from the policy node to the role node.\n\n## appliesTo\n\nThe `appliesTo` field declares which OM entities the policy governs. It contains four ID arrays, all defaulting to empty:\n\n| Field         | Target kind | Graph edge emitted                        |\n| ------------- | ----------- | ----------------------------------------- |\n| `systemIds`   | `system`    | `applies_to` from policy to system node   |\n| `actionIds`   | `action`    | `applies_to` from policy to action node   |\n| `resourceIds` | `resource`  | `applies_to` from policy to resource node |\n| `roleIds`     | `role`      | `applies_to` from policy to role node     |\n\nA policy can apply to any combination of these targets simultaneously. A policy with all four arrays empty is valid but produces no `applies_to` edges.\n\n## Lifecycle\n\nPolicies follow the same five-stage lifecycle as systems and actions: `draft`, `beta`, `active`, `deprecated`, `archived`. The default is `active`. Lifecycle is authored on the policy entry and is reflected in the graph node.\n\nThe `order` field controls domain-map iteration order. The convention is multiples of 10 (10, 20, 30, ...) to allow easy insertion between existing entries.\n\n## Graph Summary\n\n| Edge kind    | Direction                                  | When emitted                                                                       |\n| ------------ | ------------------------------------------ | ---------------------------------------------------------------------------------- |\n| `contains`   | organization root -> policy node           | Always; every policy is contained by the organization root                         |\n| `applies_to` | policy node -> system/action/resource/role | For each non-empty `appliesTo.*Ids` entry                                          |\n| `triggers`   | event or action node -> policy node        | When `trigger.kind` is `event` or `action-invocation`                              |\n| `effects`    | policy node -> action or role node         | For `invoke-action`, `notify-role`, and `require-approval` effects with a `roleId` |",
     "links": [
       {
         "target": {
@@ -22845,7 +22793,7 @@ var mdxKnowledgeNodes = [
     "title": "Platform Command View",
     "summary": "Reference for Command View, the visual Organization Model graph surface that projects systems, resources, actions, entities, events, and policies into an explorable operational view.",
     "icon": "reference",
-    "body": "## Overview\r\n\r\nCommand View is the visual surface for the Organization Model graph. It projects the OM -- systems, resources, actions, entities, events, and policies -- into an explorable graph using the same node and edge taxonomy emitted by `buildOrganizationGraph()`.\r\n\r\nIt answers operational questions such as:\r\n\r\n- What systems own which resources?\r\n- What does this agent map to in the OM?\r\n- Which actions affect which entities?\r\n- If a resource goes offline, what policies or actions reference it?\r\n- What events originate from this entity or resource?\r\n\r\nAccess Command View through the Knowledge area at `/knowledge/command-view`.\r\n\r\n## How Command View Works\r\n\r\nCommand View is a projection of the Organization Model graph, not a separate deployment manifest.\r\n\r\nThe OM `resources` domain is the single source of resource identity. The `actions` domain is the invokable semantic layer. The `systems` domain is the backbone. Command View merges the graph emitted by `buildOrganizationGraph()` with optional live Command View data (deployed resource metadata) to render a unified operational picture.\r\n\r\nGraph projection pipeline:\r\n\r\n1. Organization Model is authored in `packages/elevasis-core/src/organization-model/`.\r\n2. `buildOrganizationGraph()` projects the OM into typed nodes and edges.\r\n3. Command View data (deployed resource metadata) is optionally merged as an overlay.\r\n4. The merged graph is serialized and cached.\r\n5. The frontend visualizes the cached graph.\r\n\r\nCommand View does not own resource identity. It reads what the OM declares.\r\n\r\n## Node Kinds\r\n\r\nCommand View renders the same node kinds as the OM graph:\r\n\r\n| Kind           | Source         | Description                                                                |\r\n| -------------- | -------------- | -------------------------------------------------------------------------- |\r\n| `organization` | Root           | The organization-model root node                                           |\r\n| `system`       | `OM.systems`   | Bounded contexts with dotted IDs and parentSystemId hierarchy              |\r\n| `role`         | `OM.roles`     | Named roles with hierarchy and holder assignments                          |\r\n| `action`       | `OM.actions`   | Invokable operations with invocation type metadata                         |\r\n| `entity`       | `OM.entities`  | Business objects owned by systems                                          |\r\n| `event`        | Projected      | Derived from resource `emits` declarations and entity state catalogs       |\r\n| `policy`       | `OM.policies`  | Governance rules applied to systems, actions, resources, and roles         |\r\n| `stage`        | Projected      | Derived from prospecting stage catalogs                                    |\r\n| `resource`     | `OM.resources` | Workflows, agents, integrations, triggers, scripts, and external resources |\r\n| `knowledge`    | `OM.knowledge` | Knowledge nodes governed by systems                                        |\r\n\r\nThe `resourceType` overlay on resource nodes is a separate enum: `workflow`, `agent`, `trigger`, `integration`, `external`, `human_checkpoint`, `script`.\r\n\r\n## Edge Kinds\r\n\r\n| Kind              | Meaning                                                                        |\r\n| ----------------- | ------------------------------------------------------------------------------ |\r\n| `contains`        | Parent-to-child containment (organization to system, system to resource, etc.) |\r\n| `references`      | Cross-reference between nodes (role reports-to, agent invokes action)          |\r\n| `maps_to`         | Action mapped to a resource implementation                                     |\r\n| `uses`            | System or stage uses an action                                                 |\r\n| `governs`         | Knowledge node or role governs a system or target                              |\r\n| `links`           | Entity links to another entity                                                 |\r\n| `affects`         | Action affects an entity                                                       |\r\n| `emits`           | Resource or entity emits an event                                              |\r\n| `originates_from` | Event originates from an entity                                                |\r\n| `triggers`        | Event or action triggers a policy                                              |\r\n| `applies_to`      | Policy applies to a system, action, resource, or role                          |\r\n| `effects`         | Policy effect invokes an action or notifies a role                             |\r\n\r\n## Visualization Modes\r\n\r\nCommand View uses Cytoscape graph modes:\r\n\r\n- **Map:** preserves organization structure and honors hidden-resource visibility.\r\n- **Trace:** resolves directed paths and reveals resources for the active trace.\r\n- **Impact:** pivots around the selected node and reveals related resources for impact review.\r\n\r\nFilter panel:\r\n\r\n- Search across nodes, relationships, and IDs.\r\n- Filter by node kind, resource type, environment, topology presence, integrations, and resource facets.\r\n- Toggle resource visibility and diagnostic/testing resource visibility.\r\n- Show visible and hidden resource counts in the same control surface.\r\n\r\nHidden resource behavior:\r\n\r\n- Resource nodes are hidden by default so the organization structure remains readable.\r\n- Structural nodes remain visible as the navigation skeleton.\r\n- Selecting a visible node can reveal directly connected hidden resources.\r\n- Diagnostic and testing resources are hidden by default and can be revealed from the filter panel.\r\n\r\nExpand Around behavior:\r\n\r\n- Select a node, open Details, and use Expand Around to preview nearby graph context before revealing it.\r\n- Semantic presets cover coverage, operational dependencies, organization context, and impact paths.\r\n- System and entity nodes default to Coverage.\r\n- Resource nodes default to Operational Dependencies.\r\n- Preview counts show hidden resources before Apply reveals the graph patch.\r\n\r\nRead-only constraints:\r\n\r\n- No drag and drop.\r\n- No connection editing.\r\n- No graph mutation from the visualization layer.\r\n\r\n## Organization Model as the Source of Truth\r\n\r\nResource identity lives in `OM.resources`, not in a separate manifest. To add a resource to Command View:\r\n\r\n1. Add the resource to `OM.resources` in the organization model.\r\n2. Link it to a system via `systemPath`.\r\n3. Optionally link actions to the resource via `action.resourceId`.\r\n4. Deploy the organization model. Command View reflects the new resource automatically.\r\n\r\nThere is no separate `DeploymentSpec.relationships` declaration required for OM-declared resources. The graph builder derives containment and relationship edges directly from the OM contract.\r\n\r\nLive resource metadata (deployed name, description, runtime status) can be overlaid from Command View data when available, but the OM contract is primary.\r\n\r\n## Using Command View\r\n\r\n### System Understanding\r\n\r\nUseful exploration questions:\r\n\r\n- What systems own which resources and entities?\r\n- What actions does this system expose, and what do they map to?\r\n- Which knowledge nodes govern this system?\r\n- What policies apply to this system?\r\n- What events originate from this entity?\r\n- What roles are responsible for this system?\r\n\r\nVisual patterns:\r\n\r\n- Hub nodes with many edges indicate central resources or pivotal systems.\r\n- Linear chains show sequential workflow pipelines.\r\n- Branching shows conditional routing or multiple action paths.\r\n- Isolated nodes may indicate unused or draft resources.\r\n\r\n### Manifest Debugging\r\n\r\nUse Command View to verify:\r\n\r\n1. Resources appear as nodes under the correct system.\r\n2. Actions map to the expected resources.\r\n3. Entities link to the correct systems and each other.\r\n4. Policies apply to the correct systems, actions, or resources.\r\n5. Events appear for resources with `emits` declarations.\r\n6. Orphaned resources are intentional.\r\n\r\nCommon issues:\r\n\r\n- Resource declared in OM but assigned to the wrong `systemPath`.\r\n- Action `resourceId` points to a resource ID that does not exist.\r\n- Entity `ownedBySystemId` references an unknown system.\r\n- Policy `appliesTo` references a system, action, or resource that was removed.\r\n\r\n## Troubleshooting\r\n\r\n### Empty Graph\r\n\r\nLikely causes:\r\n\r\n- Organization has no systems or resources defined.\r\n- Search, node kind, or resource type filters hide all graph elements.\r\n- Command View resources are hidden and no structural nodes match current filters.\r\n\r\nCheck:\r\n\r\n1. OM `systems` and `resources` domains have entries.\r\n2. Filter panel visibility and filter state.\r\n3. API response for the `/api/command-view` endpoint.\r\n\r\nFix:\r\n\r\n- Add systems and resources to the organization model.\r\n- Reveal resources or reset graph filters.\r\n\r\n### Missing Nodes\r\n\r\nLikely causes:\r\n\r\n- Resource, action, or entity is defined in OM but omitted from the relevant domain map.\r\n- Node is hidden by visibility controls.\r\n- Status, resource type, or topology filters exclude the node.\r\n\r\nCheck:\r\n\r\n1. OM domain map includes the ID as a key and as `id` in the entry.\r\n2. Filter panel visibility and filter state.\r\n3. Node `lifecycle` or `enabled` field.\r\n\r\nFix by adding the entry to the correct domain map or revealing hidden nodes.\r\n\r\n### Missing Edges\r\n\r\nLikely causes:\r\n\r\n- Action `resourceId` does not match any OM resource ID.\r\n- Entity `ownedBySystemId` references an unknown system.\r\n- Policy `appliesTo` references IDs that do not exist.\r\n- Knowledge node link uses a nodeId that has no matching OM node.\r\n\r\nCheck:\r\n\r\n1. Cross-reference IDs across OM domains.\r\n2. Run `pnpm --filter @repo/core check-types` to surface Zod validation errors.\r\n\r\nFix the OM entry to reference the correct ID.\r\n\r\n## Best Practices\r\n\r\nKeep the OM up to date as systems and resources evolve:\r\n\r\n1. Add new resources to `OM.resources` with the correct `systemPath`.\r\n2. Map actions to resources via `action.resourceId` when the action calls a specific resource.\r\n3. Update `entity.ownedBySystemId` when entities move between systems.\r\n4. Update `policy.appliesTo` when systems, actions, or resources are renamed or removed.\r\n5. Declare `resource.emits` for workflows and agents that produce observable events.\r\n\r\nUse the OM graph as the authoritative reference for Command View structure. The graph builder derives the visualization from the OM contract -- do not expect Command View to show connections that are not declared in the OM.\r\n\r\n## Related References\r\n\r\n- `/knowledge read knowledge.org-model-reference`\r\n- `/knowledge read knowledge.platform-composition-patterns`\r\n- `/knowledge read knowledge.platform-integration-patterns`",
+    "body": "## Overview\n\nCommand View is the visual surface for the Organization Model graph. It projects the OM -- systems, resources, actions, entities, events, and policies -- into an explorable graph using the same node and edge taxonomy emitted by `buildOrganizationGraph()`.\n\nIt answers operational questions such as:\n\n- What systems own which resources?\n- What does this agent map to in the OM?\n- Which actions affect which entities?\n- If a resource goes offline, what policies or actions reference it?\n- What events originate from this entity or resource?\n\nAccess Command View through the Knowledge area at `/knowledge/command-view`.\n\n## How Command View Works\n\nCommand View is a projection of the Organization Model graph, not a separate deployment manifest.\n\nThe OM `resources` domain is the single source of resource identity. The `actions` domain is the invokable semantic layer. The `systems` domain is the backbone. Command View merges the graph emitted by `buildOrganizationGraph()` with optional live Command View data (deployed resource metadata) to render a unified operational picture.\n\nGraph projection pipeline:\n\n1. Organization Model is authored in `packages/elevasis-core/src/organization-model/`.\n2. `buildOrganizationGraph()` projects the OM into typed nodes and edges.\n3. Command View data (deployed resource metadata) is optionally merged as an overlay.\n4. The merged graph is serialized and cached.\n5. The frontend visualizes the cached graph.\n\nCommand View does not own resource identity. It reads what the OM declares.\n\n## Node Kinds\n\nCommand View renders the same node kinds as the OM graph:\n\n| Kind           | Source         | Description                                                                |\n| -------------- | -------------- | -------------------------------------------------------------------------- |\n| `organization` | Root           | The organization-model root node                                           |\n| `system`       | `OM.systems`   | Bounded contexts with dotted IDs and parentSystemId hierarchy              |\n| `role`         | `OM.roles`     | Named roles with hierarchy and holder assignments                          |\n| `action`       | `OM.actions`   | Invokable operations with invocation type metadata                         |\n| `entity`       | `OM.entities`  | Business objects owned by systems                                          |\n| `event`        | Projected      | Derived from resource `emits` declarations and entity state catalogs       |\n| `policy`       | `OM.policies`  | Governance rules applied to systems, actions, resources, and roles         |\n| `stage`        | Projected      | Derived from prospecting stage catalogs                                    |\n| `resource`     | `OM.resources` | Workflows, agents, integrations, triggers, scripts, and external resources |\n| `knowledge`    | `OM.knowledge` | Knowledge nodes governed by systems                                        |\n\nThe `resourceType` overlay on resource nodes is a separate enum: `workflow`, `agent`, `trigger`, `integration`, `external`, `human_checkpoint`, `script`.\n\n## Edge Kinds\n\n| Kind              | Meaning                                                                        |\n| ----------------- | ------------------------------------------------------------------------------ |\n| `contains`        | Parent-to-child containment (organization to system, system to resource, etc.) |\n| `references`      | Cross-reference between nodes (role reports-to, agent invokes action)          |\n| `maps_to`         | Action mapped to a resource implementation                                     |\n| `uses`            | System or stage uses an action                                                 |\n| `governs`         | Knowledge node or role governs a system or target                              |\n| `links`           | Entity links to another entity                                                 |\n| `affects`         | Action affects an entity                                                       |\n| `emits`           | Resource or entity emits an event                                              |\n| `originates_from` | Event originates from an entity                                                |\n| `triggers`        | Event or action triggers a policy                                              |\n| `applies_to`      | Policy applies to a system, action, resource, or role                          |\n| `effects`         | Policy effect invokes an action or notifies a role                             |\n\n## Visualization Modes\n\nCommand View uses Cytoscape graph modes:\n\n- **Map:** preserves organization structure and honors hidden-resource visibility.\n- **Trace:** resolves directed paths and reveals resources for the active trace.\n- **Impact:** pivots around the selected node and reveals related resources for impact review.\n\nFilter panel:\n\n- Search across nodes, relationships, and IDs.\n- Filter by node kind, resource type, environment, topology presence, integrations, and resource facets.\n- Toggle resource visibility and diagnostic/testing resource visibility.\n- Show visible and hidden resource counts in the same control surface.\n\nHidden resource behavior:\n\n- Resource nodes are hidden by default so the organization structure remains readable.\n- Structural nodes remain visible as the navigation skeleton.\n- Selecting a visible node can reveal directly connected hidden resources.\n- Diagnostic and testing resources are hidden by default and can be revealed from the filter panel.\n\nExpand Around behavior:\n\n- Select a node, open Details, and use Expand Around to preview nearby graph context before revealing it.\n- Semantic presets cover coverage, operational dependencies, organization context, and impact paths.\n- System and entity nodes default to Coverage.\n- Resource nodes default to Operational Dependencies.\n- Preview counts show hidden resources before Apply reveals the graph patch.\n\nRead-only constraints:\n\n- No drag and drop.\n- No connection editing.\n- No graph mutation from the visualization layer.\n\n## Organization Model as the Source of Truth\n\nResource identity lives in `OM.resources`, not in a separate manifest. To add a resource to Command View:\n\n1. Add the resource to `OM.resources` in the organization model.\n2. Link it to a system via `systemPath`.\n3. Optionally link actions to the resource via `action.resourceId`.\n4. Deploy the organization model. Command View reflects the new resource automatically.\n\nThere is no separate `DeploymentSpec.relationships` declaration required for OM-declared resources. The graph builder derives containment and relationship edges directly from the OM contract.\n\nLive resource metadata (deployed name, description, runtime status) can be overlaid from Command View data when available, but the OM contract is primary.\n\n## Using Command View\n\n### System Understanding\n\nUseful exploration questions:\n\n- What systems own which resources and entities?\n- What actions does this system expose, and what do they map to?\n- Which knowledge nodes govern this system?\n- What policies apply to this system?\n- What events originate from this entity?\n- What roles are responsible for this system?\n\nVisual patterns:\n\n- Hub nodes with many edges indicate central resources or pivotal systems.\n- Linear chains show sequential workflow pipelines.\n- Branching shows conditional routing or multiple action paths.\n- Isolated nodes may indicate unused or draft resources.\n\n### Manifest Debugging\n\nUse Command View to verify:\n\n1. Resources appear as nodes under the correct system.\n2. Actions map to the expected resources.\n3. Entities link to the correct systems and each other.\n4. Policies apply to the correct systems, actions, or resources.\n5. Events appear for resources with `emits` declarations.\n6. Orphaned resources are intentional.\n\nCommon issues:\n\n- Resource declared in OM but assigned to the wrong `systemPath`.\n- Action `resourceId` points to a resource ID that does not exist.\n- Entity `ownedBySystemId` references an unknown system.\n- Policy `appliesTo` references a system, action, or resource that was removed.\n\n## Troubleshooting\n\n### Empty Graph\n\nLikely causes:\n\n- Organization has no systems or resources defined.\n- Search, node kind, or resource type filters hide all graph elements.\n- Command View resources are hidden and no structural nodes match current filters.\n\nCheck:\n\n1. OM `systems` and `resources` domains have entries.\n2. Filter panel visibility and filter state.\n3. API response for the `/api/command-view` endpoint.\n\nFix:\n\n- Add systems and resources to the organization model.\n- Reveal resources or reset graph filters.\n\n### Missing Nodes\n\nLikely causes:\n\n- Resource, action, or entity is defined in OM but omitted from the relevant domain map.\n- Node is hidden by visibility controls.\n- Status, resource type, or topology filters exclude the node.\n\nCheck:\n\n1. OM domain map includes the ID as a key and as `id` in the entry.\n2. Filter panel visibility and filter state.\n3. Node `lifecycle` or `enabled` field.\n\nFix by adding the entry to the correct domain map or revealing hidden nodes.\n\n### Missing Edges\n\nLikely causes:\n\n- Action `resourceId` does not match any OM resource ID.\n- Entity `ownedBySystemId` references an unknown system.\n- Policy `appliesTo` references IDs that do not exist.\n- Knowledge node link uses a nodeId that has no matching OM node.\n\nCheck:\n\n1. Cross-reference IDs across OM domains.\n2. Run `pnpm --filter @repo/core check-types` to surface Zod validation errors.\n\nFix the OM entry to reference the correct ID.\n\n## Best Practices\n\nKeep the OM up to date as systems and resources evolve:\n\n1. Add new resources to `OM.resources` with the correct `systemPath`.\n2. Map actions to resources via `action.resourceId` when the action calls a specific resource.\n3. Update `entity.ownedBySystemId` when entities move between systems.\n4. Update `policy.appliesTo` when systems, actions, or resources are renamed or removed.\n5. Declare `resource.emits` for workflows and agents that produce observable events.\n\nUse the OM graph as the authoritative reference for Command View structure. The graph builder derives the visualization from the OM contract -- do not expect Command View to show connections that are not declared in the OM.\n\n## Related References\n\n- `/knowledge read knowledge.org-model-reference`\n- `/knowledge read knowledge.platform-composition-patterns`\n- `/knowledge read knowledge.platform-integration-patterns`",
     "links": [
       {
         "target": {
@@ -22865,7 +22813,7 @@ var mdxKnowledgeNodes = [
     "title": "Platform Composition Patterns",
     "summary": "Reference for composing agents, workflows, integrations, tools, observability, scaling, error handling, and security into complete Elevasis automation systems.",
     "icon": "reference",
-    "body": "## Overview\r\n\r\nUse this reference to choose how Elevasis resources compose into complete systems. The core decision is whether reasoning, deterministic orchestration, or a hybrid of both should own the business flow.\r\n\r\nThree primary patterns exist:\r\n\r\n- **Agent-centric:** an agent is the primary orchestrator, and workflows or integrations are tools.\r\n- **Workflow-centric:** a workflow is the deterministic pipeline, and agents appear only as processing steps.\r\n- **Hybrid:** agents decide what should happen, and workflows execute reliable sequences.\r\n\r\n## System Architecture Patterns\r\n\r\n### Agent-Centric Systems\r\n\r\n**Pattern:** Agent is the primary orchestrator; workflows and integrations are tools.\r\n\r\n```text\r\nTrigger to Agent\r\n           |- Tool: Integration A\r\n           |- Tool: Integration B\r\n           |- Tool: Workflow 1 via resource invocation\r\n           `- Tool: Workflow 2 via resource invocation\r\n```\r\n\r\nUse this pattern for ambiguous goals, dynamic decision-making, multi-turn conversations, and business logic that requires judgment.\r\n\r\nStrengths:\r\n\r\n- Flexible and adaptive.\r\n- Handles ambiguity well.\r\n- Can delegate to specialist resources.\r\n- Supports natural language interaction.\r\n\r\nWeaknesses:\r\n\r\n- Token cost per execution.\r\n- Non-deterministic LLM variance.\r\n- Requires strong observability for debugging.\r\n- Usually slower than deterministic workflows.\r\n\r\n### Workflow-Centric Systems\r\n\r\n**Pattern:** Workflow is the pipeline; agents are processing steps.\r\n\r\n```text\r\nTrigger to Workflow\r\n           |- Step 1: Integration A reads data\r\n           |- Step 2: Agent processes or reasons\r\n           |- Step 3: Integration B writes result\r\n           `- Step 4: Conditional routing\r\n```\r\n\r\nUse this pattern for predictable sequences, data transformation pipelines, integration orchestration, and fixed business logic.\r\n\r\nStrengths:\r\n\r\n- Deterministic and reliable.\r\n- Fast execution.\r\n- Easy to debug step-by-step.\r\n- No token cost unless an agent step is included.\r\n\r\nWeaknesses:\r\n\r\n- Rigid, because steps are predefined.\r\n- Does not handle ambiguity well.\r\n- Requires code changes for logic updates.\r\n\r\n### Hybrid Systems\r\n\r\n**Pattern:** Agents decide, workflows execute. This is the recommended default for complex automation.\r\n\r\n```text\r\nTrigger to Agent decides what to do\r\n           |- Invokes: Workflow A\r\n           |- Invokes: Workflow B\r\n           `- Uses: Integration C directly\r\n\r\nWorkflow A:\r\n  |- Integration D reads\r\n  |- Agent processes a specific subtask\r\n  `- Integration E writes\r\n```\r\n\r\nUse this pattern when the system needs variable paths, reasoning, reliability, and a mix of predictable and unpredictable steps.\r\n\r\nStrengths:\r\n\r\n- Flexible where needed and reliable where possible.\r\n- Cost-efficient because workflows do not use tokens by default.\r\n- Good observability across agent reasoning and workflow steps.\r\n\r\n## Resource Composition Patterns\r\n\r\n### Agent + Tools\r\n\r\nUse direct integration access for simple or frequent operations.\r\n\r\nTool categories:\r\n\r\n- **Base tools:** always available, high-frequency operations such as read queries or cached data access. Example: `attio_get_record`.\r\n- **Knowledge Map tools:** lazy-loaded, low-frequency operations such as write operations or domain-specific capabilities. Examples: `attio_create_contact`, `dropbox_upload_file`.\r\n- **Resource invocation tools:** delegate to workflows for deterministic sequences or call specialist agents.\r\n\r\nTool creation example:\r\n\r\n```typescript\r\nconst tool = createAttioCreateRecordTool('elevasis-attio')\r\n```\r\n\r\nCredential names resolve to organization-scoped storage. RLS policies enforce organization isolation, credentials are encrypted at rest, and OAuth tokens can refresh automatically.\r\n\r\n### Agent + Workflow\r\n\r\nUse an agent for reasoning and a workflow for deterministic execution.\r\n\r\n```text\r\nTrigger to Agent reasoning\r\n          |- Direct tool: read integration\r\n          |- Invoke tool: Workflow A\r\n          `- Invoke tool: Workflow B\r\n```\r\n\r\nExecution flow:\r\n\r\n1. Agent analyzes the request.\r\n2. Agent invokes a workflow through a tool call.\r\n3. Workflow executes deterministic steps without token cost.\r\n4. Agent explains the result to the user.\r\n\r\nUse this pattern when the system needs both reasoning and reliability, has multiple execution paths, or should minimize token use by moving predictable work into workflows.\r\n\r\n### Workflow + Integration\r\n\r\nUse a workflow to orchestrate deterministic integration sequences.\r\n\r\n```text\r\nTrigger to Workflow\r\n          |- Step 1: Integration A reads\r\n          |- Step 2: Transform pure function\r\n          |- Step 3: Integration B writes\r\n          `- Step 4: Notify\r\n```\r\n\r\nUse this pattern for predictable step sequences, data transformation pipelines, integration orchestration, and cost-sensitive work that does not need LLM reasoning.\r\n\r\n## Pattern Selection Guide\r\n\r\n| Requirement | Pattern | Example |\r\n| --- | --- | --- |\r\n| Ambiguous goals | Agent-centric | Business orchestration with variable outcomes |\r\n| Predictable sequence | Workflow-centric | Shopify to CRM sync |\r\n| Hybrid needs | Agent + workflow | Support router where agent decides and workflow executes |\r\n| `\\>10` tools | Knowledge Map | Agent with many domain capabilities |\r\n| High-frequency reads | Base tools | Attio read operations |\r\n| Low-frequency writes | Lazy-loaded tools | CRM updates or page creation |\r\n| External services | Integration tools | Attio, Gmail, Google Sheets |\r\n| Deterministic pipelines | Workflow + integration | Data transformation |\r\n\r\nComplexity guidelines:\r\n\r\n- **Simple, 1-2 resources:** agent with base tools, or workflow with 1-2 integrations.\r\n- **Medium, 3-5 resources:** agent plus Knowledge Map with 2-3 nodes, or workflow plus an agent step.\r\n- **Complex, 6+ resources:** agent plus Knowledge Map plus memory preload, or multi-integration workflows.\r\n\r\n## Cross-Cutting Concerns\r\n\r\n### Observability\r\n\r\nTrack these surfaces:\r\n\r\n- Agent iterations, including reasoning and actions.\r\n- Workflow steps, including inputs and outputs.\r\n- Tool calls, including integration requests and responses.\r\n- Errors and retries.\r\n- Token usage and cost.\r\n\r\nPrimary tools:\r\n\r\n- Execution Logs for SSE-based debugging.\r\n- Activity Log for the real-time stream.\r\n- Execution Health for cost tracking and ROI review.\r\n- Command View for system architecture and dependency review.\r\n\r\n### Cost Tracking\r\n\r\nAgent cost comes from per-iteration token usage, model pricing, and tool execution cost. Workflow cost is usually zero token cost plus any external integration API fees.\r\n\r\nOptimization rules:\r\n\r\n- Use workflows for predictable tasks.\r\n- Lazy-load tools for 80-95% token savings.\r\n- Cache frequently accessed stable data.\r\n- Choose the appropriate model per task.\r\n\r\n### Scaling Strategies\r\n\r\nHorizontal scaling:\r\n\r\n- Keep agent execution stateless.\r\n- Store sessions in the database.\r\n- Let a load balancer distribute requests.\r\n\r\nVertical optimization:\r\n\r\n- Preload memory to reduce iteration count.\r\n- Lazy-load tools to reduce token usage.\r\n- Batch tool operations where possible.\r\n- Use parallel integration calls when the steps are independent.\r\n\r\n### Error Handling\r\n\r\nAgent error handling:\r\n\r\n- Tool errors are returned to the agent so it can reason about recovery.\r\n- Iteration limits prevent infinite loops.\r\n- Timeout protection constrains long-running tools and executions.\r\n- Graceful degradation explains what failed.\r\n\r\nWorkflow error handling:\r\n\r\n- Step retry logic uses exponential backoff, commonly 1, 4, and 9 minutes.\r\n- Conditional routing can send failures to an alternative step.\r\n- Manual intervention can route work to a human checkpoint.\r\n- Idempotent steps should be safe to retry.\r\n\r\nExample:\r\n\r\n```typescript\r\n{\r\n  id: 'sync-to-crm',\r\n  handler: async ({ input, context }) => {\r\n    try {\r\n      return await crmClient.createContact(input)\r\n    } catch (error) {\r\n      if (error.code === 'DUPLICATE') {\r\n        return crmClient.updateContact(input)\r\n      }\r\n\r\n      throw error\r\n    }\r\n  },\r\n  next: { type: 'linear', target: 'send-notification' }\r\n}\r\n```\r\n\r\n### Security\r\n\r\nCredential management:\r\n\r\n- Store credentials in the `credentials` table.\r\n- Encrypt values at rest.\r\n- Scope records by organization with RLS policies.\r\n- Refresh OAuth tokens automatically where supported.\r\n- Never store API keys in code.\r\n\r\nMulti-tenancy isolation layers:\r\n\r\n1. Database RLS on tenant-scoped tables.\r\n2. API middleware that requires organization context.\r\n3. Resource registry lookups scoped to the organization.\r\n4. Command View filtered by organization.\r\n\r\n## Best Practices\r\n\r\n1. Start with a single agent or workflow, then add complexity only when needed.\r\n2. Build the working version before optimizing for caching or lazy loading.\r\n3. Put domain logic in agents and execution flow in workflows.\r\n4. Lazy-load large or low-frequency tool groups.\r\n5. Cache stable data, not fast-changing operational state.\r\n\r\nCommon mistakes:\r\n\r\n- Creating a Knowledge Map for fewer than five tools.\r\n- Using a workflow for one integration call when an agent tool would be simpler.\r\n- Loading more than ten tools as base tools.\r\n- Putting domain logic into workflows where it becomes hard to test and adapt.\r\n- Mixing unrelated concerns in one knowledge node.\r\n\r\n## Related References\r\n\r\n- `/knowledge read knowledge.platform-integration-patterns`\r\n- `/knowledge read knowledge.platform-command-view`",
+    "body": "## Overview\n\nUse this reference to choose how Elevasis resources compose into complete systems. The core decision is whether reasoning, deterministic orchestration, or a hybrid of both should own the business flow.\n\nThree primary patterns exist:\n\n- **Agent-centric:** an agent is the primary orchestrator, and workflows or integrations are tools.\n- **Workflow-centric:** a workflow is the deterministic pipeline, and agents appear only as processing steps.\n- **Hybrid:** agents decide what should happen, and workflows execute reliable sequences.\n\n## System Architecture Patterns\n\n### Agent-Centric Systems\n\n**Pattern:** Agent is the primary orchestrator; workflows and integrations are tools.\n\n```text\nTrigger to Agent\n           |- Tool: Integration A\n           |- Tool: Integration B\n           |- Tool: Workflow 1 via resource invocation\n           `- Tool: Workflow 2 via resource invocation\n```\n\nUse this pattern for ambiguous goals, dynamic decision-making, multi-turn conversations, and business logic that requires judgment.\n\nStrengths:\n\n- Flexible and adaptive.\n- Handles ambiguity well.\n- Can delegate to specialist resources.\n- Supports natural language interaction.\n\nWeaknesses:\n\n- Token cost per execution.\n- Non-deterministic LLM variance.\n- Requires strong observability for debugging.\n- Usually slower than deterministic workflows.\n\n### Workflow-Centric Systems\n\n**Pattern:** Workflow is the pipeline; agents are processing steps.\n\n```text\nTrigger to Workflow\n           |- Step 1: Integration A reads data\n           |- Step 2: Agent processes or reasons\n           |- Step 3: Integration B writes result\n           `- Step 4: Conditional routing\n```\n\nUse this pattern for predictable sequences, data transformation pipelines, integration orchestration, and fixed business logic.\n\nStrengths:\n\n- Deterministic and reliable.\n- Fast execution.\n- Easy to debug step-by-step.\n- No token cost unless an agent step is included.\n\nWeaknesses:\n\n- Rigid, because steps are predefined.\n- Does not handle ambiguity well.\n- Requires code changes for logic updates.\n\n### Hybrid Systems\n\n**Pattern:** Agents decide, workflows execute. This is the recommended default for complex automation.\n\n```text\nTrigger to Agent decides what to do\n           |- Invokes: Workflow A\n           |- Invokes: Workflow B\n           `- Uses: Integration C directly\n\nWorkflow A:\n  |- Integration D reads\n  |- Agent processes a specific subtask\n  `- Integration E writes\n```\n\nUse this pattern when the system needs variable paths, reasoning, reliability, and a mix of predictable and unpredictable steps.\n\nStrengths:\n\n- Flexible where needed and reliable where possible.\n- Cost-efficient because workflows do not use tokens by default.\n- Good observability across agent reasoning and workflow steps.\n\n## Resource Composition Patterns\n\n### Agent + Tools\n\nUse direct integration access for simple or frequent operations.\n\nTool categories:\n\n- **Base tools:** always available, high-frequency operations such as read queries or cached data access. Example: `attio_get_record`.\n- **Knowledge Map tools:** lazy-loaded, low-frequency operations such as write operations or domain-specific capabilities. Examples: `attio_create_contact`, `dropbox_upload_file`.\n- **Resource invocation tools:** delegate to workflows for deterministic sequences or call specialist agents.\n\nTool creation example:\n\n```typescript\nconst tool = createAttioCreateRecordTool('elevasis-attio')\n```\n\nCredential names resolve to organization-scoped storage. RLS policies enforce organization isolation, credentials are encrypted at rest, and OAuth tokens can refresh automatically.\n\n### Agent + Workflow\n\nUse an agent for reasoning and a workflow for deterministic execution.\n\n```text\nTrigger to Agent reasoning\n          |- Direct tool: read integration\n          |- Invoke tool: Workflow A\n          `- Invoke tool: Workflow B\n```\n\nExecution flow:\n\n1. Agent analyzes the request.\n2. Agent invokes a workflow through a tool call.\n3. Workflow executes deterministic steps without token cost.\n4. Agent explains the result to the user.\n\nUse this pattern when the system needs both reasoning and reliability, has multiple execution paths, or should minimize token use by moving predictable work into workflows.\n\n### Workflow + Integration\n\nUse a workflow to orchestrate deterministic integration sequences.\n\n```text\nTrigger to Workflow\n          |- Step 1: Integration A reads\n          |- Step 2: Transform pure function\n          |- Step 3: Integration B writes\n          `- Step 4: Notify\n```\n\nUse this pattern for predictable step sequences, data transformation pipelines, integration orchestration, and cost-sensitive work that does not need LLM reasoning.\n\n## Pattern Selection Guide\n\n| Requirement | Pattern | Example |\n| --- | --- | --- |\n| Ambiguous goals | Agent-centric | Business orchestration with variable outcomes |\n| Predictable sequence | Workflow-centric | Shopify to CRM sync |\n| Hybrid needs | Agent + workflow | Support router where agent decides and workflow executes |\n| `\\>10` tools | Knowledge Map | Agent with many domain capabilities |\n| High-frequency reads | Base tools | Attio read operations |\n| Low-frequency writes | Lazy-loaded tools | CRM updates or page creation |\n| External services | Integration tools | Attio, Gmail, Google Sheets |\n| Deterministic pipelines | Workflow + integration | Data transformation |\n\nComplexity guidelines:\n\n- **Simple, 1-2 resources:** agent with base tools, or workflow with 1-2 integrations.\n- **Medium, 3-5 resources:** agent plus Knowledge Map with 2-3 nodes, or workflow plus an agent step.\n- **Complex, 6+ resources:** agent plus Knowledge Map plus memory preload, or multi-integration workflows.\n\n## Cross-Cutting Concerns\n\n### Observability\n\nTrack these surfaces:\n\n- Agent iterations, including reasoning and actions.\n- Workflow steps, including inputs and outputs.\n- Tool calls, including integration requests and responses.\n- Errors and retries.\n- Token usage and cost.\n\nPrimary tools:\n\n- Execution Logs for SSE-based debugging.\n- Activity Log for the real-time stream.\n- Execution Health for cost tracking and ROI review.\n- Command View for system architecture and dependency review.\n\n### Cost Tracking\n\nAgent cost comes from per-iteration token usage, model pricing, and tool execution cost. Workflow cost is usually zero token cost plus any external integration API fees.\n\nOptimization rules:\n\n- Use workflows for predictable tasks.\n- Lazy-load tools for 80-95% token savings.\n- Cache frequently accessed stable data.\n- Choose the appropriate model per task.\n\n### Scaling Strategies\n\nHorizontal scaling:\n\n- Keep agent execution stateless.\n- Store sessions in the database.\n- Let a load balancer distribute requests.\n\nVertical optimization:\n\n- Preload memory to reduce iteration count.\n- Lazy-load tools to reduce token usage.\n- Batch tool operations where possible.\n- Use parallel integration calls when the steps are independent.\n\n### Error Handling\n\nAgent error handling:\n\n- Tool errors are returned to the agent so it can reason about recovery.\n- Iteration limits prevent infinite loops.\n- Timeout protection constrains long-running tools and executions.\n- Graceful degradation explains what failed.\n\nWorkflow error handling:\n\n- Step retry logic uses exponential backoff, commonly 1, 4, and 9 minutes.\n- Conditional routing can send failures to an alternative step.\n- Manual intervention can route work to a human checkpoint.\n- Idempotent steps should be safe to retry.\n\nExample:\n\n```typescript\n{\n  id: 'sync-to-crm',\n  handler: async ({ input, context }) => {\n    try {\n      return await crmClient.createContact(input)\n    } catch (error) {\n      if (error.code === 'DUPLICATE') {\n        return crmClient.updateContact(input)\n      }\n\n      throw error\n    }\n  },\n  next: { type: 'linear', target: 'send-notification' }\n}\n```\n\n### Security\n\nCredential management:\n\n- Store credentials in the `credentials` table.\n- Encrypt values at rest.\n- Scope records by organization with RLS policies.\n- Refresh OAuth tokens automatically where supported.\n- Never store API keys in code.\n\nMulti-tenancy isolation layers:\n\n1. Database RLS on tenant-scoped tables.\n2. API middleware that requires organization context.\n3. Resource registry lookups scoped to the organization.\n4. Command View filtered by organization.\n\n## Best Practices\n\n1. Start with a single agent or workflow, then add complexity only when needed.\n2. Build the working version before optimizing for caching or lazy loading.\n3. Put domain logic in agents and execution flow in workflows.\n4. Lazy-load large or low-frequency tool groups.\n5. Cache stable data, not fast-changing operational state.\n\nCommon mistakes:\n\n- Creating a Knowledge Map for fewer than five tools.\n- Using a workflow for one integration call when an agent tool would be simpler.\n- Loading more than ten tools as base tools.\n- Putting domain logic into workflows where it becomes hard to test and adapt.\n- Mixing unrelated concerns in one knowledge node.\n\n## Related References\n\n- `/knowledge read knowledge.platform-integration-patterns`\n- `/knowledge read knowledge.platform-command-view`",
     "links": [
       {
         "target": {
@@ -22885,7 +22833,7 @@ var mdxKnowledgeNodes = [
     "title": "Platform Integration Patterns",
     "summary": "Reference for connecting Elevasis agents and workflows to external services through adapters, OAuth, API keys, tenant-isolated credentials, retries, and tests.",
     "icon": "reference",
-    "body": "## Overview\r\n\r\nIntegration patterns define how Elevasis agents and workflows connect to external services such as Gmail, Attio, Google Sheets, and custom APIs. The platform uses a standardized adapter pattern with OAuth 2.0 and API key authentication backed by tenant-isolated credentials.\r\n\r\nCore patterns:\r\n\r\n- Direct integration, where a resource uses integration tools directly.\r\n- Integration workflow, where a workflow coordinates multiple integrations.\r\n- Shared integration, where multiple resources use the same credential set.\r\n- Multi-account integration, where the same provider has separate credentials for different contexts.\r\n\r\n## Direct Integration Pattern\r\n\r\n**Pattern:** Resource uses an integration tool.\r\n\r\nUse direct integration tools when an agent or workflow performs frequent operations against a provider.\r\n\r\nCharacteristics:\r\n\r\n- Tools are always available to the resource.\r\n- There is no additional navigation overhead.\r\n- The pattern is optimized for frequent read-heavy operations.\r\n\r\nTool factory location:\r\n\r\n```text\r\npackages/core/src/execution/engine/tools/integration/server/adapters/{provider}/{provider}-tools.ts\r\n```\r\n\r\nTool factories use `createIntegrationTool()` with a `credentialName` parameter. Example: `createAttioCreateRecordTool(credentialName)`.\r\n\r\n## Integration Workflow Pattern\r\n\r\n**Pattern:** Agent invokes a workflow, and the workflow uses integrations.\r\n\r\nUse an integration workflow for complex multi-step operations that need deterministic orchestration.\r\n\r\nExample lead capture flow:\r\n\r\n1. Webhook trigger receives the event.\r\n2. Workflow creates an Attio contact.\r\n3. Workflow sends a Gmail notification.\r\n4. Workflow returns confirmation.\r\n\r\nCharacteristics:\r\n\r\n- Deterministic execution order.\r\n- Step-level error handling and retry.\r\n- Multiple integrations coordinated in one place.\r\n- Built-in audit trail through workflow execution.\r\n\r\n## Shared Integration Pattern\r\n\r\n**Pattern:** Multiple resources share the same integration.\r\n\r\nUse shared integrations for organization-wide providers that should use one credential set.\r\n\r\nExample:\r\n\r\n```text\r\npackages/elevasis-operations/src/index.ts\r\n```\r\n\r\nCharacteristics:\r\n\r\n- One credential per integration.\r\n- Centralized credential management.\r\n- Shared across agents and workflows.\r\n\r\n## Multi-Account Pattern\r\n\r\n**Pattern:** Same provider, different credentials.\r\n\r\nUse this pattern for department-specific provider instances or separate dev/prod environments.\r\n\r\nExample:\r\n\r\n```typescript\r\nconst salesTool = createAttioCreateRecordTool('attio-sales')\r\nconst supportTool = createAttioCreateRecordTool('attio-support')\r\n```\r\n\r\nDisambiguate multi-account tools with explicit tool names:\r\n\r\n```typescript\r\nconst tool = createAttioToolNamed(\r\n  'attio_sales_create_record',\r\n  'attio-sales',\r\n  'createRecord'\r\n)\r\n```\r\n\r\n## Authentication Patterns\r\n\r\n### OAuth 2.0 vs API Key\r\n\r\n| Aspect | OAuth 2.0 | API key |\r\n| --- | --- | --- |\r\n| Auth flow | Browser redirect plus token exchange | Direct API key |\r\n| Setup complexity | High: client ID, secret, redirect URL | Low: single API key |\r\n| Token refresh | Automatic refresh token rotation | Manual key rotation |\r\n| Scope control | Granular permission scopes | Full access or none |\r\n| User context | Per-user authorization | Service-level access |\r\n| Revocation | User can revoke anytime | Manual key deletion |\r\n\r\n### OAuth 2.0 Pattern\r\n\r\nProviders include Gmail and Google Sheets.\r\n\r\nCredential format:\r\n\r\n```typescript\r\ninterface OAuthToken {\r\n  provider: string\r\n  accessToken: string\r\n  refreshToken: string\r\n  expiresAt: string\r\n  tokenType: 'Bearer'\r\n  scope?: string\r\n}\r\n```\r\n\r\n`expiresAt` is an ISO 8601 timestamp. The platform handles token refresh when supported by the provider and credential implementation.\r\n\r\n### API Key Pattern\r\n\r\nProviders include Attio and custom APIs.\r\n\r\nCredential format:\r\n\r\n```typescript\r\ninterface APIKeyCredentials {\r\n  apiKey: string\r\n}\r\n```\r\n\r\nProvider-specific validation belongs in the adapter. For Attio, see:\r\n\r\n```text\r\npackages/core/src/execution/engine/tools/integration/server/adapters/attio/attio-adapter.ts\r\n```\r\n\r\n## Credential Management\r\n\r\nCredentials are stored in the `credentials` table.\r\n\r\nKey columns:\r\n\r\n- `organization_id` for tenant isolation.\r\n- `name`, such as `elevasis-attio`.\r\n- `provider`, such as `gmail` or `attio`.\r\n- `encrypted_value` containing encrypted JSON.\r\n\r\nSecurity rules:\r\n\r\n- RLS policies enforce tenant isolation.\r\n- Values are encrypted at rest.\r\n- Credentials do not cross organization boundaries.\r\n\r\nBest practices:\r\n\r\n- Store credentials encrypted in the database.\r\n- Use tenant-isolated credential names.\r\n- Validate credentials before API calls.\r\n- Rotate API keys regularly.\r\n- Use least-privilege OAuth scopes.\r\n\r\nDo not:\r\n\r\n- Hardcode credentials in code.\r\n- Share credentials across organizations.\r\n- Log credential values.\r\n- Store provider API keys in environment variables for tenant integrations.\r\n- Reuse the same credential name for dev and prod.\r\n\r\nCredential resolution flow:\r\n\r\n1. Tool requests a credential by name.\r\n2. Platform queries `credentials` with the current `organization_id`.\r\n3. Platform decrypts the credential.\r\n4. Adapter validates the credential against the provider schema.\r\n5. Tool passes the credential to the provider adapter.\r\n6. Usage is logged without credential values.\r\n\r\nImplementation reference:\r\n\r\n```text\r\npackages/core/src/execution/engine/tools/integration/tool.ts\r\n```\r\n\r\n## Error Handling Patterns\r\n\r\nAdapters should convert provider errors into platform tooling errors.\r\n\r\nCommon error categories:\r\n\r\n- `credentials_invalid` for invalid or missing credentials.\r\n- `api_error` for provider API errors.\r\n- `network_error` for network or timeout failures.\r\n- `validation_error` for invalid parameters.\r\n- `method_not_found` for unknown adapter methods.\r\n\r\nRetry strategy:\r\n\r\n- Network errors: retry with exponential backoff, commonly 1, 2, and 4 seconds.\r\n- Auth errors: fail immediately because the credential needs attention.\r\n- Validation errors: fail immediately because the input needs correction.\r\n- Rate limits: retry after reset when the provider exposes a reset time.\r\n- Workflow-level retries: commonly 3 attempts with 1, 4, and 9 minute delays.\r\n\r\n## Adapter Development\r\n\r\nAdapter class location:\r\n\r\n```text\r\npackages/core/src/execution/engine/tools/integration/server/adapters/{provider}/{provider}-adapter.ts\r\n```\r\n\r\nAdapter classes implement `BaseIntegrationAdapter` and contain `call()` and `validateCredentials()` methods.\r\n\r\nTool factory location:\r\n\r\n```text\r\npackages/core/src/execution/engine/tools/integration/server/adapters/{provider}/{provider}-tools.ts\r\n```\r\n\r\nTool factories export `create{Provider}{Operation}Tool(credentialName)` functions.\r\n\r\nTests belong under:\r\n\r\n```text\r\npackages/core/src/execution/engine/tools/integration/server/adapters/{provider}/__tests__/\r\n```\r\n\r\nRegistration happens in:\r\n\r\n```text\r\npackages/core/src/execution/engine/tools/integration/server/index.ts\r\n```\r\n\r\n## Testing Strategies\r\n\r\nUnit testing:\r\n\r\n- Mock external APIs.\r\n- Cover credential validation.\r\n- Cover API call construction.\r\n- Cover response parsing.\r\n- Cover error handling.\r\n\r\nIntegration testing:\r\n\r\n- Use real API calls only with test accounts or test workspaces.\r\n- Clean up test data after tests.\r\n- Run in CI only when secret credentials are available.\r\n- Keep provider behavior mocked in unit tests.\r\n\r\nAgent testing:\r\n\r\n- Test agents using integration tools at the resource boundary.\r\n- Tenant project agent tests normally live under `external/{org}/src/agents/{agent}/__tests__/`.\r\n\r\n## Related References\r\n\r\n- `/knowledge read knowledge.platform-composition-patterns`\r\n- `/knowledge read knowledge.platform-command-view`\r\n- `/knowledge read knowledge.platform-systems-overview`",
+    "body": "## Overview\n\nIntegration patterns define how Elevasis agents and workflows connect to external services such as Gmail, Attio, Google Sheets, and custom APIs. The platform uses a standardized adapter pattern with OAuth 2.0 and API key authentication backed by tenant-isolated credentials.\n\nCore patterns:\n\n- Direct integration, where a resource uses integration tools directly.\n- Integration workflow, where a workflow coordinates multiple integrations.\n- Shared integration, where multiple resources use the same credential set.\n- Multi-account integration, where the same provider has separate credentials for different contexts.\n\n## Direct Integration Pattern\n\n**Pattern:** Resource uses an integration tool.\n\nUse direct integration tools when an agent or workflow performs frequent operations against a provider.\n\nCharacteristics:\n\n- Tools are always available to the resource.\n- There is no additional navigation overhead.\n- The pattern is optimized for frequent read-heavy operations.\n\nTool factory location:\n\n```text\npackages/core/src/execution/engine/tools/integration/server/adapters/{provider}/{provider}-tools.ts\n```\n\nTool factories use `createIntegrationTool()` with a `credentialName` parameter. Example: `createAttioCreateRecordTool(credentialName)`.\n\n## Integration Workflow Pattern\n\n**Pattern:** Agent invokes a workflow, and the workflow uses integrations.\n\nUse an integration workflow for complex multi-step operations that need deterministic orchestration.\n\nExample lead capture flow:\n\n1. Webhook trigger receives the event.\n2. Workflow creates an Attio contact.\n3. Workflow sends a Gmail notification.\n4. Workflow returns confirmation.\n\nCharacteristics:\n\n- Deterministic execution order.\n- Step-level error handling and retry.\n- Multiple integrations coordinated in one place.\n- Built-in audit trail through workflow execution.\n\n## Shared Integration Pattern\n\n**Pattern:** Multiple resources share the same integration.\n\nUse shared integrations for organization-wide providers that should use one credential set.\n\nExample:\n\n```text\npackages/elevasis-operations/src/index.ts\n```\n\nCharacteristics:\n\n- One credential per integration.\n- Centralized credential management.\n- Shared across agents and workflows.\n\n## Multi-Account Pattern\n\n**Pattern:** Same provider, different credentials.\n\nUse this pattern for department-specific provider instances or separate dev/prod environments.\n\nExample:\n\n```typescript\nconst salesTool = createAttioCreateRecordTool('attio-sales')\nconst supportTool = createAttioCreateRecordTool('attio-support')\n```\n\nDisambiguate multi-account tools with explicit tool names:\n\n```typescript\nconst tool = createAttioToolNamed(\n  'attio_sales_create_record',\n  'attio-sales',\n  'createRecord'\n)\n```\n\n## Authentication Patterns\n\n### OAuth 2.0 vs API Key\n\n| Aspect | OAuth 2.0 | API key |\n| --- | --- | --- |\n| Auth flow | Browser redirect plus token exchange | Direct API key |\n| Setup complexity | High: client ID, secret, redirect URL | Low: single API key |\n| Token refresh | Automatic refresh token rotation | Manual key rotation |\n| Scope control | Granular permission scopes | Full access or none |\n| User context | Per-user authorization | Service-level access |\n| Revocation | User can revoke anytime | Manual key deletion |\n\n### OAuth 2.0 Pattern\n\nProviders include Gmail and Google Sheets.\n\nCredential format:\n\n```typescript\ninterface OAuthToken {\n  provider: string\n  accessToken: string\n  refreshToken: string\n  expiresAt: string\n  tokenType: 'Bearer'\n  scope?: string\n}\n```\n\n`expiresAt` is an ISO 8601 timestamp. The platform handles token refresh when supported by the provider and credential implementation.\n\n### API Key Pattern\n\nProviders include Attio and custom APIs.\n\nCredential format:\n\n```typescript\ninterface APIKeyCredentials {\n  apiKey: string\n}\n```\n\nProvider-specific validation belongs in the adapter. For Attio, see:\n\n```text\npackages/core/src/execution/engine/tools/integration/server/adapters/attio/attio-adapter.ts\n```\n\n## Credential Management\n\nCredentials are stored in the `credentials` table.\n\nKey columns:\n\n- `organization_id` for tenant isolation.\n- `name`, such as `elevasis-attio`.\n- `provider`, such as `gmail` or `attio`.\n- `encrypted_value` containing encrypted JSON.\n\nSecurity rules:\n\n- RLS policies enforce tenant isolation.\n- Values are encrypted at rest.\n- Credentials do not cross organization boundaries.\n\nBest practices:\n\n- Store credentials encrypted in the database.\n- Use tenant-isolated credential names.\n- Validate credentials before API calls.\n- Rotate API keys regularly.\n- Use least-privilege OAuth scopes.\n\nDo not:\n\n- Hardcode credentials in code.\n- Share credentials across organizations.\n- Log credential values.\n- Store provider API keys in environment variables for tenant integrations.\n- Reuse the same credential name for dev and prod.\n\nCredential resolution flow:\n\n1. Tool requests a credential by name.\n2. Platform queries `credentials` with the current `organization_id`.\n3. Platform decrypts the credential.\n4. Adapter validates the credential against the provider schema.\n5. Tool passes the credential to the provider adapter.\n6. Usage is logged without credential values.\n\nImplementation reference:\n\n```text\npackages/core/src/execution/engine/tools/integration/tool.ts\n```\n\n## Error Handling Patterns\n\nAdapters should convert provider errors into platform tooling errors.\n\nCommon error categories:\n\n- `credentials_invalid` for invalid or missing credentials.\n- `api_error` for provider API errors.\n- `network_error` for network or timeout failures.\n- `validation_error` for invalid parameters.\n- `method_not_found` for unknown adapter methods.\n\nRetry strategy:\n\n- Network errors: retry with exponential backoff, commonly 1, 2, and 4 seconds.\n- Auth errors: fail immediately because the credential needs attention.\n- Validation errors: fail immediately because the input needs correction.\n- Rate limits: retry after reset when the provider exposes a reset time.\n- Workflow-level retries: commonly 3 attempts with 1, 4, and 9 minute delays.\n\n## Adapter Development\n\nAdapter class location:\n\n```text\npackages/core/src/execution/engine/tools/integration/server/adapters/{provider}/{provider}-adapter.ts\n```\n\nAdapter classes implement `BaseIntegrationAdapter` and contain `call()` and `validateCredentials()` methods.\n\nTool factory location:\n\n```text\npackages/core/src/execution/engine/tools/integration/server/adapters/{provider}/{provider}-tools.ts\n```\n\nTool factories export `create{Provider}{Operation}Tool(credentialName)` functions.\n\nTests belong under:\n\n```text\npackages/core/src/execution/engine/tools/integration/server/adapters/{provider}/__tests__/\n```\n\nRegistration happens in:\n\n```text\npackages/core/src/execution/engine/tools/integration/server/index.ts\n```\n\n## Testing Strategies\n\nUnit testing:\n\n- Mock external APIs.\n- Cover credential validation.\n- Cover API call construction.\n- Cover response parsing.\n- Cover error handling.\n\nIntegration testing:\n\n- Use real API calls only with test accounts or test workspaces.\n- Clean up test data after tests.\n- Run in CI only when secret credentials are available.\n- Keep provider behavior mocked in unit tests.\n\nAgent testing:\n\n- Test agents using integration tools at the resource boundary.\n- Tenant project agent tests normally live under `external/{org}/src/agents/{agent}/__tests__/`.\n\n## Related References\n\n- `/knowledge read knowledge.platform-composition-patterns`\n- `/knowledge read knowledge.platform-command-view`\n- `/knowledge read knowledge.platform-systems-overview`",
     "links": [
       {
         "target": {
@@ -22898,6 +22846,26 @@ var mdxKnowledgeNodes = [
     "ownerIds": [],
     "updatedAt": "2026-05-04",
     "sourceFilePath": "packages/elevasis-core/src/knowledge/nodes/platform/platform-integration-patterns.mdx"
+  },
+  {
+    "id": "knowledge.system-building",
+    "kind": "reference",
+    "title": "System Building Guidance",
+    "summary": "Reference for authoring a complete Organization Model System end to end -- shell, ontology, resources, topology, knowledge nodes, UI manifest, and apiInterface readiness. Points to the intent-to-abstraction map, the ordered build runbook, and the permanent guide.",
+    "icon": "reference",
+    "body": '## Overview\n\nUse this reference when building a new System or extending an existing one inside the Organization Model. The intent-to-abstraction map, the ordered build runbook, and the permanent guide together form the complete guidance chain.\n\nThe Organization Model is the single join point across runtime resources, UI manifests, topology wiring, and agent knowledge. System authoring starts here -- not in deployment files, UI registries, or hand-written constants.\n\n## Entry Points\n\nThree entry points exist depending on context:\n\n- **Intent-triggered (primary):** describe what the system should do in free text. The `/om` skill\'s prompt-signals route build intent to the runbook automatically -- no subcommand required.\n- **Manual trigger (secondary):** invoke `/om build` directly to walk the sequenced runbook.\n- **Copy-address:** use `/om read-folder group:systems` in the Knowledge Tree to browse all System nodes and their governing knowledge.\n\n## Intent to Abstraction Map\n\nThe intent-to-abstraction rule lives at `.claude/rules/system-building.md`. It auto-injects when editing any OM domain file and maps each user intent phrase to the exact System slot it fills, the canonical authoring file, and the `define*` helper to call.\n\nRepresentative mappings:\n\n- "react to incoming email" -- `trigger` (webhook) + `topology.triggers` edge + handler workflow\n- "store deal data" -- `system.ontology` object with `scope: { system: \'<id>\' }`\n- "expose to other systems" -- `system.apiInterface` marker + scoped topology grant\n- "show in the dashboard" -- `system.ui.surfaces` + `SystemModule` keyed to `systemId`\n- "track with a status" -- `system.ontology` catalog + `usesCatalogs` resource binding\n\nSee `.claude/rules/system-building.md` for the full 13-row table covering all System slots.\n\n## Ordered Build Runbook\n\nThe sequenced build journey (once available at `/om build`) walks:\n\n1. Define the System shell (`defineSystem` in the tenant OM)\n2. Author `system.ontology` (objects, links, actions, catalogs, events, interfaces, value types, properties, groups, endpoints)\n3. Author resources + ontology bindings (`systemPath`, `reads`/`writes`/`actions`/`usesCatalogs`/`emits`)\n4. Wire topology (`triggers`/`uses`/`approval`) and cross-system grants\n5. Author knowledge nodes (`governs: system:<id>` via `links` frontmatter)\n6. Register the UI manifest (`SystemModule` keyed to `systemId`)\n7. Mark `system.apiInterface` when the system is ready for cross-system use\n8. Run `pnpm exec elevasis om:doctor` to verify coherence\n\n## Permanent Guide\n\nThe full narrative guide with worked cross-system patterns, OM Spine producer/consumer examples, and `apiInterface` readiness troubleshooting lives at:\n\n`apps/docs/content/docs/technical/development/guides/building-systems/index.mdx`\n\nRead it for step-by-step authoring instructions, code examples, and common mistake patterns.\n\n## Key Source Files\n\n- `packages/elevasis-core/src/organization-model/systems.ts` -- `SystemEntry` master abstraction; every buildable slot lives here\n- `packages/core/src/organization-model/ontology.ts` -- ontology ID scheme (`system.path:kind/local-id`)\n- `packages/core/src/organization-model/helpers.ts` -- `getSystem` / `getResourcesForSystem` / `listAllSystems`\n- `packages/core/src/organization-model/domains/resources.ts` -- `ResourceEntry`, `systemPath`, ontology bindings\n- `packages/core/src/organization-model/domains/topology.ts` -- `triggers`/`uses`/`approval` wiring + system interface grants\n\n## Related References\n\n- `/om read knowledge.platform-composition-patterns`\n- `/om read knowledge.org-model-graph-contract`',
+    "links": [
+      {
+        "target": {
+          "kind": "system",
+          "id": "platform"
+        },
+        "nodeId": "system:platform"
+      }
+    ],
+    "ownerIds": [],
+    "updatedAt": "2026-06-06",
+    "sourceFilePath": "packages/elevasis-core/src/knowledge/nodes/platform/system-building.mdx"
   }
 ];
 
@@ -23636,19 +23604,26 @@ var platformNavigation = {
             surfaceType: "list",
             order: 30
           },
+          "operations-sessions": {
+            type: "surface",
+            label: "Agent Sessions",
+            path: "/operations/sessions",
+            surfaceType: "list",
+            order: 40
+          },
           "operations-command-queue": {
             type: "surface",
             label: "Command Queue",
             path: "/operations/command-queue",
             surfaceType: "list",
-            order: 40
+            order: 50
           },
           "operations-task-scheduler": {
             type: "surface",
             label: "Task Scheduler",
             path: "/operations/task-scheduler",
             surfaceType: "list",
-            order: 50
+            order: 60
           }
         }
       },
@@ -24121,7 +24096,7 @@ var platformRoles = {
       "Own platform operations knowledge and keep operational playbooks aligned with active systems.",
       "Maintain platform utilities, diagnostics, and resource governance health."
     ],
-    responsibleFor: ["client-management", "sales", "platform.projects", "seo", "platform"]
+    responsibleFor: ["client-management", "sales", "platform.projects", "seo", "platform", "platform.submitted-requests"]
   },
   "role.growth-operator": {
     id: "role.growth-operator",
@@ -25553,20 +25528,6 @@ var platformWorkflowResourceDefinitions = {
       description: "E2E validation of AnyMailFinder waterfall: preserves qualification + Tomba state, verifies enrichmentData.anymailfinder shape."
     }
   },
-  "lgn-tomba-discovery-diagnostic-workflow": {
-    systemPath: "sales.lead-gen",
-    codeRefs: [
-      {
-        path: "packages/elevasis-operations/src/diagnostics/lead-gen/tomba-discovery-diagnostic.ts",
-        role: "entrypoint",
-        symbol: "tombaDiscoveryDiagnosticWorkflow"
-      }
-    ],
-    displayMetadata: {
-      title: "LGN Tomba Discovery Diagnostic",
-      description: "E2E validation of Tomba discovery workflow + soft-delete logic on found contacts."
-    }
-  },
   "resend-unsubscribe-diagnostic-workflow": {
     systemPath: "platform"
   },
@@ -25591,8 +25552,9 @@ var platformWorkflowResourceDefinitions = {
         symbol: "acqIntegrationTestWorkflow"
       },
       {
-        path: "packages/elevasis-operations/src/diagnostics/inbound/integration-test-schema.ts",
-        role: "schema"
+        path: "packages/elevasis-core/src/contracts/integration-test.ts",
+        role: "schema",
+        symbol: "inputSchema"
       }
     ],
     displayMetadata: {
@@ -25698,8 +25660,9 @@ var platformWorkflowResourceDefinitions = {
         symbol: "bookingNudgeWorkflow"
       },
       {
-        path: "packages/elevasis-operations/src/sales/outreach/reply/booking-nudge-schema.ts",
-        role: "schema"
+        path: "packages/elevasis-core/src/contracts/booking-nudge.ts",
+        role: "schema",
+        symbol: "inputSchema"
       }
     ],
     displayMetadata: {
@@ -26731,7 +26694,7 @@ var platformIntegrationResources = [
         symbol: "integrations"
       }
     ],
-    provider: "apollo"
+    provider: "webhook"
   }
 ];
 var platformIntegrationResourcesWithOwners = platformIntegrationResources.map((resource2) => ({
@@ -26769,6 +26732,40 @@ var platformResourceDescriptors = defineResources(
           { kind: "slash-command", command: "/help" },
           { kind: "slash-command", command: "/work" }
         ]
+      },
+      {
+        id: "byron-voice-capture-agent",
+        order: 10010,
+        kind: "agent",
+        systemPath: "client-management",
+        title: "Byron Voice Capture Interview Agent",
+        description: "Dogfood interview agent that captures client voice, tone, messaging preferences, and examples as a session transcript.",
+        ownerRoleId: getPlatformOwnerRoleId("client-management"),
+        actsAsRoleId: getPlatformOwnerRoleId("client-management"),
+        status: "active",
+        codeRefs: [
+          {
+            path: "packages/elevasis-operations/src/client-support/voice-capture-agent.ts",
+            role: "entrypoint",
+            symbol: "byronVoiceCaptureAgent"
+          },
+          {
+            path: "packages/elevasis-operations/src/client-support/index.ts",
+            role: "config",
+            symbol: "agents"
+          },
+          {
+            path: "packages/elevasis-operations/src/index.ts",
+            role: "config",
+            symbol: "deploymentSpec"
+          }
+        ],
+        agentKind: "specialist",
+        sessionCapable: true,
+        invocations: [
+          { kind: "api-endpoint", method: "POST", path: "/api/external/sessions" },
+          { kind: "api-endpoint", method: "POST", path: "/api/external/sessions/:sessionId/turns" }
+        ]
       }
     ].map((resource2) => [resource2.id, resource2])
   )
@@ -33718,6 +33715,9 @@ var taskStatusColors = {
   pending: "gray",
   planned: "gray",
   in_progress: "blue",
+  blocked: "red",
+  completed: "green",
+  cancelled: "gray",
   submitted: "yellow",
   approved: "green",
   rejected: "red",
@@ -36311,8 +36311,7 @@ function CommandQueueDetailPage({
   const [actionsView, setActionsView] = useState("formatted");
   const [payloadView, setPayloadView] = useState("formatted");
   const [submitResultError, setSubmitResultError] = useState(null);
-  const { data: taskList, isLoading } = useCommandQueue();
-  const task = taskList?.tasks.find((t) => t.id === taskId);
+  const { data: task, isLoading } = useCommandQueueTask(taskId);
   const richTextRenderer = renderRichText ? (props) => renderRichText(props) : void 0;
   const submitCallbacks = {
     onSuccess: (data) => {
@@ -43914,7 +43913,7 @@ function SessionsPage({
     /* @__PURE__ */ jsx(
       PageTitleCaption,
       {
-        title: "Sessions",
+        title: "Agent Sessions",
         caption: "Create and manage multi-turn agent conversations",
         rightSection: !selectedAgent ? /* @__PURE__ */ jsx(ResourceFilter, { value: statusFilter, onChange: setStatusFilter }) : void 0
       }
@@ -43932,7 +43931,7 @@ function SessionsPage({
               leftSection: /* @__PURE__ */ jsx(IconPlus, { size: 16 }),
               onClick: handleCreateSession,
               loading: createSession.isPending,
-              children: "New Session"
+              children: "New Agent Session"
             }
           )
         }
@@ -43940,7 +43939,7 @@ function SessionsPage({
       agentSessions.length > 0 && /* @__PURE__ */ jsxs(Fragment, { children: [
         /* @__PURE__ */ jsx(Divider, {}),
         /* @__PURE__ */ jsxs(Stack, { gap: "xs", children: [
-          /* @__PURE__ */ jsx(Text, { size: "sm", fw: 600, style: { fontFamily: "var(--mantine-font-family-headings)" }, children: "Existing Sessions" }),
+          /* @__PURE__ */ jsx(Text, { size: "sm", fw: 600, style: { fontFamily: "var(--mantine-font-family-headings)" }, children: "Existing Agent Sessions" }),
           agentSessions.map((session) => /* @__PURE__ */ jsx(
             SessionListItem,
             {
@@ -43962,7 +43961,7 @@ function SessionsPage({
       agent.resourceId
     )) }) : /* @__PURE__ */ jsx(Paper, { withBorder: true, children: /* @__PURE__ */ jsxs(Stack, { align: "center", py: "xl", children: [
       /* @__PURE__ */ jsx(Text, { c: "dimmed", children: "No agents available" }),
-      /* @__PURE__ */ jsx(Text, { size: "sm", c: "dimmed", children: "Register agents to start conversation sessions" })
+      /* @__PURE__ */ jsx(Text, { size: "sm", c: "dimmed", children: "Register agents to start agent sessions" })
     ] }) }) })
   ] });
 }
@@ -44572,7 +44571,7 @@ function SessionsSidebar({
   const hasSessionsData = agentSessions.length > 0;
   const isInitialLoading = !isReady || !organizationReady || isResourcesLoading && !hasResourcesData || isSessionView && (isCurrentSessionLoading || isSessionsLoading) && !hasSessionsData;
   return /* @__PURE__ */ jsxs(Box, { style: { flex: 1, minHeight: 0, padding: theme.spacing.sm, display: "flex", flexDirection: "column" }, children: [
-    /* @__PURE__ */ jsx(Text, { size: "xs", fw: 600, c: "dimmed", tt: "uppercase", mb: "md", children: isSessionView ? "Sessions" : "Agents" }),
+    /* @__PURE__ */ jsx(Text, { size: "xs", fw: 600, c: "dimmed", tt: "uppercase", mb: "md", children: isSessionView ? "Agent Sessions" : "Agents" }),
     /* @__PURE__ */ jsx(ScrollArea, { style: { flex: 1, minHeight: 0 }, scrollbarSize: 8, children: isInitialLoading ? /* @__PURE__ */ jsx(SubshellSidebarLoader, {}) : isSessionView ? agentSessions.length > 0 ? /* @__PURE__ */ jsx(Stack, { gap: "xs", children: agentSessions.map((session) => /* @__PURE__ */ jsx(
       SessionListItem,
       {
@@ -44581,7 +44580,7 @@ function SessionsSidebar({
         isSelected: sessionId === session.sessionId
       },
       session.sessionId
-    )) }) : /* @__PURE__ */ jsx(Center, { p: "xl", children: /* @__PURE__ */ jsx(Text, { size: "sm", c: "dimmed", fs: "italic", children: "No sessions found" }) }) : agents.length > 0 ? /* @__PURE__ */ jsx(Stack, { gap: "xs", children: agents.map((agent) => /* @__PURE__ */ jsx(
+    )) }) : /* @__PURE__ */ jsx(Center, { p: "xl", children: /* @__PURE__ */ jsx(Text, { size: "sm", c: "dimmed", fs: "italic", children: "No agent sessions found" }) }) : agents.length > 0 ? /* @__PURE__ */ jsx(Stack, { gap: "xs", children: agents.map((agent) => /* @__PURE__ */ jsx(
       AgentListItem,
       {
         agent,
@@ -50273,7 +50272,7 @@ function ConceptInfoControl({ description }) {
 var indexPromise = null;
 function loadSearchIndex() {
   if (!indexPromise) {
-    indexPromise = import('./knowledge-search-index-MHOBQTT3.js').then(
+    indexPromise = import('./knowledge-search-index-JOPRYZN6.js').then(
       (mod) => buildSearchIndex(mod.default ?? mod)
     );
   }
@@ -51039,4 +51038,4 @@ function useAccess(key) {
   };
 }
 
-export { APIErrorAlert, AbsoluteScheduleForm, AccessGuard, AccessKeys, AccountSettings, ActionModal, ActivityCard, ActivityFeed, ActivityFeedWidget, ActivityFilters, ActivityLog, ActivityTable, ActivityTimeline, ActivityTrendChart, AgentDefinitionDisplay, AgentExecutionLogs, AgentExecutionPanel, AgentExecutionTimeline, AgentExecutionVisualizer, AgentIterationEdge, AgentIterationNode, AgentResourceEntrySchema, AgentSessionGroup, AllTasksPage, ApiKeyDisplayModal, ApiKeyList, ApiKeyService, ApiKeySettings, AppErrorBoundary, AppShellCenteredContainer, AppShellContainer, AppShellContentContainer, AppShellError, AppShellLoader, AppShellRightSideContainer, AppShellRightSideOuterContainer, AppTopbarAdjusterWrapper, AppearanceContext, AppearanceProvider, AppearanceSettings, BaseEdge, BaseExecutionLogs, BaseExecutionLogsHeader, BaseExecutionLogsStates, BaseNode, Breadcrumbs, BusinessImpactCard, CRM_ITEMS, CenteredErrorState, ChartFrame, Checklist, CheckpointGroup, CollapsibleJsonSection, CollapsibleSection, CollapsibleSidebarGroup, CombinedTrendChart, CommandQueueDetailPage, CommandQueuePage, CommandQueueShell, CommandQueueSidebar, CommandQueueSidebarMiddle, CommandQueueSidebarTop, CommandQueueTaskRow, CommandViewPage, CompanyDetailPage, ConfigCard, ConfirmationInputModal, ConfirmationModal, ContactDetailPage, ContentSections, ContextUsageBadge, ContextViewer, ContractDisplay, ConversationThread, CostAnalytics, CostBreakdownCard, CostByModelTable, CostMetricsCard, CostTrendChart, CrashErrorFallback, CreateApiKeyModal, CreateCredentialModal, CreateDeliveryEntityModal, CreateRoleModal, CreateScheduleModal, CreateWebhookEndpointModal, CredentialList, CredentialService, CredentialSettings, CrmActionsProvider, CrmOverview, CrmSettingsPage, CrmSidebar, CrmSidebarMiddle, CrmSidebarTop, CustomModal, CustomSelector, CyberAreaChart, CyberDonut, CyberDonutTooltip, CyberLegendItem, CyberParticles, DEAL_STAGES, DEAL_STAGE_COLORS, DEAL_STAGE_OPTIONS, DEFAULT_KANBAN_CONFIG, DEFAULT_SEMANTIC_ICON_REGISTRY, DELIVERY_COMMUNICATION_ITEMS, DELIVERY_PROJECT_ITEMS, DELIVERY_WORK_ITEMS, Dashboard, DashboardOperationsOverview, DealDetailPage, DealKanbanCard, DealsListPage, DeleteScheduleModal, DeploymentDetailModal, DeploymentList, DeploymentService, DeploymentSettings, DeploymentStatusBadge, DetailCardSkeleton, EMPTY_LIST_ACTIONS, EditApiKeyModal, EditCredentialModal, EditWebhookEndpointModal, ElevasisCoreProvider, ElevasisLoader, ElevasisSystemsProvider, ElevasisUIProvider, EmptyState, EmptyVisualizer, ErrorAnalysisCard, ErrorBreakdownTable, ErrorDetailsModal, ErrorReportCard, ExecuteWorkflowModal, ExecutionBreakdownTable, ExecutionErrorSection, ExecutionHealth, ExecutionHealthCard, ExecutionLogsFilters, ExecutionLogsPage, ExecutionLogsTable, ExecutionPanel, ExecutionStats, ExecutionStatusBadge, FILTERABLE_DOMAIN_KEYS, FeatureUnavailableState, FilterBar, GlowDot, GraphBackground, GraphContainer, GraphFitViewButton, GraphFitViewHandler, GraphLegend, HealthStatusCard, HeroStatsRow, IdentityDomainSchema, IntegrationResourceEntrySchema, JsonViewer, KNOWLEDGE_DOMAINS_WITH_PANELS, KNOWLEDGE_ICON_TOKEN_BY_KIND, KanbanBoard, KnowledgeSearchBar, KnowledgeTree, LEAD_GEN_ITEMS, LEAD_GEN_ROUTE_LINKS, LeadGenCompaniesPage, LeadGenContactsPage, LeadGenListDetailPage, LeadGenListsPage, LeadGenOverviewPage, LeadGenRouteShell, LeadGenSidebar, LeadGenSidebarMiddle, LeadGenSidebarTop, LinksGroup, ListActionsProvider, ListBuilderIndexPage, ListBuilderPage, ListSkeleton, LogEntry, LogGroup, MdxRenderer, MemberAccessModal, MembershipStatusBadge, MetricsStrip, MilestoneTimeline, MyRolesPage, MyTasksPanel, NavigationButton, NewKnowledgeMapEdge, NewKnowledgeMapGraph, NewKnowledgeMapNode, NoAccessState, NotificationBell, NotificationCenter, NotificationItem, NotificationList, NotificationPanel, NotificationProvider, OAuthConnectModal, OAuthIntegrationsCard, OM_NESTED_TREE_GROUPS, OM_TREE_GROUPS, ORPHAN_STAGE_ORDER, OperationsOverview, OperationsService, OperationsSidebar, OperationsSidebarMiddle, OperationsSidebarTop, OrgMembersList, OrganizationGraphPage, OrganizationMembershipService, OrganizationMembershipsList, OrganizationProvider, OrganizationSettings, OrganizationSwitcher, OrganizationSwitcherConnected, PIPELINE_FUNNEL_ORDER, PageContainer, PageNotFound, PageTitleCaption, PermissionMatrix, PipelineFunnelWidget, PolicySchema, ProjectDetailPage, ProjectsListPage, ProjectsSidebar, ProjectsSidebarMiddle, ProjectsSidebarTop, ProtectedRoute, QuickCreateActions, RecentExecutionsByResource, RecurringScheduleForm, RelativeScheduleForm, RequestActionIcon, RequestModal, ResourceCard, ResourceDefinitionSection, ResourceDetailPage, ResourceErrorState, ResourceFilter, ResourceHeader, ResourceHealthChart, ResourceHealthPanel, ResourceNotFoundState, ResourceOverview, ResourcesPage, ResourcesSidebar, RichTextEditor, RoleBadge, RoleSchema, RunResourceButton, SAVED_VIEW_PRESETS, SavedViewsPanel, ScheduleCard, ScheduleDetailModal, ScheduleTypeSelector, ScriptResourceEntrySchema, SemanticIcon, SessionChatArea, SessionChatInterface, SessionChatPage, SessionDetailsSidebar, SessionExecutionLogs, SessionHeader, SessionListItem, SessionMemory, SessionsPage, SessionsSidebar, Sidebar, SidebarContext, SidebarProvider, SortableHeader, StatCard, StatCardSkeleton, StatsCardSkeleton, StatusBadge, StepConfigForm, SubshellContainer, SubshellContentContainer, SubshellLoader, SubshellNavList, SubshellRightSideContainer, SubshellSidebar, SubshellSidebarLoader, SurfaceDefinitionSchema, SystemOpsView, SystemShell, TabCountBadge, TabSection, TableSelectionToolbar, TaskCard, TaskScheduler, TimeRangeSelector, TimelineAxis, TimelineBar, TimelineContainer, TimelineRow, ToolsListDisplay, Topbar, TopbarActions, TopbarContainer, TrendIndicator, UnifiedWorkflowEdge, UnifiedWorkflowGraph, UnifiedWorkflowNode, UnresolvedErrorsTeaser, UpcomingMilestonesPage, Vignette, VisualizerContainer, WebhookEndpointList, WebhookEndpointService, WebhookEndpointSettings, WebhookUrlDisplayModal, WorkflowDefinitionDisplay, WorkflowExecutionLogs, WorkflowExecutionPanel, WorkflowExecutionTimeline, WorkflowResourceEntrySchema, ZodFormRenderer, acquisitionListKeys, aggregateSystemMetrics, buildErrorReport, buildKnowledgeOmTreeData, calculateProgress, clientsKeys, collectResourceFilterFacets, companyKeys, contactKeys, createOrganizationsSlice, createTestSystemsProvider, createUseOrgInitialization, createUseOrganizations, crmManifest, crmPrioritySettingsKeys, dealKeys, dealNoteKeys, dealTaskKeys, deliveryManifest, deriveBusinessProgress, executionsKeys, extendSemanticIconRegistry, filterByDomainFilters, findKnowledgeTreeNodeByValue, findListActionByAction, findOmTreeGroup, formatDate3 as formatDate, formatDealStageLabel, formatResourceAttribution, formatStatusLabel, getConceptDefinition, getEnrichmentColor, getEnrichmentStatus, getExecutionStatusConfig, getGraphBackgroundStyles, getHealthColor, getIcon, getKnowledgeDomainFolderCommand, getKnowledgeGraphNodeCommand, getKnowledgeIconToken, getKnowledgeNodeReadCommand, getKnowledgeOntologyProjection, getKnowledgeTreeFolderCommand, getLeadGenApiInterfaceReadiness, getLeadGenExportWorkflowId, getListActionWorkflowId, getLogLevelConfig, getOntologyDomainLabel, getPrimaryOntologyItemsForDomain, getResourceFilterFacetIds, getSemanticIconComponent, getSeriesColor, getSharedOrganizationGraph, getStateKeyColor, getStatusColor4 as getStatusColor, getStepActionLabel, iconMap, isLeadGenExportAction, isSessionCapable, knowledgeManifest, labelResourceFilterFacet, leadGenArtifactKeys, leadGenListCompanyKeys, leadGenListMemberKeys, leadGenManifest, mdxComponents, milestoneKeys, milestoneStatusColors, monitoringManifest, normaliseConceptKey, noteKeys, noteTypeColors, observabilityKeys, operationsKeys, operationsManifest, projectActivityKeys, projectKeys, projectNavigationGroups, projectNavigationSurfaces, projectStatusColors, requestTopbarActionManifest, requestsKeys, resolveBuildPlanSteps, resolveBuildState, resolveSemanticIconComponent, scheduleKeys, sessionsKeys, settingsManifest, showApiErrorNotification, showAuthError, showErrorNotification, showInfoNotification, showSuccessNotification, showWarningNotification, sortData, sortStageKeys, subsidebarWidth, taskKeys, taskStatusColors, taskTypeColors, useAccess, useActivateDeployment, useActivities, useActivitiesRealtime, useActivityFilters, useActivityTrend, useAddCompaniesToList, useAddContactsToList, useAppearance, useArchiveSession, useArchivedLogs, useArtifacts, useAssignRole, useBatchDelete, useBatchTelemetry, useBatchedResourcesHealth, useBreadcrumbs, useBulkDeleteExecutions, useBusinessImpact, useCancelExecution, useCancelSchedule, useCheckpointTasks, useClient, useClientStatus, useClients, useCommandQueue, useCommandQueueTotals, useCommandViewData, useCommandViewDomainFilters, useCommandViewStats, useCommandViewStore, useCompanies, useCompany, useCompanyFacets, useCompleteDealTask, useContact, useContacts, useCostBreakdown, useCostByModel, useCostSummary, useCostTrends, useCreateApiKey, useCreateArtifact, useCreateClient, useCreateCompany, useCreateContact, useCreateCredential, useCreateDealNote, useCreateDealTask, useCreateList, useCreateMilestone, useCreateNote, useCreateOrgRole, useCreateProject, useCreateSchedule, useCreateSession, useCreateTask, useCreateWebhookEndpoint, useCredentials, useCrmActions, useCrmPipelineSummary, useCrmPrioritySettings, useCrmQuickMetrics, useCyberColors, useDashboardMetrics, useDeactivateDeployment, useDeactivateMembership, useDealDetail, useDealNotes, useDealTasks, useDealTasksDue, useDeals, useDealsLookup, useDealsSummary, useDeleteApiKey, useDeleteClient, useDeleteCompanies, useDeleteContacts, useDeleteCredential, useDeleteDeal, useDeleteDeployment, useDeleteExecution, useDeleteList, useDeleteLists, useDeleteMilestone, useDeleteOrgRole, useDeleteProject, useDeleteRequest, useDeleteSchedule, useDeleteSession, useDeleteTask, useDeleteTask2, useDeleteWebhookEndpoint, useDeriveActions, useEffectivePermissions, useElevasisSystems, useErrorAnalysis, useErrorDetail, useErrorDetails, useErrorDistribution, useErrorNotification, useErrorTrends, useExecuteAction, useExecuteAsync, useExecuteResource, useExecution, useExecutionHealth, useExecutionLogSSE, useExecutionLogs, useExecutionLogsFilters, useExecutionPanelState, useExecutionSSE, useExecutions, useGetExecutionHistory, useGetSchedule, useGraphBackgroundStyles, useGraphTheme, useInFlightExecutions, useLeadGenConfig, useList, useListActions, useListApiKeys, useListDeployments, useListExecutions, useListMember, useListMembers, useListProgress, useListRecords, useListSchedules, useListWebhookEndpoints, useLists, useListsTelemetry, useMarkAllAsRead, useMarkAsRead, useMilestones, useNewKnowledgeMapLayout, useNotificationAdapter, useNotificationCount, useNotifications, useOptionalElevasisSystems, useOrgRoles, useOrganizationMembers, usePaginationState, usePatchTask, usePauseSchedule, usePermissionCatalog, useProject, useProjectActivities, useProjectMilestones, useProjectNotes, useProjectRealtime, useProjectTasks, useProjects, useReactivateMembership, useRecentCrmActivity, useRecentExecutionsByResource, useRemoveCompaniesFromList, useRequest, useRequestsList, useResetCrmPrioritySettings, useResolveAllErrors, useResolveError, useResolveErrorsByExecution, useResolvedOrganizationModel, useResourceDefinition, useResourceErrors, useResourceExecutions, useResourceSearch, useResources, useResourcesDomainFilters, useResourcesHealth, useResumeSchedule, useRetryExecution, useRevokeRole, useSSEConnection, useScheduledTasks, useSession, useSessionCheck, useSessionExecution, useSessionExecutions, useSessionMessages, useSessionWebSocket, useSessions, useSidebar, useSidebarCollapse, useSortedData, useStableAccessToken, useStatusFilter, useSubmitAction, useSubmitRequest, useSuccessNotification, useSystemHealth, useTableSelection, useTableSort, useTasks, useTestNotification, useTimeRangeDates, useTopFailingResources, useTransitionItem, useTransitionListCompany, useTransitionListMember, useTransitionState, useUnresolveError, useUnresolvedErrors, useUpdateAnchor, useUpdateApiKey, useUpdateClient, useUpdateCompany, useUpdateContact, useUpdateCredential, useUpdateCrmPrioritySettings, useUpdateList, useUpdateListConfig, useUpdateListStatus, useUpdateMilestone, useUpdateOrgRole, useUpdateProject, useUpdateRequestStatus, useUpdateSchedule, useUpdateTask, useUpdateWebhookEndpoint, useUserMemberships, useVerifyCredential, useVisibleResources, useWarningNotification, useWorkflowExecution };
+export { APIErrorAlert, AbsoluteScheduleForm, AccessGuard, AccessKeys, AccountSettings, ActionModal, ActivityCard, ActivityFeed, ActivityFeedWidget, ActivityFilters, ActivityLog, ActivityTable, ActivityTimeline, ActivityTrendChart, AgentDefinitionDisplay, AgentExecutionLogs, AgentExecutionPanel, AgentExecutionTimeline, AgentExecutionVisualizer, AgentIterationEdge, AgentIterationNode, AgentResourceEntrySchema, AgentSessionGroup, AllTasksPage, ApiKeyDisplayModal, ApiKeyList, ApiKeyService, ApiKeySettings, AppErrorBoundary, AppShellCenteredContainer, AppShellContainer, AppShellContentContainer, AppShellError, AppShellLoader, AppShellRightSideContainer, AppShellRightSideOuterContainer, AppTopbarAdjusterWrapper, AppearanceContext, AppearanceProvider, AppearanceSettings, BaseEdge, BaseExecutionLogs, BaseExecutionLogsHeader, BaseExecutionLogsStates, BaseNode, Breadcrumbs, BusinessImpactCard, CRM_ITEMS, CenteredErrorState, ChartFrame, Checklist, CheckpointGroup, CollapsibleJsonSection, CollapsibleSection, CollapsibleSidebarGroup, CombinedTrendChart, CommandQueueDetailPage, CommandQueuePage, CommandQueueShell, CommandQueueSidebar, CommandQueueSidebarMiddle, CommandQueueSidebarTop, CommandQueueTaskRow, CommandViewPage, CompanyDetailPage, ConfigCard, ConfirmationInputModal, ConfirmationModal, ContactDetailPage, ContentSections, ContextUsageBadge, ContextViewer, ContractDisplay, ConversationThread, CostAnalytics, CostBreakdownCard, CostByModelTable, CostMetricsCard, CostTrendChart, CrashErrorFallback, CreateApiKeyModal, CreateCredentialModal, CreateDeliveryEntityModal, CreateRoleModal, CreateScheduleModal, CreateWebhookEndpointModal, CredentialList, CredentialService, CredentialSettings, CrmActionsProvider, CrmOverview, CrmSettingsPage, CrmSidebar, CrmSidebarMiddle, CrmSidebarTop, CustomModal, CustomSelector, CyberAreaChart, CyberDonut, CyberDonutTooltip, CyberLegendItem, CyberParticles, DEAL_STAGES, DEAL_STAGE_COLORS, DEAL_STAGE_OPTIONS, DEFAULT_KANBAN_CONFIG, DEFAULT_SEMANTIC_ICON_REGISTRY, DELIVERY_COMMUNICATION_ITEMS, DELIVERY_PROJECT_ITEMS, DELIVERY_WORK_ITEMS, Dashboard, DashboardOperationsOverview, DealDetailPage, DealKanbanCard, DealsListPage, DeleteScheduleModal, DeploymentDetailModal, DeploymentList, DeploymentService, DeploymentSettings, DeploymentStatusBadge, DetailCardSkeleton, EMPTY_LIST_ACTIONS, EditApiKeyModal, EditCredentialModal, EditWebhookEndpointModal, ElevasisCoreProvider, ElevasisLoader, ElevasisSystemsProvider, ElevasisUIProvider, EmptyState, EmptyVisualizer, ErrorAnalysisCard, ErrorBreakdownTable, ErrorDetailsModal, ErrorReportCard, ExecuteWorkflowModal, ExecutionBreakdownTable, ExecutionErrorSection, ExecutionHealth, ExecutionHealthCard, ExecutionLogsFilters, ExecutionLogsPage, ExecutionLogsTable, ExecutionPanel, ExecutionStats, ExecutionStatusBadge, FILTERABLE_DOMAIN_KEYS, FeatureUnavailableState, FilterBar, GlowDot, GraphBackground, GraphContainer, GraphFitViewButton, GraphFitViewHandler, GraphLegend, HealthStatusCard, HeroStatsRow, IdentityDomainSchema, IntegrationResourceEntrySchema, JsonViewer, KNOWLEDGE_DOMAINS_WITH_PANELS, KNOWLEDGE_ICON_TOKEN_BY_KIND, KanbanBoard, KnowledgeSearchBar, KnowledgeTree, LEAD_GEN_ITEMS, LEAD_GEN_ROUTE_LINKS, LeadGenCompaniesPage, LeadGenContactsPage, LeadGenListDetailPage, LeadGenListsPage, LeadGenOverviewPage, LeadGenRouteShell, LeadGenSidebar, LeadGenSidebarMiddle, LeadGenSidebarTop, LinksGroup, ListActionsProvider, ListBuilderIndexPage, ListBuilderPage, ListSkeleton, LogEntry, LogGroup, MdxRenderer, MemberAccessModal, MembershipStatusBadge, MetricsStrip, MilestoneTimeline, MyRolesPage, MyTasksPanel, NavigationButton, NewKnowledgeMapEdge, NewKnowledgeMapGraph, NewKnowledgeMapNode, NoAccessState, NotificationBell, NotificationCenter, NotificationItem, NotificationList, NotificationPanel, NotificationProvider, OAuthConnectModal, OAuthIntegrationsCard, OM_NESTED_TREE_GROUPS, OM_TREE_GROUPS, ORPHAN_STAGE_ORDER, OperationsOverview, OperationsService, OperationsSidebar, OperationsSidebarMiddle, OperationsSidebarTop, OrgMembersList, OrganizationGraphPage, OrganizationMembershipService, OrganizationMembershipsList, OrganizationProvider, OrganizationSettings, OrganizationSwitcher, OrganizationSwitcherConnected, PIPELINE_FUNNEL_ORDER, PageContainer, PageNotFound, PageTitleCaption, PermissionMatrix, PipelineFunnelWidget, PolicySchema, ProjectDetailPage, ProjectsListPage, ProjectsSidebar, ProjectsSidebarMiddle, ProjectsSidebarTop, ProtectedRoute, QuickCreateActions, RecentExecutionsByResource, RecurringScheduleForm, RelativeScheduleForm, RequestActionIcon, RequestModal, ResourceCard, ResourceDefinitionSection, ResourceDetailPage, ResourceErrorState, ResourceFilter, ResourceHeader, ResourceHealthChart, ResourceHealthPanel, ResourceNotFoundState, ResourceOverview, ResourcesPage, ResourcesSidebar, RichTextEditor, RoleBadge, RoleSchema, RunResourceButton, SAVED_VIEW_PRESETS, SavedViewsPanel, ScheduleCard, ScheduleDetailModal, ScheduleTypeSelector, ScriptResourceEntrySchema, SemanticIcon, SessionChatArea, SessionChatInterface, SessionChatPage, SessionDetailsSidebar, SessionExecutionLogs, SessionHeader, SessionListItem, SessionMemory, SessionsPage, SessionsSidebar, Sidebar, SidebarContext, SidebarProvider, SortableHeader, StatCard, StatCardSkeleton, StatsCardSkeleton, StatusBadge, StepConfigForm, SubshellContainer, SubshellContentContainer, SubshellLoader, SubshellNavList, SubshellRightSideContainer, SubshellSidebar, SubshellSidebarLoader, SurfaceDefinitionSchema, SystemOpsView, SystemShell, TabCountBadge, TabSection, TableSelectionToolbar, TaskCard, TaskScheduler, TimeRangeSelector, TimelineAxis, TimelineBar, TimelineContainer, TimelineRow, ToolsListDisplay, Topbar, TopbarActions, TopbarContainer, TrendIndicator, UnifiedWorkflowEdge, UnifiedWorkflowGraph, UnifiedWorkflowNode, UnresolvedErrorsTeaser, UpcomingMilestonesPage, Vignette, VisualizerContainer, WebhookEndpointList, WebhookEndpointService, WebhookEndpointSettings, WebhookUrlDisplayModal, WorkflowDefinitionDisplay, WorkflowExecutionLogs, WorkflowExecutionPanel, WorkflowExecutionTimeline, WorkflowResourceEntrySchema, ZodFormRenderer, acquisitionListKeys, aggregateSystemMetrics, buildErrorReport, buildKnowledgeOmTreeData, calculateProgress, clientsKeys, collectResourceFilterFacets, companyKeys, contactKeys, createOrganizationsSlice, createTestSystemsProvider, createUseOrgInitialization, createUseOrganizations, crmManifest, crmPrioritySettingsKeys, dealKeys, dealNoteKeys, dealTaskKeys, deliveryManifest, deriveBusinessProgress, executionsKeys, extendSemanticIconRegistry, filterByDomainFilters, findKnowledgeTreeNodeByValue, findListActionByAction, findOmTreeGroup, formatDate3 as formatDate, formatDealStageLabel, formatResourceAttribution, formatStatusLabel, getConceptDefinition, getEnrichmentColor, getEnrichmentStatus, getExecutionStatusConfig, getGraphBackgroundStyles, getHealthColor, getIcon, getKnowledgeDomainFolderCommand, getKnowledgeGraphNodeCommand, getKnowledgeIconToken, getKnowledgeNodeReadCommand, getKnowledgeOntologyProjection, getKnowledgeTreeFolderCommand, getLeadGenApiInterfaceReadiness, getLeadGenExportWorkflowId, getListActionWorkflowId, getLogLevelConfig, getOntologyDomainLabel, getPrimaryOntologyItemsForDomain, getResourceFilterFacetIds, getSemanticIconComponent, getSeriesColor, getSharedOrganizationGraph, getStateKeyColor, getStatusColor4 as getStatusColor, getStepActionLabel, iconMap, isLeadGenExportAction, isSessionCapable, knowledgeManifest, labelResourceFilterFacet, leadGenArtifactKeys, leadGenListCompanyKeys, leadGenListMemberKeys, leadGenManifest, mdxComponents, milestoneKeys, milestoneStatusColors, monitoringManifest, normaliseConceptKey, noteKeys, noteTypeColors, observabilityKeys, operationsKeys, operationsManifest, projectActivityKeys, projectKeys, projectNavigationGroups, projectNavigationSurfaces, projectStatusColors, requestTopbarActionManifest, requestsKeys, resolveBuildPlanSteps, resolveBuildState, resolveSemanticIconComponent, scheduleKeys, sessionsKeys, settingsManifest, showApiErrorNotification, showAuthError, showErrorNotification, showInfoNotification, showSuccessNotification, showWarningNotification, sortData, sortStageKeys, subsidebarWidth, taskKeys, taskStatusColors, taskTypeColors, useAccess, useActivateDeployment, useActivities, useActivitiesRealtime, useActivityFilters, useActivityTrend, useAddCompaniesToList, useAddContactsToList, useAppearance, useArchiveSession, useArchivedLogs, useArtifacts, useAssignRole, useBatchDelete, useBatchTelemetry, useBatchedResourcesHealth, useBreadcrumbs, useBulkDeleteExecutions, useBusinessImpact, useCancelExecution, useCancelSchedule, useCheckpointTasks, useClient, useClientStatus, useClients, useCommandQueue, useCommandQueueTask, useCommandQueueTotals, useCommandViewData, useCommandViewDomainFilters, useCommandViewStats, useCommandViewStore, useCompanies, useCompany, useCompanyFacets, useCompleteDealTask, useContact, useContacts, useCostBreakdown, useCostByModel, useCostSummary, useCostTrends, useCreateApiKey, useCreateArtifact, useCreateClient, useCreateCompany, useCreateContact, useCreateCredential, useCreateDealNote, useCreateDealTask, useCreateList, useCreateMilestone, useCreateNote, useCreateOrgRole, useCreateProject, useCreateSchedule, useCreateSession, useCreateTask, useCreateWebhookEndpoint, useCredentials, useCrmActions, useCrmPipelineSummary, useCrmPrioritySettings, useCrmQuickMetrics, useCyberColors, useDashboardMetrics, useDeactivateDeployment, useDeactivateMembership, useDealDetail, useDealNotes, useDealTasks, useDealTasksDue, useDeals, useDealsLookup, useDealsSummary, useDeleteApiKey, useDeleteClient, useDeleteCompanies, useDeleteContacts, useDeleteCredential, useDeleteDeal, useDeleteDeployment, useDeleteExecution, useDeleteList, useDeleteLists, useDeleteMilestone, useDeleteOrgRole, useDeleteProject, useDeleteRequest, useDeleteSchedule, useDeleteSession, useDeleteTask, useDeleteTask2, useDeleteWebhookEndpoint, useDeriveActions, useEffectivePermissions, useElevasisSystems, useErrorAnalysis, useErrorDetail, useErrorDetails, useErrorDistribution, useErrorNotification, useErrorTrends, useExecuteAction, useExecuteAsync, useExecuteResource, useExecution, useExecutionHealth, useExecutionLogSSE, useExecutionLogs, useExecutionLogsFilters, useExecutionPanelState, useExecutionSSE, useExecutions, useGetExecutionHistory, useGetSchedule, useGraphBackgroundStyles, useGraphTheme, useInFlightExecutions, useLeadGenConfig, useList, useListActions, useListApiKeys, useListDeployments, useListExecutions, useListMember, useListMembers, useListProgress, useListRecords, useListSchedules, useListWebhookEndpoints, useLists, useListsTelemetry, useMarkAllAsRead, useMarkAsRead, useMilestones, useNewKnowledgeMapLayout, useNotificationAdapter, useNotificationCount, useNotifications, useOptionalElevasisSystems, useOrgRoles, useOrganizationMembers, usePaginationState, usePatchTask, usePauseSchedule, usePermissionCatalog, useProject, useProjectActivities, useProjectMilestones, useProjectNotes, useProjectRealtime, useProjectTasks, useProjects, useReactivateMembership, useRecentCrmActivity, useRecentExecutionsByResource, useRemoveCompaniesFromList, useRequest, useRequestsList, useResetCrmPrioritySettings, useResolveAllErrors, useResolveError, useResolveErrorsByExecution, useResolvedOrganizationModel, useResourceDefinition, useResourceErrors, useResourceExecutions, useResourceSearch, useResources, useResourcesDomainFilters, useResourcesHealth, useResumeSchedule, useRetryExecution, useRevokeRole, useSSEConnection, useScheduledTasks, useSession, useSessionCheck, useSessionExecution, useSessionExecutions, useSessionMessages, useSessionWebSocket, useSessions, useSidebar, useSidebarCollapse, useSortedData, useStableAccessToken, useStatusFilter, useSubmitAction, useSubmitRequest, useSuccessNotification, useSystemHealth, useTableSelection, useTableSort, useTasks, useTestNotification, useTimeRangeDates, useTopFailingResources, useTransitionItem, useTransitionListCompany, useTransitionListMember, useTransitionState, useUnresolveError, useUnresolvedErrors, useUpdateAnchor, useUpdateApiKey, useUpdateClient, useUpdateCompany, useUpdateContact, useUpdateCredential, useUpdateCrmPrioritySettings, useUpdateList, useUpdateListConfig, useUpdateListStatus, useUpdateMilestone, useUpdateOrgRole, useUpdateProject, useUpdateRequestStatus, useUpdateSchedule, useUpdateTask, useUpdateWebhookEndpoint, useUserMemberships, useVerifyCredential, useVisibleResources, useWarningNotification, useWorkflowExecution };