@wildo-ai/platform-core-backend 1.1.4 → 1.1.5

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@wildo-ai/platform-core-backend",
-  "version": "1.1.4",
+  "version": "1.1.5",
   "description": "Custom Node.js backend library wildo.ai applications",
   "author": "Wildo AI",
   "license": "SEE LICENSE IN LICENSE",
@@ -29,15 +29,16 @@
     "test:watch": "vitest"
   },
   "dependencies": {
-    "@wildo-ai/platform-core-shared": "1.1.4",
-    "@wildo-ai/saas-backend-lib": "1.1.4",
-    "@wildo-ai/saas-models": "1.1.4",
-    "@wildo-ai/zod-decorators": "1.1.4"
+    "@wildo-ai/platform-core-shared": "1.1.5",
+    "@wildo-ai/saas-backend-lib": "1.1.5",
+    "@wildo-ai/saas-models": "1.1.5",
+    "@wildo-ai/zod-decorators": "1.1.5"
   },
   "devDependencies": {
     "@swc/core": "^1",
     "@types/node": "^24.0.15",
     "concurrently": "^9.1.0",
+    "reflect-metadata": "0.2.2",
     "rimraf": "^6.0.1",
     "tsc-alias": "1.8.16",
     "tsc-watch": "7.2.1",
@@ -45,15 +46,7 @@
     "vitest": "^1.6.1"
   },
   "peerDependencies": {
-    "axios": "^1.6.8",
-    "big.js": "^6.2.2",
-    "date-fns": "^4.1.0",
-    "express": "^5.1.0",
-    "inversify": "^8.1.0",
-    "lodash": "^4.17.23",
-    "reflect-metadata": "^0.2.2",
-    "ufo": "^1.6.3",
-    "zod": "^4.3.6"
+    "inversify": "^8.1.0"
   },
   "repository": {
     "type": "git",

package/dist/esm/flows-actors/factory-agents/index.d.ts

@@ -1,2 +0,0 @@
-export * from './prompts-library.agent-personna.backend.models';
-//# sourceMappingURL=index.d.ts.map

package/dist/esm/flows-actors/factory-agents/index.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../../../../src/flows-actors/factory-agents/index.ts"],"names":[],"mappings":"AACA,cAAc,iDAAiD,CAAC"}

package/dist/esm/flows-actors/factory-agents/index.js

@@ -1,3 +0,0 @@
-// Factory Agents Definitions
-export * from './prompts-library.agent-personna.backend.models.js';
-//# sourceMappingURL=index.js.map

package/dist/esm/flows-actors/factory-agents/index.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"index.js","sourceRoot":"","sources":["../../../../../src/flows-actors/factory-agents/index.ts"],"names":[],"mappings":"AAAA,6BAA6B;AAC7B,cAAc,iDAAiD,CAAC","sourcesContent":["// Factory Agents Definitions\nexport * from './prompts-library.agent-personna.backend.models';\n"]}

package/dist/esm/flows-actors/factory-agents/prompts-library.agent-personna.backend.models.d.ts

@@ -1,2 +0,0 @@
-export declare const cleanDescription: (description: string) => string;
-//# sourceMappingURL=prompts-library.agent-personna.backend.models.d.ts.map

package/dist/esm/flows-actors/factory-agents/prompts-library.agent-personna.backend.models.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"prompts-library.agent-personna.backend.models.d.ts","sourceRoot":"","sources":["../../../../src/flows-actors/factory-agents/prompts-library.agent-personna.backend.models.ts"],"names":[],"mappings":"AAUA,eAAO,MAAM,gBAAgB,GAAI,aAAa,MAAM,WAAiE,CAAC"}

package/dist/esm/flows-actors/factory-agents/prompts-library.agent-personna.backend.models.js

