@autobe/agent 0.20.0 → 0.22.0

package/lib/orchestrate/realize/structures/IAutoBeRealizeCorrectApplication.d.ts

@@ -1,79 +1,39 @@
-import { IAutoBeRealizeWriteApplication } from "./IAutoBeRealizeWriteApplication";
 export interface IAutoBeRealizeCorrectApplication {
+    /**
+     * Reviews and corrects TypeScript compilation errors.
+     *
+     * Fixes TypeScript compilation errors while preserving original business
+     * logic, applying minimal intervention principle.
+     *
+     * @param props Properties containing the multi-phase error correction process
+     */
     review: (props: IAutoBeRealizeCorrectApplication.IProps) => void;
 }
 export declare namespace IAutoBeRealizeCorrectApplication {
-    interface IProps extends IAutoBeRealizeWriteApplication.IProps {
-        /**
-         * Compilation Error Analysis and Resolution Strategy
-         *
-         * This field contains a detailed analysis of TypeScript compilation errors
-         * that occurred during the previous compilation attempt, along with
-         * specific strategies to resolve each error.
-         *
-         * The analysis MUST include:
-         *
-         * 📊 ERROR BREAKDOWN:
-         *
-         * - List of all TypeScript error codes encountered (e.g., TS2339, TS2345)
-         * - Exact error messages and the lines/files where they occurred
-         * - Categorization of errors by type (type mismatch, missing property, etc.)
-         *
-         * 🔍 ROOT CAUSE ANALYSIS:
-         *
-         * - Why each error occurred (e.g., incorrect type assumptions, missing
-         *   fields)
-         * - Relationship between errors (e.g., cascading errors from a single issue)
-         * - Common patterns identified across multiple errors
-         *
-         * 🛠 RESOLUTION STRATEGY:
-         *
-         * - Specific fixes for each error type
-         * - Priority order for addressing errors (fix critical errors first)
-         * - Alternative approaches if the direct fix is not possible
-         *
-         * 📝 SCHEMA VERIFICATION:
-         *
-         * - Re-verification of Prisma schema fields actually available
-         * - Identification of assumed fields that don't exist
-         * - Correct field types and relationships
-         *
-         * ⚠️ COMMON ERROR PATTERNS TO CHECK:
-         *
-         * - Using non-existent fields (e.g., deleted_at, created_by)
-         * - Type mismatches in Prisma operations
-         * - Incorrect date handling (using Date instead of string)
-         * - Missing required fields in create/update operations
-         * - Incorrect relation handling in nested operations
-         *
-         * 🎯 CORRECTION APPROACH:
-         *
-         * - Remove references to non-existent fields
-         * - Fix type conversions (especially dates with toISOStringSafe())
-         * - Simplify complex nested operations into separate queries
-         * - Add missing required fields
-         * - Use correct Prisma input types
-         *
-         * Example structure:
-         *
-         *     Errors Found:
-         *     1. TS2339: Property 'deleted_at' does not exist on type 'User'
-         *        - Cause: Field assumed but not in schema
-         *        - Fix: Remove all deleted_at references
-         *
-         *     2. TS2345: Type 'Date' is not assignable to type 'string'
-         *        - Cause: Direct Date assignment without conversion
-         *        - Fix: Use toISOStringSafe() for all date values
-         *
-         *     Resolution Plan:
-         *     1. First, remove all non-existent field references
-         *     2. Then, fix all date type conversions
-         *     3. Finally, adjust Prisma query structures
-         *
-         * This analysis ensures the review process addresses all compilation errors
-         * systematically and produces error-free code in the corrected
-         * implementation.
-         */
-        errorAnalysis: string;
+    /**
+     * Properties for error correction following Chain of Thinking (CoT).
+     *
+     * All phases are wrapped in a `revise` object for systematic error
+     * resolution.
+     */
+    interface IProps {
+        /** Revision process containing all error correction phases. */
+        revise: IRevise;
+    }
+    interface IRevise {
+        /** Step 1: Compilation error analysis and resolution strategy. */
+        errorAnalysis?: string;
+        /** Step 2: Provider function implementation plan. */
+        plan?: string;
+        /** Step 3: Relevant Prisma schema definitions. */
+        prismaSchemas?: string;
+        /** Step 4: Initial draft without using native Date type. */
+        draftWithoutDateType?: string;
+        /** Step 5: Refined version with improved completeness. */
+        review?: string;
+        /** Step 6: Corrected implementation after compiler feedback. */
+        withCompilerFeedback?: string;
+        /** Step 7: Final complete TypeScript function implementation. */
+        implementationCode: string;
     }
 }

package/lib/orchestrate/realize/structures/IAutoBeRealizeFunctionFailure.d.ts

@@ -0,0 +1,5 @@
+import { AutoBeRealizeFunction, IAutoBeTypeScriptCompileResult } from "@autobe/interface";
+export interface IAutoBeRealizeFunctionFailure {
+    function: AutoBeRealizeFunction;
+    diagnostics: IAutoBeTypeScriptCompileResult.IDiagnostic[];
+}

package/lib/orchestrate/realize/structures/IAutoBeRealizeScenarioResult.d.ts

@@ -0,0 +1,36 @@
+import { AutoBeOpenApi, AutoBeRealizeAuthorization, AutoBeTestFile } from "@autobe/interface";
+export interface IAutoBeRealizeScenarioResult {
+    /** The OpenAPI operation to be realized. */
+    operation: AutoBeOpenApi.IOperation;
+    /**
+     * The name of the function to be generated.
+     *
+     * Derived from the Swagger path and method. The function name must be
+     * written in snake_case. It serves as the entry point in both code
+     * generation and test code.
+     *
+     * Once the function is generated, the function name and file name will be
+     * the same. The generated file will be located at
+     * `src/providers/${function_name}.ts`.
+     */
+    functionName: string;
+    /** For example, `src/providers/${function_name}.ts`. */
+    location: string;
+    /**
+     * List of scenario descriptions for test code generation.
+     *
+     * Each scenario describes the expected behavior of the function under
+     * certain conditions. Used as a basis for TDD-style automated test
+     * generation.
+     */
+    testFiles: AutoBeTestFile[];
+    /**
+     * Optional decorator event for customizing code generation behavior.
+     *
+     * Provides additional metadata or instructions that can modify how the
+     * function implementation is generated. Can include custom annotations,
+     * middleware configurations, or special handling directives that affect the
+     * final code output.
+     */
+    decoratorEvent?: AutoBeRealizeAuthorization;
+}

package/lib/orchestrate/realize/structures/IAutoBeRealizeWriteApplication.d.ts

@@ -1,10 +1,34 @@
 export interface IAutoBeRealizeWriteApplication {
+    /**
+     * Generates provider function implementation through multi-phase development.
+     *
+     * This method implements a systematic approach to generate NestJS provider
+     * functions that handle business logic for API operations. It follows a
+     * schema-first approach with multiple refinement phases to ensure type-safe,
+     * error-free code generation.
+     *
+     * The generation process includes:
+     * 1. Strategic planning based on Prisma schema analysis
+     * 2. Initial draft without Date type usage
+     * 3. Review and refinement for completeness
+     * 4. Compiler feedback integration if errors detected
+     * 5. Final implementation with all validations and type safety
+     *
+     * @param next Properties containing the multi-phase implementation plan and code
+     */
     coding: (next: IAutoBeRealizeWriteApplication.IProps) => void;
 }
 export declare namespace IAutoBeRealizeWriteApplication {
+    /**
+     * Properties for the Realize Write Application following Chain of Thinking (CoT).
+     *
+     * Each field represents a distinct phase in the reasoning and implementation process,
+     * building upon the previous step to create a complete, error-free implementation.
+     * This structured approach ensures clarity, debuggability, and systematic thinking.
+     */
     interface IProps {
         /**
-         * Step 1.
+         * Step 1 - Planning Phase (CoT: Initial Reasoning)
          *
          * 🧠 Provider Function Implementation Plan
          *
@@ -17,13 +41,18 @@ export declare namespace IAutoBeRealizeWriteApplication {
          * 📋 STEP 1 - PRISMA SCHEMA VERIFICATION:
          *
          * DO:
+         *
          * - Examine the actual Prisma schema model definition
          * - List EVERY field that exists in the model with exact types
          * - Explicitly note fields that DO NOT exist
+         * - Verify database compatibility (PostgreSQL AND SQLite)
          *
          * DO NOT:
+         *
          * - Assume common fields exist without verification
-         * - Use fields like deleted_at, created_by, updated_by, is_deleted, is_active without checking
+         * - Use fields like deleted_at, created_by, updated_by, is_deleted, is_active
+         *   without checking
+         * - Use PostgreSQL-specific features like mode: "insensitive"
          *
          * 📋 STEP 2 - FIELD INVENTORY:
          *
@@ -131,7 +160,7 @@ export declare namespace IAutoBeRealizeWriteApplication {
          */
         plan: string;
         /**
-         * Step 2.
+         * Step 2 - Schema Definition (CoT: Context Establishment)
          *
          * The Prisma schema string that will be used to validate the implementation
          * logic in this file.
@@ -152,7 +181,7 @@ export declare namespace IAutoBeRealizeWriteApplication {
          */
         prisma_schemas: string;
         /**
-         * Step 3.
+         * Step 3 - Initial Draft (CoT: First Implementation Attempt)
          *
          * Draft WITHOUT using native Date type.
          *
@@ -171,10 +200,12 @@ export declare namespace IAutoBeRealizeWriteApplication {
          * Import rules:
          *
          * DO NOT:
+         *
          * - Add any new import statements manually
          * - Write import statements directly (this causes compile errors)
          *
-         * Note: All necessary imports are provided globally or by the system automatically.
+         * Note: All necessary imports are provided globally or by the system
+         * automatically.
          *
          * ✅ Requirements:
          *
@@ -186,7 +217,7 @@ export declare namespace IAutoBeRealizeWriteApplication {
          */
         draft_without_date_type: string;
         /**
-         * Step 4.
+         * Step 4 - Review and Refinement (CoT: Self-Reflection)
          *
          * A refined version of the draft with improved completeness.
          *
@@ -200,27 +231,11 @@ export declare namespace IAutoBeRealizeWriteApplication {
          * - Avoid unsafe `as` casts unless only for branding or literal narrowing.
          * - Use `toISOStringSafe()` for all date conversions (NOT `.toISOString()`).
          * - Ensure all object keys strictly conform to the expected type definitions.
+         * - NEVER use `mode: "insensitive"` in string operations (breaks SQLite).
          */
         review: string;
         /**
-         * 🛠 Phase 4-2: With compiler feedback (optional)
-         *
-         * A correction pass that applies fixes for compile-time errors that arose
-         * during the review stage (if any).
-         *
-         * ✅ Must:
-         *
-         * - Only include this field if TypeScript errors are detected in the Review
-         *   phase.
-         * - Resolve all TypeScript errors without using `as any`.
-         * - Provide safe brand casting only if required (e.g., `as string &
-         *   tags.Format<'uuid'>`).
-         * - If no TypeScript errors exist, this field MUST contain the text: "No
-         *   TypeScript errors detected - skipping this phase"
-         */
-        withCompilerFeedback: string;
-        /**
-         * Step 5.
+         * Step 5 - Complete Implementation (CoT: Final Synthesis)
          *
          * The complete and fully correct TypeScript function implementation.
          *
@@ -232,6 +247,7 @@ export declare namespace IAutoBeRealizeWriteApplication {
          * - Uses only allowed imports (e.g., from `../api/structures` and
          *   `MyGlobal.prisma`).
          * - NEVER creates intermediate variables for Prisma operations.
+         * - NEVER uses `mode: "insensitive"` (PostgreSQL-only, breaks SQLite).
          *
          * ⚠️ Fallback Behavior:
          *

package/lib/orchestrate/realize/utils/getRealizeWriteCodeTemplate.d.ts

@@ -0,0 +1,31 @@
+import { AutoBeOpenApi, AutoBeRealizeAuthorization } from "@autobe/interface";
+import { IAutoBeRealizeScenarioResult } from "../structures/IAutoBeRealizeScenarioResult";
+/**
+ * Generate a TypeScript function template for the Realize Agent to complete
+ *
+ * This utility creates a function skeleton with proper imports, parameters, and
+ * return type that the AI needs to implement. The template includes:
+ *
+ * - Import statements for required dependencies
+ * - Function signature with all parameters
+ * - Return type specification
+ *
+ * @example
+ *   // Returns a template like:
+ *   ```typescript
+ *   import { MyGlobal } from "../MyGlobal";
+ *   // ... other imports
+ *
+ *   async function post__users_create(
+ *     body: IUserCreateRequest
+ *   ): Promise<IUserResponse> {
+ *     ...
+ *   }
+ *   ```;
+ *
+ * @param scenario - The realize scenario containing function metadata
+ * @param operation - OpenAPI operation definition
+ * @param authorization - Authorization context if endpoint is authenticated
+ * @returns Complete TypeScript code template as a formatted string
+ */
+export declare function getRealizeWriteCodeTemplate(scenario: IAutoBeRealizeScenarioResult, operation: AutoBeOpenApi.IOperation, authorization: AutoBeRealizeAuthorization | null): string;

package/lib/orchestrate/realize/utils/getRealizeWriteDto.d.ts

@@ -0,0 +1,4 @@
+import { AutoBeOpenApi } from "@autobe/interface";
+import { ILlmSchema } from "@samchon/openapi";
+import { AutoBeContext } from "../../../context/AutoBeContext";
+export declare function getRealizeWriteDto<Model extends ILlmSchema.Model>(ctx: AutoBeContext<Model>, operation: AutoBeOpenApi.IOperation): Promise<Record<string, string>>;

package/lib/orchestrate/realize/utils/getRealizeWriteImportStatements.d.ts

@@ -0,0 +1,2 @@
+import { AutoBeOpenApi } from "@autobe/interface";
+export declare function getRealizeWriteImportStatements(operation: AutoBeOpenApi.IOperation): string[];

package/lib/orchestrate/realize/utils/getRealizeWriteInputType.d.ts

@@ -0,0 +1,30 @@
+import { AutoBeOpenApi, AutoBeRealizeAuthorization } from "@autobe/interface";
+/**
+ * Generate TypeScript type definition string for provider function props
+ *
+ * This utility creates the exact props interface that the Realize Agent's
+ * generated provider functions must accept. It combines:
+ *
+ * - Authentication context (user/admin/member from authorization)
+ * - URL path parameters (e.g., id, boardId, postId)
+ * - Request body type (if applicable)
+ *
+ * The output is injected into REALIZE_WRITE_ARTIFACT.md template to tell the AI
+ * exactly what parameter type the function should accept.
+ *
+ * @example
+ *   // For DELETE /posts/:id (authenticated)
+ *   // Returns: "props: { user: IUser; id: string & tags.Format<'uuid'>; }"
+ *
+ * @example
+ *   // For GET /public/info (no auth, no params)
+ *   // Returns: "// No props parameter needed - function should have no parameters"
+ *
+ * @param operation - OpenAPI operation definition containing parameters and
+ *   auth requirements
+ * @param authorization - Authorization context with user/role information (if
+ *   authenticated endpoint)
+ * @returns TypeScript interface string like "props: { user: IUser; id: string;
+ *   body: IRequest; }"
+ */
+export declare function getRealizeWriteInputType(operation: AutoBeOpenApi.IOperation, authorization: AutoBeRealizeAuthorization | null): string;

package/lib/orchestrate/realize/utils/replaceImportStatements.d.ts

@@ -1,4 +1,8 @@
+import { AutoBeOpenApi } from "@autobe/interface";
 import { ILlmSchema } from "@samchon/openapi";
 import { AutoBeContext } from "../../../context/AutoBeContext";
-import { IAutoBeTestScenarioArtifacts } from "../../test/structures/IAutoBeTestScenarioArtifacts";
-export declare function replaceImportStatements<Model extends ILlmSchema.Model>(ctx: AutoBeContext<Model>): (artifacts: IAutoBeTestScenarioArtifacts, code: string, decoratorType?: string) => Promise<string>;
+export declare function replaceImportStatements<Model extends ILlmSchema.Model>(ctx: AutoBeContext<Model>, props: {
+    operation: AutoBeOpenApi.IOperation;
+    code: string;
+    decoratorType?: string;
+}): Promise<string>;

package/lib/orchestrate/test/compile/getTestImportStatements.d.ts

@@ -0,0 +1,2 @@
+import { AutoBeOpenApi } from "@autobe/interface";
+export declare const getTestImportStatements: (document: AutoBeOpenApi.IDocument) => string;

package/lib/orchestrate/test/compile/getTestScenarioArtifacts.d.ts

@@ -2,4 +2,4 @@ import { AutoBeTestScenario } from "@autobe/interface";
 import { ILlmSchema } from "@samchon/openapi";
 import { AutoBeContext } from "../../../context/AutoBeContext";
 import { IAutoBeTestScenarioArtifacts } from "../structures/IAutoBeTestScenarioArtifacts";
-export declare function getTestScenarioArtifacts<Model extends ILlmSchema.Model>(ctx: AutoBeContext<Model>, scenario: Pick<AutoBeTestScenario, "endpoint" | "dependencies">): Promise<IAutoBeTestScenarioArtifacts>;
+export declare function getTestScenarioArtifacts<Model extends ILlmSchema.Model>(ctx: AutoBeContext<Model>, scenario: Pick<AutoBeTestScenario, "endpoint" | "dependencies" | "functionName">): Promise<IAutoBeTestScenarioArtifacts>;

package/lib/orchestrate/test/compile/getTestTemplateCode.d.ts

@@ -0,0 +1,2 @@
+import { AutoBeOpenApi, AutoBeTestScenario } from "@autobe/interface";
+export declare const getTestTemplateCode: (scenario: Pick<AutoBeTestScenario, "endpoint" | "dependencies" | "functionName">, document: AutoBeOpenApi.IDocument) => string;

package/lib/orchestrate/test/histories/transformTestCorrectHistories.d.ts

@@ -1,4 +1,6 @@
 import { IAgenticaHistoryJson } from "@agentica/core";
-import { IAutoBeTypeScriptCompileResult } from "@autobe/interface";
+import { ILlmSchema } from "@samchon/openapi";
+import { AutoBeContext } from "../../../context/AutoBeContext";
 import { IAutoBeTestFunction } from "../structures/IAutoBeTestFunction";
-export declare const transformTestCorrectHistories: (func: IAutoBeTestFunction, failure: IAutoBeTypeScriptCompileResult.IFailure) => Array<IAgenticaHistoryJson.IAssistantMessage | IAgenticaHistoryJson.ISystemMessage>;
+import { IAutoBeTestFunctionFailure } from "../structures/IAutoBeTestFunctionFailure";
+export declare const transformTestCorrectHistories: <Model extends ILlmSchema.Model>(ctx: AutoBeContext<Model>, func: IAutoBeTestFunction, failures: IAutoBeTestFunctionFailure[]) => Promise<Array<IAgenticaHistoryJson.IAssistantMessage | IAgenticaHistoryJson.ISystemMessage>>;

package/lib/orchestrate/test/histories/transformTestWriteHistories.d.ts

@@ -1,7 +1,9 @@
 import { IAgenticaHistoryJson } from "@agentica/core";
 import { AutoBeTestScenario } from "@autobe/interface";
+import { ILlmSchema } from "@samchon/openapi";
+import { AutoBeContext } from "../../../context/AutoBeContext";
 import { IAutoBeTestScenarioArtifacts } from "../structures/IAutoBeTestScenarioArtifacts";
-export declare function transformTestWriteHistories(scenario: AutoBeTestScenario, artifacts: IAutoBeTestScenarioArtifacts): Array<IAgenticaHistoryJson.ISystemMessage>;
+export declare function transformTestWriteHistories<Model extends ILlmSchema.Model>(ctx: AutoBeContext<Model>, scenario: AutoBeTestScenario, artifacts: IAutoBeTestScenarioArtifacts): Promise<Array<IAgenticaHistoryJson.ISystemMessage | IAgenticaHistoryJson.IAssistantMessage>>;
 export declare namespace transformTestWriteHistories {
     function structures(artifacts: IAutoBeTestScenarioArtifacts): string;
     function functional(artifacts: IAutoBeTestScenarioArtifacts): string;

package/lib/orchestrate/test/orchestrateTestCorrect.d.ts

@@ -2,4 +2,4 @@ import { AutoBeTestValidateEvent } from "@autobe/interface";
 import { ILlmSchema } from "@samchon/openapi";
 import { AutoBeContext } from "../../context/AutoBeContext";
 import { IAutoBeTestWriteResult } from "./structures/IAutoBeTestWriteResult";
-export declare const orchestrateTestCorrect: <Model extends ILlmSchema.Model>(ctx: AutoBeContext<Model>, writeResult: IAutoBeTestWriteResult[], life?: number) => Promise<AutoBeTestValidateEvent[]>;
+export declare const orchestrateTestCorrect: <Model extends ILlmSchema.Model>(ctx: AutoBeContext<Model>, writeResult: IAutoBeTestWriteResult[]) => Promise<AutoBeTestValidateEvent[]>;

package/lib/orchestrate/test/structures/IAutoBeTestCorrectApplication.d.ts

@@ -4,16 +4,14 @@ export interface IAutoBeTestCorrectApplication {
      * generates corrected E2E test code.
      *
      * The AI executes this function to perform the complete error correction
-     * workflow: error-free analysis → compilation error analysis → draft
-     * correction → code review → final corrected implementation. This multi-step
-     * process ensures systematic error resolution while preserving original test
-     * functionality and maintaining code quality.
+     * workflow: compilation error analysis → draft correction → code review →
+     * final corrected implementation. This multi-step process ensures systematic
+     * error resolution while preserving original test functionality and
+     * maintaining code quality.
      *
-     * The corrector first analyzes the scenario without considering compilation
-     * errors to understand the intended functionality, then incorporates
-     * compilation diagnostics to identify specific issues, and finally produces
-     * corrected code through iterative refinement with comprehensive review and
-     * validation.
+     * The corrector analyzes compilation diagnostics to identify specific issues,
+     * develops correction strategies, and produces corrected code through
+     * iterative refinement with comprehensive review and validation.
      *
      * @param props Complete specification for error correction workflow including
      *   analysis steps, draft implementation, review process, and final code
@@ -24,45 +22,29 @@ export interface IAutoBeTestCorrectApplication {
 export declare namespace IAutoBeTestCorrectApplication {
     interface IProps {
         /**
-         * Step 1: Initial analysis and understanding without compilation error
-         * context.
-         *
-         * AI analyzes the original test scenario, business requirements, and
-         * intended functionality without being influenced by compilation errors.
-         * This clean analysis establishes a clear understanding of what the test
-         * accomplishes, the expected business workflow, and the correct API
-         * integration patterns.
-         *
-         * This step ensures that error correction doesn't lose sight of the
-         * original test purpose and helps maintain the intended business logic
-         * while addressing technical compilation issues. The AI develops a
-         * comprehensive understanding of the test requirements before diving into
-         * error-specific details.
-         *
-         * Workflow: Scenario understanding → Business logic analysis → Intended
-         * functionality mapping
-         */
-        think_without_compile_error: string;
-        /**
-         * Step 2: Compilation error analysis and root cause identification.
+         * Step 1: Deep compilation error analysis and correction strategy.
+         *
+         * AI performs comprehensive analysis of compilation errors to develop
+         * targeted correction strategies. This step involves deep examination of
+         * error messages, identification of error patterns, understanding root
+         * causes, and planning systematic corrections.
          *
-         * AI re-analyzes the scenario and implementation with full awareness of
-         * compilation errors and diagnostic information. This step involves
-         * systematic examination of error messages, identification of error
-         * patterns, and understanding of how compilation issues relate to the
-         * intended functionality.
+         * The AI examines each compilation diagnostic to understand where the
+         * implementation diverged from correct TypeScript usage, identifies the
+         * business logic intent behind the failed code, and formulates strategies
+         * to fix errors while preserving the original test purpose. This analysis
+         * correlates error patterns with code structure to ensure corrections
+         * address root causes rather than symptoms.
          *
-         * The AI correlates compilation diagnostics with the original requirements
-         * to understand where the implementation diverged from correct TypeScript
-         * usage while maintaining the business logic intent. This analysis forms
-         * the foundation for targeted error correction strategies.
+         * This deep analysis forms the foundation for all subsequent correction
+         * efforts, ensuring a methodical approach to resolving compilation issues.
          *
          * Workflow: Error diagnostic analysis → Root cause identification →
-         * Correction strategy planning
+         * Correction strategy planning → Business logic preservation strategy
          */
-        think_again_with_compile_error: string;
+        think: string;
         /**
-         * Step 3: Draft corrected TypeScript E2E test code implementation.
+         * Step 2: Draft corrected TypeScript E2E test code implementation.
          *
          * AI generates the first corrected version of the test code based on error
          * analysis and correction strategies. This draft addresses all identified
@@ -82,7 +64,28 @@ export declare namespace IAutoBeTestCorrectApplication {
          */
         draft: string;
         /**
-         * Step 4: Code review and correction validation.
+         * Step 3-4: Review and finalization process.
+         *
+         * Encapsulates the review and final implementation phases into a single
+         * revision process. This structured approach ensures systematic validation
+         * and refinement of the corrected code through comprehensive review
+         * followed by production-ready implementation.
+         *
+         * The revision process maintains clear separation between review feedback
+         * and final deliverable while ensuring all corrections are properly
+         * validated and integrated.
+         */
+        revise: IReviseProps;
+    }
+    /**
+     * Revision properties for the final review and implementation phases.
+     *
+     * This interface encapsulates the final two steps of the error correction
+     * workflow, ensuring systematic review and production-ready code delivery.
+     */
+    interface IReviseProps {
+        /**
+         * Step 3: Code review and correction validation.
          *
          * AI performs a comprehensive review of the corrected draft implementation,
          * validating that all compilation errors have been resolved and that the
@@ -100,7 +103,7 @@ export declare namespace IAutoBeTestCorrectApplication {
          */
         review: string;
         /**
-         * Step 5: Final production-ready corrected test code.
+         * Step 4: Final production-ready corrected test code.
          *
          * AI produces the final, polished version of the corrected test code
          * incorporating all review feedback and validation results. This code
@@ -114,7 +117,7 @@ export declare namespace IAutoBeTestCorrectApplication {
          * behaviors and user workflows.
          *
          * Workflow: Review integration → Final refinement → Production-ready
-         * implementation This is the ultimate deliverable that will replace the
+         * implementation. This is the ultimate deliverable that will replace the
          * compilation-failed code.
          */
         final: string;

package/lib/orchestrate/test/structures/IAutoBeTestFunctionFailure.d.ts

@@ -0,0 +1,6 @@
+import { IAutoBeTypeScriptCompileResult } from "@autobe/interface";
+import { IAutoBeTestFunction } from "./IAutoBeTestFunction";
+export interface IAutoBeTestFunctionFailure {
+    function: IAutoBeTestFunction;
+    failure: IAutoBeTypeScriptCompileResult.IFailure;
+}

package/lib/orchestrate/test/structures/IAutoBeTestScenarioApplication.d.ts

@@ -28,6 +28,18 @@ export declare namespace IAutoBeTestScenarioApplication {
          *
          * Each scenario represents a specific test case for the same `path` and
          * `method`.
+         *
+         * IMPORTANT: Each scenario must be actually implementable. A scenario's
+         * implementability is determined by the existence of ALL APIs (endpoints)
+         * required to test it. This includes not only the primary endpoint being
+         * tested, but also ALL dependency endpoints needed for setup,
+         * authentication, and data preparation. If even one required dependency API
+         * is missing from the available operations, the scenario cannot be
+         * implemented and should not be generated.
+         *
+         * Example: A "test banned user login" scenario requires both a login API
+         * AND a ban user API. If the ban API doesn't exist, this scenario is not
+         * implementable regardless of database schema fields.
          */
         scenarios: IScenario[] & tags.MinItems<1>;
     }
@@ -37,6 +49,11 @@ export declare namespace IAutoBeTestScenarioApplication {
      * This interface defines a structured, user-centric test draft that includes
      * a descriptive function name, a detailed scenario draft, and logical
      * dependencies on other endpoints required for context or setup.
+     *
+     * CRITICAL: All referenced endpoints MUST exist in the provided API
+     * operations. Do NOT create scenarios for non-existent APIs, even if database
+     * schema fields suggest their existence. Test scenarios must be implementable
+     * with available APIs only.
      */
     interface IScenario {
         /**
@@ -113,11 +130,21 @@ export declare namespace IAutoBeTestScenarioApplication {
          * authentication, resource creation, or data setup, that are relevant to
          * the test. This list is not a strict execution order — if ordering is
          * important, it must be described explicitly in the `purpose`.
+         *
+         * WARNING: Every endpoint referenced here MUST exist in the provided API
+         * operations. Do NOT reference endpoints that are not explicitly available,
+         * even if they seem logically necessary based on database schema or
+         * business logic.
          */
         dependencies: IDependencies[];
     }
     interface IDependencies {
-        /** Target API endpoint that this scenario depends on. */
+        /**
+         * Target API endpoint that this scenario depends on.
+         *
+         * This endpoint MUST exist in the available API operations list.
+         * Non-existent endpoints will cause test implementation failures.
+         */
         endpoint: AutoBeOpenApi.IEndpoint;
         /**
          * A concise explanation of why this API call is relevant or required for

package/lib/orchestrate/test/structures/IAutoBeTestScenarioArtifacts.d.ts

@@ -4,4 +4,5 @@ export interface IAutoBeTestScenarioArtifacts {
     sdk: Record<string, string>;
     dto: Record<string, string>;
     e2e: Record<string, string>;
+    template: string;
 }