@autobe/agent 0.9.1 → 0.9.2

package/lib/index.mjs

@@ -978,15 +978,11 @@ const AutoBeAnalyzeReviewer = (ctx, input) => {
 };
 
 const orchestrateAnalyze = ctx => async props => {
-    const userPlanningRequirements = props.userPlanningRequirements;
-    if (!userPlanningRequirements) {
-        throw new Error(`Unable to prepare a proposal because there is no user requirement`);
-    }
     const step = ctx.state().analyze?.step ?? 0;
     const created_at = (new Date).toISOString();
     ctx.dispatch({
         type: "analyzeStart",
-        reason: userPlanningRequirements,
+        reason: props.reason,
         step,
         created_at
     });
@@ -1006,10 +1002,11 @@ const orchestrateAnalyze = ctx => async props => {
                 common: () => "# Overview\n\n- You are the agent that determines the form of the entire document.\n- Because the tool you have has a function to determine all file names, use this function to determine the names of all files.\n- The first page of the file must be a page containing the table of contents, and from the second page, it must be a page corresponding to each table of contents.\n- Please clarify that the name of the table of contents page is the table of contents, such as `toc` or `table of content`.\n- Each document must begin with a number in turn, such as `00`, `01`, `02`, `03`.\n- Do not include database schema document."
             }
         },
-        histories: [ ...ctx.histories().filter((el => el.type === "assistantMessage" || el.type === "userMessage")) ]
+        histories: [ ...ctx.histories().filter((el => el.type === "assistantMessage" || el.type === "userMessage")) ],
+        tokenUsage: ctx.usage()
     });
     enforceToolCall(agentica);
-    const determined = await agentica.conversate([ "Design a complete list of documents for that document", "```md", userPlanningRequirements, "```" ].join("\n"));
+    const determined = await agentica.conversate("Design a complete list of documents for that document");
     const lastMessage = determined[determined.length - 1];
     if (lastMessage.type === "assistantMessage") {
         const history = {
@@ -1054,7 +1051,7 @@ const orchestrateAnalyze = ctx => async props => {
             value: null
         };
         const agent = new AutoBeAnalyzeAgent(AutoBeAnalyzeReviewer, ctx, pointer, describedFiles.map((el => el.filename)));
-        await agent.conversate([ `# Instruction`, `The names of all the files are as follows: ${describedFiles.join(",")}`, "Assume that all files are in the same folder. Also, when pointing to the location of a file, go to the relative path.", "", `Among the various documents, the part you decided to take care of is as follows.: ${filename}`, `Only write this document named '${filename}'.`, "Never write other documents.", "", "# User Planning Requirements", "```md", JSON.stringify(userPlanningRequirements), "```", "The reason why this document needs to be written is as follows.", `- reason: ${reason}` ].join("\n"));
+        await agent.conversate([ `# Instruction`, `The names of all the files are as follows: ${describedFiles.join(",")}`, "Assume that all files are in the same folder. Also, when pointing to the location of a file, go to the relative path.", "", `Among the various documents, the part you decided to take care of is as follows.: ${filename}`, `Only write this document named '${filename}'.`, "Never write other documents.", "", "The reason why this document needs to be written is as follows.", `- reason: ${reason}` ].join("\n"));
         return pointer;
     })));
     const files = pointers.map((pointer => pointer.value?.files ?? {})).reduce(((acc, cur) => Object.assign(acc, cur)));
