@autobe/agent 0.25.0 → 0.25.2

package/src/orchestrate/test/histories/transformTestScenarioReviewHistories.ts

@@ -6,7 +6,7 @@ import { v7 } from "uuid";
 import { AutoBeSystemPromptConstant } from "../../../constants/AutoBeSystemPromptConstant";
 import { AutoBeState } from "../../../context/AutoBeState";
 import { IAutoBeTestScenarioApplication } from "../structures/IAutoBeTestScenarioApplication";
-import { getReferenceIds } from "../utils/getReferenceIds";
+import { getPrerequisites } from "../utils/getPrerequisites";
 
 export function transformTestScenarioReviewHistories(props: {
   state: AutoBeState;
@@ -15,11 +15,6 @@ export function transformTestScenarioReviewHistories(props: {
 }): Array<
   IAgenticaHistoryJson.ISystemMessage | IAgenticaHistoryJson.IAssistantMessage
 > {
-  interface IRelationship {
-    endpoint: AutoBeOpenApi.IEndpoint;
-    ids: string[];
-  }
-
   const document: AutoBeOpenApi.IDocument | undefined =
     props.state.interface?.document;
   if (document === undefined) {
@@ -28,20 +23,13 @@ export function transformTestScenarioReviewHistories(props: {
     );
   }
 
-  const relationships: IRelationship[] = document.operations
-    .map((o) => ({
-      endpoint: {
-        method: o.method,
-        path: o.path,
-      },
-      ids: getReferenceIds({
-        document,
-        operation: o,
-      }),
-    }))
-    .filter((v) => v.ids.length !== 0);
-
   return [
+    {
+      id: v7(),
+      created_at: new Date().toISOString(),
+      type: "systemMessage",
+      text: AutoBeSystemPromptConstant.TEST_SCENARIO,
+    },
     {
       id: v7(),
       created_at: new Date().toISOString(),
@@ -74,85 +62,24 @@ export function transformTestScenarioReviewHistories(props: {
         Match each operation with its corresponding schema.
 
         \`\`\`json
-        ${JSON.stringify({
-          operations: document.operations,
-        })}
+        ${JSON.stringify({ operations: document.operations })}
         \`\`\`
 
-        ## Test Scenario Groups
+        ## Test Scenario Groups to Review
 
-        Please review the following test scenario groups:
+        Each scenario group includes the target endpoint and its prerequisite endpoints.
 
         \`\`\`json
         ${JSON.stringify(
-          props.groups.map((g) => {
-            return {
-              ...g,
-              scenarios: g.scenarios.map((s) => {
-                const requiredId: string[] = [];
-
-                s.dependencies.forEach((dep) => {
-                  document.operations.forEach((op) => {
-                    if (
-                      g.endpoint.method === op.method &&
-                      g.endpoint.path === op.path
-                    ) {
-                      requiredId.push(
-                        ...getReferenceIds({ document, operation: op }),
-                      );
-                    }
-
-                    if (
-                      op.method === dep.endpoint.method &&
-                      op.path === dep.endpoint.path
-                    ) {
-                      requiredId.push(
-                        ...getReferenceIds({ document, operation: op }),
-                      );
-                    }
-                  });
-                });
-
-                return {
-                  ...s,
-                  requiredIds:
-                    requiredId.length > 0
-                      ? Array.from(new Set(requiredId))
-                      : [],
-                };
-              }),
-            };
-          }),
+          props.groups.map((g) => ({
+            ...g,
+            prerequisites: getPrerequisites({
+              document,
+              endpoint: g.endpoint,
+            }),
+          })),
         )}
         \`\`\`
-
-        ## Candidate Dependencies
-    
-        List of candidate dependencies extracted from path parameters and request bodies.
-
-        Apply dependency resolution to the target endpoint from "Included in Test Plan" and to dependencies found recursively from it.
-        For each required ID, locate the operation that creates the resource. Include the creator only if that operation exists in the provided operations list. Do not assume or invent operations. If no creator exists, treat the ID as an external or pre-existing input.
-
-        Dependency resolution steps:
-        1. Starting from the target endpoint, collect required IDs.
-        2. For each ID, search for a creator operation (typically POST).
-        3. If found, add it to the dependency chain in execution order and repeat for its own required IDs.
-        4. Stop when no further creators exist or are needed.
-
-        For each some_entity_id pattern, use the same approach: include a creator only when it is present in the operations list.
-    
-        Endpoint | Required IDs (MUST be created by other APIs)
-        ---------|---------------------------------------------------
-        ${relationships
-          .map((r) =>
-            [
-              `\`${r.endpoint.method} ${r.endpoint.path}\``,
-              r.ids.map((id) => `\`${id}\``).join(", "),
-            ].join(" | "),
-          )
-          .join("\n")}
-
-        Example: If an endpoint requires \`articleId\` and \`POST /articles\` exists, include it in dependencies
       `,
     },
   ];

package/src/orchestrate/test/orchestrateTestCorrect.ts

@@ -179,11 +179,12 @@ const correct = async <Model extends ILlmSchema.Model>(
   });
   if (pointer.value === null) throw new Error("Failed to correct test code.");
 
-  pointer.value.revise.final = await completeTestCode(
-    ctx,
-    props.function.artifacts,
-    pointer.value.revise.final,
-  );
+  if (pointer.value.revise.final)
+    pointer.value.revise.final = await completeTestCode(
+      ctx,
+      props.function.artifacts,
+      pointer.value.revise.final,
+    );
   pointer.value.draft = await completeTestCode(
     ctx,
     props.function.artifacts,
@@ -201,7 +202,7 @@ const correct = async <Model extends ILlmSchema.Model>(
     think: pointer.value.think,
     draft: pointer.value.draft,
     review: pointer.value.revise?.review,
-    final: pointer.value.revise?.final,
+    final: pointer.value.revise?.final ?? undefined,
   } satisfies AutoBeTestCorrectEvent);
   const newFunction: IAutoBeTestFunction = {
     ...props.function,

package/src/orchestrate/test/orchestrateTestCorrectInvalidRequest.ts

@@ -10,6 +10,7 @@ import { v7 } from "uuid";
 
 import { AutoBeContext } from "../../context/AutoBeContext";
 import { assertSchemaModel } from "../../context/assertSchemaModel";
+import { completeTestCode } from "./compile/completeTestCode";
 import { transformTestCorrectInvalidRequestHistories } from "./histories/transformTestCorrectInvalidRequestHistories";
 import { IAutoBeTestCorrectInvalidRequestApplication } from "./structures/IAutoBeTestCorrectInvalidRequestApplication";
 import { IAutoBeTestFunction } from "./structures/IAutoBeTestFunction";
@@ -82,6 +83,17 @@ const correct = async <Model extends ILlmSchema.Model>(
   if (pointer.value === null) throw new Error("Failed to correct test code.");
   else if (pointer.value === false) return event; // other's responsibility
 
+  if (pointer.value.revise.final)
+    pointer.value.revise.final = await completeTestCode(
+      ctx,
+      write.artifacts,
+      pointer.value.revise.final,
+    );
+  pointer.value.draft = await completeTestCode(
+    ctx,
+    write.artifacts,
+    pointer.value.draft,
+  );
   ctx.dispatch({
     type: "testCorrect",
     id: v7(),
@@ -97,7 +109,7 @@ const correct = async <Model extends ILlmSchema.Model>(
     think: pointer.value.think,
     draft: pointer.value.draft,
     review: pointer.value.revise?.review,
-    final: pointer.value.revise?.final,
+    final: pointer.value.revise?.final ?? undefined,
   } satisfies AutoBeTestCorrectEvent);
   const newWrite: IAutoBeTestFunction = {
     artifacts: write.artifacts,

package/src/orchestrate/test/orchestrateTestScenario.ts

@@ -5,13 +5,18 @@ import {
   AutoBeProgressEventBase,
   AutoBeTestScenario,
 } from "@autobe/interface";
-import { AutoBeEndpointComparator, MapUtil, StringUtil } from "@autobe/utils";
+import {
+  AutoBeOpenApiEndpointComparator,
+  MapUtil,
+  StringUtil,
+} from "@autobe/utils";
 import { ILlmApplication, ILlmSchema, IValidation } from "@samchon/openapi";
 import { HashMap, IPointer, Pair } from "tstl";
 import typia from "typia";
 import { NamingConvention } from "typia/lib/utils/NamingConvention";
 import { v7 } from "uuid";
 
+import { AutoBeConfigConstant } from "../../constants/AutoBeConfigConstant";
 import { AutoBeContext } from "../../context/AutoBeContext";
 import { assertSchemaModel } from "../../context/assertSchemaModel";
 import { divideArray } from "../../utils/divideArray";
@@ -24,6 +29,7 @@ import { IAutoBeTestScenarioAuthorizationRole } from "./structures/IAutoBeTestSc
 export async function orchestrateTestScenario<Model extends ILlmSchema.Model>(
   ctx: AutoBeContext<Model>,
   instruction: string,
+  capacity: number = AutoBeConfigConstant.INTERFACE_CAPACITY,
 ): Promise<AutoBeTestScenario[]> {
   const document: AutoBeOpenApi.IDocument | undefined =
     ctx.state().interface?.document;
@@ -45,8 +51,8 @@ export async function orchestrateTestScenario<Model extends ILlmSchema.Model>(
             op,
           ),
       ),
-      AutoBeEndpointComparator.hashCode,
-      AutoBeEndpointComparator.equals,
+      AutoBeOpenApiEndpointComparator.hashCode,
+      AutoBeOpenApiEndpointComparator.equals,
     );
 
   const endpointNotFound: string = [
@@ -74,7 +80,7 @@ export async function orchestrateTestScenario<Model extends ILlmSchema.Model>(
   do {
     const matrix: AutoBeOpenApi.IOperation[][] = divideArray({
       array: include,
-      capacity: 4,
+      capacity: capacity ?? AutoBeConfigConstant.INTERFACE_CAPACITY,
     });
     await executeCachedBatch(
       matrix.map((include) => async (promptCacheKey) => {
@@ -405,8 +411,8 @@ const uniqueScenarioGroups = (
 ): IAutoBeTestScenarioApplication.IScenarioGroup[] =>
   new HashMap(
     groups.map((g) => new Pair(g.endpoint, g)),
-    AutoBeEndpointComparator.hashCode,
-    AutoBeEndpointComparator.equals,
+    AutoBeOpenApiEndpointComparator.hashCode,
+    AutoBeOpenApiEndpointComparator.equals,
   )
     .toJSON()
     .map((it) => it.second);

package/src/orchestrate/test/orchestrateTestScenarioReview.ts

@@ -1,6 +1,6 @@
 import { IAgenticaController } from "@agentica/core";
 import { AutoBeProgressEventBase, AutoBeTestScenario } from "@autobe/interface";
-import { AutoBeEndpointComparator } from "@autobe/utils";
+import { AutoBeOpenApiEndpointComparator } from "@autobe/utils";
 import { ILlmApplication, ILlmSchema, IValidation } from "@samchon/openapi";
 import { HashMap, IPointer, Pair } from "tstl";
 import typia from "typia";
@@ -172,8 +172,8 @@ const uniqueScenarioGroups = (
 ): IAutoBeTestScenarioApplication.IScenarioGroup[] =>
   new HashMap(
     groups.map((g) => new Pair(g.endpoint, g)),
-    AutoBeEndpointComparator.hashCode,
-    AutoBeEndpointComparator.equals,
+    AutoBeOpenApiEndpointComparator.hashCode,
+    AutoBeOpenApiEndpointComparator.equals,
   )
     .toJSON()
     .map((it) => it.second);

package/src/orchestrate/test/orchestrateTestWrite.ts

@@ -99,11 +99,12 @@ async function process<Model extends ILlmSchema.Model>(
     throw new Error("Failed to create test code.");
   }
 
-  pointer.value.revise.final = await completeTestCode(
-    ctx,
-    artifacts,
-    pointer.value.revise.final,
-  );
+  if (pointer.value.revise.final)
+    pointer.value.revise.final = await completeTestCode(
+      ctx,
+      artifacts,
+      pointer.value.revise.final,
+    );
   pointer.value.draft = await completeTestCode(
     ctx,
     artifacts,
@@ -118,7 +119,7 @@ async function process<Model extends ILlmSchema.Model>(
     domain: pointer.value.domain,
     draft: pointer.value.draft,
     review: pointer.value.revise?.review,
-    final: pointer.value.revise?.final,
+    final: pointer.value.revise?.final ?? undefined,
     tokenUsage,
     completed: ++progress.completed,
     total: progress.total,

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

@@ -91,161 +91,6 @@ 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.
    *
@@ -253,74 +98,6 @@ 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.
      *
@@ -347,17 +124,21 @@ export namespace IAutoBeTestCorrectApplication {
      * incorporating all review feedback and validation results. This code
      * represents the completed error correction, guaranteed to compile
      * successfully while preserving all original test functionality and
-     * business logic.
+     * business logic. When the draft correction already perfectly resolves all
+     * issues with no problems found during review, this value can be null,
+     * indicating no further refinement was necessary.
      *
      * The final implementation resolves all compilation issues, maintains
      * strict type safety, follows all established conventions, and delivers a
      * production-ready test that accurately validates the intended API
-     * behaviors and user workflows.
+     * behaviors and user workflows. A null value signifies the draft correction
+     * was already optimal and requires no modifications.
      *
      * Workflow: Review integration → Final refinement → Production-ready
-     * implementation. This is the ultimate deliverable that will replace the
-     * compilation-failed code.
+     * implementation (or null if draft needs no changes). This is the ultimate
+     * deliverable that will replace the compilation-failed code when provided,
+     * otherwise the draft correction is used as-is.
      */
-    final: string;
+    final: string | null;
   }
 }

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

@@ -131,7 +131,10 @@ export namespace IAutoBeTestCorrectInvalidRequestApplication {
      * Final corrected code.
      *
      * The complete, cleaned test code with all invalid API request sections
-     * removed, ready for compilation.
+     * removed, ready for compilation. When the draft already successfully
+     * removes all problematic code with no additional issues found during
+     * review, this value can be null, indicating the draft deletion was
+     * sufficient and requires no further changes.
      *
      * This code must:
      *
@@ -140,7 +143,10 @@ export namespace IAutoBeTestCorrectInvalidRequestApplication {
      * - Have no `as any` or similar type violations
      * - Maintain the original file structure
      * - Be production-ready E2E test code
+     *
+     * A null value indicates the draft successfully removed all invalid code
+     * and needs no additional modifications.
      */
-    final: string;
+    final: string | null;
   }
 }