@autobe/agent 0.17.1 → 0.19.1

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

@@ -0,0 +1,24 @@
+import { AutoBeOpenApi } from "@autobe/interface";
+import { tags } from "typia";
+export interface IAutoBeInterfaceEndpointApplication {
+    /**
+     * Create Restful API endpoints.
+     *
+     * Create Restful API endpoints referencing the given documents; requirement
+     * analysis documents, and Prisma schema files with ERD descriptions. The API
+     * endpoints must cover every requirements and every entities in the ERD.
+     *
+     * Also, each combination of {@link AutoBeOpenApi.IEndpoint.path} and
+     * {@link AutoBeOpenApi.IEndpoint.method} must be unique to avoid duplicates.
+     * Please don't make any duplicates.
+     *
+     * @param props Properties containing the endpoints
+     */
+    makeEndpoints(props: IAutoBeInterfaceEndpointApplication.IProps): void;
+}
+export declare namespace IAutoBeInterfaceEndpointApplication {
+    interface IProps {
+        /** The endpoints to generate. */
+        endpoints: AutoBeOpenApi.IEndpoint[] & tags.MinItems<1>;
+    }
+}

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

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

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.
+     *
+     * 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
+     */
+    makeGroups(props: IAutoBeInterfaceGroupApplication.IProps): void;
+}
+export declare namespace IAutoBeInterfaceGroupApplication {
+    interface IProps {
+        /**
+         * Array of API endpoint groups for organizing development.
+         *
+         * DO: Organize groups around existing Prisma schema structure.
+         * DO: 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:**
+     *
+     * 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):**
+     *
+     * 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 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 are 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 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 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.
+         *
+         * DO: 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,171 @@
+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 includes:
+         *
+         * - 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 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.
+     *
+     * 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:
+     *
+     * ```json
+     * {
+     *   "/shoppings/customers/orders": {
+     *     "post": {
+     *       "description": "Create a new order application from shopping cart...",
+     *       "parameters": [...],
+     *       "requestBody": {...},
+     *       "responses": {...}
+     *     }
+     *   }
+     * }
+     * ```
+     */
+    interface IOperation extends Omit<AutoBeOpenApi.IOperation, "authorizationRole" | "authorizationType"> {
+        /**
+         * 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.
+         *
+         * ## ⚠️ 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
+         *
+         * 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
+         * - **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
+         * - The controller will apply the corresponding authentication decorator
+         *   based on these roles
+         *
+         * ## Examples
+         *
+         * - `[]` - 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
+         *   (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
+         * 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,132 @@
+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: 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/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,107 @@
+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.
+     *
+     * 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.
+     */
+    makeComponents(props: IAutoBeInterfaceSchemaApplication.IProps): void;
+}
+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.
+         *
+         * 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.
+         *
+         * DO: Define all object types as named types in the components.schemas
+         * section. DO NOT: Use inline anonymous object definitions.
+         *
+         * This components object includes:
+         *
+         * - Main entity types (IEntityName)
+         * - Operation-specific variants (.ICreate, .IUpdate, .ISummary, etc.)
+         * - Container types (IPage<T> for pagination)
+         * - Enumeration types
+         *
+         * 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:
+         *
+         * ```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,85 @@
+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.
+         *
+         * DO: Document only problems that need fixing.
+         * DO NOT: Include positive feedback, compliments, or confirmations
+         *
+         * Focus exclusively on issues organized by severity:
+         *
+         * 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."
+         */
+        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.
+         *
+         * 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
+         *
+         * 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
+         * 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;
+}