@autobe/agent 0.16.1 → 0.18.0

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

@@ -0,0 +1,108 @@
+import { tags } from "typia";
+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.
+     *
+     * @param props Properties containing the groups to be created for API
+     *   organization
+     */
+    makeGroups(props: IAutoBeInterfaceGroupApplication.IProps): void;
+}
+export declare namespace IAutoBeInterfaceGroupApplication {
+    interface IProps {
+        /**
+         * 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
+         * overlap.
+         */
+        groups: IGroup[] & tags.MinItems<1>;
+    }
+    /**
+     * Definition of a logical API endpoint group based on Prisma schema
+     * organization.
+     *
+     * **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.
+     *
+     * **Primary Group Sources (in order of priority):**
+     *
+     * 1. **Prisma Schema Namespaces**: Use namespace names (e.g., `namespace
+     *    Shopping` → "Shopping")
+     * 2. **Schema File Names**: Derive from file names (e.g., `shopping.prisma` →
+     *    "Shopping")
+     * 3. **Table Prefix Patterns**: Use consistent prefixes (e.g., `shopping_orders`
+     *    → "Shopping")
+     * 4. **Schema Comments/Annotations**: Follow organizational comments in schema
+     *
+     * **Group Creation Guidelines:**
+     *
+     * - Each group must cover 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
+     *
+     * **When to Create Schema-Independent Groups:**
+     *
+     * Only create groups that don't correspond to Prisma schema organization
+     * when:
+     *
+     * - Requirements include functionality not represented in any schema entity
+     * - Cross-cutting concerns span multiple schema areas
+     * - Integration operations don't map to specific database entities
+     * - System-level functionality requires dedicated API operations
+     *
+     * **Naming Standards:**
+     *
+     * - Use PascalCase format (e.g., "Shopping", "BBS", "UserManagement")
+     * - Names MUST 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
+     * - Each database entity belongs to exactly one group
+     * - Clear mapping to specific Prisma schema elements
+     * - Balance group sizes within schema constraints
+     * - Follow existing schema namespace or file structure patterns
+     */
+    interface IGroup {
+        /**
+         * Unique identifier name derived from Prisma schema structure.
+         *
+         * Must correspond to schema namespaces, file names, table prefixes, or
+         * organizational annotations rather than arbitrary business domain names.
+         */
+        name: string & tags.MinLength<1>;
+        /**
+         * Comprehensive description of the group's scope, schema foundation, and
+         * purpose.
+         *
+         * **Required Content:**
+         *
+         * 1. Schema Foundation: Identify the Prisma schema elements defining this
+         *    group
+         * 2. Database Entities: List specific tables and entities from the schema
+         * 3. Functional Scope: Detail operations and workflows for schema entities
+         * 4. Schema Relationships: Describe table relationships and dependencies
+         * 5. Key Operations: Outline main operation types (CRUD, business processes)
+         * 6. Requirements Mapping: Explain how requirements map to schema entities
+         */
+        description: string & tags.MinLength<1>;
+    }
+}

package/lib/agent/src/orchestrate/interface/structures/IAutoBeInterfaceGroupApplication.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"IAutoBeInterfaceGroupApplication.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/interface/structures/IAutoBeInterfaceGroupApplication.ts"],"names":[],"mappings":""}

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

