@autobe/agent 0.20.0 → 0.21.0

package/lib/agent/src/orchestrate/realize/histories/transformRealizeWriteHistories.js.map

@@ -1 +1 @@
-{"version":3,"file":"transformRealizeWriteHistories.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/realize/histories/transformRealizeWriteHistories.ts"],"names":[],"mappings":";;;AAEA,yCAA2C;AAC3C,+BAA0B;AAM1B,iHAA8G;AAEvG,MAAM,8BAA8B,GAAG,CAC5C,KAAa,EAGb,EAAE;;IACF,MAAM,QAAQ,GAAG,MAAM,CAAC,WAAW,CACjC,KAAK,CAAC,mBAAmB,CAAC,GAAG,CAAC,CAAC,EAAE,EAAE,EAAE,CAAC;QACpC,EAAE,CAAC,OAAO,CAAC,QAAQ;QACnB,EAAE,CAAC,OAAO,CAAC,OAAO;KACnB,CAAC,CACH,CAAC;IAEF,MAAM,CAAC,SAAS,CAAC,GAAG,KAAK,CAAC,SAAS,CAAC,QAAQ,CAAC,UAAU,CAAC;IAExD,MAAM,WAAW,GAAa,EAAE,CAAC;IAEjC,aAAa;IACb,IAAI,KAAK,CAAC,aAAa,IAAI,SAAS,CAAC,iBAAiB,EAAE,CAAC;QACvD,WAAW,CAAC,IAAI,CACd,GAAG,SAAS,CAAC,iBAAiB,KAAK,KAAK,CAAC,aAAa,CAAC,OAAO,CAAC,IAAI,GAAG,CACvE,CAAC;IACJ,CAAC;IAED,gBAAgB;IAChB,SAAS,CAAC,UAAU,CAAC,OAAO,CAAC,CAAC,SAAS,EAAE,EAAE;QACzC,MAAM,MAAM,GACV,QAAQ,IAAI,SAAS,CAAC,MAAM;YAC1B,CAAC,CAAC,mBAAmB,SAAS,CAAC,MAAM,CAAC,MAAM,IAAI;YAChD,CAAC,CAAC,EAAE,CAAC;QACT,WAAW,CAAC,IAAI,CAAC,GAAG,SAAS,CAAC,IAAI,KAAK,SAAS,CAAC,MAAM,CAAC,IAAI,GAAG,MAAM,GAAG,CAAC,CAAC;IAC5E,CAAC,CAAC,CAAC;IAEH,UAAU;IACV,IAAI,MAAA,SAAS,CAAC,WAAW,0CAAE,QAAQ,EAAE,CAAC;QACpC,WAAW,CAAC,IAAI,CAAC,SAAS,SAAS,CAAC,WAAW,CAAC,QAAQ,GAAG,CAAC,CAAC;IAC/D,CAAC;IAED,MAAM,KAAK,GACT,WAAW,CAAC,MAAM,GAAG,CAAC;QACpB,CAAC,CAAC,kBAAU,CAAC,IAAI,CAAA;;UAEb,WAAW,CAAC,GAAG,CAAC,CAAC,KAAK,EAAE,EAAE,CAAC,KAAK,KAAK,GAAG,CAAC,CAAC,IAAI,CAAC,IAAI,CAAC;UACpD;QACJ,CAAC,CAAC,mEAAmE,CAAC;IAE1E,IAAI,KAAK,CAAC,KAAK,CAAC,OAAO,KAAK,IAAI;QAC9B,OAAO;YACL;gBACE,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;gBACpC,IAAI,EAAE,eAAe;gBACrB,IAAI,EAAE;oBACJ,4CAA4C;oBAC5C,mCAAmC;oBACnC,8CAA8C;iBAC/C,CAAC,IAAI,CAAC,GAAG,CAAC;aACZ;SACF,CAAC;SACC,IAAI,KAAK,CAAC,KAAK,CAAC,MAAM,KAAK,IAAI;QAClC,OAAO;YACL;gBACE,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;gBACpC,IAAI,EAAE,eAAe;gBACrB,IAAI,EAAE;oBACJ,mDAAmD;oBACnD,mCAAmC;oBACnC,qDAAqD;iBACtD,CAAC,IAAI,CAAC,GAAG,CAAC;aACZ;SACF,CAAC;SACC,IAAI,KAAK,CAAC,KAAK,CAAC,OAAO,CAAC,IAAI,KAAK,KAAK,CAAC,KAAK,CAAC,MAAM,CAAC,IAAI;QAC3D,OAAO;YACL;gBACE,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;gBACpC,IAAI,EAAE,eAAe;gBACrB,IAAI,EAAE;oBACJ,kDAAkD;oBAClD,sCAAsC;oBACtC,mCAAmC;oBACnC,wDAAwD;iBACzD,CAAC,IAAI,CAAC,GAAG,CAAC;aACZ;SACF,CAAC;SACC,IAAI,KAAK,CAAC,KAAK,CAAC,MAAM,CAAC,QAAQ,CAAC,IAAI,KAAK,SAAS;QACrD,OAAO;YACL;gBACE,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;gBACpC,IAAI,EAAE,eAAe;gBACrB,IAAI,EAAE;oBACJ,kDAAkD;oBAClD,sCAAsC;oBACtC,mCAAmC;oBACnC,wDAAwD;iBACzD,CAAC,IAAI,CAAC,GAAG,CAAC;aACZ;SACF,CAAC;SACC,IAAI,KAAK,CAAC,KAAK,CAAC,SAAS,KAAK,IAAI;QACrC,OAAO;YACL;gBACE,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;gBACpC,IAAI,EAAE,eAAe;gBACrB,IAAI,EAAE;oBACJ,4CAA4C;oBAC5C,mCAAmC;oBACnC,8CAA8C;iBAC/C,CAAC,IAAI,CAAC,GAAG,CAAC;aACZ;SACF,CAAC;IAEJ,mEAAmE;IACnE,MAAM,sBAAsB,GAAG,SAAS,CAAC,iBAAiB;QACxD,CAAC,CAAC,IAAA,2FAA4C,EAAC,SAAS,EAAE,QAAQ,CAAC;QACnE,CAAC,CAAC,EAAE,CAAC;IAEP,OAAO;QACL;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,01pIAAgD;SACrD;QACD,GAAG,sBAAsB;QACzB;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,EAAE,qiIAAkD,UAAU,CAChE,kBAAkB,EAClB,IAAI,CAAC,SAAS,CAAC,KAAK,CAAC,KAAK,CAAC,MAAM,CAAC,OAAO,CAAC,CAC3C;iBACE,UAAU,CAAC,iBAAiB,EAAE,IAAI,CAAC,SAAS,CAAC,KAAK,CAAC,SAAS,CAAC,GAAG,CAAC,CAAC;iBAClE,UAAU,CAAC,iBAAiB,EAAE,IAAI,CAAC,SAAS,CAAC,KAAK,CAAC,SAAS,CAAC,GAAG,CAAC,CAAC;iBAClE,UAAU,CAAC,SAAS,EAAE,KAAK,CAAC;SAChC;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,EAAE,kBAAU,CAAC,IAAI,CAAA;;;;UAIjB,IAAI,CAAC,SAAS,CAAC,KAAK,CAAC,QAAQ,CAAC;;OAEjC;SACF;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,kBAAkB;YACxB,IAAI,EAAE,kBAAU,CAAC,IAAI,CAAA;;;;;;;;;;;;OAYpB;SACF;KACF,CAAC;AACJ,CAAC,CAAC;AAzKW,QAAA,8BAA8B,kCAyKzC"}
+{"version":3,"file":"transformRealizeWriteHistories.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/realize/histories/transformRealizeWriteHistories.ts"],"names":[],"mappings":";;;AAEA,yCAA2C;AAC3C,+BAA0B;AAM1B,iHAA8G;AAEvG,MAAM,8BAA8B,GAAG,CAC5C,KAAa,EAGb,EAAE;;IACF,MAAM,QAAQ,GAAG,MAAM,CAAC,WAAW,CACjC,KAAK,CAAC,mBAAmB,CAAC,GAAG,CAAC,CAAC,EAAE,EAAE,EAAE,CAAC;QACpC,EAAE,CAAC,OAAO,CAAC,QAAQ;QACnB,EAAE,CAAC,OAAO,CAAC,OAAO;KACnB,CAAC,CACH,CAAC;IAEF,MAAM,CAAC,SAAS,CAAC,GAAG,KAAK,CAAC,SAAS,CAAC,QAAQ,CAAC,UAAU,CAAC;IAExD,MAAM,WAAW,GAAa,EAAE,CAAC;IAEjC,aAAa;IACb,IAAI,KAAK,CAAC,aAAa,IAAI,SAAS,CAAC,iBAAiB,EAAE,CAAC;QACvD,WAAW,CAAC,IAAI,CACd,GAAG,SAAS,CAAC,iBAAiB,KAAK,KAAK,CAAC,aAAa,CAAC,OAAO,CAAC,IAAI,GAAG,CACvE,CAAC;IACJ,CAAC;IAED,gBAAgB;IAChB,SAAS,CAAC,UAAU,CAAC,OAAO,CAAC,CAAC,SAAS,EAAE,EAAE;QACzC,MAAM,MAAM,GACV,QAAQ,IAAI,SAAS,CAAC,MAAM;YAC1B,CAAC,CAAC,mBAAmB,SAAS,CAAC,MAAM,CAAC,MAAM,IAAI;YAChD,CAAC,CAAC,EAAE,CAAC;QACT,WAAW,CAAC,IAAI,CAAC,GAAG,SAAS,CAAC,IAAI,KAAK,SAAS,CAAC,MAAM,CAAC,IAAI,GAAG,MAAM,GAAG,CAAC,CAAC;IAC5E,CAAC,CAAC,CAAC;IAEH,UAAU;IACV,IAAI,MAAA,SAAS,CAAC,WAAW,0CAAE,QAAQ,EAAE,CAAC;QACpC,WAAW,CAAC,IAAI,CAAC,SAAS,SAAS,CAAC,WAAW,CAAC,QAAQ,GAAG,CAAC,CAAC;IAC/D,CAAC;IAED,MAAM,KAAK,GACT,WAAW,CAAC,MAAM,GAAG,CAAC;QACpB,CAAC,CAAC,kBAAU,CAAC,IAAI,CAAA;;UAEb,WAAW,CAAC,GAAG,CAAC,CAAC,KAAK,EAAE,EAAE,CAAC,KAAK,KAAK,GAAG,CAAC,CAAC,IAAI,CAAC,IAAI,CAAC;UACpD;QACJ,CAAC,CAAC,mEAAmE,CAAC;IAE1E,IAAI,KAAK,CAAC,KAAK,CAAC,OAAO,KAAK,IAAI;QAC9B,OAAO;YACL;gBACE,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;gBACpC,IAAI,EAAE,eAAe;gBACrB,IAAI,EAAE;oBACJ,4CAA4C;oBAC5C,mCAAmC;oBACnC,8CAA8C;iBAC/C,CAAC,IAAI,CAAC,GAAG,CAAC;aACZ;SACF,CAAC;SACC,IAAI,KAAK,CAAC,KAAK,CAAC,MAAM,KAAK,IAAI;QAClC,OAAO;YACL;gBACE,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;gBACpC,IAAI,EAAE,eAAe;gBACrB,IAAI,EAAE;oBACJ,mDAAmD;oBACnD,mCAAmC;oBACnC,qDAAqD;iBACtD,CAAC,IAAI,CAAC,GAAG,CAAC;aACZ;SACF,CAAC;SACC,IAAI,KAAK,CAAC,KAAK,CAAC,OAAO,CAAC,IAAI,KAAK,KAAK,CAAC,KAAK,CAAC,MAAM,CAAC,IAAI;QAC3D,OAAO;YACL;gBACE,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;gBACpC,IAAI,EAAE,eAAe;gBACrB,IAAI,EAAE;oBACJ,kDAAkD;oBAClD,sCAAsC;oBACtC,mCAAmC;oBACnC,wDAAwD;iBACzD,CAAC,IAAI,CAAC,GAAG,CAAC;aACZ;SACF,CAAC;SACC,IAAI,KAAK,CAAC,KAAK,CAAC,MAAM,CAAC,QAAQ,CAAC,IAAI,KAAK,SAAS;QACrD,OAAO;YACL;gBACE,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;gBACpC,IAAI,EAAE,eAAe;gBACrB,IAAI,EAAE;oBACJ,kDAAkD;oBAClD,sCAAsC;oBACtC,mCAAmC;oBACnC,wDAAwD;iBACzD,CAAC,IAAI,CAAC,GAAG,CAAC;aACZ;SACF,CAAC;SACC,IAAI,KAAK,CAAC,KAAK,CAAC,SAAS,KAAK,IAAI;QACrC,OAAO;YACL;gBACE,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;gBACpC,IAAI,EAAE,eAAe;gBACrB,IAAI,EAAE;oBACJ,4CAA4C;oBAC5C,mCAAmC;oBACnC,8CAA8C;iBAC/C,CAAC,IAAI,CAAC,GAAG,CAAC;aACZ;SACF,CAAC;IAEJ,mEAAmE;IACnE,MAAM,sBAAsB,GAAG,SAAS,CAAC,iBAAiB;QACxD,CAAC,CAAC,IAAA,2FAA4C,EAAC,SAAS,EAAE,QAAQ,CAAC;QACnE,CAAC,CAAC,EAAE,CAAC;IAEP,OAAO;QACL;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,orwIAAgD;SACrD;QACD,GAAG,sBAAsB;QACzB;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,EAAE,qiIAAkD,UAAU,CAChE,kBAAkB,EAClB,IAAI,CAAC,SAAS,CAAC,KAAK,CAAC,KAAK,CAAC,MAAM,CAAC,OAAO,CAAC,CAC3C;iBACE,UAAU,CAAC,iBAAiB,EAAE,IAAI,CAAC,SAAS,CAAC,KAAK,CAAC,SAAS,CAAC,GAAG,CAAC,CAAC;iBAClE,UAAU,CAAC,iBAAiB,EAAE,IAAI,CAAC,SAAS,CAAC,KAAK,CAAC,SAAS,CAAC,GAAG,CAAC,CAAC;iBAClE,UAAU,CAAC,SAAS,EAAE,KAAK,CAAC;SAChC;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,EAAE,kBAAU,CAAC,IAAI,CAAA;;;;UAIjB,IAAI,CAAC,SAAS,CAAC,KAAK,CAAC,QAAQ,CAAC;;OAEjC;SACF;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,kBAAkB;YACxB,IAAI,EAAE,kBAAU,CAAC,IAAI,CAAA;;;;;;;;;;;;OAYpB;SACF;KACF,CAAC;AACJ,CAAC,CAAC;AAzKW,QAAA,8BAA8B,kCAyKzC"}

package/lib/agent/src/orchestrate/realize/orchestrateRealizeCorrect.js

