@elevasis/ui 2.71.0 → 2.73.0

package/dist/hooks/published.js

@@ -1,10 +1,10 @@
-export { AccessKeys, ApiKeyService, CredentialService, DeploymentService, OperationsService, OrganizationMembershipService, WebhookEndpointService, acquisitionListKeys, clientsKeys, collectResourceFilterFacets, companyKeys, contactKeys, contentKeys, dealKeys, dealNoteKeys, dealTaskKeys, executionsKeys, filterByDomainFilters, getResourceFilterFacetIds, isSessionCapable, labelResourceFilterFacet, leadGenArtifactKeys, leadGenListCompanyKeys, leadGenListMemberKeys, observabilityKeys, operationsKeys, pickLatestRunAt, projectActivityKeys, requestsKeys, scheduleKeys, sessionsKeys, sortData, sumStatusCounts, useAccess, useActivateDeployment, useActivities, useActivitiesRealtime, useActivityFilters, useActivityTrend, useAddCompaniesToList, useAddContactsToList, useArchiveSession, useArchivedLogs, useArtifacts, useAssignRole, useBatchDelete, useBatchTelemetry, useBatchedResourcesHealth, useBulkDeleteExecutions, useBusinessImpact, useCancelExecution, useCancelSchedule, useCheckpointTasks, useClient, useClientStatus, useClients, useCommandQueue, useCommandQueueTask, useCommandQueueTotals, useCommandViewData, useCommandViewDomainFilters, useCommandViewStats, useCommandViewStore, useCompanies, useCompany, useCompanyFacets, useCompleteDealTask, useContact, useContacts, useContentDistribution, useContentDistributions, useContentItem, useContentItemAttempts, useContentItems, useContentPipelineSummary, useContentSourceAsset, useContentSourceAssets, useCostBreakdown, useCostByModel, useCostSummary, useCostTrends, useCreateApiKey, useCreateArtifact, useCreateClient, useCreateCompany, useCreateContact, useCreateContentSourceAsset, useCreateCredential, useCreateDealNote, useCreateDealTask, useCreateList, useCreateOrgRole, useCreateSchedule, useCreateSession, useCreateWebhookEndpoint, useCredentials, useDashboardMetrics, useDeactivateDeployment, useDeactivateMembership, useDealDetail, useDealNotes, useDealTasks, useDealTasksDue, useDeals, useDealsLookup, useDealsSummary, useDeleteApiKey, useDeleteClient, useDeleteCompanies, useDeleteContacts, useDeleteCredential, useDeleteDeal, useDeleteDeployment, useDeleteExecution, useDeleteList, useDeleteOrgRole, useDeleteRequest, useDeleteSchedule, useDeleteSession, useDeleteTask, useDeleteWebhookEndpoint, useDeriveActions, useEffectivePermissions, useEndSession, useErrorAnalysis, useErrorDetail, useErrorDetails, useErrorDistribution, useErrorNotification, useErrorTrends, useExecuteAction, useExecuteAsync, useExecuteResource, useExecution, useExecutionHealth, useExecutionLogSSE, useExecutionLogs, useExecutionLogsFilters, useExecutionPanelState, useExecutionSSE, useExecutions, useGetExecutionHistory, useGetSchedule, useInFlightExecutions, useList, useListApiKeys, useListDeployments, useListExecutions, useListMember, useListMembers, useListProgress, useListRecords, useListSchedules, useListWebhookEndpoints, useLists, useListsTelemetry, useMarkAllAsRead, useMarkAsRead, useNotificationCount as useNotificationCountSSE, useNotifications, useOrgRoles, useOrganizationMembers, useOrganizationModelDrift, usePaginationState, usePatchTask, usePauseSchedule, usePermissionCatalog, useProjectActivities, useProjectRealtime, useReactivateMembership, useRecentExecutionsByResource, useRemoveCompaniesFromList, useRequest, useRequestsList, useResolveAllErrors, useResolveError, useResolveErrorsByExecution, useResourceDefinition, useResourceErrors, useResourceExecutions, useResourceSearch, useResources, useResourcesDomainFilters, useResourcesHealth, useResumeSchedule, useRetryExecution, useReviewContentItem, useRevokeRole, useSSEConnection, useScheduledTasks, useSession, useSessionExecution, useSessionExecutions, useSessionMessages, useSessionWebSocket, useSessions, useSortedData, useStatusFilter, useSubmitAction, useSubmitRequest, useSuccessNotification, useSystemHealth, useTableSelection, useTableSort, useTestNotification, useTimeRangeDates, useTopFailingResources, useTransitionItem, useTransitionListCompany, useTransitionListMember, useTransitionState, useUnresolveError, useUnresolvedErrors, useUpdateAnchor, useUpdateApiKey, useUpdateClient, useUpdateCompany, useUpdateContact, useUpdateContentDistribution, useUpdateContentItem, useUpdateContentSourceAsset, useUpdateCredential, useUpdateList, useUpdateListConfig, useUpdateListStatus, useUpdateOrgRole, useUpdateRequestStatus, useUpdateSchedule, useUpdateWebhookEndpoint, useUserMemberships, useVerifyCredential, useVisibleResources, useWarningNotification, useWorkflowExecution } from '../chunk-UZ7MSORW.js';
+export { AccessKeys, ApiKeyService, CredentialService, DeploymentService, OperationsService, OrganizationMembershipService, SIGNED_URL_EXPIRES_IN_SECONDS, TEMPORARY_LINK_STALE_MS, THUMBNAIL_BATCH_SIZE, WebhookEndpointService, acquisitionListKeys, chunkIntoBatches, clientsKeys, cloudStorageKeys, collectResourceFilterFacets, companyKeys, contactKeys, contentKeys, dealKeys, dealNoteKeys, dealTaskKeys, executionsKeys, filterByDomainFilters, getResourceFilterFacetIds, isSessionCapable, joinSourceAssetDetails, labelResourceFilterFacet, leadGenArtifactKeys, leadGenListCompanyKeys, leadGenListMemberKeys, measureImageDimensions, mergeThumbnailBatches, observabilityKeys, operationsKeys, pickCoverSourceAsset, pickLatestRunAt, projectActivityKeys, readItemSourceAssets, requestsKeys, scheduleKeys, sessionsKeys, sortData, storageKeys, storageObjectRefKey, sumStatusCounts, useAccess, useActivateDeployment, useActivities, useActivitiesRealtime, useActivityFilters, useActivityTrend, useAddCompaniesToList, useAddContactsToList, useAddContentItemSourceAsset, useArchiveSession, useArchivedLogs, useArtifacts, useAssignRole, useBatchDelete, useBatchTelemetry, useBatchedResourcesHealth, useBulkDeleteExecutions, useBusinessImpact, useCancelExecution, useCancelSchedule, useCheckpointTasks, useClient, useClientStatus, useClients, useCloudStorageFolder, useCloudStorageImageDimensions, useCloudStorageTemporaryLinks, useCloudStorageThumbnails, useCommandQueue, useCommandQueueTask, useCommandQueueTotals, useCommandViewData, useCommandViewDomainFilters, useCommandViewStats, useCommandViewStore, useCompanies, useCompany, useCompanyFacets, useCompleteDealTask, useContact, useContacts, useContentDistribution, useContentDistributions, useContentItem, useContentItemAttempts, useContentItemSourceAssetDetails, useContentItemSourceAssets, useContentItems, useContentPipelineSummary, useContentSourceAsset, useContentSourceAssets, useCostBreakdown, useCostByModel, useCostSummary, useCostTrends, useCreateApiKey, useCreateArtifact, useCreateClient, useCreateCompany, useCreateContact, useCreateContentDistribution, useCreateContentItem, useCreateContentSourceAsset, useCreateCredential, useCreateDealNote, useCreateDealTask, useCreateList, useCreateOrgRole, useCreateSchedule, useCreateSession, useCreateWebhookEndpoint, useCredentials, useDashboardMetrics, useDeactivateDeployment, useDeactivateMembership, useDealDetail, useDealNotes, useDealTasks, useDealTasksDue, useDeals, useDealsLookup, useDealsSummary, useDeleteApiKey, useDeleteClient, useDeleteCompanies, useDeleteContacts, useDeleteCredential, useDeleteDeal, useDeleteDeployment, useDeleteExecution, useDeleteList, useDeleteOrgRole, useDeleteRequest, useDeleteSchedule, useDeleteSession, useDeleteTask, useDeleteWebhookEndpoint, useDeriveActions, useEffectivePermissions, useEndSession, useErrorAnalysis, useErrorDetail, useErrorDetails, useErrorDistribution, useErrorNotification, useErrorTrends, useExecuteAction, useExecuteAsync, useExecuteResource, useExecution, useExecutionHealth, useExecutionLogSSE, useExecutionLogs, useExecutionLogsFilters, useExecutionPanelState, useExecutionSSE, useExecutions, useGetExecutionHistory, useGetSchedule, useInFlightExecutions, useList, useListApiKeys, useListDeployments, useListExecutions, useListMember, useListMembers, useListProgress, useListRecords, useListSchedules, useListWebhookEndpoints, useLists, useListsTelemetry, useMarkAllAsRead, useMarkAsRead, useNotificationCount as useNotificationCountSSE, useNotifications, useOrgRoles, useOrganizationMembers, useOrganizationModelDrift, usePaginationState, usePatchTask, usePauseSchedule, usePermissionCatalog, useProjectActivities, useProjectRealtime, useReactivateMembership, useRecentExecutionsByResource, useRemoveCompaniesFromList, useRemoveContentItemSourceAsset, useReorderContentItemSourceAssets, useRequest, useRequestsList, useResolveAllErrors, useResolveError, useResolveErrorsByExecution, useResourceDefinition, useResourceErrors, useResourceExecutions, useResourceSearch, useResources, useResourcesDomainFilters, useResourcesHealth, useResumeSchedule, useRetryExecution, useReviewContentItem, useRevokeRole, useSSEConnection, useScheduledTasks, useSession, useSessionExecution, useSessionExecutions, useSessionMessages, useSessionWebSocket, useSessions, useSortedData, useStatusFilter, useStorageSignedUrls, useSubmitAction, useSubmitRequest, useSuccessNotification, useSystemHealth, useTableSelection, useTableSort, useTestNotification, useTimeRangeDates, useTopFailingResources, useTransitionItem, useTransitionListCompany, useTransitionListMember, useTransitionState, useUnresolveError, useUnresolvedErrors, useUpdateAnchor, useUpdateApiKey, useUpdateClient, useUpdateCompany, useUpdateContact, useUpdateContentDistribution, useUpdateContentItem, useUpdateContentItemSourceAsset, useUpdateContentSourceAsset, useUpdateCredential, useUpdateList, useUpdateListConfig, useUpdateListStatus, useUpdateOrgRole, useUpdateRequestStatus, useUpdateSchedule, useUpdateWebhookEndpoint, useUploadStorageFile, useUserMemberships, useVerifyCredential, useVisibleResources, useWarningNotification, useWorkflowExecution } from '../chunk-OCVSPAKM.js';
 import '../chunk-R6NMRXNO.js';
 import '../chunk-RBGVNPA6.js';
 import '../chunk-MKH2KOAO.js';