@@ -0,0 +1,126 @@
+import { AutoBeOpenApi, CamelPattern } from "@autobe/interface";
+import { tags } from "typia";
+export interface IAutoBeInterfaceOperationApplication {
+    /**
+     * Generate detailed API operations from path/method combinations.
+     *
+     * This function creates complete API operations following REST principles and
+     * quality standards. Each generated operation includes specification, path,
+     * method, detailed multi-paragraph description, concise summary, parameters,
+     * and appropriate request/response bodies.
+     *
+     * The function processes as many operations as possible in a single call,
+     * with progress tracking to ensure iterative completion of all required
+     * endpoints.
+     *
+     * @param props Properties containing the operations to generate.
+     */
+    makeOperations(props: IAutoBeInterfaceOperationApplication.IProps): void;
+}
+export declare namespace IAutoBeInterfaceOperationApplication {
+    interface IProps {
+        /**
+         * Array of API operations to generate.
+         *
+         * Each operation in this array must include:
+         *
+         * - Specification: Detailed API specification with clear purpose and
+         *   functionality
+         * - Path: Resource-centric URL path (e.g., "/resources/{resourceId}")
+         * - Method: HTTP method (get, post, put, delete, patch)
+         * - Description: Extremely detailed multi-paragraph description referencing
+         *   Prisma schema comments
+         * - Summary: Concise one-sentence summary of the endpoint
+         * - Parameters: Array of all necessary parameters with descriptions and
+         *   schema definitions
+         * - RequestBody: For POST/PUT/PATCH methods, with typeName referencing
+         *   components.schemas
+         * - ResponseBody: With typeName referencing appropriate response type
+         *
+         * All operations must follow strict quality standards:
+         *
+         * 1. Detailed descriptions referencing Prisma schema comments
+         * 2. Accurate parameter definitions matching path parameters
+         * 3. Appropriate request/response body type references
+         * 4. Consistent patterns for CRUD operations
+         *
+         * For list retrievals (typically PATCH), include pagination, search, and
+         * sorting. For detail retrieval (GET), return a single resource. For
+         * creation (POST), use .ICreate request body. For modification (PUT), use
+         * .IUpdate request body.
+         */
+        operations: 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, "authorizationRole"> {
+        /**
+         * Authorization roles required to access this API operation.
+         *
+         * This field specifies which user roles are allowed to access this
+         * endpoint. Multiple roles can be specified to allow different types of
+         * users to access the same endpoint.
+         *
+         * ## Naming Convention
+         *
+         * All role names MUST use camelCase.
+         *
+         * ## 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
+         *   database
+         * - This will be used by the Realize Agent to generate appropriate decorator
+         *   and authorization logic in the provider functions
+         * - The controller will apply the corresponding authentication decorator
+         *   based on these roles
+         *
+         * ## Examples
+         *
+         * - `[]` - Public endpoint, no authentication required
+         * - `["user"]` - Any authenticated user can access
+         * - `["admin"]` - Only admin users can access
+         * - `["admin", "moderator"]` - Both admin and moderator users can access
+         * - `["seller"]` - Only seller users can access
+         *
+         * Note: The actual authentication/authorization implementation will be
+         * handled by decorators at the controller level, and the provider function
+         * will receive the authenticated user object with the appropriate type.
+         */
+        authorizationRoles: Array<string & CamelPattern & tags.MinLength<1>>;
+    }
+}

package/lib/agent/src/orchestrate/interface/structures/IAutoBeInterfaceOperationApplication.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"IAutoBeInterfaceOperationApplication.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/interface/structures/IAutoBeInterfaceOperationApplication.ts"],"names":[],"mappings":""}

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