@@ -1,349 +0,0 @@
-// =============================================================================
-// Agent Persona Definitions for Factory Agents
-// =============================================================================
-// This file contains Wildo-specific agent persona definitions and prompt content.
-// TODO: When source-backed prompt parts become real again, consume
-// `@wildo-ai/framework-knowledge` directly instead of reviving any repo-local
-// prompt-part mirror.
-// =============================================================================
-// Exported constants for agent persona prompts (can be used by other modules)
-export const cleanDescription = (description) => description.split("|\n").map(line => line.trim()).join("\n");
-// =============================================================================
-// TEMPORARY STUBS - Pending migration to real framework-knowledge-backed prompt
-// parts
-// =============================================================================
-// These will be replaced once real non-test source anchors are authored and the
-// framework-knowledge generator is seeded with useful content.
-// =============================================================================
-var SourceTemplateType;
-(function (SourceTemplateType) {
-    SourceTemplateType["SERVICES_REGISTRY_HANDLER_SERVICE_OPERATION_FLOW"] = "services.registry.handler.service.operation.flow";
-    SourceTemplateType["RESOURCE_OPERATION_CUSTOM_IMPLEMENTATION_BASE"] = "resource.operation.custom.implementation.base";
-    SourceTemplateType["RESOURCE_OPERATION_CUSTOM_IMPLEMENTATION_FACTORY"] = "resource.operation.custom.implementation.factory";
-    SourceTemplateType["TODOS_CREATE_DEFAULT_CUSTOM_IMPL"] = "todos.create.default.custom.impl";
-})(SourceTemplateType || (SourceTemplateType = {}));
-function getSourceTemplate(templateType) {
-    return `[TODO: Source template "${templateType}" pending migration to framework-knowledge-backed prompt parts]`;
-}
-const WILDO_AI_FRAMEWORK_INTRODUCTION = cleanDescription(`
-  Wildo.ai is a TypeScript/Node.js engine for building multi-tenant SaaS applications |
-  through ResourceConfiguration definitions and Apps Blueprint system. The engine |
-  provides core ResourceTypes (users, organizations, billing, audit logs) with |
-  CoreResourceOperations (CREATE, READ, UPDATE, DELETE, LIST, COUNT, SEARCH) and |
-  custom resource extensions through ResourceConfiguration factories.
-  
-  Applications are defined via ResourceConfiguration schemas with mainSchema/databaseSchema, |
-  resourceRelationships, and operation variants (CRUD, searchable, repository-only). |
-  The engine generates backend services (Inversify+Express), frontend components |
-  (React+TypeScript), and deployment configurations across multiple locations |
-  (backend, frontend_main, frontend_admin, shared, website). |
-  
-  LLM agents operate through Apps Blueprint (agents with skills, flows, artifacts) |
-  to generate AppsBlueprint_SourceCode_FilePart with specific fileKinds |
-  (RESOURCE_SCHEMA, RESOURCE_CONFIGURATION, FRONTEND_CUSTOM_COMPONENT) and locations. |
-  Custom implementations are injected via apps-custom/* ResourceConfiguration factories |
-  while maintaining engine ResourceType compatibility and operation consistency.
-`);
-const WILDO_AI_RESOURCES_INTRODUCTION = cleanDescription(`
-  Resources in Wildo.ai are strongly-typed data entities defined via ResourceConfiguration |
-  with mainSchema/databaseSchema (Zod), resourceRelationships (parent/child/self/inheritance), |
-  and ResourceType identifiers. Core resources include users, organizations, billing, audit logs. |
-  Each resource has a ResourceFieldIdentifier, ResourcePrimaryScope (organizations/user_self/application), |
-  and supports inheritance via discriminatorField with inheritedSchemas. Resources are connected |
-  through ResourceRelationship with cardinality (one/many), accessScopeStrategy (requires_context/optional_context/standalone), |
-  and support many-to-many via jointResourceType. |
-`);
-const WILDO_AI_RESOURCES_DETAILLED_DESCRIPTION = cleanDescription(`
-  Resources in Wildo.ai are defined through ResourceConfiguration schemas with strongly-typed |
-  mainSchema (Zod) and optional databaseSchema for data persistence. Each resource has a |
-  ResourceType identifier, ResourceFieldIdentifier (e.g., 'userId', 'organizationId'), and |
-  ResourcePrimaryScope (ORGANIZATIONS, USER_SELF, APPLICATION) determining |
-  access context. |
-
-  ResourceRelationships define connections between resources with cardinality (ONE, ZERO_OR_ONE, |
-  ONE_OR_MANY, MANY), ResourceRelationshipAccessScopeStrategy (REQUIRES_CONTEXT, OPTIONAL_CONTEXT, |
-  STANDALONE), and ResourceParentResourceRequirement (MANDATORY, OPTIONAL). Many-to-many |
-  relationships use jointResourceType with automatic relationship generation. |
-
-  Core ResourceTypes include: USERS, ORGANIZATIONS, USER_PROFILES, USER_PREFERENCES, |
-  ORGANIZATION_MEMBERS, APPLICATION, BILLING_CUSTOMERS, PAYMENT_METHODS, SUBSCRIPTIONS, |
-  INVOICES, AUDIT_LOGS. Custom resources extend this system through ResourceConfiguration |
-  factories. |
-
-  ResourceConfiguration supports inheritance via discriminatorField with inheritedSchemas |
-  containing discriminatorFieldValue, schema, and optional databaseSchema. Resource relationships |
-  can have inheritancePath for schema-specific connections. |
-
-  The ResourcesRegistry centralizes all configurations with resourceRelationships array, |
-  resourceConfigurations map, notificationBadgeDefinitions, and additionalUserNotificationDefinitions. |
-  Resources support getFrontendResourceLabel functions for UI display with translation support. |
-
-  Data structuration follows createOrUpdateMandatoryDiscardFields pattern excluding '_id', |
-  'createdAt', 'updatedAt', 'deletedAt', '_version_db_doc' from input operations. Resources |
-  integrate with multi-tenancy, RBAC, billing systems, and audit trails through the unified |
-  configuration system. |
-`);
-const WILDO_AI_RESOURCES_OPERATIONS_INTRODUCTION = cleanDescription(`
-  Resource operations are defined via ResourceConfiguration_Operation with CoreResourceOperations |
-  (CREATE, READ, UPDATE, DELETE, LIST, COUNT, SEARCH) and custom operations. Each operation |
-  has variants (API_CALL, CRON_JOB, BATCH_JOB, INTERNAL_CALL, REPOSITORY_ONLY) with requestDto/responseDto, |
-  roles, riskLevel, and serviceRuntimeMode. Child resource lifecycle (cascade delete) is now configured |
-  via childOperations on ResourceRelationship. Operations support bulk variants, |
-  searchable configurations with filterFields/sortFields, and custom service implementation modes (OVERRIDE_ALL, PREFIX_CORE_OPERATIONS, |
-  REPLACE_CORE_OPERATIONS, POSTFIX_CORE_OPERATIONS, AFTER_USER_NOTIFICATIONS, AT_THE_END). |
-`);
-const WILDO_AI_RESOURCES_OPERATIONS_DETAILLED_DESCRIPTION = cleanDescription(`
-  Resource operations are implemented through ResourceConfiguration_Operation with CoreResourceOperations |
-  (CREATE, READ, UPDATE, DELETE, LIST, COUNT, SEARCH). Each operation supports |
-  multiple variants: API_CALL (HTTP endpoints), CRON_JOB (scheduled), BATCH_JOB (queued processing), |
-  INTERNAL_CALL (service-to-service), REPOSITORY_ONLY (data access), and API_CALL_WITH_CALLBACK (async). |
-
-  Operations have ResourceOperationVariantType determining execution context, ResourceOperation_ServiceRuntimeMode |
-  (INLINE, BACKGROUND_JOB, QUEUED, NONE), and ResourceOperationRiskLevel (LOW, MEDIUM, HIGH, CRITICAL). |
-  Each variant includes requestDto/responseDto schemas, roles authorization, and organizationFeatures requirements. |
-
-  API_CALL variants support httpVerb |
-  (GET/POST/PUT/DELETE), bulkOperations for CREATE/UPDATE/DELETE operations, consumableToken integration, |
-  and enabledCondition functions. Search operations include searchableFields, filterFields, sortFields, |
-  and maxPaginatedResultPerPageLimit with ResourceSearchQueryRequestResult schemas. |
-
-  Custom service implementations use ResourceOperation_CustomServiceImplementationMode: OVERRIDE_ALL |
-  (complete replacement), PREFIX_CORE_OPERATIONS (pre-processing), REPLACE_CORE_OPERATIONS (core logic), |
-  POSTFIX_CORE_OPERATIONS (post-processing), AFTER_USER_NOTIFICATIONS (after notifications), |
-  AT_THE_END (final hooks). Each mode has specific input/output type transformations. |
-
-  Child resource lifecycle is configured via childOperations on ResourceRelationship with |
-  ChildLifecycleMode (IMMEDIATE, LAZY) for cascade delete operations. Notifications include userNotifications |
-  (with primaryScope and auto-generated identifiers), m2mNotifications, and notificationBadgeOperations. |
-
-  Default response patterns: DefaultDeleteResponseSchema (id, deletedAt), DefaultBulkDeleteResponseSchema |
-  (deletedIds, deletedCount), DefaultUpdateManyResponseSchema (updatedCount, updatedIds), |
-  DefaultCreateManyResponseSchema (items, createdCount), DefaultActionResponseSchema (success, message, result). |
-
-  Resource operation paths use ResourceConfiguration_OperationPath with resourceIdentifier, operationIdentifier, |
-  variantType, isOperationDefault, isBulkOperation, and optional variantKey for operation routing and |
-  service registry management. |
-`);
-const WILDO_AI_APPLICATION_CUSTOM_SERVICES_INTRODUCTION = cleanDescription(`
-  Custom services extend engine operations via ResourceOperationCustomImplementationBase |
-  with typed input/output schemas and execution placeholders. Custom implementations are registered |
-  through ResourceCustomServiceImplementationFactory and accessed via ResourceConfiguration_OperationPath. |
-  Services provide utils (logger, errorBuilder, resourcesRegistry, servicesRegistry, repositoriesRegistry, |
-  externalApiHandler, platformMutualizedHandler, serverlessServicesHandler) and support schema parsing |
-  with passthrough for REPLACE_CORE_OPERATIONS mode. Custom services integrate at specific lifecycle |
-  points while maintaining ResourceType compatibility and operation consistency. |
-`);
-const WILDO_AI_APPLICATION_CUSTOM_SERVICES_DETAILLED_DESCRIPTION = cleanDescription(`
-  Custom services in Wildo.ai extend ResourceOperationCustomImplementationBase<TInput, TOutput> |
-  with strongly-typed input/output schemas and execution placeholders. Custom implementations are |
-  registered via ResourceCustomServiceImplementationFactory returning operationPathKey and |
-  implementation instances for ResourceOperationCustomImplementationRegistryBackendService. |
-
-  Custom service modes provide execution hooks: overrideAll() replaces entire operation flow, |
-  prefixCoreOperations() handles pre-processing with input augmentation, replaceCoreOperations() |
-  replaces core business logic between repository and post-logic, postfixCoreOperations() manages |
-  post-processing, afterUserNotifications() executes after notification dispatch, and atTheEnd() |
-  provides final cleanup hooks. |
-
-  Implementation factories use createResourceCustomServiceImplementation() with operationPath |
-  (resourceIdentifier, operationIdentifier, variantType), requestDtoSchema/responseDtoSchema |
-  for type safety, and handlers object containing mode-specific functions. Each handler receives |
-  _id, input, executionContext, operationPath, and utils (logger, errorBuilder, registries). |
-
-  Custom services integrate with ServicesRegistryHandlerBackendService through ResourceConfiguration_OperationPath |
-  routing. The engine provides ResourceOperation_CustomImplementation_Utils including logger, |
-  errorBuilder, resourcesRegistry, servicesRegistry, repositoriesRegistry, externalApiHandler, |
-  platformMutualizedHandler, and serverlessServicesHandler for comprehensive service access. |
-
-  Type transformations use ResourceOperationCustomImplementation_InputTypeOf and ResourceOperationCustomImplementation_OutputTypeOf |
-  with mode-specific behavior: OVERRIDE_ALL uses TInput->TOutput, PREFIX_CORE_OPERATIONS augments |
-  input with TAugment, REPLACE_CORE_OPERATIONS supports passthrough parsing, and other modes |
-  transform based on execution context. |
-
-  Custom implementations support apps-custom structure with custom-backend-lib containing service |
-  implementations, custom-shared-lib defining resource configurations, and integration points |
-  maintaining ResourceType compatibility. Examples include todos.create.default.custom-impl.custom.definitions |
-  showing complete custom operation implementation patterns. |
-
-  The system ensures type safety through parseResourceOperation_CustomServiceImplementationSchema() |
-  handling input/output validation, schema passthrough for augmented types, and error handling |
-  with ExecutionContext integration for comprehensive operation lifecycle management. |
-`);
-/*
-
-const RAW_PROMPTS_LIBRARY_AGENTS_PERSONAS :{ [k in AppsBlueprint_AgentPersonas]: Agent } = {
-  [AppsBlueprint_AgentPersonas.CUSTOM_CODE_EDITOR]: {
-    persona: AppsBlueprint_AgentPersonas.CUSTOM_CODE_EDITOR,
-    status: Agent_Status.ACTIVE,
-    accessControl: {
-      primaryScope: ResourcePrimaryScope.APPLICATION,
-      approverRoles: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN],
-    },
-    llmConfig: {
-      model: Agent_LLMModel.OPEN_AI_GPT_4O,
-      
-    },
-    skill: {
-      name: "custom_code_editor",
-      role: `You are a senior backend software engineer specialized in typescript and node.js.
-        You are in responsibility of implementing and maintaining a custom implementation for a service using the wildo-ai engine.
-
-        ${WILDO_AI_FRAMEWORK_INTRODUCTION}
-        
-        This Service will be injected into the service layer of Wildo engine and will be executed in the context of the end-user's application for the specific application.
-        for information the injection is madelike following :
-        ${getSourceTemplate(SourceTemplateType.SERVICES_REGISTRY_HANDLER_SERVICE_OPERATION_FLOW)}
-
-        Here are the engine base classes and factory for custom service implementations:
-        ${getSourceTemplate(SourceTemplateType.RESOURCE_OPERATION_CUSTOM_IMPLEMENTATION_BASE)}
-         
-         ---
-         
-         ${getSourceTemplate(SourceTemplateType.RESOURCE_OPERATION_CUSTOM_IMPLEMENTATION_FACTORY)}
-         
-         ---
-         
-         And here is an example of a custom implementation for a service:
-         ${getSourceTemplate(SourceTemplateType.TODOS_CREATE_DEFAULT_CUSTOM_IMPL)}
-
-        `,
-      inputFormats: [],
-      outputFormat: {
-        kind: FlowsActors_IO_PartKind.FILE,
-        format: AppsBlueprint_FileFormat.TYPESCRIPT,
-      },
-      tags: [],
-    },
-    version: "1.0.0",
-  },
-  [AppsBlueprint_AgentPersonas.CUSTOM_CODE_REVIEWER]: {
-    persona: AppsBlueprint_AgentPersonas.CUSTOM_CODE_REVIEWER,
-    role: "Code Reviewer",
-    aiModel: Agent_LLMModel.OPEN_AI_GPT_4O,
-    skills: [],
-    version: "1.0.0",
-  },
-  
-  [AppsBlueprint_AgentPersonas.RESOURCES_CODE_EDITOR]: {
-    persona: AppsBlueprint_AgentPersonas.RESOURCES_CODE_EDITOR,
-    role: "Resources Code Editor",
-    aiModel: Agent_LLMModel.OPEN_AI_GPT_4O,
-    skills: [],
-    version: "1.0.0",
-  },
-  
-  [AppsBlueprint_AgentPersonas.RESOURCES_CODE_REVIEWER]: {
-    persona: AppsBlueprint_AgentPersonas.RESOURCES_CODE_REVIEWER,
-    role: "Resources Code Reviewer",
-    aiModel: Agent_LLMModel.OPEN_AI_GPT_4O,
-    skills: [],
-    version: "1.0.0",
-  },
-  
-  [AppsBlueprint_AgentPersonas.TASK_ENHANCER]: {
-    persona: AppsBlueprint_AgentPersonas.TASK_ENHANCER,
-    role: "Task Enhancer",
-    aiModel: Agent_LLMModel.OPEN_AI_GPT_4O,
-    skills: [],
-    version: "1.0.0",
-  },
-  
-  [AppsBlueprint_AgentPersonas.MARKETING_STRATEGIST]: {
-    persona: AppsBlueprint_AgentPersonas.MARKETING_STRATEGIST,
-    role: "Marketing Strategist",
-    aiModel: Agent_LLMModel.OPEN_AI_GPT_4O,
-    skills: [],
-    version: "1.0.0",
-  },
-  
-  [AppsBlueprint_AgentPersonas.BRAINSTORMER]: {
-    persona: AppsBlueprint_AgentPersonas.BRAINSTORMER,
-    role: "Brainstormer",
-    aiModel: Agent_LLMModel.OPEN_AI_GPT_4O,
-    skills: [],
-    version: "1.0.0",
-  },
-  
-  [AppsBlueprint_AgentPersonas.CONTENT_WRITER]: {
-    persona: AppsBlueprint_AgentPersonas.CONTENT_WRITER,
-    role: "Content Writer",
-    aiModel: Agent_LLMModel.OPEN_AI_GPT_4O,
-    skills: [],
-    version: "1.0.0",
-  },
-  
-  [AppsBlueprint_AgentPersonas.TASK_PLANNER]: {
-    persona: AppsBlueprint_AgentPersonas.TASK_PLANNER,
-    role: "Task Planner",
-    aiModel: Agent_LLMModel.OPEN_AI_GPT_4O,
-    skills: [],
-    version: "1.0.0",
-  },
-  
-  [AppsBlueprint_AgentPersonas.APP_CONFIGURATOR]: {
-    persona: AppsBlueprint_AgentPersonas.APP_CONFIGURATOR,
-    status: Agent_Status.ACTIVE,
-    accessControl: {
-      primaryScope: ResourcePrimaryScope.APPLICATION,
-      approverRoles: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN],
-    },
-    llmConfig: {
-      model: Agent_LLMModel.OPEN_AI_GPT_4O,
-    },
-    skill: {
-      name: "app_configurator",
-      role: "App Configurator",
-      type: Agent_Skill_Type.ANALYSIS,
-      inputFormats: [],
-      outputSchema: {
-        kind: FlowsActors_PartKind.FILE,
-        format: FlowsActors_FileFormat.TYPESCRIPT,
-      },
-    },
-    version: "1.0.0",
-  },
-  
-  [AppsBlueprint_AgentPersonas.BILLING_STRATEGIST]: {
-    persona: AppsBlueprint_AgentPersonas.BILLING_STRATEGIST,
-    status: Agent_Status.ACTIVE,
-    accessControl: {
-      primaryScope: ResourcePrimaryScope.APPLICATION,
-      approverRoles: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN],
-    },
-    llmConfig: {
-      model: Agent_LLMModel.OPEN_AI_GPT_4O,
-    },
-    skill: {
-      name: "billing_strategy_analysis",
-      role: "Billing Strategist",
-      type: Agent_Skill_Type.ANALYSIS,
-      inputFormats: [],
-      outputSchema: {
-        kind: FlowsActors_PartKind.FILE,
-        format: FlowsActors_FileFormat.TYPESCRIPT,
-      },
-    },
-  },
-};
-
-const ENTRIES = Object.entries(RAW_PROMPTS_LIBRARY_AGENTS_PERSONAS) as [AppsBlueprint_AgentPersonas, Agent][];
-
-
-
-export const PromptsLibraryAgentsPersonas :{ [k in AppsBlueprint_AgentPersonas]: Agent } = (
-  Object.fromEntries(
-    ENTRIES.map(([key, persona]) => [
-      key,
-      {
-        ...persona,
-        skill: {
-          ...persona.skill,
-          role: cleanDescription(persona.skill.role),
-        },
-      },
-    ])
-  ) as unknown
-) as { [k in AppsBlueprint_AgentPersonas]: Agent };
-
-*/ 
-//# sourceMappingURL=prompts-library.agent-personna.backend.models.js.map