-import '../chunk-VDX6DL7Z.js';
+import '../chunk-NHNTX6ZL.js';
 import '../chunk-L7BZZ4SI.js';
-export { milestoneKeys, noteKeys, projectKeys, taskKeys, useCreateProject as useCreateDeliveryProject, useCreateMilestone, useCreateNote, useCreateTask, useDeleteProject as useDeleteDeliveryProject, useDeleteTask as useDeleteDeliveryTask, useDeleteMilestone, useMilestones, useProject, useProjectMilestones, useProjectNotes, useProjectTasks, useProjects, useTasks, useUpdateProject as useUpdateDeliveryProject, useUpdateMilestone, useUpdateTask } from '../chunk-C75XWBYZ.js';
+export { milestoneKeys, noteKeys, projectKeys, taskKeys, useCreateProject as useCreateDeliveryProject, useCreateMilestone, useCreateNote, useCreateTask, useDeleteProject as useDeleteDeliveryProject, useDeleteTask as useDeleteDeliveryTask, useDeleteMilestone, useMilestones, useProject, useProjectMilestones, useProjectNotes, useProjectTasks, useProjects, useTasks, useUpdateProject as useUpdateDeliveryProject, useUpdateMilestone, useUpdateTask } from '../chunk-U2H3TIHD.js';
 import '../chunk-MISHPEJX.js';
 import '../chunk-62GVNH5U.js';
 import '../chunk-P45GQ3ZW.js';
@@ -16,7 +16,7 @@ import '../chunk-UD657ICS.js';
 import '../chunk-DD3CCMCZ.js';
 import '../chunk-RNP5R5I3.js';
 import '../chunk-RT4KRGZT.js';
-import '../chunk-NM4A63KJ.js';
+import '../chunk-IBCEAVB2.js';
 export { REFETCH_INTERVAL_RUNNING, WS_MAX_RETRIES_BEFORE_ERROR, WS_RECONNECT_BASE_DELAY, WS_RECONNECT_MAX_DELAY } from '../chunk-Y6I3IC45.js';
 import '../chunk-6SSQGWK7.js';
 import '../chunk-BI5VDO2K.js';

package/dist/initialization/index.d.ts

@@ -1603,6 +1603,63 @@ type Database = {
                     }
                 ];
             };
