@autobe/agent 0.22.1 → 0.23.1

package/src/orchestrate/test/structures/IAutoBeTestCorrectApplication.ts

@@ -1,3 +1,13 @@
+// import { tags } from "typia";
+
+// export interface ICheck {
+//   /** The title or description of the validation rule/check item */
+//   title: string;
+
+//   /** The validation state (true: passed/satisfied, false: failed/violated) */
+//   state: boolean;
+// }
+
 export interface IAutoBeTestCorrectApplication {
   /**
    * Main entry point for AI Function Call - analyzes compilation errors and
@@ -81,6 +91,161 @@ export namespace IAutoBeTestCorrectApplication {
     revise: IReviseProps;
   }
 
+  // /**
+  //  * Comprehensive compilation error analysis and correction planning
+  //  * properties.
+  //  *
+  //  * This interface structures the AI's deep thinking process during error
+  //  * correction, requiring individual analysis of each compilation error along
+  //  * with an overall strategy assessment. The AI must meticulously examine every
+  //  * error message, understand its root cause, and propose targeted solutions
+  //  * while maintaining a holistic view of the correction process.
+  //  *
+  //  * The structure enforces granular error analysis while ensuring the AI
+  //  * maintains awareness of overarching patterns and systemic issues that may
+  //  * require broader strategic changes like scenario rewrites or architectural
+  //  * adjustments.
+  //  */
+  // export interface IThinkProps {
+  //   /**
+  //    * Individual analyses for each compilation diagnostic.
+  //    *
+  //    * Contains detailed examination of every compilation error encountered,
+  //    * with specific analysis and targeted solutions. Each entry represents a
+  //    * single compilation diagnostic that must be resolved. The AI must read the
+  //    * IAutoBeTypeScriptCompileResult.IDiagnostic objects, interpret their
+  //    * content, and provide human-readable summaries along with precise fixes.
+  //    *
+  //    * This granular approach ensures no error is overlooked and each issue
+  //    * receives appropriate attention and resolution strategy.
+  //    */
+  //   analyses: IDiagnosticAnalysis[] & tags.MinItems<1>;
+
+  //   /**
+  //    * Overall assessment of compilation issues and correction strategies.
+  //    *
+  //    * Synthesizes patterns across all individual errors to identify systemic
+  //    * issues and overarching correction strategies. This includes verification
+  //    * of TEST_WRITE.md and TEST_CORRECT.md compliance, assessment of whether
+  //    * scenario rewrites are needed, identification of common error patterns,
+  //    * and documentation of broad strategic decisions.
+  //    *
+  //    * Must address: type safety compliance, async/await patterns, scenario
+  //    * adaptation requirements, and overall code quality considerations that
+  //    * span multiple errors.
+  //    */
+  //   overall: string;
+  // }
+
+  // /**
+  //  * Detailed analysis structure for individual compilation diagnostics.
+  //  *
+  //  * Represents the AI's systematic approach to understanding and resolving each
+  //  * compilation diagnostic. Each diagnostic must be thoroughly analyzed to
+  //  * understand its root cause, with a specific solution that addresses the
+  //  * exact issue while maintaining type safety and code quality.
+  //  */
+  // export interface IDiagnosticAnalysis {
+  //   /**
+  //    * AI-generated summary of the compilation diagnostic.
+  //    *
+  //    * The AI must analyze the `IAutoBeTypeScriptCompileResult.IDiagnostic`
+  //    * object and provide a clear, concise summary of the error. This should
+  //    * include the error message, file location, line/column position, and error
+  //    * code in a human-readable format. The AI interprets and restructures the
+  //    * raw diagnostic data to present it in a more understandable way.
+  //    *
+  //    * **IMPORTANT**: The AI should not copy the raw diagnostic object. Instead,
+  //    * it must read and understand the diagnostic details, then compose a clear
+  //    * string description that captures all essential information about the
+  //    * error.
+  //    */
+  //   diagnostic: string;
+
+  //   /**
+  //    * Root cause analysis of why this compilation error occurred.
+  //    *
+  //    * **🚨 CRITICAL FIRST CHECK: Is this caused by INTENTIONAL TYPE ERROR TESTING? 🚨**
+  //    * - Look for `as any` usage in the error location
+  //    * - Check if code is intentionally sending wrong types to test type validation
+  //    * - Check if code is testing missing required fields
+  //    * - **IF YES → Root cause: "Prohibited type error testing code that must be DELETED"**
+  //    *
+  //    * **⚠️ THINK BEYOND THE DIAGNOSTIC LINE - EXPAND YOUR INVESTIGATION ⚠️**
+  //    * - Do NOT focus only on the error line - it might be just a symptom
+  //    * - The real cause might be ABOVE the error location in earlier code
+  //    * - The test scenario itself might be fundamentally flawed or impossible
+  //    * - Consider if the scenario is requesting non-existent APIs or prohibited actions
+  //    * - Example: Error on line 50 might be caused by wrong type assignment on line 20
+  //    * - Example: API call fails because the scenario describes unimplemented functionality
+  //    *
+  //    * AI must examine the error message carefully and identify the specific
+  //    * reason for failure. This includes understanding whether it's a missing
+  //    * property, type mismatch, nullable/undefined issue, incorrect API usage,
+  //    * intentional type error testing, flawed scenario, or other TypeScript
+  //    * violations. The analysis should be precise and fact-based, but also
+  //    * consider the broader context and causal relationships.
+  //    *
+  //    * **MANDATORY**: The AI must thoroughly review ALL sections of
+  //    * TEST_CORRECT.md and apply relevant error patterns and analysis guidelines
+  //    * from sections 4.1-4.16 to ensure accurate diagnosis.
+  //    *
+  //    * Example: "Property 'code' is missing because the object literal lacks
+  //    * this required field from ICommunityPlatformCommunity.ICreate interface"
+  //    *
+  //    * Example: "Type error caused by intentional wrong type test using 'as any'
+  //    * - prohibited pattern that must be deleted"
+  //    *
+  //    * Example: "API endpoint doesn't exist - scenario requests unimplemented
+  //    * functionality that cannot be tested"
+  //    */
+  //   analysis: string;
+
+  //   /**
+  //    * Specific solution to resolve this compilation error.
+  //    *
+  //    * **🚨 IF ROOT CAUSE IS TYPE ERROR TESTING → Solution: "DELETE entire test block" 🚨**
+  //    * **🚨 IF PROBLEM IS UNRECOVERABLE → Solution: "DELETE the problematic section" 🚨**
+  //    * - NEVER try to "fix" intentional type error tests - DELETE them
+  //    * - NEVER violate type safety to force a fix - DELETE instead
+  //    * - Tests using `as any` to send wrong types must be DELETED
+  //    * - Tests checking type validation must be DELETED
+  //    * - Unrecoverable compilation errors should result in DELETION
+  //    *
+  //    * **THREE SOLUTION TYPES:**
+  //    * 1. **FIX**: Correct the error while maintaining functionality
+  //    * 2. **DELETE**: Remove prohibited or unrecoverable code entirely
+  //    * 3. **REWRITE**: Restructure if the scenario itself is fundamentally flawed
+  //    *
+  //    * Detailed correction strategy that addresses the exact issue identified in
+  //    * the analysis. Solutions must be actionable, type-safe, and compliant with
+  //    * all project guidelines. For nullable/undefined errors with typia tags,
+  //    * immediately apply typia.assert(value!) pattern. For missing properties,
+  //    * specify what will be added and how.
+  //    *
+  //    * **CRITICAL**: The AI must thoroughly review BOTH TEST_WRITE.md and
+  //    * TEST_CORRECT.md before proposing solutions. All prohibitions from
+  //    * TEST_WRITE.md must be strictly respected (no type bypasses, proper
+  //    * async/await usage, etc.), and correction patterns from TEST_CORRECT.md
+  //    * sections 4.1-4.16 must be properly applied.
+  //    *
+  //    * **DELETION IS A VALID SOLUTION** when:
+  //    * - Code violates absolute prohibitions
+  //    * - Fixing would require type safety violations
+  //    * - The scenario describes impossible functionality
+  //    * - Multiple fix attempts have failed
+  //    *
+  //    * Example: "Add missing 'code' property using typia.random<string>() to
+  //    * generate a valid string value that satisfies the interface requirement"
+  //    *
+  //    * Example: "DELETE this entire test - it's testing type errors with 'as any'"
+  //    *
+  //    * Example: "DELETE this section - API endpoint doesn't exist and cannot be
+  //    * tested without violating type safety"
+  //    */
+  //   solution: string;
+  // }
+
   /**
    * Revision properties for the final review and implementation phases.
    *
@@ -88,6 +253,74 @@ export namespace IAutoBeTestCorrectApplication {
    * workflow, ensuring systematic review and production-ready code delivery.
    */
   export interface IReviseProps {
+    // /**
+    //  * Dual-document compliance validation for TEST_WRITE.md and
+    //  * TEST_CORRECT.md.
+    //  *
+    //  * This property tracks whether each section from BOTH TEST_WRITE.md and
+    //  * TEST_CORRECT.md guidelines has been properly followed. Since the correct
+    //  * agent must ensure compliance with both documents, keys should include
+    //  * sections from both prompt files.
+    //  *
+    //  * Each ICheck item should have:
+    //  *
+    //  * - Title: Prefixed with source document for clarity ("TEST_WRITE: " or
+    //  *   "TEST_CORRECT: ")
+    //  * - State: Compliance status (true if followed, false if violated)
+    //  *
+    //  * Note: Section identifiers may evolve as documentation updates, so
+    //  * implementations should be flexible in handling different key formats.
+    //  *
+    //  * Example:
+    //  *
+    //  * ```typescript
+    //  * rules: [
+    //  *   { title: "TEST_WRITE: 1. Role and Responsibility", state: true },
+    //  *   { title: "TEST_WRITE: 3.1. Import Management", state: true },
+    //  *   {
+    //  *     title: "TEST_CORRECT: 4.1. Missing Properties Pattern",
+    //  *     state: true,
+    //  *   },
+    //  *   {
+    //  *     title: "TEST_CORRECT: 4.2. Type Mismatch Pattern",
+    //  *     state: false,
+    //  *   },
+    //  *   // ... other sections from both documents
+    //  * ];
+    //  * ```
+    //  */
+    // rules: ICheck[] & tags.MinItems<1>;
+
+    // /**
+    //  * Combined quality checklist validation from both prompt documents.
+    //  *
+    //  * This property captures the compliance status for checklist items from
+    //  * BOTH TEST_WRITE.md (Section 5: Final Checklist) and TEST_CORRECT.md
+    //  * (Section 5: Final Review Checklist). The correct agent must validate
+    //  * against both checklists to ensure comprehensive quality control.
+    //  *
+    //  * Each ICheck item should have:
+    //  *
+    //  * - Title: Checklist item as described in the documents
+    //  * - State: Whether the criterion has been satisfied
+    //  *
+    //  * Note: Checklist items may be updated over time, so implementations should
+    //  * adapt to documentation changes while maintaining the validation purpose.
+    //  *
+    //  * Example:
+    //  *
+    //  * ```typescript
+    //  * checkList: [
+    //  *   { title: "No compilation errors", state: true },
+    //  *   { title: "Proper async/await usage", state: true },
+    //  *   { title: "All typia tags preserved", state: true },
+    //  *   { title: "No type bypasses or workarounds", state: false },
+    //  *   // ... other checklist items from both documents
+    //  * ];
+    //  * ```
+    //  */
+    // checkList: ICheck[] & tags.MinItems<1>;
+
     /**
      * Step 3: Code review and correction validation.
      *

package/src/orchestrate/test/structures/IAutoBeTestCorrectInvalidRequestApplication.ts

@@ -0,0 +1,146 @@
+export interface IAutoBeTestCorrectInvalidRequestApplication {
+  /**
+   * Rewrite function to remove code containing invalid type API requests.
+   *
+   * This function is called when the agent detects code that attempts to send
+   * API requests with deliberately wrong types, causing TypeScript compilation
+   * errors. The agent will remove the problematic code sections while
+   * preserving valid test code.
+   *
+   * Common patterns that trigger this function:
+   *
+   * - TestValidator.error calls testing type violations
+   * - Missing required fields with type assertions
+   * - Wrong type assignments with satisfies operator
+   * - Nested type violations in complex objects
+   * - Partial type testing with invalid structures
+   *
+   * The rationale for deletion:
+   *
+   * - Type validation is the server's responsibility, not E2E tests
+   * - TypeScript compiler should enforce type safety at compile time
+   * - Invalid type testing breaks the entire test suite compilation
+   * - E2E tests should focus on business logic, not type system violations
+   *
+   * @param props - The analysis and correction properties
+   * @param props.think - Analysis of what specific invalid request pattern is
+   *   causing the error
+   * @param props.draft - Initial corrected code with problematic sections
+   *   completely removed
+   * @param props.revise - Review process and final cleaned code
+   */
+  rewrite(props: IAutoBeTestCorrectInvalidRequestApplication.IProps): void;
+
+  /**
+   * Reject function when no invalid type API requests are detected.
+   *
+   * This function is called when the compilation error is not related to
+   * invalid API request types, indicating the agent should not intervene.
+   *
+   * Common scenarios for rejection:
+   *
+   * - Syntax errors unrelated to type violations
+   * - Legitimate type mismatches that need fixing (not deletion)
+   * - Framework-specific compilation issues
+   * - Configuration or environment problems
+   *
+   * When called, this indicates that another specialized agent should handle
+   * the compilation error, as it's outside this agent's domain.
+   */
+  reject(): void;
+}
+
+export namespace IAutoBeTestCorrectInvalidRequestApplication {
+  /**
+   * Properties for the rewrite function containing the analysis and correction
+   * workflow.
+   *
+   * This follows a three-phase approach: think → draft → revise, ensuring
+   * systematic removal of invalid type testing code while maintaining the
+   * integrity of valid E2E tests.
+   */
+  export interface IProps {
+    /**
+     * Initial analysis phase.
+     *
+     * Contains the agent's analysis of what specific invalid request pattern
+     * was found in the code and how it's causing the compilation error. This
+     * should identify:
+     *
+     * - The exact pattern (as any, satisfies, TestValidator.error, etc.)
+     * - Line numbers and locations of violations
+     * - The TypeScript error codes being triggered
+     * - Why this constitutes invalid type testing
+     *
+     * Example: "Detected TestValidator.error() call at line 45 with 'as any'
+     * casting on request body containing deliberately wrong types (number for
+     * email field). This is causing TS2345 compilation error."
+     */
+    think: string;
+
+    /**
+     * Draft correction phase.
+     *
+     * The initial corrected code with the problematic API request sections
+     * completely removed while preserving all valid test code.
+     *
+     * Rules for drafting:
+     *
+     * - Remove entire test functions containing type violations
+     * - Do not comment out code - delete it completely
+     * - Preserve test suite structure and valid tests
+     * - Maintain proper indentation and formatting
+     * - Keep imports that are still needed by remaining code
+     */
+    draft: string;
+
+    /**
+     * Review and finalization phase.
+     *
+     * Contains the review of changes made and the final cleaned code that
+     * should compile without the invalid API request errors. This ensures the
+     * correction is complete and accurate.
+     */
+    revise: IReviseProps;
+  }
+
+  /**
+   * Properties for the revision phase of the correction process.
+   *
+   * This phase ensures that the removal was complete and the remaining code is
+   * valid and compilable.
+   */
+  export interface IReviseProps {
+    /**
+     * Review of the changes made.
+     *
+     * Brief explanation of what invalid API request code was removed and
+     * verification that valid test code was preserved. Should confirm:
+     *
+     * - Which patterns were found and removed
+     * - Line ranges that were deleted
+     * - Verification that valid tests remain intact
+     * - Confirmation that no partial fixes were applied
+     *
+     * Example: "Removed lines 43-52 containing TestValidator.error with invalid
+     * type casting. Verified remaining tests are valid and unaffected."
+     */
+    review: string;
+
+    /**
+     * Final corrected code.
+     *
+     * The complete, cleaned test code with all invalid API request sections
+     * removed, ready for compilation.
+     *
+     * This code must:
+     *
+     * - Compile without TypeScript errors
+     * - Contain only valid business logic tests
+     * - Have no `as any` or similar type violations
+     * - Maintain the original file structure
+     * - Be production-ready E2E test code
+     */
+    final: string;
+  }
+}

package/src/orchestrate/test/structures/IAutoBeTestScenarioApplication.ts

@@ -1,4 +1,4 @@
-import { AutoBeOpenApi, SnakePattern } from "@autobe/interface";
+import { AutoBeOpenApi } from "@autobe/interface";
 import { tags } from "typia";
 
 export interface IAutoBeTestScenarioApplication {
@@ -128,7 +128,7 @@ export namespace IAutoBeTestScenarioApplication {
      * - Don't imply dependency on other API operations
      * - Represent complete user interactions
      */
-    functionName: string & SnakePattern;
+    functionName: string;
 
     /**
      * A list of other API endpoints that this scenario logically depends on.

package/src/orchestrate/test/structures/IAutoBeTestWriteApplication.ts

@@ -1,4 +1,4 @@
-import { SnakePattern } from "@autobe/interface";
+// import { tags } from "typia";
 
 export interface IAutoBeTestWriteApplication {
   /**
@@ -41,7 +41,7 @@ export namespace IAutoBeTestWriteApplication {
      * Workflow: Scenario analysis → Domain identification → Test organization
      * structure
      */
-    domain: string & SnakePattern;
+    domain: string;
 
     /**
      * Step 3: Initial TypeScript E2E test code implementation.
@@ -64,9 +64,9 @@ export namespace IAutoBeTestWriteApplication {
      * Steps 4-5: Code review and final refinement process.
      *
      * Contains the iterative improvement workflow that transforms the initial
-     * draft into production-ready test code. This two-phase process ensures
-     * systematic quality enhancement through comprehensive review followed by
-     * targeted refinement based on identified issues.
+     * draft into production-ready test code. The review phase identifies issues
+     * to fix or code to delete, followed by the final phase that produces
+     * the polished, production-ready test implementation.
      *
      * Workflow: Draft → Review analysis → Final implementation
      */
@@ -74,10 +74,60 @@ export namespace IAutoBeTestWriteApplication {
   }
 
   export interface IReviseProps {
+    // /**
+    //  * Test implementation rules compliance validation.
+    //  *
+    //  * This property tracks whether each section of the TEST_WRITE.md guidelines
+    //  * has been properly followed. Each array element represents a section from
+    //  * the documentation with its title and compliance status.
+    //  *
+    //  * Note: The specific section titles may evolve as documentation updates, so
+    //  * implementations should be flexible in handling different titles.
+    //  *
+    //  * Example:
+    //  *
+    //  * ```typescript
+    //  * rules: [
+    //  *   { title: "1. Role and Responsibility", state: true },
+    //  *   { title: "2. Input Materials Provided", state: true },
+    //  *   { title: "3. Code Generation Requirements", state: false },
+    //  *   // ... other sections
+    //  * ];
+    //  * ```
+    //  */
+    // rules: ICheck[] & tags.MinItems<1>;
+
+    // /**
+    //  * Final quality checklist validation results.
+    //  *
+    //  * This property captures the compliance status for each item in the Final
+    //  * Checklist (Section 5) from TEST_WRITE.md. Each array element represents a
+    //  * checklist item with its description and validation result.
+    //  *
+    //  * Note: Checklist items may be updated over time, so implementations should
+    //  * adapt to documentation changes while maintaining the validation purpose.
+    //  *
+    //  * Example:
+    //  *
+    //  * ```typescript
+    //  * checkList: [
+    //  *   { title: "NO additional import statements", state: true },
+    //  *   { title: "NO wrong type data in requests", state: true },
+    //  *   { title: "EVERY api.functional.* call has await", state: false },
+    //  *   // ... other checklist items
+    //  * ];
+    //  * ```
+    //  */
+    // checkList: ICheck[] & tags.MinItems<1>;
+
     /**
      * Step 4: Code review and quality assessment.
      *
-     * AI performs a thorough review of the draft implementation, examining:
+     * **🚨 TWO TYPES OF REVISIONS: FIX AND DELETE 🚨**
+     *
+     * AI performs a thorough review of the draft implementation for:
+     *
+     * **1. FIX - Improve existing code:**
      *
      * **Compilation & Syntax:**
      *
@@ -99,18 +149,29 @@ export namespace IAutoBeTestWriteApplication {
      * - Edge case handling and error condition testing
      * - Proper data dependencies and cleanup procedures
      *
+     * **2. DELETE - Remove prohibited code entirely:**
+     *
+     * **🚨 TYPE ERROR TESTING - DELETE IMMEDIATELY 🚨**
+     *
+     * - DELETE any code using `as any` to send wrong types
+     * - DELETE any intentional type mismatches for "testing"
+     * - DELETE any missing required fields testing
+     * - DELETE tests that contradict compilation requirements
+     *
      * **Code Quality & Security:**
      *
-     * - Type safety violations (any, @ts-ignore, etc.)
-     * - Variable naming and code organization
+     * - Type safety violations (any, @ts-ignore, etc.) - DELETE if found
+     * - Variable naming and code organization - FIX if needed
      * - Performance considerations and resource management
      * - Security best practices in test data generation
      *
-     * Workflow: Draft code → Systematic analysis → Specific improvement
-     * recommendations
+     * Workflow: Draft code → Systematic analysis → FIX or DELETE decisions
      *
      * The review must identify concrete issues with line-by-line feedback and
-     * provide actionable solutions for each problem discovered.
+     * provide actionable solutions (FIX) or deletion instructions (DELETE) for
+     * each problem discovered.
+     *
+     * **DO NOT FIX TYPE ERROR TESTS - DELETE THEM COMPLETELY**
      */
     review: string;
 
@@ -119,15 +180,49 @@ export namespace IAutoBeTestWriteApplication {
      *
      * AI produces the final, polished version of the test code incorporating
      * all review feedback. This code represents the completed test
-     * implementation, ready for production deployment. All identified issues
-     * must be resolved, and the code must meet the highest quality standards.
+     * implementation, ready for production deployment.
+     *
+     * **🚨 CRITICAL: APPLY ALL FIXES AND DELETIONS FROM REVIEW 🚨**
+     *
+     * - FIX all correctable issues identified in review
+     * - DELETE all prohibited code identified in review
+     * - If review found type error tests, they MUST be deleted in final
+     * - If review found code to DELETE, final MUST be different from draft
      *
-     * Workflow: Review feedback → Code refinement → Production-ready
-     * implementation
+     * All identified issues must be resolved, and the code must meet the
+     * highest quality standards.
+     *
+     * Workflow: Review feedback → Apply FIXES → Apply DELETIONS →
+     * Production-ready implementation
      *
      * This is the ultimate deliverable that will be used in the actual test
      * suite.
      */
     final: string;
   }
+
+  // /**
+  //  * Check validation item structure.
+  //  *
+  //  * Represents a validation check with its title and compliance state. Used for
+  //  * both rules validation and final checklist validation.
+  //  */
+  // export interface ICheck {
+  //   /**
+  //    * The title or description of the check.
+  //    *
+  //    * For rules: Section identifiers from TEST_WRITE.md (e.g., "1. Role and
+  //    * Responsibility") For checklist: Checklist item descriptions (e.g., "No
+  //    * compilation errors")
+  //    */
+  //   title: string;
+
+  //   /**
+  //    * The validation state of this check.
+  //    *
+  //    * - True: The requirement has been satisfied
+  //    * - False: The requirement has been violated or not met
+  //    */
+  //   state: boolean;
+  // }
 }

package/src/orchestrate/test/utils/getReferenceIds.ts

@@ -7,7 +7,7 @@ export const getReferenceIds = (props: {
 }): string[] => {
   const result: Set<string> = new Set();
   const emplace = (key: string) => {
-    if (key.endsWith("_id")) result.add(key);
+    if (key.endsWith("_id") || key.endsWith("Id")) result.add(key);
   };
 
   props.operation.parameters.forEach((p) => emplace(p.name));

package/src/structures/IAutoBeConfig.ts

@@ -64,6 +64,8 @@ export interface IAutoBeConfig {
    */
   timezone?: string;
 
+  timeout?: number;
+
   /**
    * Backoff strategy for retrying failed operations.
    *

package/src/utils/AutoBeTimeoutError.ts

@@ -0,0 +1,13 @@
+export class AutoBeTimeoutError extends Error {
+  public constructor(message: string) {
+    super(message);
+
+    const proto = new.target.prototype;
+    if (Object.setPrototypeOf) Object.setPrototypeOf(this, proto);
+    else (this as any).__proto__ = proto;
+  }
+
+  public get name(): string {
+    return this.constructor.name;
+  }
+}