package/dist/esm/flows-actors/factory-agents/prompts-library.agent-personna.backend.models.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"prompts-library.agent-personna.backend.models.js","sourceRoot":"","sources":["../../../../../src/flows-actors/factory-agents/prompts-library.agent-personna.backend.models.ts"],"names":[],"mappings":"AAAA,gFAAgF;AAChF,+CAA+C;AAC/C,gFAAgF;AAChF,kFAAkF;AAClF,mEAAmE;AACnE,8EAA8E;AAC9E,sBAAsB;AACtB,gFAAgF;AAEhF,8EAA8E;AAC9E,MAAM,CAAC,MAAM,gBAAgB,GAAG,CAAC,WAAmB,EAAE,EAAE,CAAC,WAAW,CAAC,KAAK,CAAC,KAAK,CAAC,CAAC,GAAG,CAAC,IAAI,CAAC,EAAE,CAAC,IAAI,CAAC,IAAI,EAAE,CAAC,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;AAEtH,gFAAgF;AAChF,gFAAgF;AAChF,QAAQ;AACR,gFAAgF;AAChF,gFAAgF;AAChF,+DAA+D;AAC/D,gFAAgF;AAEhF,IAAK,kBAKJ;AALD,WAAK,kBAAkB;IACrB,2HAAqG,CAAA;IACrG,qHAA+F,CAAA;IAC/F,2HAAqG,CAAA;IACrG,2FAAqE,CAAA;AACvE,CAAC,EALI,kBAAkB,KAAlB,kBAAkB,QAKtB;AAED,SAAS,iBAAiB,CAAC,YAAgC;IACzD,OAAO,2BAA2B,YAAY,iEAAiE,CAAC;AAClH,CAAC;AAED,MAAM,+BAA+B,GAAG,gBAAgB,CAAC;;;;;;;;;;;;;;;;;;CAkBxD,CAAC,CAAC;AAEH,MAAM,+BAA+B,GAAG,gBAAgB,CAAC;;;;;;;;CAQxD,CAAC,CAAC;AAEH,MAAM,wCAAwC,GAAG,gBAAgB,CAAC;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA6BjE,CAAC,CAAC;AAEH,MAAM,0CAA0C,GAAG,gBAAgB,CAAC;;;;;;;;CAQnE,CAAC,CAAC;AAEH,MAAM,mDAAmD,GAAG,gBAAgB,CAAC;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA+B5E,CAAC,CAAC;AAEH,MAAM,iDAAiD,GAAG,gBAAgB,CAAC;;;;;;;;CAQ1E,CAAC,CAAC;AAEH,MAAM,0DAA0D,GAAG,gBAAgB,CAAC;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAmCnF,CAAC,CAAC;AAGH;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EAgLE","sourcesContent":["// =============================================================================\n// Agent Persona Definitions for Factory Agents\n// =============================================================================\n// This file contains Wildo-specific agent persona definitions and prompt content.\n// TODO: When source-backed prompt parts become real again, consume\n// `@wildo-ai/framework-knowledge` directly instead of reviving any repo-local\n// prompt-part mirror.\n// =============================================================================\n\n// Exported constants for agent persona prompts (can be used by other modules)\nexport const cleanDescription = (description: string) => description.split(\"|\\n\").map(line => line.trim()).join(\"\\n\");\n\n// =============================================================================\n// TEMPORARY STUBS - Pending migration to real framework-knowledge-backed prompt\n// parts\n// =============================================================================\n// These will be replaced once real non-test source anchors are authored and the\n// framework-knowledge generator is seeded with useful content.\n// =============================================================================\n\nenum SourceTemplateType {\n  SERVICES_REGISTRY_HANDLER_SERVICE_OPERATION_FLOW = 'services.registry.handler.service.operation.flow',\n  RESOURCE_OPERATION_CUSTOM_IMPLEMENTATION_BASE = 'resource.operation.custom.implementation.base',\n  RESOURCE_OPERATION_CUSTOM_IMPLEMENTATION_FACTORY = 'resource.operation.custom.implementation.factory',\n  TODOS_CREATE_DEFAULT_CUSTOM_IMPL = 'todos.create.default.custom.impl',\n}\n\nfunction getSourceTemplate(templateType: SourceTemplateType): string {\n  return `[TODO: Source template \"${templateType}\" pending migration to framework-knowledge-backed prompt parts]`;\n}\n\nconst WILDO_AI_FRAMEWORK_INTRODUCTION = cleanDescription(`\n  Wildo.ai is a TypeScript/Node.js engine for building multi-tenant SaaS applications |\n  through ResourceConfiguration definitions and Apps Blueprint system. The engine |\n  provides core ResourceTypes (users, organizations, billing, audit logs) with |\n  CoreResourceOperations (CREATE, READ, UPDATE, DELETE, LIST, COUNT, SEARCH) and |\n  custom resource extensions through ResourceConfiguration factories.\n  \n  Applications are defined via ResourceConfiguration schemas with mainSchema/databaseSchema, |\n  resourceRelationships, and operation variants (CRUD, searchable, repository-only). |\n  The engine generates backend services (Inversify+Express), frontend components |\n  (React+TypeScript), and deployment configurations across multiple locations |\n  (backend, frontend_main, frontend_admin, shared, website). |\n  \n  LLM agents operate through Apps Blueprint (agents with skills, flows, artifacts) |\n  to generate AppsBlueprint_SourceCode_FilePart with specific fileKinds |\n  (RESOURCE_SCHEMA, RESOURCE_CONFIGURATION, FRONTEND_CUSTOM_COMPONENT) and locations. |\n  Custom implementations are injected via apps-custom/* ResourceConfiguration factories |\n  while maintaining engine ResourceType compatibility and operation consistency.\n`);\n\nconst WILDO_AI_RESOURCES_INTRODUCTION = cleanDescription(`\n  Resources in Wildo.ai are strongly-typed data entities defined via ResourceConfiguration |\n  with mainSchema/databaseSchema (Zod), resourceRelationships (parent/child/self/inheritance), |\n  and ResourceType identifiers. Core resources include users, organizations, billing, audit logs. |\n  Each resource has a ResourceFieldIdentifier, ResourcePrimaryScope (organizations/user_self/application), |\n  and supports inheritance via discriminatorField with inheritedSchemas. Resources are connected |\n  through ResourceRelationship with cardinality (one/many), accessScopeStrategy (requires_context/optional_context/standalone), |\n  and support many-to-many via jointResourceType. |\n`);\n\nconst WILDO_AI_RESOURCES_DETAILLED_DESCRIPTION = cleanDescription(`\n  Resources in Wildo.ai are defined through ResourceConfiguration schemas with strongly-typed |\n  mainSchema (Zod) and optional databaseSchema for data persistence. Each resource has a |\n  ResourceType identifier, ResourceFieldIdentifier (e.g., 'userId', 'organizationId'), and |\n  ResourcePrimaryScope (ORGANIZATIONS, USER_SELF, APPLICATION) determining |\n  access context. |\n\n  ResourceRelationships define connections between resources with cardinality (ONE, ZERO_OR_ONE, |\n  ONE_OR_MANY, MANY), ResourceRelationshipAccessScopeStrategy (REQUIRES_CONTEXT, OPTIONAL_CONTEXT, |\n  STANDALONE), and ResourceParentResourceRequirement (MANDATORY, OPTIONAL). Many-to-many |\n  relationships use jointResourceType with automatic relationship generation. |\n\n  Core ResourceTypes include: USERS, ORGANIZATIONS, USER_PROFILES, USER_PREFERENCES, |\n  ORGANIZATION_MEMBERS, APPLICATION, BILLING_CUSTOMERS, PAYMENT_METHODS, SUBSCRIPTIONS, |\n  INVOICES, AUDIT_LOGS. Custom resources extend this system through ResourceConfiguration |\n  factories. |\n\n  ResourceConfiguration supports inheritance via discriminatorField with inheritedSchemas |\n  containing discriminatorFieldValue, schema, and optional databaseSchema. Resource relationships |\n  can have inheritancePath for schema-specific connections. |\n\n  The ResourcesRegistry centralizes all configurations with resourceRelationships array, |\n  resourceConfigurations map, notificationBadgeDefinitions, and additionalUserNotificationDefinitions. |\n  Resources support getFrontendResourceLabel functions for UI display with translation support. |\n\n  Data structuration follows createOrUpdateMandatoryDiscardFields pattern excluding '_id', |\n  'createdAt', 'updatedAt', 'deletedAt', '_version_db_doc' from input operations. Resources |\n  integrate with multi-tenancy, RBAC, billing systems, and audit trails through the unified |\n  configuration system. |\n`);\n\nconst WILDO_AI_RESOURCES_OPERATIONS_INTRODUCTION = cleanDescription(`\n  Resource operations are defined via ResourceConfiguration_Operation with CoreResourceOperations |\n  (CREATE, READ, UPDATE, DELETE, LIST, COUNT, SEARCH) and custom operations. Each operation |\n  has variants (API_CALL, CRON_JOB, BATCH_JOB, INTERNAL_CALL, REPOSITORY_ONLY) with requestDto/responseDto, |\n  roles, riskLevel, and serviceRuntimeMode. Child resource lifecycle (cascade delete) is now configured |\n  via childOperations on ResourceRelationship. Operations support bulk variants, |\n  searchable configurations with filterFields/sortFields, and custom service implementation modes (OVERRIDE_ALL, PREFIX_CORE_OPERATIONS, |\n  REPLACE_CORE_OPERATIONS, POSTFIX_CORE_OPERATIONS, AFTER_USER_NOTIFICATIONS, AT_THE_END). |\n`);\n\nconst WILDO_AI_RESOURCES_OPERATIONS_DETAILLED_DESCRIPTION = cleanDescription(`\n  Resource operations are implemented through ResourceConfiguration_Operation with CoreResourceOperations |\n  (CREATE, READ, UPDATE, DELETE, LIST, COUNT, SEARCH). Each operation supports |\n  multiple variants: API_CALL (HTTP endpoints), CRON_JOB (scheduled), BATCH_JOB (queued processing), |\n  INTERNAL_CALL (service-to-service), REPOSITORY_ONLY (data access), and API_CALL_WITH_CALLBACK (async). |\n\n  Operations have ResourceOperationVariantType determining execution context, ResourceOperation_ServiceRuntimeMode |\n  (INLINE, BACKGROUND_JOB, QUEUED, NONE), and ResourceOperationRiskLevel (LOW, MEDIUM, HIGH, CRITICAL). |\n  Each variant includes requestDto/responseDto schemas, roles authorization, and organizationFeatures requirements. |\n\n  API_CALL variants support httpVerb |\n  (GET/POST/PUT/DELETE), bulkOperations for CREATE/UPDATE/DELETE operations, consumableToken integration, |\n  and enabledCondition functions. Search operations include searchableFields, filterFields, sortFields, |\n  and maxPaginatedResultPerPageLimit with ResourceSearchQueryRequestResult schemas. |\n\n  Custom service implementations use ResourceOperation_CustomServiceImplementationMode: OVERRIDE_ALL |\n  (complete replacement), PREFIX_CORE_OPERATIONS (pre-processing), REPLACE_CORE_OPERATIONS (core logic), |\n  POSTFIX_CORE_OPERATIONS (post-processing), AFTER_USER_NOTIFICATIONS (after notifications), |\n  AT_THE_END (final hooks). Each mode has specific input/output type transformations. |\n\n  Child resource lifecycle is configured via childOperations on ResourceRelationship with |\n  ChildLifecycleMode (IMMEDIATE, LAZY) for cascade delete operations. Notifications include userNotifications |\n  (with primaryScope and auto-generated identifiers), m2mNotifications, and notificationBadgeOperations. |\n\n  Default response patterns: DefaultDeleteResponseSchema (id, deletedAt), DefaultBulkDeleteResponseSchema |\n  (deletedIds, deletedCount), DefaultUpdateManyResponseSchema (updatedCount, updatedIds), |\n  DefaultCreateManyResponseSchema (items, createdCount), DefaultActionResponseSchema (success, message, result). |\n\n  Resource operation paths use ResourceConfiguration_OperationPath with resourceIdentifier, operationIdentifier, |\n  variantType, isOperationDefault, isBulkOperation, and optional variantKey for operation routing and |\n  service registry management. |\n`);\n\nconst WILDO_AI_APPLICATION_CUSTOM_SERVICES_INTRODUCTION = cleanDescription(`\n  Custom services extend engine operations via ResourceOperationCustomImplementationBase |\n  with typed input/output schemas and execution placeholders. Custom implementations are registered |\n  through ResourceCustomServiceImplementationFactory and accessed via ResourceConfiguration_OperationPath. |\n  Services provide utils (logger, errorBuilder, resourcesRegistry, servicesRegistry, repositoriesRegistry, |\n  externalApiHandler, platformMutualizedHandler, serverlessServicesHandler) and support schema parsing |\n  with passthrough for REPLACE_CORE_OPERATIONS mode. Custom services integrate at specific lifecycle |\n  points while maintaining ResourceType compatibility and operation consistency. |\n`);\n\nconst WILDO_AI_APPLICATION_CUSTOM_SERVICES_DETAILLED_DESCRIPTION = cleanDescription(`\n  Custom services in Wildo.ai extend ResourceOperationCustomImplementationBase<TInput, TOutput> |\n  with strongly-typed input/output schemas and execution placeholders. Custom implementations are |\n  registered via ResourceCustomServiceImplementationFactory returning operationPathKey and |\n  implementation instances for ResourceOperationCustomImplementationRegistryBackendService. |\n\n  Custom service modes provide execution hooks: overrideAll() replaces entire operation flow, |\n  prefixCoreOperations() handles pre-processing with input augmentation, replaceCoreOperations() |\n  replaces core business logic between repository and post-logic, postfixCoreOperations() manages |\n  post-processing, afterUserNotifications() executes after notification dispatch, and atTheEnd() |\n  provides final cleanup hooks. |\n\n  Implementation factories use createResourceCustomServiceImplementation() with operationPath |\n  (resourceIdentifier, operationIdentifier, variantType), requestDtoSchema/responseDtoSchema |\n  for type safety, and handlers object containing mode-specific functions. Each handler receives |\n  _id, input, executionContext, operationPath, and utils (logger, errorBuilder, registries). |\n\n  Custom services integrate with ServicesRegistryHandlerBackendService through ResourceConfiguration_OperationPath |\n  routing. The engine provides ResourceOperation_CustomImplementation_Utils including logger, |\n  errorBuilder, resourcesRegistry, servicesRegistry, repositoriesRegistry, externalApiHandler, |\n  platformMutualizedHandler, and serverlessServicesHandler for comprehensive service access. |\n\n  Type transformations use ResourceOperationCustomImplementation_InputTypeOf and ResourceOperationCustomImplementation_OutputTypeOf |\n  with mode-specific behavior: OVERRIDE_ALL uses TInput->TOutput, PREFIX_CORE_OPERATIONS augments |\n  input with TAugment, REPLACE_CORE_OPERATIONS supports passthrough parsing, and other modes |\n  transform based on execution context. |\n\n  Custom implementations support apps-custom structure with custom-backend-lib containing service |\n  implementations, custom-shared-lib defining resource configurations, and integration points |\n  maintaining ResourceType compatibility. Examples include todos.create.default.custom-impl.custom.definitions |\n  showing complete custom operation implementation patterns. |\n\n  The system ensures type safety through parseResourceOperation_CustomServiceImplementationSchema() |\n  handling input/output validation, schema passthrough for augmented types, and error handling |\n  with ExecutionContext integration for comprehensive operation lifecycle management. |\n`);\n\n\n/*\n\nconst RAW_PROMPTS_LIBRARY_AGENTS_PERSONAS :{ [k in AppsBlueprint_AgentPersonas]: Agent } = {\n  [AppsBlueprint_AgentPersonas.CUSTOM_CODE_EDITOR]: {\n    persona: AppsBlueprint_AgentPersonas.CUSTOM_CODE_EDITOR,\n    status: Agent_Status.ACTIVE,\n    accessControl: {\n      primaryScope: ResourcePrimaryScope.APPLICATION,\n      approverRoles: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN],\n    },\n    llmConfig: {\n      model: Agent_LLMModel.OPEN_AI_GPT_4O,\n      \n    },\n    skill: {\n      name: \"custom_code_editor\",\n      role: `You are a senior backend software engineer specialized in typescript and node.js.\n        You are in responsibility of implementing and maintaining a custom implementation for a service using the wildo-ai engine.\n\n        ${WILDO_AI_FRAMEWORK_INTRODUCTION}\n        \n        This Service will be injected into the service layer of Wildo engine and will be executed in the context of the end-user's application for the specific application.\n        for information the injection is madelike following :\n        ${getSourceTemplate(SourceTemplateType.SERVICES_REGISTRY_HANDLER_SERVICE_OPERATION_FLOW)}\n\n        Here are the engine base classes and factory for custom service implementations:\n        ${getSourceTemplate(SourceTemplateType.RESOURCE_OPERATION_CUSTOM_IMPLEMENTATION_BASE)}\n         \n         ---\n         \n         ${getSourceTemplate(SourceTemplateType.RESOURCE_OPERATION_CUSTOM_IMPLEMENTATION_FACTORY)}\n         \n         ---\n         \n         And here is an example of a custom implementation for a service:\n         ${getSourceTemplate(SourceTemplateType.TODOS_CREATE_DEFAULT_CUSTOM_IMPL)}\n\n        `,\n      inputFormats: [],\n      outputFormat: {\n        kind: FlowsActors_IO_PartKind.FILE,\n        format: AppsBlueprint_FileFormat.TYPESCRIPT,\n      },\n      tags: [],\n    },\n    version: \"1.0.0\",\n  },\n  [AppsBlueprint_AgentPersonas.CUSTOM_CODE_REVIEWER]: {\n    persona: AppsBlueprint_AgentPersonas.CUSTOM_CODE_REVIEWER,\n    role: \"Code Reviewer\",\n    aiModel: Agent_LLMModel.OPEN_AI_GPT_4O,\n    skills: [],\n    version: \"1.0.0\",\n  },\n  \n  [AppsBlueprint_AgentPersonas.RESOURCES_CODE_EDITOR]: {\n    persona: AppsBlueprint_AgentPersonas.RESOURCES_CODE_EDITOR,\n    role: \"Resources Code Editor\",\n    aiModel: Agent_LLMModel.OPEN_AI_GPT_4O,\n    skills: [],\n    version: \"1.0.0\",\n  },\n  \n  [AppsBlueprint_AgentPersonas.RESOURCES_CODE_REVIEWER]: {\n    persona: AppsBlueprint_AgentPersonas.RESOURCES_CODE_REVIEWER,\n    role: \"Resources Code Reviewer\",\n    aiModel: Agent_LLMModel.OPEN_AI_GPT_4O,\n    skills: [],\n    version: \"1.0.0\",\n  },\n  \n  [AppsBlueprint_AgentPersonas.TASK_ENHANCER]: {\n    persona: AppsBlueprint_AgentPersonas.TASK_ENHANCER,\n    role: \"Task Enhancer\",\n    aiModel: Agent_LLMModel.OPEN_AI_GPT_4O,\n    skills: [],\n    version: \"1.0.0\",\n  },\n  \n  [AppsBlueprint_AgentPersonas.MARKETING_STRATEGIST]: {\n    persona: AppsBlueprint_AgentPersonas.MARKETING_STRATEGIST,\n    role: \"Marketing Strategist\",\n    aiModel: Agent_LLMModel.OPEN_AI_GPT_4O,\n    skills: [],\n    version: \"1.0.0\",\n  },\n  \n  [AppsBlueprint_AgentPersonas.BRAINSTORMER]: {\n    persona: AppsBlueprint_AgentPersonas.BRAINSTORMER,\n    role: \"Brainstormer\",\n    aiModel: Agent_LLMModel.OPEN_AI_GPT_4O,\n    skills: [],\n    version: \"1.0.0\",\n  },\n  \n  [AppsBlueprint_AgentPersonas.CONTENT_WRITER]: {\n    persona: AppsBlueprint_AgentPersonas.CONTENT_WRITER,\n    role: \"Content Writer\",\n    aiModel: Agent_LLMModel.OPEN_AI_GPT_4O,\n    skills: [],\n    version: \"1.0.0\",\n  },\n  \n  [AppsBlueprint_AgentPersonas.TASK_PLANNER]: {\n    persona: AppsBlueprint_AgentPersonas.TASK_PLANNER,\n    role: \"Task Planner\",\n    aiModel: Agent_LLMModel.OPEN_AI_GPT_4O,\n    skills: [],\n    version: \"1.0.0\",\n  },\n  \n  [AppsBlueprint_AgentPersonas.APP_CONFIGURATOR]: {\n    persona: AppsBlueprint_AgentPersonas.APP_CONFIGURATOR,\n    status: Agent_Status.ACTIVE,\n    accessControl: {\n      primaryScope: ResourcePrimaryScope.APPLICATION,\n      approverRoles: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN],\n    },\n    llmConfig: {\n      model: Agent_LLMModel.OPEN_AI_GPT_4O,\n    },\n    skill: {\n      name: \"app_configurator\",\n      role: \"App Configurator\",\n      type: Agent_Skill_Type.ANALYSIS,\n      inputFormats: [],\n      outputSchema: {\n        kind: FlowsActors_PartKind.FILE,\n        format: FlowsActors_FileFormat.TYPESCRIPT,\n      },\n    },\n    version: \"1.0.0\",\n  },\n  \n  [AppsBlueprint_AgentPersonas.BILLING_STRATEGIST]: {\n    persona: AppsBlueprint_AgentPersonas.BILLING_STRATEGIST,\n    status: Agent_Status.ACTIVE,\n    accessControl: {\n      primaryScope: ResourcePrimaryScope.APPLICATION,\n      approverRoles: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN],\n    },\n    llmConfig: {\n      model: Agent_LLMModel.OPEN_AI_GPT_4O,\n    },\n    skill: {\n      name: \"billing_strategy_analysis\",\n      role: \"Billing Strategist\",\n      type: Agent_Skill_Type.ANALYSIS,\n      inputFormats: [],\n      outputSchema: {\n        kind: FlowsActors_PartKind.FILE,\n        format: FlowsActors_FileFormat.TYPESCRIPT,\n      },\n    },\n  },\n};\n\nconst ENTRIES = Object.entries(RAW_PROMPTS_LIBRARY_AGENTS_PERSONAS) as [AppsBlueprint_AgentPersonas, Agent][];\n\n\n\nexport const PromptsLibraryAgentsPersonas :{ [k in AppsBlueprint_AgentPersonas]: Agent } = (\n  Object.fromEntries(\n    ENTRIES.map(([key, persona]) => [\n      key,\n      { \n        ...persona, \n        skill: {\n          ...persona.skill,\n          role: cleanDescription(persona.skill.role),\n        },\n      },\n    ])\n  ) as unknown\n) as { [k in AppsBlueprint_AgentPersonas]: Agent };\n\n*/"]}