@@ -0,0 +1,96 @@
+import { AutoBeOpenApi } from "@autobe/interface";
+/**
+ * Application interface for reviewing and validating API operations.
+ *
+ * Provides functionality to systematically review generated API operations
+ * against business requirements, technical specifications, and OpenAPI
+ * standards. The review process ensures each operation meets quality criteria
+ * before proceeding to implementation.
+ */
+export interface IAutoBeInterfaceOperationsReviewApplication {
+    /**
+     * Reviews a batch of API operations for quality and correctness.
+     *
+     * Validates each operation's request/response schemas, authentication
+     * handling, error responses, and documentation completeness. Operations are
+     * marked as passed or failed based on compliance with enterprise standards.
+     *
+     * @param input Collection of operations to review with their validation
+     *   results
+     */
+    reviewOperations(input: IAutoBeInterfaceOperationsReviewApplication.IProps): void;
+}
+export declare namespace IAutoBeInterfaceOperationsReviewApplication {
+    /**
+     * Properties for API operation review and improvement process.
+     *
+     * Contains both the input operations to be reviewed and the outputs generated
+     * by the Interface Operations Review Agent, which will be published as part
+     * of the AutoBeInterfaceOperationsReviewEvent.
+     */
+    interface IProps {
+        /**
+         * Comprehensive review analysis with prioritized findings.
+         *
+         * Systematic assessment organized by severity levels (CRITICAL, HIGH,
+         * MEDIUM, LOW):
+         *
+         * - **Security Analysis**: Authentication boundary violations, exposed
+         *   passwords/tokens, unauthorized data access patterns, SQL injection
+         *   risks
+         * - **Logic Validation**: Return type consistency (list operations returning
+         *   arrays, single retrieval returning single items), HTTP method semantics
+         *   alignment, parameter usage verification
+         * - **Schema Compliance**: Field existence in Prisma schema, type accuracy,
+         *   relationship validity, required field handling
+         * - **Quality Assessment**: Documentation completeness, naming conventions,
+         *   error handling patterns, pagination standards
+         *
+         * Each finding includes specific examples, current vs expected behavior,
+         * and concrete fix recommendations. Critical security issues and logical
+         * contradictions are highlighted for immediate attention.
+         */
+        review: string;
+        /**
+         * Prioritized action plan for identified issues.
+         *
+         * Structured improvement strategy categorized by severity:
+         *
+         * - **Immediate Actions (CRITICAL)**: Security vulnerabilities that must be
+         *   fixed before production (password exposure, missing authorization,
+         *   authentication bypass risks)
+         * - **Required Fixes (HIGH)**: Functional issues affecting API correctness
+         *   (wrong return types, missing required fields, schema mismatches)
+         * - **Recommended Improvements (MEDIUM)**: Quality enhancements for better
+         *   API design (validation rules, format specifications, consistency)
+         * - **Optional Enhancements (LOW)**: Documentation and usability improvements
+         *
+         * If all operations pass review without issues, contains: "No improvements
+         * required. All operations meet AutoBE standards."
+         *
+         * Each action item includes the specific operation path, the exact change
+         * needed, and the rationale for the modification.
+         */
+        plan: string;
+        /**
+         * Production-ready operations with all critical issues resolved.
+         *
+         * Final API operations after systematic enhancement:
+         *
+         * - **Security Fixes Applied**: All authentication boundaries enforced,
+         *   sensitive data removed from responses, proper authorization
+         *   implemented
+         * - **Logic Corrections Made**: Return types match operation intent, HTTP
+         *   methods align with semantics, parameters properly utilized
+         * - **Schema Alignment Verified**: All fields exist in Prisma schema, types
+         *   correctly mapped, relationships properly defined
+         * - **Quality Improvements Added**: Enhanced documentation, format
+         *   specifications, validation rules, consistent naming patterns
+         *
+         * If no issues were found during review, this contains the exact original
+         * operations unchanged. These operations are validated and ready for schema
+         * generation and subsequent implementation phases.
+         */
+        content: AutoBeOpenApi.IOperation[];
+    }
+}

package/lib/agent/src/orchestrate/interface/structures/IAutoBeInterfaceOperationsReviewApplication.js

@@ -0,0 +1,3 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+//# sourceMappingURL=IAutoBeInterfaceOperationsReviewApplication.js.map

package/lib/agent/src/orchestrate/interface/structures/IAutoBeInterfaceOperationsReviewApplication.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"IAutoBeInterfaceOperationsReviewApplication.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/interface/structures/IAutoBeInterfaceOperationsReviewApplication.ts"],"names":[],"mappings":""}

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

