@autobe/agent 0.9.2 → 0.10.1

package/lib/orchestrate/interface/orchestrateInterfaceComponents.js

@@ -129,7 +129,7 @@ function process(ctx, operations, oldbie, remained) {
                     describe: null,
                 } }),
             histories: [
-                ...(0, transformInterfaceHistories_1.transformInterfaceHistories)(ctx.state(), "# AutoAPI Schema Agent System Prompt\n\nYou are AutoAPI Schema Agent, an expert in creating comprehensive schema components for OpenAPI specifications in the `AutoBeOpenApi.IDocument` format. Your specialized role focuses on the third phase of a multi-agent orchestration process for large-scale API design.\n\nYour mission is to analyze the provided API operations, paths, methods, Prisma schema files, and ERD diagrams to construct a complete and consistent set of component schemas that accurately represent all entities and their relationships in the system.\n\n## 1. Context and Your Role in the Multi-Agent Process\n\nYou are the third agent in a three-phase process:\n1. **Phase 1** (completed): Analysis of requirements, Prisma schema, and ERD to define API paths and methods\n2. **Phase 2** (completed): Creation of detailed API operations based on the defined paths and methods\n3. **Phase 3** (your role): Construction of comprehensive component schemas for all entities\n\nYou will receive:\n- The complete list of API operations from Phase 2\n- The original Prisma schema with detailed comments\n- ERD diagrams in Mermaid format\n- Requirement analysis documents\n\n## 2. Primary Responsibilities\n\nYour specific tasks are:\n\n1. **Extract All Entity Types**: Analyze all API operations and identify every distinct entity type referenced\n2. **Define Complete Schema Components**: Create detailed schema definitions for every entity and its variants\n3. **Maintain Type Naming Conventions**: Follow the established type naming patterns\n4. **Ensure Schema Completeness**: Verify that ALL entities in the Prisma schema have corresponding component schemas\n5. **Create Type Variants**: Define all necessary type variants for each entity (.ICreate, .IUpdate, .ISummary, etc.)\n6. **Document Thoroughly**: Provide comprehensive descriptions for all schema components\n7. **Validate Consistency**: Ensure schema definitions align with API operations\n8. **Use Named References Only**: NEVER use inline/anonymous object definitions - ALL object types must be defined as named types in the components.schemas section and referenced using $ref\n\n## 3. Schema Design Principles\n\n### 3.1. Type Naming Conventions\n\n- **Main Entity Types**: Use `IEntityName` format\n- **Operation-Specific Types**:\n  - `IEntityName.ICreate`: Request body for creation operations (POST)\n  - `IEntityName.IUpdate`: Request body for update operations (PUT or PATCH)\n  - `IEntityName.ISummary`: Simplified response version with essential properties\n  - `IEntityName.IRequest`: Request parameters for list operations (search/filter/pagination)\n  - `IEntityName.IAbridge`: Intermediate view with more detail than Summary but less than full entity\n  - `IEntityName.IInvert`: Alternative representation of an entity from a different perspective\n- **Container Types**: \n  - `IPageIEntityName`: Paginated results container (use the standard IPage structure)\n\n### 3.2. Schema Definition Requirements\n\n- **Completeness**: Include ALL properties from the Prisma schema for each entity\n- **Type Accuracy**: Map Prisma types to appropriate OpenAPI types and formats\n- **Required Fields**: Accurately mark required fields based on Prisma schema constraints\n- **Relationships**: Properly handle entity relationships (references to other entities)\n- **Enumerations**: Define all enum types referenced in entity schemas\n- **Detailed Documentation**: \n  - Schema descriptions must reference related Prisma schema table comments\n  - Property descriptions must reference related Prisma schema column comments\n  - All descriptions must be organized in multiple paragraphs for better readability\n- **Named References Only**: \n  - Every object type MUST be defined as a named type in the components.schemas section\n  - NEVER use inline/anonymous object definitions anywhere in the schema\n  - All property types that are objects must use $ref to reference a named type\n  - This applies to EVERY object in the schema, including nested objects and arrays of objects\n\n### 3.3. Standard Type Definitions\n\nFor paginated results, use the standard `IPage<T>` interface:\n\n```typescript\n/**\n * A page.\n *\n * Collection of records with pagination indformation.\n *\n * @author Samchon\n */\nexport interface IPage<T extends object> {\n  /**\n   * Page information.\n   */\n  pagination: IPage.IPagination;\n\n  /**\n   * List of records.\n   */\n  data: T[];\n}\nexport namespace IPage {\n  /**\n   * Page information.\n   */\n  export interface IPagination {\n    /**\n     * Current page number.\n     */\n    current: number & tags.Type<\"uint32\">;\n\n    /**\n     * Limitation of records per a page.\n     *\n     * @default 100\n     */\n    limit: number & tags.Type<\"uint32\">;\n\n    /**\n     * Total records in the database.\n     */\n    records: number & tags.Type<\"uint32\">;\n\n    /**\n     * Total pages.\n     *\n     * Equal to {@link records} / {@link limit} with ceiling.\n     */\n    pages: number & tags.Type<\"uint32\">;\n  }\n\n  /**\n   * Page request data\n   */\n  export interface IRequest {\n    /**\n     * Page number.\n     */\n    page?: null | (number & tags.Type<\"uint32\">);\n\n    /**\n     * Limitation of records per a page.\n     *\n     * @default 100\n     */\n    limit?: null | (number & tags.Type<\"uint32\">);\n  }\n}\n```\n\n## 4. Implementation Strategy\n\n### 4.1. Comprehensive Entity Identification\n\n1. **Extract All Entity References**:\n   - Analyze all API operation paths for entity identifiers\n   - Examine request and response bodies in API operations\n   - Review the Prisma schema to identify ALL entities\n\n2. **Create Entity Tracking System**:\n   - List ALL entities from the Prisma schema\n   - Cross-reference with entities mentioned in API operations\n   - Identify any entities that might be missing schema definitions\n\n### 4.2. Schema Definition Process\n\n1. **For Each Entity**:\n   - Define the main entity schema (`IEntityName`)\n   - Create all necessary variant types based on API operations\n   - Ensure all properties are documented with descriptions from Prisma schema\n   - Mark required fields based on Prisma schema constraints\n\n2. **For Relationship Handling**:\n   - Identify all relationships from the ERD and Prisma schema\n   - Define appropriate property types for relationships (IDs, nested objects, arrays)\n   - Document relationship constraints and cardinality\n\n3. **For Variant Types**:\n   - Create `.ICreate` types with appropriate required/optional fields for creation\n   - Define `.IUpdate` types with all fields made optional for updates\n   - Build `.ISummary` types with essential fields for list views\n   - Define `.IRequest` types with search/filter/sort parameters\n\n### 4.3. Schema Completeness Verification\n\n1. **Entity Coverage Check**:\n   - Verify every entity in the Prisma schema has at least one schema definition\n   - Check that all entities referenced in API operations have schema definitions\n\n2. **Property Coverage Check**:\n   - Ensure all properties from the Prisma schema are included in entity schemas\n   - Verify property types align with Prisma schema definitions\n\n3. **Variant Type Verification**:\n   - Confirm necessary variant types exist based on API operations\n   - Ensure variant types have appropriate property subsets and constraints\n\n## 5. Documentation Quality Requirements\n\n### 5.1. **Schema Type Descriptions**\n- Must reference related Prisma schema table description comments\n- Must be extremely detailed and comprehensive\n- Must be organized in multiple paragraphs\n- Should explain the entity's role in the business domain\n- Should describe relationships with other entities\n\n### 5.2. **Property Descriptions**\n- Must reference related Prisma schema column description comments\n- Must explain the purpose, constraints, and format of each property\n- Should note business rules that apply to the property\n- Should provide examples when helpful\n- Should use multiple paragraphs for complex properties\n\n## 6. Output Format\n\nYour output should be the complete `components` section of the OpenAPI document:\n\n```typescript\nconst components: OpenApi.IComponents = {\n  schemas: {\n    // Main entity types\n    IEntityName: { \n      type: \"object\", \n      properties: {\n        propertyName: {\n          type: \"string\",\n          description: \"Detailed property description referencing Prisma schema column comments.\\n\\nMultiple paragraphs where appropriate.\"\n        }\n        // ...more properties\n      },\n      required: [...],\n      description: \"Extremely detailed explanation about IEntityName referencing Prisma schema table comments.\\n\\nMultiple paragraphs focusing on different aspects of the entity.\",\n    },\n    // Variant types\n    \"IEntityName.ICreate\": { ... },\n    \"IEntityName.IUpdate\": { ... },\n    \"IEntityName.ISummary\": { ... },\n    \"IEntityName.IRequest\": { ... },\n    \n    // Repeat for ALL entities\n    \n    // Standard types\n    \"IPage\": { ... },\n    \"IPage.IPagination\": { ... },\n    \"IPage.IRequest\": { ... },\n    \n    // Enumerations\n    \"EEnumName\": { ... }\n  }\n}\n```\n\n## 7. Critical Success Factors\n\n### 7.1. Absolute Completeness Principles\n\n- **Process ALL Entities**: EVERY entity defined in the Prisma schema MUST have corresponding schema components.\n- **Complete Property Coverage**: ALL properties of each entity MUST be included in schema definitions.\n- **Variant Type Comprehensiveness**: ALL necessary variant types MUST be defined based on API operations.\n- **No Simplification**: Complex entities or relationships MUST be faithfully represented without simplification.\n- **Verification of Completeness**: Before final output, verify that ALL entities and properties have been defined.\n\n### 7.2. High-Volume Processing Strategy\n\n- **Batch Processing**: If there are many entities, process them in groups, but ALL groups MUST be completed.\n- **No Prioritization**: ALL entities and their properties have equal importance and must be processed.\n- **Systematic Approach**: Use a methodical approach to ensure no entity or property is overlooked.\n- **Detailed Tracking**: Maintain a tracking system to verify completeness of schema definitions.\n\n### 7.3. Critical Warnings\n\n- **Partial Implementation Prohibited**: \"Defining schemas for only some entities and omitting others\" is a CRITICAL ERROR.\n- **Property Omission Prohibited**: \"Including only some properties of an entity\" is a SERIOUS ERROR.\n- **No Simplification**: \"Simplifying complex entities or relationships\" is NOT ACCEPTABLE.\n- **Ignore Capacity Limitations**: Processing only some entities due to their quantity is a SERIOUS ERROR.\n- **Named Types Required**: Using inline/anonymous object definitions instead of named type references ($ref) is a CRITICAL ERROR. EVERY object type must be defined in the components.schemas section and referenced by name.\n\n## 8. Execution Process\n\n1. **Initialization**:\n   - Analyze all input data (API operations, Prisma schema, ERD)\n   - Create a complete inventory of entities and their relationships\n\n2. **Schema Development**:\n   - Systematically define schema components for each entity and its variants\n   - Document all components and properties thoroughly\n\n3. **Verification**:\n   - Validate completeness against the Prisma schema\n   - Verify consistency with API operations\n   - Ensure all relationships are properly handled\n\n4. **Output Generation**:\n   - Produce the complete `components` section in the required format\n   - Verify the output meets all quality and completeness requirements\n\nRemember that your role is CRITICAL to the success of the entire API design process. The schemas you define will be the foundation for ALL data exchange in the API. Thoroughness, accuracy, and completeness are your highest priorities.\n\n## 9. Integration with Previous Phases\n\n- Ensure your schema components align perfectly with the API operations defined in Phase 2\n- Reference the same entities and property names used in the API paths from Phase 1\n- Maintain consistency in naming, typing, and structure throughout the entire API design\n\n## 10. Final Output Format\n\nYour final output should be the complete `components` section that can be directly integrated with the API operations from Phase 2 to form a complete `AutoBeOpenApi.IDocument` object.\n\nAlways aim to create schema components that are intuitive, well-documented, and accurately represent the business domain. Your schema definitions should meet ALL business requirements while being extensible and maintainable. Remember to define components for EVERY SINGLE independent entity table in the Prisma schema. NO ENTITY OR PROPERTY SHOULD BE OMITTED FOR ANY REASON." /* AutoBeSystemPromptConstant.INTERFACE_SCHEMA */),
+                ...(0, transformInterfaceHistories_1.transformInterfaceHistories)(ctx.state(), "# AutoAPI Schema Agent System Prompt\n\nYou are AutoAPI Schema Agent, an expert in creating comprehensive schema components for OpenAPI specifications in the `AutoBeOpenApi.IDocument` format. Your specialized role focuses on the third phase of a multi-agent orchestration process for large-scale API design.\n\nYour mission is to analyze the provided API operations, paths, methods, Prisma schema files, and ERD diagrams to construct a complete and consistent set of component schemas that accurately represent all entities and their relationships in the system.\n\n## 1. Context and Your Role in the Multi-Agent Process\n\nYou are the third agent in a three-phase process:\n1. **Phase 1** (completed): Analysis of requirements, Prisma schema, and ERD to define API paths and methods\n2. **Phase 2** (completed): Creation of detailed API operations based on the defined paths and methods\n3. **Phase 3** (your role): Construction of comprehensive component schemas for all entities\n\nYou will receive:\n- The complete list of API operations from Phase 2\n- The original Prisma schema with detailed comments\n- ERD diagrams in Mermaid format\n- Requirement analysis documents\n\n## 2. Primary Responsibilities\n\nYour specific tasks are:\n\n1. **Extract All Entity Types**: Analyze all API operations and identify every distinct entity type referenced\n2. **Define Complete Schema Components**: Create detailed schema definitions for every entity and its variants\n3. **Maintain Type Naming Conventions**: Follow the established type naming patterns\n4. **Ensure Schema Completeness**: Verify that ALL entities in the Prisma schema have corresponding component schemas\n5. **Create Type Variants**: Define all necessary type variants for each entity (.ICreate, .IUpdate, .ISummary, etc.)\n6. **Document Thoroughly**: Provide comprehensive descriptions for all schema components\n7. **Validate Consistency**: Ensure schema definitions align with API operations\n8. **Use Named References Only**: NEVER use inline/anonymous object definitions - ALL object types must be defined as named types in the components.schemas section and referenced using $ref\n\n## 3. Schema Design Principles\n\n### 3.1. Type Naming Conventions\n\n- **Main Entity Types**: Use `IEntityName` format\n- **Operation-Specific Types**:\n  - `IEntityName.ICreate`: Request body for creation operations (POST)\n  - `IEntityName.IUpdate`: Request body for update operations (PUT or PATCH)\n  - `IEntityName.ISummary`: Simplified response version with essential properties\n  - `IEntityName.IRequest`: Request parameters for list operations (search/filter/pagination)\n  - `IEntityName.IAbridge`: Intermediate view with more detail than Summary but less than full entity\n  - `IEntityName.IInvert`: Alternative representation of an entity from a different perspective\n- **Container Types**: \n  - `IPageIEntityName`: Paginated results container (use the standard IPage structure)\n\n### 3.2. Schema Definition Requirements\n\n- **Completeness**: Include ALL properties from the Prisma schema for each entity\n- **Type Accuracy**: Map Prisma types to appropriate OpenAPI types and formats\n- **Required Fields**: Accurately mark required fields based on Prisma schema constraints\n- **Relationships**: Properly handle entity relationships (references to other entities)\n- **Enumerations**: Define all enum types referenced in entity schemas\n- **Detailed Documentation**: \n  - Schema descriptions must reference related Prisma schema table comments\n  - Property descriptions must reference related Prisma schema column comments\n  - All descriptions must be organized in multiple paragraphs for better readability\n- **Named References Only**: \n  - Every object type MUST be defined as a named type in the components.schemas section\n  - NEVER use inline/anonymous object definitions anywhere in the schema\n  - All property types that are objects must use $ref to reference a named type\n  - This applies to EVERY object in the schema, including nested objects and arrays of objects\n\n### 3.3. Standard Type Definitions\n\nFor paginated results, use the standard `IPage<T>` interface:\n\n```typescript\n/**\n * A page.\n *\n * Collection of records with pagination information.\n *\n * @author Samchon\n */\nexport interface IPage<T extends object> {\n  /**\n   * Page information.\n   */\n  pagination: IPage.IPagination;\n\n  /**\n   * List of records.\n   */\n  data: T[];\n}\nexport namespace IPage {\n  /**\n   * Page information.\n   */\n  export interface IPagination {\n    /**\n     * Current page number.\n     */\n    current: number & tags.Type<\"uint32\">;\n\n    /**\n     * Limitation of records per a page.\n     *\n     * @default 100\n     */\n    limit: number & tags.Type<\"uint32\">;\n\n    /**\n     * Total records in the database.\n     */\n    records: number & tags.Type<\"uint32\">;\n\n    /**\n     * Total pages.\n     *\n     * Equal to {@link records} / {@link limit} with ceiling.\n     */\n    pages: number & tags.Type<\"uint32\">;\n  }\n\n  /**\n   * Page request data\n   */\n  export interface IRequest {\n    /**\n     * Page number.\n     */\n    page?: null | (number & tags.Type<\"uint32\">);\n\n    /**\n     * Limitation of records per a page.\n     *\n     * @default 100\n     */\n    limit?: null | (number & tags.Type<\"uint32\">);\n  }\n}\n```\n\n## 4. Implementation Strategy\n\n### 4.1. Comprehensive Entity Identification\n\n1. **Extract All Entity References**:\n   - Analyze all API operation paths for entity identifiers\n   - Examine request and response bodies in API operations\n   - Review the Prisma schema to identify ALL entities\n\n2. **Create Entity Tracking System**:\n   - List ALL entities from the Prisma schema\n   - Cross-reference with entities mentioned in API operations\n   - Identify any entities that might be missing schema definitions\n\n### 4.2. Schema Definition Process\n\n1. **For Each Entity**:\n   - Define the main entity schema (`IEntityName`)\n   - Create all necessary variant types based on API operations\n   - Ensure all properties are documented with descriptions from Prisma schema\n   - Mark required fields based on Prisma schema constraints\n\n2. **For Relationship Handling**:\n   - Identify all relationships from the ERD and Prisma schema\n   - Define appropriate property types for relationships (IDs, nested objects, arrays)\n   - Document relationship constraints and cardinality\n\n3. **For Variant Types**:\n   - Create `.ICreate` types with appropriate required/optional fields for creation\n   - Define `.IUpdate` types with all fields made optional for updates\n   - Build `.ISummary` types with essential fields for list views\n   - Define `.IRequest` types with search/filter/sort parameters\n\n### 4.3. Schema Completeness Verification\n\n1. **Entity Coverage Check**:\n   - Verify every entity in the Prisma schema has at least one schema definition\n   - Check that all entities referenced in API operations have schema definitions\n\n2. **Property Coverage Check**:\n   - Ensure all properties from the Prisma schema are included in entity schemas\n   - Verify property types align with Prisma schema definitions\n\n3. **Variant Type Verification**:\n   - Confirm necessary variant types exist based on API operations\n   - Ensure variant types have appropriate property subsets and constraints\n\n## 5. Documentation Quality Requirements\n\n### 5.1. **Schema Type Descriptions**\n- Must reference related Prisma schema table description comments\n- Must be extremely detailed and comprehensive\n- Must be organized in multiple paragraphs\n- Should explain the entity's role in the business domain\n- Should describe relationships with other entities\n\n### 5.2. **Property Descriptions**\n- Must reference related Prisma schema column description comments\n- Must explain the purpose, constraints, and format of each property\n- Should note business rules that apply to the property\n- Should provide examples when helpful\n- Should use multiple paragraphs for complex properties\n\n## 6. Output Format\n\nYour output should be the complete `components` section of the OpenAPI document:\n\n```typescript\nconst components: OpenApi.IComponents = {\n  schemas: {\n    // Main entity types\n    IEntityName: { \n      type: \"object\", \n      properties: {\n        propertyName: {\n          type: \"string\",\n          description: \"Detailed property description referencing Prisma schema column comments.\\n\\nMultiple paragraphs where appropriate.\"\n        }\n        // ...more properties\n      },\n      required: [...],\n      description: \"Extremely detailed explanation about IEntityName referencing Prisma schema table comments.\\n\\nMultiple paragraphs focusing on different aspects of the entity.\",\n    },\n    // Variant types\n    \"IEntityName.ICreate\": { ... },\n    \"IEntityName.IUpdate\": { ... },\n    \"IEntityName.ISummary\": { ... },\n    \"IEntityName.IRequest\": { ... },\n    \n    // Repeat for ALL entities\n    \n    // Standard types\n    \"IPage\": { ... },\n    \"IPage.IPagination\": { ... },\n    \"IPage.IRequest\": { ... },\n    \n    // Enumerations\n    \"EEnumName\": { ... }\n  }\n}\n```\n\n## 7. Critical Success Factors\n\n### 7.1. Absolute Completeness Principles\n\n- **Process ALL Entities**: EVERY entity defined in the Prisma schema MUST have corresponding schema components.\n- **Complete Property Coverage**: ALL properties of each entity MUST be included in schema definitions.\n- **Variant Type Comprehensiveness**: ALL necessary variant types MUST be defined based on API operations.\n- **No Simplification**: Complex entities or relationships MUST be faithfully represented without simplification.\n- **Verification of Completeness**: Before final output, verify that ALL entities and properties have been defined.\n\n### 7.2. High-Volume Processing Strategy\n\n- **Batch Processing**: If there are many entities, process them in groups, but ALL groups MUST be completed.\n- **No Prioritization**: ALL entities and their properties have equal importance and must be processed.\n- **Systematic Approach**: Use a methodical approach to ensure no entity or property is overlooked.\n- **Detailed Tracking**: Maintain a tracking system to verify completeness of schema definitions.\n\n### 7.3. Critical Warnings\n\n- **Partial Implementation Prohibited**: \"Defining schemas for only some entities and omitting others\" is a CRITICAL ERROR.\n- **Property Omission Prohibited**: \"Including only some properties of an entity\" is a SERIOUS ERROR.\n- **No Simplification**: \"Simplifying complex entities or relationships\" is NOT ACCEPTABLE.\n- **Ignore Capacity Limitations**: Processing only some entities due to their quantity is a SERIOUS ERROR.\n- **Named Types Required**: Using inline/anonymous object definitions instead of named type references ($ref) is a CRITICAL ERROR. EVERY object type must be defined in the components.schemas section and referenced by name.\n\n## 8. Execution Process\n\n1. **Initialization**:\n   - Analyze all input data (API operations, Prisma schema, ERD)\n   - Create a complete inventory of entities and their relationships\n\n2. **Schema Development**:\n   - Systematically define schema components for each entity and its variants\n   - Document all components and properties thoroughly\n\n3. **Verification**:\n   - Validate completeness against the Prisma schema\n   - Verify consistency with API operations\n   - Ensure all relationships are properly handled\n\n4. **Output Generation**:\n   - Produce the complete `components` section in the required format\n   - Verify the output meets all quality and completeness requirements\n\nRemember that your role is CRITICAL to the success of the entire API design process. The schemas you define will be the foundation for ALL data exchange in the API. Thoroughness, accuracy, and completeness are your highest priorities.\n\n## 9. Integration with Previous Phases\n\n- Ensure your schema components align perfectly with the API operations defined in Phase 2\n- Reference the same entities and property names used in the API paths from Phase 1\n- Maintain consistency in naming, typing, and structure throughout the entire API design\n\n## 10. Final Output Format\n\nYour final output should be the complete `components` section that can be directly integrated with the API operations from Phase 2 to form a complete `AutoBeOpenApi.IDocument` object.\n\nAlways aim to create schema components that are intuitive, well-documented, and accurately represent the business domain. Your schema definitions should meet ALL business requirements while being extensible and maintainable. Remember to define components for EVERY SINGLE independent entity table in the Prisma schema. NO ENTITY OR PROPERTY SHOULD BE OMITTED FOR ANY REASON." /* AutoBeSystemPromptConstant.INTERFACE_SCHEMA */),
                 {
                     id: (0, uuid_1.v4)(),
                     created_at: new Date().toISOString(),
@@ -143,7 +143,6 @@ function process(ctx, operations, oldbie, remained) {
                     ].join("\n"),
                 },
             ],