package/dist/esm/flows-actors/flows-actors.default.definition.schemas.d.ts

@@ -1,7 +0,0 @@
-import { FlowActorSystem_InitializationFactoryMap } from "@wildo-ai/saas-backend-lib";
-import { FlowsActors_Agent } from "@wildo-ai/saas-models";
-export declare const customBackend_FlowsActorsRegistry: {
-    flowActorSystemsFactoryMap: FlowActorSystem_InitializationFactoryMap;
-    agents: FlowsActors_Agent[];
-};
-//# sourceMappingURL=flows-actors.default.definition.schemas.d.ts.map

package/dist/esm/flows-actors/flows-actors.default.definition.schemas.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"flows-actors.default.definition.schemas.d.ts","sourceRoot":"","sources":["../../../src/flows-actors/flows-actors.default.definition.schemas.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,wCAAwC,EAAE,MAAM,4BAA4B,CAAC;AACtF,OAAO,EAAE,iBAAiB,EAAE,MAAM,uBAAuB,CAAC;AAG1D,eAAO,MAAM,iCAAiC,EAAE;IAC9C,0BAA0B,EAAE,wCAAwC,CAAC;IACrE,MAAM,EAAE,iBAAiB,EAAE,CAAC;CAI7B,CAAC"}

package/dist/esm/flows-actors/flows-actors.default.definition.schemas.js