@@ -0,0 +1,75 @@
+import { AutoBeOpenApi } from "@autobe/interface";
+export interface IAutoBeInterfaceSchemaApplication {
+    /**
+     * Generate OpenAPI components containing named schema types.
+     *
+     * This method receives a complete set of schema components and integrates
+     * them into the final OpenAPI specification. It processes all entity schemas,
+     * their variants, and related type definitions to ensure a comprehensive and
+     * consistent API design.
+     *
+     * The provided components should include schemas for all entities identified
+     * in the previous phases of API path/method definition and operation
+     * 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.
+     *
+     * @param props Properties containing components to generate.
+     */
+    makeComponents(props: IAutoBeInterfaceSchemaApplication.IProps): void;
+}
+export declare namespace IAutoBeInterfaceSchemaApplication {
+    interface IProps {
+        /**
+         * Complete set of schema components for the OpenAPI specification.
+         *
+         * This property contains comprehensive type definitions for all entities in
+         * 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.
+         *
+         * This components object should include:
+         *
+         * - 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.
+         *
+         * Example structure:
+         *
+         * ```typescript
+         * {
+         *   schemas: {
+         *     IUser: {
+         *       type: "object",
+         *       properties: {
+         *         id: { type: "string", format: "uuid" },
+         *         email: { type: "string", format: "email" },
+         *         profile: { "$ref": "#/components/schemas/IUserProfile" }
+         *       },
+         *       required: ["id", "email"],
+         *       description: "User entity representing system account holders..."
+         *     },
+         *     "IUser.ICreate": { ... },
+         *     // Additional schemas
+         *   }
+         * }
+         * ```
+         */
+        schemas: Record<string, AutoBeOpenApi.IJsonSchemaDescriptive>;
+    }
+}

package/lib/agent/src/orchestrate/interface/structures/IAutoBeInterfaceSchemaApplication.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"IAutoBeInterfaceSchemaApplication.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/interface/structures/IAutoBeInterfaceSchemaApplication.ts"],"names":[],"mappings":""}

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

@@ -0,0 +1,91 @@
+import { AutoBeOpenApi } from "@autobe/interface";
+export interface IAutoBeInterfaceSchemasReviewApplication {
+    /**
+     * Analyzes and improves OpenAPI schema definitions.
+     *
+     * This function receives schema definitions and performs comprehensive review
+     * and enhancement. It identifies issues, creates an improvement plan, and
+     * produces refined schemas that meet quality standards.
+     *
+     * The function populates three key outputs:
+     *
+     * - A detailed review of findings organized by severity
+     * - An actionable plan for improvements
+     * - Enhanced schemas with all issues resolved
+     *
+     * @param props Contains review findings, improvement plan, and enhanced
+     *   schemas
+     */
+    review: (props: IAutoBeInterfaceSchemasReviewApplication.IProps) => void;
+}
+export declare namespace IAutoBeInterfaceSchemasReviewApplication {
+    /**
+     * Schema review and enhancement parameters for the review function.
+     *
+     * When the review function is called, these properties must be populated to
+     * complete the schema validation and improvement process. The LLM uses this
+     * interface to understand what outputs are required.
+     */
+    interface IProps {
+        /**
+         * 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
+         *
+         * 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
+         *
+         * 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."
+         */
+        review: string;
+        /**
+         * Action plan for addressing identified issues.
+         *
+         * Must specify concrete fixes categorized by priority:
+         *
+         * - For perfect schemas: "No improvements required. All schemas meet AutoBE
+         *   standards."
+         * - For fixable issues: List each fix with operation path and exact change
+         * - For critical problems: Describe how schemas were recreated or corrected
+         *
+         * Never leave this empty. Always provide a clear plan even if no changes
+         * are needed. The plan documents what was done to produce the content
+         * field.
+         */
+        plan: string;
+        /**
+         * 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:
+         *
+         * - Empty object {} will cause all schemas to be deleted
+         * - Returning undefined or null
+         * - Including explanations or excuses in schema descriptions
+         * - Leaving 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
+         * the system, so it must always contain complete, valid schemas.
+         */
+        content: Record<string, AutoBeOpenApi.IJsonSchemaDescriptive<AutoBeOpenApi.IJsonSchema>>;
+    }
+}

package/lib/agent/src/orchestrate/interface/structures/IAutobeInterfaceSchemasReviewApplication.js

@@ -0,0 +1,3 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+//# sourceMappingURL=IAutobeInterfaceSchemasReviewApplication.js.map

package/lib/agent/src/orchestrate/interface/structures/IAutobeInterfaceSchemasReviewApplication.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"IAutobeInterfaceSchemasReviewApplication.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/interface/structures/IAutobeInterfaceSchemasReviewApplication.ts"],"names":[],"mappings":""}

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