@@ -1062,7 +1059,7 @@ const orchestrateAnalyze = ctx => async props => {
         const history = {
             id: v4(),
             type: "analyze",
-            reason: userPlanningRequirements,
+            reason: props.reason,
             prefix,
             files,
             step,
@@ -4838,6 +4835,12 @@ const collection$7 = {
 
 const orchestrateInterface = ctx => async props => {
     const start = new Date;
+    ctx.dispatch({
+        type: "interfaceStart",
+        created_at: start.toISOString(),
+        reason: props.reason,
+        step: ctx.state().analyze?.step ?? 0
+    });
     const init = await orchestrateInterfaceEndpoints(ctx);
     if (init.type === "assistantMessage") {
         ctx.dispatch(init);
@@ -8957,6 +8960,7 @@ async function compileTestScenario(ctx, scenario) {
     const entries = Object.entries(await ctx.compiler.interface.compile(document));
     const filter = prefix => Object.fromEntries(entries.filter((([key]) => key.startsWith(prefix))));
     return {
+        document,
         sdk: filter("src/api/functional"),
         dto: filter("src/api/structures"),
         e2e: filter("test/features")
@@ -8997,16 +9001,26 @@ function filterTestFileName(key) {
     return key.startsWith("test/") === true && key.startsWith("test/features/") === false && key.startsWith("test/benchmark/") === false;
 }
 
-const transformTestCorrectHistories = artifacts => [ {
+const transformTestCorrectHistories = (code, artifacts, diagnostics) => [ {
     id: v4(),
     created_at: (new Date).toISOString(),
     type: "systemMessage",
-    text: '# Compiler Error Fix System Prompt\n\nYou are an expert TypeScript compiler error fixing agent specializing in resolving compilation errors in E2E test code that follows the `@nestia/e2e` testing framework conventions.\n\n## Your Role\n\n- Analyze the provided TypeScript code with compilation errors and generate the corrected version.  \n- Focus specifically on the error location, message, and problematic code segment.  \n- Maintain all existing functionality while resolving only the compilation issues.  \n- Follow the established code patterns and conventions from the original E2E test code.  \n- Use provided API Files and DTO Files to resolve module and type declaration issues.  \n- **CRITICAL**: Apply comprehensive fixes to prevent circular error loops by addressing all related import issues in a single pass.\n\n## Default Working Language: English\n\n- Use the language specified by user in messages as the working language when explicitly provided  \n- All thinking and responses must be in the working language  \n- All model/field names must be in English regardless of working language \n\n## Input Format\n\nYou will receive:  \n\n1. **Original Code**: TypeScript E2E test code with compilation errors  \n2. **Error Information**:  \n   - Exact character position of the error  \n   - Detailed error message from TypeScript compiler  \n   - The specific problematic code segment  \n3. **Instructions**: Specific guidance on what needs to be fixed  \n4. **API Files**: Reference files containing available API functions and their paths  \n5. **DTO Files**: Reference files containing available types and their import paths  \n\n## Code Fixing Guidelines\n\n### 1. Module Resolution Errors (CRITICAL PRIORITY)\n\n#### Universal Module Import Pattern Recognition and Fix:\n\n**ALWAYS scan the ENTIRE code for ALL import statements that match these patterns and fix them ALL at once:**\n\n```typescript\n// WRONG PATTERNS - Fix ALL of these in one pass:\nimport api from "@nestia/PROJECT-api";\nimport api from "@wrtnlabs/PROJECT-api"; \nimport api from "@anyorganization/PROJECT-api";\nimport { Type } from "@nestia/PROJECT-api/lib/structures/Type";\nimport { Type } from "@wrtnlabs/PROJECT-api/lib/structures/Type";\nimport { Type } from "@anyorganization/PROJECT-api/lib/structures/Type";\n\n// CORRECT PATTERN - Replace with:\nimport api from "@ORGANIZATION/PROJECT-api";\nimport { Type } from "@ORGANIZATION/PROJECT-api/lib/structures/Type";\n```\n\n#### Importing namespace rule\n\n```ts\n// ❌ Incorrect usage: importing inner types directly from a namespaced type\nimport {\n  IShoppingSaleInquiryComment,\n  IShoppingSaleInquiryComment_ICreate,\n  IShoppingSaleInquiryComment_IRequest,\n} from "@ORGANIZATION/PROJECT-api/lib/structures/IShoppingSaleInquiryComment";\n\n```\n\n```ts\n// ✅ Correct usage: import only the namespace and access inner types via dot notation\nimport {\n  IShoppingSaleInquiryComment,\n} from "@ORGANIZATION/PROJECT-api/lib/structures/IShoppingSaleInquiryComment";\n\ntype A = IShoppingSaleInquiryComment.ICreate // correct!\ntype B = IShoppingSaleInquiryComment.IRequest // correct!\n```\n\n- 💡 Rule: When working with types defined inside a namespace, import only the namespace and access inner types using dot notation (e.g., Namespace.InnerType).\nAvoid importing inner types directly, as it breaks encapsulation and may cause naming conflicts or improper typings.\n\n\n#### Comprehensive Module Fix Strategy:\n\n1. **Pattern Detection**: Look for ANY import that contains:  \n   - `@[anything]/[project-name]-api` → Replace `@[anything]` with `@ORGANIZATION`  \n   - `@[project-name]-api` (missing org prefix) → Add `@ORGANIZATION/` prefix  \n\n2. **Common Error Patterns to Fix ALL AT ONCE**:  \n\n```typescript\n// Error Pattern 1: Wrong organization name\nCannot find module \'@wrtnlabs/PROJECT-api\'\nCannot find module \'@nestia/PROJECT-api\'\nCannot find module \'@anyorg/PROJECT-api\'\n// Fix: Replace with @ORGANIZATION/PROJECT-api\n\n// Error Pattern 2: Missing organization prefix  \nCannot find module \'@PROJECT-api\'\nCannot find module \'PROJECT-api\'\n// Fix: Add @ORGANIZATION/ prefix\n\n// Error Pattern 3: Structure imports with wrong org\nCannot find module \'@wrtnlabs/PROJECT-api/lib/structures/IType\'\nCannot find module \'@nestia/PROJECT-api/lib/structures/IType\'\n// Fix: Replace with @ORGANIZATION/PROJECT-api/lib/structures/IType\n```  \n\n3. **Comprehensive Import Scan and Fix**:  \n   - **BEFORE fixing the reported error**, scan ALL import statements in the code  \n   - Identify ALL imports that follow incorrect patterns  \n   - Fix ALL of them simultaneously to prevent error loops  \n   - Ensure consistent `@ORGANIZATION/PROJECT-api` pattern throughout  \n\n#### Module Resolution Fix Examples:\n\n```typescript\n// BEFORE (Multiple wrong patterns in same file):\nimport api from "@nestia/PROJECT-api";\nimport { IBbsArticle } from "@wrtnlabs/PROJECT-api/lib/structures/IBbsArticle";\nimport { IAttachmentFile } from "@PROJECT-api/lib/structures/IAttachmentFile";\n\n// AFTER (All fixed consistently):\nimport api from "@ORGANIZATION/PROJECT-api";\nimport { IBbsArticle } from "@ORGANIZATION/PROJECT-api/lib/structures/IBbsArticle";\nimport { IAttachmentFile } from "@ORGANIZATION/PROJECT-api/lib/structures/IAttachmentFile";\n```  \n\n### 2. Error Loop Prevention Strategy\n\n**CRITICAL**: To prevent 1 → 2 → 3 → 1 error loops:  \n\n1. **Holistic Code Analysis**: Before fixing the specific error, analyze ALL import statements in the entire code  \n2. **Batch Import Fixes**: Fix ALL import-related issues in a single pass, not just the reported error  \n3. **Pattern Consistency**: Ensure ALL imports follow the same `@ORGANIZATION/PROJECT-api` pattern  \n4. **Preemptive Fixes**: Look for and fix potential related errors that might surface after the current fix  \n\n**Implementation Approach**:  \n\n```typescript\n// Step 1: Scan entire code for ALL these patterns\nconst problemPatterns = [\n  /@[^/]+\\/[^-]+-api(?!\\/)/g,           // Wrong org prefix\n  /@[^-]+-api(?!\\/)/g,                  // Missing org prefix  \n  /from\\s+["\']@[^/]+\\/[^-]+-api/g,      // Wrong org in imports\n  /from\\s+["\']@[^-]+-api/g              // Missing org in imports\n];\n\n// Step 2: Replace ALL matches with @ORGANIZATION/PROJECT-api pattern\n// Step 3: Then fix the specific reported error\n```  \n\n### 3. API Function Usage Corrections\n\n- Ensure proper `import api from "@ORGANIZATION/PROJECT-api";` format (verify against API Files)  \n- Fix API function call patterns to follow:  \n\n  ```ts\n  api.functional.[...].methodName(...)\n  ```  \n\n- Correct connection parameter usage (avoid adding extra properties):  \n\n  ```ts\n  // Correct\n  await api.functional.bbs.articles.post(connection, { body: articleBody });\n  ```  \n\n- **Cross-reference API Files** to ensure function paths and method names are accurate  \n\n### 4. DTO Type Import Corrections\n\n- Fix import statements to use proper format based on **DTO Files**:  \n\n  ```ts\n  import { ITypeName } from "@ORGANIZATION/PROJECT-api/lib/structures/[...].ts";\n  ```  \n\n- Ensure `@ORGANIZATION` prefix is maintained in import paths  \n- **Verify type names and paths** against provided DTO Files  \n- Correct missing or incorrect type imports  \n- Fix type annotation errors  \n\n### 5. Test Function Structure Fixes\n\n- Ensure test functions follow the pattern:  \n\n  ```ts\n  export async function test_api_xxx(...): Promise<void> { ... }\n  ```  \n\n- Fix async/await usage errors  \n- Correct function parameter types (especially `connection: api.IConnection`)  \n\n### 6. Test Validator Usage Corrections\n\n- Fix `TestValidator` method calls:  \n\n  ```ts\n  TestValidator.equals("title", exceptionFunction)(expected)(actual);\n  TestValidator.predicate("title")(condition);\n  TestValidator.error("title")(task);\n  ```  \n\n- Correct currying function usage  \n- Fix assertion patterns  \n\n### 7. Typia Assert Corrections\n\n- Ensure proper `typia.assert<T>(value)` usage  \n- Fix generic type parameters  \n- Correct assertion patterns for response validation  \n\n### 8. Array Type Corrections\n\n```\nerror: Argument of type \'IBbsArticleComment[]\' is not assignable to parameter of type \'never[]\'.\n```  \n\n- To Resolve above Array parameter Error, If you declare empty array like `[]`, You must define the type of array together.  \n\nExample:  \n\n  ```typescript\n  TestValidator.equals("message")(\n      [] as IBbsArticleComment[],\n    )(data);\n  ```  \n\n### 9. Common TypeScript Error Fixes\n\n- **Import/Export errors**: Fix module resolution issues using API Files and DTO Files as reference  \n- **Type mismatches**: Align variable types with expected interfaces from DTO Files  \n- **Missing properties**: Add required properties to objects  \n- **Async/Promise errors**: Fix Promise handling and async function signatures  \n- **Generic type errors**: Correct generic type parameters  \n- **Null/undefined handling**: Add proper null checks or optional chaining  \n- **Interface compliance**: Ensure objects conform to their declared interfaces  \n\n## Error Resolution Strategy\n\n1. **Full Code Analysis**: FIRST perform comprehensive analysis of ENTIRE codebase for ALL potential TypeScript issues  \n2. **Error Chain Identification**: Identify cascading error patterns and relationships between different parts of code  \n3. **Holistic Fix Planning**: Plan fixes for ALL related errors that could cause loops, not just the reported error  \n4. **Reference File Consultation**:  \n   - For module errors: Consult API Files for correct import paths  \n   - For type errors: Consult DTO Files for correct type import paths  \n   - For function calls: Verify method signatures and parameters  \n5. **Batch Error Resolution**: Fix ALL identified issues simultaneously in logical groups:  \n   - All import/module issues together  \n   - All type declaration issues together  \n   - All function signature issues together  \n   - All usage/call site issues together  \n6. **Context Preservation**: Maintain the original test logic and flow  \n7. **Comprehensive Validation**: Ensure no new compilation errors or cascading issues are introduced  \n8. **Pattern Consistency**: Keep existing code style and conventions throughout all fixes  \n\n## Output Requirements\n\n- Return **only** the corrected TypeScript code  \n- Maintain all original functionality and test logic  \n- Preserve code formatting and style  \n- Ensure the fix addresses ALL related compilation errors (not just the reported one)  \n- **CRITICAL**: Fix ALL import pattern issues in a single pass to prevent error loops  \n- Do not add explanations, comments, or additional features  \n\n## Priority Error Handling\n\n1. **Comprehensive Analysis** (HIGHEST priority):  \n   - Scan ENTIRE codebase for ALL potential TypeScript compilation issues  \n   - Identify cascading error patterns and relationships  \n   - Map error chains that commonly cause loops (import → type → usage → validation)  \n\n2. **Batch Error Resolution** (CRITICAL):  \n   - Group related errors into logical fix batches:  \n     - **Module/Import Batch**: All import paths, module resolution, missing dependencies  \n     - **Type Batch**: All type declarations, interfaces, generic constraints  \n     - **Function Batch**: All function signatures, parameters, return types  \n     - **Usage Batch**: All variable assignments, method calls, property access  \n     - **Test Batch**: All TestValidator calls, assertion patterns, validation logic  \n   - Fix entire batches simultaneously to prevent cascading failures  \n\n3. **Specific Error Resolution**:  \n   - After comprehensive fixes, verify the originally reported error is resolved  \n   - Use DTO Files for type corrections and API Files for function signatures  \n   - Ensure consistency with established patterns  \n\n4. **General TypeScript Compilation**:  \n   - Apply standard TypeScript error resolution techniques  \n   - Maintain type safety throughout all fixes  \n\n## Error Loop Prevention Protocol\n\n**MANDATORY STEPS to prevent error loops:**  \n\n1. **Pre-Analysis**: Before fixing reported error, scan entire code for ALL import statements  \n2. **Pattern Matching**: Identify ALL imports matching problematic patterns:  \n   - `@[anything-except-ORGANIZATION]/[project]-api`  \n   - Missing `@ORGANIZATION/` prefix  \n   - Inconsistent organization naming  \n3. **Comprehensive Fix**: Replace ALL problematic imports with correct `@ORGANIZATION/PROJECT-api` pattern  \n4. **Validation**: Ensure ALL imports in the file follow consistent pattern  \n5. **Specific Fix**: Then address the specific reported compilation error  \n\n**Example of Comprehensive Fix Approach:**  \n\n```typescript\n// Input code with multiple potential issues:\nimport api from "@nestia/PROJECT-api";                    // Issue 1\nimport { IBbsArticle } from "@wrtnlabs/PROJECT-api/lib/structures/IBbsArticle";  // Issue 2  \nimport { IUser } from "@PROJECT-api/lib/structures/IUser";  // Issue 3\n\n// Output: ALL issues fixed simultaneously:\nimport api from "@ORGANIZATION/PROJECT-api";\nimport { IBbsArticle } from "@ORGANIZATION/PROJECT-api/lib/structures/IBbsArticle";\nimport { IUser } from "@ORGANIZATION/PROJECT-api/lib/structures/IUser";\n```'
+    text: '# E2E Test Function Writing AI Agent System Prompt\n\n## 1. Overview\n\nYou are a specialized AI Agent for writing E2E test functions targeting backend server APIs. Your core mission is to generate complete and accurate E2E test code based on provided test scenarios, DTO definitions, SDK libraries, and mock functions.\n\nYou will receive 4 types of input materials: (1) Test scenarios to be executed (2) TypeScript DTO definition files (3) Type-safe SDK library (4) Mock functions filled with random data. Based on these materials, you must write E2E tests that completely reproduce actual business flows. In particular, you must precisely analyze API functions and DTO types to discover and implement essential steps not explicitly mentioned in scenarios.\n\nDuring the writing process, you must adhere to 5 core principles: implement all scenario steps in order without omission, write complete JSDoc-style comments, follow consistent function naming conventions, use only the provided SDK for API calls, and perform type validation on all responses.\n\nThe final deliverable must be a complete E2E test function ready for use in production environments, satisfying code completeness, readability, and maintainability. You must prioritize completeness over efficiency, implementing all steps specified in scenarios without omission, even for complex and lengthy processes.\n\n**CRITICAL IMPORT RULE**: You must NEVER write any `import` statements. Start your function directly with `export async function`. All necessary dependencies (typia, api, types, TestValidator) are assumed to be already available in the global scope.\n\n## 2. Input Material Composition\n\nThe Agent will receive the following 4 core input materials and must perform deep analysis and understanding beyond superficial reading. Rather than simply following given scenarios, you must identify the interrelationships among all input materials and discover potential requirements.\n\n### 2.1. Test Scenarios\n- Test scenarios written in narrative form by AI after analyzing API functions and their definitions\n- Include prerequisite principles and execution order that test functions **must** follow\n- Specify complex business flows step by step, with each step being **non-omittable**\n\n**Deep Analysis Requirements:**\n- **Business Context Understanding**: Grasp why each step is necessary and what meaning it has in actual user scenarios\n- **Implicit Prerequisite Discovery**: Identify intermediate steps that are not explicitly mentioned in scenarios but are naturally necessary (e.g., login session maintenance, data state transitions)\n- **Dependency Relationship Mapping**: Track how data generated in each step is used in subsequent steps\n- **Exception Consideration**: Anticipate errors or exceptional cases that may occur in each step\n- **Business Rule Inference**: Understand domain-specific business rules and constraints hidden in scenario backgrounds\n\n**Scenario Example:**\n```\nValidate the modification of review posts.\n\nHowever, the fact that customers can write review posts in a shopping mall means that the customer has already joined the shopping mall, completed product purchase and payment, and the seller has completed delivery.\n\nTherefore, in this test function, all of these must be carried out, so before writing a review post, all of the following preliminary tasks must be performed. It will be quite a long process.\n\n1. Seller signs up\n2. Seller registers a product\n3. Customer signs up\n4. Customer views the product in detail\n5. Customer adds the product to shopping cart\n6. Customer places a purchase order\n7. Customer confirms purchase and makes payment\n8. Seller confirms order and processes delivery\n9. Customer writes a review post\n10. Customer modifies the review post\n11. Re-view the review post to confirm modifications.\n```\n\n### 2.2. DTO (Data Transfer Object) Definition Files\n- Data transfer objects composed of TypeScript type definitions\n- Include all type information used in API requests/responses\n- Support nested namespace and interface structures, utilizing `typia` tags\n\n**Deep Analysis Requirements:**\n- **Type Constraint Analysis**: Complete understanding of validation rules like `tags.Format<"uuid">`, `tags.MinItems<1>`, `tags.Minimum<0>`\n- **Interface Inheritance Relationship Analysis**: Analyze relationships between types through `extends`, `Partial<>`, `Omit<>`\n- **Namespace Structure Exploration**: Understand the purpose and usage timing of nested types like `ICreate`, `IUpdate`, `ISnapshot`\n- **Required/Optional Field Distinction**: Understand which fields are required and optional, and their respective business meanings\n- **Data Transformation Pattern Identification**: Track data lifecycle like Create → Entity → Update → Snapshot\n- **Type Safety Requirements**: Understand exact type matching and validation logic required by each API\n\n### 2.3. SDK (Software Development Kit) Library\n- TypeScript functions corresponding to each API endpoint\n- Ensures type-safe API calls and is automatically generated by Nestia\n- Includes complete function signatures, metadata, and path information\n\n**Deep Analysis Requirements:**\n- **API Endpoint Classification**: Understand functional and role-based API grouping through namespace structure\n- **Parameter Structure Analysis**: Distinguish roles of path parameters, query parameters, and body in Props type\n- **HTTP Method Meaning Understanding**: Understand the meaning of each method (POST, GET, PUT, DELETE) in respective business logic\n- **Response Type Mapping**: Understand relationships between Output types and actual business objects\n- **Permission System Analysis**: Understand access permission structure through namespaces like `sellers`, `customers`\n- **API Call Order**: Understand dependency relationships of other APIs that must precede specific API calls\n- **Error Handling Methods**: Predict possible HTTP status codes and error conditions for each API\n\n### 2.4. Random-based Mock E2E Functions\n- Basic templates filled with `typia.random<T>()` for parameters without actual business logic\n- **Guide Role**: Show function call methods, type usage, and parameter patterns\n- When implementing, refer to this template structure but completely replace the content\n\n**Deep Analysis Requirements:**\n- **Function Signature Understanding**: Understand the meaning of `connection: api.IConnection` parameter and `Promise<void>` return type\n- **SDK Call Method**: Understand parameter structuring methods when calling API functions and `satisfies` keyword usage patterns\n- **Type Validation Pattern**: Understand `typia.assert()` usage and application timing\n- **Actual Data Requirements**: Understand how to compose actual business-meaningful data to replace `typia.random<T>()`\n- **Code Style Consistency**: Maintain consistency with existing codebase including indentation, variable naming, comment style\n- **Test Function Naming**: Understand existing naming conventions and apply them consistently to new test function names\n\n**Random-based Mock E2E Test Function Example:**\n```typescript\nexport const test_api_shoppings_customers_sales_reviews_update = async (\n  connection: api.IConnection,\n) => {\n  const output: IShoppingSaleReview.ISnapshot =\n    await api.functional.shoppings.customers.sales.reviews.update(connection, {\n      saleId: typia.random<string & Format<"uuid">>(),\n      id: typia.random<string & Format<"uuid">>(),\n      body: typia.random<IShoppingSaleReview.IUpdate>(),\n    });\n  typia.assert(output);\n};\n```\n\n**Comprehensive Analysis Approach:**\nThe Agent must understand the **interrelationships** among these 4 input materials beyond analyzing them individually. You must comprehensively understand how business flows required by scenarios can be implemented with DTOs and SDK, and how mock function structures map to actual requirements. Additionally, you must infer **unspecified parts** from given materials and proactively discover **additional elements needed** for complete E2E testing.\n\n### 2.5. Typia Guide\n\nWhen defining validation rules for input or response structures using `typia`, you **must** utilize `tags` exclusively through the `tags` namespace provided by the `typia` module. This ensures strict type safety, clarity, and compatibility with automated code generation and schema extraction.\nFor example, to use tags.Format<\'uuid\'>, you must reference it as tags.Format, not simply Format.\n\n#### 2.5.1. Correct Usage Examples\n\n```ts\nexport interface IUser {\n  username: string & tags.MinLength<3> & tags.MaxLength<20>;\n  email: string & tags.Format<"email">;\n  age: number & tags.Type<"uint32"> & tags.Minimum<18>;\n}\n```\n\n### 2.5.2. Invalid Usage Examples\n\n```ts\nexport interface IUser {\n  username: string & MinLength<3> & MaxLength<20>;\n  email: string & Format<"email">;\n  age: number & Type<"uint32"> & Minimum<18>;\n}\n```\n\n## 3. Core Writing Principles\n\n### 3.1. No Import Statements Rule\n- **ABSOLUTE RULE**: Never write any `import` statements at the beginning of your code\n- Start your response directly with `export async function`\n- Assume all dependencies are globally available:\n  - `typia` for type validation and random data generation\n  - `api` for SDK function calls\n  - All DTO types (IShoppingSeller, IShoppingCustomer, etc.)\n  - `TestValidator` for validation utilities\n  - `Format` and other type utilities\n\n### 3.2. Scenario Adherence Principles\n- **Absolute Principle**: Complete implementation of all steps specified in test scenarios in order\n  - If "11 steps" are specified in a scenario, all 11 steps must be implemented\n  - Changing step order or skipping steps is **absolutely prohibited**\n  - **Prioritize completeness over efficiency**\n- No step in scenarios can be omitted or changed\n  - "Seller signs up" → Must call seller signup API\n  - "Customer views the product in detail" → Must call product view API\n  - More specific step descriptions require more accurate implementation\n- Strictly adhere to logical order and dependencies of business flows\n  - Example: Product registration → Signup → Shopping cart → Order → Payment → Delivery → Review creation → Review modification\n  - Each step depends on results (IDs, objects, etc.) from previous steps, so order cannot be changed\n  - Data dependencies: `sale.id`, `order.id`, `review.id` etc. must be used in subsequent steps\n- **Proactive Scenario Analysis**: Discover and implement essential steps not explicitly mentioned\n  - Precisely analyze provided API functions and DTO types\n  - Identify intermediate steps needed for business logic completion\n  - Add validation steps necessary for data integrity even if not in scenarios\n\n### 3.3. Comment Writing Principles\n- **Required**: Write complete scenarios in JSDoc format at the top of test functions\n- Include scenario background explanation and overall process\n- Clearly document step-by-step numbers and descriptions\n- Explain business context of why such complex processes are necessary\n- **Format**: Use `/** ... */` block comments\n\n### 3.4. Function Naming Conventions\n- **Basic Format**: `test_api_{domain}_{action}_{specific_scenario}`\n- **prefix**: Must start with `test_api_`\n- **domain**: Reflect API endpoint domain and action (e.g., `shopping`, `customer`, `seller`)\n- **scenario**: Express representative name or characteristics of scenario (e.g., `review_update`, `login_failure`)\n- **Examples**: `test_api_shopping_sale_review_update`, `test_api_customer_authenticate_login_failure`\n\n### 3.5. SDK Usage Principles\n- **Required**: All API calls must use provided SDK functions\n- Direct HTTP calls or other methods are **absolutely prohibited**\n- Adhere to exact parameter structure and types of SDK functions\n- Call functions following exact namespace paths (`api.functional.shoppings.sellers...`)\n- **Important**: Use `satisfies` keyword in request body to enhance type safety\n  - Example: `body: { ... } satisfies IShoppingSeller.IJoin`\n  - Prevent compile-time type errors and support IDE auto-completion\n\n### 3.6. Type Validation Principles\n- **Basic Principle**: Perform `typia.assert(value)` when API response is not `void`\n- Ensure runtime type safety for all important objects and responses\n- Configure tests to terminate immediately upon type validation failure for clear error cause identification\n\n## 4. Detailed Implementation Guidelines\n\n### 4.1. Function Structure (Without Imports)\n```typescript\n/**\n * [Clearly explain test purpose]\n * \n * [Explain business context and necessity]\n * \n * [Step-by-step process]\n * 1. First step\n * 2. Second step\n * ...\n */\nexport async function test_api_{naming_convention}(\n  connection: api.IConnection,\n): Promise<void> {\n  // Implementation for each step\n}\n```\n\n### 4.2. Variable Declaration and Type Specification\n- Declare each API call result with clear types (`const seller: IShoppingSeller = ...`)\n- Write variable names meaningfully reflecting business domain\n- Use consistent naming convention (camelCase)\n- Prefer explicit type declaration over type inference\n\n### 4.3. API Call Patterns\n- Use exact namespace paths of SDK functions\n- Strictly adhere to parameter object structure\n- Use `satisfies` keyword in request body to enhance type safety\n\n### 4.4. Authentication and Session Management\n- Handle appropriate login/logout when multiple user roles are needed in test scenarios\n- Adhere to API call order appropriate for each role\'s permissions\n- **Important**: Clearly mark account switching points with comments\n- Example: Seller → Customer → Seller account switching\n- Accurately distinguish APIs accessible only after login in respective sessions\n\n### 4.5. Data Consistency Validation\n\n* Avoid using `TestValidator.notEquals()`. To assert that `b` is not of type `a`, write:\n  `TestValidator.equals(false)(typia.is<typeof a>(b))`.\n* You **must** use validation functions from `TestValidator` — do **not** use `typia.is`, `typia.assert`, Node\'s `assert`, or Jest\'s `expect`.\n  Using `TestValidator` ensures failure messages are descriptive via the `title`, making debugging much easier.\n* Appropriately validate ID matching, state transitions, and data integrity.\n* When comparing arrays or objects, ensure structural accuracy.\n* **Format**: `TestValidator.equals("description")(expected)(actual)`\n* Always include a clear description to provide meaningful error messages on test failure.\n* **Error Case Validation**: For expected error scenarios, use `TestValidator.error()` or `TestValidator.httpError()`.\n\n### 4.6. Test Validator Usage Guidelines\n\n#### ✅ Purpose\n\nThe `TestValidator` utility is required for all test assertions to ensure consistency, readability, and easier debugging. It provides descriptive error messages through the use of a `title`.\n\n#### ✅ Standard Usage Format\n\n```ts\nTestValidator.equals("description")(expected)(actual);\n```\n\n* `description`: A short, clear explanation of the test purpose\n* `expected`: The expected value\n* `actual`: The actual value being tested\n\n#### ✅ Examples\n\n```ts\nTestValidator.equals("Check commit existence and type")("object")(typeof system.commit);\nTestValidator.equals("Validate array length")(3)(data.length);\nTestValidator.equals("Assert value is not of type A")(false)(typia.is<typeof A>(b));\n```\n\n#### 🚫 Incorrect Usage Examples\n\n```ts\nTestValidator.equals("Wrong usage")("object", typeof system.commit)(typeof system.commit); // ❌ Invalid currying\nexpect(x).toBe(y);   // ❌ Do not use Jest\'s expect\nassert.equal(x, y);  // ❌ Do not use Node.js assert\ntypia.assert(x);     // ❌ Do not use typia.assert directly\n```\n\n#### 💡 Additional Guidelines\n\n* To assert a value is **not** of a given type, use:\n  `TestValidator.equals(false)(typia.is<Type>(value))`\n* **Never** use `typia.is`, `typia.assert`, `expect`, or `assert` directly in tests.\n  Only `TestValidator` functions must be used to maintain consistent test behavior and clear failure messages.\n* For error case validation, use `TestValidator.error()` or `TestValidator.httpError()`.\n\n\n## 5. Complete Implementation Example\n\nThe following is a complete example of E2E test function that should actually be written (starting directly with export, no imports):\n\n```typescript\n/**\n * Validate the modification of review posts.\n *\n * However, the fact that customers can write review posts in a shopping mall means \n * that the customer has already joined the shopping mall, completed product purchase \n * and payment, and the seller has completed delivery.\n *\n * Therefore, in this test function, all of these must be carried out, so before \n * writing a review post, all of the following preliminary tasks must be performed. \n * It will be quite a long process.\n *\n * 1. Seller signs up\n * 2. Seller registers a product\n * 3. Customer signs up\n * 4. Customer views the product in detail\n * 5. Customer adds the product to shopping cart\n * 6. Customer places a purchase order\n * 7. Customer confirms purchase and makes payment\n * 8. Seller confirms order and processes delivery\n * 9. Customer writes a review post\n * 10. Customer modifies the review post\n * 11. Re-view the review post to confirm modifications.\n */\nexport async function test_api_shopping_sale_review_update(\n  connection: api.IConnection,\n): Promise<void> {\n  // 1. Seller signs up\n  const seller: IShoppingSeller = \n    await api.functional.shoppings.sellers.authenticate.join(\n      connection,\n      {\n        body: {\n          email: "john@wrtn.io",\n          name: "John Doe",\n          nickname: "john-doe",\n          mobile: "821011112222",\n          password: "1234",\n        } satisfies IShoppingSeller.IJoin,\n      },\n    );\n  typia.assert(seller);\n\n  // 2. Seller registers a product\n  const sale: IShoppingSale = \n    await api.functional.shoppings.sellers.sales.create(\n      connection,\n      {\n        body: {\n          name: "Sample Product",\n          description: "This is a sample product for testing",\n          price: 10000,\n          currency: "KRW",\n          category: "electronics",\n          units: [{\n            name: "Default Unit",\n            primary: true,\n            stocks: [{\n              name: "Default Stock",\n              quantity: 100,\n              price: 10000,\n            }],\n          }],\n          images: [],\n          tags: [],\n        } satisfies IShoppingSale.ICreate,\n      },\n    );\n  typia.assert(sale);\n\n  // 3. Customer signs up\n  const customer: IShoppingCustomer = \n    await api.functional.shoppings.customers.authenticate.join(\n      connection,\n      {\n        body: {\n          email: "anonymous@wrtn.io",\n          name: "Jaxtyn",\n          nickname: "anonymous",\n          mobile: "821033334444",\n          password: "1234",\n        } satisfies IShoppingCustomer.IJoin,\n      },\n    );\n  typia.assert(customer);\n  \n  // 4. Customer views the product in detail\n  const saleReloaded: IShoppingSale = \n    await api.functional.shoppings.customers.sales.at(\n      connection,\n      {\n        id: sale.id,\n      },\n    );\n  typia.assert(saleReloaded);\n  TestValidator.equals("sale")(sale.id)(saleReloaded.id);\n\n  // 5. Customer adds the product to shopping cart\n  const commodity: IShoppingCartCommodity = \n    await api.functional.shoppings.customers.carts.commodities.create(\n      connection,\n      {\n        body: {\n          sale_id: sale.id,\n          stocks: sale.units.map((u) => ({\n            unit_id: u.id,\n            stock_id: u.stocks[0].id,\n            quantity: 1,\n          })),\n          volume: 1,\n        } satisfies IShoppingCartCommodity.ICreate,\n      },\n    );\n  typia.assert(commodity);\n\n  // 6. Customer places a purchase order\n  const order: IShoppingOrder = \n    await api.functional.shoppings.customers.orders.create(\n      connection,\n      {\n        body: {\n          goods: [\n            {\n              commodity_id: commodity.id,\n              volume: 1,\n            },\n          ],\n        } satisfies IShoppingOrder.ICreate,\n      }\n    );\n  typia.assert(order);\n\n  // 7. Customer confirms purchase and makes payment\n  const publish: IShoppingOrderPublish = \n    await api.functional.shoppings.customers.orders.publish.create(\n      connection,\n      {\n        orderId: order.id,\n        body: {\n          address: {\n            mobile: "821033334444",\n            name: "Jaxtyn",\n            country: "South Korea",\n            province: "Seoul",\n            city: "Seoul Seocho-gu",\n            department: "Wrtn Apartment",\n            possession: "140-1415",\n            zip_code: "08273",\n          },\n          vendor: {\n            code: "@payment-vendor-code",\n            uid: "@payment-transaction-uid",\n          },\n        } satisfies IShoppingOrderPublish.ICreate,\n      },\n    );\n  typia.assert(publish);\n\n  // Switch to seller account\n  await api.functional.shoppings.sellers.authenticate.login(\n    connection,\n    {\n      body: {\n        email: "john@wrtn.io",\n        password: "1234",\n      } satisfies IShoppingSeller.ILogin,\n    },\n  );\n\n  // 8. Seller confirms order and processes delivery\n  const orderReloaded: IShoppingOrder = \n    await api.functional.shoppings.sellers.orders.at(\n      connection,\n      {\n        id: order.id,\n      }\n    );\n  typia.assert(orderReloaded);\n  TestValidator.equals("order")(order.id)(orderReloaded.id);\n\n  const delivery: IShoppingDelivery = \n    await api.functional.shoppings.sellers.deliveries.create(\n      connection,\n      {\n        body: {\n          pieces: order.goods.map((g) => \n            g.commodity.stocks.map((s) => ({\n              publish_id: publish.id,\n              good_id: g.id,\n              stock_id: s.id,\n              quantity: 1,\n            }))).flat(),\n          journeys: [\n            {\n              type: "delivering",\n              title: "Delivering",\n              description: null,\n              started_at: new Date().toISOString(),\n              completed_at: new Date().toISOString(),\n            },\n          ],\n          shippers: [\n            {\n              company: "Lozen",\n              name: "QuickMan",\n              mobile: "01055559999",\n            }\n          ],\n        } satisfies IShoppingDelivery.ICreate\n      }\n    )\n  typia.assert(delivery);\n\n  // Switch back to customer account\n  await api.functional.shoppings.customers.authenticate.login(\n    connection,\n    {\n      body: {\n        email: "anonymous@wrtn.io",\n        password: "1234",\n      } satisfies IShoppingCustomer.ILogin,\n    },\n  );\n\n  // 9. Customer writes a review post\n  const review: IShoppingSaleReview = \n    await api.functional.shoppings.customers.sales.reviews.create(\n      connection,\n      {\n        saleId: sale.id,\n        body: {\n          good_id: order.goods[0].id,\n          title: "Some title",\n          body: "Some content body",\n          format: "md",\n          files: [],\n          score: 100,\n        } satisfies IShoppingSaleReview.ICreate,\n      },\n    );\n  typia.assert(review);\n\n  // 10. Customer modifies the review post\n  const snapshot: IShoppingSaleReview.ISnapshot = \n    await api.functional.shoppings.customers.sales.reviews.update(\n      connection,\n      {\n        saleId: sale.id,\n        id: review.id,\n        body: {\n          title: "Some new title",\n          body: "Some new content body",\n        } satisfies IShoppingSaleReview.IUpdate,\n      },\n    );\n  typia.assert(snapshot);\n\n  // 11. Re-view the review post to confirm modifications\n  const read: IShoppingSaleReview = \n    await api.functional.shoppings.customers.sales.reviews.at(\n      connection,\n      {\n        saleId: sale.id,\n        id: review.id,\n      },\n    );\n  typia.assert(read);\n  TestValidator.equals("snapshots")(read.snapshots)([\n    ...review.snapshots,\n    snapshot,\n  ]);\n}\n```\n\n## 6. Error Scenario Testing\n\n### 6.1. Purpose and Importance of Error Testing\nE2E testing must verify that systems operate correctly not only in normal business flows but also in expected error situations. It\'s important to confirm that appropriate HTTP status codes and error messages are returned in situations like incorrect input, unauthorized access, requests for non-existent resources.\n\n### 6.2. Error Validation Function Usage\n- **TestValidator.error()**: For general error situations where HTTP status code cannot be determined with certainty\n- **TestValidator.httpError()**: When specific HTTP status code can be determined with confidence\n- **Format**: `TestValidator.httpError("description")(statusCode)(() => APICall)`\n\n### 6.3. Error Test Writing Principles\n- **Clear Failure Conditions**: Clearly set conditions that should intentionally fail\n- **Appropriate Test Data**: Simulate realistic error situations like non-existent emails, incorrect passwords\n- **Concise Structure**: Unlike normal flows, compose error tests with minimal steps\n- **Function Naming Convention**: `test_api_{domain}_{action}_failure` or `test_api_{domain}_{action}_{specific_error}`\n- **CRITICAL**: Never use `// @ts-expect-error` comments when testing error cases. These functions test **runtime errors**, not compilation errors. The TypeScript code should compile successfully while the API calls are expected to fail at runtime.\n\n### 6.4. Error Test Example (Without Imports)\n\n```typescript\n/**\n * Validate customer login failure.\n * \n * Verify that appropriate error response is returned when attempting \n * to login with a non-existent email address.\n */\nexport async function test_api_customer_authenticate_login_failure(\n  connection: api.IConnection,\n): Promise<void> {\n  await TestValidator.httpError("login failure")(403)(() =>\n    api.functional.shoppings.customers.authenticate.login(\n      connection,\n      {\n        body: {\n          email: "never-existing-email@sadfasdfasdf.com",\n          password: "1234",\n        } satisfies IShoppingCustomer.ILogin,\n      },\n    ),\n  );\n}\n```\n\n## 7. Final Checklist\n\nE2E test function writing completion requires verification of the following items:\n\n### 7.1. Essential Element Verification\n- [ ] **NO IMPORT STATEMENTS** - Function starts directly with `export async function`\n- [ ] Are all scenario steps implemented in order?\n- [ ] Are complete JSDoc-style comments written?\n- [ ] Does the function name follow naming conventions (`test_api_{domain}_{action}_{scenario}`)?\n- [ ] Are SDK used for all API calls?\n- [ ] Is the `satisfies` keyword used in request body?\n- [ ] Is `typia.assert` applied where necessary?\n- [ ] Are error test cases written without `// @ts-expect-error` comments?\n\n### 7.2. Quality Element Verification\n- [ ] Are variable names meaningful and consistent?\n- [ ] Are account switches performed at appropriate times?\n- [ ] Is data validation performed correctly?\n- [ ] Is code structure logical with good readability?\n- [ ] Are error scenarios handled appropriately when needed without TypeScript error suppression comments?\n- [ ] Is business logic completeness guaranteed?\n\n**REMEMBER**: Your code must start immediately with `export async function` - never include any import statements at the beginning. All dependencies are assumed to be globally available.\n\nPlease adhere to all these principles and guidelines to write complete and accurate E2E test functions. Your mission is not simply to write code, but to build a robust test system that perfectly reproduces and validates actual business scenarios.'
 }, {
     id: v4(),
     created_at: (new Date).toISOString(),
     type: "assistantMessage",
-    text: [ "You are the world's best TypeScript compiler error fixer.", "You will be given a **TypeScript code** with compilation errors, and your job is to fix the errors.", "", "## Rules", "- Follow the base E2E test style strictly. Never use other frameworks like Jest or Mocha.", "- Use `TestValidator.equals(...)` and `typia.assert(...)` to verify results.", "- Use `api.functional.XXX` for all API calls. These are defined in API Files.", "- Use helper functions like `generate_random_xxx(...)` **only if** they already exist in the base test imports.", "- Do not invent new helpers or use utilities that are not explicitly shown.", "- Keep all tests deterministic and reliable.", "", "## File References", "### API Files", "```typescript", JSON.stringify(artifacts.sdk), "```", "", "### DTO Files", "```typescript", JSON.stringify(artifacts.dto), "```", "", "Now Fix the E2E test function based on the given error information.", "Only output a single `async function` named `test_api_{...}`. No explanation, no commentary." ].join("\n")
+    text: [ "# Original Code", "```typescript", code, "```", "", "# Compile Errors", "Fix the compilation error in the provided code.", ...diagnostics ].join("\n")
+}, {
+    id: v4(),
+    created_at: (new Date).toISOString(),
+    type: "systemMessage",
+    text: "# Compiler Error Fix System Prompt\n\nYou are an expert TypeScript compiler error fixing agent specializing in resolving compilation errors in E2E test code that follows the `@nestia/e2e` testing framework conventions. If the error content is a complicated type problem, it is better to erase everything and re-squeeze it.\n\n## Your Role\n\n- Analyze the provided TypeScript code with compilation errors and generate the corrected version.\n- Focus specifically on the error location, message, and problematic code segment.\n- Maintain all existing functionality while resolving only the compilation issues.\n- Follow the established code patterns and conventions from the original E2E test code.\n- Use provided API Files and DTO Files to resolve module and type declaration issues.\n\n## Default Working Language: English\n\n- Use the language specified by user in messages as the working language when explicitly provided\n- All thinking and responses must be in the working language\n- All model/field names must be in English regardless of working language\n\n## Input Format\n\nYou will receive:\n\n1. **Original Code**: TypeScript E2E test code with compilation errors\n2. **Error Information**:\n\n   * Exact character position of the error\n   * Detailed error message from TypeScript compiler\n   * The specific problematic code segment\n3. **Instructions**: Specific guidance on what needs to be fixed\n4. **API Files**: Reference files containing available API functions and their paths\n5. **DTO Files**: Reference files containing available types and their import paths\n\n### 3. API Function Usage Corrections\n\n- Fix API function call patterns to follow:\n\n  ```ts\n  api.functional.[...].methodName(...)\n  ```\n\n- Correct connection parameter usage (avoid adding extra properties):\n\n  ```ts\n  // Correct\n  await api.functional.bbs.articles.post(connection, { body: articleBody });\n  ```\n\n- **Cross-reference API Files** to ensure function paths and method names are accurate\n\n### 4. Test Function Structure Fixes\n\n- Ensure test functions follow the pattern:\n\n  ```ts\n  export async function test_api_xxx(...): Promise<void> { ... }\n  ```\n\n- Fix async/await usage errors\n\n- Correct function parameter types (especially `connection: api.IConnection`)\n\n### 5. Typia Assert Corrections\n\n- Ensure proper `typia.assert<T>(value)` usage\n- Fix generic type parameters\n- Correct assertion patterns for response validation\n\n### 6. Array Type Corrections\n\n```\nerror: Argument of type 'IBbsArticleComment[]' is not assignable to parameter of type 'never[]'.\n```\n\n- To Resolve above Array parameter Error, If you declare empty array like `[]`, You must define the type of array together.\n\nExample:\n\n```typescript\nTestValidator.equals(\"message\")(\n    [] as IBbsArticleComment[],\n  )(data);\n```\n\n### 7. Common TypeScript Error Fixes\n\n- **Type mismatches**: Align variable types with expected interfaces from DTO Files\n- **Missing properties**: Add required properties to objects\n- **Async/Promise errors**: Fix Promise handling and async function signatures\n- **Generic type errors**: Correct generic type parameters\n- **Null/undefined handling**: Add proper null checks or optional chaining\n- **Interface compliance**: Ensure objects conform to their declared interfaces\n\n## Error Resolution Strategy\n\n1. **Full Code Analysis**: FIRST perform comprehensive analysis of ENTIRE codebase for ALL potential TypeScript issues\n2. **Error Chain Identification**: Identify cascading error patterns and relationships between different parts of code\n3. **Holistic Fix Planning**: Plan fixes for ALL related errors that could cause loops, not just the reported error\n4. **Batch Error Resolution**: Fix ALL identified issues simultaneously in logical groups:\n\n   * All type declaration issues together\n   * All function signature issues together\n   * All usage/call site issues together\n   * All test-related issues together\n5. **Context Preservation**: Maintain the original test logic and flow\n6. **Comprehensive Validation**: Ensure no new compilation errors or cascading issues are introduced\n7. **Pattern Consistency**: Keep existing code style and conventions throughout all fixes"
+}, {
+    id: v4(),
+    created_at: (new Date).toISOString(),
+    type: "systemMessage",
+    text: [ "You are the world's best TypeScript compiler error fixer.", "You will be given a **TypeScript code** with compilation errors, and your job is to fix the errors.", "", "# Rules", "- Follow the base E2E test style strictly. Never use other frameworks like Jest or Mocha.", "- Use `TestValidator.equals(...)` and `typia.assert(...)` to verify results.", "- Use `api.functional.XXX` for all API calls. These are defined in API Files.", "- Use helper functions like `generate_random_xxx(...)` **only if** they already exist in the base test imports.", "- Do not invent new helpers or use utilities that are not explicitly shown.", "- Keep all tests deterministic and reliable.", "", "# File References", `The import statements are automatically inserted based on the AST, which provides all necessary types and SDKs required.`, `Therefore, if an import is not automatically included,`, `it means that the corresponding type or SDK is not available for use in the current test code.`, `You must solve the issue using only the provided SDK and types.`, "", "## API Files", "```typescript", JSON.stringify(artifacts.sdk), "```", "", "## DTO Files", "```typescript", JSON.stringify(artifacts.dto), "```", "", "Now Fix the E2E test function based on the given error information.", "Only output a single `async function` named `test_api_{...}`. No explanation, no commentary." ].join("\n")
 } ];
 
 async function orchestrateTestCorrect(ctx, codes, scenarios, life = 4) {
@@ -9047,7 +9061,12 @@ async function orchestrateTestCorrect(ctx, codes, scenarios, life = 4) {
 
 async function step(ctx, entireFiles, testFiles, life) {
     const result = await ctx.compiler.typescript.compile({
-        files: entireFiles
+        files: {
+            ...entireFiles,
+            ...testFiles.map((el => ({
+                [el.location]: el.content
+            }))).reduce(((acc, cur) => Object.assign(acc, cur)), {})
+        }
     });
     if (result.type === "success") {
         return {
@@ -9120,11 +9139,18 @@ async function step(ctx, entireFiles, testFiles, life) {
         });
         return {
             location: filename,
-            content: code,
+            content: response.content,
             scenario
         };
     })));
-    return step(ctx, entireFiles, testFiles.map((f => {
+    return step(ctx, Object.entries(entireFiles).map((([filename, content]) => {
+        const overwritten = validatedFiles.find((el => el.location === filename));
+        return overwritten ? {
+            [overwritten.location]: overwritten.content
+        } : {
+            [filename]: content
+        };
+    })).reduce(((acc, cur) => Object.assign(acc, cur)), {}), testFiles.map((f => {
         const validated = validatedFiles.find((v => v.location === f.location));
         return validated ? validated : f;
     })), life - 1);
@@ -9135,6 +9161,15 @@ async function process$1(ctx, diagnostics, code, scenario) {
         value: null
     };
     const artifacts = await compileTestScenario(ctx, scenario);
+    const lines = code.split("\n").map(((line, num, arr) => {
+        const start = arr.slice(0, num).map((el => el.length + 1)).reduce(((acc, cur) => acc + cur), 0);
+        return {
+            line: num + 1,
+            text: line,
+            start,
+            end: start + line.length + 1
+        };
+    }));
     const agentica = new MicroAgentica({
         model: ctx.model,
         vendor: {
@@ -9143,7 +9178,7 @@ async function process$1(ctx, diagnostics, code, scenario) {
         config: {
             ...ctx.config ?? {}
         },
-        histories: transformTestCorrectHistories(artifacts),
+        histories: transformTestCorrectHistories(code, artifacts, diagnostics.map((diagnostic => diagnostic.start === undefined || diagnostic.length === undefined ? "" : formatDiagnostic(code, lines, diagnostic)))),
         controllers: [ createApplication$2({
             model: ctx.model,
             build: next => {
@@ -9154,18 +9189,81 @@ async function process$1(ctx, diagnostics, code, scenario) {
     });
     enforceToolCall(agentica);
     await randomBackoffRetry((async () => {
-        await agentica.conversate([ "Fix the compilation error in the provided code.", "", "## Original Code", "```typescript", code, "```", "", diagnostics.map((diagnostic => {
-            if (diagnostic.start === undefined || diagnostic.length === undefined) return "";
-            const checkDtoRegexp = `Cannot find module '@ORGANIZATION/template-api/lib/structures/IBbsArticleComment' or its corresponding type declarations.`;
-            const [group] = [ ...checkDtoRegexp.matchAll(/Cannot find module '(.*lib\/structures\/.*)'/g) ];
-            const [_, filename] = group ?? [];
-            return [ "## Error Information", `- Position: Characters ${diagnostic.start} to ${diagnostic.start + diagnostic.length}`, `- Error Message: ${diagnostic.messageText}`, `- Problematic Code: \`${code.substring(diagnostic.start, diagnostic.start + diagnostic.length)}\``, filename ? `The type files located under **/lib/structures are declared in '@ORGANIZATION/PROJECT-api/lib/structures'.\n` + `Note: '@ORGANIZATION/PROJECT-api' must be written exactly as is and should not be replaced.\n` : "" ].join("\n");
-        })), "## Instructions", "1. Focus on the specific error location and message", "2. Provide the corrected TypeScript code", "3. Ensure the fix resolves the compilation error", "", "Return only the fixed code without explanations." ].join("\n"));
+        await agentica.conversate([ "# Instructions", "1. Focus on the specific error location and message", "2. Provide the corrected TypeScript code", "3. Ensure the fix resolves the compilation error", "", "Return only the fixed code without explanations." ].join("\n"));
     }));
     if (pointer.value === null) throw new Error("Failed to modify test code.");
+    const typeReferences = Array.from(new Set(Object.keys(artifacts.document.components.schemas).map((key => key.split(".")[0]))));
+    pointer.value.content = pointer.value.content.replace(/^[ \t]*import\b[\s\S]*?;[ \t]*$/gm, "").trim();
+    pointer.value.content = [ `import { TestValidator } from "@nestia/e2e";`, `import typia, { tags } from "typia";`, "", `import api from "@ORGANIZATION/PROJECT-api";`, ...typeReferences.map((ref => `import type { ${ref} } from "@ORGANIZATION/PROJECT-api/lib/structures/${ref}";`)), "", pointer.value.content ].join("\n");
+    pointer.value.content = pointer.value.content.replaceAll('string & Format<"uuid">', 'string & tags.Format<"uuid">');
     return pointer.value;
 }
 
+function formatDiagnostic(code, lines, diagnostic) {
+    const {start, length, messageText} = diagnostic;
+    const message = messageText;
+    if (typeof start === "number" && typeof length === "number") {
+        const end = start + length;
+        const problematicCode = code.substring(start, end);
+        const errorLine = lines.find((line => line.end > start)) ?? null;
+        const lineText = errorLine?.text ?? "";
+        const hints = getHints(message, lineText);
+        function createAdjustedArray(n) {
+            let start = n - 2;
+            if (start < 0) {
+                start = 0;
+            }
+            return Array.from({
+                length: 5
+            }, ((_, i) => start + i));
+        }
+        const errorLines = createAdjustedArray(errorLine?.line ?? 0);
+        const context = errorLines.map((num => {
+            if (num === errorLine?.line) {
+                if (lines[num - 1]) {
+                    return `${lines[num - 1]?.text} // <- ERROR LINE (line:${num})`;
+                }
+            }
+            if (lines[num - 1]) {
+                return lines[num - 1]?.text;
+            }
+            return null;
+        })).filter((el => el !== null));
+        return [ "## Error Information", `- Position: Characters ${start} to ${end}`, `- Error Message: ${message}`, `- Error Lines: \n${context.length ? [ "\t```ts", ...context.map((el => `\t${el}`)), "\t```" ].join("\n") : "(none)"}`, `- Problematic Code: ${problematicCode.length > 0 ? `\`${problematicCode}\`` : "(none)"}`, ...hints.map((hint => `- Hint: ${hint}`)) ].join("\n");
+    }
+    return [ "## Error Information", `- Error Message: ${message}` ].join("\n");
+}
+
+function getHints(message, lineText) {
+    const isTestValidator = lineText.includes("TestValidator");
+    const isTypia = message === "Cannot find name 'Format'. Did you mean 'FormData'?";
+    const isJest = message === "Cannot find name 'expect'.";
+    const isCurrying = isTestValidator && message === "Expected 1 arguments, but got 2";
+    const isAssignability = /Argument of type '([^']+)' is not assignable to parameter of type '([^']+)'/.test(message);
+    const hints = [];
+    if (isTypia) {
+        hints.push("If you want to use typia tags, use `tags.Format` instead of `Format`.");
+    }
+    if (isJest) {
+        hints.push('Detected invalid `expect` usage. Use `TestValidator.equals("description")(expected)(actual)`.');
+    }
+    if (isCurrying) {
+        hints.push("`TestValidator.equals` is a curried function and must be called in **three steps**: `title → expected → actual`.");
+    } else if (isTestValidator) {
+        hints.push("The second argument `expected` must be assignable from the type of `actual`. Consider swapping the order if you get a type error.");
+    }
+    if (isAssignability && isTestValidator) {
+        const match = lineText.trim().match(/TestValidator\.equals\("([^"]+)"\)\(([^)]+)\)\(([^)]+)\)/);
+        if (match) {
+            const [, title, expected, actual] = match;
+            if (actual.includes(expected)) {
+                hints.push(`You can try rearranging the order like this: TestValidator.equals("${title}")(${actual})(${expected})`);
+            }
+        }
+    }
+    return hints;
+}
+
 function createApplication$2(props) {
     assertSchemaModel(props.model);
     const application = collection$3[props.model];
@@ -9464,7 +9562,7 @@ async function orchestrateTestScenario(ctx) {
     do {
         const matrix = divideArray({
             array: include,
-            capacity: 30
+            capacity: 5
         });
         await Promise.all(matrix.map((async _include => {
             exclude.push(...await execute(ctx, operations, _include, exclude.map((x => x.endpoint))));
@@ -9483,7 +9581,7 @@ async function orchestrateTestScenario(ctx) {
             endpoint: pg.endpoint,
             draft: plan.draft,
             functionName: plan.functionName,
-            dependencies: plan.dependsOn
+            dependencies: plan.dependencies
         }))))),
         created_at: (new Date).toISOString()
     };
@@ -9524,15 +9622,19 @@ const createHistoryProperties = (operations, include, exclude) => [ {
     id: v4(),
     created_at: (new Date).toISOString(),
     type: "systemMessage",
-    text: 'You are the AutoAPI Test Scenario Generator.\n\nYour job is to analyze an array of API operation objects and generate realistic, structured test scenario drafts for each operation.\n\n---\n\n## Input Format\n\nYou will receive an array of `Operation` objects structured like this:\n\n```ts\n{\n  method: "post" | "get" | "put" | "patch" | "delete",\n  path: "/path/to/resource",\n  specification: string,     // API specification with business logic and constraints\n  description: string,       // Multi-paragraph description\n  summary: string,           // One-line summary\n  parameters: [...],         // List of path/query/body parameters\n  requestBody?: {\n    typeName: string,\n    description: string\n  },\n  responseBody: {\n    typeName: string,\n    description: string\n  }\n}\n```\n\n---\n\n## Output Format\n\nYour output must be an array of grouped test plans, using the following structure:\n\n```ts\n[\n  {\n    method: "post",\n    path: "/shopping/products",\n    plans: [\n      {\n        draft: "Test product creation by submitting two requests with the same product.pid. Confirm that the second request returns a uniqueness constraint error.",\n        dependsOn: [\n          {\n            method: "post",\n            path: "/shopping/categories",\n            purpose: "Create a category beforehand so the product can reference it."\n          },\n          {\n            method: "get",\n            path: "/users/me",\n            purpose: "Verify a valid user session and obtain user context for the test."\n          }\n        ]\n      },\n      {\n        draft: "Verify that missing required fields like \'name\' or \'price\' trigger appropriate validation errors.",\n        dependsOn: []\n      }\n    ]\n  },\n  {\n    method: "patch",\n    path: "/shopping/products/{productId}",\n    plans: [\n      {\n        draft: "Attempt to update a product with an invalid productId and expect a 404 error.",\n        dependsOn: []\n      }\n    ]\n  }\n]\n```\n\n- Each top-level object is a **plan group** for a single unique endpoint (`method + path`).\n- The `plans` array contains **one or more test drafts** for that endpoint.\n- Each `draft` may list its **prerequisite API calls** in the `dependsOn` array, which includes `method`, `path`, and a `purpose` for context.\n\n---\n\n### ✅ **Uniqueness Rule**\n\n> ⚠️ **Each `{method} + {path}` combination must appear only once** in the output array.\n> This means **you must not create multiple plan groups with the same HTTP method and path.**\n\n* Treat each `{method} + {path}` pair as a **unique test identifier**.\n* All test plans (`plans`) related to the same endpoint must be **grouped under a single PlanGroup object**.\n* Duplicating PlanGroups for the same endpoint will lead to invalid output.\n\n**✅ Good:**\n\n```ts\n[\n  {\n    method: "patch",\n    path: "/blog/posts/{postId}",\n    plans: [\n      { draft: "...", dependsOn: [...] },\n      { draft: "...", dependsOn: [...] }\n    ]\n  }\n]\n```\n\n**❌ Bad:**\n\n```ts\n[\n  {\n    method: "patch",\n    path: "/blog/posts/{postId}",\n    plans: [ ... ]\n  },\n  {\n    method: "patch",\n    path: "/blog/posts/{postId}", // Duplicate! Not allowed.\n    plans: [ ... ]\n  }\n]\n```\n\n---\n\n## Writing Guidelines\n\n1. **draft**:\n   - Write a clear and realistic test plan for the operation.\n   - Include both success and failure cases where applicable.\n   - Incorporate constraints mentioned in the API description such as uniqueness, foreign key requirements, or authentication.\n   - For complex operations, include multiple steps within the same `draft` string (e.g., create → verify → delete).\n\n2. **dependsOn**:\n   - List other API operations that must be invoked before this test can be executed.\n   - Each item must include `method`, `path`, and `purpose`.\n   - The `purpose` field should explain *why* the dependency is needed in the test setup.\n\n3. Treat each `{method} + {path}` combination as a unique test identifier.\n\n---\n\n## Purpose\n\nThese test scenario objects are designed to support QA engineers and backend developers in planning automated or manual tests. Each test draft reflects the core functionality and business rules of the API to ensure robust system behavior.'
+    text: '# API Test Scenario Generator AI Agent System Prompt\n\n## 1. Overview\n\nYou are a specialized AI Agent for generating comprehensive API test scenarios based on provided API operation definitions. Your core mission is to analyze API endpoints and create realistic, business-logic-focused test scenario drafts that will later be used by developers to implement actual E2E test functions.\n\n\nYou will receive an array of API operation objects along with their specifications, descriptions, and parameters. Based on these materials, you must generate structured test scenario groups that encompass both success and failure cases, considering real-world business constraints and user workflows.\n\nYour role is **scenario planning**. You must think like a QA engineer who understands business logic and user journeys, creating comprehensive test plans that cover edge cases, validation rules, and complex multi-step processes.\n\nThe final deliverable must be a structured output containing scenario groups with detailed test drafts, dependency mappings, and clear function naming that reflects user-centric perspectives.\n\n## 2. Input Material Composition\n\n### 2.1. API Operations Array\n\n* Complete API operation definitions with summary, method and path\n* Business logic descriptions and constraints embedded in summary\n\n**Deep Analysis Requirements:**\n\n* **Business Domain Understanding**: Identify the business domain (e-commerce, content management, user authentication, etc.) and understand typical user workflows\n* **Entity Relationship Discovery**: Map relationships between different entities (users, products, orders, reviews, etc.) and understand their dependencies\n* **Workflow Pattern Recognition**: Identify common patterns like CRUD operations, authentication flows, approval processes, and multi-step transactions\n* **Constraint and Validation Rule Extraction**: Extract business rules, validation constraints, uniqueness requirements, and permission-based access controls\n* **User Journey Mapping**: Understand complete user journeys that span multiple API calls and identify realistic test scenarios\n\n### 2.2. Include/Exclude Lists\n\n* **Include List**: API endpoints that must be covered in the test scenarios being generated. These are the primary targets of the current test generation.\n* **Exclude List**: Endpoints that do not require new test scenarios in this iteration. However, these endpoints may still be referenced as **dependencies** in the scenario drafts if the current tests logically depend on their outcomes or data.\n\n**Deep Analysis Requirements:**\n\n* **Dependency Identification**: Understand which excluded endpoints can serve as prerequisites for included endpoints\n* **Coverage Gap Analysis**: Ensure all included endpoints have comprehensive test coverage without redundancy\n* **Cross-Reference Mapping**: Map relationships between included endpoints and available excluded endpoints for dependency planning\n\n## 3. Core Scenario Generation Principles\n\n### 3.1. Business Logic Focus Principle\n\n* **Real-World Scenarios**: Generate scenarios that reflect actual user workflows and business processes\n* **End-to-End Thinking**: Consider complete user journeys that may span multiple API calls\n* **Business Rule Validation**: Include scenarios that test business constraints, validation rules, and edge cases\n* **User Perspective**: Write scenarios from the user\'s perspective, focusing on what users are trying to accomplish\n\n### 3.2. Comprehensive Coverage Principle\n\n* **Success Path Coverage**: Ensure all primary business functions are covered with successful execution scenarios\n* **Failure Path Coverage**: Include validation failures, permission errors, resource not found cases, and business rule violations\n* **Edge Case Identification**: Consider boundary conditions, race conditions, and unusual but valid user behaviors\n* **State Transition Testing**: Test different states of entities and valid/invalid state transitions\n\n### 3.3. Dependency Management Principle\n\n* **Prerequisite Identification**: Clearly identify all API calls that must precede the target operation (only when explicitly required)\n* **Data Setup Requirements**: Understand what data must exist before testing specific scenarios\n* **Authentication Context**: Include necessary authentication and authorization setup steps\n* **Logical Ordering**: Ensure dependencies are listed in the correct execution order if step-by-step execution is required\n\n> ⚠️ **Note**: The `dependencies` field in a scenario is not a sequential execution plan. It is an indicative reference to other endpoints that this scenario relies on for logical or data setup context. If execution order is relevant, describe it explicitly in the `purpose` field of each dependency.\n\n### 3.4. Realistic Scenario Principle\n\n* **Authentic User Stories**: Create scenarios that represent real user needs and workflows\n* **Business Context Integration**: Embed scenarios within realistic business contexts (e.g., e-commerce purchase flows, content publication workflows)\n* **Multi-Step Process Modeling**: Model complex business processes that require multiple coordinated API calls\n* **Error Recovery Scenarios**: Include scenarios for how users recover from errors or complete alternative workflows\n\n### 3.5. Clear Communication Principle\n\n* **Descriptive Draft Writing**: Write clear, detailed scenario descriptions that developers can easily understand and implement\n* **Function Naming Clarity**: Create function names that immediately convey the user scenario being tested\n* **Dependency Purpose Explanation**: Clearly explain why each dependency is necessary for the test scenario\n* **Business Justification**: Explain the business value and importance of each test scenario\n\n## 4. Detailed Scenario Generation Guidelines\n\n### 4.1. API Analysis Methodology\n\n* **Domain Context Discovery**: Identify the business domain and understand typical user workflows within that domain\n* **Entity Relationship Mapping**: Map relationships between different entities and understand their lifecycle dependencies\n* **Permission Model Understanding**: Understand user roles, permissions, and access control patterns\n* **Business Process Identification**: Identify multi-step business processes that span multiple API endpoints\n* **Validation Rule Extraction**: Extract all validation rules, constraints, and business logic from API specifications\n\n### 4.2. Scenario Draft Structure\n\nEach scenario draft should include:\n\n* **Context Setting**: Brief explanation of the business context and user motivation\n* **Step-by-Step Process**: Detailed description of the testing process, including all necessary steps\n* **Expected Outcomes**: Clear description of what should happen in both success and failure cases\n* **Business Rule Validation**: Specific business rules or constraints being tested\n* **Data Requirements**: What data needs to be prepared or validated during testing\n\n### 4.3. Function Naming Guidelines\n\nFollow the user-centric naming convention:\n\n* **Prefix**: Must start with `test_`\n* **User Action**: Primary action the user is performing (create, get, update, delete, search, etc.)\n* **Target Resource**: What the user is interacting with (user, product, order, review, etc.)\n* **Scenario Context**: Specific situation or condition (valid\\_data, invalid\\_email, not\\_found, permission\\_denied, etc.)\n\n**Examples:**\n\n* `test_create_product_with_valid_data`\n* `test_update_product_price_without_permission`\n* `test_search_products_with_empty_results`\n* `test_delete_product_that_does_not_exist`\n\n### 4.4. Dependency Identification Process\n\n* **Prerequisite Data Creation**: Identify what entities must be created before testing the target endpoint\n* **Authentication Setup**: Determine necessary authentication and authorization steps\n* **State Preparation**: Understand what system state must be established before testing\n* **Resource Relationship**: Map relationships between resources and identify dependent resource creation\n\n### 4.5. Multi-Scenario Planning\n\nFor complex endpoints, generate multiple scenarios covering:\n\n* **Happy Path**: Successful execution with valid data\n* **Validation Errors**: Various types of input validation failures\n* **Permission Errors**: Unauthorized access attempts\n* **Resource State Errors**: Operations on resources in invalid states\n* **Business Rule Violations**: Attempts to violate domain-specific business rules\n\n## 5. Dependency Purpose Guidelines\n\n* **The `dependencies` array refers to relevant API calls this scenario logically depends on, whether or not they are in the include list.**\n* **The presence of a dependency does not imply that it must be executed immediately beforehand.**\n* **Execution order, if required, should be explained in the `purpose`.**\n\nExample:\n\n```yaml\n  dependencies:\n    - endpoint: { method: "post", path: "/posts" }\n      functionName: "test_create_post_with_valid_data"\n      purpose: "Create a post and extract postId for use in voting scenario"\n```\n\n## 6. Error Scenario Guidelines\n\n### 6.1. Purpose and Importance of Error Scenarios\n\nTest scenarios must cover not only successful business flows but also various error conditions to ensure robust system behavior. Error scenarios help verify that appropriate responses are returned for invalid inputs, unauthorized access, resource conflicts, and business rule violations.\n\n### 6.2. Error Scenario Categories\n\n* **Validation Errors**: Invalid input data, missing required fields, format violations\n* **Authentication/Authorization Errors**: Unauthorized access, insufficient permissions, expired sessions\n* **Resource State Errors**: Operations on non-existent resources, invalid state transitions\n* **Business Rule Violations**: Attempts to violate domain-specific constraints and rules\n* **System Constraint Violations**: Duplicate resource creation, referential integrity violations\n\n### 6.3. Error Scenario Writing Guidelines\n\n* **Specific Error Conditions**: Clearly define the error condition being tested\n* **Expected Error Response**: Specify what type of error response should be returned\n* **Realistic Error Situations**: Model error conditions that actually occur in real usage\n* **Recovery Scenarios**: Consider how users might recover from or handle error conditions\n\n\n### 6.4. Error Scenario Example\n\n```typescript\n{\n  draft: "Test product creation failure caused by attempting to create a product with a duplicate SKU. First, create a seller account authorized to create products. Then, create an initial product with a specific SKU to set up the conflict condition. Finally, attempt to create another product with the same SKU and verify that the system returns a conflict error indicating SKU uniqueness violation. Note that these steps must be executed in order to properly simulate the scenario.",\n  functionName: "test_create_product_with_duplicate_sku",\n  dependencies: [\n    {\n      endpoint: { method: "post", path: "/shopping/sellers/auth/join" },\n      purpose: "Create a seller account with permission to create products. This must be done first to ensure proper authorization."\n    },\n    {\n      endpoint: { method: "post", path: "/shopping/sellers/sales" },\n      purpose: "Create the first product with a specific SKU to establish the conflict condition. This must be done after seller creation."\n    }\n  ]\n}\n````\n\n---\n\n**Additional Notes:**\n\n* It is critical to explicitly declare *all* prerequisite API calls necessary to prepare the test context within the `dependencies` array.\n* Dependencies represent logical requirements for the scenario and may or may not require strict execution order.\n* When there *is* a required sequence, such as creating a user before creating a product tied to that user, you **must** clearly indicate this order either in the scenario’s `draft` description or in the `purpose` explanation of each dependency.\n* This explicit approach prevents using placeholder or fake data (like dummy UUIDs) and instead ensures that all data setup is conducted via real API calls, increasing test reliability and maintainability.\n* Providing clear and detailed `draft` text describing the full user workflow and error expectations helps downstream agents or developers generate complete and realistic test implementations.\n\nBy following these guidelines, generated test scenarios will be comprehensive, accurate, and fully grounded in the actual API ecosystem and business logic.\n\n\n\n\n## 7. Final Checklist\n\n### 7.1. Essential Element Verification\n\n* [ ] Are all included endpoints covered with appropriate scenarios?\n* [ ] Do scenarios reflect realistic business workflows and user journeys?\n* [ ] Are function names descriptive and follow the user-centric naming convention?\n* [ ] Are all necessary dependencies identified and properly ordered?\n* [ ] Do dependency purposes clearly explain why each prerequisite is needed?\n* [ ] Are both success and failure scenarios included for complex operations?\n* [ ] Do scenarios test relevant business rules and validation constraints?\n\n### 7.2. Quality Element Verification\n\n* [ ] Are scenario descriptions detailed enough for developers to implement?\n* [ ] Do scenarios represent authentic user needs and workflows?\n* [ ] Is the business context clearly explained for each scenario?\n* [ ] Are error scenarios realistic and cover important failure conditions?\n* [ ] Do multi-step scenarios include all necessary intermediate steps?\n* [ ] Are scenarios grouped logically by endpoint and functionality?\n\n### 7.3. Structural Verification\n\n* [ ] Does the output follow the correct IAutoBeTestScenarioApplication.IProps structure?\n* [ ] Are all endpoint objects properly formatted with method and path?\n* [ ] Do all scenarios include required fields (draft, functionName, dependencies)?\n* [ ] Are dependency objects complete with endpoint and purpose information?\n* [ ] Is each endpoint method/path combination unique in the scenario groups?\n\n## 7. Quality Standards\n\n### 7.1. Completeness\n- **Comprehensive Coverage**: All included endpoints have appropriate test scenarios\n- **Multi-Perspective Testing**: Include scenarios from different user roles and perspectives\n- **Edge Case Inclusion**: Cover boundary conditions, error cases, and unusual but valid scenarios\n- **Business Rule Coverage**: Test all relevant business rules and constraints\n\n### 7.2. Clarity and Usability\n- **Clear Scenario Descriptions**: Write scenarios that developers can easily understand and implement\n- **Logical Dependency Ordering**: List dependencies in the correct execution order\n- **Meaningful Function Names**: Create function names that clearly convey the test purpose\n- **Business Context**: Provide sufficient business context for understanding scenario importance\n\n### 7.3. Realistic Applicability\n- **Real-World Relevance**: Generate scenarios that reflect actual user workflows and business needs\n- **Implementation Feasibility**: Ensure scenarios can be realistically implemented using available APIs\n- **Business Value**: Focus on scenarios that test important business functionality\n- **User-Centric Design**: Write scenarios from the user\'s perspective and goals\n\n## 8. Error Scenario Generation (Appendix)\n\n### 8.1. Purpose and Importance of Error Scenarios\nTest scenarios must cover not only successful business flows but also various error conditions to ensure robust system behavior. Error scenarios help verify that appropriate responses are returned for invalid inputs, unauthorized access, resource conflicts, and business rule violations.\n\n### 8.2. Error Scenario Categories\n- **Validation Errors**: Invalid input data, missing required fields, format violations\n- **Authentication/Authorization Errors**: Unauthorized access, insufficient permissions, expired sessions\n- **Resource State Errors**: Operations on non-existent resources, invalid state transitions\n- **Business Rule Violations**: Attempts to violate domain-specific constraints and rules\n- **System Constraint Violations**: Duplicate resource creation, referential integrity violations\n\n### 8.3. Error Scenario Writing Guidelines\n- **Specific Error Conditions**: Clearly define the error condition being tested\n- **Expected Error Response**: Specify what type of error response should be returned\n- **Realistic Error Situations**: Model error conditions that actually occur in real usage\n- **Recovery Scenarios**: Consider how users might recover from or handle error conditions\n\n### 8.4. Error Scenario Example\n```typescript\n{\n  draft: "Test product creation failure when attempting to create a product with a duplicate SKU. Create an initial product with a specific SKU, then attempt to create another product with the same SKU. Verify that the system returns a conflict error indicating SKU uniqueness violation.",\n  functionName: "test_create_product_with_duplicate_sku",\n  dependencies: [\n    {\n      endpoint: { method: "post", path: "/shopping/sellers/auth/join" },\n      purpose: "Create a seller account with permission to create products"\n    },\n    {\n      endpoint: { method: "post", path: "/shopping/sellers/sales" },\n      purpose: "Create the first product with a specific SKU to establish the conflict condition"\n    }\n  ]\n}\n```\n\n## 9. Final Checklist\n\nTest scenario generation completion requires verification of the following items:\n\n### 9.1. Essential Element Verification\n- [ ] Are all included endpoints covered with appropriate scenarios?\n- [ ] Do scenarios reflect realistic business workflows and user journeys?\n- [ ] Are function names descriptive and follow the user-centric naming convention?\n- [ ] Are all necessary dependencies identified and properly ordered?\n- [ ] Do dependency purposes clearly explain why each prerequisite is needed?\n- [ ] Are both success and failure scenarios included for complex operations?\n- [ ] Do scenarios test relevant business rules and validation constraints?\n\n### 9.2. Quality Element Verification\n- [ ] Are scenario descriptions detailed enough for developers to implement?\n- [ ] Do scenarios represent authentic user needs and workflows?\n- [ ] Is the business context clearly explained for each scenario?\n- [ ] Are error scenarios realistic and cover important failure conditions?\n- [ ] Do multi-step scenarios include all necessary intermediate steps?\n- [ ] Are scenarios grouped logically by endpoint and functionality?\n\n### 9.3. Structural Verification\n- [ ] Does the output follow the correct IAutoBeTestScenarioApplication.IProps structure?\n- [ ] Are all endpoint objects properly formatted with method and path?\n- [ ] Do all scenarios include required fields (draft, functionName, dependencies)?\n- [ ] Are dependency objects complete with endpoint and purpose information?\n- [ ] Is each endpoint method/path combination unique in the scenario groups?\n\nPlease adhere to all these principles and guidelines to generate comprehensive and accurate API test scenarios. Your mission is to create scenario blueprints that enable developers to build robust, business-focused E2E test suites that thoroughly validate API functionality and business logic.'
 }, {
     id: v4(),
     created_at: (new Date).toISOString(),
     type: "systemMessage",
-    text: [ "Below are the full operations. Please refer to this.", "Your role is to draft all test cases for each given Operation.", "It is also permissible to write multiple test codes on a single endpoint.", "However, rather than meaningless tests, business logic tests should be written and an E2E test situation should be assumed.", "", "```json", JSON.stringify(operations.map((el => ({
+    text: [ "# Operations", "Below are the full operations. Please refer to this.", "Your role is to draft all test cases for each given Operation.", "It is also permissible to write multiple test codes on a single endpoint.", "However, rather than meaningless tests, business logic tests should be written and an E2E test situation should be assumed.", "", "Please carefully analyze each operation to identify all dependencies required for testing.", "For example, if you want to test liking and then deleting a post,", "you might think to test post creation, liking, and unlike operations.", "However, even if not explicitly mentioned, user registration and login are essential prerequisites.", "Pay close attention to IDs and related values in the API,", "and ensure you identify all dependencies between endpoints.", "", "```json", JSON.stringify(operations.map((el => ({
         path: el.path,
         method: el.method,
-        summary: el.summary
+        summary: el.summary,
+        description: el.description,
+        parameters: el.parameters,
+        requestBody: el.requestBody,
+        responseBody: el.responseBody
     })))), "```" ].join("\n")
 }, {
     id: v4(),
@@ -9549,7 +9651,7 @@ function createApplication$1(props) {
             const _io0 = input => Array.isArray(input.scenarioGroups) && input.scenarioGroups.every((elem => "object" === typeof elem && null !== elem && _io1(elem)));
             const _io1 = input => "object" === typeof input.endpoint && null !== input.endpoint && _io2(input.endpoint) && (Array.isArray(input.scenarios) && input.scenarios.every((elem => "object" === typeof elem && null !== elem && _io3(elem))));
             const _io2 = input => "string" === typeof input.path && ("get" === input.method || "post" === input.method || "put" === input.method || "delete" === input.method || "patch" === input.method);
-            const _io3 = input => "string" === typeof input.draft && "string" === typeof input.functionName && (Array.isArray(input.dependsOn) && input.dependsOn.every((elem => "object" === typeof elem && null !== elem && _io4(elem))));
+            const _io3 = input => "string" === typeof input.draft && "string" === typeof input.functionName && (Array.isArray(input.dependencies) && input.dependencies.every((elem => "object" === typeof elem && null !== elem && _io4(elem))));
             const _io4 = input => "object" === typeof input.endpoint && null !== input.endpoint && _io2(input.endpoint) && "string" === typeof input.purpose;
             const _vo0 = (input, _path, _exceptionable = true) => [ (Array.isArray(input.scenarioGroups) || _report(_exceptionable, {
                 path: _path + ".scenarioGroups",
@@ -9610,22 +9712,22 @@ function createApplication$1(props) {
                 path: _path + ".functionName",
                 expected: "string",
                 value: input.functionName
-            }), (Array.isArray(input.dependsOn) || _report(_exceptionable, {
-                path: _path + ".dependsOn",
-                expected: "Array<IAutoBeTestScenarioApplication.IDependsOn>",
-                value: input.dependsOn
-            })) && input.dependsOn.map(((elem, _index6) => ("object" === typeof elem && null !== elem || _report(_exceptionable, {
-                path: _path + ".dependsOn[" + _index6 + "]",
-                expected: "IAutoBeTestScenarioApplication.IDependsOn",
+            }), (Array.isArray(input.dependencies) || _report(_exceptionable, {
+                path: _path + ".dependencies",
+                expected: "Array<IAutoBeTestScenarioApplication.IDependencies>",
+                value: input.dependencies
+            })) && input.dependencies.map(((elem, _index6) => ("object" === typeof elem && null !== elem || _report(_exceptionable, {
+                path: _path + ".dependencies[" + _index6 + "]",
+                expected: "IAutoBeTestScenarioApplication.IDependencies",
                 value: elem
-            })) && _vo4(elem, _path + ".dependsOn[" + _index6 + "]", _exceptionable) || _report(_exceptionable, {
-                path: _path + ".dependsOn[" + _index6 + "]",
-                expected: "IAutoBeTestScenarioApplication.IDependsOn",
+            })) && _vo4(elem, _path + ".dependencies[" + _index6 + "]", _exceptionable) || _report(_exceptionable, {
+                path: _path + ".dependencies[" + _index6 + "]",
+                expected: "IAutoBeTestScenarioApplication.IDependencies",
                 value: elem
             }))).every((flag => flag)) || _report(_exceptionable, {
-                path: _path + ".dependsOn",
-                expected: "Array<IAutoBeTestScenarioApplication.IDependsOn>",
-                value: input.dependsOn
+                path: _path + ".dependencies",
+                expected: "Array<IAutoBeTestScenarioApplication.IDependencies>",
+                value: input.dependencies
             }) ].every((flag => flag));
             const _vo4 = (input, _path, _exceptionable = true) => [ ("object" === typeof input.endpoint && null !== input.endpoint || _report(_exceptionable, {
                 path: _path + ".endpoint",
@@ -9768,11 +9870,11 @@ const claude$2 = {
                                 description: "Array of test scenarios.",
                                 type: "array",
                                 items: {
-                                    description: "Description of the current {@link IAutoBeTestScenarioApplication.IScenario} type:\n\n> Represents a test scenario for a single API operation.\n> \n> This interface extends `AutoBeOpenApi.IEndpoint`, inheriting its HTTP\n> method and path information, and adds two key properties:\n> \n> - `draft`: A free-form, human-readable test scenario description for the API\n>   endpoint.\n> - `dependsOn`: A list of other API endpoints that must be invoked beforehand\n>   in order to prepare the context for this test. Each dependency includes\n>   the purpose of the dependency.\n> \n> This structure is intended to help organize test specifications for complex\n> workflows and ensure that all prerequisites are explicitly declared.",
+                                    description: "Description of the current {@link IAutoBeTestScenarioApplication.IScenario} type:\n\n> Represents a test scenario for a single API operation.\n> \n> This interface defines a structured, user-centric test draft that includes\n> a descriptive function name, a detailed scenario draft, and logical\n> dependencies on other endpoints required for context or setup.",
                                     type: "object",
                                     properties: {
                                         draft: {
-                                            description: "A detailed natural language description of how this API endpoint should\nbe tested. This should include both successful and failure scenarios,\nbusiness rule validations, edge cases, and any sequence of steps\nnecessary to perform the test. A subsequent agent will use this draft to\ngenerate multiple test scenarios.",
+                                            description: "A detailed natural language description of how this API endpoint should\nbe tested. This should include both successful and failure scenarios,\nbusiness rule validations, edge cases, and any sequence of steps\nnecessary to perform the test. A subsequent agent will use this draft to\ngenerate multiple concrete test cases.",
                                             type: "string"
                                         },
                                         functionName: {
@@ -9780,15 +9882,16 @@ const claude$2 = {
                                             description: "Descriptive function name derived from the user scenario.\n\nThe function name serves as a concise, technical identifier that clearly\nrepresents the specific user scenario being described. It should be\nimmediately understandable and directly correspond to the user situation\nwithout requiring additional context.\n\n## Naming Convention\n\n- Must start with `test_` prefix (mandatory requirement)\n- Use snake_case formatting throughout\n- Include the primary user action (create, get, update, delete, list, etc.)\n- Specify the target resource (user, product, order, profile, etc.)\n- Add scenario-specific context (valid_data, invalid_email, not_found,\n  etc.)\n\n## Content Structure\n\nFunction names should follow this pattern:\n`test_[user_action]_[resource]_[scenario_context]`\n\nWhere:\n\n- `user_action`: What the user is trying to do\n- `resource`: What the user is interacting with\n- `scenario_context`: The specific situation or condition\n\n## User-Focused Examples\n\n- `test_create_user_profile_with_complete_information` - User providing all\n  available profile data\n- `test_retrieve_user_profile_when_profile_exists` - User accessing their\n  existing profile\n- `test_update_user_email_with_valid_new_address` - User changing their\n  email to a valid new one\n- `test_delete_user_account_when_user_lacks_permission` - User attempting\n  account deletion without authorization\n- `test_search_user_profiles_with_pagination_preferences` - User browsing\n  profiles with specific pagination\n\n## Clarity Guidelines\n\n- Prioritize clarity over brevity\n- Avoid technical jargon or implementation terms\n- Use terminology that reflects user perspective\n- Ensure the name alone conveys the user's intent\n- Make it understandable to non-technical stakeholders\n- Keep consistent with user scenario description\n\n## Single Endpoint Alignment\n\nFunction names must reflect scenarios that:\n\n- Accomplish user goals through this single endpoint only\n- Don't imply dependency on other API operations\n- Represent complete user interactions",
                                             type: "string"
                                         },
-                                        dependsOn: {
-                                            description: "A list of other API endpoints that must be executed before this test\nscenario. This helps express dependencies such as data creation or\nauthentication steps required to reach the intended test state.",
+                                        dependencies: {
+                                            title: "A list of other API endpoints that this scenario logically depends on",
+                                            description: "A list of other API endpoints that this scenario logically depends on.\n\nThese dependencies represent context or prerequisite conditions, such as\nauthentication, resource creation, or data setup, that are relevant to\nthe test. This list is not a strict execution order — if ordering is\nimportant, it must be described explicitly in the `purpose`.",
                                             type: "array",
                                             items: {
-                                                description: "Current Type: {@link IAutoBeTestScenarioApplication.IDependsOn}",
+                                                description: "Current Type: {@link IAutoBeTestScenarioApplication.IDependencies}",
                                                 type: "object",
                                                 properties: {
                                                     endpoint: {
-                                                        description: "Target API endpoint that must be executed before the main operation.\n\n------------------------------\n\nDescription of the current {@link AutoBeOpenApi.IEndpoint} type:\n\n> API endpoint information.",
+                                                        description: "Target API endpoint that this scenario depends on.\n\n------------------------------\n\nDescription of the current {@link AutoBeOpenApi.IEndpoint} type:\n\n> API endpoint information.",
                                                         type: "object",
                                                         properties: {
                                                             path: {
@@ -9815,7 +9918,7 @@ const claude$2 = {
                                                         required: [ "path", "method" ]
                                                     },
                                                     purpose: {
-                                                        description: 'A concise exscenarioation of why this API call is required before\nexecuting the test for the main operation.\n\nExample: "Creates a category so that a product can be linked to it during\ncreation."',
+                                                        description: 'A concise explanation of why this API call is relevant or required for\nthe main test scenario.\n\nThis should describe the contextual or setup role of the dependency, such\nas creating necessary data or establishing user authentication.\n\nExample: "Creates a category so that a product can be linked to it during\ncreation."',
                                                         type: "string"
                                                     }
                                                 },
@@ -9823,7 +9926,7 @@ const claude$2 = {
                                             }
                                         }
                                     },
-                                    required: [ "draft", "functionName", "dependsOn" ]
+                                    required: [ "draft", "functionName", "dependencies" ]
                                 }
                             }
                         },
@@ -9840,7 +9943,7 @@ const claude$2 = {
             const _io0 = input => Array.isArray(input.scenarioGroups) && input.scenarioGroups.every((elem => "object" === typeof elem && null !== elem && _io1(elem)));
             const _io1 = input => "object" === typeof input.endpoint && null !== input.endpoint && _io2(input.endpoint) && (Array.isArray(input.scenarios) && input.scenarios.every((elem => "object" === typeof elem && null !== elem && _io3(elem))));
             const _io2 = input => "string" === typeof input.path && ("get" === input.method || "post" === input.method || "put" === input.method || "delete" === input.method || "patch" === input.method);
-            const _io3 = input => "string" === typeof input.draft && "string" === typeof input.functionName && (Array.isArray(input.dependsOn) && input.dependsOn.every((elem => "object" === typeof elem && null !== elem && _io4(elem))));
+            const _io3 = input => "string" === typeof input.draft && "string" === typeof input.functionName && (Array.isArray(input.dependencies) && input.dependencies.every((elem => "object" === typeof elem && null !== elem && _io4(elem))));
             const _io4 = input => "object" === typeof input.endpoint && null !== input.endpoint && _io2(input.endpoint) && "string" === typeof input.purpose;
             const _vo0 = (input, _path, _exceptionable = true) => [ (Array.isArray(input.scenarioGroups) || _report(_exceptionable, {
                 path: _path + ".scenarioGroups",
@@ -9901,22 +10004,22 @@ const claude$2 = {
                 path: _path + ".functionName",
                 expected: "string",
                 value: input.functionName
-            }), (Array.isArray(input.dependsOn) || _report(_exceptionable, {
-                path: _path + ".dependsOn",
-                expected: "Array<IAutoBeTestScenarioApplication.IDependsOn>",
-                value: input.dependsOn
-            })) && input.dependsOn.map(((elem, _index6) => ("object" === typeof elem && null !== elem || _report(_exceptionable, {
-                path: _path + ".dependsOn[" + _index6 + "]",
-                expected: "IAutoBeTestScenarioApplication.IDependsOn",
+            }), (Array.isArray(input.dependencies) || _report(_exceptionable, {
+                path: _path + ".dependencies",
+                expected: "Array<IAutoBeTestScenarioApplication.IDependencies>",
+                value: input.dependencies
+            })) && input.dependencies.map(((elem, _index6) => ("object" === typeof elem && null !== elem || _report(_exceptionable, {
+                path: _path + ".dependencies[" + _index6 + "]",
+                expected: "IAutoBeTestScenarioApplication.IDependencies",
                 value: elem
-            })) && _vo4(elem, _path + ".dependsOn[" + _index6 + "]", _exceptionable) || _report(_exceptionable, {
-                path: _path + ".dependsOn[" + _index6 + "]",
-                expected: "IAutoBeTestScenarioApplication.IDependsOn",
+            })) && _vo4(elem, _path + ".dependencies[" + _index6 + "]", _exceptionable) || _report(_exceptionable, {
+                path: _path + ".dependencies[" + _index6 + "]",
+                expected: "IAutoBeTestScenarioApplication.IDependencies",
                 value: elem
             }))).every((flag => flag)) || _report(_exceptionable, {
-                path: _path + ".dependsOn",
-                expected: "Array<IAutoBeTestScenarioApplication.IDependsOn>",
-                value: input.dependsOn
+                path: _path + ".dependencies",
+                expected: "Array<IAutoBeTestScenarioApplication.IDependencies>",
+                value: input.dependencies
             }) ].every((flag => flag));
             const _vo4 = (input, _path, _exceptionable = true) => [ ("object" === typeof input.endpoint && null !== input.endpoint || _report(_exceptionable, {
                 path: _path + ".endpoint",
@@ -10011,11 +10114,11 @@ const collection$2 = {
                                     description: "Array of test scenarios.",
                                     type: "array",
                                     items: {
-                                        description: "Description of the current {@link IAutoBeTestScenarioApplication.IScenario} type:\n\n> Represents a test scenario for a single API operation.\n> \n> This interface extends `AutoBeOpenApi.IEndpoint`, inheriting its HTTP\n> method and path information, and adds two key properties:\n> \n> - `draft`: A free-form, human-readable test scenario description for the API\n>   endpoint.\n> - `dependsOn`: A list of other API endpoints that must be invoked beforehand\n>   in order to prepare the context for this test. Each dependency includes\n>   the purpose of the dependency.\n> \n> This structure is intended to help organize test specifications for complex\n> workflows and ensure that all prerequisites are explicitly declared.",
+                                        description: "Description of the current {@link IAutoBeTestScenarioApplication.IScenario} type:\n\n> Represents a test scenario for a single API operation.\n> \n> This interface defines a structured, user-centric test draft that includes\n> a descriptive function name, a detailed scenario draft, and logical\n> dependencies on other endpoints required for context or setup.",
                                         type: "object",
                                         properties: {
                                             draft: {
-                                                description: "A detailed natural language description of how this API endpoint should\nbe tested. This should include both successful and failure scenarios,\nbusiness rule validations, edge cases, and any sequence of steps\nnecessary to perform the test. A subsequent agent will use this draft to\ngenerate multiple test scenarios.",
+                                                description: "A detailed natural language description of how this API endpoint should\nbe tested. This should include both successful and failure scenarios,\nbusiness rule validations, edge cases, and any sequence of steps\nnecessary to perform the test. A subsequent agent will use this draft to\ngenerate multiple concrete test cases.",
                                                 type: "string"
                                             },
                                             functionName: {
@@ -10023,15 +10126,16 @@ const collection$2 = {
                                                 description: "Descriptive function name derived from the user scenario.\n\nThe function name serves as a concise, technical identifier that clearly\nrepresents the specific user scenario being described. It should be\nimmediately understandable and directly correspond to the user situation\nwithout requiring additional context.\n\n## Naming Convention\n\n- Must start with `test_` prefix (mandatory requirement)\n- Use snake_case formatting throughout\n- Include the primary user action (create, get, update, delete, list, etc.)\n- Specify the target resource (user, product, order, profile, etc.)\n- Add scenario-specific context (valid_data, invalid_email, not_found,\n  etc.)\n\n## Content Structure\n\nFunction names should follow this pattern:\n`test_[user_action]_[resource]_[scenario_context]`\n\nWhere:\n\n- `user_action`: What the user is trying to do\n- `resource`: What the user is interacting with\n- `scenario_context`: The specific situation or condition\n\n## User-Focused Examples\n\n- `test_create_user_profile_with_complete_information` - User providing all\n  available profile data\n- `test_retrieve_user_profile_when_profile_exists` - User accessing their\n  existing profile\n- `test_update_user_email_with_valid_new_address` - User changing their\n  email to a valid new one\n- `test_delete_user_account_when_user_lacks_permission` - User attempting\n  account deletion without authorization\n- `test_search_user_profiles_with_pagination_preferences` - User browsing\n  profiles with specific pagination\n\n## Clarity Guidelines\n\n- Prioritize clarity over brevity\n- Avoid technical jargon or implementation terms\n- Use terminology that reflects user perspective\n- Ensure the name alone conveys the user's intent\n- Make it understandable to non-technical stakeholders\n- Keep consistent with user scenario description\n\n## Single Endpoint Alignment\n\nFunction names must reflect scenarios that:\n\n- Accomplish user goals through this single endpoint only\n- Don't imply dependency on other API operations\n- Represent complete user interactions",
                                                 type: "string"
                                             },
-                                            dependsOn: {
-                                                description: "A list of other API endpoints that must be executed before this test\nscenario. This helps express dependencies such as data creation or\nauthentication steps required to reach the intended test state.",
+                                            dependencies: {
+                                                title: "A list of other API endpoints that this scenario logically depends on",
+                                                description: "A list of other API endpoints that this scenario logically depends on.\n\nThese dependencies represent context or prerequisite conditions, such as\nauthentication, resource creation, or data setup, that are relevant to\nthe test. This list is not a strict execution order — if ordering is\nimportant, it must be described explicitly in the `purpose`.",
                                                 type: "array",
                                                 items: {
-                                                    description: "Current Type: {@link IAutoBeTestScenarioApplication.IDependsOn}",
+                                                    description: "Current Type: {@link IAutoBeTestScenarioApplication.IDependencies}",
                                                     type: "object",
                                                     properties: {
                                                         endpoint: {
-                                                            description: "Target API endpoint that must be executed before the main operation.\n\n------------------------------\n\nDescription of the current {@link AutoBeOpenApi.IEndpoint} type:\n\n> API endpoint information.",
+                                                            description: "Target API endpoint that this scenario depends on.\n\n------------------------------\n\nDescription of the current {@link AutoBeOpenApi.IEndpoint} type:\n\n> API endpoint information.",
                                                             type: "object",
                                                             properties: {
                                                                 path: {
@@ -10049,7 +10153,7 @@ const collection$2 = {
                                                             required: [ "path", "method" ]
                                                         },
                                                         purpose: {
-                                                            description: 'A concise exscenarioation of why this API call is required before\nexecuting the test for the main operation.\n\nExample: "Creates a category so that a product can be linked to it during\ncreation."',
+                                                            description: 'A concise explanation of why this API call is relevant or required for\nthe main test scenario.\n\nThis should describe the contextual or setup role of the dependency, such\nas creating necessary data or establishing user authentication.\n\nExample: "Creates a category so that a product can be linked to it during\ncreation."',
                                                             type: "string"
                                                         }
                                                     },
@@ -10057,7 +10161,7 @@ const collection$2 = {
                                                 }
                                             }
                                         },
-                                        required: [ "draft", "functionName", "dependsOn" ]
+                                        required: [ "draft", "functionName", "dependencies" ]
                                     }
                                 }
                             },
@@ -10074,7 +10178,7 @@ const collection$2 = {
                 const _io0 = input => Array.isArray(input.scenarioGroups) && input.scenarioGroups.every((elem => "object" === typeof elem && null !== elem && _io1(elem)));
                 const _io1 = input => "object" === typeof input.endpoint && null !== input.endpoint && _io2(input.endpoint) && (Array.isArray(input.scenarios) && input.scenarios.every((elem => "object" === typeof elem && null !== elem && _io3(elem))));
                 const _io2 = input => "string" === typeof input.path && ("get" === input.method || "post" === input.method || "put" === input.method || "delete" === input.method || "patch" === input.method);
-                const _io3 = input => "string" === typeof input.draft && "string" === typeof input.functionName && (Array.isArray(input.dependsOn) && input.dependsOn.every((elem => "object" === typeof elem && null !== elem && _io4(elem))));
+                const _io3 = input => "string" === typeof input.draft && "string" === typeof input.functionName && (Array.isArray(input.dependencies) && input.dependencies.every((elem => "object" === typeof elem && null !== elem && _io4(elem))));
                 const _io4 = input => "object" === typeof input.endpoint && null !== input.endpoint && _io2(input.endpoint) && "string" === typeof input.purpose;
                 const _vo0 = (input, _path, _exceptionable = true) => [ (Array.isArray(input.scenarioGroups) || _report(_exceptionable, {
                     path: _path + ".scenarioGroups",
@@ -10135,22 +10239,22 @@ const collection$2 = {
                     path: _path + ".functionName",
                     expected: "string",
                     value: input.functionName
-                }), (Array.isArray(input.dependsOn) || _report(_exceptionable, {
-                    path: _path + ".dependsOn",
-                    expected: "Array<IAutoBeTestScenarioApplication.IDependsOn>",
-                    value: input.dependsOn
-                })) && input.dependsOn.map(((elem, _index6) => ("object" === typeof elem && null !== elem || _report(_exceptionable, {
-                    path: _path + ".dependsOn[" + _index6 + "]",
-                    expected: "IAutoBeTestScenarioApplication.IDependsOn",
+                }), (Array.isArray(input.dependencies) || _report(_exceptionable, {
+                    path: _path + ".dependencies",
+                    expected: "Array<IAutoBeTestScenarioApplication.IDependencies>",
+                    value: input.dependencies
+                })) && input.dependencies.map(((elem, _index6) => ("object" === typeof elem && null !== elem || _report(_exceptionable, {
+                    path: _path + ".dependencies[" + _index6 + "]",
+                    expected: "IAutoBeTestScenarioApplication.IDependencies",
                     value: elem
-                })) && _vo4(elem, _path + ".dependsOn[" + _index6 + "]", _exceptionable) || _report(_exceptionable, {
-                    path: _path + ".dependsOn[" + _index6 + "]",
-                    expected: "IAutoBeTestScenarioApplication.IDependsOn",
+                })) && _vo4(elem, _path + ".dependencies[" + _index6 + "]", _exceptionable) || _report(_exceptionable, {
+                    path: _path + ".dependencies[" + _index6 + "]",
+                    expected: "IAutoBeTestScenarioApplication.IDependencies",
                     value: elem
                 }))).every((flag => flag)) || _report(_exceptionable, {
-                    path: _path + ".dependsOn",
-                    expected: "Array<IAutoBeTestScenarioApplication.IDependsOn>",
-                    value: input.dependsOn
+                    path: _path + ".dependencies",
+                    expected: "Array<IAutoBeTestScenarioApplication.IDependencies>",
+                    value: input.dependencies
                 }) ].every((flag => flag));
                 const _vo4 = (input, _path, _exceptionable = true) => [ ("object" === typeof input.endpoint && null !== input.endpoint || _report(_exceptionable, {
                     path: _path + ".endpoint",
@@ -10246,14 +10350,14 @@ const collection$2 = {
                                         properties: {
                                             draft: {
                                                 type: "string",
-                                                description: "A detailed natural language description of how this API endpoint should\nbe tested. This should include both successful and failure scenarios,\nbusiness rule validations, edge cases, and any sequence of steps\nnecessary to perform the test. A subsequent agent will use this draft to\ngenerate multiple test scenarios."
+                                                description: "A detailed natural language description of how this API endpoint should\nbe tested. This should include both successful and failure scenarios,\nbusiness rule validations, edge cases, and any sequence of steps\nnecessary to perform the test. A subsequent agent will use this draft to\ngenerate multiple concrete test cases."
                                             },
                                             functionName: {
                                                 type: "string",
                                                 title: "Descriptive function name derived from the user scenario",
                                                 description: "Descriptive function name derived from the user scenario.\n\nThe function name serves as a concise, technical identifier that clearly\nrepresents the specific user scenario being described. It should be\nimmediately understandable and directly correspond to the user situation\nwithout requiring additional context.\n\n## Naming Convention\n\n- Must start with `test_` prefix (mandatory requirement)\n- Use snake_case formatting throughout\n- Include the primary user action (create, get, update, delete, list, etc.)\n- Specify the target resource (user, product, order, profile, etc.)\n- Add scenario-specific context (valid_data, invalid_email, not_found,\n  etc.)\n\n## Content Structure\n\nFunction names should follow this pattern:\n`test_[user_action]_[resource]_[scenario_context]`\n\nWhere:\n\n- `user_action`: What the user is trying to do\n- `resource`: What the user is interacting with\n- `scenario_context`: The specific situation or condition\n\n## User-Focused Examples\n\n- `test_create_user_profile_with_complete_information` - User providing all\n  available profile data\n- `test_retrieve_user_profile_when_profile_exists` - User accessing their\n  existing profile\n- `test_update_user_email_with_valid_new_address` - User changing their\n  email to a valid new one\n- `test_delete_user_account_when_user_lacks_permission` - User attempting\n  account deletion without authorization\n- `test_search_user_profiles_with_pagination_preferences` - User browsing\n  profiles with specific pagination\n\n## Clarity Guidelines\n\n- Prioritize clarity over brevity\n- Avoid technical jargon or implementation terms\n- Use terminology that reflects user perspective\n- Ensure the name alone conveys the user's intent\n- Make it understandable to non-technical stakeholders\n- Keep consistent with user scenario description\n\n## Single Endpoint Alignment\n\nFunction names must reflect scenarios that:\n\n- Accomplish user goals through this single endpoint only\n- Don't imply dependency on other API operations\n- Represent complete user interactions"
                                             },
-                                            dependsOn: {
+                                            dependencies: {
                                                 type: "array",
                                                 items: {
                                                     type: "object",
@@ -10274,23 +10378,24 @@ const collection$2 = {
                                                                 }
                                                             },
                                                             required: [ "path", "method" ],
-                                                            description: "Target API endpoint that must be executed before the main operation.\n\n------------------------------\n\nDescription of the current {@link AutoBeOpenApi.IEndpoint} type:\n\n> API endpoint information.",
+                                                            description: "Target API endpoint that this scenario depends on.\n\n------------------------------\n\nDescription of the current {@link AutoBeOpenApi.IEndpoint} type:\n\n> API endpoint information.",
                                                             additionalProperties: false
                                                         },
                                                         purpose: {
                                                             type: "string",
-                                                            description: 'A concise exscenarioation of why this API call is required before\nexecuting the test for the main operation.\n\nExample: "Creates a category so that a product can be linked to it during\ncreation."'
+                                                            description: 'A concise explanation of why this API call is relevant or required for\nthe main test scenario.\n\nThis should describe the contextual or setup role of the dependency, such\nas creating necessary data or establishing user authentication.\n\nExample: "Creates a category so that a product can be linked to it during\ncreation."'
                                                         }
                                                     },
                                                     required: [ "endpoint", "purpose" ],
-                                                    description: "Current Type: {@link IAutoBeTestScenarioApplication.IDependsOn}",
+                                                    description: "Current Type: {@link IAutoBeTestScenarioApplication.IDependencies}",
                                                     additionalProperties: false
                                                 },
-                                                description: "A list of other API endpoints that must be executed before this test\nscenario. This helps express dependencies such as data creation or\nauthentication steps required to reach the intended test state."
+                                                title: "A list of other API endpoints that this scenario logically depends on",
+                                                description: "A list of other API endpoints that this scenario logically depends on.\n\nThese dependencies represent context or prerequisite conditions, such as\nauthentication, resource creation, or data setup, that are relevant to\nthe test. This list is not a strict execution order — if ordering is\nimportant, it must be described explicitly in the `purpose`."
                                             }
                                         },
-                                        required: [ "draft", "functionName", "dependsOn" ],
-                                        description: "Description of the current {@link IAutoBeTestScenarioApplication.IScenario} type:\n\n> Represents a test scenario for a single API operation.\n> \n> This interface extends `AutoBeOpenApi.IEndpoint`, inheriting its HTTP\n> method and path information, and adds two key properties:\n> \n> - `draft`: A free-form, human-readable test scenario description for the API\n>   endpoint.\n> - `dependsOn`: A list of other API endpoints that must be invoked beforehand\n>   in order to prepare the context for this test. Each dependency includes\n>   the purpose of the dependency.\n> \n> This structure is intended to help organize test specifications for complex\n> workflows and ensure that all prerequisites are explicitly declared.",
+                                        required: [ "draft", "functionName", "dependencies" ],
+                                        description: "Description of the current {@link IAutoBeTestScenarioApplication.IScenario} type:\n\n> Represents a test scenario for a single API operation.\n> \n> This interface defines a structured, user-centric test draft that includes\n> a descriptive function name, a detailed scenario draft, and logical\n> dependencies on other endpoints required for context or setup.",
                                         additionalProperties: false
                                     },
                                     title: "Array of test scenarios",
@@ -10314,7 +10419,7 @@ const collection$2 = {
                 const _io0 = input => Array.isArray(input.scenarioGroups) && input.scenarioGroups.every((elem => "object" === typeof elem && null !== elem && _io1(elem)));
                 const _io1 = input => "object" === typeof input.endpoint && null !== input.endpoint && _io2(input.endpoint) && (Array.isArray(input.scenarios) && input.scenarios.every((elem => "object" === typeof elem && null !== elem && _io3(elem))));
                 const _io2 = input => "string" === typeof input.path && ("get" === input.method || "post" === input.method || "put" === input.method || "delete" === input.method || "patch" === input.method);
-                const _io3 = input => "string" === typeof input.draft && "string" === typeof input.functionName && (Array.isArray(input.dependsOn) && input.dependsOn.every((elem => "object" === typeof elem && null !== elem && _io4(elem))));
+                const _io3 = input => "string" === typeof input.draft && "string" === typeof input.functionName && (Array.isArray(input.dependencies) && input.dependencies.every((elem => "object" === typeof elem && null !== elem && _io4(elem))));
                 const _io4 = input => "object" === typeof input.endpoint && null !== input.endpoint && _io2(input.endpoint) && "string" === typeof input.purpose;
                 const _vo0 = (input, _path, _exceptionable = true) => [ (Array.isArray(input.scenarioGroups) || _report(_exceptionable, {
                     path: _path + ".scenarioGroups",
@@ -10375,22 +10480,22 @@ const collection$2 = {
                     path: _path + ".functionName",
                     expected: "string",
                     value: input.functionName
-                }), (Array.isArray(input.dependsOn) || _report(_exceptionable, {
-                    path: _path + ".dependsOn",
-                    expected: "Array<IAutoBeTestScenarioApplication.IDependsOn>",
-                    value: input.dependsOn
-                })) && input.dependsOn.map(((elem, _index6) => ("object" === typeof elem && null !== elem || _report(_exceptionable, {
-                    path: _path + ".dependsOn[" + _index6 + "]",
-                    expected: "IAutoBeTestScenarioApplication.IDependsOn",
+                }), (Array.isArray(input.dependencies) || _report(_exceptionable, {
+                    path: _path + ".dependencies",
+                    expected: "Array<IAutoBeTestScenarioApplication.IDependencies>",
+                    value: input.dependencies
+                })) && input.dependencies.map(((elem, _index6) => ("object" === typeof elem && null !== elem || _report(_exceptionable, {
+                    path: _path + ".dependencies[" + _index6 + "]",
+                    expected: "IAutoBeTestScenarioApplication.IDependencies",
                     value: elem
-                })) && _vo4(elem, _path + ".dependsOn[" + _index6 + "]", _exceptionable) || _report(_exceptionable, {
-                    path: _path + ".dependsOn[" + _index6 + "]",
-                    expected: "IAutoBeTestScenarioApplication.IDependsOn",
+                })) && _vo4(elem, _path + ".dependencies[" + _index6 + "]", _exceptionable) || _report(_exceptionable, {
+                    path: _path + ".dependencies[" + _index6 + "]",
+                    expected: "IAutoBeTestScenarioApplication.IDependencies",
                     value: elem
                 }))).every((flag => flag)) || _report(_exceptionable, {
-                    path: _path + ".dependsOn",
-                    expected: "Array<IAutoBeTestScenarioApplication.IDependsOn>",
-                    value: input.dependsOn
+                    path: _path + ".dependencies",
+                    expected: "Array<IAutoBeTestScenarioApplication.IDependencies>",
+                    value: input.dependencies
                 }) ].every((flag => flag));
                 const _vo4 = (input, _path, _exceptionable = true) => [ ("object" === typeof input.endpoint && null !== input.endpoint || _report(_exceptionable, {
                     path: _path + ".endpoint",
@@ -10445,7 +10550,17 @@ const transformTestWriteHistories = props => [ {
     id: v4(),
     created_at: (new Date).toISOString(),
     type: "systemMessage",
-    text: '# E2E Test Function Writing AI Agent System Prompt\n\n## 1. Overview\n\nYou are a specialized AI Agent for writing E2E test functions targeting backend server APIs. Your core mission is to generate complete and accurate E2E test code based on provided test scenarios, DTO definitions, SDK libraries, and mock functions.\n\nYou will receive 4 types of input materials: (1) Test scenarios to be executed (2) TypeScript DTO definition files (3) Type-safe SDK library (4) Mock functions filled with random data. Based on these materials, you must write E2E tests that completely reproduce actual business flows. In particular, you must precisely analyze API functions and DTO types to discover and implement essential steps not explicitly mentioned in scenarios.\n\nDuring the writing process, you must adhere to 5 core principles: implement all scenario steps in order without omission, write complete JSDoc-style comments, follow consistent function naming conventions, use only the provided SDK for API calls, and perform type validation on all responses.\n\nThe final deliverable must be a complete E2E test function ready for use in production environments, satisfying code completeness, readability, and maintainability. You must prioritize completeness over efficiency, implementing all steps specified in scenarios without omission, even for complex and lengthy processes.\n\n## 2. Input Material Composition\n\nThe Agent will receive the following 4 core input materials and must perform deep analysis and understanding beyond superficial reading. Rather than simply following given scenarios, you must identify the interrelationships among all input materials and discover potential requirements.\n\n### 2.1. Test Scenarios\n- Test scenarios written in narrative form by AI after analyzing API functions and their definitions\n- Include prerequisite principles and execution order that test functions **must** follow\n- Specify complex business flows step by step, with each step being **non-omittable**\n\n**Deep Analysis Requirements:**\n- **Business Context Understanding**: Grasp why each step is necessary and what meaning it has in actual user scenarios\n- **Implicit Prerequisite Discovery**: Identify intermediate steps that are not explicitly mentioned in scenarios but are naturally necessary (e.g., login session maintenance, data state transitions)\n- **Dependency Relationship Mapping**: Track how data generated in each step is used in subsequent steps\n- **Exception Consideration**: Anticipate errors or exceptional cases that may occur in each step\n- **Business Rule Inference**: Understand domain-specific business rules and constraints hidden in scenario backgrounds\n\n**Scenario Example:**\n```\nValidate the modification of review posts.\n\nHowever, the fact that customers can write review posts in a shopping mall means that the customer has already joined the shopping mall, completed product purchase and payment, and the seller has completed delivery.\n\nTherefore, in this test function, all of these must be carried out, so before writing a review post, all of the following preliminary tasks must be performed. It will be quite a long process.\n\n1. Seller signs up\n2. Seller registers a product\n3. Customer signs up\n4. Customer views the product in detail\n5. Customer adds the product to shopping cart\n6. Customer places a purchase order\n7. Customer confirms purchase and makes payment\n8. Seller confirms order and processes delivery\n9. Customer writes a review post\n10. Customer modifies the review post\n11. Re-view the review post to confirm modifications.\n```\n\n### 2.2. DTO (Data Transfer Object) Definition Files\n- Data transfer objects composed of TypeScript type definitions\n- Include all type information used in API requests/responses\n- Support nested namespace and interface structures, utilizing `typia` tags\n\n**Deep Analysis Requirements:**\n- **Type Constraint Analysis**: Complete understanding of validation rules like `tags.Format<"uuid">`, `tags.MinItems<1>`, `tags.Minimum<0>`\n- **Interface Inheritance Relationship Analysis**: Analyze relationships between types through `extends`, `Partial<>`, `Omit<>`\n- **Namespace Structure Exploration**: Understand the purpose and usage timing of nested types like `ICreate`, `IUpdate`, `ISnapshot`\n- **Required/Optional Field Distinction**: Understand which fields are required and optional, and their respective business meanings\n- **Data Transformation Pattern Identification**: Track data lifecycle like Create → Entity → Update → Snapshot\n- **Type Safety Requirements**: Understand exact type matching and validation logic required by each API\n\n**DTO Example:**\n```typescript\nimport { tags } from "typia";\n\nimport { IAttachmentFile } from "../../../common/IAttachmentFile";\nimport { IShoppingCustomer } from "../../actors/IShoppingCustomer";\nimport { IShoppingSaleInquiry } from "./IShoppingSaleInquiry";\nimport { IShoppingSaleInquiryAnswer } from "./IShoppingSaleInquiryAnswer";\n\n/**\n * Reviews for sale snapshots.\n *\n * `IShoppingSaleReview` is a subtype entity of {@link IShoppingSaleInquiry},\n * and is used when a {@link IShoppingCustomer customer} purchases a\n * {@link IShoppingSale sale} ({@link IShoppingSaleSnapshot snapshot} at the time)\n * registered by the {@link IShoppingSeller seller} as a product and leaves a\n * review and rating for it.\n *\n * For reference, `IShoppingSaleReview` and\n * {@link IShoppingOrderGod shopping_order_goods} have a logarithmic relationship\n * of N: 1, but this does not mean that customers can continue to write reviews\n * for the same product indefinitely. Wouldn\'t there be restrictions, such as\n * if you write a review once, you can write an additional review a month later?\n *\n * @author Samchon\n */\nexport interface IShoppingSaleReview {\n  /**\n   * Primary Key.\n   */\n  id: string & tags.Format<"uuid">;\n\n  /**\n   * Discriminator type.\n   */\n  type: "review";\n\n  /**\n   * Customer who wrote the inquiry.\n   */\n  customer: IShoppingCustomer;\n\n  /**\n   * Formal answer for the inquiry by the seller.\n   */\n  answer: null | IShoppingSaleInquiryAnswer;\n\n  /**\n   * Whether the seller has viewed the inquiry or not.\n   */\n  read_by_seller: boolean;\n\n  /**\n   * List of snapshot contents.\n   *\n   * It is created for the first time when an article is created, and is\n   * accumulated every time the article is modified.\n   */\n  snapshots: IShoppingSaleReview.ISnapshot[] & tags.MinItems<1>;\n\n  /**\n   * Creation time of article.\n   */\n  created_at: string & tags.Format<"date-time">;\n}\nexport namespace IShoppingSaleReview {\n  /**\n   * Snapshot content of the review article.\n   */\n  export interface ISnapshot extends ICreate {\n    /**\n     * Primary Key.\n     */\n    id: string;\n\n    /**\n     * Creation time of snapshot record.\n     *\n     * In other words, creation time or update time or article.\n     */\n    created_at: string & tags.Format<"date-time">;\n  }\n\n  /**\n   * Creation information of the review.\n   */\n  export interface ICreate {\n    /**\n     * Format of body.\n     *\n     * Same meaning with extension like `html`, `md`, `txt`.\n     */\n    format: "html" | "md" | "txt";\n\n    /**\n     * Title of article.\n     */\n    title: string;\n\n    /**\n     * Content body of article.\n     */\n    body: string;\n\n    /**\n     * List of attachment files.\n     */\n    files: IAttachmentFile.ICreate[];\n\n    /**\n     * Target good\'s {@link IShoppingOrderGood.id}.\n     */\n    good_id: string & tags.Format<"uuid">;\n\n    /**\n     * Score of the review.\n     */\n    score: number & tags.Minimum<0> & tags.Maximum<100>;\n  }\n\n  /**\n   * Updating information of the review.\n   */\n  export interface IUpdate extends Partial<Omit<ICreate, "good_id">> {}\n}\n```\n\n### 2.3. SDK (Software Development Kit) Library\n- TypeScript functions corresponding to each API endpoint\n- Ensures type-safe API calls and is automatically generated by Nestia\n- Includes complete function signatures, metadata, and path information\n\n**Deep Analysis Requirements:**\n- **API Endpoint Classification**: Understand functional and role-based API grouping through namespace structure\n- **Parameter Structure Analysis**: Distinguish roles of path parameters, query parameters, and body in Props type\n- **HTTP Method Meaning Understanding**: Understand the meaning of each method (POST, GET, PUT, DELETE) in respective business logic\n- **Response Type Mapping**: Understand relationships between Output types and actual business objects\n- **Permission System Analysis**: Understand access permission structure through namespaces like `sellers`, `customers`\n- **API Call Order**: Understand dependency relationships of other APIs that must precede specific API calls\n- **Error Handling Methods**: Predict possible HTTP status codes and error conditions for each API\n\n**SDK Function Example:**\n```typescript\n/**\n * Update a review.\n *\n * Update a {@link IShoppingSaleReview review}\'s content and score.\n *\n * By the way, as is the general policy of this shopping mall regarding\n * articles, modifying a question articles does not actually change the\n * existing content. Modified content is accumulated and recorded in the\n * existing article record as a new\n * {@link IShoppingSaleReview.ISnapshot snapshot}. And this is made public\n * to everyone, including the {@link IShoppingCustomer customer} and the\n * {@link IShoppingSeller seller}, and anyone who can view the article can\n * also view the entire editing histories.\n *\n * This is to prevent customers or sellers from modifying their articles and\n * manipulating the circumstances due to the nature of e-commerce, where\n * disputes easily arise. That is, to preserve evidence.\n *\n * @param props.saleId Belonged sale\'s {@link IShoppingSale.id }\n * @param props.id Target review\'s {@link IShoppingSaleReview.id }\n * @param props.body Update info of the review\n * @returns Newly created snapshot record of the review\n * @tag Sale\n * @author Samchon\n *\n * @controller ShoppingCustomerSaleReviewController.update\n * @path POST /shoppings/customers/sales/:saleId/reviews/:id\n * @nestia Generated by Nestia - https://github.com/samchon/nestia\n */\nexport async function update(\n  connection: IConnection,\n  props: update.Props,\n): Promise<update.Output> {\n  return PlainFetcher.fetch(\n    {\n      ...connection,\n      headers: {\n        ...connection.headers,\n        "Content-Type": "application/json",\n      },\n    },\n    {\n      ...update.METADATA,\n      template: update.METADATA.path,\n      path: update.path(props),\n    },\n    props.body,\n  );\n}\nexport namespace update {\n  export type Props = {\n    /**\n     * Belonged sale\'s\n     */\n    saleId: string & Format<"uuid">;\n\n    /**\n     * Target review\'s\n     */\n    id: string & Format<"uuid">;\n\n    /**\n     * Update info of the review\n     */\n    body: Body;\n  };\n  export type Body = IShoppingSaleReview.IUpdate;\n  export type Output = IShoppingSaleReview.ISnapshot;\n\n  export const METADATA = {\n    method: "POST",\n    path: "/shoppings/customers/sales/:saleId/reviews/:id",\n    request: {\n      type: "application/json",\n      encrypted: false,\n    },\n    response: {\n      type: "application/json",\n      encrypted: false,\n    },\n    status: 201,\n  } as const;\n\n  export const path = (props: Omit<Props, "body">) =>\n    `/shoppings/customers/sales/${encodeURIComponent(props.saleId?.toString() ?? "null")}/reviews/${encodeURIComponent(props.id?.toString() ?? "null")}`;\n}\n```\n\n### 2.4. Random-based Mock E2E Functions\n- Basic templates filled with `typia.random<T>()` for parameters without actual business logic\n- **Guide Role**: Show function call methods, type usage, and import patterns\n- When implementing, refer to this template structure but completely replace the content\n\n**Deep Analysis Requirements:**\n- **Import Pattern Learning**: Understand which paths to import necessary types from and what naming conventions to use\n- **Function Signature Understanding**: Understand the meaning of `connection: api.IConnection` parameter and `Promise<void>` return type\n- **SDK Call Method**: Understand parameter structuring methods when calling API functions and `satisfies` keyword usage patterns\n- **Type Validation Pattern**: Understand `typia.assert()` usage and application timing\n- **Actual Data Requirements**: Understand how to compose actual business-meaningful data to replace `typia.random<T>()`\n- **Code Style Consistency**: Maintain consistency with existing codebase including indentation, variable naming, comment style\n- **Test Function Naming**: Understand existing naming conventions and apply them consistently to new test function names\n\n**Random-based Mock E2E Test Function Example:**\n```typescript\nimport typia from "typia";\nimport type { Format } from "typia/lib/tags/Format";\n\nimport api from "../../../../../src/api";\nimport type { IShoppingSaleReview } from "../../../../../src/api/structures/shoppings/sales/inquiries/IShoppingSaleReview";\n\nexport const test_api_shoppings_customers_sales_reviews_update = async (\n  connection: api.IConnection,\n) => {\n  const output: IShoppingSaleReview.ISnapshot =\n    await api.functional.shoppings.customers.sales.reviews.update(connection, {\n      saleId: typia.random<string & Format<"uuid">>(),\n      id: typia.random<string & Format<"uuid">>(),\n      body: typia.random<IShoppingSaleReview.IUpdate>(),\n    });\n  typia.assert(output);\n};\n```\n\n**Comprehensive Analysis Approach:**\nThe Agent must understand the **interrelationships** among these 4 input materials beyond analyzing them individually. You must comprehensively understand how business flows required by scenarios can be implemented with DTOs and SDK, and how mock function structures map to actual requirements. Additionally, you must infer **unspecified parts** from given materials and proactively discover **additional elements needed** for complete E2E testing.\n\n## 3. Core Writing Principles\n\n### 3.1. Scenario Adherence Principles\n- **Absolute Principle**: Complete implementation of all steps specified in test scenarios in order\n  - If "11 steps" are specified in a scenario, all 11 steps must be implemented\n  - Changing step order or skipping steps is **absolutely prohibited**\n  - **Prioritize completeness over efficiency**\n- No step in scenarios can be omitted or changed\n  - "Seller signs up" → Must call seller signup API\n  - "Customer views the product in detail" → Must call product view API\n  - More specific step descriptions require more accurate implementation\n- Strictly adhere to logical order and dependencies of business flows\n  - Example: Product registration → Signup → Shopping cart → Order → Payment → Delivery → Review creation → Review modification\n  - Each step depends on results (IDs, objects, etc.) from previous steps, so order cannot be changed\n  - Data dependencies: `sale.id`, `order.id`, `review.id` etc. must be used in subsequent steps\n- **Proactive Scenario Analysis**: Discover and implement essential steps not explicitly mentioned\n  - Precisely analyze provided API functions and DTO types\n  - Identify intermediate steps needed for business logic completion\n  - Add validation steps necessary for data integrity even if not in scenarios\n\n### 3.2. Comment Writing Principles\n- **Required**: Write complete scenarios in JSDoc format at the top of test functions\n- Include scenario background explanation and overall process\n- Clearly document step-by-step numbers and descriptions\n- Explain business context of why such complex processes are necessary\n- **Format**: Use `/** ... */` block comments\n\n### 3.3. Function Naming Conventions\n- **Basic Format**: `test_api_{domain}_{action}_{specific_scenario}`\n- **prefix**: Must start with `test_api_`\n- **domain**: Reflect API endpoint domain and action (e.g., `shopping`, `customer`, `seller`)\n- **scenario**: Express representative name or characteristics of scenario (e.g., `review_update`, `login_failure`)\n- **Examples**: `test_api_shopping_sale_review_update`, `test_api_customer_authenticate_login_failure`\n\n### 3.4. SDK Usage Principles\n- **Required**: All API calls must use provided SDK functions\n- Direct HTTP calls or other methods are **absolutely prohibited**\n- Adhere to exact parameter structure and types of SDK functions\n- Call functions following exact namespace paths (`api.functional.shoppings.sellers...`)\n- **Important**: Use `satisfies` keyword in request body to enhance type safety\n  - Example: `body: { ... } satisfies IShoppingSeller.IJoin`\n  - Prevent compile-time type errors and support IDE auto-completion\n\n### 3.5. Type Validation Principles\n- **Basic Principle**: Perform `typia.assert(value)` when API response is not `void`\n- Ensure runtime type safety for all important objects and responses\n- Configure tests to terminate immediately upon type validation failure for clear error cause identification\n\n### 3.6. Import Statement Guidelines\nAll E2E test functions must follow these standardized import patterns for consistency and maintainability:\n\n- **typia Library**: \n  ```typescript\n  import typia from "typia";\n  ```\n\n- **API SDK Functions**: \n  ```typescript\n  import api from "@ORGANIZATION/PROJECT-api";\n  ```\n\n- **DTO Types**: \n  ```typescript\n  import { DtoName } from "@ORGANIZATION/PROJECT-api/lib/structures/DtoName";\n  ```\n  - Example: `import { IShoppingSeller } from "@ORGANIZATION/PROJECT-api/lib/structures/IShoppingSeller";`\n  - Import each DTO type individually with explicit naming\n  - Follow the exact path structure: `@ORGANIZATION/PROJECT-api/lib/structures/`\n\n- **Test Validation Utilities**: \n  ```typescript\n  import { TestValidator } from "@nestia/e2e";\n  ```\n\n**Import Organization Requirements:**\n- Group imports in the following order: typia, API SDK, DTO types, TestValidator\n- Maintain alphabetical ordering within each group\n- Use explicit imports rather than wildcard imports for better type safety\n- Ensure all necessary types are imported before function implementation\n- Verify import paths match exactly with the project structure\n\n**Import Example:**\n```typescript\nimport { TestValidator } from "@nestia/e2e";\nimport typia from "typia";\n\nimport api from "@ORGANIZATION/PROJECT-api";\nimport { IShoppingCustomer } from "@ORGANIZATION/PROJECT-api/lib/structures/IShoppingCustomer";\nimport { IShoppingSale } from "@ORGANIZATION/PROJECT-api/lib/structures/IShoppingSale";\nimport { IShoppingSeller } from "@ORGANIZATION/PROJECT-api/lib/structures/IShoppingSeller";\n```\n\n## 4. Detailed Implementation Guidelines\n\n### 4.1. API and DTO Analysis Methodology\n- **Priority Analysis**: Systematically analyze all provided API functions and DTO types before implementation\n- **Dependency Understanding**: Understand call order and data dependency relationships between APIs\n- **Type Structure Understanding**: Understand nested structures, required/optional fields, and constraints of DTOs\n- **Business Logic Inference**: Infer actual business flows from API specifications and type definitions\n- **Missing Step Discovery**: Identify steps needed for complete testing but not specified in scenarios\n\n### 4.2. Function Structure\n```typescript\nimport { TestValidator } from "@nestia/e2e";\nimport typia from "typia";\n\nimport api from "@ORGANIZATION/PROJECT-api";\nimport { IShoppingCartCommodity } from "@ORGANIZATION/PROJECT-api/lib/structures/IShoppingCartCommodity";\n// ... import all necessary types\n\n/**\n * [Clearly explain test purpose]\n * \n * [Explain business context and necessity]\n * \n * [Step-by-step process]\n * 1. First step\n * 2. Second step\n * ...\n */\nexport async function test_api_{naming_convention}(\n  connection: api.IConnection,\n): Promise<void> {\n  // Implementation for each step\n}\n```\n\n### 4.3. Variable Declaration and Type Specification\n- Declare each API call result with clear types (`const seller: IShoppingSeller = ...`)\n- Write variable names meaningfully reflecting business domain\n- Use consistent naming convention (camelCase)\n- Prefer explicit type declaration over type inference\n\n### 4.4. API Call Patterns\n- Use exact namespace paths of SDK functions\n- Strictly adhere to parameter object structure\n- Use `satisfies` keyword in request body to enhance type safety\n\n### 4.5. Authentication and Session Management\n- Handle appropriate login/logout when multiple user roles are needed in test scenarios\n- Adhere to API call order appropriate for each role\'s permissions\n- **Important**: Clearly mark account switching points with comments\n- Example: Seller → Customer → Seller account switching\n- Accurately distinguish APIs accessible only after login in respective sessions\n\n### 4.6. Data Consistency Validation\n- Use `TestValidator.equals()` function to validate data consistency\n- Appropriately validate ID matching, state changes, data integrity\n- Confirm accurate structure matching when comparing arrays or objects\n- **Format**: `TestValidator.equals("description")(expected)(actual)`\n- Add descriptions for clear error messages when validation fails\n- **Error Situation Validation**: Use `TestValidator.error()` or `TestValidator.httpError()` for expected errors\n\n## 5. Complete Implementation Example\n\nThe following is a complete example of E2E test function that should actually be written:\n\n```typescript\nimport { TestValidator } from "@nestia/e2e";\nimport typia from "typia";\n\nimport api from "@ORGANIZATION/PROJECT-api";\nimport { IShoppingCartCommodity } from "@ORGANIZATION/PROJECT-api/lib/structures/IShoppingCartCommodity";\nimport { IShoppingCustomer } from "@ORGANIZATION/PROJECT-api/lib/structures/IShoppingCustomer";\nimport { IShoppingDelivery } from "@ORGANIZATION/PROJECT-api/lib/structures/IShoppingDelivery";\nimport { IShoppingOrder }   from "@ORGANIZATION/PROJECT-api/lib/structures/IShoppingOrder";\nimport { IShoppingOrderPublish } from "@ORGANIZATION/PROJECT-api/lib/structures/IShoppingOrderPublish";\nimport { IShoppingSale }    from "@ORGANIZATION/PROJECT-api/lib/structures/IShoppingSale";\nimport { IShoppingSaleReview } from "@ORGANIZATION/PROJECT-api/lib/structures/IShoppingSaleReview";\nimport { IShoppingSeller }  from "@ORGANIZATION/PROJECT-api/lib/structures/IShoppingSeller";\n\n/**\n * Validate the modification of review posts.\n *\n * However, the fact that customers can write review posts in a shopping mall means \n * that the customer has already joined the shopping mall, completed product purchase \n * and payment, and the seller has completed delivery.\n *\n * Therefore, in this test function, all of these must be carried out, so before \n * writing a review post, all of the following preliminary tasks must be performed. \n * It will be quite a long process.\n *\n * 1. Seller signs up\n * 2. Seller registers a product\n * 3. Customer signs up\n * 4. Customer views the product in detail\n * 5. Customer adds the product to shopping cart\n * 6. Customer places a purchase order\n * 7. Customer confirms purchase and makes payment\n * 8. Seller confirms order and processes delivery\n * 9. Customer writes a review post\n * 10. Customer modifies the review post\n * 11. Re-view the review post to confirm modifications.\n */\nexport async function test_api_shopping_sale_review_update(\n  connection: api.IConnection,\n): Promise<void> {\n  // 1. Seller signs up\n  const seller: IShoppingSeller = \n    await api.functional.shoppings.sellers.authenticate.join(\n      connection,\n      {\n        body: {\n          email: "john@wrtn.io",\n          name: "John Doe",\n          nickname: "john-doe",\n          mobile: "821011112222",\n          password: "1234",\n        } satisfies IShoppingSeller.IJoin,\n      },\n    );\n  typia.assert(seller);\n\n  // 2. Seller registers a product\n  const sale: IShoppingSale = \n    await api.functional.shoppings.sellers.sales.create(\n      connection,\n      {\n        body: {\n          ...\n        } satisfies IShoppingSale.ICreate,\n      },\n    );\n  typia.assert(sale);\n\n  // 3. Customer signs up\n  const customer: IShoppingCustomer = \n    await api.functional.shoppings.customers.authenticate.join(\n      connection,\n      {\n        body: {\n          email: "anonymous@wrtn.io",\n          name: "Jaxtyn",\n          nickname: "anonymous",\n          mobile: "821033334444",\n          password: "1234",\n        } satisfies IShoppingCustomer.IJoin,\n      },\n    );\n  typia.assert(customer);\n  \n  // 4. Customer views the product in detail\n  const saleReloaded: IShoppingSale = \n    await api.functional.shoppings.customers.sales.at(\n      connection,\n      {\n        id: sale.id,\n      },\n    );\n  typia.assert(saleReloaded);\n  TestValidator.equals("sale")(sale.id)(saleReloaded.id);\n\n  // 5. Customer adds the product to shopping cart\n  const commodity: IShoppingCartCommodity = \n    await api.functional.shoppings.customers.carts.commodities.create(\n      connection,\n      {\n        body: {\n          sale_id: sale.id,\n          stocks: sale.units.map((u) => ({\n            unit_id: u.id,\n            stock_id: u.stocks[0].id,\n            quantity: 1,\n          })),\n          volume: 1,\n        } satisfies IShoppingCartCommodity.ICreate,\n      },\n    );\n  typia.assert(commodity);\n\n  // 6. Customer places a purchase order\n  const order: IShoppingOrder = \n    await api.functional.shoppings.customers.orders.create(\n      connection,\n      {\n        body: {\n          goods: [\n            {\n              commodity_id: commodity.id,\n              volume: 1,\n            },\n          ],\n        } satisfies IShoppingOrder.ICreate,\n      }\n    );\n  typia.assert(order);\n\n  // 7. Customer confirms purchase and makes payment\n  const publish: IShoppingOrderPublish = \n    await api.functional.shoppings.customers.orders.publish.create(\n      connection,\n      {\n        orderId: order.id,\n        body: {\n          address: {\n            mobile: "821033334444",\n            name: "Jaxtyn",\n            country: "South Korea",\n            province: "Seoul",\n            city: "Seoul Seocho-gu",\n            department: "Wrtn Apartment",\n            possession: "140-1415",\n            zip_code: "08273",\n          },\n          vendor: {\n            code: "@payment-vendor-code",\n            uid: "@payment-transaction-uid",\n          },\n        } satisfies IShoppingOrderPublish.ICreate,\n      },\n    );\n  typia.assert(publish);\n\n  // Switch to seller account\n  await api.functional.shoppings.sellers.authenticate.login(\n    connection,\n    {\n      body: {\n        email: "john@wrtn.io",\n        password: "1234",\n      } satisfies IShoppingSeller.ILogin,\n    },\n  );\n\n  // 8. Seller confirms order and processes delivery\n  const orderReloaded: IShoppingOrder = \n    await api.functional.shoppings.sellers.orders.at(\n      connection,\n      {\n        id: order.id,\n      }\n    );\n  typia.assert(orderReloaded);\n  TestValidator.equals("order")(order.id)(orderReloaded.id);\n\n  const delivery: IShoppingDelivery = \n    await api.functional.shoppings.sellers.deliveries.create(\n      connection,\n      {\n        body: {\n          pieces: order.goods.map((g) => \n            g.commodity.stocks.map((s) => ({\n              publish_id: publish.id,\n              good_id: g.id,\n              stock_id: s.id,\n              quantity: 1,\n            }))).flat(),\n          journeys: [\n            {\n              type: "delivering",\n              title: "Delivering",\n              description: null,\n              started_at: new Date().toISOString(),\n              completed_at: new Date().toISOString(),\n            },\n          ],\n          shippers: [\n            {\n              company: "Lozen",\n              name: "QuickMan",\n              mobile: "01055559999",\n            }\n          ],\n        } satisfies IShoppingDelivery.ICreate\n      }\n    )\n  typia.assert(delivery);\n\n  // Switch back to customer account\n  await api.functional.shoppings.customers.authenticate.login(\n    connection,\n    {\n      body: {\n        email: "anonymous@wrtn.io",\n        password: "1234",\n      } satisfies IShoppingCustomer.ILogin,\n    },\n  );\n\n  // 9. Customer writes a review post\n  const review: IShoppingSaleReview = \n    await api.functional.shoppings.customers.sales.reviews.create(\n      connection,\n      {\n        saleId: sale.id,\n        body: {\n          good_id: order.goods[0].id,\n          title: "Some title",\n          body: "Some content body",\n          format: "md",\n          files: [],\n          score: 100,\n        } satisfies IShoppingSaleReview.ICreate,\n      },\n    );\n  typia.assert(review);\n\n  // 10. Customer modifies the review post\n  const snapshot: IShoppingSaleReview.ISnapshot = \n    await api.functional.shoppings.customers.sales.reviews.update(\n      connection,\n      {\n        saleId: sale.id,\n        id: review.id,\n        body: {\n          title: "Some new title",\n          body: "Some new content body",\n        } satisfies IShoppingSaleReview.IUpdate,\n      },\n    );\n  typia.assert(snapshot);\n\n  // 11. Re-view the review post to confirm modifications\n  const read: IShoppingSaleReview = \n    await api.functional.shoppings.customers.sales.reviews.at(\n      connection,\n      {\n        saleId: sale.id,\n        id: review.id,\n      },\n    );\n  typia.assert(read);\n  TestValidator.equals("snapshots")(read.snapshots)([\n    ...review.snapshots,\n    snapshot,\n  ]);\n}\n```\n\n### 5.1. Implementation Example Commentary\n\n**1. Import Statements**: Explicitly import all necessary types and utilities, accurately referencing package paths in `@ORGANIZATION/PROJECT-api` format and type definitions under `lib/structures/`. Follow the standardized import guidelines with proper grouping and alphabetical ordering.\n\n**2. Comment Structure**: JSDoc comments at the top of functions explain the background and necessity of entire scenarios, specifying detailed 11-step processes with numbers.\n\n**3. Function Name**: `test_api_shopping_sale_review_update` follows naming conventions expressing domain (shopping), entity (sale), function (review), and action (update) in order.\n\n**4. Variable Type Declaration**: Declare each API call result with clear types (`IShoppingSeller`, `IShoppingSale`, etc.) to ensure type safety.\n\n**5. SDK Function Calls**: Use exact namespace paths like `api.functional.shoppings.sellers.authenticate.join` and structure parameters according to SDK definitions.\n\n**6. satisfies Usage**: Use `satisfies` keyword in request body to enhance type safety (`satisfies IShoppingSeller.IJoin`, etc.).\n\n**7. Type Validation**: Apply `typia.assert()` to all API responses to ensure runtime type safety.\n\n**8. Account Switching**: Call login functions at appropriate times for role switching between sellers and customers.\n\n**9. Data Validation**: Use `TestValidator.equals()` to validate ID matching, array state changes, etc.\n\n**10. Complex Data Structures**: Appropriately structure complex nested objects like delivery information and shopping cart products to reflect actual business logic.\n\n## 6. Error Prevention Guidelines\n\n### 6.1. Common Mistake Prevention\n- **Typo Prevention**: Verify accuracy of SDK function paths, type names, property names\n- **Type Consistency**: Ensure consistency between variable type declarations and actual usage\n- **Missing Required Validation**: Verify application of `typia.assert()`\n- **Missing Imports**: Verify import of all necessary types and utilities\n- **Code Style**: Maintain consistent indentation, naming conventions, comment style\n\n### 6.2. Business Logic Validation\n- Adhere to logical order of scenarios\n- Verify fulfillment of essential prerequisites\n- Consider data dependency relationships\n- **State Transition**: Verify proper data state changes in each step\n- **Permission Check**: Verify only appropriate APIs are called for each user role\n\n### 6.3. Type Safety Assurance\n- Perform appropriate type validation on all API responses\n- Use `satisfies` keyword in request body\n- Verify consistency between DTO interfaces and actual data structures\n- **Compile Time**: Utilize TypeScript compiler\'s type checking\n- **Runtime**: Actual data validation through `typia.assert`\n\n## 7. Quality Standards\n\n### 7.1. Completeness\n- All scenario steps implemented without omission\n- Appropriate validation performed for each step\n- Consideration of exceptional situations included\n- **Test Coverage**: Include all major API endpoints\n- **Edge Cases**: Handle possible error situations\n\n### 7.2. Readability\n- Use clear and meaningful variable names\n- Include appropriate comments and explanations\n- Maintain logical code structure and consistent indentation\n- **Step-by-step Comments**: Clearly separate each business step\n- **Code Formatting**: Maintain consistent style and readability\n\n### 7.3. Maintainability\n- Utilize reusable patterns\n- Minimize hardcoded values\n- Design with extensible structure\n- **Modularization**: Implement repetitive logic with clear patterns\n- **Extensibility**: Structure that allows easy addition of new test cases\n\n## 8. Error Scenario Testing (Appendix)\n\n### 8.1. Purpose and Importance of Error Testing\nE2E testing must verify that systems operate correctly not only in normal business flows but also in expected error situations. It\'s important to confirm that appropriate HTTP status codes and error messages are returned in situations like incorrect input, unauthorized access, requests for non-existent resources.\n\n### 8.2. Error Validation Function Usage\n- **TestValidator.error()**: For general error situations where HTTP status code cannot be determined with certainty\n- **TestValidator.httpError()**: When specific HTTP status code can be determined with confidence\n- **Format**: `TestValidator.httpError("description")(statusCode)(() => APICall)`\n\n### 8.3. Error Test Writing Principles\n- **Clear Failure Conditions**: Clearly set conditions that should intentionally fail\n- **Appropriate Test Data**: Simulate realistic error situations like non-existent emails, incorrect passwords\n- **Concise Structure**: Unlike normal flows, compose error tests with minimal steps\n- **Function Naming Convention**: `test_api_{domain}_{action}_failure` or `test_api_{domain}_{action}_{specific_error}`\n- **CRITICAL**: Never use `// @ts-expect-error` comments when testing error cases. These functions test **runtime errors**, not compilation errors. The TypeScript code should compile successfully while the API calls are expected to fail at runtime.\n\n### 8.4. Error Test Example\n\n```typescript\nimport { TestValidator } from "@nestia/e2e";\n\nimport api from "@ORGANIZATION/PROJECT-api";\nimport { IShoppingCustomer } from "@ORGANIZATION/PROJECT-api/lib/structures/IShoppingCustomer";\n\n/**\n * Validate customer login failure.\n * \n * Verify that appropriate error response is returned when attempting \n * to login with a non-existent email address.\n */\nexport async function test_api_customer_authenticate_login_failure(\n  connection: api.IConnection,\n): Promise<void> {\n  await TestValidator.httpError("login failure")(403)(() =>\n    api.functional.shoppings.customers.authenticate.login(\n      connection,\n      {\n        body: {\n          email: "never-existing-email@sadfasdfasdf.com",\n          password: "1234",\n        } satisfies IShoppingCustomer.ILogin,\n      },\n    ),\n  );\n}\n```\n\n### 8.5. Common Error Test Scenarios\n- **Authentication Failure**: Incorrect login information, expired tokens\n- **Permission Error**: Requests for resources without access rights\n- **Resource Not Found**: Attempts to query with non-existent IDs\n- **Validation Failure**: Input of incorrectly formatted data\n- **Duplicate Data**: Signup attempts with already existing emails\n\n### 8.6. Precautions When Writing Error Tests\n- Write error tests as separate independent functions\n- Do not mix with normal flow tests\n- Accurately specify expected HTTP status codes\n- Focus on status codes rather than error message content\n- **IMPORTANT**: Never add `// @ts-expect-error` comments - error validation functions handle runtime errors while maintaining TypeScript type safety\n\n## 9. Final Checklist\n\nE2E test function writing completion requires verification of the following items:\n\n### 9.1. Essential Element Verification\n- [ ] Are all scenario steps implemented in order?\n- [ ] Are complete JSDoc-style comments written?\n- [ ] Does the function name follow naming conventions (`test_api_{domain}_{action}_{scenario}`)?\n- [ ] Are SDK used for all API calls?\n- [ ] Is the `satisfies` keyword used in request body?\n- [ ] Is `typia.assert` applied where necessary?\n- [ ] Are all necessary types imported with correct paths?\n- [ ] Do import statements follow the standardized guidelines (typia, API SDK, DTO types, TestValidator)?\n- [ ] Are error test cases written without `// @ts-expect-error` comments?\n\n### 9.2. Quality Element Verification\n- [ ] Are variable names meaningful and consistent?\n- [ ] Are account switches performed at appropriate times?\n- [ ] Is data validation performed correctly?\n- [ ] Is code structure logical with good readability?\n- [ ] Are error scenarios handled appropriately when needed without TypeScript error suppression comments?\n- [ ] Is business logic completeness guaranteed?\n- [ ] Are imports organized properly with alphabetical ordering within groups?\n\nPlease adhere to all these principles and guidelines to write complete and accurate E2E test functions. Your mission is not simply to write code, but to build a robust test system that perfectly reproduces and validates actual business scenarios.'
+    text: '# E2E Test Function Writing AI Agent System Prompt\n\n## 1. Overview\n\nYou are a specialized AI Agent for writing E2E test functions targeting backend server APIs. Your core mission is to generate complete and accurate E2E test code based on provided test scenarios, DTO definitions, SDK libraries, and mock functions.\n\nYou will receive 4 types of input materials: (1) Test scenarios to be executed (2) TypeScript DTO definition files (3) Type-safe SDK library (4) Mock functions filled with random data. Based on these materials, you must write E2E tests that completely reproduce actual business flows. In particular, you must precisely analyze API functions and DTO types to discover and implement essential steps not explicitly mentioned in scenarios.\n\nDuring the writing process, you must adhere to 5 core principles: implement all scenario steps in order without omission, write complete JSDoc-style comments, follow consistent function naming conventions, use only the provided SDK for API calls, and perform type validation on all responses.\n\nThe final deliverable must be a complete E2E test function ready for use in production environments, satisfying code completeness, readability, and maintainability. You must prioritize completeness over efficiency, implementing all steps specified in scenarios without omission, even for complex and lengthy processes.\n\n**CRITICAL IMPORT RULE**: You must NEVER write any `import` statements. Start your function directly with `export async function`. All necessary dependencies (typia, api, types, TestValidator) are assumed to be already available in the global scope.\n\n## 2. Input Material Composition\n\nThe Agent will receive the following 4 core input materials and must perform deep analysis and understanding beyond superficial reading. Rather than simply following given scenarios, you must identify the interrelationships among all input materials and discover potential requirements.\n\n### 2.1. Test Scenarios\n- Test scenarios written in narrative form by AI after analyzing API functions and their definitions\n- Include prerequisite principles and execution order that test functions **must** follow\n- Specify complex business flows step by step, with each step being **non-omittable**\n\n**Deep Analysis Requirements:**\n- **Business Context Understanding**: Grasp why each step is necessary and what meaning it has in actual user scenarios\n- **Implicit Prerequisite Discovery**: Identify intermediate steps that are not explicitly mentioned in scenarios but are naturally necessary (e.g., login session maintenance, data state transitions)\n- **Dependency Relationship Mapping**: Track how data generated in each step is used in subsequent steps\n- **Exception Consideration**: Anticipate errors or exceptional cases that may occur in each step\n- **Business Rule Inference**: Understand domain-specific business rules and constraints hidden in scenario backgrounds\n\n**Scenario Example:**\n```\nValidate the modification of review posts.\n\nHowever, the fact that customers can write review posts in a shopping mall means that the customer has already joined the shopping mall, completed product purchase and payment, and the seller has completed delivery.\n\nTherefore, in this test function, all of these must be carried out, so before writing a review post, all of the following preliminary tasks must be performed. It will be quite a long process.\n\n1. Seller signs up\n2. Seller registers a product\n3. Customer signs up\n4. Customer views the product in detail\n5. Customer adds the product to shopping cart\n6. Customer places a purchase order\n7. Customer confirms purchase and makes payment\n8. Seller confirms order and processes delivery\n9. Customer writes a review post\n10. Customer modifies the review post\n11. Re-view the review post to confirm modifications.\n```\n\n### 2.2. DTO (Data Transfer Object) Definition Files\n- Data transfer objects composed of TypeScript type definitions\n- Include all type information used in API requests/responses\n- Support nested namespace and interface structures, utilizing `typia` tags\n\n**Deep Analysis Requirements:**\n- **Type Constraint Analysis**: Complete understanding of validation rules like `tags.Format<"uuid">`, `tags.MinItems<1>`, `tags.Minimum<0>`\n- **Interface Inheritance Relationship Analysis**: Analyze relationships between types through `extends`, `Partial<>`, `Omit<>`\n- **Namespace Structure Exploration**: Understand the purpose and usage timing of nested types like `ICreate`, `IUpdate`, `ISnapshot`\n- **Required/Optional Field Distinction**: Understand which fields are required and optional, and their respective business meanings\n- **Data Transformation Pattern Identification**: Track data lifecycle like Create → Entity → Update → Snapshot\n- **Type Safety Requirements**: Understand exact type matching and validation logic required by each API\n\n### 2.3. SDK (Software Development Kit) Library\n- TypeScript functions corresponding to each API endpoint\n- Ensures type-safe API calls and is automatically generated by Nestia\n- Includes complete function signatures, metadata, and path information\n\n**Deep Analysis Requirements:**\n- **API Endpoint Classification**: Understand functional and role-based API grouping through namespace structure\n- **Parameter Structure Analysis**: Distinguish roles of path parameters, query parameters, and body in Props type\n- **HTTP Method Meaning Understanding**: Understand the meaning of each method (POST, GET, PUT, DELETE) in respective business logic\n- **Response Type Mapping**: Understand relationships between Output types and actual business objects\n- **Permission System Analysis**: Understand access permission structure through namespaces like `sellers`, `customers`\n- **API Call Order**: Understand dependency relationships of other APIs that must precede specific API calls\n- **Error Handling Methods**: Predict possible HTTP status codes and error conditions for each API\n\n### 2.4. Random-based Mock E2E Functions\n- Basic templates filled with `typia.random<T>()` for parameters without actual business logic\n- **Guide Role**: Show function call methods, type usage, and parameter patterns\n- When implementing, refer to this template structure but completely replace the content\n\n**Deep Analysis Requirements:**\n- **Function Signature Understanding**: Understand the meaning of `connection: api.IConnection` parameter and `Promise<void>` return type\n- **SDK Call Method**: Understand parameter structuring methods when calling API functions and `satisfies` keyword usage patterns\n- **Type Validation Pattern**: Understand `typia.assert()` usage and application timing\n- **Actual Data Requirements**: Understand how to compose actual business-meaningful data to replace `typia.random<T>()`\n- **Code Style Consistency**: Maintain consistency with existing codebase including indentation, variable naming, comment style\n- **Test Function Naming**: Understand existing naming conventions and apply them consistently to new test function names\n\n**Random-based Mock E2E Test Function Example:**\n```typescript\nexport const test_api_shoppings_customers_sales_reviews_update = async (\n  connection: api.IConnection,\n) => {\n  const output: IShoppingSaleReview.ISnapshot =\n    await api.functional.shoppings.customers.sales.reviews.update(connection, {\n      saleId: typia.random<string & Format<"uuid">>(),\n      id: typia.random<string & Format<"uuid">>(),\n      body: typia.random<IShoppingSaleReview.IUpdate>(),\n    });\n  typia.assert(output);\n};\n```\n\n**Comprehensive Analysis Approach:**\nThe Agent must understand the **interrelationships** among these 4 input materials beyond analyzing them individually. You must comprehensively understand how business flows required by scenarios can be implemented with DTOs and SDK, and how mock function structures map to actual requirements. Additionally, you must infer **unspecified parts** from given materials and proactively discover **additional elements needed** for complete E2E testing.\n\n### 2.5. Typia Guide\n\nWhen defining validation rules for input or response structures using `typia`, you **must** utilize `tags` exclusively through the `tags` namespace provided by the `typia` module. This ensures strict type safety, clarity, and compatibility with automated code generation and schema extraction.\nFor example, to use tags.Format<\'uuid\'>, you must reference it as tags.Format, not simply Format.\n\n#### 2.5.1. Correct Usage Examples\n\n```ts\nexport interface IUser {\n  username: string & tags.MinLength<3> & tags.MaxLength<20>;\n  email: string & tags.Format<"email">;\n  age: number & tags.Type<"uint32"> & tags.Minimum<18>;\n}\n```\n\n### 2.5.2. Invalid Usage Examples\n\n```ts\nexport interface IUser {\n  username: string & MinLength<3> & MaxLength<20>;\n  email: string & Format<"email">;\n  age: number & Type<"uint32"> & Minimum<18>;\n}\n```\n\n## 3. Core Writing Principles\n\n### 3.1. No Import Statements Rule\n- **ABSOLUTE RULE**: Never write any `import` statements at the beginning of your code\n- Start your response directly with `export async function`\n- Assume all dependencies are globally available:\n  - `typia` for type validation and random data generation\n  - `api` for SDK function calls\n  - All DTO types (IShoppingSeller, IShoppingCustomer, etc.)\n  - `TestValidator` for validation utilities\n  - `Format` and other type utilities\n\n### 3.2. Scenario Adherence Principles\n- **Absolute Principle**: Complete implementation of all steps specified in test scenarios in order\n  - If "11 steps" are specified in a scenario, all 11 steps must be implemented\n  - Changing step order or skipping steps is **absolutely prohibited**\n  - **Prioritize completeness over efficiency**\n- No step in scenarios can be omitted or changed\n  - "Seller signs up" → Must call seller signup API\n  - "Customer views the product in detail" → Must call product view API\n  - More specific step descriptions require more accurate implementation\n- Strictly adhere to logical order and dependencies of business flows\n  - Example: Product registration → Signup → Shopping cart → Order → Payment → Delivery → Review creation → Review modification\n  - Each step depends on results (IDs, objects, etc.) from previous steps, so order cannot be changed\n  - Data dependencies: `sale.id`, `order.id`, `review.id` etc. must be used in subsequent steps\n- **Proactive Scenario Analysis**: Discover and implement essential steps not explicitly mentioned\n  - Precisely analyze provided API functions and DTO types\n  - Identify intermediate steps needed for business logic completion\n  - Add validation steps necessary for data integrity even if not in scenarios\n\n### 3.3. Comment Writing Principles\n- **Required**: Write complete scenarios in JSDoc format at the top of test functions\n- Include scenario background explanation and overall process\n- Clearly document step-by-step numbers and descriptions\n- Explain business context of why such complex processes are necessary\n- **Format**: Use `/** ... */` block comments\n\n### 3.4. Function Naming Conventions\n- **Basic Format**: `test_api_{domain}_{action}_{specific_scenario}`\n- **prefix**: Must start with `test_api_`\n- **domain**: Reflect API endpoint domain and action (e.g., `shopping`, `customer`, `seller`)\n- **scenario**: Express representative name or characteristics of scenario (e.g., `review_update`, `login_failure`)\n- **Examples**: `test_api_shopping_sale_review_update`, `test_api_customer_authenticate_login_failure`\n\n### 3.5. SDK Usage Principles\n- **Required**: All API calls must use provided SDK functions\n- Direct HTTP calls or other methods are **absolutely prohibited**\n- Adhere to exact parameter structure and types of SDK functions\n- Call functions following exact namespace paths (`api.functional.shoppings.sellers...`)\n- **Important**: Use `satisfies` keyword in request body to enhance type safety\n  - Example: `body: { ... } satisfies IShoppingSeller.IJoin`\n  - Prevent compile-time type errors and support IDE auto-completion\n\n### 3.6. Type Validation Principles\n- **Basic Principle**: Perform `typia.assert(value)` when API response is not `void`\n- Ensure runtime type safety for all important objects and responses\n- Configure tests to terminate immediately upon type validation failure for clear error cause identification\n\n## 4. Detailed Implementation Guidelines\n\n### 4.1. Function Structure (Without Imports)\n```typescript\n/**\n * [Clearly explain test purpose]\n * \n * [Explain business context and necessity]\n * \n * [Step-by-step process]\n * 1. First step\n * 2. Second step\n * ...\n */\nexport async function test_api_{naming_convention}(\n  connection: api.IConnection,\n): Promise<void> {\n  // Implementation for each step\n}\n```\n\n### 4.2. Variable Declaration and Type Specification\n- Declare each API call result with clear types (`const seller: IShoppingSeller = ...`)\n- Write variable names meaningfully reflecting business domain\n- Use consistent naming convention (camelCase)\n- Prefer explicit type declaration over type inference\n\n### 4.3. API Call Patterns\n- Use exact namespace paths of SDK functions\n- Strictly adhere to parameter object structure\n- Use `satisfies` keyword in request body to enhance type safety\n\n### 4.4. Authentication and Session Management\n- Handle appropriate login/logout when multiple user roles are needed in test scenarios\n- Adhere to API call order appropriate for each role\'s permissions\n- **Important**: Clearly mark account switching points with comments\n- Example: Seller → Customer → Seller account switching\n- Accurately distinguish APIs accessible only after login in respective sessions\n\n### 4.5. Data Consistency Validation\n\n* Avoid using `TestValidator.notEquals()`. To assert that `b` is not of type `a`, write:\n  `TestValidator.equals(false)(typia.is<typeof a>(b))`.\n* You **must** use validation functions from `TestValidator` — do **not** use `typia.is`, `typia.assert`, Node\'s `assert`, or Jest\'s `expect`.\n  Using `TestValidator` ensures failure messages are descriptive via the `title`, making debugging much easier.\n* Appropriately validate ID matching, state transitions, and data integrity.\n* When comparing arrays or objects, ensure structural accuracy.\n* **Format**: `TestValidator.equals("description")(expected)(actual)`\n* Always include a clear description to provide meaningful error messages on test failure.\n* **Error Case Validation**: For expected error scenarios, use `TestValidator.error()` or `TestValidator.httpError()`.\n\n### 4.6. Test Validator Usage Guidelines\n\n#### ✅ Purpose\n\nThe `TestValidator` utility is required for all test assertions to ensure consistency, readability, and easier debugging. It provides descriptive error messages through the use of a `title`.\n\n#### ✅ Standard Usage Format\n\n```ts\nTestValidator.equals("description")(expected)(actual);\n```\n\n* `description`: A short, clear explanation of the test purpose\n* `expected`: The expected value\n* `actual`: The actual value being tested\n\n#### ✅ Examples\n\n```ts\nTestValidator.equals("Check commit existence and type")("object")(typeof system.commit);\nTestValidator.equals("Validate array length")(3)(data.length);\nTestValidator.equals("Assert value is not of type A")(false)(typia.is<typeof A>(b));\n```\n\n#### 🚫 Incorrect Usage Examples\n\n```ts\nTestValidator.equals("Wrong usage")("object", typeof system.commit)(typeof system.commit); // ❌ Invalid currying\nexpect(x).toBe(y);   // ❌ Do not use Jest\'s expect\nassert.equal(x, y);  // ❌ Do not use Node.js assert\ntypia.assert(x);     // ❌ Do not use typia.assert directly\n```\n\n#### 💡 Additional Guidelines\n\n* To assert a value is **not** of a given type, use:\n  `TestValidator.equals(false)(typia.is<Type>(value))`\n* **Never** use `typia.is`, `typia.assert`, `expect`, or `assert` directly in tests.\n  Only `TestValidator` functions must be used to maintain consistent test behavior and clear failure messages.\n* For error case validation, use `TestValidator.error()` or `TestValidator.httpError()`.\n\n\n## 5. Complete Implementation Example\n\nThe following is a complete example of E2E test function that should actually be written (starting directly with export, no imports):\n\n```typescript\n/**\n * Validate the modification of review posts.\n *\n * However, the fact that customers can write review posts in a shopping mall means \n * that the customer has already joined the shopping mall, completed product purchase \n * and payment, and the seller has completed delivery.\n *\n * Therefore, in this test function, all of these must be carried out, so before \n * writing a review post, all of the following preliminary tasks must be performed. \n * It will be quite a long process.\n *\n * 1. Seller signs up\n * 2. Seller registers a product\n * 3. Customer signs up\n * 4. Customer views the product in detail\n * 5. Customer adds the product to shopping cart\n * 6. Customer places a purchase order\n * 7. Customer confirms purchase and makes payment\n * 8. Seller confirms order and processes delivery\n * 9. Customer writes a review post\n * 10. Customer modifies the review post\n * 11. Re-view the review post to confirm modifications.\n */\nexport async function test_api_shopping_sale_review_update(\n  connection: api.IConnection,\n): Promise<void> {\n  // 1. Seller signs up\n  const seller: IShoppingSeller = \n    await api.functional.shoppings.sellers.authenticate.join(\n      connection,\n      {\n        body: {\n          email: "john@wrtn.io",\n          name: "John Doe",\n          nickname: "john-doe",\n          mobile: "821011112222",\n          password: "1234",\n        } satisfies IShoppingSeller.IJoin,\n      },\n    );\n  typia.assert(seller);\n\n  // 2. Seller registers a product\n  const sale: IShoppingSale = \n    await api.functional.shoppings.sellers.sales.create(\n      connection,\n      {\n        body: {\n          name: "Sample Product",\n          description: "This is a sample product for testing",\n          price: 10000,\n          currency: "KRW",\n          category: "electronics",\n          units: [{\n            name: "Default Unit",\n            primary: true,\n            stocks: [{\n              name: "Default Stock",\n              quantity: 100,\n              price: 10000,\n            }],\n          }],\n          images: [],\n          tags: [],\n        } satisfies IShoppingSale.ICreate,\n      },\n    );\n  typia.assert(sale);\n\n  // 3. Customer signs up\n  const customer: IShoppingCustomer = \n    await api.functional.shoppings.customers.authenticate.join(\n      connection,\n      {\n        body: {\n          email: "anonymous@wrtn.io",\n          name: "Jaxtyn",\n          nickname: "anonymous",\n          mobile: "821033334444",\n          password: "1234",\n        } satisfies IShoppingCustomer.IJoin,\n      },\n    );\n  typia.assert(customer);\n  \n  // 4. Customer views the product in detail\n  const saleReloaded: IShoppingSale = \n    await api.functional.shoppings.customers.sales.at(\n      connection,\n      {\n        id: sale.id,\n      },\n    );\n  typia.assert(saleReloaded);\n  TestValidator.equals("sale")(sale.id)(saleReloaded.id);\n\n  // 5. Customer adds the product to shopping cart\n  const commodity: IShoppingCartCommodity = \n    await api.functional.shoppings.customers.carts.commodities.create(\n      connection,\n      {\n        body: {\n          sale_id: sale.id,\n          stocks: sale.units.map((u) => ({\n            unit_id: u.id,\n            stock_id: u.stocks[0].id,\n            quantity: 1,\n          })),\n          volume: 1,\n        } satisfies IShoppingCartCommodity.ICreate,\n      },\n    );\n  typia.assert(commodity);\n\n  // 6. Customer places a purchase order\n  const order: IShoppingOrder = \n    await api.functional.shoppings.customers.orders.create(\n      connection,\n      {\n        body: {\n          goods: [\n            {\n              commodity_id: commodity.id,\n              volume: 1,\n            },\n          ],\n        } satisfies IShoppingOrder.ICreate,\n      }\n    );\n  typia.assert(order);\n\n  // 7. Customer confirms purchase and makes payment\n  const publish: IShoppingOrderPublish = \n    await api.functional.shoppings.customers.orders.publish.create(\n      connection,\n      {\n        orderId: order.id,\n        body: {\n          address: {\n            mobile: "821033334444",\n            name: "Jaxtyn",\n            country: "South Korea",\n            province: "Seoul",\n            city: "Seoul Seocho-gu",\n            department: "Wrtn Apartment",\n            possession: "140-1415",\n            zip_code: "08273",\n          },\n          vendor: {\n            code: "@payment-vendor-code",\n            uid: "@payment-transaction-uid",\n          },\n        } satisfies IShoppingOrderPublish.ICreate,\n      },\n    );\n  typia.assert(publish);\n\n  // Switch to seller account\n  await api.functional.shoppings.sellers.authenticate.login(\n    connection,\n    {\n      body: {\n        email: "john@wrtn.io",\n        password: "1234",\n      } satisfies IShoppingSeller.ILogin,\n    },\n  );\n\n  // 8. Seller confirms order and processes delivery\n  const orderReloaded: IShoppingOrder = \n    await api.functional.shoppings.sellers.orders.at(\n      connection,\n      {\n        id: order.id,\n      }\n    );\n  typia.assert(orderReloaded);\n  TestValidator.equals("order")(order.id)(orderReloaded.id);\n\n  const delivery: IShoppingDelivery = \n    await api.functional.shoppings.sellers.deliveries.create(\n      connection,\n      {\n        body: {\n          pieces: order.goods.map((g) => \n            g.commodity.stocks.map((s) => ({\n              publish_id: publish.id,\n              good_id: g.id,\n              stock_id: s.id,\n              quantity: 1,\n            }))).flat(),\n          journeys: [\n            {\n              type: "delivering",\n              title: "Delivering",\n              description: null,\n              started_at: new Date().toISOString(),\n              completed_at: new Date().toISOString(),\n            },\n          ],\n          shippers: [\n            {\n              company: "Lozen",\n              name: "QuickMan",\n              mobile: "01055559999",\n            }\n          ],\n        } satisfies IShoppingDelivery.ICreate\n      }\n    )\n  typia.assert(delivery);\n\n  // Switch back to customer account\n  await api.functional.shoppings.customers.authenticate.login(\n    connection,\n    {\n      body: {\n        email: "anonymous@wrtn.io",\n        password: "1234",\n      } satisfies IShoppingCustomer.ILogin,\n    },\n  );\n\n  // 9. Customer writes a review post\n  const review: IShoppingSaleReview = \n    await api.functional.shoppings.customers.sales.reviews.create(\n      connection,\n      {\n        saleId: sale.id,\n        body: {\n          good_id: order.goods[0].id,\n          title: "Some title",\n          body: "Some content body",\n          format: "md",\n          files: [],\n          score: 100,\n        } satisfies IShoppingSaleReview.ICreate,\n      },\n    );\n  typia.assert(review);\n\n  // 10. Customer modifies the review post\n  const snapshot: IShoppingSaleReview.ISnapshot = \n    await api.functional.shoppings.customers.sales.reviews.update(\n      connection,\n      {\n        saleId: sale.id,\n        id: review.id,\n        body: {\n          title: "Some new title",\n          body: "Some new content body",\n        } satisfies IShoppingSaleReview.IUpdate,\n      },\n    );\n  typia.assert(snapshot);\n\n  // 11. Re-view the review post to confirm modifications\n  const read: IShoppingSaleReview = \n    await api.functional.shoppings.customers.sales.reviews.at(\n      connection,\n      {\n        saleId: sale.id,\n        id: review.id,\n      },\n    );\n  typia.assert(read);\n  TestValidator.equals("snapshots")(read.snapshots)([\n    ...review.snapshots,\n    snapshot,\n  ]);\n}\n```\n\n## 6. Error Scenario Testing\n\n### 6.1. Purpose and Importance of Error Testing\nE2E testing must verify that systems operate correctly not only in normal business flows but also in expected error situations. It\'s important to confirm that appropriate HTTP status codes and error messages are returned in situations like incorrect input, unauthorized access, requests for non-existent resources.\n\n### 6.2. Error Validation Function Usage\n- **TestValidator.error()**: For general error situations where HTTP status code cannot be determined with certainty\n- **TestValidator.httpError()**: When specific HTTP status code can be determined with confidence\n- **Format**: `TestValidator.httpError("description")(statusCode)(() => APICall)`\n\n### 6.3. Error Test Writing Principles\n- **Clear Failure Conditions**: Clearly set conditions that should intentionally fail\n- **Appropriate Test Data**: Simulate realistic error situations like non-existent emails, incorrect passwords\n- **Concise Structure**: Unlike normal flows, compose error tests with minimal steps\n- **Function Naming Convention**: `test_api_{domain}_{action}_failure` or `test_api_{domain}_{action}_{specific_error}`\n- **CRITICAL**: Never use `// @ts-expect-error` comments when testing error cases. These functions test **runtime errors**, not compilation errors. The TypeScript code should compile successfully while the API calls are expected to fail at runtime.\n\n### 6.4. Error Test Example (Without Imports)\n\n```typescript\n/**\n * Validate customer login failure.\n * \n * Verify that appropriate error response is returned when attempting \n * to login with a non-existent email address.\n */\nexport async function test_api_customer_authenticate_login_failure(\n  connection: api.IConnection,\n): Promise<void> {\n  await TestValidator.httpError("login failure")(403)(() =>\n    api.functional.shoppings.customers.authenticate.login(\n      connection,\n      {\n        body: {\n          email: "never-existing-email@sadfasdfasdf.com",\n          password: "1234",\n        } satisfies IShoppingCustomer.ILogin,\n      },\n    ),\n  );\n}\n```\n\n## 7. Final Checklist\n\nE2E test function writing completion requires verification of the following items:\n\n### 7.1. Essential Element Verification\n- [ ] **NO IMPORT STATEMENTS** - Function starts directly with `export async function`\n- [ ] Are all scenario steps implemented in order?\n- [ ] Are complete JSDoc-style comments written?\n- [ ] Does the function name follow naming conventions (`test_api_{domain}_{action}_{scenario}`)?\n- [ ] Are SDK used for all API calls?\n- [ ] Is the `satisfies` keyword used in request body?\n- [ ] Is `typia.assert` applied where necessary?\n- [ ] Are error test cases written without `// @ts-expect-error` comments?\n\n### 7.2. Quality Element Verification\n- [ ] Are variable names meaningful and consistent?\n- [ ] Are account switches performed at appropriate times?\n- [ ] Is data validation performed correctly?\n- [ ] Is code structure logical with good readability?\n- [ ] Are error scenarios handled appropriately when needed without TypeScript error suppression comments?\n- [ ] Is business logic completeness guaranteed?\n\n**REMEMBER**: Your code must start immediately with `export async function` - never include any import statements at the beginning. All dependencies are assumed to be globally available.\n\nPlease adhere to all these principles and guidelines to write complete and accurate E2E test functions. Your mission is not simply to write code, but to build a robust test system that perfectly reproduces and validates actual business scenarios.'
+}, {
+    id: v4(),
+    created_at: (new Date).toISOString(),
+    type: "systemMessage",
+    text: '# ✅ `TestValidator`\n\nYou are given access to the `TestValidator` utility, which provides functional testing helpers. It includes assertion helpers (`equals`, `predicate`) and error expectation helpers (`error`, `httpError`). All methods use **currying**, meaning you must call them **step-by-step** in sequence.\n\nThe following are the core functions you may use, along with exact signatures and usage rules:\n\n---\n\n## 🔹 `TestValidator.equals(title)(expected)(actual)`\n\n* **Purpose**: Validates that `expected` and `actual` values are deeply equal.\n* **Currying steps**:\n\n  1. `title: string` — description shown when the comparison fails.\n  2. `expected: T` — the baseline value. Must be the same type or **wider** than `actual`.\n  3. `actual: T` — the value to compare with.\n* **Returns**: `void`\n* **Exception**: Throws an error if `expected` and `actual` differ.\n* **Optional**: You can provide a second argument to `equals(title, exception)` to skip certain keys during comparison.\n\n```ts\nTestValidator.equals("Article must match")(expectedArticle)(receivedArticle);\n```\n\n❗ **Important: Expected value must be wider or equal in type.**\n\n```ts\n// ✅ Correct: actual ("md") is assignable to expected ("md" | "html")\nTestValidator.equals("Format check")(updatedSnapshot.format as "md" | "html")("md" as "md");\n\n// ❌ Incorrect: "md" is not assignable to "md" | "html" → compile-time error\nTestValidator.equals("Format check")("md" as "md")(updatedSnapshot.format as "md" | "html");\n```\n\nThis type direction ensures TypeScript can validate structural compatibility statically.\n\n❗ **Important: Please do not use it to check for the void type.**\n\n```ts\nTestValidator.equals("health check API는 void 반환")(undefined)(output) // Invalid!\n```\n\nYou cannot validate the `void` type directly. If you want to compare a function\'s return type that is `void`, use the following pattern:\n\n```ts\nTestValidator.equals("This type should be void")(typia.is<void>(target))(true); // Good!\n```\n\n\n---\n\n## 🔹 `TestValidator.predicate(title)(condition)`\n\n* **Purpose**: Validates that a boolean condition is true.\n* **Currying steps**:\n\n  1. `title: string` — message used when the condition fails.\n  2. `condition: boolean | () => boolean | () => Promise<boolean>` — condition to evaluate.\n* **Returns**:\n\n  * `void` if the condition is synchronous\n  * `Promise<void>` if the condition is asynchronous\n* **Exception**: Throws an error with the `title` if the condition is false.\n\n```ts\nTestValidator.predicate("User must be active")(() => user.status === "active");\n```\n\nTo resolve errors like:\n\n```error\nType \'{ page: number; limit: number; sort: string[]; }\' is not assignable to type \'IRequest\'.\n```\n\nit is recommended to use `TestValidator.predicate`.\n\nYou can provide a function that returns a boolean value, such as:\n\n```ts\nTestValidator.predicate("description of what you\'re testing")(() => {\n    return typia.is<Type>(targetObj);\n});\n```\n\nThis approach allows you to validate whether the object conforms to the expected type without causing assignment errors.\n\n\n---\n\n## 🔹 `TestValidator.error(title)(task)`\n\n* **Purpose**: Validates that the given task throws an error.\n* **Currying steps**:\n\n  1. `title: string` — message shown when no error is thrown.\n  2. `task: () => any | Promise<any>` — function that is expected to throw.\n* **Returns**:\n\n  * `void` or `Promise<void>`\n* **Exception**: Throws an error if the task completes **without** throwing.\n\n```ts\nTestValidator.error("Expected login to fail")(() => login(invalidCredentials));\n```\n\n---\n\n## 🔹 `TestValidator.httpError(title)(...statuses)(task)`\n\n* **Purpose**: Validates that the given task throws an HTTP error with one of the specified status codes.\n* **Currying steps**:\n\n  1. `title: string` — message shown when no HTTP error or unexpected status occurs.\n  2. `...statuses: number[]` — acceptable HTTP error codes.\n  3. `task: () => any | Promise<any>` — function that is expected to fail.\n* **Returns**:\n\n  * `void` or `Promise<void>`\n* **Exception**: Throws if no error is thrown, or if the status code does not match any in `statuses`.\n\n```ts\nTestValidator.httpError("Should return 403")(403)(() => accessAdminPage(user));\n```\n\n---\n\n# ⚠️ Currying is Required\n\nEach method uses **currying** — do **not** invoke with all parameters at once. You **must** call each method step by step (e.g., `f(x)(y)(z)`), not as `f(x, y, z)`.\n\n---\n\n# ⚠️ Type Direction Matters in `equals`\n\nThe type of `expected` must be **wider or equal** to the type of `actual`. This allows TypeScript to validate that the actual result conforms to what is expected. Reversing this order may cause a compile-time type error.\n\n```ts\n// ✅ Correct: expected is wider ("md" | "html"), actual is narrower ("md")\nTestValidator.equals("Format check")(updatedSnapshot.format as "md" | "html")("md" as "md");\n\n// ✅ Correct: expected is wider or equal type when comparing snapshots\nconst latest = reloaded.snapshots.at(-1);\nif (!latest) throw new Error("No snapshots found");\nTestValidator.equals("Latest snapshot match")(latest)(updatedSnapshot);\n\n// ❌ Incorrect: expected is narrower ("md"), actual is wider ("md" | "html") → type error\nTestValidator.equals("Format check")("md" as "md")(updatedSnapshot.format as "md" | "html");\n\n// ❌ Incorrect: swapped snapshot order may cause type error\nTestValidator.equals("Latest snapshot match")(updatedSnapshot)(reloaded.snapshots.at(-1));\n```\n\n---\n\n# 🧠 Purpose\n\nUse `TestValidator` in automated tests to assert:\n\n* equality (`equals`)\n* correctness of booleans (`predicate`)\n* expected failure cases (`error`, `httpError`)\n\n---\n\n# 🧪 Example\n\n```ts\nTestValidator.equals("Returned user must match")(expectedUser)(receivedUser);\nTestValidator.predicate("User must be admin")(() => user.role === "admin");\nawait TestValidator.error("Creating with invalid data should fail")(() => createUser(invalidData));\nawait TestValidator.httpError("Forbidden access")(403, 401)(() => accessSecret(user));\n```\n\n# ⚠️ Be Careful with Empty Array Literals and Type Inference in `equals`\n\nWhen using `TestValidator.equals`, be cautious with implicit type inference — especially with empty literals like `[]` or `null`.\n\n## 🔸 Problem: `[]` becomes `never[]`\n\nIf you pass an empty array literal (`[]`) directly as the `expected` value, TypeScript will infer its type as `never[]`, which is unlikely to match the actual data type.\n\n```ts\n// ❌ Incorrect: `[]` is inferred as `never[]`, causing a type mismatch\nTestValidator.equals("Result data should be empty")([])(result.data); // type error\n```\n\n## ✅ Recommended: Declare types explicitly with variables\n\nInstead of passing literals directly, declare variables with explicit types to guide TypeScript\'s inference:\n\n```ts\n// ✅ Correct: declare expected with the proper type\nconst expected: ISummary[] = [];\nconst actual: ISummary[] = result.data;\nTestValidator.equals("Result data should be empty")(expected)(actual);\n```\n\nThis helps ensure type compatibility and avoids hidden inference issues like `never[]`.\n\n---\n\n## 🔸 Problem: Union types like `Type | null`\n\nAnother common mistake is passing a value with a union type (e.g., `Type | null`) as `expected`, while `actual` has a narrower type (e.g., just `Type`). This can lead to errors like:\n\n```\nArgument of type \'(string & Format<"uuid">) | null\' is not assignable to parameter of type \'null\'.\n```\n\n## ✅ Recommended: Align types exactly\n\nUse explicit variable declarations with exact types to prevent such mismatches:\n\n```ts\n// ✅ Correct: Align both types exactly\nconst expected: string & Format<"uuid"> | null = generatedUuid;\nconst actual: string & Format<"uuid"> = response.id;\nTestValidator.equals("UUIDs must match")(expected)(actual);\n```\n\nThis practice helps catch type errors early and ensures that the validator works as intended with strict type checking.\n\n\n# ⚠️ Prefer Property-Level Comparison for Complex Objects\n\nWhen using `TestValidator.equals` to compare objects (especially arrays of objects), it\'s easy to run into subtle type mismatches or unintentional structural differences — such as missing optional fields, different property orders, or union type overlaps.\n\n```ts\n// ❌ Risky: Full object comparison may fail due to minor type differences\nTestValidator.equals("File list updated")([\n  { name: "doc", extension: "pdf", url: "https://files.example.com/doc.pdf" },\n])(updatedSnapshot.files);\n```\n\nEven if the runtime values look the same, TypeScript may infer slightly different types for literals vs. actual data, which can lead to confusing type errors.\n\n---\n\n## ✅ Recommended: Compare individual properties explicitly\n\nTo avoid fragile deep comparisons, prefer comparing each property separately:\n\n```ts\nconst file = updatedSnapshot.files[0];\nTestValidator.equals("File name should be \'doc\'")("doc")(file.name);\nTestValidator.equals("File extension should be \'pdf\'")("pdf")(file.extension);\nTestValidator.equals("File URL should match")("https://files.example.com/doc.pdf")(file.url);\n```\n\nThis approach gives:\n\n* Clearer failure messages\n* More precise type checking\n* Easier debugging when only part of the object is incorrect\n\nUse full-object comparison only when the types are tightly controlled and guaranteed to match exactly.'
+}, {
+    id: v4(),
+    created_at: (new Date).toISOString(),
+    type: "systemMessage",
+    text: "### ❌ Line terminator not permitted before arrow.\n\nWhen you get a syntax error saying \"`Line terminator not permitted before arrow.`\", it means the arrow `=>` is placed at the start of a new line, which is invalid.\n\n**Fix this by placing `=>` at the end of the previous line**, for example:\n\n```ts\n() => api.doSomething()\n```\n\ninstead of\n\n```ts\n()\n=> api.doSomething()\n```\n\nAlternatively, use a block body with braces:\n\n```ts\n() => {\n  return api.doSomething();\n}\n```\n\n### ❌ The operand of a 'delete' operator must be optional\n\nWhen you get a TypeScript error like:\n\n```\nThe operand of a 'delete' operator must be optional.\n```\n\nIt means you're trying to use the `delete` operator on a **non-optional property**, which is not allowed in strict mode.\n\nFor example:\n\n```ts\ntype User = { name: string };\nconst user: User = { name: \"Alice\" };\n\ndelete user.name; // ❌ Error: 'name' is not optional\n```\n\n#### ✅ Fix this by making the property optional:\n\n```ts\ntype User = { name?: string }; // name is now optional\nconst user: User = { name: \"Alice\" };\n\ndelete user.name; // ✅ OK\n```\n\n#### ✅ Or avoid using `delete` altogether:\n\nIn most cases, **you should avoid using `delete`** in TypeScript.\nInstead, explicitly set the value to `undefined`:\n\n```ts\nuser.name = undefined; // ✅ Preferred in most cases\n```\n\n> 🔎 In TypeScript, `delete` is primarily intended for dynamic objects like `Record<string, any>`.\n> When working with structured types (interfaces, classes), prefer marking fields as optional and assigning `undefined` instead of deleting them."
 }, {
     id: v4(),
     created_at: (new Date).toISOString(),
@@ -10499,6 +10614,10 @@ async function process(ctx, scenario) {
     enforceToolCall(agentica);
     await agentica.conversate("Create e2e test functions.");
     if (pointer.value === null) throw new Error("Failed to create test code.");
+    const typeReferences = Array.from(new Set(Object.keys(artifacts.document.components.schemas).map((key => key.split(".")[0]))));
+    pointer.value.content = pointer.value.content.replace(/^[ \t]*import\b[\s\S]*?;[ \t]*$/gm, "").trim();
+    pointer.value.content = [ `import { TestValidator } from "@nestia/e2e";`, `import typia, { tags } from "typia";`, "", `import api from "@ORGANIZATION/PROJECT-api";`, ...typeReferences.map((ref => `import type { ${ref} } from "@ORGANIZATION/PROJECT-api/lib/structures/${ref}";`)), "", pointer.value.content ].join("\n");
+    pointer.value.content = pointer.value.content.replaceAll('string & Format<"uuid">', 'string & tags.Format<"uuid">');
     return pointer.value;
 }
 
@@ -10531,7 +10650,7 @@ const claude$1 = {
             properties: {
                 scenario: {
                     title: "Strategic approach for test implementation",
-                    description: "Strategic approach for test implementation.\n\nDefine the high-level strategy and logical flow for testing the given\nscenario. Focus on test methodology, data preparation, and assertion\nstrategy.\n\n### Critical Requirements\n\n- Must follow the Test Generation Guildelines.\n- Must Planning the test code Never occur the typescript compile error.\n\n### Planning Elements:\n\n#### Test Methodology\n\n- Identify test scenario type (CRUD operation, authentication flow,\n  validation test)\n- Define test data requirements and preparation strategy\n- Plan positive/negative test cases and edge cases\n- Design assertion logic and validation points\n\n#### Execution Strategy\n\n- Outline step-by-step test execution flow\n- Plan error handling and exception plans\n- Define cleanup and teardown procedures\n- Identify dependencies and prerequisites\n\n### Example Plan:\n\n    Test Strategy: Article Creation Validation\n    1. Prepare valid article data with required fields\n    2. Execute POST request to create article\n    3. Validate response structure and data integrity\n    4. Test error plans (missing fields, invalid data)\n    5. Verify database state changes\n    6. Reconsider the scenario if it doesn't follow the Test Generation\n       Guildelines.",
+                    description: "Strategic approach for test implementation.\n\nDefine the high-level strategy and logical flow for testing the given\nscenario. Focus on test methodology, data preparation, and assertion\nstrategy.\n\n### Critical Requirements\n\n- Must follow the Test Generation Guidelines.\n- Must Planning the test code Never occur the TypeScript compile error.\n- NEVER include import statements in planning or implementation.\n\n### Planning Elements:\n\n#### Test Methodology\n\n- Identify test scenario type (CRUD operation, authentication flow,\n  validation test)\n- Define test data requirements and preparation strategy\n- Plan positive/negative test cases and edge cases\n- Design assertion logic and validation points\n\n#### Execution Strategy\n\n- Outline step-by-step test execution flow\n- Plan error handling and exception plans\n- Define cleanup and teardown procedures\n- Identify dependencies and prerequisites\n\n### Example Plan:\n\n    Test Strategy: Article Creation Validation\n    1. Prepare valid article data with required fields\n    2. Execute POST request to create article\n    3. Validate response structure and data integrity\n    4. Test error plans (missing fields, invalid data)\n    5. Verify database state changes\n    6. Reconsider the scenario if it doesn't follow the Test Generation\n       Guidelines.",
                     type: "string"
                 },
                 domain: {
@@ -10615,7 +10734,7 @@ const collection$1 = {
                 properties: {
                     scenario: {
                         title: "Strategic approach for test implementation",
-                        description: "Strategic approach for test implementation.\n\nDefine the high-level strategy and logical flow for testing the given\nscenario. Focus on test methodology, data preparation, and assertion\nstrategy.\n\n### Critical Requirements\n\n- Must follow the Test Generation Guildelines.\n- Must Planning the test code Never occur the typescript compile error.\n\n### Planning Elements:\n\n#### Test Methodology\n\n- Identify test scenario type (CRUD operation, authentication flow,\n  validation test)\n- Define test data requirements and preparation strategy\n- Plan positive/negative test cases and edge cases\n- Design assertion logic and validation points\n\n#### Execution Strategy\n\n- Outline step-by-step test execution flow\n- Plan error handling and exception plans\n- Define cleanup and teardown procedures\n- Identify dependencies and prerequisites\n\n### Example Plan:\n\n    Test Strategy: Article Creation Validation\n    1. Prepare valid article data with required fields\n    2. Execute POST request to create article\n    3. Validate response structure and data integrity\n    4. Test error plans (missing fields, invalid data)\n    5. Verify database state changes\n    6. Reconsider the scenario if it doesn't follow the Test Generation\n       Guildelines.",
+                        description: "Strategic approach for test implementation.\n\nDefine the high-level strategy and logical flow for testing the given\nscenario. Focus on test methodology, data preparation, and assertion\nstrategy.\n\n### Critical Requirements\n\n- Must follow the Test Generation Guidelines.\n- Must Planning the test code Never occur the TypeScript compile error.\n- NEVER include import statements in planning or implementation.\n\n### Planning Elements:\n\n#### Test Methodology\n\n- Identify test scenario type (CRUD operation, authentication flow,\n  validation test)\n- Define test data requirements and preparation strategy\n- Plan positive/negative test cases and edge cases\n- Design assertion logic and validation points\n\n#### Execution Strategy\n\n- Outline step-by-step test execution flow\n- Plan error handling and exception plans\n- Define cleanup and teardown procedures\n- Identify dependencies and prerequisites\n\n### Example Plan:\n\n    Test Strategy: Article Creation Validation\n    1. Prepare valid article data with required fields\n    2. Execute POST request to create article\n    3. Validate response structure and data integrity\n    4. Test error plans (missing fields, invalid data)\n    5. Verify database state changes\n    6. Reconsider the scenario if it doesn't follow the Test Generation\n       Guidelines.",
                         type: "string"
                     },
                     domain: {
@@ -10701,7 +10820,7 @@ const collection$1 = {
                     scenario: {
                         type: "string",
                         title: "Strategic approach for test implementation",
-                        description: "Strategic approach for test implementation.\n\nDefine the high-level strategy and logical flow for testing the given\nscenario. Focus on test methodology, data preparation, and assertion\nstrategy.\n\n### Critical Requirements\n\n- Must follow the Test Generation Guildelines.\n- Must Planning the test code Never occur the typescript compile error.\n\n### Planning Elements:\n\n#### Test Methodology\n\n- Identify test scenario type (CRUD operation, authentication flow,\n  validation test)\n- Define test data requirements and preparation strategy\n- Plan positive/negative test cases and edge cases\n- Design assertion logic and validation points\n\n#### Execution Strategy\n\n- Outline step-by-step test execution flow\n- Plan error handling and exception plans\n- Define cleanup and teardown procedures\n- Identify dependencies and prerequisites\n\n### Example Plan:\n\n    Test Strategy: Article Creation Validation\n    1. Prepare valid article data with required fields\n    2. Execute POST request to create article\n    3. Validate response structure and data integrity\n    4. Test error plans (missing fields, invalid data)\n    5. Verify database state changes\n    6. Reconsider the scenario if it doesn't follow the Test Generation\n       Guildelines."
+                        description: "Strategic approach for test implementation.\n\nDefine the high-level strategy and logical flow for testing the given\nscenario. Focus on test methodology, data preparation, and assertion\nstrategy.\n\n### Critical Requirements\n\n- Must follow the Test Generation Guidelines.\n- Must Planning the test code Never occur the TypeScript compile error.\n- NEVER include import statements in planning or implementation.\n\n### Planning Elements:\n\n#### Test Methodology\n\n- Identify test scenario type (CRUD operation, authentication flow,\n  validation test)\n- Define test data requirements and preparation strategy\n- Plan positive/negative test cases and edge cases\n- Design assertion logic and validation points\n\n#### Execution Strategy\n\n- Outline step-by-step test execution flow\n- Plan error handling and exception plans\n- Define cleanup and teardown procedures\n- Identify dependencies and prerequisites\n\n### Example Plan:\n\n    Test Strategy: Article Creation Validation\n    1. Prepare valid article data with required fields\n    2. Execute POST request to create article\n    3. Validate response structure and data integrity\n    4. Test error plans (missing fields, invalid data)\n    5. Verify database state changes\n    6. Reconsider the scenario if it doesn't follow the Test Generation\n       Guidelines."
                     },
                     domain: {
                         type: "string",
@@ -10935,10 +11054,6 @@ const claude = {
                     title: "The reason of the function call",
                     description: "The reason of the function call.",
                     type: "string"
-                },
-                userPlanningRequirements: {
-                    description: "# Define prompts to translate user planning requirements into messages for internal agents\n\nThis prompt defines how to convert a user's planning-oriented requirements\ninto a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if\nsome parts of the user's input are inappropriate or insufficient from a\nplanning standpoint, you are allowed to add **supplementary remarks**—but\nonly under strict rules.\n\n# Supplementary Remark Rules\n\n1. **Definition** A supplementary remark is additional information that may\n   differ from the user's original intent. Because of this, **you must\n   clearly indicate that it is _not_ part of the user’s thinking**.\n2. **When to Supplement**\n\n- If the user's input reveals a lack of technical understanding (e.g.,\n  suggesting \"put all data into one table\"), and the plan is not an MVP or\n  PoC, it's encouraged to make reasonable additions for a more scalable or\n  robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement\n  the content to ensure completeness.\n\n3. **When Not to Supplement**\n\n- If the user's input is vague or ambiguous, **do not assume or add extra\n  details**. Instead, it’s better to ask the user follow-up questions to\n  clarify their intent.\n- If the user has made no comment on design, **do not impose design-related\n  decisions** (e.g., colors, fonts, tone). However, you may state\n  explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds\n  value, as such goals are assumed in all services.\n\n# Style Guidelines\n\nThis prompt is delivered to the sub-agent, and several are created for\nparallel processing of the sub-agent. Additionally, there should be a guide\nto style, since sub-agents cannot create different styles of documents due\nto the disconnection of their conversations with each other.\n\nFor example, there should be a hyperlink to the previous document, the next\ndocument, before or after the document, or there should be no more than N\nheadings. The entire content of the document will have requirements, such\nas maintaining informal or formal language.\n\nThe style guide should include conventions for Markdown formatting elements\nsuch as headings, lists, and tables. Additionally, it should define\nexpectations regarding document length and overall composition. When\ndescribing structural guidelines, include a template to illustrate the\nrecommended format.\n\n# Limiting the volume of a document\n\nHowever, do not go beyond the volume guide; each agent only needs to create\none page because the agent receiving this document will be created as many\nas the number of pages.",
-                    type: "string"
                 }
             },
             required: [ "reason" ],
@@ -10970,15 +11085,11 @@ const claude = {
         },
         description: "Run Analyze Agent.\n\nExecutes the Analyze agent to process user requirements and generate a\nstructured specification document. This agent analyzes all conversation\nhistory between users and AI, separates business logic from technical\nrequirements, and establishes development priorities and scope.\n\n**IMPORTANT**: Only call this function when sufficient requirements have\nbeen discussed to generate a comprehensive specification. The context must\ncontain enough detail about the system's purpose, core features, data\nmodels, and business rules. If requirements are unclear or incomplete,\ncontinue gathering information through conversation instead.\n\nThe agent will automatically generate follow-up questions for any ambiguous\nrequirements and continuously refine its understanding through iterative\nconversation. When executed after other agents have generated code, it can\nalso interpret change requests in the context of existing implementations.",
         validate: (() => {
-            const _io0 = input => "string" === typeof input.reason && (undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements);
+            const _io0 = input => "string" === typeof input.reason;
             const _vo0 = (input, _path, _exceptionable = true) => [ "string" === typeof input.reason || _report(_exceptionable, {
                 path: _path + ".reason",
                 expected: "string",
                 value: input.reason
-            }), undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements || _report(_exceptionable, {
-                path: _path + ".userPlanningRequirements",
-                expected: "(string | undefined)",
-                value: input.userPlanningRequirements
             }) ].every((flag => flag));
             const __is = input => "object" === typeof input && null !== input && _io0(input);
             let errors;
@@ -11022,10 +11133,6 @@ const claude = {
                     title: "The reason of the function call",
                     description: "The reason of the function call.",
                     type: "string"
-                },
-                userPlanningRequirements: {
-                    description: "# Define prompts to translate user planning requirements into messages for internal agents\n\nThis prompt defines how to convert a user's planning-oriented requirements\ninto a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if\nsome parts of the user's input are inappropriate or insufficient from a\nplanning standpoint, you are allowed to add **supplementary remarks**—but\nonly under strict rules.\n\n# Supplementary Remark Rules\n\n1. **Definition** A supplementary remark is additional information that may\n   differ from the user's original intent. Because of this, **you must\n   clearly indicate that it is _not_ part of the user’s thinking**.\n2. **When to Supplement**\n\n- If the user's input reveals a lack of technical understanding (e.g.,\n  suggesting \"put all data into one table\"), and the plan is not an MVP or\n  PoC, it's encouraged to make reasonable additions for a more scalable or\n  robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement\n  the content to ensure completeness.\n\n3. **When Not to Supplement**\n\n- If the user's input is vague or ambiguous, **do not assume or add extra\n  details**. Instead, it’s better to ask the user follow-up questions to\n  clarify their intent.\n- If the user has made no comment on design, **do not impose design-related\n  decisions** (e.g., colors, fonts, tone). However, you may state\n  explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds\n  value, as such goals are assumed in all services.\n\n# Style Guidelines\n\nThis prompt is delivered to the sub-agent, and several are created for\nparallel processing of the sub-agent. Additionally, there should be a guide\nto style, since sub-agents cannot create different styles of documents due\nto the disconnection of their conversations with each other.\n\nFor example, there should be a hyperlink to the previous document, the next\ndocument, before or after the document, or there should be no more than N\nheadings. The entire content of the document will have requirements, such\nas maintaining informal or formal language.\n\nThe style guide should include conventions for Markdown formatting elements\nsuch as headings, lists, and tables. Additionally, it should define\nexpectations regarding document length and overall composition. When\ndescribing structural guidelines, include a template to illustrate the\nrecommended format.\n\n# Limiting the volume of a document\n\nHowever, do not go beyond the volume guide; each agent only needs to create\none page because the agent receiving this document will be created as many\nas the number of pages.",
-                    type: "string"
                 }
             },
             required: [ "reason" ],
@@ -11057,15 +11164,11 @@ const claude = {
         },
         description: "Run prisma agent.\n\nExecutes the Prisma agent to generate database schema files and ERD\ndocumentation. This agent reads the requirements specification created by\nthe {@link analyze Analyze agent} and produces a complete Prisma schema with\ncomprehensive documentation for each entity and attribute.\n\n**PREREQUISITE**: Only call this function after the {@link analyze} function\nhas been successfully executed and a requirements specification document\nhas been generated. The Prisma agent depends on the structured requirements\nanalysis to design the database schema properly. Without a completed\nrequirements specification, this function should NOT be called.\n\nThe agent will automatically validate the generated schema using the Prisma\ncompiler, self-correct any compilation errors through feedback loops, and\ngenerate ERD documentation using prisma-markdown. An internal review\nprocess ensures schema quality and optimization.",
         validate: (() => {
-            const _io0 = input => "string" === typeof input.reason && (undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements);
+            const _io0 = input => "string" === typeof input.reason;
             const _vo0 = (input, _path, _exceptionable = true) => [ "string" === typeof input.reason || _report(_exceptionable, {
                 path: _path + ".reason",
                 expected: "string",
                 value: input.reason
-            }), undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements || _report(_exceptionable, {
-                path: _path + ".userPlanningRequirements",
-                expected: "(string | undefined)",
-                value: input.userPlanningRequirements
             }) ].every((flag => flag));
             const __is = input => "object" === typeof input && null !== input && _io0(input);
             let errors;
@@ -11109,10 +11212,6 @@ const claude = {
                     title: "The reason of the function call",
                     description: "The reason of the function call.",
                     type: "string"
-                },
-                userPlanningRequirements: {
-                    description: "# Define prompts to translate user planning requirements into messages for internal agents\n\nThis prompt defines how to convert a user's planning-oriented requirements\ninto a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if\nsome parts of the user's input are inappropriate or insufficient from a\nplanning standpoint, you are allowed to add **supplementary remarks**—but\nonly under strict rules.\n\n# Supplementary Remark Rules\n\n1. **Definition** A supplementary remark is additional information that may\n   differ from the user's original intent. Because of this, **you must\n   clearly indicate that it is _not_ part of the user’s thinking**.\n2. **When to Supplement**\n\n- If the user's input reveals a lack of technical understanding (e.g.,\n  suggesting \"put all data into one table\"), and the plan is not an MVP or\n  PoC, it's encouraged to make reasonable additions for a more scalable or\n  robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement\n  the content to ensure completeness.\n\n3. **When Not to Supplement**\n\n- If the user's input is vague or ambiguous, **do not assume or add extra\n  details**. Instead, it’s better to ask the user follow-up questions to\n  clarify their intent.\n- If the user has made no comment on design, **do not impose design-related\n  decisions** (e.g., colors, fonts, tone). However, you may state\n  explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds\n  value, as such goals are assumed in all services.\n\n# Style Guidelines\n\nThis prompt is delivered to the sub-agent, and several are created for\nparallel processing of the sub-agent. Additionally, there should be a guide\nto style, since sub-agents cannot create different styles of documents due\nto the disconnection of their conversations with each other.\n\nFor example, there should be a hyperlink to the previous document, the next\ndocument, before or after the document, or there should be no more than N\nheadings. The entire content of the document will have requirements, such\nas maintaining informal or formal language.\n\nThe style guide should include conventions for Markdown formatting elements\nsuch as headings, lists, and tables. Additionally, it should define\nexpectations regarding document length and overall composition. When\ndescribing structural guidelines, include a template to illustrate the\nrecommended format.\n\n# Limiting the volume of a document\n\nHowever, do not go beyond the volume guide; each agent only needs to create\none page because the agent receiving this document will be created as many\nas the number of pages.",
-                    type: "string"
                 }
             },
             required: [ "reason" ],
@@ -11144,15 +11243,11 @@ const claude = {
         },
         description: "Run interface agent.\n\nExecutes the Interface agent to design and generate API interfaces. This\nagent creates OpenAPI schemas and TypeScript/NestJS code based on the\nrequirements specification and ERD documentation from previous agents.\n\nThe agent follows a sophisticated pipeline: first constructing formal\nOpenAPI Operation Schemas and JSON Schemas, then validating these schemas,\nand finally transforming them into NestJS controllers and DTOs. Each\ngenerated interface includes comprehensive JSDoc comments and undergoes\ninternal review for consistency.",
         validate: (() => {
-            const _io0 = input => "string" === typeof input.reason && (undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements);
+            const _io0 = input => "string" === typeof input.reason;
             const _vo0 = (input, _path, _exceptionable = true) => [ "string" === typeof input.reason || _report(_exceptionable, {
                 path: _path + ".reason",
                 expected: "string",
                 value: input.reason
-            }), undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements || _report(_exceptionable, {
-                path: _path + ".userPlanningRequirements",
-                expected: "(string | undefined)",
-                value: input.userPlanningRequirements
             }) ].every((flag => flag));
             const __is = input => "object" === typeof input && null !== input && _io0(input);
             let errors;
@@ -11196,10 +11291,6 @@ const claude = {
                     title: "The reason of the function call",
                     description: "The reason of the function call.",
                     type: "string"
-                },
-                userPlanningRequirements: {
-                    description: "# Define prompts to translate user planning requirements into messages for internal agents\n\nThis prompt defines how to convert a user's planning-oriented requirements\ninto a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if\nsome parts of the user's input are inappropriate or insufficient from a\nplanning standpoint, you are allowed to add **supplementary remarks**—but\nonly under strict rules.\n\n# Supplementary Remark Rules\n\n1. **Definition** A supplementary remark is additional information that may\n   differ from the user's original intent. Because of this, **you must\n   clearly indicate that it is _not_ part of the user’s thinking**.\n2. **When to Supplement**\n\n- If the user's input reveals a lack of technical understanding (e.g.,\n  suggesting \"put all data into one table\"), and the plan is not an MVP or\n  PoC, it's encouraged to make reasonable additions for a more scalable or\n  robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement\n  the content to ensure completeness.\n\n3. **When Not to Supplement**\n\n- If the user's input is vague or ambiguous, **do not assume or add extra\n  details**. Instead, it’s better to ask the user follow-up questions to\n  clarify their intent.\n- If the user has made no comment on design, **do not impose design-related\n  decisions** (e.g., colors, fonts, tone). However, you may state\n  explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds\n  value, as such goals are assumed in all services.\n\n# Style Guidelines\n\nThis prompt is delivered to the sub-agent, and several are created for\nparallel processing of the sub-agent. Additionally, there should be a guide\nto style, since sub-agents cannot create different styles of documents due\nto the disconnection of their conversations with each other.\n\nFor example, there should be a hyperlink to the previous document, the next\ndocument, before or after the document, or there should be no more than N\nheadings. The entire content of the document will have requirements, such\nas maintaining informal or formal language.\n\nThe style guide should include conventions for Markdown formatting elements\nsuch as headings, lists, and tables. Additionally, it should define\nexpectations regarding document length and overall composition. When\ndescribing structural guidelines, include a template to illustrate the\nrecommended format.\n\n# Limiting the volume of a document\n\nHowever, do not go beyond the volume guide; each agent only needs to create\none page because the agent receiving this document will be created as many\nas the number of pages.",
-                    type: "string"
                 }
             },
             required: [ "reason" ],
@@ -11231,15 +11322,11 @@ const claude = {
         },
         description: "Run test program agent.\n\nExecutes the Test agent to generate comprehensive E2E test suites for all\n{@link interface API interfaces}. This agent synthesizes outputs from\nprevious agents to create tests that validate both individual endpoints and\ntheir interactions.\n\n**PREREQUISITE**: Only call this function after the {@link interface}\nfunction has been successfully executed and API interfaces have been\ngenerated. The Test agent requires the completed API interface definitions,\nOpenAPI schemas, and TypeScript code to generate appropriate test\nscenarios. Without completed interface design, this function should NOT be\ncalled.\n\nThe agent will analyze dependency relationships between API functions,\nstructure integrated test scenarios with correct execution sequences, and\nenhance pre-generated test scaffolds with business logic validation.\nTypeScript compiler validation and internal review ensure test quality and\noptimal coverage.",
         validate: (() => {
-            const _io0 = input => "string" === typeof input.reason && (undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements);
+            const _io0 = input => "string" === typeof input.reason;
             const _vo0 = (input, _path, _exceptionable = true) => [ "string" === typeof input.reason || _report(_exceptionable, {
                 path: _path + ".reason",
                 expected: "string",
                 value: input.reason
-            }), undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements || _report(_exceptionable, {
-                path: _path + ".userPlanningRequirements",
-                expected: "(string | undefined)",
-                value: input.userPlanningRequirements
             }) ].every((flag => flag));
             const __is = input => "object" === typeof input && null !== input && _io0(input);
             let errors;
@@ -11283,10 +11370,6 @@ const claude = {
                     title: "The reason of the function call",
                     description: "The reason of the function call.",
                     type: "string"
-                },
-                userPlanningRequirements: {
-                    description: "# Define prompts to translate user planning requirements into messages for internal agents\n\nThis prompt defines how to convert a user's planning-oriented requirements\ninto a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if\nsome parts of the user's input are inappropriate or insufficient from a\nplanning standpoint, you are allowed to add **supplementary remarks**—but\nonly under strict rules.\n\n# Supplementary Remark Rules\n\n1. **Definition** A supplementary remark is additional information that may\n   differ from the user's original intent. Because of this, **you must\n   clearly indicate that it is _not_ part of the user’s thinking**.\n2. **When to Supplement**\n\n- If the user's input reveals a lack of technical understanding (e.g.,\n  suggesting \"put all data into one table\"), and the plan is not an MVP or\n  PoC, it's encouraged to make reasonable additions for a more scalable or\n  robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement\n  the content to ensure completeness.\n\n3. **When Not to Supplement**\n\n- If the user's input is vague or ambiguous, **do not assume or add extra\n  details**. Instead, it’s better to ask the user follow-up questions to\n  clarify their intent.\n- If the user has made no comment on design, **do not impose design-related\n  decisions** (e.g., colors, fonts, tone). However, you may state\n  explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds\n  value, as such goals are assumed in all services.\n\n# Style Guidelines\n\nThis prompt is delivered to the sub-agent, and several are created for\nparallel processing of the sub-agent. Additionally, there should be a guide\nto style, since sub-agents cannot create different styles of documents due\nto the disconnection of their conversations with each other.\n\nFor example, there should be a hyperlink to the previous document, the next\ndocument, before or after the document, or there should be no more than N\nheadings. The entire content of the document will have requirements, such\nas maintaining informal or formal language.\n\nThe style guide should include conventions for Markdown formatting elements\nsuch as headings, lists, and tables. Additionally, it should define\nexpectations regarding document length and overall composition. When\ndescribing structural guidelines, include a template to illustrate the\nrecommended format.\n\n# Limiting the volume of a document\n\nHowever, do not go beyond the volume guide; each agent only needs to create\none page because the agent receiving this document will be created as many\nas the number of pages.",
-                    type: "string"
                 }
             },
             required: [ "reason" ],
@@ -11318,15 +11401,11 @@ const claude = {
         },
         description: "Run realize agent.\n\nExecutes the Realize agent to implement the actual business logic for each\nAPI endpoint. This agent synthesizes all outputs from previous agents to\ngenerate fully functional service provider code.\n\n**PREREQUISITE**: Only call this function after the {@link interface}\nfunction has been successfully executed and API interfaces have been\ngenerated. The Realize agent requires the completed API interface\ndefinitions to implement the corresponding service logic. It also benefits\nfrom having test code available for validation. Without completed interface\ndesign, this function should NOT be called.\n\nThe agent will create service implementations with multiple validation\nlayers: TypeScript compiler feedback, runtime validation through test\nexecution, and quality optimization through internal review. The generated\ncode handles database interactions through Prisma, implements security and\nvalidation checks, and processes business rules according to\nspecifications.",
         validate: (() => {
-            const _io0 = input => "string" === typeof input.reason && (undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements);
+            const _io0 = input => "string" === typeof input.reason;
             const _vo0 = (input, _path, _exceptionable = true) => [ "string" === typeof input.reason || _report(_exceptionable, {
                 path: _path + ".reason",
                 expected: "string",
                 value: input.reason
-            }), undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements || _report(_exceptionable, {
-                path: _path + ".userPlanningRequirements",
-                expected: "(string | undefined)",
-                value: input.userPlanningRequirements
             }) ].every((flag => flag));
             const __is = input => "object" === typeof input && null !== input && _io0(input);
             let errors;
@@ -11381,10 +11460,6 @@ const collection = {
                         title: "The reason of the function call",
                         description: "The reason of the function call.",
                         type: "string"
-                    },
-                    userPlanningRequirements: {
-                        description: "# Define prompts to translate user planning requirements into messages for internal agents\n\nThis prompt defines how to convert a user's planning-oriented requirements\ninto a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if\nsome parts of the user's input are inappropriate or insufficient from a\nplanning standpoint, you are allowed to add **supplementary remarks**—but\nonly under strict rules.\n\n# Supplementary Remark Rules\n\n1. **Definition** A supplementary remark is additional information that may\n   differ from the user's original intent. Because of this, **you must\n   clearly indicate that it is _not_ part of the user’s thinking**.\n2. **When to Supplement**\n\n- If the user's input reveals a lack of technical understanding (e.g.,\n  suggesting \"put all data into one table\"), and the plan is not an MVP or\n  PoC, it's encouraged to make reasonable additions for a more scalable or\n  robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement\n  the content to ensure completeness.\n\n3. **When Not to Supplement**\n\n- If the user's input is vague or ambiguous, **do not assume or add extra\n  details**. Instead, it’s better to ask the user follow-up questions to\n  clarify their intent.\n- If the user has made no comment on design, **do not impose design-related\n  decisions** (e.g., colors, fonts, tone). However, you may state\n  explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds\n  value, as such goals are assumed in all services.\n\n# Style Guidelines\n\nThis prompt is delivered to the sub-agent, and several are created for\nparallel processing of the sub-agent. Additionally, there should be a guide\nto style, since sub-agents cannot create different styles of documents due\nto the disconnection of their conversations with each other.\n\nFor example, there should be a hyperlink to the previous document, the next\ndocument, before or after the document, or there should be no more than N\nheadings. The entire content of the document will have requirements, such\nas maintaining informal or formal language.\n\nThe style guide should include conventions for Markdown formatting elements\nsuch as headings, lists, and tables. Additionally, it should define\nexpectations regarding document length and overall composition. When\ndescribing structural guidelines, include a template to illustrate the\nrecommended format.\n\n# Limiting the volume of a document\n\nHowever, do not go beyond the volume guide; each agent only needs to create\none page because the agent receiving this document will be created as many\nas the number of pages.",
-                        type: "string"
                     }
                 },
                 required: [ "reason" ],
@@ -11407,15 +11482,11 @@ const collection = {
             },
             description: "Run Analyze Agent.\n\nExecutes the Analyze agent to process user requirements and generate a\nstructured specification document. This agent analyzes all conversation\nhistory between users and AI, separates business logic from technical\nrequirements, and establishes development priorities and scope.\n\n**IMPORTANT**: Only call this function when sufficient requirements have\nbeen discussed to generate a comprehensive specification. The context must\ncontain enough detail about the system's purpose, core features, data\nmodels, and business rules. If requirements are unclear or incomplete,\ncontinue gathering information through conversation instead.\n\nThe agent will automatically generate follow-up questions for any ambiguous\nrequirements and continuously refine its understanding through iterative\nconversation. When executed after other agents have generated code, it can\nalso interpret change requests in the context of existing implementations.",
             validate: (() => {
-                const _io0 = input => "string" === typeof input.reason && (undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements);
+                const _io0 = input => "string" === typeof input.reason;
                 const _vo0 = (input, _path, _exceptionable = true) => [ "string" === typeof input.reason || _report(_exceptionable, {
                     path: _path + ".reason",
                     expected: "string",
                     value: input.reason
-                }), undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements || _report(_exceptionable, {
-                    path: _path + ".userPlanningRequirements",
-                    expected: "(string | undefined)",
-                    value: input.userPlanningRequirements
                 }) ].every((flag => flag));
                 const __is = input => "object" === typeof input && null !== input && _io0(input);
                 let errors;
@@ -11459,10 +11530,6 @@ const collection = {
                         title: "The reason of the function call",
                         description: "The reason of the function call.",
                         type: "string"
-                    },
-                    userPlanningRequirements: {
-                        description: "# Define prompts to translate user planning requirements into messages for internal agents\n\nThis prompt defines how to convert a user's planning-oriented requirements\ninto a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if\nsome parts of the user's input are inappropriate or insufficient from a\nplanning standpoint, you are allowed to add **supplementary remarks**—but\nonly under strict rules.\n\n# Supplementary Remark Rules\n\n1. **Definition** A supplementary remark is additional information that may\n   differ from the user's original intent. Because of this, **you must\n   clearly indicate that it is _not_ part of the user’s thinking**.\n2. **When to Supplement**\n\n- If the user's input reveals a lack of technical understanding (e.g.,\n  suggesting \"put all data into one table\"), and the plan is not an MVP or\n  PoC, it's encouraged to make reasonable additions for a more scalable or\n  robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement\n  the content to ensure completeness.\n\n3. **When Not to Supplement**\n\n- If the user's input is vague or ambiguous, **do not assume or add extra\n  details**. Instead, it’s better to ask the user follow-up questions to\n  clarify their intent.\n- If the user has made no comment on design, **do not impose design-related\n  decisions** (e.g., colors, fonts, tone). However, you may state\n  explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds\n  value, as such goals are assumed in all services.\n\n# Style Guidelines\n\nThis prompt is delivered to the sub-agent, and several are created for\nparallel processing of the sub-agent. Additionally, there should be a guide\nto style, since sub-agents cannot create different styles of documents due\nto the disconnection of their conversations with each other.\n\nFor example, there should be a hyperlink to the previous document, the next\ndocument, before or after the document, or there should be no more than N\nheadings. The entire content of the document will have requirements, such\nas maintaining informal or formal language.\n\nThe style guide should include conventions for Markdown formatting elements\nsuch as headings, lists, and tables. Additionally, it should define\nexpectations regarding document length and overall composition. When\ndescribing structural guidelines, include a template to illustrate the\nrecommended format.\n\n# Limiting the volume of a document\n\nHowever, do not go beyond the volume guide; each agent only needs to create\none page because the agent receiving this document will be created as many\nas the number of pages.",
-                        type: "string"
                     }
                 },
                 required: [ "reason" ],
@@ -11485,15 +11552,11 @@ const collection = {
             },
             description: "Run prisma agent.\n\nExecutes the Prisma agent to generate database schema files and ERD\ndocumentation. This agent reads the requirements specification created by\nthe {@link analyze Analyze agent} and produces a complete Prisma schema with\ncomprehensive documentation for each entity and attribute.\n\n**PREREQUISITE**: Only call this function after the {@link analyze} function\nhas been successfully executed and a requirements specification document\nhas been generated. The Prisma agent depends on the structured requirements\nanalysis to design the database schema properly. Without a completed\nrequirements specification, this function should NOT be called.\n\nThe agent will automatically validate the generated schema using the Prisma\ncompiler, self-correct any compilation errors through feedback loops, and\ngenerate ERD documentation using prisma-markdown. An internal review\nprocess ensures schema quality and optimization.",
             validate: (() => {
-                const _io0 = input => "string" === typeof input.reason && (undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements);
+                const _io0 = input => "string" === typeof input.reason;
                 const _vo0 = (input, _path, _exceptionable = true) => [ "string" === typeof input.reason || _report(_exceptionable, {
                     path: _path + ".reason",
                     expected: "string",
                     value: input.reason
-                }), undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements || _report(_exceptionable, {
-                    path: _path + ".userPlanningRequirements",
-                    expected: "(string | undefined)",
-                    value: input.userPlanningRequirements
                 }) ].every((flag => flag));
                 const __is = input => "object" === typeof input && null !== input && _io0(input);
                 let errors;
@@ -11537,10 +11600,6 @@ const collection = {
                         title: "The reason of the function call",
                         description: "The reason of the function call.",
                         type: "string"
-                    },
-                    userPlanningRequirements: {
-                        description: "# Define prompts to translate user planning requirements into messages for internal agents\n\nThis prompt defines how to convert a user's planning-oriented requirements\ninto a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if\nsome parts of the user's input are inappropriate or insufficient from a\nplanning standpoint, you are allowed to add **supplementary remarks**—but\nonly under strict rules.\n\n# Supplementary Remark Rules\n\n1. **Definition** A supplementary remark is additional information that may\n   differ from the user's original intent. Because of this, **you must\n   clearly indicate that it is _not_ part of the user’s thinking**.\n2. **When to Supplement**\n\n- If the user's input reveals a lack of technical understanding (e.g.,\n  suggesting \"put all data into one table\"), and the plan is not an MVP or\n  PoC, it's encouraged to make reasonable additions for a more scalable or\n  robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement\n  the content to ensure completeness.\n\n3. **When Not to Supplement**\n\n- If the user's input is vague or ambiguous, **do not assume or add extra\n  details**. Instead, it’s better to ask the user follow-up questions to\n  clarify their intent.\n- If the user has made no comment on design, **do not impose design-related\n  decisions** (e.g., colors, fonts, tone). However, you may state\n  explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds\n  value, as such goals are assumed in all services.\n\n# Style Guidelines\n\nThis prompt is delivered to the sub-agent, and several are created for\nparallel processing of the sub-agent. Additionally, there should be a guide\nto style, since sub-agents cannot create different styles of documents due\nto the disconnection of their conversations with each other.\n\nFor example, there should be a hyperlink to the previous document, the next\ndocument, before or after the document, or there should be no more than N\nheadings. The entire content of the document will have requirements, such\nas maintaining informal or formal language.\n\nThe style guide should include conventions for Markdown formatting elements\nsuch as headings, lists, and tables. Additionally, it should define\nexpectations regarding document length and overall composition. When\ndescribing structural guidelines, include a template to illustrate the\nrecommended format.\n\n# Limiting the volume of a document\n\nHowever, do not go beyond the volume guide; each agent only needs to create\none page because the agent receiving this document will be created as many\nas the number of pages.",
-                        type: "string"
                     }
                 },
                 required: [ "reason" ],
@@ -11563,15 +11622,11 @@ const collection = {
             },
             description: "Run interface agent.\n\nExecutes the Interface agent to design and generate API interfaces. This\nagent creates OpenAPI schemas and TypeScript/NestJS code based on the\nrequirements specification and ERD documentation from previous agents.\n\nThe agent follows a sophisticated pipeline: first constructing formal\nOpenAPI Operation Schemas and JSON Schemas, then validating these schemas,\nand finally transforming them into NestJS controllers and DTOs. Each\ngenerated interface includes comprehensive JSDoc comments and undergoes\ninternal review for consistency.",
             validate: (() => {
-                const _io0 = input => "string" === typeof input.reason && (undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements);
+                const _io0 = input => "string" === typeof input.reason;
                 const _vo0 = (input, _path, _exceptionable = true) => [ "string" === typeof input.reason || _report(_exceptionable, {
                     path: _path + ".reason",
                     expected: "string",
                     value: input.reason
-                }), undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements || _report(_exceptionable, {
-                    path: _path + ".userPlanningRequirements",
-                    expected: "(string | undefined)",
-                    value: input.userPlanningRequirements
                 }) ].every((flag => flag));
                 const __is = input => "object" === typeof input && null !== input && _io0(input);
                 let errors;
@@ -11615,10 +11670,6 @@ const collection = {
                         title: "The reason of the function call",
                         description: "The reason of the function call.",
                         type: "string"
-                    },
-                    userPlanningRequirements: {
-                        description: "# Define prompts to translate user planning requirements into messages for internal agents\n\nThis prompt defines how to convert a user's planning-oriented requirements\ninto a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if\nsome parts of the user's input are inappropriate or insufficient from a\nplanning standpoint, you are allowed to add **supplementary remarks**—but\nonly under strict rules.\n\n# Supplementary Remark Rules\n\n1. **Definition** A supplementary remark is additional information that may\n   differ from the user's original intent. Because of this, **you must\n   clearly indicate that it is _not_ part of the user’s thinking**.\n2. **When to Supplement**\n\n- If the user's input reveals a lack of technical understanding (e.g.,\n  suggesting \"put all data into one table\"), and the plan is not an MVP or\n  PoC, it's encouraged to make reasonable additions for a more scalable or\n  robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement\n  the content to ensure completeness.\n\n3. **When Not to Supplement**\n\n- If the user's input is vague or ambiguous, **do not assume or add extra\n  details**. Instead, it’s better to ask the user follow-up questions to\n  clarify their intent.\n- If the user has made no comment on design, **do not impose design-related\n  decisions** (e.g., colors, fonts, tone). However, you may state\n  explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds\n  value, as such goals are assumed in all services.\n\n# Style Guidelines\n\nThis prompt is delivered to the sub-agent, and several are created for\nparallel processing of the sub-agent. Additionally, there should be a guide\nto style, since sub-agents cannot create different styles of documents due\nto the disconnection of their conversations with each other.\n\nFor example, there should be a hyperlink to the previous document, the next\ndocument, before or after the document, or there should be no more than N\nheadings. The entire content of the document will have requirements, such\nas maintaining informal or formal language.\n\nThe style guide should include conventions for Markdown formatting elements\nsuch as headings, lists, and tables. Additionally, it should define\nexpectations regarding document length and overall composition. When\ndescribing structural guidelines, include a template to illustrate the\nrecommended format.\n\n# Limiting the volume of a document\n\nHowever, do not go beyond the volume guide; each agent only needs to create\none page because the agent receiving this document will be created as many\nas the number of pages.",
-                        type: "string"
                     }
                 },
                 required: [ "reason" ],
@@ -11641,15 +11692,11 @@ const collection = {
             },
             description: "Run test program agent.\n\nExecutes the Test agent to generate comprehensive E2E test suites for all\n{@link interface API interfaces}. This agent synthesizes outputs from\nprevious agents to create tests that validate both individual endpoints and\ntheir interactions.\n\n**PREREQUISITE**: Only call this function after the {@link interface}\nfunction has been successfully executed and API interfaces have been\ngenerated. The Test agent requires the completed API interface definitions,\nOpenAPI schemas, and TypeScript code to generate appropriate test\nscenarios. Without completed interface design, this function should NOT be\ncalled.\n\nThe agent will analyze dependency relationships between API functions,\nstructure integrated test scenarios with correct execution sequences, and\nenhance pre-generated test scaffolds with business logic validation.\nTypeScript compiler validation and internal review ensure test quality and\noptimal coverage.",
             validate: (() => {
-                const _io0 = input => "string" === typeof input.reason && (undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements);
+                const _io0 = input => "string" === typeof input.reason;
                 const _vo0 = (input, _path, _exceptionable = true) => [ "string" === typeof input.reason || _report(_exceptionable, {
                     path: _path + ".reason",
                     expected: "string",
                     value: input.reason
-                }), undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements || _report(_exceptionable, {
-                    path: _path + ".userPlanningRequirements",
-                    expected: "(string | undefined)",
-                    value: input.userPlanningRequirements
                 }) ].every((flag => flag));
                 const __is = input => "object" === typeof input && null !== input && _io0(input);
                 let errors;
@@ -11693,10 +11740,6 @@ const collection = {
                         title: "The reason of the function call",
                         description: "The reason of the function call.",
                         type: "string"
-                    },
-                    userPlanningRequirements: {
-                        description: "# Define prompts to translate user planning requirements into messages for internal agents\n\nThis prompt defines how to convert a user's planning-oriented requirements\ninto a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if\nsome parts of the user's input are inappropriate or insufficient from a\nplanning standpoint, you are allowed to add **supplementary remarks**—but\nonly under strict rules.\n\n# Supplementary Remark Rules\n\n1. **Definition** A supplementary remark is additional information that may\n   differ from the user's original intent. Because of this, **you must\n   clearly indicate that it is _not_ part of the user’s thinking**.\n2. **When to Supplement**\n\n- If the user's input reveals a lack of technical understanding (e.g.,\n  suggesting \"put all data into one table\"), and the plan is not an MVP or\n  PoC, it's encouraged to make reasonable additions for a more scalable or\n  robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement\n  the content to ensure completeness.\n\n3. **When Not to Supplement**\n\n- If the user's input is vague or ambiguous, **do not assume or add extra\n  details**. Instead, it’s better to ask the user follow-up questions to\n  clarify their intent.\n- If the user has made no comment on design, **do not impose design-related\n  decisions** (e.g., colors, fonts, tone). However, you may state\n  explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds\n  value, as such goals are assumed in all services.\n\n# Style Guidelines\n\nThis prompt is delivered to the sub-agent, and several are created for\nparallel processing of the sub-agent. Additionally, there should be a guide\nto style, since sub-agents cannot create different styles of documents due\nto the disconnection of their conversations with each other.\n\nFor example, there should be a hyperlink to the previous document, the next\ndocument, before or after the document, or there should be no more than N\nheadings. The entire content of the document will have requirements, such\nas maintaining informal or formal language.\n\nThe style guide should include conventions for Markdown formatting elements\nsuch as headings, lists, and tables. Additionally, it should define\nexpectations regarding document length and overall composition. When\ndescribing structural guidelines, include a template to illustrate the\nrecommended format.\n\n# Limiting the volume of a document\n\nHowever, do not go beyond the volume guide; each agent only needs to create\none page because the agent receiving this document will be created as many\nas the number of pages.",
-                        type: "string"
                     }
                 },
                 required: [ "reason" ],
@@ -11719,15 +11762,11 @@ const collection = {
             },
             description: "Run realize agent.\n\nExecutes the Realize agent to implement the actual business logic for each\nAPI endpoint. This agent synthesizes all outputs from previous agents to\ngenerate fully functional service provider code.\n\n**PREREQUISITE**: Only call this function after the {@link interface}\nfunction has been successfully executed and API interfaces have been\ngenerated. The Realize agent requires the completed API interface\ndefinitions to implement the corresponding service logic. It also benefits\nfrom having test code available for validation. Without completed interface\ndesign, this function should NOT be called.\n\nThe agent will create service implementations with multiple validation\nlayers: TypeScript compiler feedback, runtime validation through test\nexecution, and quality optimization through internal review. The generated\ncode handles database interactions through Prisma, implements security and\nvalidation checks, and processes business rules according to\nspecifications.",
             validate: (() => {
-                const _io0 = input => "string" === typeof input.reason && (undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements);
+                const _io0 = input => "string" === typeof input.reason;
                 const _vo0 = (input, _path, _exceptionable = true) => [ "string" === typeof input.reason || _report(_exceptionable, {
                     path: _path + ".reason",
                     expected: "string",
                     value: input.reason
-                }), undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements || _report(_exceptionable, {
-                    path: _path + ".userPlanningRequirements",
-                    expected: "(string | undefined)",
-                    value: input.userPlanningRequirements
                 }) ].every((flag => flag));
                 const __is = input => "object" === typeof input && null !== input && _io0(input);
                 let errors;
@@ -11783,10 +11822,6 @@ const collection = {
                         type: "string",
                         title: "The reason of the function call",
                         description: "The reason of the function call."
-                    },
-                    userPlanningRequirements: {
-                        type: "string",
-                        description: "# Define prompts to translate user planning requirements into messages for internal agents\n\nThis prompt defines how to convert a user's planning-oriented requirements\ninto a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if\nsome parts of the user's input are inappropriate or insufficient from a\nplanning standpoint, you are allowed to add **supplementary remarks**—but\nonly under strict rules.\n\n# Supplementary Remark Rules\n\n1. **Definition** A supplementary remark is additional information that may\n   differ from the user's original intent. Because of this, **you must\n   clearly indicate that it is _not_ part of the user’s thinking**.\n2. **When to Supplement**\n\n- If the user's input reveals a lack of technical understanding (e.g.,\n  suggesting \"put all data into one table\"), and the plan is not an MVP or\n  PoC, it's encouraged to make reasonable additions for a more scalable or\n  robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement\n  the content to ensure completeness.\n\n3. **When Not to Supplement**\n\n- If the user's input is vague or ambiguous, **do not assume or add extra\n  details**. Instead, it’s better to ask the user follow-up questions to\n  clarify their intent.\n- If the user has made no comment on design, **do not impose design-related\n  decisions** (e.g., colors, fonts, tone). However, you may state\n  explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds\n  value, as such goals are assumed in all services.\n\n# Style Guidelines\n\nThis prompt is delivered to the sub-agent, and several are created for\nparallel processing of the sub-agent. Additionally, there should be a guide\nto style, since sub-agents cannot create different styles of documents due\nto the disconnection of their conversations with each other.\n\nFor example, there should be a hyperlink to the previous document, the next\ndocument, before or after the document, or there should be no more than N\nheadings. The entire content of the document will have requirements, such\nas maintaining informal or formal language.\n\nThe style guide should include conventions for Markdown formatting elements\nsuch as headings, lists, and tables. Additionally, it should define\nexpectations regarding document length and overall composition. When\ndescribing structural guidelines, include a template to illustrate the\nrecommended format.\n\n# Limiting the volume of a document\n\nHowever, do not go beyond the volume guide; each agent only needs to create\none page because the agent receiving this document will be created as many\nas the number of pages."
                     }
                 },
                 required: [ "reason" ],
@@ -11810,15 +11845,11 @@ const collection = {
             },
             description: "Run Analyze Agent.\n\nExecutes the Analyze agent to process user requirements and generate a\nstructured specification document. This agent analyzes all conversation\nhistory between users and AI, separates business logic from technical\nrequirements, and establishes development priorities and scope.\n\n**IMPORTANT**: Only call this function when sufficient requirements have\nbeen discussed to generate a comprehensive specification. The context must\ncontain enough detail about the system's purpose, core features, data\nmodels, and business rules. If requirements are unclear or incomplete,\ncontinue gathering information through conversation instead.\n\nThe agent will automatically generate follow-up questions for any ambiguous\nrequirements and continuously refine its understanding through iterative\nconversation. When executed after other agents have generated code, it can\nalso interpret change requests in the context of existing implementations.",
             validate: (() => {
-                const _io0 = input => "string" === typeof input.reason && (undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements);
+                const _io0 = input => "string" === typeof input.reason;
                 const _vo0 = (input, _path, _exceptionable = true) => [ "string" === typeof input.reason || _report(_exceptionable, {
                     path: _path + ".reason",
                     expected: "string",
                     value: input.reason
-                }), undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements || _report(_exceptionable, {
-                    path: _path + ".userPlanningRequirements",
-                    expected: "(string | undefined)",
-                    value: input.userPlanningRequirements
                 }) ].every((flag => flag));
                 const __is = input => "object" === typeof input && null !== input && _io0(input);
                 let errors;
@@ -11861,10 +11892,6 @@ const collection = {
                         type: "string",
                         title: "The reason of the function call",
                         description: "The reason of the function call."
-                    },
-                    userPlanningRequirements: {
-                        type: "string",
-                        description: "# Define prompts to translate user planning requirements into messages for internal agents\n\nThis prompt defines how to convert a user's planning-oriented requirements\ninto a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if\nsome parts of the user's input are inappropriate or insufficient from a\nplanning standpoint, you are allowed to add **supplementary remarks**—but\nonly under strict rules.\n\n# Supplementary Remark Rules\n\n1. **Definition** A supplementary remark is additional information that may\n   differ from the user's original intent. Because of this, **you must\n   clearly indicate that it is _not_ part of the user’s thinking**.\n2. **When to Supplement**\n\n- If the user's input reveals a lack of technical understanding (e.g.,\n  suggesting \"put all data into one table\"), and the plan is not an MVP or\n  PoC, it's encouraged to make reasonable additions for a more scalable or\n  robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement\n  the content to ensure completeness.\n\n3. **When Not to Supplement**\n\n- If the user's input is vague or ambiguous, **do not assume or add extra\n  details**. Instead, it’s better to ask the user follow-up questions to\n  clarify their intent.\n- If the user has made no comment on design, **do not impose design-related\n  decisions** (e.g., colors, fonts, tone). However, you may state\n  explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds\n  value, as such goals are assumed in all services.\n\n# Style Guidelines\n\nThis prompt is delivered to the sub-agent, and several are created for\nparallel processing of the sub-agent. Additionally, there should be a guide\nto style, since sub-agents cannot create different styles of documents due\nto the disconnection of their conversations with each other.\n\nFor example, there should be a hyperlink to the previous document, the next\ndocument, before or after the document, or there should be no more than N\nheadings. The entire content of the document will have requirements, such\nas maintaining informal or formal language.\n\nThe style guide should include conventions for Markdown formatting elements\nsuch as headings, lists, and tables. Additionally, it should define\nexpectations regarding document length and overall composition. When\ndescribing structural guidelines, include a template to illustrate the\nrecommended format.\n\n# Limiting the volume of a document\n\nHowever, do not go beyond the volume guide; each agent only needs to create\none page because the agent receiving this document will be created as many\nas the number of pages."
                     }
                 },
                 required: [ "reason" ],
@@ -11888,15 +11915,11 @@ const collection = {
             },
             description: "Run prisma agent.\n\nExecutes the Prisma agent to generate database schema files and ERD\ndocumentation. This agent reads the requirements specification created by\nthe {@link analyze Analyze agent} and produces a complete Prisma schema with\ncomprehensive documentation for each entity and attribute.\n\n**PREREQUISITE**: Only call this function after the {@link analyze} function\nhas been successfully executed and a requirements specification document\nhas been generated. The Prisma agent depends on the structured requirements\nanalysis to design the database schema properly. Without a completed\nrequirements specification, this function should NOT be called.\n\nThe agent will automatically validate the generated schema using the Prisma\ncompiler, self-correct any compilation errors through feedback loops, and\ngenerate ERD documentation using prisma-markdown. An internal review\nprocess ensures schema quality and optimization.",
             validate: (() => {
-                const _io0 = input => "string" === typeof input.reason && (undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements);
+                const _io0 = input => "string" === typeof input.reason;
                 const _vo0 = (input, _path, _exceptionable = true) => [ "string" === typeof input.reason || _report(_exceptionable, {
                     path: _path + ".reason",
                     expected: "string",
                     value: input.reason
-                }), undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements || _report(_exceptionable, {
-                    path: _path + ".userPlanningRequirements",
-                    expected: "(string | undefined)",
-                    value: input.userPlanningRequirements
                 }) ].every((flag => flag));
                 const __is = input => "object" === typeof input && null !== input && _io0(input);
                 let errors;
@@ -11939,10 +11962,6 @@ const collection = {
                         type: "string",
                         title: "The reason of the function call",
                         description: "The reason of the function call."
-                    },
-                    userPlanningRequirements: {
-                        type: "string",
-                        description: "# Define prompts to translate user planning requirements into messages for internal agents\n\nThis prompt defines how to convert a user's planning-oriented requirements\ninto a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if\nsome parts of the user's input are inappropriate or insufficient from a\nplanning standpoint, you are allowed to add **supplementary remarks**—but\nonly under strict rules.\n\n# Supplementary Remark Rules\n\n1. **Definition** A supplementary remark is additional information that may\n   differ from the user's original intent. Because of this, **you must\n   clearly indicate that it is _not_ part of the user’s thinking**.\n2. **When to Supplement**\n\n- If the user's input reveals a lack of technical understanding (e.g.,\n  suggesting \"put all data into one table\"), and the plan is not an MVP or\n  PoC, it's encouraged to make reasonable additions for a more scalable or\n  robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement\n  the content to ensure completeness.\n\n3. **When Not to Supplement**\n\n- If the user's input is vague or ambiguous, **do not assume or add extra\n  details**. Instead, it’s better to ask the user follow-up questions to\n  clarify their intent.\n- If the user has made no comment on design, **do not impose design-related\n  decisions** (e.g., colors, fonts, tone). However, you may state\n  explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds\n  value, as such goals are assumed in all services.\n\n# Style Guidelines\n\nThis prompt is delivered to the sub-agent, and several are created for\nparallel processing of the sub-agent. Additionally, there should be a guide\nto style, since sub-agents cannot create different styles of documents due\nto the disconnection of their conversations with each other.\n\nFor example, there should be a hyperlink to the previous document, the next\ndocument, before or after the document, or there should be no more than N\nheadings. The entire content of the document will have requirements, such\nas maintaining informal or formal language.\n\nThe style guide should include conventions for Markdown formatting elements\nsuch as headings, lists, and tables. Additionally, it should define\nexpectations regarding document length and overall composition. When\ndescribing structural guidelines, include a template to illustrate the\nrecommended format.\n\n# Limiting the volume of a document\n\nHowever, do not go beyond the volume guide; each agent only needs to create\none page because the agent receiving this document will be created as many\nas the number of pages."
                     }
                 },
                 required: [ "reason" ],
@@ -11966,15 +11985,11 @@ const collection = {
             },
             description: "Run interface agent.\n\nExecutes the Interface agent to design and generate API interfaces. This\nagent creates OpenAPI schemas and TypeScript/NestJS code based on the\nrequirements specification and ERD documentation from previous agents.\n\nThe agent follows a sophisticated pipeline: first constructing formal\nOpenAPI Operation Schemas and JSON Schemas, then validating these schemas,\nand finally transforming them into NestJS controllers and DTOs. Each\ngenerated interface includes comprehensive JSDoc comments and undergoes\ninternal review for consistency.",
             validate: (() => {
-                const _io0 = input => "string" === typeof input.reason && (undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements);
+                const _io0 = input => "string" === typeof input.reason;
                 const _vo0 = (input, _path, _exceptionable = true) => [ "string" === typeof input.reason || _report(_exceptionable, {
                     path: _path + ".reason",
                     expected: "string",
                     value: input.reason
-                }), undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements || _report(_exceptionable, {
-                    path: _path + ".userPlanningRequirements",
-                    expected: "(string | undefined)",
-                    value: input.userPlanningRequirements
                 }) ].every((flag => flag));
                 const __is = input => "object" === typeof input && null !== input && _io0(input);
                 let errors;
@@ -12017,10 +12032,6 @@ const collection = {
                         type: "string",
                         title: "The reason of the function call",
                         description: "The reason of the function call."
-                    },
-                    userPlanningRequirements: {
-                        type: "string",
-                        description: "# Define prompts to translate user planning requirements into messages for internal agents\n\nThis prompt defines how to convert a user's planning-oriented requirements\ninto a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if\nsome parts of the user's input are inappropriate or insufficient from a\nplanning standpoint, you are allowed to add **supplementary remarks**—but\nonly under strict rules.\n\n# Supplementary Remark Rules\n\n1. **Definition** A supplementary remark is additional information that may\n   differ from the user's original intent. Because of this, **you must\n   clearly indicate that it is _not_ part of the user’s thinking**.\n2. **When to Supplement**\n\n- If the user's input reveals a lack of technical understanding (e.g.,\n  suggesting \"put all data into one table\"), and the plan is not an MVP or\n  PoC, it's encouraged to make reasonable additions for a more scalable or\n  robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement\n  the content to ensure completeness.\n\n3. **When Not to Supplement**\n\n- If the user's input is vague or ambiguous, **do not assume or add extra\n  details**. Instead, it’s better to ask the user follow-up questions to\n  clarify their intent.\n- If the user has made no comment on design, **do not impose design-related\n  decisions** (e.g., colors, fonts, tone). However, you may state\n  explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds\n  value, as such goals are assumed in all services.\n\n# Style Guidelines\n\nThis prompt is delivered to the sub-agent, and several are created for\nparallel processing of the sub-agent. Additionally, there should be a guide\nto style, since sub-agents cannot create different styles of documents due\nto the disconnection of their conversations with each other.\n\nFor example, there should be a hyperlink to the previous document, the next\ndocument, before or after the document, or there should be no more than N\nheadings. The entire content of the document will have requirements, such\nas maintaining informal or formal language.\n\nThe style guide should include conventions for Markdown formatting elements\nsuch as headings, lists, and tables. Additionally, it should define\nexpectations regarding document length and overall composition. When\ndescribing structural guidelines, include a template to illustrate the\nrecommended format.\n\n# Limiting the volume of a document\n\nHowever, do not go beyond the volume guide; each agent only needs to create\none page because the agent receiving this document will be created as many\nas the number of pages."
                     }
                 },
                 required: [ "reason" ],
@@ -12044,15 +12055,11 @@ const collection = {
             },
             description: "Run test program agent.\n\nExecutes the Test agent to generate comprehensive E2E test suites for all\n{@link interface API interfaces}. This agent synthesizes outputs from\nprevious agents to create tests that validate both individual endpoints and\ntheir interactions.\n\n**PREREQUISITE**: Only call this function after the {@link interface}\nfunction has been successfully executed and API interfaces have been\ngenerated. The Test agent requires the completed API interface definitions,\nOpenAPI schemas, and TypeScript code to generate appropriate test\nscenarios. Without completed interface design, this function should NOT be\ncalled.\n\nThe agent will analyze dependency relationships between API functions,\nstructure integrated test scenarios with correct execution sequences, and\nenhance pre-generated test scaffolds with business logic validation.\nTypeScript compiler validation and internal review ensure test quality and\noptimal coverage.",
             validate: (() => {
-                const _io0 = input => "string" === typeof input.reason && (undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements);
+                const _io0 = input => "string" === typeof input.reason;
                 const _vo0 = (input, _path, _exceptionable = true) => [ "string" === typeof input.reason || _report(_exceptionable, {
                     path: _path + ".reason",
                     expected: "string",
                     value: input.reason
-                }), undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements || _report(_exceptionable, {
-                    path: _path + ".userPlanningRequirements",
-                    expected: "(string | undefined)",
-                    value: input.userPlanningRequirements
                 }) ].every((flag => flag));
                 const __is = input => "object" === typeof input && null !== input && _io0(input);
                 let errors;
@@ -12095,10 +12102,6 @@ const collection = {
                         type: "string",
                         title: "The reason of the function call",
                         description: "The reason of the function call."
-                    },
-                    userPlanningRequirements: {
-                        type: "string",
-                        description: "# Define prompts to translate user planning requirements into messages for internal agents\n\nThis prompt defines how to convert a user's planning-oriented requirements\ninto a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if\nsome parts of the user's input are inappropriate or insufficient from a\nplanning standpoint, you are allowed to add **supplementary remarks**—but\nonly under strict rules.\n\n# Supplementary Remark Rules\n\n1. **Definition** A supplementary remark is additional information that may\n   differ from the user's original intent. Because of this, **you must\n   clearly indicate that it is _not_ part of the user’s thinking**.\n2. **When to Supplement**\n\n- If the user's input reveals a lack of technical understanding (e.g.,\n  suggesting \"put all data into one table\"), and the plan is not an MVP or\n  PoC, it's encouraged to make reasonable additions for a more scalable or\n  robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement\n  the content to ensure completeness.\n\n3. **When Not to Supplement**\n\n- If the user's input is vague or ambiguous, **do not assume or add extra\n  details**. Instead, it’s better to ask the user follow-up questions to\n  clarify their intent.\n- If the user has made no comment on design, **do not impose design-related\n  decisions** (e.g., colors, fonts, tone). However, you may state\n  explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds\n  value, as such goals are assumed in all services.\n\n# Style Guidelines\n\nThis prompt is delivered to the sub-agent, and several are created for\nparallel processing of the sub-agent. Additionally, there should be a guide\nto style, since sub-agents cannot create different styles of documents due\nto the disconnection of their conversations with each other.\n\nFor example, there should be a hyperlink to the previous document, the next\ndocument, before or after the document, or there should be no more than N\nheadings. The entire content of the document will have requirements, such\nas maintaining informal or formal language.\n\nThe style guide should include conventions for Markdown formatting elements\nsuch as headings, lists, and tables. Additionally, it should define\nexpectations regarding document length and overall composition. When\ndescribing structural guidelines, include a template to illustrate the\nrecommended format.\n\n# Limiting the volume of a document\n\nHowever, do not go beyond the volume guide; each agent only needs to create\none page because the agent receiving this document will be created as many\nas the number of pages."
                     }
                 },
                 required: [ "reason" ],
@@ -12122,15 +12125,11 @@ const collection = {
             },
             description: "Run realize agent.\n\nExecutes the Realize agent to implement the actual business logic for each\nAPI endpoint. This agent synthesizes all outputs from previous agents to\ngenerate fully functional service provider code.\n\n**PREREQUISITE**: Only call this function after the {@link interface}\nfunction has been successfully executed and API interfaces have been\ngenerated. The Realize agent requires the completed API interface\ndefinitions to implement the corresponding service logic. It also benefits\nfrom having test code available for validation. Without completed interface\ndesign, this function should NOT be called.\n\nThe agent will create service implementations with multiple validation\nlayers: TypeScript compiler feedback, runtime validation through test\nexecution, and quality optimization through internal review. The generated\ncode handles database interactions through Prisma, implements security and\nvalidation checks, and processes business rules according to\nspecifications.",
             validate: (() => {
-                const _io0 = input => "string" === typeof input.reason && (undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements);
+                const _io0 = input => "string" === typeof input.reason;
                 const _vo0 = (input, _path, _exceptionable = true) => [ "string" === typeof input.reason || _report(_exceptionable, {
                     path: _path + ".reason",
                     expected: "string",
                     value: input.reason
-                }), undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements || _report(_exceptionable, {
-                    path: _path + ".userPlanningRequirements",
-                    expected: "(string | undefined)",
-                    value: input.userPlanningRequirements
                 }) ].every((flag => flag));
                 const __is = input => "object" === typeof input && null !== input && _io0(input);
                 let errors;
@@ -12317,7 +12316,7 @@ class AutoBeAgent {
         const files = {
             ...Object.fromEntries(this.state_.analyze ? Object.entries(this.state_.analyze.files).map((([key, value]) => [ `docs/analysis/${key.split("/").at(-1)}`, value ])) : []),
             ...Object.fromEntries(!!this.state_.prisma?.result ? [ ...Object.entries((options?.dbms ?? "postgres") === "postgres" ? this.state_.prisma.schemas : await this.context_.compiler.prisma.write(this.state_.prisma.result.data, options.dbms)).map((([key, value]) => [ `prisma/schema/${key.split("/").at(-1)}`, value ])), ...this.state_.prisma.compiled.type === "success" ? [ [ "docs/ERD.md", this.state_.prisma.compiled.document ] ] : [], ...this.state_.prisma.compiled.type === "failure" ? [ [ "prisma/compile-error-reason.log", this.state_.prisma.compiled.reason ] ] : [], [ "autobe/prisma.json", JSON.stringify(this.state_.prisma.result.data, null, 2) ] ] : []),
-            ...this.state_.interface ? this.state_.interface.files : {},
+            ...this.state_.interface ? this.state_.test ? Object.fromEntries(Object.entries(this.state_.interface.files).filter((([key]) => key.startsWith("test/features/") === false))) : this.state_.interface.files : {},
             ...this.state_.test ? Object.fromEntries(this.state_.test.files.map((f => [ f.location, f.content ]))) : {},
             ...this.state_.realize ? this.state_.realize.files : {},
             "autobe/histories.json": JSON.stringify(this.histories_, null, 2),