@@ -1,6 +0,0 @@
-// Export with consistent naming convention matching resources registry pattern
-export const customBackend_FlowsActorsRegistry = {
-    flowActorSystemsFactoryMap: {},
-    agents: [],
-};
-//# sourceMappingURL=flows-actors.default.definition.schemas.js.map

package/dist/esm/flows-actors/flows-actors.default.definition.schemas.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"flows-actors.default.definition.schemas.js","sourceRoot":"","sources":["../../../../src/flows-actors/flows-actors.default.definition.schemas.ts"],"names":[],"mappings":"AAGA,+EAA+E;AAC/E,MAAM,CAAC,MAAM,iCAAiC,GAG1C;IACF,0BAA0B,EAAE,EAAE;IAC9B,MAAM,EAAE,EAAE;CACX,CAAC","sourcesContent":["import { FlowActorSystem_InitializationFactoryMap } from \"@wildo-ai/saas-backend-lib\";\nimport { FlowsActors_Agent } from \"@wildo-ai/saas-models\";\n\n// Export with consistent naming convention matching resources registry pattern\nexport const customBackend_FlowsActorsRegistry: {\n  flowActorSystemsFactoryMap: FlowActorSystem_InitializationFactoryMap;\n  agents: FlowsActors_Agent[];\n} = {\n  flowActorSystemsFactoryMap: {},\n  agents: [],\n};\n\n"]}