@@ -0,0 +1,6 @@
+import { AutoBeOpenApi } from "@autobe/interface";
+export declare namespace OpenApiEndpointComparator {
+    function hashCode(e: AutoBeOpenApi.IEndpoint): number;
+    function equals(x: AutoBeOpenApi.IEndpoint, y: AutoBeOpenApi.IEndpoint): boolean;
+    function compare(x: AutoBeOpenApi.IEndpoint, y: AutoBeOpenApi.IEndpoint): number;
+}

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

@@ -0,0 +1 @@
+{"version":3,"file":"OpenApiEndpointComparator.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/interface/utils/OpenApiEndpointComparator.ts"],"names":[],"mappings":";;;AACA,+BAA4B;AAE5B,IAAiB,yBAAyB,CAmBzC;AAnBD,WAAiB,yBAAyB;IACxC,SAAgB,QAAQ,CAAC,CAA0B;QACjD,OAAO,IAAA,WAAI,EAAC,CAAC,CAAC,IAAI,EAAE,CAAC,CAAC,MAAM,CAAC,CAAC;IAChC,CAAC;IAFe,kCAAQ,WAEvB,CAAA;IAED,SAAgB,MAAM,CACpB,CAA0B,EAC1B,CAA0B;QAE1B,OAAO,CAAC,CAAC,IAAI,KAAK,CAAC,CAAC,IAAI,IAAI,CAAC,CAAC,MAAM,KAAK,CAAC,CAAC,MAAM,CAAC;IACpD,CAAC;IALe,gCAAM,SAKrB,CAAA;IAED,SAAgB,OAAO,CACrB,CAA0B,EAC1B,CAA0B;QAE1B,IAAI,CAAC,CAAC,IAAI,KAAK,CAAC,CAAC,IAAI;YAAE,OAAO,CAAC,CAAC,IAAI,CAAC,aAAa,CAAC,CAAC,CAAC,IAAI,CAAC,CAAC;QAC3D,OAAO,CAAC,CAAC,MAAM,CAAC,aAAa,CAAC,CAAC,CAAC,MAAM,CAAC,CAAC;IAC1C,CAAC;IANe,iCAAO,UAMtB,CAAA;AACH,CAAC,EAnBgB,yBAAyB,yCAAzB,yBAAyB,QAmBzC"}

package/lib/agent/src/orchestrate/internal/IProgress.d.ts

@@ -0,0 +1,4 @@
+export interface IProgress {
+    total: number;
+    completed: number;
+}

package/lib/agent/src/orchestrate/internal/IProgress.js

@@ -0,0 +1,3 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+//# sourceMappingURL=IProgress.js.map

package/lib/agent/src/orchestrate/internal/IProgress.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"IProgress.js","sourceRoot":"","sources":["../../../../../src/orchestrate/internal/IProgress.ts"],"names":[],"mappings":""}

package/lib/{orchestrate/prisma → agent/src/orchestrate/prisma/histories}/transformPrismaComponentsHistories.d.ts

@@ -1,3 +1,3 @@
 import { IAgenticaHistoryJson } from "@agentica/core";
-import { AutoBeState } from "../../context/AutoBeState";
+import { AutoBeState } from "../../../context/AutoBeState";
 export declare const transformPrismaComponentsHistories: (state: AutoBeState, prefix?: string | null) => Array<IAgenticaHistoryJson.IAssistantMessage | IAgenticaHistoryJson.ISystemMessage>;

package/lib/{orchestrate/prisma → agent/src/orchestrate/prisma/histories}/transformPrismaComponentsHistories.js

@@ -21,7 +21,7 @@ const transformPrismaComponentsHistories = (state, prefix = null) => {
             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 `IExtractComponentsProps` interface:\n\n```typescript\ninterface IExtractComponentsProps {\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  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\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: IExtractComponentsProps = {\n  components: [\n    {\n      filename: \"schema-01-systematic.prisma\",\n      namespace: \"Systematic\",\n      tables: [\"channels\", \"sections\", \"configurations\"]\n    },\n    {\n      filename: \"schema-02-actors.prisma\", \n      namespace: \"Actors\",\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\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\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)(),

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

@@ -0,0 +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"}