+            content_item_source_assets: {
+                Row: {
+                    alt_text: string | null;
+                    content_item_id: string;
+                    created_at: string;
+                    crop: Json | null;
+                    derivative_crop: Json | null;
+                    derivative_path: string | null;
+                    derivative_rendered_at: string | null;
+                    id: string;
+                    organization_id: string;
+                    position: number;
+                    source_asset_id: string;
+                };
+                Insert: {
+                    alt_text?: string | null;
+                    content_item_id: string;
+                    created_at?: string;
+                    crop?: Json | null;
+                    derivative_crop?: Json | null;
+                    derivative_path?: string | null;
+                    derivative_rendered_at?: string | null;
+                    id?: string;
+                    organization_id: string;
+                    position: number;
+                    source_asset_id: string;
+                };
+                Update: {
+                    alt_text?: string | null;
+                    content_item_id?: string;
+                    created_at?: string;
+                    crop?: Json | null;
+                    derivative_crop?: Json | null;
+                    derivative_path?: string | null;
+                    derivative_rendered_at?: string | null;
+                    id?: string;
+                    organization_id?: string;
+                    position?: number;
+                    source_asset_id?: string;
+                };
+                Relationships: [
+                    {
+                        foreignKeyName: "content_item_source_assets_asset_fkey";
+                        columns: ["source_asset_id", "organization_id"];
+                        isOneToOne: false;
+                        referencedRelation: "content_source_assets";
+                        referencedColumns: ["id", "organization_id"];
+                    },
+                    {
+                        foreignKeyName: "content_item_source_assets_item_fkey";
+                        columns: ["content_item_id", "organization_id"];
+                        isOneToOne: false;
+                        referencedRelation: "content_items";
+                        referencedColumns: ["id", "organization_id"];
+                    }
+                ];
+            };
             content_items: {
                 Row: {
                     body: string | null;
@@ -3358,6 +3415,25 @@ type Database = {
                 };
                 Returns: Json;
             };
+            activate_deployment_atomic: {
+                Args: {
+                    p_deployment_id: string;
+                    p_organization_id: string;
+                };
+                Returns: {
+                    created_at: string;
+                    deployment_version: string | null;
+                    error_message: string | null;
+                    id: string;
+                    organization_id: string;
+                    pid: number | null;
+                    port: number | null;
+                    sdk_version: string;
+                    status: string;
+                    tarball_path: string | null;
+                    updated_at: string;
+                };
+            };
             append_deal_activity: {
                 Args: {
                     p_activity: Json;

package/dist/knowledge/index.d.ts

@@ -13,7 +13,9 @@ declare const OntologyScopeSchema: z.ZodDefault<z.ZodObject<{
         aliases: z.ZodOptional<z.ZodArray<z.ZodString>>;
         properties: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodUnknown>>;
         storage: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodUnknown>>;
-    }, z.core.$loose>>>>;
+        rowSchema: z.ZodOptional<z.ZodString>;
+        stateCatalogId: z.ZodOptional<z.ZodString>;
+    }, z.core.$strict>>>>;
     linkTypes: z.ZodOptional<z.ZodDefault<z.ZodRecord<z.ZodString, z.ZodObject<{
         id: z.ZodString;
         label: z.ZodOptional<z.ZodString>;
@@ -24,7 +26,7 @@ declare const OntologyScopeSchema: z.ZodDefault<z.ZodObject<{
         to: z.ZodString;
         cardinality: z.ZodOptional<z.ZodString>;
         via: z.ZodOptional<z.ZodString>;
-    }, z.core.$loose>>>>;
+    }, z.core.$strict>>>>;
     actionTypes: z.ZodOptional<z.ZodDefault<z.ZodRecord<z.ZodString, z.ZodObject<{
         id: z.ZodString;
         label: z.ZodOptional<z.ZodString>;
@@ -34,7 +36,11 @@ declare const OntologyScopeSchema: z.ZodDefault<z.ZodObject<{
         actsOn: z.ZodOptional<z.ZodDefault<z.ZodArray<z.ZodString>>>;
         input: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodUnknown>>;
         effects: z.ZodOptional<z.ZodArray<z.ZodRecord<z.ZodString, z.ZodUnknown>>>;
-    }, z.core.$loose>>>>;
+        resourceId: z.ZodOptional<z.ZodString>;
+        invocations: z.ZodOptional<z.ZodArray<z.ZodUnknown>>;
+        lifecycle: z.ZodOptional<z.ZodString>;
+        legacyActionId: z.ZodOptional<z.ZodString>;
+    }, z.core.$strict>>>>;
     catalogTypes: z.ZodOptional<z.ZodDefault<z.ZodRecord<z.ZodString, z.ZodObject<{
         id: z.ZodString;
         label: z.ZodOptional<z.ZodString>;
@@ -44,7 +50,10 @@ declare const OntologyScopeSchema: z.ZodDefault<z.ZodObject<{
         kind: z.ZodOptional<z.ZodString>;
         appliesTo: z.ZodOptional<z.ZodString>;
         entries: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodUnknown>>;
-    }, z.core.$loose>>>>;
+        legacyCatalogKey: z.ZodOptional<z.ZodString>;
+        legacyPipelineKey: z.ZodOptional<z.ZodString>;
+        legacyEntityKey: z.ZodOptional<z.ZodString>;
+    }, z.core.$strict>>>>;
     eventTypes: z.ZodOptional<z.ZodDefault<z.ZodRecord<z.ZodString, z.ZodObject<{
         id: z.ZodString;
         label: z.ZodOptional<z.ZodString>;
@@ -52,7 +61,7 @@ declare const OntologyScopeSchema: z.ZodDefault<z.ZodObject<{
         ownerSystemId: z.ZodOptional<z.ZodString>;
         aliases: z.ZodOptional<z.ZodArray<z.ZodString>>;
         payload: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodUnknown>>;
-    }, z.core.$loose>>>>;
+    }, z.core.$strict>>>>;
     interfaceTypes: z.ZodOptional<z.ZodDefault<z.ZodRecord<z.ZodString, z.ZodObject<{
         id: z.ZodString;
         label: z.ZodOptional<z.ZodString>;
@@ -60,7 +69,7 @@ declare const OntologyScopeSchema: z.ZodDefault<z.ZodObject<{
         ownerSystemId: z.ZodOptional<z.ZodString>;
         aliases: z.ZodOptional<z.ZodArray<z.ZodString>>;
         properties: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodUnknown>>;
-    }, z.core.$loose>>>>;
+    }, z.core.$strict>>>>;
     valueTypes: z.ZodOptional<z.ZodDefault<z.ZodRecord<z.ZodString, z.ZodObject<{
         id: z.ZodString;
         label: z.ZodOptional<z.ZodString>;
@@ -68,7 +77,7 @@ declare const OntologyScopeSchema: z.ZodDefault<z.ZodObject<{
         ownerSystemId: z.ZodOptional<z.ZodString>;
         aliases: z.ZodOptional<z.ZodArray<z.ZodString>>;
         primitive: z.ZodOptional<z.ZodString>;
-    }, z.core.$loose>>>>;
+    }, z.core.$strict>>>>;
     sharedProperties: z.ZodOptional<z.ZodDefault<z.ZodRecord<z.ZodString, z.ZodObject<{
         id: z.ZodString;
         label: z.ZodOptional<z.ZodString>;
@@ -78,7 +87,7 @@ declare const OntologyScopeSchema: z.ZodDefault<z.ZodObject<{
         valueType: z.ZodOptional<z.ZodString>;
         searchable: z.ZodOptional<z.ZodBoolean>;
         pii: z.ZodOptional<z.ZodBoolean>;
-    }, z.core.$loose>>>>;
+    }, z.core.$strict>>>>;
     groups: z.ZodOptional<z.ZodDefault<z.ZodRecord<z.ZodString, z.ZodObject<{
         id: z.ZodString;
         label: z.ZodOptional<z.ZodString>;
@@ -86,7 +95,7 @@ declare const OntologyScopeSchema: z.ZodDefault<z.ZodObject<{
         ownerSystemId: z.ZodOptional<z.ZodString>;
         aliases: z.ZodOptional<z.ZodArray<z.ZodString>>;
         members: z.ZodOptional<z.ZodDefault<z.ZodArray<z.ZodString>>>;
-    }, z.core.$loose>>>>;
+    }, z.core.$strict>>>>;
     endpoints: z.ZodOptional<z.ZodDefault<z.ZodRecord<z.ZodString, z.ZodObject<{
         id: z.ZodString;
         label: z.ZodOptional<z.ZodString>;
@@ -94,8 +103,8 @@ declare const OntologyScopeSchema: z.ZodDefault<z.ZodObject<{
         ownerSystemId: z.ZodOptional<z.ZodString>;
         aliases: z.ZodOptional<z.ZodArray<z.ZodString>>;
         route: z.ZodOptional<z.ZodString>;
-    }, z.core.$loose>>>>;
-}, z.core.$strip>>;
+    }, z.core.$strict>>>>;
+}, z.core.$strict>>;
 type OntologyScope = z.infer<typeof OntologyScopeSchema>;
 
 declare const SystemApiInterfaceSchema: z.ZodObject<{
@@ -818,7 +827,9 @@ declare const OrganizationModelSchema: z.ZodObject<{
             aliases: z.ZodOptional<z.ZodArray<z.ZodString>>;
             properties: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodUnknown>>;
             storage: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodUnknown>>;
-        }, z.core.$loose>>>>;
+            rowSchema: z.ZodOptional<z.ZodString>;
+            stateCatalogId: z.ZodOptional<z.ZodString>;
+        }, z.core.$strict>>>>;
         linkTypes: z.ZodOptional<z.ZodDefault<z.ZodRecord<z.ZodString, z.ZodObject<{
             id: z.ZodString;
             label: z.ZodOptional<z.ZodString>;
@@ -829,7 +840,7 @@ declare const OrganizationModelSchema: z.ZodObject<{
             to: z.ZodString;
             cardinality: z.ZodOptional<z.ZodString>;
             via: z.ZodOptional<z.ZodString>;
-        }, z.core.$loose>>>>;
+        }, z.core.$strict>>>>;
         actionTypes: z.ZodOptional<z.ZodDefault<z.ZodRecord<z.ZodString, z.ZodObject<{
             id: z.ZodString;
             label: z.ZodOptional<z.ZodString>;
@@ -839,7 +850,11 @@ declare const OrganizationModelSchema: z.ZodObject<{
             actsOn: z.ZodOptional<z.ZodDefault<z.ZodArray<z.ZodString>>>;
             input: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodUnknown>>;
             effects: z.ZodOptional<z.ZodArray<z.ZodRecord<z.ZodString, z.ZodUnknown>>>;
-        }, z.core.$loose>>>>;
+            resourceId: z.ZodOptional<z.ZodString>;
+            invocations: z.ZodOptional<z.ZodArray<z.ZodUnknown>>;
+            lifecycle: z.ZodOptional<z.ZodString>;
+            legacyActionId: z.ZodOptional<z.ZodString>;
+        }, z.core.$strict>>>>;
         catalogTypes: z.ZodOptional<z.ZodDefault<z.ZodRecord<z.ZodString, z.ZodObject<{
             id: z.ZodString;
             label: z.ZodOptional<z.ZodString>;
@@ -849,7 +864,10 @@ declare const OrganizationModelSchema: z.ZodObject<{
             kind: z.ZodOptional<z.ZodString>;
             appliesTo: z.ZodOptional<z.ZodString>;
             entries: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodUnknown>>;
-        }, z.core.$loose>>>>;
+            legacyCatalogKey: z.ZodOptional<z.ZodString>;
+            legacyPipelineKey: z.ZodOptional<z.ZodString>;
+            legacyEntityKey: z.ZodOptional<z.ZodString>;
+        }, z.core.$strict>>>>;
         eventTypes: z.ZodOptional<z.ZodDefault<z.ZodRecord<z.ZodString, z.ZodObject<{
             id: z.ZodString;
             label: z.ZodOptional<z.ZodString>;
@@ -857,7 +875,7 @@ declare const OrganizationModelSchema: z.ZodObject<{
             ownerSystemId: z.ZodOptional<z.ZodString>;
             aliases: z.ZodOptional<z.ZodArray<z.ZodString>>;
             payload: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodUnknown>>;
-        }, z.core.$loose>>>>;
+        }, z.core.$strict>>>>;
         interfaceTypes: z.ZodOptional<z.ZodDefault<z.ZodRecord<z.ZodString, z.ZodObject<{
             id: z.ZodString;
             label: z.ZodOptional<z.ZodString>;
@@ -865,7 +883,7 @@ declare const OrganizationModelSchema: z.ZodObject<{
             ownerSystemId: z.ZodOptional<z.ZodString>;
             aliases: z.ZodOptional<z.ZodArray<z.ZodString>>;
             properties: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodUnknown>>;
-        }, z.core.$loose>>>>;
+        }, z.core.$strict>>>>;
         valueTypes: z.ZodOptional<z.ZodDefault<z.ZodRecord<z.ZodString, z.ZodObject<{
             id: z.ZodString;
             label: z.ZodOptional<z.ZodString>;
@@ -873,7 +891,7 @@ declare const OrganizationModelSchema: z.ZodObject<{
             ownerSystemId: z.ZodOptional<z.ZodString>;
             aliases: z.ZodOptional<z.ZodArray<z.ZodString>>;
             primitive: z.ZodOptional<z.ZodString>;
-        }, z.core.$loose>>>>;
+        }, z.core.$strict>>>>;
         sharedProperties: z.ZodOptional<z.ZodDefault<z.ZodRecord<z.ZodString, z.ZodObject<{
             id: z.ZodString;
             label: z.ZodOptional<z.ZodString>;
@@ -883,7 +901,7 @@ declare const OrganizationModelSchema: z.ZodObject<{
             valueType: z.ZodOptional<z.ZodString>;
             searchable: z.ZodOptional<z.ZodBoolean>;
             pii: z.ZodOptional<z.ZodBoolean>;
-        }, z.core.$loose>>>>;
+        }, z.core.$strict>>>>;
         groups: z.ZodOptional<z.ZodDefault<z.ZodRecord<z.ZodString, z.ZodObject<{
             id: z.ZodString;
             label: z.ZodOptional<z.ZodString>;
@@ -891,7 +909,7 @@ declare const OrganizationModelSchema: z.ZodObject<{
             ownerSystemId: z.ZodOptional<z.ZodString>;
             aliases: z.ZodOptional<z.ZodArray<z.ZodString>>;
             members: z.ZodOptional<z.ZodDefault<z.ZodArray<z.ZodString>>>;
-        }, z.core.$loose>>>>;
+        }, z.core.$strict>>>>;
         endpoints: z.ZodOptional<z.ZodDefault<z.ZodRecord<z.ZodString, z.ZodObject<{
             id: z.ZodString;
             label: z.ZodOptional<z.ZodString>;
@@ -899,8 +917,8 @@ declare const OrganizationModelSchema: z.ZodObject<{
             ownerSystemId: z.ZodOptional<z.ZodString>;
             aliases: z.ZodOptional<z.ZodArray<z.ZodString>>;
             route: z.ZodOptional<z.ZodString>;
-        }, z.core.$loose>>>>;
-    }, z.core.$strip>>>;
+        }, z.core.$strict>>>>;
+    }, z.core.$strict>>>;
     resources: z.ZodDefault<z.ZodDefault<z.ZodRecord<z.ZodString, z.ZodDiscriminatedUnion<[z.ZodObject<{
         id: z.ZodString;
         order: z.ZodDefault<z.ZodNumber>;

package/dist/knowledge/index.js

@@ -1,15 +1,15 @@
-import '../chunk-DH2MO5DX.js';
-import '../chunk-AIOV5NM7.js';
-import '../chunk-DCMFNSJ6.js';
+import '../chunk-CJ2232PQ.js';
+import '../chunk-Z4ICFQXG.js';
+import '../chunk-3TS5U5BL.js';
 import { PageContainer } from '../chunk-BZZCNLT6.js';
-import { getConceptDefinition, normaliseConceptKey, SemanticIcon, getKnowledgeIconToken, getKnowledgeGraphNodeCommand, IdentityDomainSchema, WorkflowResourceEntrySchema, AgentResourceEntrySchema, IntegrationResourceEntrySchema, ScriptResourceEntrySchema, findOmTreeGroup, SubshellContentContainer, getKnowledgeNodeReadCommand, getKnowledgeOntologyProjection, getPrimaryOntologyItemsForDomain, projectNavigationSurfaces, projectNavigationGroups, SurfaceDefinitionSchema, RoleSchema, getOntologyDomainLabel, getKnowledgeDomainFolderCommand, buildKnowledgeOmTreeData, findKnowledgeTreeNodeByValue, getKnowledgeTreeFolderCommand, KNOWLEDGE_DOMAINS_WITH_PANELS } from '../chunk-UZ7MSORW.js';
-export { FILTERABLE_DOMAIN_KEYS, KNOWLEDGE_DOMAINS_WITH_PANELS, KNOWLEDGE_ICON_TOKEN_BY_KIND, KnowledgeSearchBar, KnowledgeTree, OM_NESTED_TREE_GROUPS, OM_TREE_GROUPS, SemanticIcon, buildKnowledgeOmTreeData, extendSemanticIconRegistry, findKnowledgeTreeNodeByValue, findOmTreeGroup, getKnowledgeIconToken, getSemanticIconComponent, getSharedOrganizationGraph, resolveSemanticIconComponent } from '../chunk-UZ7MSORW.js';
+import { getConceptDefinition, normaliseConceptKey, SemanticIcon, getKnowledgeIconToken, getKnowledgeGraphNodeCommand, IdentityDomainSchema, WorkflowResourceEntrySchema, AgentResourceEntrySchema, IntegrationResourceEntrySchema, ScriptResourceEntrySchema, findOmTreeGroup, SubshellContentContainer, getKnowledgeNodeReadCommand, getKnowledgeOntologyProjection, getPrimaryOntologyItemsForDomain, projectNavigationSurfaces, projectNavigationGroups, SurfaceDefinitionSchema, RoleSchema, getOntologyDomainLabel, getKnowledgeDomainFolderCommand, buildKnowledgeOmTreeData, findKnowledgeTreeNodeByValue, getKnowledgeTreeFolderCommand, KNOWLEDGE_DOMAINS_WITH_PANELS } from '../chunk-OCVSPAKM.js';
+export { FILTERABLE_DOMAIN_KEYS, KNOWLEDGE_DOMAINS_WITH_PANELS, KNOWLEDGE_ICON_TOKEN_BY_KIND, KnowledgeSearchBar, KnowledgeTree, OM_NESTED_TREE_GROUPS, OM_TREE_GROUPS, SemanticIcon, buildKnowledgeOmTreeData, extendSemanticIconRegistry, findKnowledgeTreeNodeByValue, findOmTreeGroup, getKnowledgeIconToken, getSemanticIconComponent, getSharedOrganizationGraph, resolveSemanticIconComponent } from '../chunk-OCVSPAKM.js';
 import { usePresetsContext } from '../chunk-R6NMRXNO.js';
 import '../chunk-RBGVNPA6.js';
 import '../chunk-MKH2KOAO.js';
-import '../chunk-VDX6DL7Z.js';
+import '../chunk-NHNTX6ZL.js';
 import '../chunk-L7BZZ4SI.js';
-import '../chunk-C75XWBYZ.js';
+import '../chunk-U2H3TIHD.js';
 import '../chunk-MISHPEJX.js';
 import '../chunk-62GVNH5U.js';
 import '../chunk-P45GQ3ZW.js';
@@ -21,7 +21,7 @@ import '../chunk-UD657ICS.js';
 import '../chunk-DD3CCMCZ.js';
 import '../chunk-RNP5R5I3.js';
 import '../chunk-RT4KRGZT.js';
-import { getSystem, SystemEntrySchema, EntitySchema, ActionSchema, OntologyIdSchema, ontologyGraphNodeId, compileOrganizationOntology, parseOntologyId } from '../chunk-NM4A63KJ.js';
+import { getSystem, SystemEntrySchema, EntitySchema, ActionSchema, OntologyIdSchema, ontologyGraphNodeId, compileOrganizationOntology, parseOntologyId } from '../chunk-IBCEAVB2.js';
 import '../chunk-Y6I3IC45.js';
 import '../chunk-6SSQGWK7.js';
 import '../chunk-BI5VDO2K.js';
@@ -683,11 +683,11 @@ function _createMdxContent(props) {
     }), "\\n", _jsxs(_components.ul, {
       children: ["\\n", _jsxs(_components.li, {
         children: ["Use ", _jsx(_components.code, {
-          children: "/om acquisition outreach"
+          children: "/internal acquisition outreach"
         }), " for campaign review and analytics."]
       }), "\\n", _jsxs(_components.li, {
         children: ["Use ", _jsx(_components.code, {
-          children: "/om acquisition inbound status"
+          children: "/internal acquisition inbound status"
         }), " for reply handling and active deal state."]
       }), "\\n", _jsx(_components.li, {
         children: "Watch open rate, reply rate, positive reply rate, and bounce rate."
@@ -5783,15 +5783,15 @@ function _createMdxContent(props) {
     }), "\\n", _jsxs(_components.ul, {
       children: ["\\n", _jsx(_components.li, {
         children: _jsx(_components.code, {
-          children: "/knowledge read knowledge.org-model-reference"
+          children: "/om read knowledge.org-model-reference"
         })
       }), "\\n", _jsx(_components.li, {
         children: _jsx(_components.code, {
-          children: "/knowledge read knowledge.platform-composition-patterns"
+          children: "/om read knowledge.platform-composition-patterns"
         })
       }), "\\n", _jsx(_components.li, {
         children: _jsx(_components.code, {
-          children: "/knowledge read knowledge.platform-integration-patterns"
+          children: "/om read knowledge.platform-integration-patterns"
         })
       }), "\\n"]
     })]
@@ -6284,11 +6284,11 @@ function _createMdxContent(props) {
     }), "\\n", _jsxs(_components.ul, {
       children: ["\\n", _jsx(_components.li, {
         children: _jsx(_components.code, {
-          children: "/knowledge read knowledge.platform-integration-patterns"
+          children: "/om read knowledge.platform-integration-patterns"
         })
       }), "\\n", _jsx(_components.li, {
         children: _jsx(_components.code, {
-          children: "/knowledge read knowledge.platform-command-view"
+          children: "/om read knowledge.platform-command-view"
         })
       }), "\\n"]
     })]
@@ -6780,15 +6780,15 @@ function _createMdxContent(props) {
     }), "\\n", _jsxs(_components.ul, {
       children: ["\\n", _jsx(_components.li, {
         children: _jsx(_components.code, {
-          children: "/knowledge read knowledge.platform-composition-patterns"
+          children: "/om read knowledge.platform-composition-patterns"
         })
       }), "\\n", _jsx(_components.li, {
         children: _jsx(_components.code, {
-          children: "/knowledge read knowledge.platform-command-view"
+          children: "/om read knowledge.platform-command-view"
         })
       }), "\\n", _jsx(_components.li, {
         children: _jsx(_components.code, {
-          children: "/knowledge read knowledge.platform-systems-overview"
+          children: "/om read knowledge.platform-systems-overview"
         })
       }), "\\n"]
     })]