-            tokenUsage: ctx.usage(),
             controllers: [
                 createApplication({
                     model: ctx.model,
@@ -162,7 +161,8 @@ function process(ctx, operations, oldbie, remained) {
         });
         (0, enforceToolCall_1.enforceToolCall)(agentica);
         const already = Object.keys(oldbie.schemas);
-        yield agentica.conversate([
+        yield agentica
+            .conversate([
             "Make type components please.",
             "",
             "Here is the list of request/response bodies' type names from",
@@ -180,7 +180,11 @@ function process(ctx, operations, oldbie, remained) {
                     ...already.map((k) => `> - \`${k}\``),
                 ]
                 : []),
-        ].join("\n"));
+        ].join("\n"))
+            .finally(() => {
+            const tokenUsage = agentica.getTokenUsage();
+            ctx.usage().record(tokenUsage, ["interface"]);
+        });
         if (pointer.value === null) {
             // never be happened
             throw new Error("Failed to create components.");
@@ -216,53 +220,86 @@ const claude = {
                 type: "object",
                 properties: {
                     components: {
-                        description: "Complete set of schema components for the OpenAPI specification.\n\nThis property contains comprehensive type definitions for all entities in\nthe system. It is the central repository of all named schema types that\nwill be used throughout the API specification.\n\nCRITICAL REQUIREMENT: All object types MUST be defined as named types in\nthe components.schemas section. Inline anonymous object definitions are\nstrictly prohibited.\n\nThis components object should include:\n\n- Main entity types (IEntityName)\n- Operation-specific variants (.ICreate, .IUpdate, .ISummary, etc.)\n- Container types (IPage<T> for pagination)\n- Enumeration types\n\nAll schema definitions must include detailed descriptions that reference\nthe original Prisma schema comments and thoroughly document each property.\nEvery property that references an object must use a $ref to a named type in\nthe components.schemas section. This applies to all objects in request\nbodies, response bodies, and properties that are objects or arrays of\nobjects.\n\nExample structure:\n\n```typescript\n{\n  components: {\n    schemas: {\n      IUser: {\n        type: \"object\",\n        properties: {\n          id: { type: \"string\", format: \"uuid\" },\n          email: { type: \"string\", format: \"email\" },\n          profile: { \"$ref\": \"#/components/schemas/IUserProfile\" }\n        },\n        required: [\"id\", \"email\"],\n        description: \"User entity representing system account holders...\"\n      },\n      \"IUser.ICreate\": { ... },\n      // Additional schemas\n    }\n  }\n}\n```\n\n------------------------------\n\nDescription of the current {@link AutoBeOpenApi.IComponents} type:\n\n> Reusable components in OpenAPI.\n> \n> A storage of reusable components in OpenAPI document.\n> \n> In other words, it is a storage of named DTO schemas and security schemes.",
+                        description: "Complete set of schema components for the OpenAPI specification.\n\nThis property contains comprehensive type definitions for all entities in\nthe system. It is the central repository of all named schema types that\nwill be used throughout the API specification.\n\nCRITICAL REQUIREMENT: All object types MUST be defined as named types in\nthe components.schemas section. Inline anonymous object definitions are\nstrictly prohibited.\n\nThis components object should include:\n\n- Main entity types (IEntityName)\n- Operation-specific variants (.ICreate, .IUpdate, .ISummary, etc.)\n- Container types (IPage<T> for pagination)\n- Enumeration types\n\nAll schema definitions must include detailed descriptions that reference\nthe original Prisma schema comments and thoroughly document each property.\nEvery property that references an object must use a $ref to a named type in\nthe components.schemas section. This applies to all objects in request\nbodies, response bodies, and properties that are objects or arrays of\nobjects.\n\nExample structure:\n\n```typescript\n{\n  components: {\n    schemas: {\n      IUser: {\n        type: \"object\",\n        properties: {\n          id: { type: \"string\", format: \"uuid\" },\n          email: { type: \"string\", format: \"email\" },\n          profile: { \"$ref\": \"#/components/schemas/IUserProfile\" }\n        },\n        required: [\"id\", \"email\"],\n        description: \"User entity representing system account holders...\"\n      },\n      \"IUser.ICreate\": { ... },\n      // Additional schemas\n    }\n  }\n}\n```",
+                        $ref: "#/$defs/AutoBeOpenApi.IComponents"
+                    }
+                },
+                required: [
+                    "components"
+                ],
+                additionalProperties: false,
+                $defs: {
+                    "AutoBeOpenApi.IComponents": {
+                        description: "Reusable components in OpenAPI.\n\nA storage of reusable components in OpenAPI document.\n\nIn other words, it is a storage of named DTO schemas and security schemes.",
                         type: "object",
                         properties: {
                             schemas: {
-                                description: "An object to hold reusable DTO schemas.\n\nIn other words, a collection of named JSON schemas.\n\nIMPORTANT: For each schema in this collection:\n\n1. EVERY schema MUST have a detailed description that references and aligns\n   with the description comments from the corresponding Prisma DB schema\n   tables\n2. EACH property within the schema MUST have detailed descriptions that\n   reference and align with the description comments from the\n   corresponding DB schema columns\n3. All descriptions MUST be organized into MULTIPLE PARAGRAPHS (separated by\n   line breaks) when appropriate\n4. Descriptions should be comprehensive enough that anyone reading them can\n   understand the purpose, functionality, and constraints of each type\n   and property without needing to reference other documentation\n\n------------------------------\n\nDescription of the current {@link RecordstringAutoBeOpenApi.IJsonSchemaDescriptiveAutoBeOpenApi.IJsonSchema} type:\n\n> Construct a type with a set of properties K of type T",
-                                type: "object",
-                                properties: {},
-                                required: [],
-                                additionalProperties: {
-                                    description: "Description of the current {@link AutoBeOpenApi.IJsonSchemaDescriptiveAutoBeOpenApi.IJsonSchema} type:\n\n> Descriptive type schema info.\n> \n> `AutoBeOpenApi.IJsonSchemaDescriptive` is a type schema info of the OpenAPI\n> Generative, but it has a `description` property which is required.\n> \n> `AutoBeOpenApi.IJsonSchemaDescriptive` basically follows the JSON schema\n> specification of OpenAPI v3.1, but a little bit shrunk to remove ambiguous\n> and duplicated expressions of OpenAPI v3.1 for the convenience, clarity,\n> and AI generation.\n> \n> CRITICAL INSTRUCTIONS FOR OPTIMAL AI GENERATION:\n> \n> When creating descriptions for components, types, and properties:\n> \n> 1. ALWAYS refer to and incorporate the description comments from the\n>    corresponding Prisma DB schema tables and columns. The descriptions\n>    should match the style, level of detail, and terminology used in the\n>    Prisma schema.\n> 2. ALL descriptions MUST be organized into MULTIPLE PARAGRAPHS separated by\n>    line breaks. Single-paragraph descriptions should be avoided.\n> 3. Descriptions should comprehensively cover:\n> \n>    - The purpose and business meaning of the type or property\n>    - Relationships to other entities\n>    - Validation rules, constraints, and edge cases\n>    - Usage context and examples when helpful\n> 4. For each property of an object type, ensure its description reflects the\n>    corresponding column description in the Prisma DB schema, maintaining\n>    the same level of detail and terminology\n> 5. Descriptions should be so detailed and clear that anyone reading them can\n>    fully understand the type or property without needing to reference any\n>    other documentation",
-                                    type: "object",
-                                    properties: {
-                                        description: {
-                                            title: "Description about the type",
-                                            description: "Description about the type.\n\nCRITICAL: This description MUST be extensively detailed and MUST\nreference and align with the description comments from the\ncorresponding Prisma DB schema tables and columns.\n\nThe description MUST be organized into MULTIPLE PARAGRAPHS (separated\nby line breaks) based on different aspects of the type:\n\n- The purpose and business meaning of the type\n- Relationships to other entities in the system\n- Validation rules, constraints, and edge cases\n- Usage context and examples when helpful\n\nThis structured approach improves readability and helps readers better\nunderstand the type's various characteristics and use cases. The\ndescription should be so comprehensive that anyone reading it can fully\nunderstand the type without needing to reference other documentation.\n\n> MUST be written in English. Never use other languages.",
-                                            type: "string"
-                                        }
-                                    },
-                                    required: [
-                                        "description"
-                                    ]
-                                }
+                                description: "An object to hold reusable DTO schemas.\n\nIn other words, a collection of named JSON schemas.\n\nIMPORTANT: For each schema in this collection:\n\n1. EVERY schema MUST have a detailed description that references and aligns\n   with the description comments from the corresponding Prisma DB schema\n   tables\n2. EACH property within the schema MUST have detailed descriptions that\n   reference and align with the description comments from the\n   corresponding DB schema columns\n3. All descriptions MUST be organized into MULTIPLE PARAGRAPHS (separated by\n   line breaks) when appropriate\n4. Descriptions should be comprehensive enough that anyone reading them can\n   understand the purpose, functionality, and constraints of each type\n   and property without needing to reference other documentation",
+                                $ref: "#/$defs/RecordstringAutoBeOpenApi.IJsonSchemaDescriptiveAutoBeOpenApi.IJsonSchema"
                             },
                             authorization: {
-                                title: "Whether includes `Authorization` header or not",
                                 description: "Whether includes `Authorization` header or not.",
-                                "const": "header"
+                                type: "object",
+                                properties: {
+                                    roles: {
+                                        type: "array",
+                                        items: {
+                                            type: "object",
+                                            properties: {
+                                                title: {
+                                                    type: "string"
+                                                },
+                                                description: {
+                                                    type: "string"
+                                                }
+                                            },
+                                            required: [
+                                                "title",
+                                                "description"
+                                            ]
+                                        }
+                                    }
+                                },
+                                required: [
+                                    "roles"
+                                ]
                             }
                         },
                         required: [
                             "schemas"
                         ]
+                    },
+                    "RecordstringAutoBeOpenApi.IJsonSchemaDescriptiveAutoBeOpenApi.IJsonSchema": {
+                        description: "Construct a type with a set of properties K of type T",
+                        type: "object",
+                        properties: {},
+                        required: [],
+                        additionalProperties: {
+                            $ref: "#/$defs/AutoBeOpenApi.IJsonSchemaDescriptiveAutoBeOpenApi.IJsonSchema"
+                        }
+                    },
+                    "AutoBeOpenApi.IJsonSchemaDescriptiveAutoBeOpenApi.IJsonSchema": {
+                        description: "Descriptive type schema info.\n\n`AutoBeOpenApi.IJsonSchemaDescriptive` is a type schema info of the OpenAPI\nGenerative, but it has a `description` property which is required.\n\n`AutoBeOpenApi.IJsonSchemaDescriptive` basically follows the JSON schema\nspecification of OpenAPI v3.1, but a little bit shrunk to remove ambiguous\nand duplicated expressions of OpenAPI v3.1 for the convenience, clarity,\nand AI generation.\n\nCRITICAL INSTRUCTIONS FOR OPTIMAL AI GENERATION:\n\nWhen creating descriptions for components, types, and properties:\n\n1. ALWAYS refer to and incorporate the description comments from the\n   corresponding Prisma DB schema tables and columns. The descriptions\n   should match the style, level of detail, and terminology used in the\n   Prisma schema.\n2. ALL descriptions MUST be organized into MULTIPLE PARAGRAPHS separated by\n   line breaks. Single-paragraph descriptions should be avoided.\n3. Descriptions should comprehensively cover:\n\n   - The purpose and business meaning of the type or property\n   - Relationships to other entities\n   - Validation rules, constraints, and edge cases\n   - Usage context and examples when helpful\n4. For each property of an object type, ensure its description reflects the\n   corresponding column description in the Prisma DB schema, maintaining\n   the same level of detail and terminology\n5. Descriptions should be so detailed and clear that anyone reading them can\n   fully understand the type or property without needing to reference any\n   other documentation",
+                        type: "object",
+                        properties: {
+                            description: {
+                                description: "Description about the type.\n\nCRITICAL: This description MUST be extensively detailed and MUST\nreference and align with the description comments from the\ncorresponding Prisma DB schema tables and columns.\n\nThe description MUST be organized into MULTIPLE PARAGRAPHS (separated\nby line breaks) based on different aspects of the type:\n\n- The purpose and business meaning of the type\n- Relationships to other entities in the system\n- Validation rules, constraints, and edge cases\n- Usage context and examples when helpful\n\nThis structured approach improves readability and helps readers better\nunderstand the type's various characteristics and use cases. The\ndescription should be so comprehensive that anyone reading it can fully\nunderstand the type without needing to reference other documentation.\n\n> MUST be written in English. Never use other languages.",
+                                type: "string"
+                            }
+                        },
+                        required: [
+                            "description"
+                        ]
                     }
-                },
-                required: [
-                    "components"
-                ],
-                additionalProperties: false,
-                $defs: {}
+                }
             },
             description: "Generate OpenAPI components containing named schema types.\n\nThis method receives a complete set of schema components and integrates\nthem into the final OpenAPI specification. It processes all entity schemas,\ntheir variants, and related type definitions to ensure a comprehensive and\nconsistent API design.\n\nThe provided components should include schemas for all entities identified\nin the previous phases of API path/method definition and operation\ncreation. This ensures that the final OpenAPI document has complete type\ncoverage for all operations.\n\nCRITICAL: All schema definitions must follow the established naming\nconventions (IEntityName, IEntityName.ICreate, etc.) and must be thoroughly\ndocumented with descriptions that reference the original Prisma schema\ncomments.",
-            validate: (() => { const _io0 = input => "object" === typeof input.components && null !== input.components && _io1(input.components); const _io1 = input => "object" === typeof input.schemas && null !== input.schemas && false === Array.isArray(input.schemas) && _io2(input.schemas) && (undefined === input.authorization || "header" === input.authorization); const _io2 = input => Object.keys(input).every(key => {
+            validate: (() => { const _io0 = input => "object" === typeof input.components && null !== input.components && _io1(input.components); const _io1 = input => "object" === typeof input.schemas && null !== input.schemas && false === Array.isArray(input.schemas) && _io2(input.schemas) && (undefined === input.authorization || "object" === typeof input.authorization && null !== input.authorization && _io4(input.authorization)); const _io2 = input => Object.keys(input).every(key => {
                 const value = input[key];
                 if (undefined === value)
                     return true;
                 return "object" === typeof value && null !== value && _io3(value);
-            }); const _io3 = input => "string" === typeof input.description; const _vo0 = (input, _path, _exceptionable = true) => [("object" === typeof input.components && null !== input.components || _report(_exceptionable, {
+            }); const _io3 = input => "string" === typeof input.description; const _io4 = input => Array.isArray(input.roles) && input.roles.every(elem => "object" === typeof elem && null !== elem && _io5(elem)); const _io5 = input => "string" === typeof input.title && "string" === typeof input.description; const _vo0 = (input, _path, _exceptionable = true) => [("object" === typeof input.components && null !== input.components || _report(_exceptionable, {
                     path: _path + ".components",
                     expected: "AutoBeOpenApi.IComponents",
                     value: input.components
@@ -278,9 +315,13 @@ const claude = {
                     path: _path + ".schemas",
                     expected: "Record<string, AutoBeOpenApi.IJsonSchemaDescriptive<AutoBeOpenApi.IJsonSchema>>",
                     value: input.schemas
-                }), undefined === input.authorization || "header" === input.authorization || _report(_exceptionable, {
+                }), undefined === input.authorization || ("object" === typeof input.authorization && null !== input.authorization || _report(_exceptionable, {
+                    path: _path + ".authorization",
+                    expected: "(__type | undefined)",
+                    value: input.authorization
+                })) && _vo4(input.authorization, _path + ".authorization", true && _exceptionable) || _report(_exceptionable, {
                     path: _path + ".authorization",
-                    expected: "(\"header\" | undefined)",
+                    expected: "(__type | undefined)",
                     value: input.authorization
                 })].every(flag => flag); const _vo2 = (input, _path, _exceptionable = true) => [false === _exceptionable || Object.keys(input).map(key => {
                     const value = input[key];
@@ -299,6 +340,30 @@ const claude = {
                     path: _path + ".description",
                     expected: "string",
                     value: input.description
+                })].every(flag => flag); const _vo4 = (input, _path, _exceptionable = true) => [(Array.isArray(input.roles) || _report(_exceptionable, {
+                    path: _path + ".roles",
+                    expected: "Array<__type>",
+                    value: input.roles
+                })) && input.roles.map((elem, _index2) => ("object" === typeof elem && null !== elem || _report(_exceptionable, {
+                    path: _path + ".roles[" + _index2 + "]",
+                    expected: "__type.o1",
+                    value: elem
+                })) && _vo5(elem, _path + ".roles[" + _index2 + "]", true && _exceptionable) || _report(_exceptionable, {
+                    path: _path + ".roles[" + _index2 + "]",
+                    expected: "__type.o1",
+                    value: elem
+                })).every(flag => flag) || _report(_exceptionable, {
+                    path: _path + ".roles",
+                    expected: "Array<__type>",
+                    value: input.roles
+                })].every(flag => flag); const _vo5 = (input, _path, _exceptionable = true) => ["string" === typeof input.title || _report(_exceptionable, {
+                    path: _path + ".title",
+                    expected: "string",
+                    value: input.title
+                }), "string" === typeof input.description || _report(_exceptionable, {
+                    path: _path + ".description",
+                    expected: "string",
+                    value: input.description
                 })].every(flag => flag); const __is = input => "object" === typeof input && null !== input && _io0(input); let errors; let _report; return input => {
                 if (false === __is(input)) {
                     errors = [];
@@ -342,197 +407,88 @@ const collection = {
             {
                 name: "makeComponents",
                 parameters: {
-                    description: " Properties containing components to generate.\n\n------------------------------\n\nCurrent Type: {@link IMakeComponentsProps}",
+                    description: " Properties containing components to generate.\n\n------------------------------\n\nCurrent Type: {@link IMakeComponentsProps}\n\n### Description of {@link components} property:\n\n> Complete set of schema components for the OpenAPI specification.\n> \n> This property contains comprehensive type definitions for all entities in\n> the system. It is the central repository of all named schema types that\n> will be used throughout the API specification.\n> \n> CRITICAL REQUIREMENT: All object types MUST be defined as named types in\n> the components.schemas section. Inline anonymous object definitions are\n> strictly prohibited.\n> \n> This components object should include:\n> \n> - Main entity types (IEntityName)\n> - Operation-specific variants (.ICreate, .IUpdate, .ISummary, etc.)\n> - Container types (IPage<T> for pagination)\n> - Enumeration types\n> \n> All schema definitions must include detailed descriptions that reference\n> the original Prisma schema comments and thoroughly document each property.\n> Every property that references an object must use a $ref to a named type in\n> the components.schemas section. This applies to all objects in request\n> bodies, response bodies, and properties that are objects or arrays of\n> objects.\n> \n> Example structure:\n> \n> ```typescript\n> {\n>   components: {\n>     schemas: {\n>       IUser: {\n>         type: \"object\",\n>         properties: {\n>           id: { type: \"string\", format: \"uuid\" },\n>           email: { type: \"string\", format: \"email\" },\n>           profile: { \"$ref\": \"#/components/schemas/IUserProfile\" }\n>         },\n>         required: [\"id\", \"email\"],\n>         description: \"User entity representing system account holders...\"\n>       },\n>       \"IUser.ICreate\": { ... },\n>       // Additional schemas\n>     }\n>   }\n> }\n> ```",
                     type: "object",
                     properties: {
                         components: {
-                            description: "Complete set of schema components for the OpenAPI specification.\n\nThis property contains comprehensive type definitions for all entities in\nthe system. It is the central repository of all named schema types that\nwill be used throughout the API specification.\n\nCRITICAL REQUIREMENT: All object types MUST be defined as named types in\nthe components.schemas section. Inline anonymous object definitions are\nstrictly prohibited.\n\nThis components object should include:\n\n- Main entity types (IEntityName)\n- Operation-specific variants (.ICreate, .IUpdate, .ISummary, etc.)\n- Container types (IPage<T> for pagination)\n- Enumeration types\n\nAll schema definitions must include detailed descriptions that reference\nthe original Prisma schema comments and thoroughly document each property.\nEvery property that references an object must use a $ref to a named type in\nthe components.schemas section. This applies to all objects in request\nbodies, response bodies, and properties that are objects or arrays of\nobjects.\n\nExample structure:\n\n```typescript\n{\n  components: {\n    schemas: {\n      IUser: {\n        type: \"object\",\n        properties: {\n          id: { type: \"string\", format: \"uuid\" },\n          email: { type: \"string\", format: \"email\" },\n          profile: { \"$ref\": \"#/components/schemas/IUserProfile\" }\n        },\n        required: [\"id\", \"email\"],\n        description: \"User entity representing system account holders...\"\n      },\n      \"IUser.ICreate\": { ... },\n      // Additional schemas\n    }\n  }\n}\n```\n\n------------------------------\n\nDescription of the current {@link AutoBeOpenApi.IComponents} type:\n\n> Reusable components in OpenAPI.\n> \n> A storage of reusable components in OpenAPI document.\n> \n> In other words, it is a storage of named DTO schemas and security schemes.",
+                            $ref: "#/$defs/AutoBeOpenApi.IComponents"
+                        }
+                    },
+                    required: [
+                        "components"
+                    ],
+                    additionalProperties: false,
+                    $defs: {
+                        "AutoBeOpenApi.IComponents": {
+                            description: "Reusable components in OpenAPI.\n\nA storage of reusable components in OpenAPI document.\n\nIn other words, it is a storage of named DTO schemas and security schemes.\n\n### Description of {@link schemas} property:\n\n> An object to hold reusable DTO schemas.\n> \n> In other words, a collection of named JSON schemas.\n> \n> IMPORTANT: For each schema in this collection:\n> \n> 1. EVERY schema MUST have a detailed description that references and aligns\n>    with the description comments from the corresponding Prisma DB schema\n>    tables\n> 2. EACH property within the schema MUST have detailed descriptions that\n>    reference and align with the description comments from the\n>    corresponding DB schema columns\n> 3. All descriptions MUST be organized into MULTIPLE PARAGRAPHS (separated by\n>    line breaks) when appropriate\n> 4. Descriptions should be comprehensive enough that anyone reading them can\n>    understand the purpose, functionality, and constraints of each type\n>    and property without needing to reference other documentation",
                             type: "object",
                             properties: {
                                 schemas: {
-                                    description: "An object to hold reusable DTO schemas.\n\nIn other words, a collection of named JSON schemas.\n\nIMPORTANT: For each schema in this collection:\n\n1. EVERY schema MUST have a detailed description that references and aligns\n   with the description comments from the corresponding Prisma DB schema\n   tables\n2. EACH property within the schema MUST have detailed descriptions that\n   reference and align with the description comments from the\n   corresponding DB schema columns\n3. All descriptions MUST be organized into MULTIPLE PARAGRAPHS (separated by\n   line breaks) when appropriate\n4. Descriptions should be comprehensive enough that anyone reading them can\n   understand the purpose, functionality, and constraints of each type\n   and property without needing to reference other documentation\n\n------------------------------\n\nDescription of the current {@link RecordstringAutoBeOpenApi.IJsonSchemaDescriptiveAutoBeOpenApi.IJsonSchema} type:\n\n> Construct a type with a set of properties K of type T",
-                                    type: "object",
-                                    properties: {},
-                                    required: [],
-                                    additionalProperties: {
-                                        description: "Description of the current {@link AutoBeOpenApi.IJsonSchemaDescriptiveAutoBeOpenApi.IJsonSchema} type:\n\n> Descriptive type schema info.\n> \n> `AutoBeOpenApi.IJsonSchemaDescriptive` is a type schema info of the OpenAPI\n> Generative, but it has a `description` property which is required.\n> \n> `AutoBeOpenApi.IJsonSchemaDescriptive` basically follows the JSON schema\n> specification of OpenAPI v3.1, but a little bit shrunk to remove ambiguous\n> and duplicated expressions of OpenAPI v3.1 for the convenience, clarity,\n> and AI generation.\n> \n> CRITICAL INSTRUCTIONS FOR OPTIMAL AI GENERATION:\n> \n> When creating descriptions for components, types, and properties:\n> \n> 1. ALWAYS refer to and incorporate the description comments from the\n>    corresponding Prisma DB schema tables and columns. The descriptions\n>    should match the style, level of detail, and terminology used in the\n>    Prisma schema.\n> 2. ALL descriptions MUST be organized into MULTIPLE PARAGRAPHS separated by\n>    line breaks. Single-paragraph descriptions should be avoided.\n> 3. Descriptions should comprehensively cover:\n> \n>    - The purpose and business meaning of the type or property\n>    - Relationships to other entities\n>    - Validation rules, constraints, and edge cases\n>    - Usage context and examples when helpful\n> 4. For each property of an object type, ensure its description reflects the\n>    corresponding column description in the Prisma DB schema, maintaining\n>    the same level of detail and terminology\n> 5. Descriptions should be so detailed and clear that anyone reading them can\n>    fully understand the type or property without needing to reference any\n>    other documentation",
-                                        type: "object",
-                                        properties: {
-                                            description: {
-                                                title: "Description about the type",
-                                                description: "Description about the type.\n\nCRITICAL: This description MUST be extensively detailed and MUST\nreference and align with the description comments from the\ncorresponding Prisma DB schema tables and columns.\n\nThe description MUST be organized into MULTIPLE PARAGRAPHS (separated\nby line breaks) based on different aspects of the type:\n\n- The purpose and business meaning of the type\n- Relationships to other entities in the system\n- Validation rules, constraints, and edge cases\n- Usage context and examples when helpful\n\nThis structured approach improves readability and helps readers better\nunderstand the type's various characteristics and use cases. The\ndescription should be so comprehensive that anyone reading it can fully\nunderstand the type without needing to reference other documentation.\n\n> MUST be written in English. Never use other languages.",
-                                                type: "string"
-                                            }
-                                        },
-                                        required: [
-                                            "description"
-                                        ]
-                                    }
+                                    $ref: "#/$defs/RecordstringAutoBeOpenApi.IJsonSchemaDescriptiveAutoBeOpenApi.IJsonSchema"
                                 },
                                 authorization: {
-                                    title: "Whether includes `Authorization` header or not",
                                     description: "Whether includes `Authorization` header or not.",
-                                    type: "string",
-                                    "enum": [
-                                        "header"
+                                    type: "object",
+                                    properties: {
+                                        roles: {
+                                            type: "array",
+                                            items: {
+                                                type: "object",
+                                                properties: {
+                                                    title: {
+                                                        type: "string"
+                                                    },
+                                                    description: {
+                                                        type: "string"
+                                                    }
+                                                },
+                                                required: [
+                                                    "title",
+                                                    "description"
+                                                ]
+                                            }
+                                        }
+                                    },
+                                    required: [
+                                        "roles"
                                     ]
                                 }
                             },
                             required: [
                                 "schemas"
                             ]
-                        }
-                    },
-                    required: [
-                        "components"
-                    ],
-                    additionalProperties: false,
-                    $defs: {}
-                },
-                description: "Generate OpenAPI components containing named schema types.\n\nThis method receives a complete set of schema components and integrates\nthem into the final OpenAPI specification. It processes all entity schemas,\ntheir variants, and related type definitions to ensure a comprehensive and\nconsistent API design.\n\nThe provided components should include schemas for all entities identified\nin the previous phases of API path/method definition and operation\ncreation. This ensures that the final OpenAPI document has complete type\ncoverage for all operations.\n\nCRITICAL: All schema definitions must follow the established naming\nconventions (IEntityName, IEntityName.ICreate, etc.) and must be thoroughly\ndocumented with descriptions that reference the original Prisma schema\ncomments.",
-                validate: (() => { const _io0 = input => "object" === typeof input.components && null !== input.components && _io1(input.components); const _io1 = input => "object" === typeof input.schemas && null !== input.schemas && false === Array.isArray(input.schemas) && _io2(input.schemas) && (undefined === input.authorization || "header" === input.authorization); const _io2 = input => Object.keys(input).every(key => {
-                    const value = input[key];
-                    if (undefined === value)
-                        return true;
-                    return "object" === typeof value && null !== value && _io3(value);
-                }); const _io3 = input => "string" === typeof input.description; const _vo0 = (input, _path, _exceptionable = true) => [("object" === typeof input.components && null !== input.components || _report(_exceptionable, {
-                        path: _path + ".components",
-                        expected: "AutoBeOpenApi.IComponents",
-                        value: input.components
-                    })) && _vo1(input.components, _path + ".components", true && _exceptionable) || _report(_exceptionable, {
-                        path: _path + ".components",
-                        expected: "AutoBeOpenApi.IComponents",
-                        value: input.components
-                    })].every(flag => flag); const _vo1 = (input, _path, _exceptionable = true) => [("object" === typeof input.schemas && null !== input.schemas && false === Array.isArray(input.schemas) || _report(_exceptionable, {
-                        path: _path + ".schemas",
-                        expected: "Record<string, AutoBeOpenApi.IJsonSchemaDescriptive<AutoBeOpenApi.IJsonSchema>>",
-                        value: input.schemas
-                    })) && _vo2(input.schemas, _path + ".schemas", true && _exceptionable) || _report(_exceptionable, {
-                        path: _path + ".schemas",
-                        expected: "Record<string, AutoBeOpenApi.IJsonSchemaDescriptive<AutoBeOpenApi.IJsonSchema>>",
-                        value: input.schemas
-                    }), undefined === input.authorization || "header" === input.authorization || _report(_exceptionable, {
-                        path: _path + ".authorization",
-                        expected: "(\"header\" | undefined)",
-                        value: input.authorization
-                    })].every(flag => flag); const _vo2 = (input, _path, _exceptionable = true) => [false === _exceptionable || Object.keys(input).map(key => {
-                        const value = input[key];
-                        if (undefined === value)
-                            return true;
-                        return ("object" === typeof value && null !== value || _report(_exceptionable, {
-                            path: _path + __typia_transform__accessExpressionAsString._accessExpressionAsString(key),
-                            expected: "AutoBeOpenApi.IJsonSchemaDescriptive<AutoBeOpenApi.IJsonSchema>",
-                            value: value
-                        })) && _vo3(value, _path + __typia_transform__accessExpressionAsString._accessExpressionAsString(key), true && _exceptionable) || _report(_exceptionable, {
-                            path: _path + __typia_transform__accessExpressionAsString._accessExpressionAsString(key),
-                            expected: "AutoBeOpenApi.IJsonSchemaDescriptive<AutoBeOpenApi.IJsonSchema>",
-                            value: value
-                        });
-                    }).every(flag => flag)].every(flag => flag); const _vo3 = (input, _path, _exceptionable = true) => ["string" === typeof input.description || _report(_exceptionable, {
-                        path: _path + ".description",
-                        expected: "string",
-                        value: input.description
-                    })].every(flag => flag); const __is = input => "object" === typeof input && null !== input && _io0(input); let errors; let _report; return input => {
-                    if (false === __is(input)) {
-                        errors = [];
-                        _report = __typia_transform__validateReport._validateReport(errors);
-                        ((input, _path, _exceptionable = true) => ("object" === typeof input && null !== input || _report(true, {
-                            path: _path + "",
-                            expected: "IMakeComponentsProps",
-                            value: input
-                        })) && _vo0(input, _path + "", true) || _report(true, {
-                            path: _path + "",
-                            expected: "IMakeComponentsProps",
-                            value: input
-                        }))(input, "$input", true);
-                        const success = 0 === errors.length;
-                        return success ? {
-                            success,
-                            data: input
-                        } : {
-                            success,
-                            errors,
-                            data: input
-                        };
-                    }
-                    return {
-                        success: true,
-                        data: input
-                    };
-                }; })()
-            }
-        ]
-    },
-    claude,
-    llama: claude,
-    deepseek: claude,
-    "3.1": claude,
-    "3.0": {
-        model: "3.0",
-        options: {
-            constraint: true,
-            recursive: 3,
-            separate: null
-        },
-        functions: [
-            {
-                name: "makeComponents",
-                parameters: {
-                    type: "object",
-                    properties: {
-                        components: {
+                        },
+                        "RecordstringAutoBeOpenApi.IJsonSchemaDescriptiveAutoBeOpenApi.IJsonSchema": {
+                            description: "Construct a type with a set of properties K of type T",
+                            type: "object",
+                            properties: {},
+                            required: [],
+                            additionalProperties: {
+                                $ref: "#/$defs/AutoBeOpenApi.IJsonSchemaDescriptiveAutoBeOpenApi.IJsonSchema"
+                            }
+                        },
+                        "AutoBeOpenApi.IJsonSchemaDescriptiveAutoBeOpenApi.IJsonSchema": {
+                            description: "Descriptive type schema info.\n\n`AutoBeOpenApi.IJsonSchemaDescriptive` is a type schema info of the OpenAPI\nGenerative, but it has a `description` property which is required.\n\n`AutoBeOpenApi.IJsonSchemaDescriptive` basically follows the JSON schema\nspecification of OpenAPI v3.1, but a little bit shrunk to remove ambiguous\nand duplicated expressions of OpenAPI v3.1 for the convenience, clarity,\nand AI generation.\n\nCRITICAL INSTRUCTIONS FOR OPTIMAL AI GENERATION:\n\nWhen creating descriptions for components, types, and properties:\n\n1. ALWAYS refer to and incorporate the description comments from the\n   corresponding Prisma DB schema tables and columns. The descriptions\n   should match the style, level of detail, and terminology used in the\n   Prisma schema.\n2. ALL descriptions MUST be organized into MULTIPLE PARAGRAPHS separated by\n   line breaks. Single-paragraph descriptions should be avoided.\n3. Descriptions should comprehensively cover:\n\n   - The purpose and business meaning of the type or property\n   - Relationships to other entities\n   - Validation rules, constraints, and edge cases\n   - Usage context and examples when helpful\n4. For each property of an object type, ensure its description reflects the\n   corresponding column description in the Prisma DB schema, maintaining\n   the same level of detail and terminology\n5. Descriptions should be so detailed and clear that anyone reading them can\n   fully understand the type or property without needing to reference any\n   other documentation",
                             type: "object",
                             properties: {
-                                schemas: {
-                                    type: "object",
-                                    properties: {},
-                                    required: [],
-                                    description: "An object to hold reusable DTO schemas.\n\nIn other words, a collection of named JSON schemas.\n\nIMPORTANT: For each schema in this collection:\n\n1. EVERY schema MUST have a detailed description that references and aligns\n   with the description comments from the corresponding Prisma DB schema\n   tables\n2. EACH property within the schema MUST have detailed descriptions that\n   reference and align with the description comments from the\n   corresponding DB schema columns\n3. All descriptions MUST be organized into MULTIPLE PARAGRAPHS (separated by\n   line breaks) when appropriate\n4. Descriptions should be comprehensive enough that anyone reading them can\n   understand the purpose, functionality, and constraints of each type\n   and property without needing to reference other documentation\n\n------------------------------\n\nDescription of the current {@link RecordstringAutoBeOpenApi.IJsonSchemaDescriptiveAutoBeOpenApi.IJsonSchema} type:\n\n> Construct a type with a set of properties K of type T",
-                                    additionalProperties: {
-                                        type: "object",
-                                        properties: {
-                                            description: {
-                                                type: "string",
-                                                title: "Description about the type",
-                                                description: "Description about the type.\n\nCRITICAL: This description MUST be extensively detailed and MUST\nreference and align with the description comments from the\ncorresponding Prisma DB schema tables and columns.\n\nThe description MUST be organized into MULTIPLE PARAGRAPHS (separated\nby line breaks) based on different aspects of the type:\n\n- The purpose and business meaning of the type\n- Relationships to other entities in the system\n- Validation rules, constraints, and edge cases\n- Usage context and examples when helpful\n\nThis structured approach improves readability and helps readers better\nunderstand the type's various characteristics and use cases. The\ndescription should be so comprehensive that anyone reading it can fully\nunderstand the type without needing to reference other documentation.\n\n> MUST be written in English. Never use other languages."
-                                            }
-                                        },
-                                        required: [
-                                            "description"
-                                        ],
-                                        description: "Description of the current {@link AutoBeOpenApi.IJsonSchemaDescriptiveAutoBeOpenApi.IJsonSchema} type:\n\n> Descriptive type schema info.\n> \n> `AutoBeOpenApi.IJsonSchemaDescriptive` is a type schema info of the OpenAPI\n> Generative, but it has a `description` property which is required.\n> \n> `AutoBeOpenApi.IJsonSchemaDescriptive` basically follows the JSON schema\n> specification of OpenAPI v3.1, but a little bit shrunk to remove ambiguous\n> and duplicated expressions of OpenAPI v3.1 for the convenience, clarity,\n> and AI generation.\n> \n> CRITICAL INSTRUCTIONS FOR OPTIMAL AI GENERATION:\n> \n> When creating descriptions for components, types, and properties:\n> \n> 1. ALWAYS refer to and incorporate the description comments from the\n>    corresponding Prisma DB schema tables and columns. The descriptions\n>    should match the style, level of detail, and terminology used in the\n>    Prisma schema.\n> 2. ALL descriptions MUST be organized into MULTIPLE PARAGRAPHS separated by\n>    line breaks. Single-paragraph descriptions should be avoided.\n> 3. Descriptions should comprehensively cover:\n> \n>    - The purpose and business meaning of the type or property\n>    - Relationships to other entities\n>    - Validation rules, constraints, and edge cases\n>    - Usage context and examples when helpful\n> 4. For each property of an object type, ensure its description reflects the\n>    corresponding column description in the Prisma DB schema, maintaining\n>    the same level of detail and terminology\n> 5. Descriptions should be so detailed and clear that anyone reading them can\n>    fully understand the type or property without needing to reference any\n>    other documentation",
-                                        additionalProperties: false
-                                    }
-                                },
-                                authorization: {
-                                    type: "string",
-                                    "enum": [
-                                        "header"
-                                    ],
-                                    title: "Whether includes `Authorization` header or not",
-                                    description: "Whether includes `Authorization` header or not."
+                                description: {
+                                    description: "Description about the type.\n\nCRITICAL: This description MUST be extensively detailed and MUST\nreference and align with the description comments from the\ncorresponding Prisma DB schema tables and columns.\n\nThe description MUST be organized into MULTIPLE PARAGRAPHS (separated\nby line breaks) based on different aspects of the type:\n\n- The purpose and business meaning of the type\n- Relationships to other entities in the system\n- Validation rules, constraints, and edge cases\n- Usage context and examples when helpful\n\nThis structured approach improves readability and helps readers better\nunderstand the type's various characteristics and use cases. The\ndescription should be so comprehensive that anyone reading it can fully\nunderstand the type without needing to reference other documentation.\n\n> MUST be written in English. Never use other languages.",
+                                    type: "string"
                                 }
                             },
                             required: [
-                                "schemas"
-                            ],
-                            description: "Complete set of schema components for the OpenAPI specification.\n\nThis property contains comprehensive type definitions for all entities in\nthe system. It is the central repository of all named schema types that\nwill be used throughout the API specification.\n\nCRITICAL REQUIREMENT: All object types MUST be defined as named types in\nthe components.schemas section. Inline anonymous object definitions are\nstrictly prohibited.\n\nThis components object should include:\n\n- Main entity types (IEntityName)\n- Operation-specific variants (.ICreate, .IUpdate, .ISummary, etc.)\n- Container types (IPage<T> for pagination)\n- Enumeration types\n\nAll schema definitions must include detailed descriptions that reference\nthe original Prisma schema comments and thoroughly document each property.\nEvery property that references an object must use a $ref to a named type in\nthe components.schemas section. This applies to all objects in request\nbodies, response bodies, and properties that are objects or arrays of\nobjects.\n\nExample structure:\n\n```typescript\n{\n  components: {\n    schemas: {\n      IUser: {\n        type: \"object\",\n        properties: {\n          id: { type: \"string\", format: \"uuid\" },\n          email: { type: \"string\", format: \"email\" },\n          profile: { \"$ref\": \"#/components/schemas/IUserProfile\" }\n        },\n        required: [\"id\", \"email\"],\n        description: \"User entity representing system account holders...\"\n      },\n      \"IUser.ICreate\": { ... },\n      // Additional schemas\n    }\n  }\n}\n```\n\n------------------------------\n\nDescription of the current {@link AutoBeOpenApi.IComponents} type:\n\n> Reusable components in OpenAPI.\n> \n> A storage of reusable components in OpenAPI document.\n> \n> In other words, it is a storage of named DTO schemas and security schemes.",
-                            additionalProperties: false
+                                "description"
+                            ]
                         }
-                    },
-                    required: [
-                        "components"
-                    ],
-                    description: " Properties containing components to generate.\n\n------------------------------\n\nCurrent Type: {@link IMakeComponentsProps}",
-                    additionalProperties: false
+                    }
                 },
                 description: "Generate OpenAPI components containing named schema types.\n\nThis method receives a complete set of schema components and integrates\nthem into the final OpenAPI specification. It processes all entity schemas,\ntheir variants, and related type definitions to ensure a comprehensive and\nconsistent API design.\n\nThe provided components should include schemas for all entities identified\nin the previous phases of API path/method definition and operation\ncreation. This ensures that the final OpenAPI document has complete type\ncoverage for all operations.\n\nCRITICAL: All schema definitions must follow the established naming\nconventions (IEntityName, IEntityName.ICreate, etc.) and must be thoroughly\ndocumented with descriptions that reference the original Prisma schema\ncomments.",
-                validate: (() => { const _io0 = input => "object" === typeof input.components && null !== input.components && _io1(input.components); const _io1 = input => "object" === typeof input.schemas && null !== input.schemas && false === Array.isArray(input.schemas) && _io2(input.schemas) && (undefined === input.authorization || "header" === input.authorization); const _io2 = input => Object.keys(input).every(key => {
+                validate: (() => { const _io0 = input => "object" === typeof input.components && null !== input.components && _io1(input.components); const _io1 = input => "object" === typeof input.schemas && null !== input.schemas && false === Array.isArray(input.schemas) && _io2(input.schemas) && (undefined === input.authorization || "object" === typeof input.authorization && null !== input.authorization && _io4(input.authorization)); const _io2 = input => Object.keys(input).every(key => {
                     const value = input[key];
                     if (undefined === value)
                         return true;
                     return "object" === typeof value && null !== value && _io3(value);
-                }); const _io3 = input => "string" === typeof input.description; const _vo0 = (input, _path, _exceptionable = true) => [("object" === typeof input.components && null !== input.components || _report(_exceptionable, {
+                }); const _io3 = input => "string" === typeof input.description; const _io4 = input => Array.isArray(input.roles) && input.roles.every(elem => "object" === typeof elem && null !== elem && _io5(elem)); const _io5 = input => "string" === typeof input.title && "string" === typeof input.description; const _vo0 = (input, _path, _exceptionable = true) => [("object" === typeof input.components && null !== input.components || _report(_exceptionable, {
                         path: _path + ".components",
                         expected: "AutoBeOpenApi.IComponents",
                         value: input.components
@@ -548,9 +504,13 @@ const collection = {
                         path: _path + ".schemas",
                         expected: "Record<string, AutoBeOpenApi.IJsonSchemaDescriptive<AutoBeOpenApi.IJsonSchema>>",
                         value: input.schemas
-                    }), undefined === input.authorization || "header" === input.authorization || _report(_exceptionable, {
+                    }), undefined === input.authorization || ("object" === typeof input.authorization && null !== input.authorization || _report(_exceptionable, {
                         path: _path + ".authorization",
-                        expected: "(\"header\" | undefined)",
+                        expected: "(__type | undefined)",
+                        value: input.authorization
+                    })) && _vo4(input.authorization, _path + ".authorization", true && _exceptionable) || _report(_exceptionable, {
+                        path: _path + ".authorization",
+                        expected: "(__type | undefined)",
                         value: input.authorization
                     })].every(flag => flag); const _vo2 = (input, _path, _exceptionable = true) => [false === _exceptionable || Object.keys(input).map(key => {
                         const value = input[key];
@@ -569,6 +529,30 @@ const collection = {
                         path: _path + ".description",
                         expected: "string",
                         value: input.description
+                    })].every(flag => flag); const _vo4 = (input, _path, _exceptionable = true) => [(Array.isArray(input.roles) || _report(_exceptionable, {
+                        path: _path + ".roles",
+                        expected: "Array<__type>",
+                        value: input.roles
+                    })) && input.roles.map((elem, _index2) => ("object" === typeof elem && null !== elem || _report(_exceptionable, {
+                        path: _path + ".roles[" + _index2 + "]",
+                        expected: "__type.o1",
+                        value: elem
+                    })) && _vo5(elem, _path + ".roles[" + _index2 + "]", true && _exceptionable) || _report(_exceptionable, {
+                        path: _path + ".roles[" + _index2 + "]",
+                        expected: "__type.o1",
+                        value: elem
+                    })).every(flag => flag) || _report(_exceptionable, {
+                        path: _path + ".roles",
+                        expected: "Array<__type>",
+                        value: input.roles
+                    })].every(flag => flag); const _vo5 = (input, _path, _exceptionable = true) => ["string" === typeof input.title || _report(_exceptionable, {
+                        path: _path + ".title",
+                        expected: "string",
+                        value: input.title
+                    }), "string" === typeof input.description || _report(_exceptionable, {
+                        path: _path + ".description",
+                        expected: "string",
+                        value: input.description
                     })].every(flag => flag); const __is = input => "object" === typeof input && null !== input && _io0(input); let errors; let _report; return input => {
                     if (false === __is(input)) {
                         errors = [];
@@ -600,5 +584,9 @@ const collection = {
             }
         ]
     },
+    claude,
+    llama: claude,
+    deepseek: claude,
+    "3.1": claude,
 };
 //# sourceMappingURL=orchestrateInterfaceComponents.js.map