@autobe/agent 0.30.4 → 0.30.5

package/src/orchestrate/common/structures/IAutoBePreliminaryGetRealizeTransformers.ts

@@ -1,31 +1,12 @@
 import { tags } from "typia";
 
-/**
- * Request to retrieve Realize Transformer function definitions for context.
- *
- * This type is used in the preliminary phase to request specific transformer
- * functions generated during the REALIZE_TRANSFORMER_WRITE phase. Transformers
- * convert database query results into API response DTOs.
- *
- * @author Samchon
- */
+/** Request to retrieve Realize Transformer function definitions for context. */
 export interface IAutoBePreliminaryGetRealizeTransformers {
-  /**
-   * Type discriminator for the request.
-   *
-   * Determines which action to perform: preliminary data retrieval or actual
-   * task execution. Value "getRealizeTransformers" indicates this is a
-   * preliminary data request for transformer functions.
-   */
+  /** Type discriminator. */
   type: "getRealizeTransformers";
 
   /**
-   * List of transformer DTO type names to retrieve.
-   *
-   * DTO type names for response DTOs that have transformer functions (e.g.,
-   * "IShoppingSale", "IBbsArticle", "IShoppingSale.ISummary").
-   *
-   * CRITICAL: DO NOT request the same type names that you have already
+   * Transformer DTO type names to retrieve. DO NOT request same names already
    * requested in previous calls.
    */
   dtoTypeNames: string[] & tags.MinItems<1>;

package/src/orchestrate/interface/structures/IAutoBeInterfaceAuthorizationApplication.ts

@@ -7,53 +7,21 @@ import { IAutoBePreliminaryGetPreviousAnalysisSections } from "../../common/stru
 import { IAutoBePreliminaryGetPreviousDatabaseSchemas } from "../../common/structures/IAutoBePreliminaryGetPreviousDatabaseSchemas";
 
 export interface IAutoBeInterfaceAuthorizationApplication {
-  /**
-   * Process authorization operations generation task or preliminary data
-   * requests.
-   *
-   * Generates authorization operations for the given roles and ensures the
-   * interface reflects correct permissions and access levels.
-   *
-   * @param props Request containing either preliminary data request or complete
-   *   task
-   */
+  /** Process task or retrieve preliminary data. */
   process(props: IAutoBeInterfaceAuthorizationApplication.IProps): void;
 }
 
 export namespace IAutoBeInterfaceAuthorizationApplication {
   export interface IProps {
     /**
-     * Think before you act.
-     *
-     * Before requesting preliminary data or completing your task, reflect on
-     * your current state and explain your reasoning:
-     *
-     * For preliminary requests (getAnalysisSections, getDatabaseSchemas, etc.):
-     *
-     * - What critical information is missing that you don't already have?
-     * - Why do you need it specifically right now?
-     * - Be brief - state the gap, don't list everything you have.
-     *
-     * For completion (complete):
-     *
-     * - What key assets did you acquire?
-     * - What did you accomplish?
-     * - Why is it sufficient to complete?
-     * - Summarize - don't enumerate every single item.
-     *
-     * This reflection helps you avoid duplicate requests and premature
-     * completion.
+     * Reasoning about your current state: what's missing (preliminary) or what
+     * you accomplished (completion).
      */
     thinking: string;
 
     /**
-     * Type discriminator for the request.
-     *
-     * Determines which action to perform: preliminary data retrieval
-     * (getAnalysisSections, getPreviousAnalysisSections, getDatabaseSchemas,
-     * getPreviousDatabaseSchemas) or final authorization operations generation
-     * (complete). When preliminary returns empty array, that type is removed
-     * from the union, physically preventing repeated calls.
+     * Action to perform. Exhausted preliminary types are removed from the
+     * union.
      */
     request:
       | IComplete
@@ -63,73 +31,18 @@ export namespace IAutoBeInterfaceAuthorizationApplication {
       | IAutoBePreliminaryGetPreviousDatabaseSchemas;
   }
 
-  /**
-   * Request to generate authorization operations.
-   *
-   * Executes authorization operations generation to define the authorization
-   * requirements for the given roles. Ensures operations reflect correct
-   * permissions and access levels for each role.
-   */
+  /** Request to generate authorization operations. */
   export interface IComplete {
-    /**
-     * Type discriminator for the request.
-     *
-     * Determines which action to perform: preliminary data retrieval or actual
-     * task execution. Value "complete" indicates this is the final task
-     * execution request.
-     */
+    /** Type discriminator for completion request. */
     type: "complete";
 
-    /**
-     * Analysis of the actor's authentication requirements and schema context.
-     *
-     * Documents the agent's understanding of the actor type
-     * (guest/member/admin), what authentication fields exist in the database
-     * schema, what additional authentication features are supported by the
-     * schema, and what operations are appropriate for this actor kind.
-     */
+    /** Analysis of the actor's authentication requirements and schema context. */
     analysis: string;
 
-    /**
-     * Rationale for the authorization operation design decisions.
-     *
-     * Explains why specific operations were included or excluded, how the actor
-     * kind influenced the essential operations selection (e.g., why guests
-     * don't have login), what schema fields enabled additional operations, and
-     * why certain authentication patterns were chosen.
-     */
+    /** Rationale for authorization operation design decisions. */
     rationale: string;
 
-    /**
-     * Array of API operations to generate authorization operation for.
-     *
-     * Each operation in this array must include:
-     *
-     * - Specification: Detailed API specification with clear purpose and
-     *   functionality
-     * - Path: Resource-centric URL path (e.g., "/resources/{resourceId}")
-     * - Method: HTTP method (get, post, put, delete, patch)
-     * - Description: Extremely detailed multi-paragraph description referencing
-     *   database schema comments
-     * - Summary: Concise one-sentence summary of the endpoint
-     * - Parameters: Array of all necessary parameters with descriptions and
-     *   schema definitions
-     * - RequestBody: For POST/PUT/PATCH methods, with typeName referencing
-     *   components.schemas
-     * - ResponseBody: With typeName referencing appropriate response type
-     *
-     * All operations must follow strict quality standards:
-     *
-     * 1. Detailed descriptions referencing database 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.
-     */
+    /** Array of API operations to generate for authorization. */
     operations: AutoBeOpenApi.IOperation[] & tags.MinItems<1>;
   }
 }

package/src/orchestrate/interface/structures/IAutoBeInterfaceEndpointReviewApplication.ts

@@ -8,19 +8,8 @@ import { IAutoBePreliminaryGetPreviousInterfaceOperations } from "../../common/s
 
 export interface IAutoBeInterfaceEndpointReviewApplication {
   /**
-   * Process endpoint review task or preliminary data requests.
-   *
-   * Reviews and validates generated endpoints to ensure they meet quality
-   * standards. The review process examines endpoint design, identifies issues
-   * such as duplicates or inconsistencies, and applies corrections through
-   * revision operations (keep, create, update, or erase).
-   *
-   * **Critical**: Every endpoint in the provided list MUST receive a revision
-   * decision. No omissions are allowed - use "keep" to explicitly approve
-   * endpoints that need no changes.
-   *
-   * @param props Request containing either preliminary data request or endpoint
-   *   review completion
+   * Process task or retrieve preliminary data. Every endpoint MUST receive a
+   * revision decision.
    */
   process(props: IAutoBeInterfaceEndpointReviewApplication.IProps): void;
 }
@@ -28,38 +17,14 @@ export interface IAutoBeInterfaceEndpointReviewApplication {
 export namespace IAutoBeInterfaceEndpointReviewApplication {
   export interface IProps {
     /**
-     * Think before you act.
-     *
-     * Before requesting preliminary data or completing your task, reflect on
-     * your current state and explain your reasoning:
-     *
-     * For preliminary requests (getAnalysisSections, getDatabaseSchemas, etc.):
-     *
-     * - What critical information is missing that you don't already have?
-     * - Why do you need it specifically right now?
-     * - Be brief - state the gap, don't list everything you have.
-     *
-     * For completion (complete):
-     *
-     * - What key assets did you acquire?
-     * - What did you accomplish?
-     * - Why is it sufficient to complete?
-     * - Summarize - don't enumerate every single item.
-     *
-     * This reflection helps you avoid duplicate requests and premature
-     * completion.
+     * Reasoning about your current state: what's missing (preliminary) or what
+     * you accomplished (completion).
      */
     thinking: string;
 
     /**
-     * Type discriminator for the request.
-     *
-     * Determines which action to perform: preliminary data retrieval
-     * (getAnalysisSections, getDatabaseSchemas, getPreviousAnalysisSections,
-     * getPreviousDatabaseSchemas, getPreviousInterfaceOperations) or completion
-     * of the review with all modifications (complete). When preliminary returns
-     * empty array, that type is removed from the union, physically preventing
-     * repeated calls.
+     * Action to perform. Exhausted preliminary types are removed from the
+     * union.
      */
     request:
       | IComplete
@@ -71,57 +36,23 @@ export namespace IAutoBeInterfaceEndpointReviewApplication {
   }
 
   /**
-   * Request to complete the endpoint review process.
-   *
-   * Finalizes the review by submitting revision decisions for ALL endpoints.
-   * Every endpoint in the provided list must have exactly one revision:
-   *
-   * - **keep**: Approve endpoint as-is (explicitly confirm it's correct)
-   * - **create**: Add a new endpoint that was missing
-   * - **update**: Fix an incorrectly structured endpoint
-   * - **erase**: Remove an invalid or duplicate endpoint
-   *
-   * The revisions ensure the final API structure is consistent, free of
-   * duplicates, properly designed, and aligned with RESTful conventions.
+   * Complete endpoint review with revision decisions (keep/create/update/erase)
+   * for ALL endpoints.
    */
   export interface IComplete {
-    /**
-     * Type discriminator for the request.
-     *
-     * Determines which action to perform: preliminary data retrieval or actual
-     * task execution. Value "complete" indicates this is the final task
-     * execution request.
-     */
+    /** Type discriminator for completion request. */
     type: "complete";
 
     /**
-     * Summary of issues found and fixes applied during review.
-     *
-     * Document all issues discovered during endpoint validation:
-     *
-     * - What duplicates, inconsistencies, or design issues were found?
-     * - What endpoints needed to be added, modified, or removed?
-     * - What patterns or conventions were violated?
-     *
-     * State "No issues found." if all endpoints pass review.
+     * Summary of issues found and fixes applied. State "No issues found." if
+     * all pass.
      */
     review: string;
 
     /**
-     * Revision decisions for ALL endpoints.
-     *
-     * You MUST provide exactly one revision for each endpoint in the provided
-     * list. No omissions allowed.
-     *
-     * - Use **keep** for endpoints that are correct (do NOT simply omit them)
-     * - Use **create** to add missing endpoints
-     * - Use **update** to fix incorrectly structured endpoints
-     * - Use **erase** to remove invalid or duplicate endpoints
-     *
-     * The endpoint field in keep, update, and erase must exactly match an
-     * endpoint from the provided list (path + method).
-     *
-     * @see AutoBeInterfaceEndpointRevise - Discriminated union of revision types
+     * Revision decisions for ALL endpoints. One revision per endpoint, no
+     * omissions. The endpoint field in keep/update/erase must exactly match a
+     * provided endpoint (path + method).
      */
     revises: AutoBeInterfaceEndpointRevise[];
   }

package/src/orchestrate/interface/structures/IAutoBeInterfaceEndpointWriteApplication.ts

@@ -7,52 +7,21 @@ import { IAutoBePreliminaryGetPreviousDatabaseSchemas } from "../../common/struc
 import { IAutoBePreliminaryGetPreviousInterfaceOperations } from "../../common/structures/IAutoBePreliminaryGetPreviousInterfaceOperations";
 
 export interface IAutoBeInterfaceEndpointWriteApplication {
-  /**
-   * Process endpoint generation task or preliminary data requests.
-   *
-   * Generates API endpoints based on requirements analysis and database
-   * schemas. Endpoints are created to fulfill business requirements while
-   * adhering to RESTful design principles and AutoBE conventions.
-   *
-   * @param props Request containing either preliminary data request or complete
-   *   task
-   */
+  /** Process task or retrieve preliminary data. */
   process(props: IAutoBeInterfaceEndpointWriteApplication.IProps): void;
 }
 
 export namespace IAutoBeInterfaceEndpointWriteApplication {
   export interface IProps {
     /**
-     * Think before you act.
-     *
-     * Before requesting preliminary data or completing your task, reflect on
-     * your current state and explain your reasoning:
-     *
-     * For preliminary requests (getAnalysisSections, getDatabaseSchemas, etc.):
-     *
-     * - What critical information is missing that you don't already have?
-     * - Why do you need it specifically right now?
-     * - Be brief - state the gap, don't list everything you have.
-     *
-     * For completion (complete):
-     *
-     * - What key assets did you acquire?
-     * - What did you accomplish?
-     * - Why is it sufficient to complete?
-     * - Summarize - don't enumerate every single item.
-     *
-     * This reflection helps you avoid duplicate requests and premature
-     * completion.
+     * Reasoning about your current state: what's missing (preliminary) or what
+     * you accomplished (completion).
      */
     thinking: string;
 
     /**
-     * Type discriminator for the request.
-     *
-     * Determines which action to perform: preliminary data retrieval
-     * (getAnalysisSections, getDatabaseSchemas) or final endpoint generation
-     * (complete). When preliminary returns empty array, that type is removed
-     * from the union, physically preventing repeated calls.
+     * Action to perform. Exhausted preliminary types are removed from the
+     * union.
      */
     request:
       | IComplete
@@ -63,70 +32,23 @@ export namespace IAutoBeInterfaceEndpointWriteApplication {
       | IAutoBePreliminaryGetPreviousInterfaceOperations;
   }
 
-  /**
-   * Request to complete endpoint generation.
-   *
-   * Finalizes the endpoint generation task by submitting all generated
-   * endpoints. Each endpoint is derived from requirements analysis and database
-   * schemas, designed to fulfill specific business needs while maintaining
-   * RESTful conventions and API design best practices.
-   */
+  /** Request to complete endpoint generation. */
   export interface IComplete {
-    /**
-     * Type discriminator for the request.
-     *
-     * Determines which action to perform: preliminary data retrieval or actual
-     * task execution. Value "complete" indicates this is the final task
-     * execution request.
-     */
+    /** Type discriminator for completion request. */
     type: "complete";
 
-    /**
-     * Analysis of the requirements and database schema for endpoint design.
-     *
-     * Before designing endpoints, analyze what you know:
-     *
-     * - What business requirements need API coverage?
-     * - What database entities and relationships inform endpoint structure?
-     * - What CRUD operations are needed for each entity?
-     * - What special operations beyond basic CRUD are required?
-     */
+    /** Analysis of requirements and database schema for endpoint design. */
     analysis: string;
 
-    /**
-     * Rationale for the endpoint design decisions.
-     *
-     * Explain why you designed endpoints this way:
-     *
-     * - Why did you choose these paths and methods?
-     * - How do endpoints map to requirements and entities?
-     * - What RESTful conventions did you follow?
-     * - What was excluded and why?
-     */
+    /** Rationale for the endpoint design decisions. */
     rationale: string;
 
     /**
      * Array of endpoint designs to generate.
      *
-     * Each design pairs an endpoint (path + method) with a description of its
-     * purpose. All endpoints must adhere to RESTful conventions and AutoBE
-     * design standards.
-     *
-     * ## Path Structure
-     *
-     * - Must use hierarchical `/` structure (NOT camelCase concatenation)
-     * - Must start with `/`
-     * - Must NOT include domain prefixes (`/shopping/`, `/bbs/`)
-     * - Resource collection names should use plural form
-     *
-     * ## Common Validation Rules
-     *
-     * - Must NOT duplicate existing endpoints
-     * - HTTP methods must align with their semantic meanings
-     * - Path parameters must be clearly named (e.g., `{userId}`, `{productId}`)
-     * - Nested paths should reflect entity relationships
-     *
-     * @see AutoBeInterfaceEndpointDesign - Endpoint design type with description
+     * Path rules: hierarchical `/` structure, must start with `/`, no domain
+     * prefixes, plural resource names. No duplicate endpoints. Path parameters
+     * clearly named. Nested paths reflect entity relationships.
      */
     designs: AutoBeInterfaceEndpointDesign[];
   }

package/src/orchestrate/interface/structures/IAutoBeInterfaceGroupApplication.ts

@@ -8,55 +8,21 @@ import { IAutoBePreliminaryGetPreviousDatabaseSchemas } from "../../common/struc
 import { IAutoBePreliminaryGetPreviousInterfaceOperations } from "../../common/structures/IAutoBePreliminaryGetPreviousInterfaceOperations";
 
 export interface IAutoBeInterfaceGroupApplication {
-  /**
-   * Process group generation task or preliminary data requests.
-   *
-   * Generate logical groups for organizing API endpoint creation based on
-   * database schema structure. Processes group generation with incremental
-   * context loading to ensure comprehensive organization.
-   *
-   * @param props Request containing either preliminary data request or complete
-   *   task
-   */
+  /** Process task or retrieve preliminary data. */
   process(props: IAutoBeInterfaceGroupApplication.IProps): void;
 }
 
 export namespace IAutoBeInterfaceGroupApplication {
   export interface IProps {
     /**
-     * Think before you act.
-     *
-     * Before requesting preliminary data or completing your task, reflect on
-     * your current state and explain your reasoning:
-     *
-     * For preliminary requests (getAnalysisSections,
-     * getPreviousAnalysisSections, getDatabaseSchemas,
-     * getPreviousDatabaseSchemas):
-     *
-     * - What critical information is missing that you don't already have?
-     * - Why do you need it specifically right now?
-     * - Be brief - state the gap, don't list everything you have.
-     *
-     * For completion (complete):
-     *
-     * - What key assets did you acquire?
-     * - What did you accomplish?
-     * - Why is it sufficient to complete?
-     * - Summarize - don't enumerate every single item.
-     *
-     * This reflection helps you avoid duplicate requests and premature
-     * completion.
+     * Reasoning about your current state: what's missing (preliminary) or what
+     * you accomplished (completion).
      */
     thinking: string;
 
     /**
-     * Type discriminator for the request.
-     *
-     * Determines which action to perform: preliminary data retrieval
-     * (getAnalysisSections, getPreviousAnalysisSections, getDatabaseSchemas,
-     * getPreviousDatabaseSchemas) or final group generation (complete). When
-     * preliminary returns empty array, that type is removed from the union,
-     * physically preventing repeated calls.
+     * Action to perform. Exhausted preliminary types are removed from the
+     * union.
      */
     request:
       | IComplete
@@ -67,55 +33,21 @@ export namespace IAutoBeInterfaceGroupApplication {
       | IAutoBePreliminaryGetPreviousInterfaceOperations;
   }
 
-  /**
-   * Request to generate API endpoint groups.
-   *
-   * Executes group generation to organize API endpoints based on database
-   * schema structure.
-   */
+  /** Request to generate API endpoint groups. */
   export interface IComplete {
-    /**
-     * Type discriminator for the request.
-     *
-     * Determines which action to perform: preliminary data retrieval or actual
-     * task execution. Value "complete" indicates this is the final task
-     * execution request.
-     */
+    /** Type discriminator for completion request. */
     type: "complete";
 
-    /**
-     * Analysis of the database schema structure and grouping needs.
-     *
-     * Before designing groups, analyze what you know:
-     *
-     * - What namespaces, prefixes, or organizational patterns exist in the DB?
-     * - Which entities naturally belong together based on table relationships?
-     * - What business domains or functional areas can be identified?
-     * - Are there existing interface operations that suggest grouping patterns?
-     */
+    /** Analysis of the database schema structure and grouping needs. */
     analysis: string;
 
-    /**
-     * Rationale for the group design decisions.
-     *
-     * Explain why you organized groups this way:
-     *
-     * - Why did you create each group?
-     * - What entities are included in each group and why?
-     * - How does this grouping reflect the database schema structure?
-     * - What coverage does this provide for all requirements?
-     */
+    /** Rationale for the group design decisions. */
     rationale: string;
 
     /**
-     * Array of API endpoint groups for organizing development.
-     *
-     * DO: Derive groups from database 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. DO: Organize groups around existing database
-     * schema structure. DO: Provide complete coverage of all entities and
-     * requirements without overlap.
+     * Array of API endpoint groups. Derive from database schema organization
+     * (namespaces, table prefixes), not arbitrary business domains. Provide
+     * complete coverage without overlap.
      */
     groups: AutoBeInterfaceGroup[] & tags.MinItems<1>;
   }