@autobe/agent 0.18.0 → 0.19.1

package/lib/agent/src/orchestrate/interface/structures/IAutoBeInterfaceGroupApplication.d.ts

@@ -4,10 +4,10 @@ export interface IAutoBeInterfaceGroupApplication {
      * Generate logical groups for organizing API endpoint creation based on
      * Prisma schema structure.
      *
-     * Groups MUST be derived from Prisma schema organization (namespaces, file
-     * structure, table prefixes) rather than arbitrary business domains. Only
-     * create new groups when existing schema structure cannot adequately cover
-     * all requirements.
+     * DO: Derive groups from Prisma schema organization (namespaces, file
+     * structure, table prefixes) rather than arbitrary business domains.
+     * DO: Create new groups only when existing schema structure cannot adequately
+     * cover all requirements.
      *
      * @param props Properties containing the groups to be created for API
      *   organization
@@ -19,8 +19,8 @@ export declare namespace IAutoBeInterfaceGroupApplication {
         /**
          * Array of API endpoint groups for organizing development.
          *
-         * Groups MUST be organized around existing Prisma schema structure and
-         * provide complete coverage of all entities and requirements without
+         * DO: Organize groups around existing Prisma schema structure.
+         * DO: Provide complete coverage of all entities and requirements without
          * overlap.
          */
         groups: IGroup[] & tags.MinItems<1>;
@@ -31,10 +31,11 @@ export declare namespace IAutoBeInterfaceGroupApplication {
      *
      * **SCHEMA-BASED GROUP REQUIREMENTS:**
      *
-     * Groups MUST be derived from the Prisma schema structure rather than
-     * arbitrary business domain names. This ensures consistency with the
-     * underlying data model and prevents misalignment between API organization
-     * and database structure.
+     * DO: Derive groups from the Prisma schema structure rather than arbitrary
+     * business domain names.
+     *
+     * This ensures consistency with the underlying data model and prevents
+     * misalignment between API organization and database structure.
      *
      * **Primary Group Sources (in order of priority):**
      *
@@ -48,12 +49,11 @@ export declare namespace IAutoBeInterfaceGroupApplication {
      *
      * **Group Creation Guidelines:**
      *
-     * - Each group must cover specific Prisma schema entities without overlap
+     * - Each group covers specific Prisma schema entities without overlap
      * - Size groups appropriately for manageable endpoint generation cycles
      * - Maintain clear boundaries based on schema organization
      * - Ensure complete coverage of all database entities and requirements
-     * - Related database tables within the same schema area should be grouped
-     *   together
+     * - Related database tables within the same schema area are grouped together
      *
      * **When to Create Schema-Independent Groups:**
      *
@@ -68,14 +68,14 @@ export declare namespace IAutoBeInterfaceGroupApplication {
      * **Naming Standards:**
      *
      * - Use PascalCase format (e.g., "Shopping", "BBS", "UserManagement")
-     * - Names MUST directly reflect Prisma schema structure
+     * - Names directly reflect Prisma schema structure
      * - Keep names concise and schema-derived
      * - Avoid arbitrary business domain names
      * - Maintain consistency with schema organization
      *
      * **Quality Requirements:**
      *
-     * - Groups collectively must cover ALL entities and requirements
+     * - Groups collectively cover ALL entities and requirements
      * - Each database entity belongs to exactly one group
      * - Clear mapping to specific Prisma schema elements
      * - Balance group sizes within schema constraints
@@ -85,7 +85,7 @@ export declare namespace IAutoBeInterfaceGroupApplication {
         /**
          * Unique identifier name derived from Prisma schema structure.
          *
-         * Must correspond to schema namespaces, file names, table prefixes, or
+         * DO: Correspond to schema namespaces, file names, table prefixes, or
          * organizational annotations rather than arbitrary business domain names.
          */
         name: string & tags.MinLength<1>;

package/lib/agent/src/orchestrate/interface/structures/IAutoBeInterfaceOperationApplication.d.ts

@@ -22,7 +22,7 @@ export declare namespace IAutoBeInterfaceOperationApplication {
         /**
          * Array of API operations to generate.
          *
-         * Each operation in this array must include:
+         * Each operation in this array includes:
          *
          * - Specification: Detailed API specification with clear purpose and
          *   functionality
@@ -37,7 +37,7 @@ export declare namespace IAutoBeInterfaceOperationApplication {
          *   components.schemas
          * - ResponseBody: With typeName referencing appropriate response type
          *
-         * All operations must follow strict quality standards:
+         * All operations follow strict quality standards:
          *
          * 1. Detailed descriptions referencing Prisma schema comments
          * 2. Accurate parameter definitions matching path parameters
@@ -64,11 +64,10 @@ export declare namespace IAutoBeInterfaceOperationApplication {
      * reason and description fields, making it clear why the API was designed and
      * how it should be used.
      *
-     * All request bodies and responses for this operation must be object types
-     * and must reference named types defined in the components section. The
-     * content-type is always `application/json`. For file upload/download
-     * operations, use `string & tags.Format<"uri">` in the appropriate schema
-     * instead of binary data formats.
+     * DO: Use object types for all request bodies and responses. DO: Reference
+     * named types defined in the components section. DO: Use `application/json`
+     * as the content-type. DO: Use `string & tags.Format<"uri">` in the schema
+     * for file upload/download operations instead of binary data formats.
      *
      * In OpenAPI, this might represent:
      *
@@ -85,7 +84,7 @@ export declare namespace IAutoBeInterfaceOperationApplication {
      * }
      * ```
      */
-    interface IOperation extends Omit<AutoBeOpenApi.IOperation, "authorizationRole"> {
+    interface IOperation extends Omit<AutoBeOpenApi.IOperation, "authorizationRole" | "authorizationType"> {
         /**
          * Authorization roles required to access this API operation.
          *
@@ -93,16 +92,47 @@ export declare namespace IAutoBeInterfaceOperationApplication {
          * endpoint. Multiple roles can be specified to allow different types of
          * users to access the same endpoint.
          *
+         * ## ⚠️ CRITICAL: Role Multiplication Effect
+         *
+         * **EACH ROLE IN THIS ARRAY GENERATES A SEPARATE ENDPOINT**
+         *
+         * - If you specify `["admin", "moderator", "member"]`, this creates 3
+         *   separate endpoints
+         * - Total generated endpoints = operations × average roles.length
+         * - Example: 100 operations with 3 roles each = 300 actual endpoints
+         *
+         * ## 🔴 AVOID OVER-GENERATION
+         *
+         * **DO NOT create role-specific endpoints when a public endpoint would
+         * suffice:**
+         *
+         * - ❌ BAD: Separate GET endpoints for admin, member, moderator to view the
+         *   same public data
+         * - ✅ GOOD: Single public endpoint `[]` with role-based filtering in business
+         *   logic
+         *
+         * **DO NOT enumerate all possible roles when the Prisma schema uses a
+         * single User table:**
+         *
+         * - If Prisma has a User table with role/permission fields, you likely only
+         *   need `["user"]`
+         * - Avoid listing `["admin", "seller", "buyer", "moderator", ...]`
+         *   unnecessarily
+         * - The actual role checking happens in business logic, not at the endpoint
+         *   level
+         *
          * ## Naming Convention
          *
-         * All role names MUST use camelCase.
+         * DO: Use camelCase for all role names.
          *
          * ## Important Guidelines
          *
          * - Set to empty array `[]` for public endpoints that require no
          *   authentication
          * - Set to array with role strings for role-restricted endpoints
-         * - The role names MUST match exactly with the user type/role defined in the
+         * - **MINIMIZE the number of roles per endpoint to prevent explosion**
+         * - Consider if the endpoint can be public with role-based filtering instead
+         * - The role names match exactly with the user type/role defined in the
          *   database
          * - This will be used by the Realize Agent to generate appropriate decorator
          *   and authorization logic in the provider functions
@@ -111,11 +141,26 @@ export declare namespace IAutoBeInterfaceOperationApplication {
          *
          * ## Examples
          *
-         * - `[]` - Public endpoint, no authentication required
-         * - `["user"]` - Any authenticated user can access
-         * - `["admin"]` - Only admin users can access
+         * - `[]` - Public endpoint, no authentication required (PREFERRED for read
+         *   operations)
+         * - `["user"]` - Any authenticated user can access (PREFERRED for
+         *   user-specific operations)
+         * - `["admin"]` - Only admin users can access (USE SPARINGLY)
          * - `["admin", "moderator"]` - Both admin and moderator users can access
-         * - `["seller"]` - Only seller users can access
+         *   (AVOID if possible)
+         * - `["seller"]` - Only seller users can access (ONLY if Seller is a separate
+         *   table)
+         *
+         * ## Best Practices
+         *
+         * 1. **Start with public `[]` for all read operations** unless sensitive data
+         *    is involved
+         * 2. **Use single role `["user"]` for authenticated operations** and handle
+         *    permissions in business logic
+         * 3. **Only use multiple roles when absolutely necessary** for different
+         *    business logic paths
+         * 4. **Remember: Fewer roles = Fewer endpoints = Better performance and
+         *    maintainability**
          *
          * Note: The actual authentication/authorization implementation will be
          * handled by decorators at the controller level, and the provider function

package/lib/agent/src/orchestrate/interface/structures/IAutoBeInterfaceOperationsReviewApplication.d.ts

@@ -91,6 +91,42 @@ export declare namespace IAutoBeInterfaceOperationsReviewApplication {
          * operations unchanged. These operations are validated and ready for schema
          * generation and subsequent implementation phases.
          */
-        content: AutoBeOpenApi.IOperation[];
+        content: IOperation[];
+    }
+    /**
+     * Operation of the Restful API.
+     *
+     * This interface defines a single API endpoint with its HTTP {@link method},
+     * {@link path}, {@link parameters path parameters},
+     * {@link requestBody request body}, and {@link responseBody} structure. It
+     * corresponds to an individual operation in the paths section of an OpenAPI
+     * document.
+     *
+     * Each operation requires a detailed explanation of its purpose through the
+     * reason and description fields, making it clear why the API was designed and
+     * how it should be used.
+     *
+     * All request bodies and responses for this operation must be object types
+     * and must reference named types defined in the components section. The
+     * content-type is always `application/json`. For file upload/download
+     * operations, use `string & tags.Format<"uri">` in the appropriate schema
+     * instead of binary data formats.
+     *
+     * In OpenAPI, this might represent:
+     *
+     * ```json
+     * {
+     *   "/shoppings/customers/orders": {
+     *     "post": {
+     *       "description": "Create a new order application from shopping cart...",
+     *       "parameters": [...],
+     *       "requestBody": {...},
+     *       "responses": {...}
+     *     }
+     *   }
+     * }
+     * ```
+     */
+    interface IOperation extends Omit<AutoBeOpenApi.IOperation, "authorizationType"> {
     }
 }

package/lib/agent/src/orchestrate/interface/structures/IAutoBeInterfaceSchemaApplication.d.ts

@@ -13,10 +13,9 @@ export interface IAutoBeInterfaceSchemaApplication {
      * creation. This ensures that the final OpenAPI document has complete type
      * coverage for all operations.
      *
-     * CRITICAL: All schema definitions must follow the established naming
-     * conventions (IEntityName, IEntityName.ICreate, etc.) and must be thoroughly
-     * documented with descriptions that reference the original Prisma schema
-     * comments.
+     * DO: Follow established naming conventions (IEntityName,
+     * IEntityName.ICreate, etc.) DO: Document thoroughly with descriptions that
+     * reference the original Prisma schema comments.
      *
      * @param props Properties containing components to generate.
      */
@@ -24,6 +23,39 @@ export interface IAutoBeInterfaceSchemaApplication {
 }
 export declare namespace IAutoBeInterfaceSchemaApplication {
     interface IProps {
+        /**
+         * TypeScript draft code for schema definitions.
+         *
+         * This property contains TypeScript interface definitions that serve as a
+         * preliminary draft before generating the final JSON schema components.
+         * The draft allows for initial design and validation of the schema structure
+         * using TypeScript's type system before converting to OpenAPI/JSON Schema format.
+         *
+         * The draft typically includes:
+         * - Entity interfaces matching the Prisma models
+         * - Operation-specific variants (ICreate, IUpdate, etc.)
+         * - Utility types and enumerations
+         * - Type relationships and constraints
+         *
+         * This TypeScript draft serves as the foundation for the subsequent schema
+         * generation, ensuring type safety and consistency. The final schemas in the
+         * `schemas` property should be derived from and validated against this draft.
+         *
+         * Example draft structure:
+         * ```typescript
+         * interface IUser {
+         *   id: string;
+         *   email: string;
+         *   profile: IUserProfile;
+         * }
+         *
+         * namespace IUser {
+         *   interface ICreate extends Omit<IUser, "id"> {}
+         *   interface IUpdate extends Partial<ICreate> {}
+         * }
+         * ```
+         */
+        draft: string;
         /**
          * Complete set of schema components for the OpenAPI specification.
          *
@@ -31,23 +63,23 @@ export declare namespace IAutoBeInterfaceSchemaApplication {
          * the system. It is the central repository of all named schema types that
          * will be used throughout the API specification.
          *
-         * CRITICAL REQUIREMENT: All object types MUST be defined as named types in
-         * the components.schemas section. Inline anonymous object definitions are
-         * strictly prohibited.
+         * DO: Define all object types as named types in the components.schemas
+         * section. DO NOT: Use inline anonymous object definitions.
          *
-         * This components object should include:
+         * This components object includes:
          *
          * - Main entity types (IEntityName)
          * - Operation-specific variants (.ICreate, .IUpdate, .ISummary, etc.)
          * - Container types (IPage<T> for pagination)
          * - Enumeration types
          *
-         * All schema definitions must include detailed descriptions that reference
-         * the original Prisma schema comments and thoroughly document each
-         * property. Every property that references an object must use a $ref to a
-         * named type in the components.schemas section. This applies to all objects
-         * in request bodies, response bodies, and properties that are objects or
-         * arrays of objects.
+         * DO: Include detailed descriptions that reference the original Prisma
+         * schema comments and thoroughly document each property. DO: Use a $ref to
+         * a named type in the components.schemas section for every property that
+         * references an object.
+         *
+         * This applies to all objects in request bodies, response bodies, and
+         * properties that are objects or arrays of objects.
          *
          * Example structure:
          *

package/lib/agent/src/orchestrate/interface/structures/IAutobeInterfaceSchemasReviewApplication.d.ts

@@ -30,19 +30,16 @@ export declare namespace IAutoBeInterfaceSchemasReviewApplication {
         /**
          * Issues and problems found during schema analysis.
          *
-         * IMPORTANT: Only document problems that need fixing. Do NOT include:
-         *
-         * - Positive feedback about what's already correct
-         * - Compliments about well-structured schemas
-         * - Confirmation that certain aspects meet standards
+         * DO: Document only problems that need fixing.
+         * DO NOT: Include positive feedback, compliments, or confirmations
          *
          * Focus exclusively on issues organized by severity:
          *
-         * - CRITICAL: Security vulnerabilities (exposed passwords, missing auth
-         *   boundaries)
-         * - HIGH: Missing required variants, incorrect type mappings
-         * - MEDIUM: Missing format specifications, incomplete relationships
-         * - LOW: Documentation improvements, style consistency
+         * Severity levels:
+         * - Security vulnerabilities (exposed passwords, missing auth boundaries)
+         * - Missing required variants, incorrect type mappings
+         * - Missing format specifications, incomplete relationships
+         * - Documentation improvements, style consistency
          *
          * Each issue must include the specific schema name and what needs to be
          * fixed. If there are no issues at all, simply state: "No issues found."
@@ -66,21 +63,18 @@ export declare namespace IAutoBeInterfaceSchemasReviewApplication {
         /**
          * Final validated and enhanced schemas ready for production use.
          *
-         * CRITICAL REQUIREMENTS:
-         *
-         * - MUST NEVER be an empty object {}
-         * - MUST contain valid OpenAPI schema definitions
-         * - MUST include all entities that were in the original input
-         * - If original schemas have critical issues, MUST contain fixed versions
-         * - If entity names are wrong, MUST contain renamed correct versions
-         * - If schemas are missing variants, MUST include the created variants
-         *
-         * FORBIDDEN:
+         * DO:
+         * - Include valid OpenAPI schema definitions
+         * - Include all entities that were in the original input
+         * - Provide fixed versions if original schemas have issues
+         * - Rename entities correctly if names are wrong
+         * - Include created variants if schemas are missing them
          *
-         * - Empty object {} will cause all schemas to be deleted
-         * - Returning undefined or null
-         * - Including explanations or excuses in schema descriptions
-         * - Leaving broken schemas unfixed
+         * DO NOT:
+         * - Return an empty object {} (this will delete all schemas)
+         * - Return undefined or null
+         * - Include explanations or excuses in schema descriptions
+         * - Leave broken schemas unfixed
          *
          * When original schemas are beyond repair, recreate them properly based on
          * entity names and context. This field becomes the final schemas used by

package/lib/agent/src/orchestrate/interface/utils/validateAuthorizationSchema.d.ts

@@ -0,0 +1,7 @@
+import { AutoBeOpenApi } from "@autobe/interface";
+import { IValidation } from "typia";
+export declare const validateAuthorizationSchema: (props: {
+    errors: IValidation.IError[];
+    schemas: Record<string, AutoBeOpenApi.IJsonSchemaDescriptive>;
+    path: string;
+}) => void;

package/lib/agent/src/orchestrate/interface/utils/validateAuthorizationSchema.js

@@ -0,0 +1,35 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.validateAuthorizationSchema = void 0;
+const validateAuthorizationSchema = (props) => {
+    var _a, _b;
+    for (const [key, value] of Object.entries(props.schemas)) {
+        if (!key.endsWith(".IAuthorized"))
+            continue;
+        // Check if it's an object type
+        if (!isObjectSchema(value)) {
+            props.errors.push({
+                path: `${props.path}.${key}`,
+                expected: `AutoBeOpenApi.IJsonSchemaDescriptive<AutoBeOpenApi.IJsonSchema.IObject>`,
+                value: value,
+                description: `${key} must be an object type for authorization responses`,
+            });
+            continue;
+        }
+        // Check if token property exists
+        (_a = value.properties) !== null && _a !== void 0 ? _a : (value.properties = {});
+        value.properties["token"] = {
+            $ref: "#/components/schemas/IAuthorizationToken",
+            description: "JWT token information for authentication",
+        };
+        (_b = value.required) !== null && _b !== void 0 ? _b : (value.required = []);
+        if (value.required.includes("token") === false) {
+            value.required.push("token");
+        }
+    }
+};
+exports.validateAuthorizationSchema = validateAuthorizationSchema;
+const isObjectSchema = (schema) => {
+    return "type" in schema && schema.type === "object";
+};
+//# sourceMappingURL=validateAuthorizationSchema.js.map

package/lib/agent/src/orchestrate/interface/utils/validateAuthorizationSchema.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"validateAuthorizationSchema.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/interface/utils/validateAuthorizationSchema.ts"],"names":[],"mappings":";;;AAGO,MAAM,2BAA2B,GAAG,CAAC,KAI3C,EAAQ,EAAE;;IACT,KAAK,MAAM,CAAC,GAAG,EAAE,KAAK,CAAC,IAAI,MAAM,CAAC,OAAO,CAAC,KAAK,CAAC,OAAO,CAAC,EAAE,CAAC;QACzD,IAAI,CAAC,GAAG,CAAC,QAAQ,CAAC,cAAc,CAAC;YAAE,SAAS;QAE5C,+BAA+B;QAC/B,IAAI,CAAC,cAAc,CAAC,KAAK,CAAC,EAAE,CAAC;YAC3B,KAAK,CAAC,MAAM,CAAC,IAAI,CAAC;gBAChB,IAAI,EAAE,GAAG,KAAK,CAAC,IAAI,IAAI,GAAG,EAAE;gBAC5B,QAAQ,EAAE,yEAAyE;gBACnF,KAAK,EAAE,KAAK;gBACZ,WAAW,EAAE,GAAG,GAAG,qDAAqD;aACzE,CAAC,CAAC;YACH,SAAS;QACX,CAAC;QAED,iCAAiC;QACjC,MAAA,KAAK,CAAC,UAAU,oCAAhB,KAAK,CAAC,UAAU,GAAK,EAAE,EAAC;QACxB,KAAK,CAAC,UAAU,CAAC,OAAO,CAAC,GAAG;YAC1B,IAAI,EAAE,0CAA0C;YAChD,WAAW,EAAE,0CAA0C;SACsB,CAAC;QAEhF,MAAA,KAAK,CAAC,QAAQ,oCAAd,KAAK,CAAC,QAAQ,GAAK,EAAE,EAAC;QACtB,IAAI,KAAK,CAAC,QAAQ,CAAC,QAAQ,CAAC,OAAO,CAAC,KAAK,KAAK,EAAE,CAAC;YAC/C,KAAK,CAAC,QAAQ,CAAC,IAAI,CAAC,OAAO,CAAC,CAAC;QAC/B,CAAC;IACH,CAAC;AACH,CAAC,CAAC;AA/BW,QAAA,2BAA2B,+BA+BtC;AAEF,MAAM,cAAc,GAAG,CACrB,MAA4C,EACuC,EAAE;IACrF,OAAO,MAAM,IAAI,MAAM,IAAI,MAAM,CAAC,IAAI,KAAK,QAAQ,CAAC;AACtD,CAAC,CAAC"}

package/lib/agent/src/orchestrate/prisma/histories/transformPrismaComponentsHistories.js

@@ -1,27 +1,20 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.transformPrismaComponentsHistories = void 0;
+const NamingConvention_1 = require("typia/lib/utils/NamingConvention");
 const uuid_1 = require("uuid");
 const transformPrismaComponentsHistories = (state, prefix = null) => {
     if (state.analyze === null)
-        return [
-            {
-                id: (0, uuid_1.v4)(),
-                created_at: new Date().toISOString(),
-                type: "systemMessage",
-                text: [
-                    "Requirement analysis is not yet completed.",
-                    "Don't call any tool function,",
-                    "but say to process the requirement analysis.",
-                ].join(" "),
-            },
-        ];
+        // unreachable
+        throw new Error("Analyze state is not set.");
+    if (prefix)
+        prefix = NamingConvention_1.NamingConvention.snake(prefix);
     return [
         {
             id: (0, uuid_1.v4)(),
             created_at: new Date().toISOString(),
             type: "systemMessage",
-            text: "# Prisma Component Extraction Agent - System Prompt\n\nYou are a world-class database architecture analyst specializing in domain-driven design and component extraction for Prisma schema generation. Your expertise lies in analyzing business requirements and organizing database entities into logical, maintainable components that follow enterprise-grade patterns.\n\n## Core Mission\n\nTransform user requirements into a structured component organization that will serve as the foundation for complete Prisma schema generation. You extract business domains, identify required database tables, and organize them into logical components following domain-driven design principles.\n\n## Key Responsibilities\n\n### 1. Requirements Analysis\n- **Deep Business Understanding**: Analyze user requirements to identify core business domains and entities\n- **Entity Extraction**: Identify all database tables needed to fulfill the business requirements\n- **Domain Boundaries**: Determine clear boundaries between different business domains\n- **Relationship Mapping**: Understand how different domains interact and reference each other\n\n### 2. Component Organization\n- **Domain-Driven Grouping**: Organize tables into logical business domains (typically 8-10 components)\n- **Dependency Analysis**: Ensure proper component ordering for schema generation\n- **Naming Consistency**: Apply consistent naming conventions across all components\n- **Scalability Planning**: Structure components for maintainable, scalable database architecture\n\n### 3. Table Name Standardization\n- **Plural Convention**: Convert all table names to plural form using snake_case\n- **Domain Prefixing**: Apply appropriate domain prefixes where needed for clarity\n- **Consistency Check**: Ensure naming consistency across related tables\n- **Business Alignment**: Match table names to business terminology and concepts\n\n## Component Organization Guidelines\n\n### Typical Domain Categories\n\nBased on enterprise application patterns, organize components into these common domains:\n\n1. **Systematic/Core** (`schema-01-systematic.prisma`)\n   - System configuration, channels, sections\n   - Application metadata and settings\n   - Core infrastructure tables\n\n2. **Identity/Actors** (`schema-02-actors.prisma`)\n   - Users, customers, administrators\n   - Authentication and authorization\n   - User profiles and preferences\n\n3. **Business Logic** (`schema-03-{domain}.prisma`)\n   - Core business entities specific to the application\n   - Domain-specific workflows and processes\n   - Main business data structures\n\n4. **Sales/Commerce** (`schema-04-sales.prisma`)\n   - Products, services, catalog management\n   - Sales transactions and snapshots\n   - Pricing and inventory basics\n\n5. **Shopping/Carts** (`schema-05-carts.prisma`)\n   - Shopping cart functionality\n   - Cart items and management\n   - Session-based shopping data\n\n6. **Orders/Transactions** (`schema-06-orders.prisma`)\n   - Order processing and fulfillment\n   - Payment processing\n   - Order lifecycle management\n\n7. **Promotions/Coupons** (`schema-07-coupons.prisma`)\n   - Discount systems and coupon management\n   - Promotional campaigns\n   - Loyalty programs\n\n8. **Financial/Coins** (`schema-08-coins.prisma`)\n   - Digital currency systems\n   - Mileage and points management\n   - Financial transactions\n\n9. **Communication/Inquiries** (`schema-09-inquiries.prisma`)\n   - Customer support systems\n   - FAQ and help desk\n   - Communication logs\n\n10. **Content/Articles** (`schema-10-articles.prisma`)\n    - Content management systems\n    - Blog and article publishing\n    - User-generated content\n\n### Component Structure Principles\n\n- **Single Responsibility**: Each component should represent one cohesive business domain\n- **Logical Grouping**: Tables within a component should be closely related\n- **Dependency Order**: Components should be ordered to minimize cross-dependencies\n- **Balanced Size**: Aim for 3-15 tables per component for maintainability\n\n## Table Naming Standards\n\n### Required Naming Conventions\n\n1. **Plural Forms**: All table names must be plural\n   - `user` \u2192 `users`\n   - `product` \u2192 `products`\n   - `order_item` \u2192 `order_items`\n\n2. **Snake Case**: Use snake_case for all table names\n   - `UserProfile` \u2192 `user_profiles`\n   - `OrderItem` \u2192 `order_items`\n   - `ShoppingCart` \u2192 `shopping_carts`\n\n3. **Domain Prefixes**: Apply consistent prefixes within domains\n   - Shopping domain: `shopping_customers`, `shopping_carts`, `shopping_orders`\n   - BBS domain: `bbs_articles`, `bbs_comments`, `bbs_categories`\n\n4. **Special Table Types**:\n   - **Snapshots**: Add `_snapshots` suffix for versioning tables\n   - **Junction Tables**: Use both entity names: `user_roles`, `product_categories`\n   - **Materialized Views**: Will be handled by the second agent with `mv_` prefix\n\n### Business Entity Patterns\n\nCommon table patterns to identify:\n\n- **Core Entities**: Main business objects (users, products, orders)\n- **Snapshot Tables**: For audit trails and versioning (user_snapshots, order_snapshots)\n- **Junction Tables**: For many-to-many relationships (user_roles, product_tags)\n- **Configuration Tables**: For system settings and parameters\n- **Log Tables**: For tracking and audit purposes\n\n## Function Calling Requirements\n\n### Output Structure\n\nYou must generate a structured function call using the `IAutoBePrismaComponentApplication.IProps` interface:\n\n```typescript\ninterface IAutoBePrismaComponentApplication.IProps {\n  thinking: string;\n  review: string;\n  decision: string;\n  components: AutoBePrisma.IComponent[];\n}\n```\n\n### Component Interface Compliance\n\nEach component must follow the `AutoBePrisma.IComponent` structure:\n\n```typescript\ninterface IComponent {\n  filename: string & tags.Pattern<\"^[a-zA-Z0-9._-]+\\\\.prisma$\">;\n  namespace: string;\n  thinking: string;\n  review: string;\n  rationale: string;\n  tables: Array<string & tags.Pattern<\"^[a-z][a-z0-9_]*$\">>;\n}\n```\n\n### Quality Requirements\n\n- **Filename Format**: `schema-{number}-{domain}.prisma` with proper numbering\n- **Namespace Clarity**: Use PascalCase for namespace names that clearly represent the domain\n- **Table Completeness**: Include ALL tables required by the business requirements\n- **Pattern Compliance**: All table names must match the regex pattern `^[a-z][a-z0-9_]*$`\n- **Top-Level Thought Process**:\n  - `thinking`: Initial thoughts on namespace classification criteria across all domains\n  - `review`: Review and refinement of the overall namespace classification\n  - `decision`: Final decision on the complete namespace organization\n- **Component-Level Thought Process**: \n  - `thinking`: Initial thoughts on why these specific tables belong together\n  - `review`: Review considerations for this component grouping\n  - `rationale`: Final rationale for this component's composition\n\n## Analysis Process\n\n### Step 1: Requirements Deep Dive\n1. **Business Domain Analysis**: Identify all business domains mentioned in requirements\n2. **Entity Extraction**: List all database entities needed to fulfill requirements\n3. **Relationship Mapping**: Understand how entities relate across domains\n4. **Scope Validation**: Ensure all functional requirements are covered\n\n### Step 2: Domain Organization\n1. **Component Identification**: Group related entities into logical components\n2. **Dependency Analysis**: Order components to minimize cross-dependencies\n3. **Naming Standardization**: Apply consistent naming conventions\n4. **Balance Check**: Ensure reasonable distribution of tables across components\n\n### Step 3: Validation\n1. **Coverage Verification**: Confirm all requirements are addressed\n2. **Consistency Check**: Verify naming and organization consistency\n3. **Scalability Assessment**: Ensure the structure supports future growth\n4. **Business Alignment**: Validate alignment with business terminology\n\n## Critical Success Factors\n\n### Must-Have Qualities\n\n1. **Complete Coverage**: Every business requirement must be reflected in table organization\n2. **Logical Grouping**: Related tables must be in the same component\n3. **Consistent Naming**: All table names must follow the established conventions\n4. **Proper Ordering**: Components must be ordered to handle dependencies correctly\n5. **Domain Clarity**: Each component must represent a clear business domain\n\n### Common Pitfalls to Avoid\n\n- **Over-Fragmentation**: Don't create too many small components\n- **Under-Organization**: Don't put unrelated tables in the same component\n- **Naming Inconsistency**: Don't mix naming conventions\n- **Missing Entities**: Don't overlook entities mentioned in requirements\n- **Circular Dependencies**: Don't create component dependency cycles\n\n## Working Language\n\n- **Default Language**: English for all technical terms, model names, and field names\n- **User Language**: Use the language specified by the user for thinking and responses\n- **Technical Consistency**: Maintain English for all database-related terminology regardless of user language\n\n## Output Format\n\nAlways respond with a single function call that provides the complete component organization:\n\n```typescript\n// Example function call structure\nconst componentExtraction: IAutoBePrismaComponentApplication.IProps = {\n  thinking: \"Based on the business requirements, I identify several key domains: user management, product catalog, order processing, and content management. Each domain has clear boundaries and responsibilities.\",\n  review: \"Upon review, I noticed that some entities like 'shopping_channel_categories' bridge multiple domains. I've placed them based on their primary responsibility and ownership.\",\n  decision: \"Final decision: Organize tables into 10 main namespaces following domain-driven design principles. This structure provides clear separation of concerns, maintainable code organization, and supports future scalability.\",\n  components: [\n    {\n      filename: \"schema-01-systematic.prisma\",\n      namespace: \"Systematic\",\n      thinking: \"These tables all relate to system configuration and channel management. They form the foundation of the platform.\",\n      review: \"Considering the relationships, configurations table has connections to multiple domains but fundamentally defines system behavior.\",\n      rationale: \"Grouping all system configuration tables together provides a clear foundation layer that other domains can reference.\",\n      tables: [\"channels\", \"sections\", \"configurations\"]\n    },\n    {\n      filename: \"schema-02-actors.prisma\", \n      namespace: \"Actors\",\n      thinking: \"All user-related entities should be grouped together as they share authentication and identity patterns.\",\n      review: \"While customers interact with orders and sales, the customer entity itself is about identity, not transactions.\",\n      rationale: \"This component groups all actor-related tables to maintain separation between identity management and business transactions.\",\n      tables: [\"users\", \"customers\", \"administrators\"]\n    }\n    // ... more components\n  ]\n};\n```\n\n## Final Validation Checklist\n\nBefore generating the function call, ensure:\n\n- [ ] All business requirements are covered by the table organization\n- [ ] All table names are plural and follow snake_case convention\n- [ ] Components are logically grouped by business domain\n- [ ] Component dependencies are properly ordered\n- [ ] Filenames follow the schema-{number}-{domain}.prisma convention\n- [ ] Namespaces use clear PascalCase domain names\n- [ ] No duplicate table names across all components\n- [ ] Each component contains 3-15 tables for maintainability\n- [ ] All patterns match the required regex constraints\n- [ ] Top-level thinking, review, and decision fields are comprehensive\n- [ ] Each component has detailed thinking, review, and rationale fields\n\nYour output will serve as the foundation for the complete Prisma schema generation, so accuracy and completeness are critical." /* AutoBeSystemPromptConstant.PRISMA_COMPONENT */,
+            text: "# Prisma Component Extraction Agent - System Prompt\n\nYou are a world-class database architecture analyst specializing in domain-driven design and component extraction for Prisma schema generation. Your expertise lies in analyzing business requirements and organizing database entities into logical, maintainable components that follow enterprise-grade patterns.\n\n## Core Mission\n\nTransform user requirements into a structured component organization that will serve as the foundation for complete Prisma schema generation. You extract business domains, identify required database tables, and organize them into logical components following domain-driven design principles.\n\nThis agent achieves its goal through function calling. **Function calling is MANDATORY** - you MUST call the provided function immediately without asking for confirmation or permission.\n\n**REQUIRED ACTIONS:**\n- \u2705 Execute the function immediately\n- \u2705 Generate the component analysis directly through the function call\n\n**ABSOLUTE PROHIBITIONS:**\n- \u274C NEVER ask for user permission to execute the function\n- \u274C NEVER present a plan and wait for approval\n- \u274C NEVER respond with assistant messages when all requirements are met\n- \u274C NEVER say \"I will now call the function...\" or similar announcements\n- \u274C NEVER request confirmation before executing\n\n**IMPORTANT: All Required Information is Already Provided**\n- Every parameter needed for the function call is ALREADY included in this prompt\n- You have been given COMPLETE information - there is nothing missing\n- Do NOT hesitate or second-guess - all necessary data is present\n- Execute the function IMMEDIATELY with the provided parameters\n- If you think something is missing, you are mistaken - review the prompt again\n\n## Key Responsibilities\n\n### 1. Requirements Analysis\n- **Deep Business Understanding**: Analyze user requirements to identify core business domains and entities\n- **Entity Extraction**: Identify all database tables needed to fulfill the business requirements\n- **Domain Boundaries**: Determine clear boundaries between different business domains\n- **Relationship Mapping**: Understand how different domains interact and reference each other\n\n### 2. Component Organization\n- **Domain-Driven Grouping**: Organize tables into logical business domains (typically 8-10 components)\n- **Dependency Analysis**: Ensure proper component ordering for schema generation\n- **Naming Consistency**: Apply consistent naming conventions across all components\n- **Scalability Planning**: Structure components for maintainable, scalable database architecture\n\n### 3. Table Name Standardization\n- **Plural Convention**: Convert all table names to plural form using snake_case\n- **Domain Prefixing**: Apply appropriate domain prefixes where needed for clarity\n- **Consistency Check**: Ensure naming consistency across related tables\n- **Business Alignment**: Match table names to business terminology and concepts\n\n## Component Organization Guidelines\n\n### Typical Domain Categories\n\nBased on enterprise application patterns, organize components into these common domains:\n\n1. **Systematic/Core** (`schema-01-systematic.prisma`)\n   - System configuration, channels, sections\n   - Application metadata and settings\n   - Core infrastructure tables\n\n2. **Identity/Actors** (`schema-02-actors.prisma`)\n   - Users, customers, administrators\n   - Authentication and authorization\n   - User profiles and preferences\n\n3. **Business Logic** (`schema-03-{domain}.prisma`)\n   - Core business entities specific to the application\n   - Domain-specific workflows and processes\n   - Main business data structures\n\n4. **Sales/Commerce** (`schema-04-sales.prisma`)\n   - Products, services, catalog management\n   - Sales transactions and snapshots\n   - Pricing and inventory basics\n\n5. **Shopping/Carts** (`schema-05-carts.prisma`)\n   - Shopping cart functionality\n   - Cart items and management\n   - Session-based shopping data\n\n6. **Orders/Transactions** (`schema-06-orders.prisma`)\n   - Order processing and fulfillment\n   - Payment processing\n   - Order lifecycle management\n\n7. **Promotions/Coupons** (`schema-07-coupons.prisma`)\n   - Discount systems and coupon management\n   - Promotional campaigns\n   - Loyalty programs\n\n8. **Financial/Coins** (`schema-08-coins.prisma`)\n   - Digital currency systems\n   - Mileage and points management\n   - Financial transactions\n\n9. **Communication/Inquiries** (`schema-09-inquiries.prisma`)\n   - Customer support systems\n   - FAQ and help desk\n   - Communication logs\n\n10. **Content/Articles** (`schema-10-articles.prisma`)\n    - Content management systems\n    - Blog and article publishing\n    - User-generated content\n\n### Component Structure Principles\n\n- **Single Responsibility**: Each component should represent one cohesive business domain\n- **Logical Grouping**: Tables within a component should be closely related\n- **Dependency Order**: Components should be ordered to minimize cross-dependencies\n- **Balanced Size**: Aim for 3-15 tables per component for maintainability\n\n## Table Naming Standards\n\n### Required Naming Conventions\n\n1. **Plural Forms**: All table names must be plural\n   - `user` \u2192 `users`\n   - `product` \u2192 `products`\n   - `order_item` \u2192 `order_items`\n\n2. **Snake Case**: Use snake_case for all table names\n   - `UserProfile` \u2192 `user_profiles`\n   - `OrderItem` \u2192 `order_items`\n   - `ShoppingCart` \u2192 `shopping_carts`\n\n3. **Domain Prefixes**: Apply consistent prefixes within domains\n   - Shopping domain: `shopping_customers`, `shopping_carts`, `shopping_orders`\n   - BBS domain: `bbs_articles`, `bbs_comments`, `bbs_categories`\n\n4. **Special Table Types**:\n   - **Snapshots**: Add `_snapshots` suffix for versioning tables\n   - **Junction Tables**: Use both entity names: `user_roles`, `product_categories`\n   - **Materialized Views**: Will be handled by the second agent with `mv_` prefix\n\n### Business Entity Patterns\n\nCommon table patterns to identify:\n\n- **Core Entities**: Main business objects (users, products, orders)\n- **Snapshot Tables**: For audit trails and versioning (user_snapshots, order_snapshots)\n- **Junction Tables**: For many-to-many relationships (user_roles, product_tags)\n- **Configuration Tables**: For system settings and parameters\n- **Log Tables**: For tracking and audit purposes\n\n## Function Calling Requirements\n\n### Output Structure\n\nYou must generate a structured function call using the `IAutoBePrismaComponentApplication.IProps` interface:\n\n```typescript\ninterface IAutoBePrismaComponentApplication.IProps {\n  thinking: string;\n  review: string;\n  decision: string;\n  components: AutoBePrisma.IComponent[];\n}\n```\n\n### Component Interface Compliance\n\nEach component must follow the `AutoBePrisma.IComponent` structure:\n\n```typescript\ninterface IComponent {\n  filename: string & tags.Pattern<\"^[a-zA-Z0-9._-]+\\\\.prisma$\">;\n  namespace: string;\n  thinking: string;\n  review: string;\n  rationale: string;\n  tables: Array<string & tags.Pattern<\"^[a-z][a-z0-9_]*$\">>;\n}\n```\n\n### Quality Requirements\n\n- **Filename Format**: `schema-{number}-{domain}.prisma` with proper numbering\n- **Namespace Clarity**: Use PascalCase for namespace names that clearly represent the domain\n- **Table Completeness**: Include ALL tables required by the business requirements\n- **Pattern Compliance**: All table names must match the regex pattern `^[a-z][a-z0-9_]*$`\n- **Top-Level Thought Process**:\n  - `thinking`: Initial thoughts on namespace classification criteria across all domains\n  - `review`: Review and refinement of the overall namespace classification\n  - `decision`: Final decision on the complete namespace organization\n- **Component-Level Thought Process**: \n  - `thinking`: Initial thoughts on why these specific tables belong together\n  - `review`: Review considerations for this component grouping\n  - `rationale`: Final rationale for this component's composition\n\n## Analysis Process\n\n### Step 1: Requirements Deep Dive\n1. **Business Domain Analysis**: Identify all business domains mentioned in requirements\n2. **Entity Extraction**: List all database entities needed to fulfill requirements\n3. **Relationship Mapping**: Understand how entities relate across domains\n4. **Scope Validation**: Ensure all functional requirements are covered\n\n### Step 2: Domain Organization\n1. **Component Identification**: Group related entities into logical components\n2. **Dependency Analysis**: Order components to minimize cross-dependencies\n3. **Naming Standardization**: Apply consistent naming conventions\n4. **Balance Check**: Ensure reasonable distribution of tables across components\n\n### Step 3: Validation\n1. **Coverage Verification**: Confirm all requirements are addressed\n2. **Consistency Check**: Verify naming and organization consistency\n3. **Scalability Assessment**: Ensure the structure supports future growth\n4. **Business Alignment**: Validate alignment with business terminology\n\n## Critical Success Factors\n\n### Must-Have Qualities\n\n1. **Complete Coverage**: Every business requirement must be reflected in table organization\n2. **Logical Grouping**: Related tables must be in the same component\n3. **Consistent Naming**: All table names must follow the established conventions\n4. **Proper Ordering**: Components must be ordered to handle dependencies correctly\n5. **Domain Clarity**: Each component must represent a clear business domain\n\n### Common Pitfalls to Avoid\n\n- **Over-Fragmentation**: Don't create too many small components\n- **Under-Organization**: Don't put unrelated tables in the same component\n- **Naming Inconsistency**: Don't mix naming conventions\n- **Missing Entities**: Don't overlook entities mentioned in requirements\n- **Circular Dependencies**: Don't create component dependency cycles\n\n## Working Language\n\n- **Default Language**: English for all technical terms, model names, and field names\n- **User Language**: Use the language specified by the user for thinking and responses\n- **Technical Consistency**: Maintain English for all database-related terminology regardless of user language\n\n## Output Format\n\nAlways respond with a single function call that provides the complete component organization:\n\n```typescript\n// Example function call structure\nconst componentExtraction: IAutoBePrismaComponentApplication.IProps = {\n  thinking: \"Based on the business requirements, I identify several key domains: user management, product catalog, order processing, and content management. Each domain has clear boundaries and responsibilities.\",\n  review: \"Upon review, I noticed that some entities like 'shopping_channel_categories' bridge multiple domains. I've placed them based on their primary responsibility and ownership.\",\n  decision: \"Final decision: Organize tables into 10 main namespaces following domain-driven design principles. This structure provides clear separation of concerns, maintainable code organization, and supports future scalability.\",\n  components: [\n    {\n      filename: \"schema-01-systematic.prisma\",\n      namespace: \"Systematic\",\n      thinking: \"These tables all relate to system configuration and channel management. They form the foundation of the platform.\",\n      review: \"Considering the relationships, configurations table has connections to multiple domains but fundamentally defines system behavior.\",\n      rationale: \"Grouping all system configuration tables together provides a clear foundation layer that other domains can reference.\",\n      tables: [\"channels\", \"sections\", \"configurations\"]\n    },\n    {\n      filename: \"schema-02-actors.prisma\", \n      namespace: \"Actors\",\n      thinking: \"All user-related entities should be grouped together as they share authentication and identity patterns.\",\n      review: \"While customers interact with orders and sales, the customer entity itself is about identity, not transactions.\",\n      rationale: \"This component groups all actor-related tables to maintain separation between identity management and business transactions.\",\n      tables: [\"users\", \"customers\", \"administrators\"]\n    }\n    // ... more components\n  ]\n};\n```\n\n## Final Validation Checklist\n\nBefore generating the function call, ensure:\n\n- [ ] All business requirements are covered by the table organization\n- [ ] All table names are plural and follow snake_case convention\n- [ ] Components are logically grouped by business domain\n- [ ] Component dependencies are properly ordered\n- [ ] Filenames follow the schema-{number}-{domain}.prisma convention\n- [ ] Namespaces use clear PascalCase domain names\n- [ ] No duplicate table names across all components\n- [ ] Each component contains 3-15 tables for maintainability\n- [ ] All patterns match the required regex constraints\n- [ ] Top-level thinking, review, and decision fields are comprehensive\n- [ ] Each component has detailed thinking, review, and rationale fields\n\nYour output will serve as the foundation for the complete Prisma schema generation, so accuracy and completeness are critical." /* AutoBeSystemPromptConstant.PRISMA_COMPONENT */,
         },
         {
             id: (0, uuid_1.v4)(),
@@ -43,13 +36,14 @@ const transformPrismaComponentsHistories = (state, prefix = null) => {
                 `* Prefix provided by the user: ${prefix}`,
                 "",
                 "The user wants all database schema (table) names to start with the prefix provided below.",
-                "If the prefix is `null`, it should be ignored.",
-                "If a prefix is provided, all table names **must begin with it**.",
-                "However, if there is a special-purpose prefix like `mv` (for materialized views), it **must precede** the given prefix.",
+                "",
+                "DO: Use the provided prefix for all table names",
+                "DO: Place special-purpose prefixes like `mv` (for materialized views) before the given prefix",
+                "DO NOT: Apply prefix if it is `null`",
                 "",
                 "## Prefix Example",
                 "",
-                "If the prefix is `shopping`, then table names should be like:",
+                "If the prefix is `shopping`, then table names are like:",
                 "",
                 "* `shopping_sales`",
                 "* `shopping_sale_options`",

package/lib/agent/src/orchestrate/prisma/histories/transformPrismaComponentsHistories.js.map

@@ -1 +1 @@
-{"version":3,"file":"transformPrismaComponentsHistories.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/prisma/histories/transformPrismaComponentsHistories.ts"],"names":[],"mappings":";;;AACA,+BAA0B;AAKnB,MAAM,kCAAkC,GAAG,CAChD,KAAkB,EAClB,SAAwB,IAAI,EAG5B,EAAE;IACF,IAAI,KAAK,CAAC,OAAO,KAAK,IAAI;QACxB,OAAO;YACL;gBACE,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;gBACpC,IAAI,EAAE,eAAe;gBACrB,IAAI,EAAE;oBACJ,4CAA4C;oBAC5C,+BAA+B;oBAC/B,8CAA8C;iBAC/C,CAAC,IAAI,CAAC,GAAG,CAAC;aACZ;SACF,CAAC;IACJ,OAAO;QACL;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,o+XAA6C;SAClD;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,kBAAkB;YACxB,IAAI,EAAE;gBACJ,0CAA0C;gBAC1C,EAAE;gBACF,8DAA8D;gBAC9D,gDAAgD;gBAChD,EAAE;gBACF,gCAAgC;gBAChC,EAAE;gBACF,SAAS;gBACT,IAAI,CAAC,SAAS,CAAC,KAAK,CAAC,OAAO,CAAC,KAAK,CAAC;gBACnC,KAAK;gBACL,WAAW;gBACX,EAAE;gBACF,kCAAkC,MAAM,EAAE;gBAC1C,EAAE;gBACF,2FAA2F;gBAC3F,gDAAgD;gBAChD,kEAAkE;gBAClE,yHAAyH;gBACzH,EAAE;gBACF,mBAAmB;gBACnB,EAAE;gBACF,+DAA+D;gBAC/D,EAAE;gBACF,oBAAoB;gBACpB,2BAA2B;gBAC3B,EAAE;gBACF,uIAAuI;gBACvI,cAAc;gBACd,EAAE;gBACF,6BAA6B;gBAC7B,EAAE;gBACF,EAAE;gBACF,KAAK,CAAC,OAAO,CAAC,KAAK,CAAC,MAAM,GAAG,CAAC;oBAC5B,CAAC,CAAC;wBACE,uBAAuB;wBACvB,EAAE;wBACF,sEAAsE,KAAK,CAAC,OAAO,CAAC,KAAK,CAAC,IAAI,CAAC,IAAI,CAAC,GAAG;wBACvG,EAAE;wBACF,sDAAsD;wBACtD,uFAAuF;wBACvF,EAAE;wBACF,uCAAuC;wBACvC,EAAE;wBACF,KAAK,CAAC,OAAO,CAAC,KAAK;6BAChB,GAAG,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,KAAK,MAAM,IAAI,IAAI,CAAC,IAAI,CAAC,WAAW,EAAE,EAAE,CAAC;6BACvD,IAAI,CAAC,IAAI,CAAC;wBACb,EAAE;qBACH,CAAC,IAAI,CAAC,IAAI,CAAC;oBACd,CAAC,CAAC,EAAE;aACP,CAAC,IAAI,CAAC,IAAI,CAAC;SACb;KACF,CAAC;AACJ,CAAC,CAAC;AAnFW,QAAA,kCAAkC,sCAmF7C"}
+{"version":3,"file":"transformPrismaComponentsHistories.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/prisma/histories/transformPrismaComponentsHistories.ts"],"names":[],"mappings":";;;AACA,uEAAoE;AACpE,+BAA0B;AAKnB,MAAM,kCAAkC,GAAG,CAChD,KAAkB,EAClB,SAAwB,IAAI,EAG5B,EAAE;IACF,IAAI,KAAK,CAAC,OAAO,KAAK,IAAI;QACxB,cAAc;QACd,MAAM,IAAI,KAAK,CAAC,2BAA2B,CAAC,CAAC;IAC/C,IAAI,MAAM;QAAE,MAAM,GAAG,mCAAgB,CAAC,KAAK,CAAC,MAAM,CAAC,CAAC;IACpD,OAAO;QACL;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,wkaAA6C;SAClD;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,kBAAkB;YACxB,IAAI,EAAE;gBACJ,0CAA0C;gBAC1C,EAAE;gBACF,8DAA8D;gBAC9D,gDAAgD;gBAChD,EAAE;gBACF,gCAAgC;gBAChC,EAAE;gBACF,SAAS;gBACT,IAAI,CAAC,SAAS,CAAC,KAAK,CAAC,OAAO,CAAC,KAAK,CAAC;gBACnC,KAAK;gBACL,WAAW;gBACX,EAAE;gBACF,kCAAkC,MAAM,EAAE;gBAC1C,EAAE;gBACF,2FAA2F;gBAC3F,EAAE;gBACF,iDAAiD;gBACjD,+FAA+F;gBAC/F,sCAAsC;gBACtC,EAAE;gBACF,mBAAmB;gBACnB,EAAE;gBACF,yDAAyD;gBACzD,EAAE;gBACF,oBAAoB;gBACpB,2BAA2B;gBAC3B,EAAE;gBACF,uIAAuI;gBACvI,cAAc;gBACd,EAAE;gBACF,6BAA6B;gBAC7B,EAAE;gBACF,EAAE;gBACF,KAAK,CAAC,OAAO,CAAC,KAAK,CAAC,MAAM,GAAG,CAAC;oBAC5B,CAAC,CAAC;wBACE,uBAAuB;wBACvB,EAAE;wBACF,sEAAsE,KAAK,CAAC,OAAO,CAAC,KAAK,CAAC,IAAI,CAAC,IAAI,CAAC,GAAG;wBACvG,EAAE;wBACF,sDAAsD;wBACtD,uFAAuF;wBACvF,EAAE;wBACF,uCAAuC;wBACvC,EAAE;wBACF,KAAK,CAAC,OAAO,CAAC,KAAK;6BAChB,GAAG,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,KAAK,MAAM,IAAI,IAAI,CAAC,IAAI,CAAC,WAAW,EAAE,EAAE,CAAC;6BACvD,IAAI,CAAC,IAAI,CAAC;wBACb,EAAE;qBACH,CAAC,IAAI,CAAC,IAAI,CAAC;oBACd,CAAC,CAAC,EAAE;aACP,CAAC,IAAI,CAAC,IAAI,CAAC;SACb;KACF,CAAC;AACJ,CAAC,CAAC;AA3EW,QAAA,kCAAkC,sCA2E7C"}