package/dist/{knowledge-search-index-LP2WVSQX.js → knowledge-search-index-RZLIVWPJ.js}

@@ -269,8 +269,8 @@ Monitor and Optimize
 
 After launch, monitor both campaign metrics and inbound replies:
 
-- Use /om acquisition outreach for campaign review and analytics.
-- Use /om acquisition inbound status for reply handling and active deal state.
+- Use /internal acquisition outreach for campaign review and analytics.
+- Use /internal acquisition inbound status for reply handling and active deal state.
 - Watch open rate, reply rate, positive reply rate, and bounce rate.
 - Pause or repair the campaign if bounce rate rises above the accepted threshold.
 - Rework subject lines, personalization, or offer framing when reply rate is below target.
@@ -1436,19 +1436,19 @@ Actions follow a five-stage lifecycle: draft, beta, active, deprecated, archived
     id: "knowledge.platform-command-view",
     title: "Platform Command View",
     summary: "Reference for Command View, the visual Organization Model graph surface that projects systems, resources, actions, entities, and events into an explorable operational view.",
-    bodyText: "Overview\n\nCommand View is the visual surface for the Organization Model graph. It projects the OM -- systems, resources, actions, entities, and events -- 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 actions or topology relationships reference it?\n- What events originate from this entity or resource?\n\nAccess Command View through the Knowledge area at /knowledge/command-view.\n\nHow 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/config/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\nNode 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| 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, humancheckpoint, script.\n\nEdge 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| mapsto         | 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| originatesfrom | Event originates from an entity                                                |\n| triggers        | Topology relationship with kind: 'triggers'                                  |\n| approval        | Topology relationship with kind: 'approval'                                  |\n| appliesto      | Ontology catalog, offering, or surface scoped to its target                    |\n| actions         | Resource bound to an ontology action                                           |\n| reads           | Resource reads an ontology object                                              |\n| writes          | Resource writes an ontology object                                             |\n| usescatalog    | Resource uses an ontology catalog                                              |\n\nVisualization 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\nOrganization 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\nUsing Command View\n\nSystem 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 topology relationships wire this system to others?\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\nManifest 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. Topology relationships connect the correct source and target nodes.\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- Topology relationship references a node that was removed.\n\nTroubleshooting\n\nEmpty 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\nMissing 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\nMissing Edges\n\nLikely causes:\n\n- Action resourceId does not match any OM resource ID.\n- Entity ownedBySystemId references an unknown system.\n- Topology relationship source or target references an ID that does 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\nBest 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 topology.relationships when the nodes they wire 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\nRelated References\n\n- /knowledge read knowledge.org-model-reference\n- /knowledge read knowledge.platform-composition-patterns\n- /knowledge read knowledge.platform-integration-patterns"
+    bodyText: "Overview\n\nCommand View is the visual surface for the Organization Model graph. It projects the OM -- systems, resources, actions, entities, and events -- 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 actions or topology relationships reference it?\n- What events originate from this entity or resource?\n\nAccess Command View through the Knowledge area at /knowledge/command-view.\n\nHow 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/config/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\nNode 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| 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, humancheckpoint, script.\n\nEdge 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| mapsto         | 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| originatesfrom | Event originates from an entity                                                |\n| triggers        | Topology relationship with kind: 'triggers'                                  |\n| approval        | Topology relationship with kind: 'approval'                                  |\n| appliesto      | Ontology catalog, offering, or surface scoped to its target                    |\n| actions         | Resource bound to an ontology action                                           |\n| reads           | Resource reads an ontology object                                              |\n| writes          | Resource writes an ontology object                                             |\n| usescatalog    | Resource uses an ontology catalog                                              |\n\nVisualization 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\nOrganization 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\nUsing Command View\n\nSystem 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 topology relationships wire this system to others?\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\nManifest 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. Topology relationships connect the correct source and target nodes.\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- Topology relationship references a node that was removed.\n\nTroubleshooting\n\nEmpty 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\nMissing 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\nMissing Edges\n\nLikely causes:\n\n- Action resourceId does not match any OM resource ID.\n- Entity ownedBySystemId references an unknown system.\n- Topology relationship source or target references an ID that does 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\nBest 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 topology.relationships when the nodes they wire 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\nRelated References\n\n- /om read knowledge.org-model-reference\n- /om read knowledge.platform-composition-patterns\n- /om read knowledge.platform-integration-patterns"
   },
   {
     id: "knowledge.platform-composition-patterns",
     title: "Platform Composition Patterns",
     summary: "Reference for composing agents, workflows, integrations, tools, observability, scaling, error handling, and security into complete Elevasis automation systems.",
-    bodyText: "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\nSystem Architecture Patterns\n\nAgent-Centric Systems\n\nPattern: Agent is the primary orchestrator; workflows and integrations are tools.\n\ntext\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\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\nWorkflow-Centric Systems\n\nPattern: Workflow is the pipeline; agents are processing steps.\n\ntext\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\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\nHybrid Systems\n\nPattern: Agents decide, workflows execute. This is the recommended default for complex automation.\n\ntext\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\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\nResource Composition Patterns\n\nAgent + 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: attiogetrecord.\n- Knowledge Map tools: lazy-loaded, low-frequency operations such as write operations or domain-specific capabilities. Examples: attiocreatecontact, dropboxuploadfile.\n- Resource invocation tools: delegate to workflows for deterministic sequences or call specialist agents.\n\nTool creation example:\n\ntypescript\nconst tool = createAttioCreateRecordTool('elevasis-attio')\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\nAgent + Workflow\n\nUse an agent for reasoning and a workflow for deterministic execution.\n\ntext\nTrigger to Agent reasoning\n          |- Direct tool: read integration\n          |- Invoke tool: Workflow A\n          - Invoke tool: Workflow B\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\nWorkflow + Integration\n\nUse a workflow to orchestrate deterministic integration sequences.\n\ntext\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\nUse this pattern for predictable step sequences, data transformation pipelines, integration orchestration, and cost-sensitive work that does not need LLM reasoning.\n\nPattern 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\nCross-Cutting Concerns\n\nObservability\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\nCost 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\nScaling 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\nError 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\ntypescript\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\nSecurity\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\nBest 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\nRelated References\n\n- /knowledge read knowledge.platform-integration-patterns\n- /knowledge read knowledge.platform-command-view"
+    bodyText: "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\nSystem Architecture Patterns\n\nAgent-Centric Systems\n\nPattern: Agent is the primary orchestrator; workflows and integrations are tools.\n\ntext\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\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\nWorkflow-Centric Systems\n\nPattern: Workflow is the pipeline; agents are processing steps.\n\ntext\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\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\nHybrid Systems\n\nPattern: Agents decide, workflows execute. This is the recommended default for complex automation.\n\ntext\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\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\nResource Composition Patterns\n\nAgent + 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: attiogetrecord.\n- Knowledge Map tools: lazy-loaded, low-frequency operations such as write operations or domain-specific capabilities. Examples: attiocreatecontact, dropboxuploadfile.\n- Resource invocation tools: delegate to workflows for deterministic sequences or call specialist agents.\n\nTool creation example:\n\ntypescript\nconst tool = createAttioCreateRecordTool('elevasis-attio')\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\nAgent + Workflow\n\nUse an agent for reasoning and a workflow for deterministic execution.\n\ntext\nTrigger to Agent reasoning\n          |- Direct tool: read integration\n          |- Invoke tool: Workflow A\n          - Invoke tool: Workflow B\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\nWorkflow + Integration\n\nUse a workflow to orchestrate deterministic integration sequences.\n\ntext\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\nUse this pattern for predictable step sequences, data transformation pipelines, integration orchestration, and cost-sensitive work that does not need LLM reasoning.\n\nPattern 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\nCross-Cutting Concerns\n\nObservability\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\nCost 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\nScaling 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\nError 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\ntypescript\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\nSecurity\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\nBest 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\nRelated References\n\n- /om read knowledge.platform-integration-patterns\n- /om read knowledge.platform-command-view"
   },
   {
     id: "knowledge.platform-integration-patterns",
     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.",
-    bodyText: "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\nDirect Integration Pattern\n\nPattern: 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\ntext\npackages/core/src/execution/engine/tools/integration/server/adapters/{provider}/{provider}-tools.ts\n\nTool factories use createIntegrationTool() with a credentialName parameter. Example: createAttioCreateRecordTool(credentialName).\n\nIntegration Workflow Pattern\n\nPattern: 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\nShared Integration Pattern\n\nPattern: Multiple resources share the same integration.\n\nUse shared integrations for organization-wide providers that should use one credential set.\n\nExample:\n\ntext\npackages/elevasis/operations/src/index.ts\n\nCharacteristics:\n\n- One credential per integration.\n- Centralized credential management.\n- Shared across agents and workflows.\n\nMulti-Account Pattern\n\nPattern: Same provider, different credentials.\n\nUse this pattern for department-specific provider instances or separate dev/prod environments.\n\nExample:\n\ntypescript\nconst salesTool = createAttioCreateRecordTool('attio-sales')\nconst supportTool = createAttioCreateRecordTool('attio-support')\n\nDisambiguate multi-account tools with explicit tool names:\n\ntypescript\nconst tool = createAttioToolNamed(\n  'attiosalescreaterecord',\n  'attio-sales',\n  'createRecord'\n)\n\nAuthentication Patterns\n\nOAuth 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\nOAuth 2.0 Pattern\n\nProviders include Gmail and Google Sheets.\n\nCredential format:\n\ntypescript\ninterface OAuthToken {\n  provider: string\n  accessToken: string\n  refreshToken: string\n  expiresAt: string\n  tokenType: 'Bearer'\n  scope?: string\n}\n\nexpiresAt is an ISO 8601 timestamp. The platform handles token refresh when supported by the provider and credential implementation.\n\nAPI Key Pattern\n\nProviders include Attio and custom APIs.\n\nCredential format:\n\ntypescript\ninterface APIKeyCredentials {\n  apiKey: string\n}\n\nProvider-specific validation belongs in the adapter. For Attio, see:\n\ntext\npackages/core/src/execution/engine/tools/integration/server/adapters/attio/attio-adapter.ts\n\nCredential Management\n\nCredentials are stored in the credentials table.\n\nKey columns:\n\n- organizationid for tenant isolation.\n- name, such as elevasis-attio.\n- provider, such as gmail or attio.\n- encryptedvalue 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 organizationid.\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\ntext\npackages/core/src/execution/engine/tools/integration/tool.ts\n\nError Handling Patterns\n\nAdapters should convert provider errors into platform tooling errors.\n\nCommon error categories:\n\n- credentialsinvalid for invalid or missing credentials.\n- apierror for provider API errors.\n- networkerror for network or timeout failures.\n- validationerror for invalid parameters.\n- methodnotfound 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\nAdapter Development\n\nAdapter class location:\n\ntext\npackages/core/src/execution/engine/tools/integration/server/adapters/{provider}/{provider}-adapter.ts\n\nAdapter classes implement BaseIntegrationAdapter and contain call() and validateCredentials() methods.\n\nTool factory location:\n\ntext\npackages/core/src/execution/engine/tools/integration/server/adapters/{provider}/{provider}-tools.ts\n\nTool factories export create{Provider}{Operation}Tool(credentialName) functions.\n\nTests belong under:\n\ntext\npackages/core/src/execution/engine/tools/integration/server/adapters/{provider}/tests/\n\nRegistration happens in:\n\ntext\npackages/core/src/execution/engine/tools/integration/server/index.ts\n\nTesting 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\nRelated References\n\n- /knowledge read knowledge.platform-composition-patterns\n- /knowledge read knowledge.platform-command-view\n- /knowledge read knowledge.platform-systems-overview"
+    bodyText: "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\nDirect Integration Pattern\n\nPattern: 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\ntext\npackages/core/src/execution/engine/tools/integration/server/adapters/{provider}/{provider}-tools.ts\n\nTool factories use createIntegrationTool() with a credentialName parameter. Example: createAttioCreateRecordTool(credentialName).\n\nIntegration Workflow Pattern\n\nPattern: 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\nShared Integration Pattern\n\nPattern: Multiple resources share the same integration.\n\nUse shared integrations for organization-wide providers that should use one credential set.\n\nExample:\n\ntext\npackages/elevasis/operations/src/index.ts\n\nCharacteristics:\n\n- One credential per integration.\n- Centralized credential management.\n- Shared across agents and workflows.\n\nMulti-Account Pattern\n\nPattern: Same provider, different credentials.\n\nUse this pattern for department-specific provider instances or separate dev/prod environments.\n\nExample:\n\ntypescript\nconst salesTool = createAttioCreateRecordTool('attio-sales')\nconst supportTool = createAttioCreateRecordTool('attio-support')\n\nDisambiguate multi-account tools with explicit tool names:\n\ntypescript\nconst tool = createAttioToolNamed(\n  'attiosalescreaterecord',\n  'attio-sales',\n  'createRecord'\n)\n\nAuthentication Patterns\n\nOAuth 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\nOAuth 2.0 Pattern\n\nProviders include Gmail and Google Sheets.\n\nCredential format:\n\ntypescript\ninterface OAuthToken {\n  provider: string\n  accessToken: string\n  refreshToken: string\n  expiresAt: string\n  tokenType: 'Bearer'\n  scope?: string\n}\n\nexpiresAt is an ISO 8601 timestamp. The platform handles token refresh when supported by the provider and credential implementation.\n\nAPI Key Pattern\n\nProviders include Attio and custom APIs.\n\nCredential format:\n\ntypescript\ninterface APIKeyCredentials {\n  apiKey: string\n}\n\nProvider-specific validation belongs in the adapter. For Attio, see:\n\ntext\npackages/core/src/execution/engine/tools/integration/server/adapters/attio/attio-adapter.ts\n\nCredential Management\n\nCredentials are stored in the credentials table.\n\nKey columns:\n\n- organizationid for tenant isolation.\n- name, such as elevasis-attio.\n- provider, such as gmail or attio.\n- encryptedvalue 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 organizationid.\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\ntext\npackages/core/src/execution/engine/tools/integration/tool.ts\n\nError Handling Patterns\n\nAdapters should convert provider errors into platform tooling errors.\n\nCommon error categories:\n\n- credentialsinvalid for invalid or missing credentials.\n- apierror for provider API errors.\n- networkerror for network or timeout failures.\n- validationerror for invalid parameters.\n- methodnotfound 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\nAdapter Development\n\nAdapter class location:\n\ntext\npackages/core/src/execution/engine/tools/integration/server/adapters/{provider}/{provider}-adapter.ts\n\nAdapter classes implement BaseIntegrationAdapter and contain call() and validateCredentials() methods.\n\nTool factory location:\n\ntext\npackages/core/src/execution/engine/tools/integration/server/adapters/{provider}/{provider}-tools.ts\n\nTool factories export create{Provider}{Operation}Tool(credentialName) functions.\n\nTests belong under:\n\ntext\npackages/core/src/execution/engine/tools/integration/server/adapters/{provider}/tests/\n\nRegistration happens in:\n\ntext\npackages/core/src/execution/engine/tools/integration/server/index.ts\n\nTesting 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\nRelated References\n\n- /om read knowledge.platform-composition-patterns\n- /om read knowledge.platform-command-view\n- /om read knowledge.platform-systems-overview"
   },
   {
     id: "knowledge.platform-systems-overview",

package/dist/layout/index.js

@@ -1,14 +1,14 @@
-export { AppShellContainer, AppShellContentContainer, AppShellRightSideContainer, AppShellRightSideOuterContainer, AppTopbarAdjusterWrapper, CollapsibleSidebarGroup, CyberParticles, LinksGroup, Sidebar, SidebarContext, SidebarProvider, SubshellNavList, Topbar, TopbarActions, TopbarContainer, Vignette, subsidebarWidth, useSidebar, useSidebarCollapse } from '../chunk-DH2MO5DX.js';
-export { SubshellLoader } from '../chunk-AIOV5NM7.js';
-export { AppShellCenteredContainer, AppShellError, AppShellLoader } from '../chunk-DCMFNSJ6.js';
+export { AppShellContainer, AppShellContentContainer, AppShellRightSideContainer, AppShellRightSideOuterContainer, AppTopbarAdjusterWrapper, CollapsibleSidebarGroup, CyberParticles, LinksGroup, Sidebar, SidebarContext, SidebarProvider, SubshellNavList, Topbar, TopbarActions, TopbarContainer, Vignette, subsidebarWidth, useSidebar, useSidebarCollapse } from '../chunk-CJ2232PQ.js';
+export { SubshellLoader } from '../chunk-Z4ICFQXG.js';
+export { AppShellCenteredContainer, AppShellError, AppShellLoader } from '../chunk-3TS5U5BL.js';
 export { PageContainer } from '../chunk-BZZCNLT6.js';
-export { SubshellContainer, SubshellContentContainer, SubshellRightSideContainer, SubshellSidebar, SubshellSidebarLoader } from '../chunk-UZ7MSORW.js';
+export { SubshellContainer, SubshellContentContainer, SubshellRightSideContainer, SubshellSidebar, SubshellSidebarLoader } from '../chunk-OCVSPAKM.js';
 import '../chunk-R6NMRXNO.js';
 export { AmbientBloomGrid, AppBackground, CyberBackground, FilmGrain, FloatingMotes, FloatingOrbs, PerspectiveGrid, RadiantGlow, WaveBackground } from '../chunk-RBGVNPA6.js';
 import '../chunk-MKH2KOAO.js';
-import '../chunk-VDX6DL7Z.js';
+import '../chunk-NHNTX6ZL.js';
 import '../chunk-L7BZZ4SI.js';
-import '../chunk-C75XWBYZ.js';
+import '../chunk-U2H3TIHD.js';
 export { SubshellNavItem, SubshellSidebarSection, sidebarBottomSectionCollapsedHeight, sidebarBottomSectionHeight, sidebarCollapsedWidth, sidebarGroupChevronSize, sidebarHoverDelay, sidebarIconInnerSize, sidebarIconSize, sidebarIconStroke, sidebarItemGap, sidebarItemHeight, sidebarItemPadding, sidebarSectionPadding, sidebarSubLinkIndent, sidebarSubLinkPaddingX, sidebarSubLinkPaddingY, sidebarToggleIconSize, sidebarTransitionDuration, sidebarWidth, subshellNavItemIconSize, topbarHeight } from '../chunk-MISHPEJX.js';
 import '../chunk-62GVNH5U.js';
 import '../chunk-P45GQ3ZW.js';
@@ -20,7 +20,7 @@ import '../chunk-UD657ICS.js';
 import '../chunk-DD3CCMCZ.js';
 import '../chunk-RNP5R5I3.js';
 import '../chunk-RT4KRGZT.js';
-import '../chunk-NM4A63KJ.js';
+import '../chunk-IBCEAVB2.js';
 import '../chunk-Y6I3IC45.js';
 import '../chunk-6SSQGWK7.js';
 import '../chunk-BI5VDO2K.js';