@@ -138,7 +138,7 @@ const claude = {
                         type: "string"
                     },
                     plan: {
-                        description: "Step 1.\n\n\uD83E\uDDE0 Provider Function Implementation Plan\n\nThis field outlines the strategic plan for implementing the provider\nfunction according to the Realize Coder Agent specification. Before\nwriting the actual code, think through the logic and structure.\n\nThe plan follows a SCHEMA-FIRST APPROACH:\n\n\uD83D\uDCCB STEP 1 - PRISMA SCHEMA VERIFICATION:\n\nDO:\n- Examine the actual Prisma schema model definition\n- List EVERY field that exists in the model with exact types\n- Explicitly note fields that DO NOT exist\n\nDO NOT:\n- Assume common fields exist without verification\n- Use fields like deleted_at, created_by, updated_by, is_deleted, is_active without checking\n\n\uD83D\uDCCB STEP 2 - FIELD INVENTORY:\n\n- List ONLY fields confirmed to exist in schema\n- Example: \"Verified fields in user model: id (String), email (String),\n  created_at (DateTime), updated_at (DateTime)\"\n- Example: \"Fields that DO NOT exist: deleted_at, is_active, created_by\"\n\n\uD83D\uDCCB STEP 3 - FIELD ACCESS STRATEGY:\n\n- Plan which verified fields will be used in select, update, create\n  operations\n- For complex operations with type errors, plan to use separate queries\n  instead of nested operations\n\n\uD83D\uDCCB STEP 4 - TYPE COMPATIBILITY:\n\n- Plan DateTime to ISO string conversions using toISOStringSafe()\n- Plan handling of nullable vs required fields\n\n\uD83D\uDCCB STEP 5 - IMPLEMENTATION APPROACH:\n\n- \uD83E\uDDE9 Required business entities (e.g., users, posts, logs) and their\n  relationships\n- \uD83D\uDEE0 Operations needed to fulfill the business scenario (e.g., fetch,\n  create, update) using ONLY verified fields\n- \uD83D\uDD04 Data dependencies between steps (e.g., use userId to fetch related\n  data)\n- \u2705 Validation points (based on business rules, not field presence)\n- \uD83D\uDEA7 Error and edge cases that must be handled explicitly (e.g., missing\n  records)\n- \uD83C\uDFD7 Structure: always a single `async function`, using only `parameters`\n  and `body`\n\n\u26A0\uFE0F Important Constraints:\n\n- Do NOT perform input validation \u2014 assume `parameters` and `body` are\n  already valid\n- Use `typia.random<T>()` with an explanatory comment if logic can't be\n  implemented\n- Never use `any` or make assumptions without sufficient context\n- Use only allowed imports \u2014 DTOs and Prisma types\n- Use `MyGlobal.prisma` for DB access and respect Prisma typing rules\n\n\u26A0\uFE0F TypeScript-specific considerations:\n\n- Do **not** use native `Date` objects directly; always convert all dates\n  using `toISOStringSafe()` and brand as `string &\n  tags.Format<'date-time'>`. This rule applies throughout all phases.\n- Prefer `satisfies` for DTO conformance instead of unsafe `as` casts\n- Avoid weak typing such as `any`, `as any`, or `satisfies any`\n- Use branded types (e.g., `tags.Format<'uuid'>`) and literal unions where\n  applicable\n\n\u2705 Example Structure:\n\n```ts\nexport async function doSomething(\n  user: { id: string & tags.Format<\"uuid\">; type: string },\n  parameters: IParams,\n  body: IBody\n): Promise<IReturn> {\n  const { id } = parameters;\n  const { name } = body;\n  const user = await MyGlobal.prisma.users.findFirst({ where: { id } });\n  if (!user) throw new Error(\"User not found\");\n  ...\n  return result;\n}\n```\n\n\uD83D\uDD0D Feasibility Analysis Requirement:\n\n- Before generating any code, the agent **must analyze** whether the\n  requested implementation is **feasible based on the given Prisma schema\n  and DTO types**.\n- If required fields or relationships are **missing or incompatible**, the\n  plan should explicitly state that the implementation is **not\n  possible** with the current schema/DTO, and no code should be generated\n  in later stages.\n- In such cases, only a detailed **comment in the `implementationCode`**\n  should be returned explaining why the logic cannot be implemented.\n\n\uD83D\uDD25 Error Handling Plan:\n\nIf an error is expected or encountered during implementation:\n\n- Clearly document the error message(s) and TypeScript error codes.\n- Analyze the root cause (e.g., type mismatch, missing field, nullability\n  issue).\n- Define concrete steps to resolve the issue, such as:\n\n  - Adjusting type declarations or using Prisma-generated input types.\n  - Using `?? undefined` to normalize nullable fields.\n  - Applying correct relation handling (e.g., `connect` instead of direct\n      foreign key assignment).\n  - Ensuring all date fields use `.toISOString()` and proper branding.\n- Include fallback or workaround plans if a direct fix is complex.\n- If no error is present, simply omit this section.\n\nThis plan ensures the function will:\n\n- Respect the global architecture and coding conventions\n- Be safe, predictable, and aligned with upstream logic",
+                        description: "Step 1.\n\n\uD83E\uDDE0 Provider Function Implementation Plan\n\nThis field outlines the strategic plan for implementing the provider\nfunction according to the Realize Coder Agent specification. Before\nwriting the actual code, think through the logic and structure.\n\nThe plan follows a SCHEMA-FIRST APPROACH:\n\n\uD83D\uDCCB STEP 1 - PRISMA SCHEMA VERIFICATION:\n\nDO:\n\n- Examine the actual Prisma schema model definition\n- List EVERY field that exists in the model with exact types\n- Explicitly note fields that DO NOT exist\n\nDO NOT:\n\n- Assume common fields exist without verification\n- Use fields like deleted_at, created_by, updated_by, is_deleted, is_active\n  without checking\n\n\uD83D\uDCCB STEP 2 - FIELD INVENTORY:\n\n- List ONLY fields confirmed to exist in schema\n- Example: \"Verified fields in user model: id (String), email (String),\n  created_at (DateTime), updated_at (DateTime)\"\n- Example: \"Fields that DO NOT exist: deleted_at, is_active, created_by\"\n\n\uD83D\uDCCB STEP 3 - FIELD ACCESS STRATEGY:\n\n- Plan which verified fields will be used in select, update, create\n  operations\n- For complex operations with type errors, plan to use separate queries\n  instead of nested operations\n\n\uD83D\uDCCB STEP 4 - TYPE COMPATIBILITY:\n\n- Plan DateTime to ISO string conversions using toISOStringSafe()\n- Plan handling of nullable vs required fields\n\n\uD83D\uDCCB STEP 5 - IMPLEMENTATION APPROACH:\n\n- \uD83E\uDDE9 Required business entities (e.g., users, posts, logs) and their\n  relationships\n- \uD83D\uDEE0 Operations needed to fulfill the business scenario (e.g., fetch,\n  create, update) using ONLY verified fields\n- \uD83D\uDD04 Data dependencies between steps (e.g., use userId to fetch related\n  data)\n- \u2705 Validation points (based on business rules, not field presence)\n- \uD83D\uDEA7 Error and edge cases that must be handled explicitly (e.g., missing\n  records)\n- \uD83C\uDFD7 Structure: always a single `async function`, using only `parameters`\n  and `body`\n\n\u26A0\uFE0F Important Constraints:\n\n- Do NOT perform input validation \u2014 assume `parameters` and `body` are\n  already valid\n- Use `typia.random<T>()` with an explanatory comment if logic can't be\n  implemented\n- Never use `any` or make assumptions without sufficient context\n- Use only allowed imports \u2014 DTOs and Prisma types\n- Use `MyGlobal.prisma` for DB access and respect Prisma typing rules\n\n\u26A0\uFE0F TypeScript-specific considerations:\n\n- Do **not** use native `Date` objects directly; always convert all dates\n  using `toISOStringSafe()` and brand as `string &\n  tags.Format<'date-time'>`. This rule applies throughout all phases.\n- Prefer `satisfies` for DTO conformance instead of unsafe `as` casts\n- Avoid weak typing such as `any`, `as any`, or `satisfies any`\n- Use branded types (e.g., `tags.Format<'uuid'>`) and literal unions where\n  applicable\n\n\u2705 Example Structure:\n\n```ts\nexport async function doSomething(\n  user: { id: string & tags.Format<\"uuid\">; type: string },\n  parameters: IParams,\n  body: IBody\n): Promise<IReturn> {\n  const { id } = parameters;\n  const { name } = body;\n  const user = await MyGlobal.prisma.users.findFirst({ where: { id } });\n  if (!user) throw new Error(\"User not found\");\n  ...\n  return result;\n}\n```\n\n\uD83D\uDD0D Feasibility Analysis Requirement:\n\n- Before generating any code, the agent **must analyze** whether the\n  requested implementation is **feasible based on the given Prisma schema\n  and DTO types**.\n- If required fields or relationships are **missing or incompatible**, the\n  plan should explicitly state that the implementation is **not\n  possible** with the current schema/DTO, and no code should be generated\n  in later stages.\n- In such cases, only a detailed **comment in the `implementationCode`**\n  should be returned explaining why the logic cannot be implemented.\n\n\uD83D\uDD25 Error Handling Plan:\n\nIf an error is expected or encountered during implementation:\n\n- Clearly document the error message(s) and TypeScript error codes.\n- Analyze the root cause (e.g., type mismatch, missing field, nullability\n  issue).\n- Define concrete steps to resolve the issue, such as:\n\n  - Adjusting type declarations or using Prisma-generated input types.\n  - Using `?? undefined` to normalize nullable fields.\n  - Applying correct relation handling (e.g., `connect` instead of direct\n      foreign key assignment).\n  - Ensuring all date fields use `.toISOString()` and proper branding.\n- Include fallback or workaround plans if a direct fix is complex.\n- If no error is present, simply omit this section.\n\nThis plan ensures the function will:\n\n- Respect the global architecture and coding conventions\n- Be safe, predictable, and aligned with upstream logic",
                         type: "string"
                     },
                     prisma_schemas: {
@@ -146,7 +146,7 @@ const claude = {
                         type: "string"
                     },
                     draft_without_date_type: {
-                        description: "Step 3.\n\nDraft WITHOUT using native Date type.\n\nThis is the initial drafting phase where you outline the basic skeleton\nof the function.\n\nDO NOT: Use the native Date type.\n\n- The function signature must correctly include `user`, `parameters`, and\n  `body` arguments.\n- Design the main flow of business logic, such as DB fetches and early\n  returns based on conditions.\n- Mark any incomplete or missing parts clearly with placeholders (e.g.,\n  comments or temporary values).\n\nImport rules:\n\nDO NOT:\n- Add any new import statements manually\n- Write import statements directly (this causes compile errors)\n\nNote: All necessary imports are provided globally or by the system automatically.\n\n\u2705 Requirements:\n\n- Avoid using the `any` type at all costs to ensure type safety.\n- NEVER declare variables with `: Date` type\n- ALWAYS use `string & tags.Format<'date-time'>` for date values\n- Use `toISOStringSafe(new Date())` for current timestamps\n- Maintain a single-function structure; avoid using classes.",
+                        description: "Step 3.\n\nDraft WITHOUT using native Date type.\n\nThis is the initial drafting phase where you outline the basic skeleton\nof the function.\n\nDO NOT: Use the native Date type.\n\n- The function signature must correctly include `user`, `parameters`, and\n  `body` arguments.\n- Design the main flow of business logic, such as DB fetches and early\n  returns based on conditions.\n- Mark any incomplete or missing parts clearly with placeholders (e.g.,\n  comments or temporary values).\n\nImport rules:\n\nDO NOT:\n\n- Add any new import statements manually\n- Write import statements directly (this causes compile errors)\n\nNote: All necessary imports are provided globally or by the system\nautomatically.\n\n\u2705 Requirements:\n\n- Avoid using the `any` type at all costs to ensure type safety.\n- NEVER declare variables with `: Date` type\n- ALWAYS use `string & tags.Format<'date-time'>` for date values\n- Use `toISOStringSafe(new Date())` for current timestamps\n- Maintain a single-function structure; avoid using classes.",
                         type: "string"
                     },
                     review: {
@@ -253,7 +253,7 @@ const collection = {
                             type: "string"
                         },
                         plan: {
-                            description: "Step 1.\n\n\uD83E\uDDE0 Provider Function Implementation Plan\n\nThis field outlines the strategic plan for implementing the provider\nfunction according to the Realize Coder Agent specification. Before\nwriting the actual code, think through the logic and structure.\n\nThe plan follows a SCHEMA-FIRST APPROACH:\n\n\uD83D\uDCCB STEP 1 - PRISMA SCHEMA VERIFICATION:\n\nDO:\n- Examine the actual Prisma schema model definition\n- List EVERY field that exists in the model with exact types\n- Explicitly note fields that DO NOT exist\n\nDO NOT:\n- Assume common fields exist without verification\n- Use fields like deleted_at, created_by, updated_by, is_deleted, is_active without checking\n\n\uD83D\uDCCB STEP 2 - FIELD INVENTORY:\n\n- List ONLY fields confirmed to exist in schema\n- Example: \"Verified fields in user model: id (String), email (String),\n  created_at (DateTime), updated_at (DateTime)\"\n- Example: \"Fields that DO NOT exist: deleted_at, is_active, created_by\"\n\n\uD83D\uDCCB STEP 3 - FIELD ACCESS STRATEGY:\n\n- Plan which verified fields will be used in select, update, create\n  operations\n- For complex operations with type errors, plan to use separate queries\n  instead of nested operations\n\n\uD83D\uDCCB STEP 4 - TYPE COMPATIBILITY:\n\n- Plan DateTime to ISO string conversions using toISOStringSafe()\n- Plan handling of nullable vs required fields\n\n\uD83D\uDCCB STEP 5 - IMPLEMENTATION APPROACH:\n\n- \uD83E\uDDE9 Required business entities (e.g., users, posts, logs) and their\n  relationships\n- \uD83D\uDEE0 Operations needed to fulfill the business scenario (e.g., fetch,\n  create, update) using ONLY verified fields\n- \uD83D\uDD04 Data dependencies between steps (e.g., use userId to fetch related\n  data)\n- \u2705 Validation points (based on business rules, not field presence)\n- \uD83D\uDEA7 Error and edge cases that must be handled explicitly (e.g., missing\n  records)\n- \uD83C\uDFD7 Structure: always a single `async function`, using only `parameters`\n  and `body`\n\n\u26A0\uFE0F Important Constraints:\n\n- Do NOT perform input validation \u2014 assume `parameters` and `body` are\n  already valid\n- Use `typia.random<T>()` with an explanatory comment if logic can't be\n  implemented\n- Never use `any` or make assumptions without sufficient context\n- Use only allowed imports \u2014 DTOs and Prisma types\n- Use `MyGlobal.prisma` for DB access and respect Prisma typing rules\n\n\u26A0\uFE0F TypeScript-specific considerations:\n\n- Do **not** use native `Date` objects directly; always convert all dates\n  using `toISOStringSafe()` and brand as `string &\n  tags.Format<'date-time'>`. This rule applies throughout all phases.\n- Prefer `satisfies` for DTO conformance instead of unsafe `as` casts\n- Avoid weak typing such as `any`, `as any`, or `satisfies any`\n- Use branded types (e.g., `tags.Format<'uuid'>`) and literal unions where\n  applicable\n\n\u2705 Example Structure:\n\n```ts\nexport async function doSomething(\n  user: { id: string & tags.Format<\"uuid\">; type: string },\n  parameters: IParams,\n  body: IBody\n): Promise<IReturn> {\n  const { id } = parameters;\n  const { name } = body;\n  const user = await MyGlobal.prisma.users.findFirst({ where: { id } });\n  if (!user) throw new Error(\"User not found\");\n  ...\n  return result;\n}\n```\n\n\uD83D\uDD0D Feasibility Analysis Requirement:\n\n- Before generating any code, the agent **must analyze** whether the\n  requested implementation is **feasible based on the given Prisma schema\n  and DTO types**.\n- If required fields or relationships are **missing or incompatible**, the\n  plan should explicitly state that the implementation is **not\n  possible** with the current schema/DTO, and no code should be generated\n  in later stages.\n- In such cases, only a detailed **comment in the `implementationCode`**\n  should be returned explaining why the logic cannot be implemented.\n\n\uD83D\uDD25 Error Handling Plan:\n\nIf an error is expected or encountered during implementation:\n\n- Clearly document the error message(s) and TypeScript error codes.\n- Analyze the root cause (e.g., type mismatch, missing field, nullability\n  issue).\n- Define concrete steps to resolve the issue, such as:\n\n  - Adjusting type declarations or using Prisma-generated input types.\n  - Using `?? undefined` to normalize nullable fields.\n  - Applying correct relation handling (e.g., `connect` instead of direct\n      foreign key assignment).\n  - Ensuring all date fields use `.toISOString()` and proper branding.\n- Include fallback or workaround plans if a direct fix is complex.\n- If no error is present, simply omit this section.\n\nThis plan ensures the function will:\n\n- Respect the global architecture and coding conventions\n- Be safe, predictable, and aligned with upstream logic",
+                            description: "Step 1.\n\n\uD83E\uDDE0 Provider Function Implementation Plan\n\nThis field outlines the strategic plan for implementing the provider\nfunction according to the Realize Coder Agent specification. Before\nwriting the actual code, think through the logic and structure.\n\nThe plan follows a SCHEMA-FIRST APPROACH:\n\n\uD83D\uDCCB STEP 1 - PRISMA SCHEMA VERIFICATION:\n\nDO:\n\n- Examine the actual Prisma schema model definition\n- List EVERY field that exists in the model with exact types\n- Explicitly note fields that DO NOT exist\n\nDO NOT:\n\n- Assume common fields exist without verification\n- Use fields like deleted_at, created_by, updated_by, is_deleted, is_active\n  without checking\n\n\uD83D\uDCCB STEP 2 - FIELD INVENTORY:\n\n- List ONLY fields confirmed to exist in schema\n- Example: \"Verified fields in user model: id (String), email (String),\n  created_at (DateTime), updated_at (DateTime)\"\n- Example: \"Fields that DO NOT exist: deleted_at, is_active, created_by\"\n\n\uD83D\uDCCB STEP 3 - FIELD ACCESS STRATEGY:\n\n- Plan which verified fields will be used in select, update, create\n  operations\n- For complex operations with type errors, plan to use separate queries\n  instead of nested operations\n\n\uD83D\uDCCB STEP 4 - TYPE COMPATIBILITY:\n\n- Plan DateTime to ISO string conversions using toISOStringSafe()\n- Plan handling of nullable vs required fields\n\n\uD83D\uDCCB STEP 5 - IMPLEMENTATION APPROACH:\n\n- \uD83E\uDDE9 Required business entities (e.g., users, posts, logs) and their\n  relationships\n- \uD83D\uDEE0 Operations needed to fulfill the business scenario (e.g., fetch,\n  create, update) using ONLY verified fields\n- \uD83D\uDD04 Data dependencies between steps (e.g., use userId to fetch related\n  data)\n- \u2705 Validation points (based on business rules, not field presence)\n- \uD83D\uDEA7 Error and edge cases that must be handled explicitly (e.g., missing\n  records)\n- \uD83C\uDFD7 Structure: always a single `async function`, using only `parameters`\n  and `body`\n\n\u26A0\uFE0F Important Constraints:\n\n- Do NOT perform input validation \u2014 assume `parameters` and `body` are\n  already valid\n- Use `typia.random<T>()` with an explanatory comment if logic can't be\n  implemented\n- Never use `any` or make assumptions without sufficient context\n- Use only allowed imports \u2014 DTOs and Prisma types\n- Use `MyGlobal.prisma` for DB access and respect Prisma typing rules\n\n\u26A0\uFE0F TypeScript-specific considerations:\n\n- Do **not** use native `Date` objects directly; always convert all dates\n  using `toISOStringSafe()` and brand as `string &\n  tags.Format<'date-time'>`. This rule applies throughout all phases.\n- Prefer `satisfies` for DTO conformance instead of unsafe `as` casts\n- Avoid weak typing such as `any`, `as any`, or `satisfies any`\n- Use branded types (e.g., `tags.Format<'uuid'>`) and literal unions where\n  applicable\n\n\u2705 Example Structure:\n\n```ts\nexport async function doSomething(\n  user: { id: string & tags.Format<\"uuid\">; type: string },\n  parameters: IParams,\n  body: IBody\n): Promise<IReturn> {\n  const { id } = parameters;\n  const { name } = body;\n  const user = await MyGlobal.prisma.users.findFirst({ where: { id } });\n  if (!user) throw new Error(\"User not found\");\n  ...\n  return result;\n}\n```\n\n\uD83D\uDD0D Feasibility Analysis Requirement:\n\n- Before generating any code, the agent **must analyze** whether the\n  requested implementation is **feasible based on the given Prisma schema\n  and DTO types**.\n- If required fields or relationships are **missing or incompatible**, the\n  plan should explicitly state that the implementation is **not\n  possible** with the current schema/DTO, and no code should be generated\n  in later stages.\n- In such cases, only a detailed **comment in the `implementationCode`**\n  should be returned explaining why the logic cannot be implemented.\n\n\uD83D\uDD25 Error Handling Plan:\n\nIf an error is expected or encountered during implementation:\n\n- Clearly document the error message(s) and TypeScript error codes.\n- Analyze the root cause (e.g., type mismatch, missing field, nullability\n  issue).\n- Define concrete steps to resolve the issue, such as:\n\n  - Adjusting type declarations or using Prisma-generated input types.\n  - Using `?? undefined` to normalize nullable fields.\n  - Applying correct relation handling (e.g., `connect` instead of direct\n      foreign key assignment).\n  - Ensuring all date fields use `.toISOString()` and proper branding.\n- Include fallback or workaround plans if a direct fix is complex.\n- If no error is present, simply omit this section.\n\nThis plan ensures the function will:\n\n- Respect the global architecture and coding conventions\n- Be safe, predictable, and aligned with upstream logic",
                             type: "string"
                         },
                         prisma_schemas: {
@@ -261,7 +261,7 @@ const collection = {
                             type: "string"
                         },
                         draft_without_date_type: {
-                            description: "Step 3.\n\nDraft WITHOUT using native Date type.\n\nThis is the initial drafting phase where you outline the basic skeleton\nof the function.\n\nDO NOT: Use the native Date type.\n\n- The function signature must correctly include `user`, `parameters`, and\n  `body` arguments.\n- Design the main flow of business logic, such as DB fetches and early\n  returns based on conditions.\n- Mark any incomplete or missing parts clearly with placeholders (e.g.,\n  comments or temporary values).\n\nImport rules:\n\nDO NOT:\n- Add any new import statements manually\n- Write import statements directly (this causes compile errors)\n\nNote: All necessary imports are provided globally or by the system automatically.\n\n\u2705 Requirements:\n\n- Avoid using the `any` type at all costs to ensure type safety.\n- NEVER declare variables with `: Date` type\n- ALWAYS use `string & tags.Format<'date-time'>` for date values\n- Use `toISOStringSafe(new Date())` for current timestamps\n- Maintain a single-function structure; avoid using classes.",
+                            description: "Step 3.\n\nDraft WITHOUT using native Date type.\n\nThis is the initial drafting phase where you outline the basic skeleton\nof the function.\n\nDO NOT: Use the native Date type.\n\n- The function signature must correctly include `user`, `parameters`, and\n  `body` arguments.\n- Design the main flow of business logic, such as DB fetches and early\n  returns based on conditions.\n- Mark any incomplete or missing parts clearly with placeholders (e.g.,\n  comments or temporary values).\n\nImport rules:\n\nDO NOT:\n\n- Add any new import statements manually\n- Write import statements directly (this causes compile errors)\n\nNote: All necessary imports are provided globally or by the system\nautomatically.\n\n\u2705 Requirements:\n\n- Avoid using the `any` type at all costs to ensure type safety.\n- NEVER declare variables with `: Date` type\n- ALWAYS use `string & tags.Format<'date-time'>` for date values\n- Use `toISOStringSafe(new Date())` for current timestamps\n- Maintain a single-function structure; avoid using classes.",
                             type: "string"
                         },
                         review: {

package/lib/agent/src/orchestrate/realize/orchestrateRealizeScenario.js

@@ -23,7 +23,7 @@ exports.orchestrateRealizeScenario = void 0;
  */
 const orchestrateRealizeScenario = (ctx, operation, authorization) => {
     var _a, _b;
-    const testScenarios = (_b = (_a = ctx
+    const testFiles = (_b = (_a = ctx
         .state()
         .test) === null || _a === void 0 ? void 0 : _a.files.filter((el) => el.scenario.endpoint.method === operation.method &&
         el.scenario.endpoint.path === operation.path)) !== null && _b !== void 0 ? _b : [];
@@ -36,7 +36,7 @@ const orchestrateRealizeScenario = (ctx, operation, authorization) => {
         operation: operation,
         functionName: functionName,
         location: `src/providers/${functionName}.ts`,
-        testScenarios: testScenarios.map((el) => el.scenario.draft),
+        testFiles: testFiles,
         decoratorEvent: authorization,
     };
 };

package/lib/agent/src/orchestrate/realize/orchestrateRealizeScenario.js.map

@@ -1 +1 @@
-{"version":3,"file":"orchestrateRealizeScenario.js","sourceRoot":"","sources":["../../../../../src/orchestrate/realize/orchestrateRealizeScenario.ts"],"names":[],"mappings":";;;AAMA;;;;;;;;;;;;;;;;;;;GAmBG;AACI,MAAM,0BAA0B,GAAG,CACxC,GAAyB,EACzB,SAAmC,EACnC,aAA0C,EACA,EAAE;;IAC5C,MAAM,aAAa,GACjB,MAAA,MAAA,GAAG;SACA,KAAK,EAAE;SACP,IAAI,0CAAE,KAAK,CAAC,MAAM,CACjB,CAAC,EAAE,EAAE,EAAE,CACL,EAAE,CAAC,QAAQ,CAAC,QAAQ,CAAC,MAAM,KAAK,SAAS,CAAC,MAAM;QAChD,EAAE,CAAC,QAAQ,CAAC,QAAQ,CAAC,IAAI,KAAK,SAAS,CAAC,IAAI,CAC/C,mCAAI,EAAE,CAAC;IAEZ,MAAM,YAAY,GAAG,GAAG,SAAS,CAAC,MAAM,IAAI,SAAS,CAAC,IAAI;SACvD,UAAU,CAAC,GAAG,EAAE,GAAG,CAAC;SACpB,UAAU,CAAC,GAAG,EAAE,GAAG,CAAC;SACpB,UAAU,CAAC,GAAG,EAAE,GAAG,CAAC;SACpB,UAAU,CAAC,GAAG,EAAE,EAAE,CAAC,EAAE,CAAC;IACzB,OAAO;QACL,SAAS,EAAE,SAAS;QACpB,YAAY,EAAE,YAAY;QAC1B,QAAQ,EAAE,iBAAiB,YAAY,KAAK;QAC5C,aAAa,EAAE,aAAa,CAAC,GAAG,CAAC,CAAC,EAAE,EAAE,EAAE,CAAC,EAAE,CAAC,QAAQ,CAAC,KAAK,CAAC;QAC3D,cAAc,EAAE,aAAa;KAC9B,CAAC;AACJ,CAAC,CAAC;AA1BW,QAAA,0BAA0B,8BA0BrC"}
+{"version":3,"file":"orchestrateRealizeScenario.js","sourceRoot":"","sources":["../../../../../src/orchestrate/realize/orchestrateRealizeScenario.ts"],"names":[],"mappings":";;;AAUA;;;;;;;;;;;;;;;;;;;GAmBG;AACI,MAAM,0BAA0B,GAAG,CACxC,GAAyB,EACzB,SAAmC,EACnC,aAA0C,EACA,EAAE;;IAC5C,MAAM,SAAS,GACb,MAAA,MAAA,GAAG;SACA,KAAK,EAAE;SACP,IAAI,0CAAE,KAAK,CAAC,MAAM,CACjB,CAAC,EAAE,EAAE,EAAE,CACL,EAAE,CAAC,QAAQ,CAAC,QAAQ,CAAC,MAAM,KAAK,SAAS,CAAC,MAAM;QAChD,EAAE,CAAC,QAAQ,CAAC,QAAQ,CAAC,IAAI,KAAK,SAAS,CAAC,IAAI,CAC/C,mCAAI,EAAE,CAAC;IAEZ,MAAM,YAAY,GAAG,GAAG,SAAS,CAAC,MAAM,IAAI,SAAS,CAAC,IAAI;SACvD,UAAU,CAAC,GAAG,EAAE,GAAG,CAAC;SACpB,UAAU,CAAC,GAAG,EAAE,GAAG,CAAC;SACpB,UAAU,CAAC,GAAG,EAAE,GAAG,CAAC;SACpB,UAAU,CAAC,GAAG,EAAE,EAAE,CAAC,EAAE,CAAC;IACzB,OAAO;QACL,SAAS,EAAE,SAAS;QACpB,YAAY,EAAE,YAAY;QAC1B,QAAQ,EAAE,iBAAiB,YAAY,KAAK;QAC5C,SAAS,EAAE,SAAS;QACpB,cAAc,EAAE,aAAa;KAC9B,CAAC;AACJ,CAAC,CAAC;AA1BW,QAAA,0BAA0B,8BA0BrC"}

package/lib/agent/src/orchestrate/realize/orchestrateRealizeWrite.js

@@ -145,7 +145,7 @@ const claude = {
                 type: "object",
                 properties: {
                     plan: {
-                        description: "Step 1.\n\n\uD83E\uDDE0 Provider Function Implementation Plan\n\nThis field outlines the strategic plan for implementing the provider\nfunction according to the Realize Coder Agent specification. Before\nwriting the actual code, think through the logic and structure.\n\nThe plan follows a SCHEMA-FIRST APPROACH:\n\n\uD83D\uDCCB STEP 1 - PRISMA SCHEMA VERIFICATION:\n\nDO:\n- Examine the actual Prisma schema model definition\n- List EVERY field that exists in the model with exact types\n- Explicitly note fields that DO NOT exist\n\nDO NOT:\n- Assume common fields exist without verification\n- Use fields like deleted_at, created_by, updated_by, is_deleted, is_active without checking\n\n\uD83D\uDCCB STEP 2 - FIELD INVENTORY:\n\n- List ONLY fields confirmed to exist in schema\n- Example: \"Verified fields in user model: id (String), email (String),\n  created_at (DateTime), updated_at (DateTime)\"\n- Example: \"Fields that DO NOT exist: deleted_at, is_active, created_by\"\n\n\uD83D\uDCCB STEP 3 - FIELD ACCESS STRATEGY:\n\n- Plan which verified fields will be used in select, update, create\n  operations\n- For complex operations with type errors, plan to use separate queries\n  instead of nested operations\n\n\uD83D\uDCCB STEP 4 - TYPE COMPATIBILITY:\n\n- Plan DateTime to ISO string conversions using toISOStringSafe()\n- Plan handling of nullable vs required fields\n\n\uD83D\uDCCB STEP 5 - IMPLEMENTATION APPROACH:\n\n- \uD83E\uDDE9 Required business entities (e.g., users, posts, logs) and their\n  relationships\n- \uD83D\uDEE0 Operations needed to fulfill the business scenario (e.g., fetch,\n  create, update) using ONLY verified fields\n- \uD83D\uDD04 Data dependencies between steps (e.g., use userId to fetch related\n  data)\n- \u2705 Validation points (based on business rules, not field presence)\n- \uD83D\uDEA7 Error and edge cases that must be handled explicitly (e.g., missing\n  records)\n- \uD83C\uDFD7 Structure: always a single `async function`, using only `parameters`\n  and `body`\n\n\u26A0\uFE0F Important Constraints:\n\n- Do NOT perform input validation \u2014 assume `parameters` and `body` are\n  already valid\n- Use `typia.random<T>()` with an explanatory comment if logic can't be\n  implemented\n- Never use `any` or make assumptions without sufficient context\n- Use only allowed imports \u2014 DTOs and Prisma types\n- Use `MyGlobal.prisma` for DB access and respect Prisma typing rules\n\n\u26A0\uFE0F TypeScript-specific considerations:\n\n- Do **not** use native `Date` objects directly; always convert all dates\n  using `toISOStringSafe()` and brand as `string &\n  tags.Format<'date-time'>`. This rule applies throughout all phases.\n- Prefer `satisfies` for DTO conformance instead of unsafe `as` casts\n- Avoid weak typing such as `any`, `as any`, or `satisfies any`\n- Use branded types (e.g., `tags.Format<'uuid'>`) and literal unions where\n  applicable\n\n\u2705 Example Structure:\n\n```ts\nexport async function doSomething(\n  user: { id: string & tags.Format<\"uuid\">; type: string },\n  parameters: IParams,\n  body: IBody\n): Promise<IReturn> {\n  const { id } = parameters;\n  const { name } = body;\n  const user = await MyGlobal.prisma.users.findFirst({ where: { id } });\n  if (!user) throw new Error(\"User not found\");\n  ...\n  return result;\n}\n```\n\n\uD83D\uDD0D Feasibility Analysis Requirement:\n\n- Before generating any code, the agent **must analyze** whether the\n  requested implementation is **feasible based on the given Prisma schema\n  and DTO types**.\n- If required fields or relationships are **missing or incompatible**, the\n  plan should explicitly state that the implementation is **not\n  possible** with the current schema/DTO, and no code should be generated\n  in later stages.\n- In such cases, only a detailed **comment in the `implementationCode`**\n  should be returned explaining why the logic cannot be implemented.\n\n\uD83D\uDD25 Error Handling Plan:\n\nIf an error is expected or encountered during implementation:\n\n- Clearly document the error message(s) and TypeScript error codes.\n- Analyze the root cause (e.g., type mismatch, missing field, nullability\n  issue).\n- Define concrete steps to resolve the issue, such as:\n\n  - Adjusting type declarations or using Prisma-generated input types.\n  - Using `?? undefined` to normalize nullable fields.\n  - Applying correct relation handling (e.g., `connect` instead of direct\n      foreign key assignment).\n  - Ensuring all date fields use `.toISOString()` and proper branding.\n- Include fallback or workaround plans if a direct fix is complex.\n- If no error is present, simply omit this section.\n\nThis plan ensures the function will:\n\n- Respect the global architecture and coding conventions\n- Be safe, predictable, and aligned with upstream logic",
+                        description: "Step 1.\n\n\uD83E\uDDE0 Provider Function Implementation Plan\n\nThis field outlines the strategic plan for implementing the provider\nfunction according to the Realize Coder Agent specification. Before\nwriting the actual code, think through the logic and structure.\n\nThe plan follows a SCHEMA-FIRST APPROACH:\n\n\uD83D\uDCCB STEP 1 - PRISMA SCHEMA VERIFICATION:\n\nDO:\n\n- Examine the actual Prisma schema model definition\n- List EVERY field that exists in the model with exact types\n- Explicitly note fields that DO NOT exist\n\nDO NOT:\n\n- Assume common fields exist without verification\n- Use fields like deleted_at, created_by, updated_by, is_deleted, is_active\n  without checking\n\n\uD83D\uDCCB STEP 2 - FIELD INVENTORY:\n\n- List ONLY fields confirmed to exist in schema\n- Example: \"Verified fields in user model: id (String), email (String),\n  created_at (DateTime), updated_at (DateTime)\"\n- Example: \"Fields that DO NOT exist: deleted_at, is_active, created_by\"\n\n\uD83D\uDCCB STEP 3 - FIELD ACCESS STRATEGY:\n\n- Plan which verified fields will be used in select, update, create\n  operations\n- For complex operations with type errors, plan to use separate queries\n  instead of nested operations\n\n\uD83D\uDCCB STEP 4 - TYPE COMPATIBILITY:\n\n- Plan DateTime to ISO string conversions using toISOStringSafe()\n- Plan handling of nullable vs required fields\n\n\uD83D\uDCCB STEP 5 - IMPLEMENTATION APPROACH:\n\n- \uD83E\uDDE9 Required business entities (e.g., users, posts, logs) and their\n  relationships\n- \uD83D\uDEE0 Operations needed to fulfill the business scenario (e.g., fetch,\n  create, update) using ONLY verified fields\n- \uD83D\uDD04 Data dependencies between steps (e.g., use userId to fetch related\n  data)\n- \u2705 Validation points (based on business rules, not field presence)\n- \uD83D\uDEA7 Error and edge cases that must be handled explicitly (e.g., missing\n  records)\n- \uD83C\uDFD7 Structure: always a single `async function`, using only `parameters`\n  and `body`\n\n\u26A0\uFE0F Important Constraints:\n\n- Do NOT perform input validation \u2014 assume `parameters` and `body` are\n  already valid\n- Use `typia.random<T>()` with an explanatory comment if logic can't be\n  implemented\n- Never use `any` or make assumptions without sufficient context\n- Use only allowed imports \u2014 DTOs and Prisma types\n- Use `MyGlobal.prisma` for DB access and respect Prisma typing rules\n\n\u26A0\uFE0F TypeScript-specific considerations:\n\n- Do **not** use native `Date` objects directly; always convert all dates\n  using `toISOStringSafe()` and brand as `string &\n  tags.Format<'date-time'>`. This rule applies throughout all phases.\n- Prefer `satisfies` for DTO conformance instead of unsafe `as` casts\n- Avoid weak typing such as `any`, `as any`, or `satisfies any`\n- Use branded types (e.g., `tags.Format<'uuid'>`) and literal unions where\n  applicable\n\n\u2705 Example Structure:\n\n```ts\nexport async function doSomething(\n  user: { id: string & tags.Format<\"uuid\">; type: string },\n  parameters: IParams,\n  body: IBody\n): Promise<IReturn> {\n  const { id } = parameters;\n  const { name } = body;\n  const user = await MyGlobal.prisma.users.findFirst({ where: { id } });\n  if (!user) throw new Error(\"User not found\");\n  ...\n  return result;\n}\n```\n\n\uD83D\uDD0D Feasibility Analysis Requirement:\n\n- Before generating any code, the agent **must analyze** whether the\n  requested implementation is **feasible based on the given Prisma schema\n  and DTO types**.\n- If required fields or relationships are **missing or incompatible**, the\n  plan should explicitly state that the implementation is **not\n  possible** with the current schema/DTO, and no code should be generated\n  in later stages.\n- In such cases, only a detailed **comment in the `implementationCode`**\n  should be returned explaining why the logic cannot be implemented.\n\n\uD83D\uDD25 Error Handling Plan:\n\nIf an error is expected or encountered during implementation:\n\n- Clearly document the error message(s) and TypeScript error codes.\n- Analyze the root cause (e.g., type mismatch, missing field, nullability\n  issue).\n- Define concrete steps to resolve the issue, such as:\n\n  - Adjusting type declarations or using Prisma-generated input types.\n  - Using `?? undefined` to normalize nullable fields.\n  - Applying correct relation handling (e.g., `connect` instead of direct\n      foreign key assignment).\n  - Ensuring all date fields use `.toISOString()` and proper branding.\n- Include fallback or workaround plans if a direct fix is complex.\n- If no error is present, simply omit this section.\n\nThis plan ensures the function will:\n\n- Respect the global architecture and coding conventions\n- Be safe, predictable, and aligned with upstream logic",
                         type: "string"
                     },
                     prisma_schemas: {
@@ -153,7 +153,7 @@ const claude = {
                         type: "string"
                     },
                     draft_without_date_type: {
-                        description: "Step 3.\n\nDraft WITHOUT using native Date type.\n\nThis is the initial drafting phase where you outline the basic skeleton\nof the function.\n\nDO NOT: Use the native Date type.\n\n- The function signature must correctly include `user`, `parameters`, and\n  `body` arguments.\n- Design the main flow of business logic, such as DB fetches and early\n  returns based on conditions.\n- Mark any incomplete or missing parts clearly with placeholders (e.g.,\n  comments or temporary values).\n\nImport rules:\n\nDO NOT:\n- Add any new import statements manually\n- Write import statements directly (this causes compile errors)\n\nNote: All necessary imports are provided globally or by the system automatically.\n\n\u2705 Requirements:\n\n- Avoid using the `any` type at all costs to ensure type safety.\n- NEVER declare variables with `: Date` type\n- ALWAYS use `string & tags.Format<'date-time'>` for date values\n- Use `toISOStringSafe(new Date())` for current timestamps\n- Maintain a single-function structure; avoid using classes.",
+                        description: "Step 3.\n\nDraft WITHOUT using native Date type.\n\nThis is the initial drafting phase where you outline the basic skeleton\nof the function.\n\nDO NOT: Use the native Date type.\n\n- The function signature must correctly include `user`, `parameters`, and\n  `body` arguments.\n- Design the main flow of business logic, such as DB fetches and early\n  returns based on conditions.\n- Mark any incomplete or missing parts clearly with placeholders (e.g.,\n  comments or temporary values).\n\nImport rules:\n\nDO NOT:\n\n- Add any new import statements manually\n- Write import statements directly (this causes compile errors)\n\nNote: All necessary imports are provided globally or by the system\nautomatically.\n\n\u2705 Requirements:\n\n- Avoid using the `any` type at all costs to ensure type safety.\n- NEVER declare variables with `: Date` type\n- ALWAYS use `string & tags.Format<'date-time'>` for date values\n- Use `toISOStringSafe(new Date())` for current timestamps\n- Maintain a single-function structure; avoid using classes.",
                         type: "string"
                     },
                     review: {
@@ -251,7 +251,7 @@ const collection = {
                     type: "object",
                     properties: {
                         plan: {
-                            description: "Step 1.\n\n\uD83E\uDDE0 Provider Function Implementation Plan\n\nThis field outlines the strategic plan for implementing the provider\nfunction according to the Realize Coder Agent specification. Before\nwriting the actual code, think through the logic and structure.\n\nThe plan follows a SCHEMA-FIRST APPROACH:\n\n\uD83D\uDCCB STEP 1 - PRISMA SCHEMA VERIFICATION:\n\nDO:\n- Examine the actual Prisma schema model definition\n- List EVERY field that exists in the model with exact types\n- Explicitly note fields that DO NOT exist\n\nDO NOT:\n- Assume common fields exist without verification\n- Use fields like deleted_at, created_by, updated_by, is_deleted, is_active without checking\n\n\uD83D\uDCCB STEP 2 - FIELD INVENTORY:\n\n- List ONLY fields confirmed to exist in schema\n- Example: \"Verified fields in user model: id (String), email (String),\n  created_at (DateTime), updated_at (DateTime)\"\n- Example: \"Fields that DO NOT exist: deleted_at, is_active, created_by\"\n\n\uD83D\uDCCB STEP 3 - FIELD ACCESS STRATEGY:\n\n- Plan which verified fields will be used in select, update, create\n  operations\n- For complex operations with type errors, plan to use separate queries\n  instead of nested operations\n\n\uD83D\uDCCB STEP 4 - TYPE COMPATIBILITY:\n\n- Plan DateTime to ISO string conversions using toISOStringSafe()\n- Plan handling of nullable vs required fields\n\n\uD83D\uDCCB STEP 5 - IMPLEMENTATION APPROACH:\n\n- \uD83E\uDDE9 Required business entities (e.g., users, posts, logs) and their\n  relationships\n- \uD83D\uDEE0 Operations needed to fulfill the business scenario (e.g., fetch,\n  create, update) using ONLY verified fields\n- \uD83D\uDD04 Data dependencies between steps (e.g., use userId to fetch related\n  data)\n- \u2705 Validation points (based on business rules, not field presence)\n- \uD83D\uDEA7 Error and edge cases that must be handled explicitly (e.g., missing\n  records)\n- \uD83C\uDFD7 Structure: always a single `async function`, using only `parameters`\n  and `body`\n\n\u26A0\uFE0F Important Constraints:\n\n- Do NOT perform input validation \u2014 assume `parameters` and `body` are\n  already valid\n- Use `typia.random<T>()` with an explanatory comment if logic can't be\n  implemented\n- Never use `any` or make assumptions without sufficient context\n- Use only allowed imports \u2014 DTOs and Prisma types\n- Use `MyGlobal.prisma` for DB access and respect Prisma typing rules\n\n\u26A0\uFE0F TypeScript-specific considerations:\n\n- Do **not** use native `Date` objects directly; always convert all dates\n  using `toISOStringSafe()` and brand as `string &\n  tags.Format<'date-time'>`. This rule applies throughout all phases.\n- Prefer `satisfies` for DTO conformance instead of unsafe `as` casts\n- Avoid weak typing such as `any`, `as any`, or `satisfies any`\n- Use branded types (e.g., `tags.Format<'uuid'>`) and literal unions where\n  applicable\n\n\u2705 Example Structure:\n\n```ts\nexport async function doSomething(\n  user: { id: string & tags.Format<\"uuid\">; type: string },\n  parameters: IParams,\n  body: IBody\n): Promise<IReturn> {\n  const { id } = parameters;\n  const { name } = body;\n  const user = await MyGlobal.prisma.users.findFirst({ where: { id } });\n  if (!user) throw new Error(\"User not found\");\n  ...\n  return result;\n}\n```\n\n\uD83D\uDD0D Feasibility Analysis Requirement:\n\n- Before generating any code, the agent **must analyze** whether the\n  requested implementation is **feasible based on the given Prisma schema\n  and DTO types**.\n- If required fields or relationships are **missing or incompatible**, the\n  plan should explicitly state that the implementation is **not\n  possible** with the current schema/DTO, and no code should be generated\n  in later stages.\n- In such cases, only a detailed **comment in the `implementationCode`**\n  should be returned explaining why the logic cannot be implemented.\n\n\uD83D\uDD25 Error Handling Plan:\n\nIf an error is expected or encountered during implementation:\n\n- Clearly document the error message(s) and TypeScript error codes.\n- Analyze the root cause (e.g., type mismatch, missing field, nullability\n  issue).\n- Define concrete steps to resolve the issue, such as:\n\n  - Adjusting type declarations or using Prisma-generated input types.\n  - Using `?? undefined` to normalize nullable fields.\n  - Applying correct relation handling (e.g., `connect` instead of direct\n      foreign key assignment).\n  - Ensuring all date fields use `.toISOString()` and proper branding.\n- Include fallback or workaround plans if a direct fix is complex.\n- If no error is present, simply omit this section.\n\nThis plan ensures the function will:\n\n- Respect the global architecture and coding conventions\n- Be safe, predictable, and aligned with upstream logic",
+                            description: "Step 1.\n\n\uD83E\uDDE0 Provider Function Implementation Plan\n\nThis field outlines the strategic plan for implementing the provider\nfunction according to the Realize Coder Agent specification. Before\nwriting the actual code, think through the logic and structure.\n\nThe plan follows a SCHEMA-FIRST APPROACH:\n\n\uD83D\uDCCB STEP 1 - PRISMA SCHEMA VERIFICATION:\n\nDO:\n\n- Examine the actual Prisma schema model definition\n- List EVERY field that exists in the model with exact types\n- Explicitly note fields that DO NOT exist\n\nDO NOT:\n\n- Assume common fields exist without verification\n- Use fields like deleted_at, created_by, updated_by, is_deleted, is_active\n  without checking\n\n\uD83D\uDCCB STEP 2 - FIELD INVENTORY:\n\n- List ONLY fields confirmed to exist in schema\n- Example: \"Verified fields in user model: id (String), email (String),\n  created_at (DateTime), updated_at (DateTime)\"\n- Example: \"Fields that DO NOT exist: deleted_at, is_active, created_by\"\n\n\uD83D\uDCCB STEP 3 - FIELD ACCESS STRATEGY:\n\n- Plan which verified fields will be used in select, update, create\n  operations\n- For complex operations with type errors, plan to use separate queries\n  instead of nested operations\n\n\uD83D\uDCCB STEP 4 - TYPE COMPATIBILITY:\n\n- Plan DateTime to ISO string conversions using toISOStringSafe()\n- Plan handling of nullable vs required fields\n\n\uD83D\uDCCB STEP 5 - IMPLEMENTATION APPROACH:\n\n- \uD83E\uDDE9 Required business entities (e.g., users, posts, logs) and their\n  relationships\n- \uD83D\uDEE0 Operations needed to fulfill the business scenario (e.g., fetch,\n  create, update) using ONLY verified fields\n- \uD83D\uDD04 Data dependencies between steps (e.g., use userId to fetch related\n  data)\n- \u2705 Validation points (based on business rules, not field presence)\n- \uD83D\uDEA7 Error and edge cases that must be handled explicitly (e.g., missing\n  records)\n- \uD83C\uDFD7 Structure: always a single `async function`, using only `parameters`\n  and `body`\n\n\u26A0\uFE0F Important Constraints:\n\n- Do NOT perform input validation \u2014 assume `parameters` and `body` are\n  already valid\n- Use `typia.random<T>()` with an explanatory comment if logic can't be\n  implemented\n- Never use `any` or make assumptions without sufficient context\n- Use only allowed imports \u2014 DTOs and Prisma types\n- Use `MyGlobal.prisma` for DB access and respect Prisma typing rules\n\n\u26A0\uFE0F TypeScript-specific considerations:\n\n- Do **not** use native `Date` objects directly; always convert all dates\n  using `toISOStringSafe()` and brand as `string &\n  tags.Format<'date-time'>`. This rule applies throughout all phases.\n- Prefer `satisfies` for DTO conformance instead of unsafe `as` casts\n- Avoid weak typing such as `any`, `as any`, or `satisfies any`\n- Use branded types (e.g., `tags.Format<'uuid'>`) and literal unions where\n  applicable\n\n\u2705 Example Structure:\n\n```ts\nexport async function doSomething(\n  user: { id: string & tags.Format<\"uuid\">; type: string },\n  parameters: IParams,\n  body: IBody\n): Promise<IReturn> {\n  const { id } = parameters;\n  const { name } = body;\n  const user = await MyGlobal.prisma.users.findFirst({ where: { id } });\n  if (!user) throw new Error(\"User not found\");\n  ...\n  return result;\n}\n```\n\n\uD83D\uDD0D Feasibility Analysis Requirement:\n\n- Before generating any code, the agent **must analyze** whether the\n  requested implementation is **feasible based on the given Prisma schema\n  and DTO types**.\n- If required fields or relationships are **missing or incompatible**, the\n  plan should explicitly state that the implementation is **not\n  possible** with the current schema/DTO, and no code should be generated\n  in later stages.\n- In such cases, only a detailed **comment in the `implementationCode`**\n  should be returned explaining why the logic cannot be implemented.\n\n\uD83D\uDD25 Error Handling Plan:\n\nIf an error is expected or encountered during implementation:\n\n- Clearly document the error message(s) and TypeScript error codes.\n- Analyze the root cause (e.g., type mismatch, missing field, nullability\n  issue).\n- Define concrete steps to resolve the issue, such as:\n\n  - Adjusting type declarations or using Prisma-generated input types.\n  - Using `?? undefined` to normalize nullable fields.\n  - Applying correct relation handling (e.g., `connect` instead of direct\n      foreign key assignment).\n  - Ensuring all date fields use `.toISOString()` and proper branding.\n- Include fallback or workaround plans if a direct fix is complex.\n- If no error is present, simply omit this section.\n\nThis plan ensures the function will:\n\n- Respect the global architecture and coding conventions\n- Be safe, predictable, and aligned with upstream logic",
                             type: "string"
                         },
                         prisma_schemas: {
@@ -259,7 +259,7 @@ const collection = {
                             type: "string"
                         },
                         draft_without_date_type: {
-                            description: "Step 3.\n\nDraft WITHOUT using native Date type.\n\nThis is the initial drafting phase where you outline the basic skeleton\nof the function.\n\nDO NOT: Use the native Date type.\n\n- The function signature must correctly include `user`, `parameters`, and\n  `body` arguments.\n- Design the main flow of business logic, such as DB fetches and early\n  returns based on conditions.\n- Mark any incomplete or missing parts clearly with placeholders (e.g.,\n  comments or temporary values).\n\nImport rules:\n\nDO NOT:\n- Add any new import statements manually\n- Write import statements directly (this causes compile errors)\n\nNote: All necessary imports are provided globally or by the system automatically.\n\n\u2705 Requirements:\n\n- Avoid using the `any` type at all costs to ensure type safety.\n- NEVER declare variables with `: Date` type\n- ALWAYS use `string & tags.Format<'date-time'>` for date values\n- Use `toISOStringSafe(new Date())` for current timestamps\n- Maintain a single-function structure; avoid using classes.",
+                            description: "Step 3.\n\nDraft WITHOUT using native Date type.\n\nThis is the initial drafting phase where you outline the basic skeleton\nof the function.\n\nDO NOT: Use the native Date type.\n\n- The function signature must correctly include `user`, `parameters`, and\n  `body` arguments.\n- Design the main flow of business logic, such as DB fetches and early\n  returns based on conditions.\n- Mark any incomplete or missing parts clearly with placeholders (e.g.,\n  comments or temporary values).\n\nImport rules:\n\nDO NOT:\n\n- Add any new import statements manually\n- Write import statements directly (this causes compile errors)\n\nNote: All necessary imports are provided globally or by the system\nautomatically.\n\n\u2705 Requirements:\n\n- Avoid using the `any` type at all costs to ensure type safety.\n- NEVER declare variables with `: Date` type\n- ALWAYS use `string & tags.Format<'date-time'>` for date values\n- Use `toISOStringSafe(new Date())` for current timestamps\n- Maintain a single-function structure; avoid using classes.",
                             type: "string"
                         },
                         review: {

package/lib/agent/src/orchestrate/realize/structures/IAutoBeRealizeScenarioApplication.d.ts

@@ -1,4 +1,4 @@
-import { AutoBeOpenApi, AutoBeRealizeAuthorization } from "@autobe/interface";
+import { AutoBeOpenApi, AutoBeRealizeAuthorization, AutoBeTestFile } from "@autobe/interface";
 export declare namespace IAutoBeRealizeScenarioApplication {
     interface IProps {
         /** The OpenAPI operation to be realized. */
@@ -24,7 +24,7 @@ export declare namespace IAutoBeRealizeScenarioApplication {
          * certain conditions. Used as a basis for TDD-style automated test
          * generation.
          */
-        testScenarios: string[];
+        testFiles: AutoBeTestFile[];
         /**
          * Optional decorator event for customizing code generation behavior.
          *

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

@@ -17,13 +17,16 @@ export declare namespace IAutoBeRealizeWriteApplication {
          * 📋 STEP 1 - PRISMA SCHEMA VERIFICATION:
          *
          * DO:
+         *
          * - Examine the actual Prisma schema model definition
          * - List EVERY field that exists in the model with exact types
          * - Explicitly note fields that DO NOT exist
          *
          * DO NOT:
+         *
          * - Assume common fields exist without verification
-         * - Use fields like deleted_at, created_by, updated_by, is_deleted, is_active without checking
+         * - Use fields like deleted_at, created_by, updated_by, is_deleted, is_active
+         *   without checking
          *
          * 📋 STEP 2 - FIELD INVENTORY:
          *
@@ -171,10 +174,12 @@ export declare namespace IAutoBeRealizeWriteApplication {
          * Import rules:
          *
          * DO NOT:
+         *
          * - Add any new import statements manually
          * - Write import statements directly (this causes compile errors)
          *
-         * Note: All necessary imports are provided globally or by the system automatically.
+         * Note: All necessary imports are provided globally or by the system
+         * automatically.
          *
          * ✅ Requirements:
          *

package/lib/agent/src/orchestrate/test/compile/getTestExternalDeclarations.js

@@ -25,6 +25,6 @@ const singleton = new tstl_1.Singleton((compiler) => __awaiter(void 0, void 0, v
             throw new Error(`File not found: ${location}`);
         return { [location]: content };
     };
-    return Object.assign(Object.assign({}, external("node_modules/@nestia/e2e/lib/TestValidator.d.ts")), external("node_modules/@nestia/fetcher/lib/IConnection.d.ts"));
+    return Object.assign(Object.assign(Object.assign(Object.assign({}, external("node_modules/@nestia/e2e/lib/ArrayUtil.d.ts")), external("node_modules/@nestia/e2e/lib/RandomGenerator.d.ts")), external("node_modules/@nestia/e2e/lib/TestValidator.d.ts")), external("node_modules/@nestia/fetcher/lib/IConnection.d.ts"));
 }));
 //# sourceMappingURL=getTestExternalDeclarations.js.map

package/lib/agent/src/orchestrate/test/compile/getTestExternalDeclarations.js.map

@@ -1 +1 @@
-{"version":3,"file":"getTestExternalDeclarations.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/test/compile/getTestExternalDeclarations.ts"],"names":[],"mappings":";;;;;;;;;;;AAMA,kEAKC;AATD,+BAAiC;AAIjC,SAAsB,2BAA2B,CAE/C,GAAyB;;QACzB,MAAM,QAAQ,GAAG,MAAM,GAAG,CAAC,QAAQ,EAAE,CAAC;QACtC,OAAO,SAAS,CAAC,GAAG,CAAC,QAAQ,CAAC,IAAI,CAAC,CAAC;IACtC,CAAC;CAAA;AAED,MAAM,SAAS,GAAG,IAAI,gBAAS,CAAC,CAAO,QAA6B,EAAE,EAAE;IACtE,MAAM,OAAO,GAA2B,MAAM,QAAQ,CAAC,WAAW,EAAE,CAAC;IACrE,MAAM,QAAQ,GAAG,CAAC,QAAgB,EAA0B,EAAE;QAC5D,MAAM,OAAO,GAAuB,OAAO,CAAC,QAAQ,CAAC,CAAC;QACtD,IAAI,OAAO,KAAK,SAAS;YAAE,MAAM,IAAI,KAAK,CAAC,mBAAmB,QAAQ,EAAE,CAAC,CAAC;QAC1E,OAAO,EAAE,CAAC,QAAQ,CAAC,EAAE,OAAO,EAAE,CAAC;IACjC,CAAC,CAAC;IACF,OAAO,gCACF,QAAQ,CAAC,iDAAiD,CAAC,GAC3D,QAAQ,CAAC,mDAAmD,CAAC,CAChC,CAAC;AACrC,CAAC,CAAA,CAAC,CAAC"}
+{"version":3,"file":"getTestExternalDeclarations.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/test/compile/getTestExternalDeclarations.ts"],"names":[],"mappings":";;;;;;;;;;;AAMA,kEAKC;AATD,+BAAiC;AAIjC,SAAsB,2BAA2B,CAE/C,GAAyB;;QACzB,MAAM,QAAQ,GAAG,MAAM,GAAG,CAAC,QAAQ,EAAE,CAAC;QACtC,OAAO,SAAS,CAAC,GAAG,CAAC,QAAQ,CAAC,IAAI,CAAC,CAAC;IACtC,CAAC;CAAA;AAED,MAAM,SAAS,GAAG,IAAI,gBAAS,CAAC,CAAO,QAA6B,EAAE,EAAE;IACtE,MAAM,OAAO,GAA2B,MAAM,QAAQ,CAAC,WAAW,EAAE,CAAC;IACrE,MAAM,QAAQ,GAAG,CAAC,QAAgB,EAA0B,EAAE;QAC5D,MAAM,OAAO,GAAuB,OAAO,CAAC,QAAQ,CAAC,CAAC;QACtD,IAAI,OAAO,KAAK,SAAS;YAAE,MAAM,IAAI,KAAK,CAAC,mBAAmB,QAAQ,EAAE,CAAC,CAAC;QAC1E,OAAO,EAAE,CAAC,QAAQ,CAAC,EAAE,OAAO,EAAE,CAAC;IACjC,CAAC,CAAC;IACF,OAAO,4DACF,QAAQ,CAAC,6CAA6C,CAAC,GACvD,QAAQ,CAAC,mDAAmD,CAAC,GAC7D,QAAQ,CAAC,iDAAiD,CAAC,GAC3D,QAAQ,CAAC,mDAAmD,CAAC,CAChC,CAAC;AACrC,CAAC,CAAA,CAAC,CAAC"}

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

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

package/lib/agent/src/orchestrate/test/histories/transformTestCorrectHistories.js

@@ -1,35 +1,51 @@
 "use strict";
+var __awaiter = (this && this.__awaiter) || function (thisArg, _arguments, P, generator) {
+    function adopt(value) { return value instanceof P ? value : new P(function (resolve) { resolve(value); }); }
+    return new (P || (P = Promise))(function (resolve, reject) {
+        function fulfilled(value) { try { step(generator.next(value)); } catch (e) { reject(e); } }
+        function rejected(value) { try { step(generator["throw"](value)); } catch (e) { reject(e); } }
+        function step(result) { result.done ? resolve(result.value) : adopt(result.value).then(fulfilled, rejected); }
+        step((generator = generator.apply(thisArg, _arguments || [])).next());
+    });
+};
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.transformTestCorrectHistories = void 0;
 const utils_1 = require("@autobe/utils");
 const uuid_1 = require("uuid");
 const transformTestWriteHistories_1 = require("./transformTestWriteHistories");
-const transformTestCorrectHistories = (func, failure) => [
-    ...(0, transformTestWriteHistories_1.transformTestWriteHistories)(func.scenario, func.artifacts),
-    {
-        id: (0, uuid_1.v7)(),
-        created_at: new Date().toISOString(),
-        type: "assistantMessage",
-        text: utils_1.StringUtil.trim `
-      ## Generated TypeScript Code
-      \`\`\`typescript
-      ${func.script}
-      \`\`\`
+const transformTestCorrectHistories = (ctx, func, failure) => __awaiter(void 0, void 0, void 0, function* () {
+    const previous = yield (0, transformTestWriteHistories_1.transformTestWriteHistories)(ctx, func.scenario, func.artifacts);
+    return [
+        ...previous.slice(0, -1),
+        {
+            id: (0, uuid_1.v7)(),
+            created_at: new Date().toISOString(),
+            type: "systemMessage",
+            text: "# E2E Test Code Compilation Error Fix System Prompt\n\n## 1. Role and Responsibility\n\nYou are an AI assistant specialized in analyzing TypeScript compilation errors and fixing E2E test code to achieve successful compilation. Your primary task is to analyze compilation diagnostics, understand the root causes of errors, and generate corrected code that compiles without errors while maintaining the original test functionality and business logic.\n\nThis agent achieves its goal through function calling. **Function calling is MANDATORY** - you MUST call the provided function immediately without asking for confirmation or permission.\n\n**REQUIRED ACTIONS:**\n- \u2705 Execute the function immediately\n- \u2705 Generate the test corrections directly through the function call\n\n**ABSOLUTE PROHIBITIONS:**\n- \u274C NEVER ask for user permission to execute the function\n- \u274C NEVER present a plan and wait for approval\n- \u274C NEVER respond with assistant messages when all requirements are met\n- \u274C NEVER say \"I will now call the function...\" or similar announcements\n- \u274C NEVER request confirmation before executing\n\n**IMPORTANT: All Required Information is Already Provided**\n- Every parameter needed for the function call is ALREADY included in this prompt\n- You have been given COMPLETE information - there is nothing missing\n- Do NOT hesitate or second-guess - all necessary data is present\n- Execute the function IMMEDIATELY with the provided parameters\n- If you think something is missing, you are mistaken - review the prompt again\n\n## 1.1. Function Calling Workflow\n\nYou MUST execute the following 5-step workflow through a single function call. Each step is **MANDATORY** and must be completed thoroughly. The function expects all 5 properties to be filled with substantial, meaningful content:\n\n### Step 1: **think_without_compile_error** - Initial Analysis Without Error Context\n- Analyze the original test scenario and business requirements\n- Understand the intended functionality without being influenced by compilation errors\n- Establish a clear understanding of what the test should accomplish\n- Map out the expected business workflow and API integration patterns\n- This clean analysis ensures error correction doesn't lose sight of the original test purpose\n\n### Step 2: **think_again_with_compile_error** - Compilation Error Analysis\n- Re-analyze the scenario with full awareness of compilation errors\n- Systematically examine each error message and diagnostic information\n- Identify error patterns and understand how they relate to the intended functionality\n- Correlate compilation diagnostics with the original requirements\n- Plan targeted error correction strategies based on root cause analysis\n\n### Step 3: **draft** - Draft Corrected Implementation\n- Generate the first corrected version of the test code\n- Address ALL identified compilation errors systematically\n- Preserve the original business logic and test workflow\n- Ensure the code is compilation-error-free\n- Follow all established conventions and type safety requirements\n- **Critical**: Start directly with `export async function` - NO import statements\n\n### Step 4: **review** - Code Review and Validation\n- Perform a comprehensive review of the corrected draft\n- **This step is CRITICAL** - thoroughly validate all corrections\n- Verify that:\n  - All compilation errors have been resolved\n  - Original functionality is preserved\n  - TypeScript type safety is maintained\n  - API integration is correct\n  - Test workflow remains complete\n- Identify any remaining issues or improvements needed\n- Document specific validations performed\n\n### Step 5: **final** - Production-Ready Corrected Code\n- Produce the final, polished version incorporating all review feedback\n- Ensure ALL compilation issues are resolved\n- Maintain strict type safety without using any bypass mechanisms\n- Deliver production-ready test code that compiles successfully\n- This is the deliverable that will replace the compilation-failed code\n\n**IMPORTANT**: All 5 steps must contain substantial content. Do not provide empty or minimal responses for any step. Each property should demonstrate thorough analysis and correction effort.\n\n## 2. Input Materials Overview\n\nYou will receive the following context through the conversation messages:\n\n- **Original system prompt**: Complete guidelines and requirements used by the initial code writing agent\n- **Original input materials**: Test scenario, API specifications, DTO types, and other materials used for initial code generation\n- **Generated code**: The TypeScript E2E test code that failed to compile\n- **Compilation diagnostics**: Detailed TypeScript compilation error information\n\nYour job is to analyze the compilation errors and produce corrected code that follows all the original guidelines while resolving compilation issues.\n\n## 3. TypeScript Compilation Results Analysis\n\nThe compilation error information follows this detailed structure:\n\n```typescript\n/**\n * Result of TypeScript compilation and validation operations.\n *\n * This union type represents all possible outcomes when the TypeScript compiler\n * processes generated code from the Test and Realize agents. The compilation\n * results enable AI self-correction through detailed feedback mechanisms while\n * ensuring that all generated code meets production standards and integrates\n * seamlessly with the TypeScript ecosystem.\n *\n * The compilation process validates framework integration, type system\n * integrity, dependency resolution, and build compatibility. Success results\n * indicate production-ready code, while failure results provide detailed\n * diagnostics for iterative refinement through the AI feedback loop.\n *\n * @author Samchon\n */\nexport type IAutoBeTypeScriptCompileResult =\n  | IAutoBeTypeScriptCompileResult.ISuccess\n  | IAutoBeTypeScriptCompileResult.IFailure\n  | IAutoBeTypeScriptCompileResult.IException;\n\nexport namespace IAutoBeTypeScriptCompileResult {\n  /**\n   * Successful compilation result with generated JavaScript output.\n   *\n   * Represents the ideal outcome where TypeScript compilation completed without\n   * errors and produced clean JavaScript code ready for execution. This result\n   * indicates that the generated TypeScript code meets all production\n   * standards, integrates correctly with frameworks and dependencies, and\n   * maintains complete type safety throughout the application stack.\n   */\n  export interface ISuccess {\n    /** Discriminator indicating successful compilation. */\n    type: \"success\";\n  }\n\n  /**\n   * Compilation failure with detailed diagnostic information and partial\n   * output.\n   *\n   * Represents cases where TypeScript compilation encountered errors or\n   * warnings that prevent successful code generation. This result provides\n   * comprehensive diagnostic information to enable AI agents to understand\n   * specific issues and implement targeted corrections through the iterative\n   * refinement process.\n   */\n  export interface IFailure {\n    /** Discriminator indicating compilation failure. */\n    type: \"failure\";\n\n    /**\n     * Detailed compilation diagnostics for error analysis and correction.\n     *\n     * Contains comprehensive information about compilation errors, warnings,\n     * and suggestions that occurred during the TypeScript compilation process.\n     * Each diagnostic includes file location, error category, diagnostic codes,\n     * and detailed messages that enable AI agents to understand and resolve\n     * specific compilation issues.\n     */\n    diagnostics: IDiagnostic[];\n  }\n\n  /**\n   * Unexpected exception during the compilation process.\n   *\n   * Represents cases where the TypeScript compilation process encountered an\n   * unexpected runtime error or system exception that prevented normal\n   * compilation operation. These cases indicate potential issues with the\n   * compilation environment or unexpected edge cases that should be\n   * investigated.\n   */\n  export interface IException {\n    /** Discriminator indicating compilation exception. */\n    type: \"exception\";\n\n    /**\n     * The raw error or exception that occurred during compilation.\n     *\n     * Contains the original error object or exception details for debugging\n     * purposes. This information helps developers identify the root cause of\n     * unexpected compilation failures and improve system reliability while\n     * maintaining the robustness of the automated development pipeline.\n     */\n    error: unknown;\n  }\n\n  /**\n   * Detailed diagnostic information for compilation issues.\n   *\n   * Provides comprehensive details about specific compilation problems\n   * including file locations, error categories, diagnostic codes, and\n   * descriptive messages. This information is essential for AI agents to\n   * understand compilation failures and implement precise corrections during\n   * the iterative development process.\n   *\n   * @author Samchon\n   */\n  export interface IDiagnostic {\n    /**\n     * Source file where the diagnostic was generated.\n     *\n     * Specifies the TypeScript source file that contains the issue, or null if\n     * the diagnostic applies to the overall compilation process rather than a\n     * specific file. This information helps AI agents target corrections to the\n     * appropriate source files during the refinement process.\n     */\n    file: string | null;\n\n    /**\n     * Category of the diagnostic message.\n     *\n     * Indicates the severity and type of the compilation issue, enabling AI\n     * agents to prioritize fixes and understand the impact of each diagnostic.\n     * Errors must be resolved for successful compilation, while warnings and\n     * suggestions can guide code quality improvements.\n     */\n    category: DiagnosticCategory;\n\n    /**\n     * TypeScript diagnostic code for the specific issue.\n     *\n     * Provides the official TypeScript diagnostic code that identifies the\n     * specific type of compilation issue. This code can be used to look up\n     * detailed explanations and resolution strategies in TypeScript\n     * documentation or automated correction systems.\n     */\n    code: number | string;\n\n    /**\n     * Character position where the diagnostic begins in the source file.\n     *\n     * Specifies the exact location in the source file where the issue starts,\n     * or undefined if the diagnostic doesn't apply to a specific location. This\n     * precision enables AI agents to make targeted corrections without\n     * affecting unrelated code sections.\n     */\n    start: number | undefined;\n\n    /**\n     * Length of the text span covered by this diagnostic.\n     *\n     * Indicates how many characters from the start position are affected by\n     * this diagnostic, or undefined if the diagnostic doesn't apply to a\n     * specific text span. This information helps AI agents understand the scope\n     * of corrections needed for each issue.\n     */\n    length: number | undefined;\n\n    /**\n     * Human-readable description of the compilation issue.\n     *\n     * Provides a detailed explanation of the compilation problem in natural\n     * language that AI agents can analyze to understand the issue and formulate\n     * appropriate corrections. The message text includes context and\n     * suggestions for resolving the identified problem.\n     */\n    messageText: string;\n  }\n\n  /**\n   * Categories of TypeScript diagnostic messages.\n   *\n   * Defines the severity levels and types of compilation diagnostics that can\n   * be generated during TypeScript compilation. These categories help AI agents\n   * prioritize fixes and understand the impact of each compilation issue on the\n   * overall code quality and functionality.\n   *\n   * @author Samchon\n   */\n  export type DiagnosticCategory =\n    | \"warning\" // Issues that don't prevent compilation but indicate potential problems\n    | \"error\" // Critical issues that prevent successful compilation and must be fixed\n    | \"suggestion\" // Recommendations for code improvements that enhance quality\n    | \"message\"; // Informational messages about the compilation process\n}\n```\n\n## 4. Error Analysis and Correction Strategy\n\n### 4.1. Strict Correction Requirements\n\n**FORBIDDEN CORRECTION METHODS - NEVER USE THESE:**\n- Never use `any` type to bypass type checking\n- Never use `@ts-ignore` comments to suppress compilation errors\n- Never use `@ts-expect-error` comments to bypass type validation\n- Never use `as any` type assertions to force type compatibility\n- Never use `satisfies any` expressions to skip type validation\n- Never use any other type safety bypass mechanisms\n\n**REQUIRED CORRECTION APPROACH:**\n- Fix errors by using correct types from provided DTO definitions\n- Resolve type mismatches by following exact API SDK function signatures\n- Address compilation issues through proper TypeScript syntax and typing\n- Maintain strict type safety throughout the entire correction process\n- **AGGRESSIVE SCENARIO MODIFICATION**: If compilation errors cannot be resolved through code changes alone, aggressively modify or rewrite the test scenario itself to achieve compilation success\n\nThe goal is to achieve genuine compilation success through proper TypeScript usage, not to hide errors through type system suppression.\n\n**IMPLEMENTATION FEASIBILITY REQUIREMENT:**\nIf the original code attempts to implement functionality that cannot be realized with the provided API functions and DTO types, **REMOVE OR REWRITE those parts** during error correction. Prioritize achieving successful compilation by aggressively modifying the test scenario when necessary, rather than preserving unimplementable test cases.\n\n### 4.2. Diagnostic Analysis Process\n\n**Systematic Error Analysis:**\n1. **Error Categorization**: Focus on `\"error\"` category diagnostics first, as these prevent successful compilation\n2. **Error Priority Assessment**: \n   - Type system violations and missing type definitions\n   - API function signature mismatches\n   - Import/export issues and module resolution\n   - Syntax errors and malformed expressions\n   - Logic errors and incorrect implementations\n3. **Location Mapping**: Use `file`, `start`, and `length` to pinpoint exact error locations in the source code\n4. **Error Code Analysis**: Reference TypeScript diagnostic codes to understand specific error types\n5. **Message Interpretation**: Analyze `messageText` to understand the root cause and required corrections\n\n**Root Cause Identification:**\n- Analyze each diagnostic's file location, error code, and message\n- Identify patterns in errors that suggest systematic issues\n- Determine if errors are related to incorrect API usage, type mismatches, or logic problems\n- Check for cascading errors where fixing one issue resolves multiple diagnostics\n\n### 4.3. Systematic Error Resolution\n\n**Error Resolution Strategy:**\n- Prioritize errors over warnings and suggestions\n- Fix errors that may be causing cascading issues first\n- Maintain all original functionality while resolving compilation issues\n- Ensure the corrected code follows all guidelines from the original system prompt\n- Verify that fixes don't introduce new compilation errors\n\n**Common Error Resolution Patterns:**\n- **Type Mismatches**: Use correct types from provided DTO definitions\n- **Function Signature Errors**: Match exact API SDK function signatures\n- **Import Errors**: Remember no import statements should be used in E2E tests\n- **Authentication Issues**: Use only actual authentication APIs provided in materials\n- **TestValidator Errors**: Apply proper function syntax and parameter order\n- **typia.random() Errors**: Always provide explicit generic type arguments to `typia.random<T>()`\n\n### 4.4. Special Compilation Error Patterns and Solutions\n\n### 4.4.1. Non-existent API SDK Function Calls\n\nYou must only use API SDK functions that actually exist in the provided materials.\n\nIf the error message (`ITypeScriptCompileResult.IDiagnostic.messageText`) shows something like:\n```\nProperty 'update' does not exist on type 'typeof import(\"src/api/functional/bbs/articles/index\")'.\n```\n\nThis indicates an attempt to call a non-existent API SDK function. Refer to the following list of available API functions and replace the incorrect function call with the proper one:\n\n{{API_SDK_FUNCTIONS}}\n\n**Solution approach:**\n- Locate the failing function call in your code\n- Find the correct function name from the table above\n- Replace the non-existent function call with the correct API SDK function\n- Ensure the function signature matches the provided SDK specification\n\n### 4.4.2. Undefined DTO Type References\n\nIf the error message shows:\n```\nCannot find module '@ORGANIZATION/PROJECT-api/lib/structures/ISomeDtoTypeName.ts' or its corresponding type declarations\n```\n\nThis means you are using DTO types that don't exist in the provided materials. You must only use DTO types that are explicitly defined in the input materials.\n\nRefer to the following DTO definitions and replace undefined types with the correct ones:\n\n{{API_DTO_SCHEMAS}}\n\n**Solution approach:**\n- Identify the undefined type name in the error message\n- Search for the correct type name in the DTO definitions above\n- Replace the undefined type reference with the correct DTO type\n- Ensure the type usage matches the provided type definition structure\n\n**Critical DTO Type Usage Rules:**\n- **Use DTO types exactly as provided**: NEVER add any prefix or namespace to DTO types\n  - \u274C WRONG: `api.structures.ICustomer` \n  - \u274C WRONG: `api.ICustomer`\n  - \u274C WRONG: `structures.ICustomer`\n  - \u274C WRONG: `dto.ICustomer`\n  - \u274C WRONG: `types.ICustomer`\n  - \u2705 CORRECT: `ICustomer` (use the exact name provided)\n- **Always use `satisfies` for request body data**: When declaring or assigning request body DTOs, use `satisfies` keyword:\n  - Variable declaration: `const requestBody = { ... } satisfies IRequestBody;`\n  - API function body parameter: `body: { ... } satisfies IRequestBody`\n  - Never use `as` keyword for type assertions with request bodies\n\n### 4.4.3. Complex Error Message Validation\n\nIf the test scenario suggests implementing complex error message validation or using fallback closures with `TestValidator.error()`, **DO NOT IMPLEMENT** these test cases. Focus only on simple error occurrence testing.\n\nIf you encounter code like:\n```typescript\n// WRONG: Don't implement complex error message validation\nawait TestValidator.error(\n  \"limit validation error\",\n  async () => {\n    await api.functional.bbs.categories.patch(connection, {\n      body: { page: 1, limit: 1000000 } satisfies IBbsCategories.IRequest,\n    });\n  },\n  (error) => { // \u2190 Remove this fallback closure\n    if (!error?.message?.toLowerCase().includes(\"limit\"))\n      throw new Error(\"Error message validation\");\n  },\n);\n```\n\n**Solution approach:**\n- Remove any fallback closure (second parameter) from `TestValidator.error()` calls\n- Simplify to only test whether an error occurs or not\n- Do not attempt to validate specific error messages, error types, or error properties\n- Focus on runtime business logic errors with properly typed, valid TypeScript code\n- **AGGRESSIVE SCENARIO MODIFICATION**: If the test case fundamentally relies on complex error validation that cannot be implemented, completely remove or rewrite that test case to focus on simpler, compilable scenarios\n\n```typescript\n// CORRECT: Simple error occurrence testing\nTestValidator.error(\n  \"limit validation error\",\n  () => {\n    return api.functional.bbs.categories.patch(connection, {\n      body: { page: 1, limit: 1000000 } satisfies IBbsCategories.IRequest,\n    });\n  },\n);\n```\n\n**Rule:** Only test scenarios that involve runtime errors with properly typed, valid TypeScript code. Skip any test scenarios that require detailed error message validation or complex error inspection logic.\n\n### 4.4.4. Type-safe Equality Assertions\n\nWhen fixing `TestValidator.equals()` and `TestValidator.notEquals()` calls, be careful about parameter order. The generic type is determined by the first parameter, so the second parameter must be assignable to the first parameter's type.\n\n**IMPORTANT: Use actual-first, expected-second pattern**\nFor best type compatibility, use the actual value (from API responses or variables) as the first parameter and the expected value as the second parameter:\n\n```typescript\n// CORRECT: actual value first, expected value second\nconst member: IMember = await api.functional.membership.join(connection, ...);\nTestValidator.equals(\"no recommender\", member.recommender, null); // member.recommender is IRecommender | null, can accept null \u2713\n\n// WRONG: expected value first, actual value second - may cause type errors\nTestValidator.equals(\"no recommender\", null, member.recommender); // null cannot accept IRecommender | null \u2717\n\n// CORRECT: String comparison example\nTestValidator.equals(\"user ID matches\", createdUser.id, expectedId); // actual first, expected second \u2713\n\n// CORRECT: Object comparison example  \nTestValidator.equals(\"user data matches\", actualUser, expectedUserData); // actual first, expected second \u2713\n```\n\n**Additional type compatibility examples:**\n```typescript\n// CORRECT: First parameter type can accept second parameter\nconst user = { id: \"123\", name: \"John\", email: \"john@example.com\" };\nconst userSummary = { id: \"123\", name: \"John\" };\n\nTestValidator.equals(\"user contains summary data\", user, userSummary); // user type can accept userSummary \u2713\nTestValidator.equals(\"user summary matches\", userSummary, user); // WRONG: userSummary cannot accept user with extra properties \u2717\n\n// CORRECT: Extract specific properties for comparison\nTestValidator.equals(\"user ID matches\", user.id, userSummary.id); // string = string \u2713\nTestValidator.equals(\"user name matches\", user.name, userSummary.name); // string = string \u2713\n\n// CORRECT: Union type parameter order\nconst value: string | null = getSomeValue();\nTestValidator.equals(\"value should be null\", value, null); // string | null can accept null \u2713\nTestValidator.equals(\"value should be null\", null, value); // WRONG: null cannot accept string | null \u2717\n```\n\n**Solution approach:**\n- Use the pattern `TestValidator.equals(\"description\", actualValue, expectedValue)` where actualValue is typically from API responses\n- If compilation errors occur with `TestValidator.equals(title, x, y)` because `y` cannot be assigned to `x`'s type, reverse the order to `TestValidator.equals(title, y, x)`\n- Alternatively, extract specific properties for comparison to ensure type compatibility\n- Apply the same logic to `TestValidator.notEquals()` calls\n\n### 4.4.5. Unimplementable Scenario Components\n\nIf the original code attempts to implement functionality that cannot be realized with the provided API functions and DTO types, **REMOVE those parts** during error correction. Only fix and retain code that is technically feasible with the actual materials provided.\n\n**Examples of unimplementable functionality to REMOVE:**\n- Code attempting to call API functions that don't exist in the provided SDK function definitions\n- Code using DTO properties that don't exist in the provided type definitions\n- Code implementing features that require API endpoints not available in the materials\n- Code with data filtering or searching using parameters not supported by the actual DTO types\n\n```typescript\n// REMOVE: If code tries to call non-existent bulk ship function\n// await api.functional.orders.bulkShip(connection, {...}); \u2190 Remove this entirely\n\n// REMOVE: If code tries to use non-existent date filter properties\n// { startDate: \"2024-01-01\", endDate: \"2024-12-31\" } \u2190 Remove these properties\n```\n\n**Solution approach:**\n1. **Identify unimplementable code**: Look for compilation errors related to non-existent API functions or DTO properties\n2. **Verify against provided materials**: Check if the functionality exists in the actual API SDK functions and DTO definitions\n3. **Remove entire code blocks**: Delete the unimplementable functionality rather than trying to fix it\n4. **Maintain test flow**: Ensure the remaining code still forms a coherent test workflow\n5. **Focus on feasible functionality**: Preserve and fix only the parts that can be properly implemented\n\n**Solution approach:**\n1. **Identify incorrect patterns**: Look for compilation errors related to incorrect parameter counts or function signatures\n2. **Apply proper parameters**: Pass all parameters directly to the function\n3. **Maintain type safety**: Ensure parameter order follows the type-safe guidelines (first parameter determines generic type)\n4. **Verify function signatures**: Check that each function call receives the correct number of parameters\n\n### 4.4.7. Missing Generic Type Arguments in typia.random()\n\nIf you encounter compilation errors related to `typia.random()` calls without explicit generic type arguments, fix them by adding the required type parameters.\n\n**CRITICAL: Always provide generic type arguments to typia.random()**\nThe `typia.random()` function requires explicit generic type arguments. This is a common source of compilation errors in E2E tests.\n\n**Common error patterns to fix:**\n```typescript\n// WRONG: Missing generic type argument causes compilation error\nconst x = typia.random(); // \u2190 Compilation error\nconst x: string & tags.Format<\"uuid\"> = typia.random(); // \u2190 Still compilation error\n\n// CORRECT: Always provide explicit generic type arguments\nconst x = typia.random<string & tags.Format<\"uuid\">>();\nconst x: string = typia.random<string & tags.Format<\"uuid\">>();\nconst x: string & tags.Format<\"uuid\"> = typia.random<string & tags.Format<\"uuid\">>();\n```\n\n**Solution approach:**\n1. **Identify missing generic arguments**: Look for compilation errors related to `typia.random()` calls\n2. **Add explicit type parameters**: Ensure all `typia.random()` calls have `<TypeDefinition>` generic arguments\n3. **Use appropriate types**: Match the generic type with the intended data type for the test\n4. **Verify compilation**: Check that the fix resolves the compilation error\n\n**Rule:** Always use the pattern `typia.random<TypeDefinition>()` with explicit generic type arguments, regardless of variable type annotations.\n\n### 4.4.8. Promises Must Be Awaited\n\nIf you encounter the compilation error \"Promises must be awaited\", this means an asynchronous function is being called without the `await` keyword.\n\n**Common error patterns to fix:**\n```typescript\n// WRONG: Missing await for async function calls\napi.functional.users.getUser(connection, userId); // \u2190 Compilation error: Promises must be awaited\nTestValidator.error(\"test\", () => api.functional.users.create(connection, body)); // \u2190 Missing await\n\n// CORRECT: Use await with async function calls\nawait api.functional.users.getUser(connection, userId); \nawait TestValidator.error(\"test\", () => api.functional.users.create(connection, body));\n```\n\n**Solution approach:**\n1. **Identify async function calls**: All API SDK functions return Promises\n2. **Add await keyword**: Ensure all async function calls are preceded by `await`\n3. **Check TestValidator calls**: Even within TestValidator functions, API calls must be awaited\n4. **Verify async context**: Ensure the containing function is marked as `async`\n\n**Rule:** All asynchronous function calls must use the `await` keyword to properly handle Promises.\n\n### 4.4.9. Connection Headers Initialization\n\nIf you encounter errors related to `connection.headers` being undefined when trying to assign values:\n\n**Error pattern:**\n```typescript\n// WRONG: Direct assignment when headers is undefined\nconnection.headers.Authorization = \"Bearer token\"; // \u2190 Error: Cannot set property 'Authorization' of undefined\n```\n\n**Solution:**\n```typescript\n// CORRECT: Initialize headers object before assignment\nconnection.headers ??= {};\nconnection.headers.Authorization = \"Bearer token\";\n```\n\n**Solution approach:**\n1. **Check if headers exists**: `connection.headers` has a default value of `undefined`\n2. **Initialize if needed**: Use the nullish coalescing assignment operator `??=` to initialize\n3. **Then assign values**: After initialization, you can safely assign header values\n\n**Rule:** Always initialize `connection.headers` as an empty object before assigning any values to it.\n\n### 4.4.10. Typia Tag Type Conversion Errors (Compilation Error Fix Only)\n\n**\u26A0\uFE0F CRITICAL: This section is ONLY for fixing compilation errors. Do NOT use satisfies pattern in normal code!**\n\nWhen encountering type errors with Typia tags, especially when dealing with complex intersection types:\n\n**Error pattern:**\n```typescript\n// Error: Type 'number & Type<\"int32\">' is not assignable to type '(number & Type<\"int32\"> & Minimum<1> & Maximum<1000>) | undefined'\nconst limit: number & tags.Type<\"int32\"> & tags.Minimum<1> & tags.Maximum<1000> = typia.random<number & tags.Type<\"int32\">>();\n```\n\n**Solution (ONLY USE THIS WHEN YOU GET A COMPILATION ERROR):**\n```typescript\n// \u26A0\uFE0F IMPORTANT: Only use satisfies when you encounter type mismatch compilation errors!\n// Don't add satisfies to code that already compiles successfully.\n\n// WRONG: Including tags in satisfies - DON'T DO THIS!\nconst limit = typia.random<number & tags.Type<\"int32\">>() satisfies (number & tags.Type<\"int32\">) as (number & tags.Type<\"int32\">);  // NO! Don't include tags in satisfies\nconst pageLimit = typia.random<number & tags.Type<\"uint32\">>() satisfies (number & tags.Type<\"uint32\">) as number;  // WRONG! satisfies should use basic type only\n\n// CORRECT: Use satisfies with basic type only (WHEN FIXING COMPILATION ERRORS)\nconst limit = typia.random<number & tags.Type<\"int32\">>() satisfies number as number;  // YES! satisfies uses basic type\nconst pageLimit = typia.random<number & tags.Type<\"uint32\"> & tags.Minimum<10> & tags.Maximum<100>>() satisfies number as number;  // CORRECT!\n\n// More examples (ONLY WHEN FIXING ERRORS):\nconst name = typia.random<string & tags.MinLength<3> & tags.MaxLength<50>>() satisfies string as string;  // Good\nconst email = typia.random<string & tags.Format<\"email\">>() satisfies string as string;  // Good\nconst age = typia.random<number & tags.Type<\"uint32\"> & tags.Minimum<0> & tags.Maximum<120>>() satisfies number as number;  // Good\n```\n\n**Solution approach:**\n1. **Check if there's a compilation error**: Only use satisfies if TypeScript complains about type mismatches\n2. **Use basic types in satisfies**: `satisfies number`, `satisfies string`, NOT `satisfies (number & tags.Type<\"int32\">)`\n3. **Then use as**: Convert to the target basic type\n\n**Rule:** The `satisfies ... as ...` pattern is a COMPILATION ERROR FIX, not a general coding pattern. Only use it when the TypeScript compiler reports type mismatch errors with tagged types.\n\n### 4.4.11. Literal Type Arrays with RandomGenerator.pick\n\nWhen selecting from a fixed set of literal values using `RandomGenerator.pick()`, you MUST use `as const` to preserve literal types:\n\n**Problem:**\n```typescript\n// WRONG: Without 'as const', the array becomes string[] and loses literal types\nconst possibleRoles = [\"super_admin\", \"compliance_officer\", \"customer_service\"];\nconst role = RandomGenerator.pick(possibleRoles); // role is type 'string', not literal union\n\nconst adminData = {\n  email: \"admin@example.com\",\n  role: role  // Type error: string is not assignable to \"super_admin\" | \"compliance_officer\" | \"customer_service\"\n} satisfies IAdmin.ICreate;\n```\n\n**Solution:**\n```typescript\n// CORRECT: Use 'as const' to preserve literal types\nconst possibleRoles = [\"super_admin\", \"compliance_officer\", \"customer_service\"] as const;\nconst role = RandomGenerator.pick(possibleRoles); // role is type \"super_admin\" | \"compliance_officer\" | \"customer_service\"\n\nconst adminData = {\n  email: \"admin@example.com\",\n  role: role  // Works! Literal type matches expected union\n} satisfies IAdmin.ICreate;\n\n// More examples:\nconst statuses = [\"active\", \"inactive\", \"pending\"] as const;\nconst status = RandomGenerator.pick(statuses);\n\nconst priorities = [1, 2, 3, 4, 5] as const;\nconst priority = RandomGenerator.pick(priorities);\n\nconst booleans = [true, false] as const;\nconst isActive = RandomGenerator.pick(booleans);\n```\n\n**Rule:** Always use `as const` when creating arrays of literal values for `RandomGenerator.pick()`. This ensures TypeScript preserves the literal types instead of widening to primitive types.\n\n## 5. Correction Requirements\n\nYour corrected code must:\n\n**Compilation Success:**\n- Resolve all TypeScript compilation errors identified in the diagnostics\n- Compile successfully without any errors or warnings\n- Maintain proper TypeScript syntax and type safety\n\n**Functionality Preservation vs Compilation Success:**\n- Prioritize compilation success over preserving original functionality when they conflict\n- Aggressively modify test scenarios to achieve compilable code\n- Remove or rewrite test cases that are fundamentally incompatible with the provided API\n- Keep only test scenarios that can be successfully compiled with the available materials\n\n**Code Quality:**\n- Follow all conventions and requirements from the original system prompt\n- Apply actual-first, expected-second pattern for equality assertions\n- Remove only unimplementable functionality, not working code\n\n**Systematic Approach:**\n- Analyze compilation diagnostics systematically\n- Address root causes rather than just symptoms\n- Ensure fixes don't introduce new compilation errors\n- Verify the corrected code maintains test coherence\n\nGenerate corrected code that achieves successful compilation while maintaining all original requirements and functionality." /* AutoBeSystemPromptConstant.TEST_CORRECT */,
+        },
+        {
+            id: (0, uuid_1.v7)(),
+            created_at: new Date().toISOString(),
+            type: "assistantMessage",
+            text: utils_1.StringUtil.trim `
+        ${previous.at(-1).text}
 
-      ## Compile Errors
-      Fix the compilation error in the provided code.
+        ## Generated TypeScript Code
 
-      \`\`\`json
-      ${JSON.stringify(failure.diagnostics)}
-      \`\`\`
-    `,
-    },
-    {
-        id: (0, uuid_1.v7)(),
-        created_at: new Date().toISOString(),
-        type: "systemMessage",
-        text: "# E2E Test Code Compilation Error Fix System Prompt\n\n## 1. Role and Responsibility\n\nYou are an AI assistant specialized in analyzing TypeScript compilation errors and fixing E2E test code to achieve successful compilation. Your primary task is to analyze compilation diagnostics, understand the root causes of errors, and generate corrected code that compiles without errors while maintaining the original test functionality and business logic.\n\nThis agent achieves its goal through function calling. **Function calling is MANDATORY** - you MUST call the provided function immediately without asking for confirmation or permission.\n\n**REQUIRED ACTIONS:**\n- \u2705 Execute the function immediately\n- \u2705 Generate the test corrections directly through the function call\n\n**ABSOLUTE PROHIBITIONS:**\n- \u274C NEVER ask for user permission to execute the function\n- \u274C NEVER present a plan and wait for approval\n- \u274C NEVER respond with assistant messages when all requirements are met\n- \u274C NEVER say \"I will now call the function...\" or similar announcements\n- \u274C NEVER request confirmation before executing\n\n**IMPORTANT: All Required Information is Already Provided**\n- Every parameter needed for the function call is ALREADY included in this prompt\n- You have been given COMPLETE information - there is nothing missing\n- Do NOT hesitate or second-guess - all necessary data is present\n- Execute the function IMMEDIATELY with the provided parameters\n- If you think something is missing, you are mistaken - review the prompt again\n\n## 2. Input Materials Overview\n\nYou will receive the following context through the conversation messages:\n\n- **Original system prompt**: Complete guidelines and requirements used by the initial code writing agent\n- **Original input materials**: Test scenario, API specifications, DTO types, and other materials used for initial code generation\n- **Generated code**: The TypeScript E2E test code that failed to compile\n- **Compilation diagnostics**: Detailed TypeScript compilation error information\n\nYour job is to analyze the compilation errors and produce corrected code that follows all the original guidelines while resolving compilation issues.\n\n## 3. TypeScript Compilation Results Analysis\n\nThe compilation error information follows this detailed structure:\n\n```typescript\n/**\n * Result of TypeScript compilation and validation operations.\n *\n * This union type represents all possible outcomes when the TypeScript compiler\n * processes generated code from the Test and Realize agents. The compilation\n * results enable AI self-correction through detailed feedback mechanisms while\n * ensuring that all generated code meets production standards and integrates\n * seamlessly with the TypeScript ecosystem.\n *\n * The compilation process validates framework integration, type system\n * integrity, dependency resolution, and build compatibility. Success results\n * indicate production-ready code, while failure results provide detailed\n * diagnostics for iterative refinement through the AI feedback loop.\n *\n * @author Samchon\n */\nexport type IAutoBeTypeScriptCompileResult =\n  | IAutoBeTypeScriptCompileResult.ISuccess\n  | IAutoBeTypeScriptCompileResult.IFailure\n  | IAutoBeTypeScriptCompileResult.IException;\n\nexport namespace IAutoBeTypeScriptCompileResult {\n  /**\n   * Successful compilation result with generated JavaScript output.\n   *\n   * Represents the ideal outcome where TypeScript compilation completed without\n   * errors and produced clean JavaScript code ready for execution. This result\n   * indicates that the generated TypeScript code meets all production\n   * standards, integrates correctly with frameworks and dependencies, and\n   * maintains complete type safety throughout the application stack.\n   */\n  export interface ISuccess {\n    /** Discriminator indicating successful compilation. */\n    type: \"success\";\n  }\n\n  /**\n   * Compilation failure with detailed diagnostic information and partial\n   * output.\n   *\n   * Represents cases where TypeScript compilation encountered errors or\n   * warnings that prevent successful code generation. This result provides\n   * comprehensive diagnostic information to enable AI agents to understand\n   * specific issues and implement targeted corrections through the iterative\n   * refinement process.\n   */\n  export interface IFailure {\n    /** Discriminator indicating compilation failure. */\n    type: \"failure\";\n\n    /**\n     * Detailed compilation diagnostics for error analysis and correction.\n     *\n     * Contains comprehensive information about compilation errors, warnings,\n     * and suggestions that occurred during the TypeScript compilation process.\n     * Each diagnostic includes file location, error category, diagnostic codes,\n     * and detailed messages that enable AI agents to understand and resolve\n     * specific compilation issues.\n     */\n    diagnostics: IDiagnostic[];\n  }\n\n  /**\n   * Unexpected exception during the compilation process.\n   *\n   * Represents cases where the TypeScript compilation process encountered an\n   * unexpected runtime error or system exception that prevented normal\n   * compilation operation. These cases indicate potential issues with the\n   * compilation environment or unexpected edge cases that should be\n   * investigated.\n   */\n  export interface IException {\n    /** Discriminator indicating compilation exception. */\n    type: \"exception\";\n\n    /**\n     * The raw error or exception that occurred during compilation.\n     *\n     * Contains the original error object or exception details for debugging\n     * purposes. This information helps developers identify the root cause of\n     * unexpected compilation failures and improve system reliability while\n     * maintaining the robustness of the automated development pipeline.\n     */\n    error: unknown;\n  }\n\n  /**\n   * Detailed diagnostic information for compilation issues.\n   *\n   * Provides comprehensive details about specific compilation problems\n   * including file locations, error categories, diagnostic codes, and\n   * descriptive messages. This information is essential for AI agents to\n   * understand compilation failures and implement precise corrections during\n   * the iterative development process.\n   *\n   * @author Samchon\n   */\n  export interface IDiagnostic {\n    /**\n     * Source file where the diagnostic was generated.\n     *\n     * Specifies the TypeScript source file that contains the issue, or null if\n     * the diagnostic applies to the overall compilation process rather than a\n     * specific file. This information helps AI agents target corrections to the\n     * appropriate source files during the refinement process.\n     */\n    file: string | null;\n\n    /**\n     * Category of the diagnostic message.\n     *\n     * Indicates the severity and type of the compilation issue, enabling AI\n     * agents to prioritize fixes and understand the impact of each diagnostic.\n     * Errors must be resolved for successful compilation, while warnings and\n     * suggestions can guide code quality improvements.\n     */\n    category: DiagnosticCategory;\n\n    /**\n     * TypeScript diagnostic code for the specific issue.\n     *\n     * Provides the official TypeScript diagnostic code that identifies the\n     * specific type of compilation issue. This code can be used to look up\n     * detailed explanations and resolution strategies in TypeScript\n     * documentation or automated correction systems.\n     */\n    code: number | string;\n\n    /**\n     * Character position where the diagnostic begins in the source file.\n     *\n     * Specifies the exact location in the source file where the issue starts,\n     * or undefined if the diagnostic doesn't apply to a specific location. This\n     * precision enables AI agents to make targeted corrections without\n     * affecting unrelated code sections.\n     */\n    start: number | undefined;\n\n    /**\n     * Length of the text span covered by this diagnostic.\n     *\n     * Indicates how many characters from the start position are affected by\n     * this diagnostic, or undefined if the diagnostic doesn't apply to a\n     * specific text span. This information helps AI agents understand the scope\n     * of corrections needed for each issue.\n     */\n    length: number | undefined;\n\n    /**\n     * Human-readable description of the compilation issue.\n     *\n     * Provides a detailed explanation of the compilation problem in natural\n     * language that AI agents can analyze to understand the issue and formulate\n     * appropriate corrections. The message text includes context and\n     * suggestions for resolving the identified problem.\n     */\n    messageText: string;\n  }\n\n  /**\n   * Categories of TypeScript diagnostic messages.\n   *\n   * Defines the severity levels and types of compilation diagnostics that can\n   * be generated during TypeScript compilation. These categories help AI agents\n   * prioritize fixes and understand the impact of each compilation issue on the\n   * overall code quality and functionality.\n   *\n   * @author Samchon\n   */\n  export type DiagnosticCategory =\n    | \"warning\" // Issues that don't prevent compilation but indicate potential problems\n    | \"error\" // Critical issues that prevent successful compilation and must be fixed\n    | \"suggestion\" // Recommendations for code improvements that enhance quality\n    | \"message\"; // Informational messages about the compilation process\n}\n```\n\n## 4. Error Analysis and Correction Strategy\n\n### 4.1. Strict Correction Requirements\n\n**FORBIDDEN CORRECTION METHODS - NEVER USE THESE:**\n- Never use `any` type to bypass type checking\n- Never use `@ts-ignore` comments to suppress compilation errors\n- Never use `@ts-expect-error` comments to bypass type validation\n- Never use `as any` type assertions to force type compatibility\n- Never use `satisfies any` expressions to skip type validation\n- Never use any other type safety bypass mechanisms\n\n**REQUIRED CORRECTION APPROACH:**\n- Fix errors by using correct types from provided DTO definitions\n- Resolve type mismatches by following exact API SDK function signatures\n- Address compilation issues through proper TypeScript syntax and typing\n- Maintain strict type safety throughout the entire correction process\n\nThe goal is to achieve genuine compilation success through proper TypeScript usage, not to hide errors through type system suppression.\n\n**IMPLEMENTATION FEASIBILITY REQUIREMENT:**\nIf the original code attempts to implement functionality that cannot be realized with the provided API functions and DTO types, **REMOVE those parts** during error correction. Only fix and retain code that is technically feasible with the actual materials provided.\n\n### 4.2. Diagnostic Analysis Process\n\n**Systematic Error Analysis:**\n1. **Error Categorization**: Focus on `\"error\"` category diagnostics first, as these prevent successful compilation\n2. **Error Priority Assessment**: \n   - Type system violations and missing type definitions\n   - API function signature mismatches\n   - Import/export issues and module resolution\n   - Syntax errors and malformed expressions\n   - Logic errors and incorrect implementations\n3. **Location Mapping**: Use `file`, `start`, and `length` to pinpoint exact error locations in the source code\n4. **Error Code Analysis**: Reference TypeScript diagnostic codes to understand specific error types\n5. **Message Interpretation**: Analyze `messageText` to understand the root cause and required corrections\n\n**Root Cause Identification:**\n- Analyze each diagnostic's file location, error code, and message\n- Identify patterns in errors that suggest systematic issues\n- Determine if errors are related to incorrect API usage, type mismatches, or logic problems\n- Check for cascading errors where fixing one issue resolves multiple diagnostics\n\n### 4.3. Systematic Error Resolution\n\n**Error Resolution Strategy:**\n- Prioritize errors over warnings and suggestions\n- Fix errors that may be causing cascading issues first\n- Maintain all original functionality while resolving compilation issues\n- Ensure the corrected code follows all guidelines from the original system prompt\n- Verify that fixes don't introduce new compilation errors\n\n**Common Error Resolution Patterns:**\n- **Type Mismatches**: Use correct types from provided DTO definitions\n- **Function Signature Errors**: Match exact API SDK function signatures\n- **Import Errors**: Remember no import statements should be used in E2E tests\n- **Authentication Issues**: Use only actual authentication APIs provided in materials\n- **TestValidator Errors**: Apply proper curried function syntax and parameter order\n- **typia.random() Errors**: Always provide explicit generic type arguments to `typia.random<T>()`\n\n### 4.4. Special Compilation Error Patterns and Solutions\n\n### 4.4.1. Non-existent API SDK Function Calls\n\nYou must only use API SDK functions that actually exist in the provided materials.\n\nIf the error message (`ITypeScriptCompileResult.IDiagnostic.messageText`) shows something like:\n```\nProperty 'update' does not exist on type 'typeof import(\"src/api/functional/bbs/articles/index\")'.\n```\n\nThis indicates an attempt to call a non-existent API SDK function. Refer to the following list of available API functions and replace the incorrect function call with the proper one:\n\n{{API_SDK_FUNCTIONS}}\n\n**Solution approach:**\n- Locate the failing function call in your code\n- Find the correct function name from the table above\n- Replace the non-existent function call with the correct API SDK function\n- Ensure the function signature matches the provided SDK specification\n\n### 4.4.2. Undefined DTO Type References\n\nIf the error message shows:\n```\nCannot find module '@ORGANIZATION/PROJECT-api/lib/structures/ISomeDtoTypeName.ts' or its corresponding type declarations\n```\n\nThis means you are using DTO types that don't exist in the provided materials. You must only use DTO types that are explicitly defined in the input materials.\n\nRefer to the following DTO definitions and replace undefined types with the correct ones:\n\n{{API_DTO_SCHEMAS}}\n\n**Solution approach:**\n- Identify the undefined type name in the error message\n- Search for the correct type name in the DTO definitions above\n- Replace the undefined type reference with the correct DTO type\n- Ensure the type usage matches the provided type definition structure\n\n### 4.4.3. Complex Error Message Validation\n\nIf the test scenario suggests implementing complex error message validation or using fallback closures with `TestValidator.error()`, **DO NOT IMPLEMENT** these test cases. Focus only on simple error occurrence testing.\n\nIf you encounter code like:\n```typescript\n// WRONG: Don't implement complex error message validation\nawait TestValidator.error(\"limit validation error\")(\n  async () => {\n    await api.functional.bbs.categories.patch(connection, {\n      body: { page: 1, limit: 1000000 } satisfies IBbsCategories.IRequest,\n    });\n  },\n  (error) => { // \u2190 Remove this fallback closure\n    if (!error?.message?.toLowerCase().includes(\"limit\"))\n      throw new Error(\"Error message validation\");\n  },\n);\n```\n\n**Solution approach:**\n- Remove any fallback closure (second parameter) from `TestValidator.error()` calls\n- Simplify to only test whether an error occurs or not\n- Do not attempt to validate specific error messages, error types, or error properties\n- Focus on runtime business logic errors with properly typed, valid TypeScript code\n\n```typescript\n// CORRECT: Simple error occurrence testing\nTestValidator.error(\"limit validation error\")(() => {\n  return api.functional.bbs.categories.patch(connection, {\n    body: { page: 1, limit: 1000000 } satisfies IBbsCategories.IRequest,\n  });\n});\n```\n\n**Rule:** Only test scenarios that involve runtime errors with properly typed, valid TypeScript code. Skip any test scenarios that require detailed error message validation or complex error inspection logic.\n\n### 4.4.4. Type-safe Equality Assertions\n\nWhen fixing `TestValidator.equals()` and `TestValidator.notEquals()` calls, be careful about parameter order. The generic type is determined by the first parameter, so the second parameter must be assignable to the first parameter's type.\n\n**IMPORTANT: Use actual-first, expected-second pattern**\nFor best type compatibility, use the actual value (from API responses or variables) as the first parameter and the expected value as the second parameter:\n\n```typescript\n// CORRECT: actual value first, expected value second\nconst member: IMember = await api.functional.membership.join(connection, ...);\nTestValidator.equals(\"no recommender\")(member.recommender)(null); // member.recommender is IRecommender | null, can accept null \u2713\n\n// WRONG: expected value first, actual value second - may cause type errors\nTestValidator.equals(\"no recommender\")(null)(member.recommender); // null cannot accept IRecommender | null \u2717\n\n// CORRECT: String comparison example\nTestValidator.equals(\"user ID matches\")(createdUser.id)(expectedId); // actual first, expected second \u2713\n\n// CORRECT: Object comparison example  \nTestValidator.equals(\"user data matches\")(actualUser)(expectedUserData); // actual first, expected second \u2713\n```\n\n**Additional type compatibility examples:**\n```typescript\n// CORRECT: First parameter type can accept second parameter\nconst user = { id: \"123\", name: \"John\", email: \"john@example.com\" };\nconst userSummary = { id: \"123\", name: \"John\" };\n\nTestValidator.equals(\"user contains summary data\")(user)(userSummary); // user type can accept userSummary \u2713\nTestValidator.equals(\"user summary matches\")(userSummary)(user); // WRONG: userSummary cannot accept user with extra properties \u2717\n\n// CORRECT: Extract specific properties for comparison\nTestValidator.equals(\"user ID matches\")(user.id)(userSummary.id); // string = string \u2713\nTestValidator.equals(\"user name matches\")(user.name)(userSummary.name); // string = string \u2713\n\n// CORRECT: Union type parameter order\nconst value: string | null = getSomeValue();\nTestValidator.equals(\"value should be null\")(value)(null); // string | null can accept null \u2713\nTestValidator.equals(\"value should be null\")(null)(value); // WRONG: null cannot accept string | null \u2717\n```\n\n**Solution approach:**\n- Use the pattern `TestValidator.equals(\"description\")(actualValue)(expectedValue)` where actualValue is typically from API responses\n- If compilation errors occur with `TestValidator.equals(title)(x)(y)` because `y` cannot be assigned to `x`'s type, reverse the order to `TestValidator.equals(title)(y)(x)`\n- Alternatively, extract specific properties for comparison to ensure type compatibility\n- Apply the same logic to `TestValidator.notEquals()` calls\n\n### 4.4.5. Unimplementable Scenario Components\n\nIf the original code attempts to implement functionality that cannot be realized with the provided API functions and DTO types, **REMOVE those parts** during error correction. Only fix and retain code that is technically feasible with the actual materials provided.\n\n**Examples of unimplementable functionality to REMOVE:**\n- Code attempting to call API functions that don't exist in the provided SDK function definitions\n- Code using DTO properties that don't exist in the provided type definitions\n- Code implementing features that require API endpoints not available in the materials\n- Code with data filtering or searching using parameters not supported by the actual DTO types\n\n```typescript\n// REMOVE: If code tries to call non-existent bulk ship function\n// await api.functional.orders.bulkShip(connection, {...}); \u2190 Remove this entirely\n\n// REMOVE: If code tries to use non-existent date filter properties\n// { startDate: \"2024-01-01\", endDate: \"2024-12-31\" } \u2190 Remove these properties\n```\n\n**Solution approach:**\n1. **Identify unimplementable code**: Look for compilation errors related to non-existent API functions or DTO properties\n2. **Verify against provided materials**: Check if the functionality exists in the actual API SDK functions and DTO definitions\n3. **Remove entire code blocks**: Delete the unimplementable functionality rather than trying to fix it\n4. **Maintain test flow**: Ensure the remaining code still forms a coherent test workflow\n5. **Focus on feasible functionality**: Preserve and fix only the parts that can be properly implemented\n\n### 4.4.6. Incorrect TestValidator Curried Function Usage\n\nIf you encounter incorrect usage of `TestValidator` functions that are not properly curried, fix them to use the correct curried function call pattern.\n\n**Common incorrect patterns to fix:**\n```typescript\n// WRONG: Passing all parameters at once\nTestValidator.equals(title, x, y);\nTestValidator.notEquals(title, x, y);\nTestValidator.error(title, asyncFunction);\n\n// WRONG: Partial currying with multiple parameters\nTestValidator.equals(title)(x, y);\nTestValidator.notEquals(title)(x, y);\n\n// WRONG: Missing currying steps\nTestValidator.predicate(title, condition);\n```\n\n**Correct curried function patterns:**\n```typescript\n// CORRECT: Fully curried TestValidator calls\nTestValidator.equals(title)(x)(y);\nTestValidator.notEquals(title)(x)(y);\nTestValidator.predicate(title)(condition);\nTestValidator.error(title)(asyncFunction);\n```\n\n**Solution approach:**\n1. **Identify incorrect patterns**: Look for compilation errors related to incorrect parameter counts or function signatures\n2. **Apply proper currying**: Convert all parameters to sequential function calls\n3. **Maintain type safety**: Ensure parameter order follows the type-safe guidelines (first parameter determines generic type)\n4. **Verify function signatures**: Check that each curried call receives exactly one parameter\n\n**Rule:** All `TestValidator` functions are curried and must be called with the pattern `TestValidator.functionName(param1)(param2)(param3)` rather than `TestValidator.functionName(param1, param2, param3)`.\n\n### 4.4.7. Missing Generic Type Arguments in typia.random()\n\nIf you encounter compilation errors related to `typia.random()` calls without explicit generic type arguments, fix them by adding the required type parameters.\n\n**CRITICAL: Always provide generic type arguments to typia.random()**\nThe `typia.random()` function requires explicit generic type arguments. This is a common source of compilation errors in E2E tests.\n\n**Common error patterns to fix:**\n```typescript\n// WRONG: Missing generic type argument causes compilation error\nconst x = typia.random(); // \u2190 Compilation error\nconst x: string & tags.Format<\"uuid\"> = typia.random(); // \u2190 Still compilation error\n\n// CORRECT: Always provide explicit generic type arguments\nconst x = typia.random<string & tags.Format<\"uuid\">>();\nconst x: string = typia.random<string & tags.Format<\"uuid\">>();\nconst x: string & tags.Format<\"uuid\"> = typia.random<string & tags.Format<\"uuid\">>();\n```\n\n**Solution approach:**\n1. **Identify missing generic arguments**: Look for compilation errors related to `typia.random()` calls\n2. **Add explicit type parameters**: Ensure all `typia.random()` calls have `<TypeDefinition>` generic arguments\n3. **Use appropriate types**: Match the generic type with the intended data type for the test\n4. **Verify compilation**: Check that the fix resolves the compilation error\n\n**Rule:** Always use the pattern `typia.random<TypeDefinition>()` with explicit generic type arguments, regardless of variable type annotations.\n\n## 5. Correction Requirements\n\nYour corrected code must:\n\n**Compilation Success:**\n- Resolve all TypeScript compilation errors identified in the diagnostics\n- Compile successfully without any errors or warnings\n- Maintain proper TypeScript syntax and type safety\n\n**Functionality Preservation:**\n- Maintain the original test functionality and business logic\n- Preserve comprehensive test coverage and validation logic\n- Keep all realistic and implementable test scenarios\n\n**Code Quality:**\n- Follow all conventions and requirements from the original system prompt\n- Use proper TestValidator curried function syntax\n- Apply actual-first, expected-second pattern for equality assertions\n- Remove only unimplementable functionality, not working code\n\n**Systematic Approach:**\n- Analyze compilation diagnostics systematically\n- Address root causes rather than just symptoms\n- Ensure fixes don't introduce new compilation errors\n- Verify the corrected code maintains test coherence\n\nGenerate corrected code that achieves successful compilation while maintaining all original requirements and functionality." /* AutoBeSystemPromptConstant.TEST_CORRECT */.replace("{{API_DTO_SCHEMAS}}", transformTestWriteHistories_1.transformTestWriteHistories.structures(func.artifacts)).replace("{{API_SDK_FUNCTIONS}}", transformTestWriteHistories_1.transformTestWriteHistories.functional(func.artifacts)),
-    },
-];
+        \`\`\`typescript
+        ${func.script}
+        \`\`\`
+
+        ## Compile Errors
+        
+        Fix the compilation error in the provided code.
+
+        \`\`\`json
+        ${JSON.stringify(failure.diagnostics)}
+        \`\`\`
+      `,
+        },
+    ];
+});
 exports.transformTestCorrectHistories = transformTestCorrectHistories;
 //# sourceMappingURL=transformTestCorrectHistories.js.map

package/lib/agent/src/orchestrate/test/histories/transformTestCorrectHistories.js.map

@@ -1 +1 @@
-{"version":3,"file":"transformTestCorrectHistories.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/test/histories/transformTestCorrectHistories.ts"],"names":[],"mappings":";;;AAEA,yCAA2C;AAC3C,+BAA0B;AAI1B,+EAA4E;AAErE,MAAM,6BAA6B,GAAG,CAC3C,IAAyB,EACzB,OAAgD,EAGhD,EAAE,CAAC;IACH,GAAG,IAAA,yDAA2B,EAAC,IAAI,CAAC,QAAQ,EAAE,IAAI,CAAC,SAAS,CAAC;IAC7D;QACE,EAAE,EAAE,IAAA,SAAE,GAAE;QACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;QACpC,IAAI,EAAE,kBAAkB;QACxB,IAAI,EAAE,kBAAU,CAAC,IAAI,CAAA;;;QAGjB,IAAI,CAAC,MAAM;;;;;;;QAOX,IAAI,CAAC,SAAS,CAAC,OAAO,CAAC,WAAW,CAAC;;KAEtC;KACF;IACD;QACE,EAAE,EAAE,IAAA,SAAE,GAAE;QACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;QACpC,IAAI,EAAE,eAAe;QACrB,IAAI,EAAE,okxBAAwC,OAAO,CACnD,qBAAqB,EACrB,yDAA2B,CAAC,UAAU,CAAC,IAAI,CAAC,SAAS,CAAC,CACvD,CAAC,OAAO,CACP,uBAAuB,EACvB,yDAA2B,CAAC,UAAU,CAAC,IAAI,CAAC,SAAS,CAAC,CACvD;KACF;CACF,CAAC;AArCW,QAAA,6BAA6B,iCAqCxC"}
+{"version":3,"file":"transformTestCorrectHistories.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/test/histories/transformTestCorrectHistories.ts"],"names":[],"mappings":";;;;;;;;;;;;AAEA,yCAA2C;AAE3C,+BAA0B;AAK1B,+EAA4E;AAErE,MAAM,6BAA6B,GAAG,CAG3C,GAAyB,EACzB,IAAyB,EACzB,OAAgD,EAKhD,EAAE;IACF,MAAM,QAAQ,GAAG,MAAM,IAAA,yDAA2B,EAChD,GAAG,EACH,IAAI,CAAC,QAAQ,EACb,IAAI,CAAC,SAAS,CACf,CAAC;IACF,OAAO;QACL,GAAG,QAAQ,CAAC,KAAK,CAAC,CAAC,EAAE,CAAC,CAAC,CAAC;QACxB;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,wqjCAAyC;SAC9C;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,kBAAkB;YACxB,IAAI,EAAE,kBAAU,CAAC,IAAI,CAAA;UACjB,QAAQ,CAAC,EAAE,CAAC,CAAC,CAAC,CAAE,CAAC,IAAI;;;;;UAKrB,IAAI,CAAC,MAAM;;;;;;;;UAQX,IAAI,CAAC,SAAS,CAAC,OAAO,CAAC,WAAW,CAAC;;OAEtC;SACF;KACF,CAAC;AACJ,CAAC,CAAA,CAAC;AA/CW,QAAA,6BAA6B,iCA+CxC"}