@autobe/agent 0.18.0 → 0.20.0

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

@@ -47,16 +47,18 @@ var __importDefault = (this && this.__importDefault) || function (mod) {
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.orchestrateRealizeCorrect = orchestrateRealizeCorrect;
 const __typia_transform__validateReport = __importStar(require("typia/lib/internal/_validateReport.js"));
+const utils_1 = require("@autobe/utils");
 const typia_1 = __importDefault(require("typia"));
+const uuid_1 = require("uuid");
 const assertSchemaModel_1 = require("../../context/assertSchemaModel");
 const getTestScenarioArtifacts_1 = require("../test/compile/getTestScenarioArtifacts");
 const transformRealizeCorrectHistories_1 = require("./histories/transformRealizeCorrectHistories");
 const replaceImportStatements_1 = require("./utils/replaceImportStatements");
-function orchestrateRealizeCorrect(ctx, authorization, scenario, code, diagnostic, progress) {
+function orchestrateRealizeCorrect(ctx, props) {
     return __awaiter(this, void 0, void 0, function* () {
-        var _a, _b;
+        var _a, _b, _c;
         const artifacts = yield (0, getTestScenarioArtifacts_1.getTestScenarioArtifacts)(ctx, {
-            endpoint: scenario.operation,
+            endpoint: props.scenario.operation,
             dependencies: [],
         });
         const pointer = {
@@ -72,29 +74,32 @@ function orchestrateRealizeCorrect(ctx, authorization, scenario, code, diagnosti
             }),
             histories: (0, transformRealizeCorrectHistories_1.transformRealizeCorrectHistories)({
                 state: ctx.state(),
-                scenario,
+                scenario: props.scenario,
                 artifacts,
-                authorization,
-                code,
-                diagnostic,
+                authorization: props.authorization,
+                code: props.code,
+                diagnostic: props.diagnostic,
+                totalAuthorizations: props.totalAuthorizations,
             }),
             enforceFunctionCall: true,
-            message: [
-                `Correct the TypeScript code implementation to strictly follow these rules:`,
-                `1. Ensure that the code is production-ready and follows best practices.`,
-            ].join("\n"),
+            message: utils_1.StringUtil.trim `
+      Correct the TypeScript code implementation to strictly follow these rules:
+      
+      1. Ensure that the code is production-ready and follows best practices.
+    `,
         });
         if (pointer.value === null)
             throw new Error("Failed to correct implementation code.");
-        pointer.value.implementationCode = yield (0, replaceImportStatements_1.replaceImportStatements)(ctx)(artifacts, pointer.value.implementationCode, authorization === null || authorization === void 0 ? void 0 : authorization.payload.name);
+        pointer.value.implementationCode = yield (0, replaceImportStatements_1.replaceImportStatements)(ctx)(artifacts, pointer.value.implementationCode, (_a = props.authorization) === null || _a === void 0 ? void 0 : _a.payload.name);
         const event = {
             type: "realizeCorrect",
-            location: scenario.location,
+            id: (0, uuid_1.v7)(),
+            location: props.scenario.location,
             content: pointer.value.implementationCode,
             tokenUsage,
-            completed: ++progress.completed,
-            total: progress.total,
-            step: (_b = (_a = ctx.state().analyze) === null || _a === void 0 ? void 0 : _a.step) !== null && _b !== void 0 ? _b : 0,
+            completed: ++props.progress.completed,
+            total: props.progress.total,
+            step: (_c = (_b = ctx.state().analyze) === null || _b === void 0 ? void 0 : _b.step) !== null && _c !== void 0 ? _c : 0,
             created_at: new Date().toISOString(),
         };
         ctx.dispatch(event);
@@ -133,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 MUST follow MANDATORY SCHEMA-FIRST APPROACH:\n\n\uD83D\uDCCB STEP 1 - PRISMA SCHEMA VERIFICATION (MOST CRITICAL):\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 (e.g., \"Note: deleted_at field\n  DOES NOT EXIST\")\n- Common assumption errors to avoid: `deleted_at`, `created_by`,\n  `updated_by`, `is_deleted`, `is_active`\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- 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",
                         type: "string"
                     },
                     prisma_schemas: {
@@ -141,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. CRITICAL: This draft must NEVER use the native Date\ntype.\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\n\u26A0\uFE0F Import rules:\n\n- Do NOT add any new import statements manually.\n- All necessary imports are provided globally or by the system\n  automatically.\n- Writing import statements directly is prohibited and may cause compile\n  errors. If import errors occur, check your environment configuration.\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- 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.",
                         type: "string"
                     },
                     review: {
@@ -248,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 MUST follow MANDATORY SCHEMA-FIRST APPROACH:\n\n\uD83D\uDCCB STEP 1 - PRISMA SCHEMA VERIFICATION (MOST CRITICAL):\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 (e.g., \"Note: deleted_at field\n  DOES NOT EXIST\")\n- Common assumption errors to avoid: `deleted_at`, `created_by`,\n  `updated_by`, `is_deleted`, `is_active`\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- 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",
                             type: "string"
                         },
                         prisma_schemas: {
@@ -256,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. CRITICAL: This draft must NEVER use the native Date\ntype.\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\n\u26A0\uFE0F Import rules:\n\n- Do NOT add any new import statements manually.\n- All necessary imports are provided globally or by the system\n  automatically.\n- Writing import statements directly is prohibited and may cause compile\n  errors. If import errors occur, check your environment configuration.\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- 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.",
                             type: "string"
                         },
                         review: {

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

@@ -1 +1 @@
-{"version":3,"file":"orchestrateRealizeCorrect.js","sourceRoot":"","sources":["../../../../../src/orchestrate/realize/orchestrateRealizeCorrect.ts"],"names":[],"mappings":";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;AAkBA,8DA6DC;;AAxED,kDAA0B;AAG1B,uEAAoE;AACpE,uFAAoF;AAEpF,mGAAgG;AAGhG,6EAA0E;AAE1E,SAAsB,yBAAyB,CAC7C,GAAyB,EACzB,aAAgD,EAChD,QAAkD,EAClD,IAAY,EACZ,UAAsD,EACtD,QAAmB;;;QAEnB,MAAM,SAAS,GACb,MAAM,IAAA,mDAAwB,EAAC,GAAG,EAAE;YAClC,QAAQ,EAAE,QAAQ,CAAC,SAAS;YAC5B,YAAY,EAAE,EAAE;SACjB,CAAC,CAAC;QAEL,MAAM,OAAO,GAA6D;YACxE,KAAK,EAAE,IAAI;SACZ,CAAC;QACF,MAAM,EAAE,UAAU,EAAE,GAAG,MAAM,GAAG,CAAC,UAAU,CAAC;YAC1C,MAAM,EAAE,gBAAgB;YACxB,UAAU,EAAE,gBAAgB,CAAC;gBAC3B,KAAK,EAAE,GAAG,CAAC,KAAK;gBAChB,KAAK,EAAE,CAAC,IAAI,EAAE,EAAE;oBACd,OAAO,CAAC,KAAK,GAAG,IAAI,CAAC;gBACvB,CAAC;aACF,CAAC;YACF,SAAS,EAAE,IAAA,mEAAgC,EAAC;gBAC1C,KAAK,EAAE,GAAG,CAAC,KAAK,EAAE;gBAClB,QAAQ;gBACR,SAAS;gBACT,aAAa;gBACb,IAAI;gBACJ,UAAU;aACX,CAAC;YACF,mBAAmB,EAAE,IAAI;YACzB,OAAO,EAAE;gBACP,4EAA4E;gBAC5E,yEAAyE;aAC1E,CAAC,IAAI,CAAC,IAAI,CAAC;SACb,CAAC,CAAC;QAEH,IAAI,OAAO,CAAC,KAAK,KAAK,IAAI;YACxB,MAAM,IAAI,KAAK,CAAC,wCAAwC,CAAC,CAAC;QAE5D,OAAO,CAAC,KAAK,CAAC,kBAAkB,GAAG,MAAM,IAAA,iDAAuB,EAAC,GAAG,CAAC,CACnE,SAAS,EACT,OAAO,CAAC,KAAK,CAAC,kBAAkB,EAChC,aAAa,aAAb,aAAa,uBAAb,aAAa,CAAE,OAAO,CAAC,IAAI,CAC5B,CAAC;QAEF,MAAM,KAAK,GAA8B;YACvC,IAAI,EAAE,gBAAgB;YACtB,QAAQ,EAAE,QAAQ,CAAC,QAAQ;YAC3B,OAAO,EAAE,OAAO,CAAC,KAAK,CAAC,kBAAkB;YACzC,UAAU;YACV,SAAS,EAAE,EAAE,QAAQ,CAAC,SAAS;YAC/B,KAAK,EAAE,QAAQ,CAAC,KAAK;YACrB,IAAI,EAAE,MAAA,MAAA,GAAG,CAAC,KAAK,EAAE,CAAC,OAAO,0CAAE,IAAI,mCAAI,CAAC;YACpC,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;SACrC,CAAC;QACF,GAAG,CAAC,QAAQ,CAAC,KAAK,CAAC,CAAC;QACpB,OAAO,KAAK,CAAC;IACf,CAAC;CAAA;AAED,SAAS,gBAAgB,CAAiC,KAGzD;IACC,IAAA,qCAAiB,EAAC,KAAK,CAAC,KAAK,CAAC,CAAC;IAC/B,MAAM,WAAW,GAA2B,UAAU,CACpD,KAAK,CAAC,KAAK,CACwD,CAAC;IAEtE,OAAO;QACL,QAAQ,EAAE,OAAO;QACjB,IAAI,EAAE,YAAY;QAClB,WAAW;QACX,OAAO,EAAE;YACP,MAAM,EAAE,CAAC,IAAI,EAAE,EAAE;gBACf,KAAK,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC;YACpB,CAAC;SACyC;KAC7C,CAAC;AACJ,CAAC;AAED,MAAM,MAAM;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAGT,CAAC;AACJ,MAAM,UAAU,GAAG;IACjB,OAAO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;KAAsE;IAC7E,MAAM;IACN,KAAK,EAAE,MAAM;IACb,QAAQ,EAAE,MAAM;IAChB,KAAK,EAAE,MAAM;CACd,CAAC"}
+{"version":3,"file":"orchestrateRealizeCorrect.js","sourceRoot":"","sources":["../../../../../src/orchestrate/realize/orchestrateRealizeCorrect.ts"],"names":[],"mappings":";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;AAqBA,8DAmEC;;AAlFD,yCAA2C;AAG3C,kDAA0B;AAC1B,+BAA0B;AAG1B,uEAAoE;AACpE,uFAAoF;AAEpF,mGAAgG;AAGhG,6EAA0E;AAE1E,SAAsB,yBAAyB,CAC7C,GAAyB,EACzB,KAOC;;;QAED,MAAM,SAAS,GACb,MAAM,IAAA,mDAAwB,EAAC,GAAG,EAAE;YAClC,QAAQ,EAAE,KAAK,CAAC,QAAQ,CAAC,SAAS;YAClC,YAAY,EAAE,EAAE;SACjB,CAAC,CAAC;QAEL,MAAM,OAAO,GAA6D;YACxE,KAAK,EAAE,IAAI;SACZ,CAAC;QACF,MAAM,EAAE,UAAU,EAAE,GAAG,MAAM,GAAG,CAAC,UAAU,CAAC;YAC1C,MAAM,EAAE,gBAAgB;YACxB,UAAU,EAAE,gBAAgB,CAAC;gBAC3B,KAAK,EAAE,GAAG,CAAC,KAAK;gBAChB,KAAK,EAAE,CAAC,IAAI,EAAE,EAAE;oBACd,OAAO,CAAC,KAAK,GAAG,IAAI,CAAC;gBACvB,CAAC;aACF,CAAC;YACF,SAAS,EAAE,IAAA,mEAAgC,EAAC;gBAC1C,KAAK,EAAE,GAAG,CAAC,KAAK,EAAE;gBAClB,QAAQ,EAAE,KAAK,CAAC,QAAQ;gBACxB,SAAS;gBACT,aAAa,EAAE,KAAK,CAAC,aAAa;gBAClC,IAAI,EAAE,KAAK,CAAC,IAAI;gBAChB,UAAU,EAAE,KAAK,CAAC,UAAU;gBAC5B,mBAAmB,EAAE,KAAK,CAAC,mBAAmB;aAC/C,CAAC;YACF,mBAAmB,EAAE,IAAI;YACzB,OAAO,EAAE,kBAAU,CAAC,IAAI,CAAA;;;;KAIvB;SACF,CAAC,CAAC;QAEH,IAAI,OAAO,CAAC,KAAK,KAAK,IAAI;YACxB,MAAM,IAAI,KAAK,CAAC,wCAAwC,CAAC,CAAC;QAE5D,OAAO,CAAC,KAAK,CAAC,kBAAkB,GAAG,MAAM,IAAA,iDAAuB,EAAC,GAAG,CAAC,CACnE,SAAS,EACT,OAAO,CAAC,KAAK,CAAC,kBAAkB,EAChC,MAAA,KAAK,CAAC,aAAa,0CAAE,OAAO,CAAC,IAAI,CAClC,CAAC;QAEF,MAAM,KAAK,GAA8B;YACvC,IAAI,EAAE,gBAAgB;YACtB,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,QAAQ,EAAE,KAAK,CAAC,QAAQ,CAAC,QAAQ;YACjC,OAAO,EAAE,OAAO,CAAC,KAAK,CAAC,kBAAkB;YACzC,UAAU;YACV,SAAS,EAAE,EAAE,KAAK,CAAC,QAAQ,CAAC,SAAS;YACrC,KAAK,EAAE,KAAK,CAAC,QAAQ,CAAC,KAAK;YAC3B,IAAI,EAAE,MAAA,MAAA,GAAG,CAAC,KAAK,EAAE,CAAC,OAAO,0CAAE,IAAI,mCAAI,CAAC;YACpC,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;SACrC,CAAC;QACF,GAAG,CAAC,QAAQ,CAAC,KAAK,CAAC,CAAC;QACpB,OAAO,KAAK,CAAC;IACf,CAAC;CAAA;AAED,SAAS,gBAAgB,CAAiC,KAGzD;IACC,IAAA,qCAAiB,EAAC,KAAK,CAAC,KAAK,CAAC,CAAC;IAC/B,MAAM,WAAW,GAA2B,UAAU,CACpD,KAAK,CAAC,KAAK,CACwD,CAAC;IAEtE,OAAO;QACL,QAAQ,EAAE,OAAO;QACjB,IAAI,EAAE,YAAY;QAClB,WAAW;QACX,OAAO,EAAE;YACP,MAAM,EAAE,CAAC,IAAI,EAAE,EAAE;gBACf,KAAK,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC;YACpB,CAAC;SACyC;KAC7C,CAAC;AACJ,CAAC;AAED,MAAM,MAAM;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAGT,CAAC;AACJ,MAAM,UAAU,GAAG;IACjB,OAAO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;KAAsE;IAC7E,MAAM;IACN,KAAK,EAAE,MAAM;IACb,QAAQ,EAAE,MAAM;IAChB,KAAK,EAAE,MAAM;CACd,CAAC"}

package/lib/agent/src/orchestrate/realize/orchestrateRealizeScenario.d.ts

@@ -2,72 +2,6 @@ import { AutoBeOpenApi, AutoBeRealizeAuthorization } from "@autobe/interface";
 import { ILlmSchema } from "@samchon/openapi";
 import { AutoBeContext } from "../../context/AutoBeContext";
 import { IAutoBeRealizeScenarioApplication } from "./structures/IAutoBeRealizeScenarioApplication";
-export interface IAutoBeRealizeScenario {
-    /**
-     * The name of the function to be generated.
-     *
-     * Derived from the Swagger path and method. The function name must be written
-     * in snake_case. It serves as the entry point in both code generation and
-     * test code.
-     *
-     * Once the function is generated, the function name and file name will be the
-     * same. The generated file will be located at
-     * `src/providers/${function_name}.ts`.
-     */
-    functionName: string;
-    /**
-     * Definition of path and query parameters extracted from the OpenAPI spec.
-     *
-     * Includes input values passed via URL path or query string. Used for type
-     * definitions, validation, and function signature construction.
-     */
-    parameters: AutoBeOpenApi.IParameter[];
-    /**
-     * Schema definition for the request body input.
-     *
-     * Extracted from the requestBody section of Swagger. Represents the input
-     * data passed in the body (e.g., JSON). Used for generating function
-     * arguments or DTOs.
-     */
-    inputSchema: AutoBeOpenApi.IRequestBody | null;
-    /**
-     * Schema definition for the response body.
-     *
-     * Extracted from the responses section of Swagger. Used to define the return
-     * type and expected output in test code.
-     */
-    outputSchema: AutoBeOpenApi.IResponseBody | null;
-    /**
-     * Natural language description of the function’s purpose.
-     *
-     * Extracted from the summary or description field of Swagger. Used for code
-     * documentation, test scenario generation, and conveying function intent.
-     */
-    description: string;
-    /**
-     * HTTP method information.
-     *
-     * Extracted from the Swagger operation method. Used to define the request
-     * type during code and test generation.
-     */
-    method: "get" | "post" | "put" | "delete" | "patch";
-    /**
-     * List of scenario descriptions for test code generation.
-     *
-     * Each scenario describes the expected behavior of the function under certain
-     * conditions. Used as a basis for TDD-style automated test generation.
-     */
-    testScenarios: string[];
-    /**
-     * Optional decorator event for customizing code generation behavior.
-     *
-     * Provides additional metadata or instructions that can modify how the
-     * function implementation is generated. Can include custom annotations,
-     * middleware configurations, or special handling directives that affect the
-     * final code output.
-     */
-    decoratorEvent?: AutoBeRealizeAuthorization;
-}
 /**
  * Generates a planning result that defines what kind of function should be
  * created, based solely on the provided Swagger (OpenAPI) operation — without

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":";;;AAgFA;;;;;;;;;;;;;;;;;;;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":";;;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"}

package/lib/agent/src/orchestrate/realize/orchestrateRealizeWrite.d.ts

@@ -1,9 +1,11 @@
-import { AutoBeRealizeAuthorization, AutoBeRealizeWriteEvent } from "@autobe/interface";
+import { AutoBeProgressEventBase, AutoBeRealizeAuthorization, AutoBeRealizeWriteEvent } from "@autobe/interface";
 import { ILlmSchema } from "@samchon/openapi";
 import { AutoBeContext } from "../../context/AutoBeContext";
 import { IAutoBeRealizeScenarioApplication } from "./structures/IAutoBeRealizeScenarioApplication";
-export declare function orchestrateRealizeWrite<Model extends ILlmSchema.Model>(ctx: AutoBeContext<Model>, authorization: AutoBeRealizeAuthorization | null, scenario: IAutoBeRealizeScenarioApplication.IProps, progress: IProgress): Promise<AutoBeRealizeWriteEvent>;
-export interface IProgress {
-    total: number;
-    completed: number;
-}
+export declare function orchestrateRealizeWrite<Model extends ILlmSchema.Model>(ctx: AutoBeContext<Model>, props: {
+    totalAuthorizations: AutoBeRealizeAuthorization[];
+    authorization: AutoBeRealizeAuthorization | null;
+    scenario: IAutoBeRealizeScenarioApplication.IProps;
+    progress: AutoBeProgressEventBase;
+    promptCacheKey: string;
+}): Promise<AutoBeRealizeWriteEvent>;

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

@@ -47,16 +47,18 @@ var __importDefault = (this && this.__importDefault) || function (mod) {
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.orchestrateRealizeWrite = orchestrateRealizeWrite;
 const __typia_transform__validateReport = __importStar(require("typia/lib/internal/_validateReport.js"));
+const utils_1 = require("@autobe/utils");
 const typia_1 = __importDefault(require("typia"));
+const uuid_1 = require("uuid");
 const assertSchemaModel_1 = require("../../context/assertSchemaModel");
 const getTestScenarioArtifacts_1 = require("../test/compile/getTestScenarioArtifacts");
 const transformRealizeWriteHistories_1 = require("./histories/transformRealizeWriteHistories");
 const replaceImportStatements_1 = require("./utils/replaceImportStatements");
-function orchestrateRealizeWrite(ctx, authorization, scenario, progress) {
+function orchestrateRealizeWrite(ctx, props) {
     return __awaiter(this, void 0, void 0, function* () {
-        var _a, _b;
+        var _a, _b, _c;
         const artifacts = yield (0, getTestScenarioArtifacts_1.getTestScenarioArtifacts)(ctx, {
-            endpoint: scenario.operation,
+            endpoint: props.scenario.operation,
             dependencies: [],
         });
         const pointer = {
@@ -66,9 +68,10 @@ function orchestrateRealizeWrite(ctx, authorization, scenario, progress) {
             source: "realizeWrite",
             histories: (0, transformRealizeWriteHistories_1.transformRealizeWriteHistories)({
                 state: ctx.state(),
-                scenario,
+                scenario: props.scenario,
                 artifacts,
-                authorization,
+                authorization: props.authorization,
+                totalAuthorizations: props.totalAuthorizations,
             }),
             controller: createController({
                 model: ctx.model,
@@ -77,31 +80,37 @@ function orchestrateRealizeWrite(ctx, authorization, scenario, progress) {
                 },
             }),
             enforceFunctionCall: true,
-            message: [
-                `Write complete, production-ready TypeScript code that strictly follows these rules:`,
-                "",
-                `1. Do **not** use the native \`Date\` type anywhere.`,
-                `2. All date or datetime values must be written as \`string & tags.Format<'date-time'>\`.`,
-                `3. UUIDs must be generated using \`v4()\` and typed as \`string & tags.Format<'uuid'>\`.`,
-                `4. Do not use \`as\` for type assertions — resolve types properly.`,
-                `5. All functions must be fully typed with clear parameter and return types.`,
-                `6. Do not skip validations or default values where necessary.`,
-                `7. Follow functional, immutable, and consistent code structure.`,
-                "",
-                `Use \`@nestia/e2e\` test structure if relevant.`,
-            ].join("\n"),
+            promptCacheKey: props.promptCacheKey,
+            message: utils_1.StringUtil.trim `
+      Write complete, production-ready TypeScript code that strictly follows these rules:
+
+      DO NOT:
+      - Use the native \`Date\` type anywhere
+      - Use \`as\` for type assertions
+
+      DO:
+      - Write all date/datetime values as \`string & tags.Format<'date-time'>\`
+      - Generate UUIDs using \`v4()\` and type as \`string & tags.Format<'uuid'>\`
+      - Resolve types properly without assertions
+      - Type all functions with clear parameter and return types
+      6. Do not skip validations or default values where necessary.
+      7. Follow functional, immutable, and consistent code structure.
+
+      Use \`@nestia/e2e\` test structure if relevant.
+    `,
         });
         if (pointer.value === null)
             throw new Error("Failed to write code.");
-        pointer.value.implementationCode = yield (0, replaceImportStatements_1.replaceImportStatements)(ctx)(artifacts, pointer.value.implementationCode, authorization === null || authorization === void 0 ? void 0 : authorization.payload.name);
+        pointer.value.implementationCode = yield (0, replaceImportStatements_1.replaceImportStatements)(ctx)(artifacts, pointer.value.implementationCode, (_a = props.authorization) === null || _a === void 0 ? void 0 : _a.payload.name);
         const event = {
             type: "realizeWrite",
-            location: scenario.location,
+            id: (0, uuid_1.v7)(),
+            location: props.scenario.location,
             content: pointer.value.implementationCode,
             tokenUsage,
-            completed: ++progress.completed,
-            total: progress.total,
-            step: (_b = (_a = ctx.state().analyze) === null || _a === void 0 ? void 0 : _a.step) !== null && _b !== void 0 ? _b : 0,
+            completed: ++props.progress.completed,
+            total: props.progress.total,
+            step: (_c = (_b = ctx.state().analyze) === null || _b === void 0 ? void 0 : _b.step) !== null && _c !== void 0 ? _c : 0,
             created_at: new Date().toISOString(),
         };
         ctx.dispatch(event);
@@ -136,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 MUST follow MANDATORY SCHEMA-FIRST APPROACH:\n\n\uD83D\uDCCB STEP 1 - PRISMA SCHEMA VERIFICATION (MOST CRITICAL):\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 (e.g., \"Note: deleted_at field\n  DOES NOT EXIST\")\n- Common assumption errors to avoid: `deleted_at`, `created_by`,\n  `updated_by`, `is_deleted`, `is_active`\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- 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",
                         type: "string"
                     },
                     prisma_schemas: {
@@ -144,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. CRITICAL: This draft must NEVER use the native Date\ntype.\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\n\u26A0\uFE0F Import rules:\n\n- Do NOT add any new import statements manually.\n- All necessary imports are provided globally or by the system\n  automatically.\n- Writing import statements directly is prohibited and may cause compile\n  errors. If import errors occur, check your environment configuration.\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- 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.",
                         type: "string"
                     },
                     review: {
@@ -242,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 MUST follow MANDATORY SCHEMA-FIRST APPROACH:\n\n\uD83D\uDCCB STEP 1 - PRISMA SCHEMA VERIFICATION (MOST CRITICAL):\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 (e.g., \"Note: deleted_at field\n  DOES NOT EXIST\")\n- Common assumption errors to avoid: `deleted_at`, `created_by`,\n  `updated_by`, `is_deleted`, `is_active`\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- 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",
                             type: "string"
                         },
                         prisma_schemas: {
@@ -250,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. CRITICAL: This draft must NEVER use the native Date\ntype.\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\n\u26A0\uFE0F Import rules:\n\n- Do NOT add any new import statements manually.\n- All necessary imports are provided globally or by the system\n  automatically.\n- Writing import statements directly is prohibited and may cause compile\n  errors. If import errors occur, check your environment configuration.\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- 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.",
                             type: "string"
                         },
                         review: {

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

@@ -1 +1 @@
-{"version":3,"file":"orchestrateRealizeWrite.js","sourceRoot":"","sources":["../../../../../src/orchestrate/realize/orchestrateRealizeWrite.ts"],"names":[],"mappings":";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;AAiBA,0DA+DC;;AA1ED,kDAA0B;AAG1B,uEAAoE;AACpE,uFAAoF;AAEpF,+FAA4F;AAG5F,6EAA0E;AAE1E,SAAsB,uBAAuB,CAC3C,GAAyB,EACzB,aAAgD,EAChD,QAAkD,EAClD,QAAmB;;;QAEnB,MAAM,SAAS,GACb,MAAM,IAAA,mDAAwB,EAAC,GAAG,EAAE;YAClC,QAAQ,EAAE,QAAQ,CAAC,SAAS;YAC5B,YAAY,EAAE,EAAE;SACjB,CAAC,CAAC;QACL,MAAM,OAAO,GAA2D;YACtE,KAAK,EAAE,IAAI;SACZ,CAAC;QACF,MAAM,EAAE,UAAU,EAAE,GAAG,MAAM,GAAG,CAAC,UAAU,CAAC;YAC1C,MAAM,EAAE,cAAc;YACtB,SAAS,EAAE,IAAA,+DAA8B,EAAC;gBACxC,KAAK,EAAE,GAAG,CAAC,KAAK,EAAE;gBAClB,QAAQ;gBACR,SAAS;gBACT,aAAa;aACd,CAAC;YACF,UAAU,EAAE,gBAAgB,CAAC;gBAC3B,KAAK,EAAE,GAAG,CAAC,KAAK;gBAChB,KAAK,EAAE,CAAC,IAAI,EAAE,EAAE;oBACd,OAAO,CAAC,KAAK,GAAG,IAAI,CAAC;gBACvB,CAAC;aACF,CAAC;YACF,mBAAmB,EAAE,IAAI;YACzB,OAAO,EAAE;gBACP,qFAAqF;gBACrF,EAAE;gBACF,sDAAsD;gBACtD,0FAA0F;gBAC1F,0FAA0F;gBAC1F,oEAAoE;gBACpE,6EAA6E;gBAC7E,+DAA+D;gBAC/D,iEAAiE;gBACjE,EAAE;gBACF,iDAAiD;aAClD,CAAC,IAAI,CAAC,IAAI,CAAC;SACb,CAAC,CAAC;QACH,IAAI,OAAO,CAAC,KAAK,KAAK,IAAI;YAAE,MAAM,IAAI,KAAK,CAAC,uBAAuB,CAAC,CAAC;QAErE,OAAO,CAAC,KAAK,CAAC,kBAAkB,GAAG,MAAM,IAAA,iDAAuB,EAAC,GAAG,CAAC,CACnE,SAAS,EACT,OAAO,CAAC,KAAK,CAAC,kBAAkB,EAChC,aAAa,aAAb,aAAa,uBAAb,aAAa,CAAE,OAAO,CAAC,IAAI,CAC5B,CAAC;QAEF,MAAM,KAAK,GAA4B;YACrC,IAAI,EAAE,cAAc;YACpB,QAAQ,EAAE,QAAQ,CAAC,QAAQ;YAC3B,OAAO,EAAE,OAAO,CAAC,KAAK,CAAC,kBAAkB;YACzC,UAAU;YACV,SAAS,EAAE,EAAE,QAAQ,CAAC,SAAS;YAC/B,KAAK,EAAE,QAAQ,CAAC,KAAK;YACrB,IAAI,EAAE,MAAA,MAAA,GAAG,CAAC,KAAK,EAAE,CAAC,OAAO,0CAAE,IAAI,mCAAI,CAAC;YACpC,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;SACrC,CAAC;QACF,GAAG,CAAC,QAAQ,CAAC,KAAK,CAAC,CAAC;QACpB,OAAO,KAAK,CAAC;IACf,CAAC;CAAA;AAED,SAAS,gBAAgB,CAAiC,KAGzD;IACC,IAAA,qCAAiB,EAAC,KAAK,CAAC,KAAK,CAAC,CAAC;IAE/B,MAAM,WAAW,GAA2B,UAAU,CACpD,KAAK,CAAC,KAAK,CACwD,CAAC;IAEtE,OAAO;QACL,QAAQ,EAAE,OAAO;QACjB,IAAI,EAAE,YAAY;QAClB,WAAW;QACX,OAAO,EAAE;YACP,MAAM,EAAE,CAAC,IAAI,EAAE,EAAE;gBACf,KAAK,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC;YACpB,CAAC;SACuC;KAC3C,CAAC;AACJ,CAAC;AAED,MAAM,MAAM;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAGT,CAAC;AACJ,MAAM,UAAU,GAAG;IACjB,OAAO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;KAAoE;IAC3E,MAAM;IACN,KAAK,EAAE,MAAM;IACb,QAAQ,EAAE,MAAM;IAChB,KAAK,EAAE,MAAM;CACd,CAAC"}
+{"version":3,"file":"orchestrateRealizeWrite.js","sourceRoot":"","sources":["../../../../../src/orchestrate/realize/orchestrateRealizeWrite.ts"],"names":[],"mappings":";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;AAoBA,0DA0EC;;AAzFD,yCAA2C;AAG3C,kDAA0B;AAC1B,+BAA0B;AAG1B,uEAAoE;AACpE,uFAAoF;AAEpF,+FAA4F;AAG5F,6EAA0E;AAE1E,SAAsB,uBAAuB,CAC3C,GAAyB,EACzB,KAMC;;;QAED,MAAM,SAAS,GACb,MAAM,IAAA,mDAAwB,EAAC,GAAG,EAAE;YAClC,QAAQ,EAAE,KAAK,CAAC,QAAQ,CAAC,SAAS;YAClC,YAAY,EAAE,EAAE;SACjB,CAAC,CAAC;QACL,MAAM,OAAO,GAA2D;YACtE,KAAK,EAAE,IAAI;SACZ,CAAC;QACF,MAAM,EAAE,UAAU,EAAE,GAAG,MAAM,GAAG,CAAC,UAAU,CAAC;YAC1C,MAAM,EAAE,cAAc;YACtB,SAAS,EAAE,IAAA,+DAA8B,EAAC;gBACxC,KAAK,EAAE,GAAG,CAAC,KAAK,EAAE;gBAClB,QAAQ,EAAE,KAAK,CAAC,QAAQ;gBACxB,SAAS;gBACT,aAAa,EAAE,KAAK,CAAC,aAAa;gBAClC,mBAAmB,EAAE,KAAK,CAAC,mBAAmB;aAC/C,CAAC;YACF,UAAU,EAAE,gBAAgB,CAAC;gBAC3B,KAAK,EAAE,GAAG,CAAC,KAAK;gBAChB,KAAK,EAAE,CAAC,IAAI,EAAE,EAAE;oBACd,OAAO,CAAC,KAAK,GAAG,IAAI,CAAC;gBACvB,CAAC;aACF,CAAC;YACF,mBAAmB,EAAE,IAAI;YACzB,cAAc,EAAE,KAAK,CAAC,cAAc;YACpC,OAAO,EAAE,kBAAU,CAAC,IAAI,CAAA;;;;;;;;;;;;;;;;KAgBvB;SACF,CAAC,CAAC;QACH,IAAI,OAAO,CAAC,KAAK,KAAK,IAAI;YAAE,MAAM,IAAI,KAAK,CAAC,uBAAuB,CAAC,CAAC;QAErE,OAAO,CAAC,KAAK,CAAC,kBAAkB,GAAG,MAAM,IAAA,iDAAuB,EAAC,GAAG,CAAC,CACnE,SAAS,EACT,OAAO,CAAC,KAAK,CAAC,kBAAkB,EAChC,MAAA,KAAK,CAAC,aAAa,0CAAE,OAAO,CAAC,IAAI,CAClC,CAAC;QAEF,MAAM,KAAK,GAA4B;YACrC,IAAI,EAAE,cAAc;YACpB,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,QAAQ,EAAE,KAAK,CAAC,QAAQ,CAAC,QAAQ;YACjC,OAAO,EAAE,OAAO,CAAC,KAAK,CAAC,kBAAkB;YACzC,UAAU;YACV,SAAS,EAAE,EAAE,KAAK,CAAC,QAAQ,CAAC,SAAS;YACrC,KAAK,EAAE,KAAK,CAAC,QAAQ,CAAC,KAAK;YAC3B,IAAI,EAAE,MAAA,MAAA,GAAG,CAAC,KAAK,EAAE,CAAC,OAAO,0CAAE,IAAI,mCAAI,CAAC;YACpC,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;SACrC,CAAC;QACF,GAAG,CAAC,QAAQ,CAAC,KAAK,CAAC,CAAC;QACpB,OAAO,KAAK,CAAC;IACf,CAAC;CAAA;AAED,SAAS,gBAAgB,CAAiC,KAGzD;IACC,IAAA,qCAAiB,EAAC,KAAK,CAAC,KAAK,CAAC,CAAC;IAE/B,MAAM,WAAW,GAA2B,UAAU,CACpD,KAAK,CAAC,KAAK,CACwD,CAAC;IAEtE,OAAO;QACL,QAAQ,EAAE,OAAO;QACjB,IAAI,EAAE,YAAY;QAClB,WAAW;QACX,OAAO,EAAE;YACP,MAAM,EAAE,CAAC,IAAI,EAAE,EAAE;gBACf,KAAK,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC;YACpB,CAAC;SACuC;KAC3C,CAAC;AACJ,CAAC;AAED,MAAM,MAAM;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAGT,CAAC;AACJ,MAAM,UAAU,GAAG;IACjB,OAAO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;KAAoE;IAC3E,MAAM;IACN,KAAK,EAAE,MAAM;IACb,QAAQ,EAAE,MAAM;IAChB,KAAK,EAAE,MAAM;CACd,CAAC"}

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

@@ -34,7 +34,7 @@ export declare namespace IAutoBeRealizeAuthorizationApplication {
          * called by the decorator to verify JWT tokens and return authenticated
          * user information for the specified role.
          *
-         * MUST use camelCase naming convention.
+         * DO: Use camelCase naming convention.
          */
         name: string & CamelPattern;
         /**
@@ -55,7 +55,7 @@ export declare namespace IAutoBeRealizeAuthorizationApplication {
          * authorize users for the specific role, injecting the authenticated user
          * payload as a method parameter.
          *
-         * MUST use PascalCase naming convention.
+         * DO: Use PascalCase naming convention.
          */
         name: string & PascalPattern;
         /**
@@ -75,7 +75,7 @@ export declare namespace IAutoBeRealizeAuthorizationApplication {
          * authenticated user data that will be injected into Controller methods
          * when using the decorator.
          *
-         * MUST use PascalCase naming convention.
+         * DO: Use PascalCase naming convention.
          */
         name: string & PascalPattern;
         /**

package/lib/agent/src/orchestrate/{internal/IProgress.js → realize/structures/IAutoBeRealizeCorrectApplication.js}

@@ -1,3 +1,3 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
-//# sourceMappingURL=IProgress.js.map
+//# sourceMappingURL=IAutoBeRealizeCorrectApplication.js.map

package/lib/agent/src/orchestrate/realize/structures/IAutoBeRealizeCorrectApplication.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"IAutoBeRealizeCorrectApplication.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/realize/structures/IAutoBeRealizeCorrectApplication.ts"],"names":[],"mappings":""}

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

@@ -12,16 +12,18 @@ export declare namespace IAutoBeRealizeWriteApplication {
          * function according to the Realize Coder Agent specification. Before
          * writing the actual code, think through the logic and structure.
          *
-         * The plan MUST follow MANDATORY SCHEMA-FIRST APPROACH:
+         * The plan follows a SCHEMA-FIRST APPROACH:
          *
-         * 📋 STEP 1 - PRISMA SCHEMA VERIFICATION (MOST CRITICAL):
+         * 📋 STEP 1 - PRISMA SCHEMA VERIFICATION:
          *
-         * - 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 (e.g., "Note: deleted_at field
-         *   DOES NOT EXIST")
-         * - Common assumption errors to avoid: `deleted_at`, `created_by`,
-         *   `updated_by`, `is_deleted`, `is_active`
+         * 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
          *
          * 📋 STEP 2 - FIELD INVENTORY:
          *
@@ -155,8 +157,9 @@ export declare namespace IAutoBeRealizeWriteApplication {
          * Draft WITHOUT using native Date type.
          *
          * This is the initial drafting phase where you outline the basic skeleton
-         * of the function. CRITICAL: This draft must NEVER use the native Date
-         * type.
+         * of the function.
+         *
+         * DO NOT: Use the native Date type.
          *
          * - The function signature must correctly include `user`, `parameters`, and
          *   `body` arguments.
@@ -165,13 +168,13 @@ export declare namespace IAutoBeRealizeWriteApplication {
          * - Mark any incomplete or missing parts clearly with placeholders (e.g.,
          *   comments or temporary values).
          *
-         * ⚠️ Import rules:
+         * Import rules:
+         *
+         * DO NOT:
+         * - Add any new import statements manually
+         * - Write import statements directly (this causes compile errors)
          *
-         * - Do NOT add any new import statements manually.
-         * - All necessary imports are provided globally or by the system
-         *   automatically.
-         * - Writing import statements directly is prohibited and may cause compile
-         *   errors. If import errors occur, check your environment configuration.
+         * Note: All necessary imports are provided globally or by the system automatically.
          *
          * ✅ Requirements:
          *

package/lib/agent/src/orchestrate/realize/utils/replaceImportStatements.js

@@ -25,7 +25,10 @@ function replaceImportStatements(ctx) {
                 .replace(/import\s+typia\s*from\s*["']typia["']\s*;?\s*/gm, "")
                 .replace(/import\s*{\s*Prisma\s*}\s*from\s*["']@prisma\/client["']\s*;?\s*/gm, "")
                 .replace(/import\s*{\s*v4\s*}\s*from\s*["']uuid["']\s*;?\s*/gm, "")
-                .replace(/import\s*{\s*toISOStringSafe\s*}\s*from\s*["']\.\.\/util\/toISOStringSafe["']\s*;?\s*/gm, "");
+                .replace(/import\s*{\s*toISOStringSafe\s*}\s*from\s*["']\.\.\/util\/toISOStringSafe["']\s*;?\s*/gm, "")
+                // Remove JWT import if it exists (to prevent duplication)
+                .replace(/import\s+jwt\s+from\s*["']jsonwebtoken["']\s*;?\s*/gm, "")
+                .replace(/import\s*\*\s*as\s+jwt\s+from\s*["']jsonwebtoken["']\s*;?\s*/gm, "");
             // Remove any existing API structure imports
             // Pattern 1: ../api/structures path
             code = code.replace(/import\s*(?:type\s*)?{\s*[^}]+\s*}\s*from\s*["']\.\.\/api\/structures\/[^"']+["']\s*;?\s*/gm, "");
@@ -44,6 +47,7 @@ function replaceImportStatements(ctx) {
             }
             // Build the standard imports
             const imports = [
+                'import jwt from "jsonwebtoken";',
                 'import { MyGlobal } from "../MyGlobal";',
                 'import typia, { tags } from "typia";',
                 'import { Prisma } from "@prisma/client";',

package/lib/agent/src/orchestrate/realize/utils/replaceImportStatements.js.map

@@ -1 +1 @@
-{"version":3,"file":"replaceImportStatements.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/realize/utils/replaceImportStatements.ts"],"names":[],"mappings":";;;;;;;;;;;AAMA,0DAuHC;AAvHD,SAAgB,uBAAuB,CACrC,GAAyB;IAEzB,OAAO,UACL,SAAuC,EACvC,IAAY,EACZ,aAAsB;;YAEtB,MAAM,cAAc,GAAa,KAAK,CAAC,IAAI,CACzC,IAAI,GAAG,CACL,MAAM,CAAC,IAAI,CAAC,SAAS,CAAC,QAAQ,CAAC,UAAU,CAAC,OAAO,CAAC,CAAC,GAAG,CACpD,CAAC,GAAG,EAAE,EAAE,CAAC,GAAG,CAAC,KAAK,CAAC,GAAG,CAAC,CAAC,CAAC,CAAE,CAC5B,CACF,CACF,CAAC;YAEF,MAAM,QAAQ,GAAoB,MAAM,GAAG,CAAC,QAAQ,EAAE,CAAC;YACvD,IAAI,GAAG,MAAM,QAAQ,CAAC,UAAU,CAAC,QAAQ,CAAC,IAAI,CAAC,CAAC;YAChD,kEAAkE;YAClE,IAAI,GAAG,IAAI;iBACR,OAAO,CACN,qEAAqE,EACrE,EAAE,CACH;iBACA,OAAO,CACN,oEAAoE,EACpE,EAAE,CACH;iBACA,OAAO,CAAC,wDAAwD,EAAE,EAAE,CAAC;iBACrE,OAAO,CACN,oEAAoE,EACpE,EAAE,CACH;iBACA,OAAO,CAAC,iDAAiD,EAAE,EAAE,CAAC;iBAC9D,OAAO,CACN,oEAAoE,EACpE,EAAE,CACH;iBACA,OAAO,CAAC,qDAAqD,EAAE,EAAE,CAAC;iBAClE,OAAO,CACN,yFAAyF,EACzF,EAAE,CACH,CAAC;YAEJ,4CAA4C;YAC5C,oCAAoC;YACpC,IAAI,GAAG,IAAI,CAAC,OAAO,CACjB,6FAA6F,EAC7F,EAAE,CACH,CAAC;YACF,2DAA2D;YAC3D,IAAI,GAAG,IAAI,CAAC,OAAO,CACjB,mHAAmH,EACnH,EAAE,CACH,CAAC;YAEF,6DAA6D;YAC7D,KAAK,MAAM,GAAG,IAAI,cAAc,EAAE,CAAC;gBACjC,wDAAwD;gBACxD,MAAM,eAAe,GAAG,IAAI,MAAM,CAChC,+BAA+B,GAAG,2CAA2C,EAC7E,IAAI,CACL,CAAC;gBACF,IAAI,GAAG,IAAI,CAAC,OAAO,CAAC,eAAe,EAAE,EAAE,CAAC,CAAC;YAC3C,CAAC;YAED,yEAAyE;YACzE,IAAI,aAAa,EAAE,CAAC;gBAClB,MAAM,kBAAkB,GAAG,IAAI,MAAM,CACnC,+BAA+B,aAAa,qDAAqD,aAAa,gBAAgB,EAC9H,IAAI,CACL,CAAC;gBACF,IAAI,GAAG,IAAI,CAAC,OAAO,CAAC,kBAAkB,EAAE,EAAE,CAAC,CAAC;YAC9C,CAAC;YAED,6BAA6B;YAC7B,MAAM,OAAO,GAAG;gBACd,yCAAyC;gBACzC,sCAAsC;gBACtC,0CAA0C;gBAC1C,4BAA4B;gBAC5B,2DAA2D;gBAC3D,GAAG,cAAc,CAAC,GAAG,CACnB,CAAC,GAAG,EAAE,EAAE,CACN,YAAY,GAAG,qDAAqD,GAAG,IAAI,CAC9E;aACF,CAAC;YAEF,6CAA6C;YAC7C,IAAI,aAAa,EAAE,CAAC;gBAClB,OAAO,CAAC,IAAI,CACV,YAAY,aAAa,kCAAkC,aAAa,GAAG,CAC5E,CAAC;YACJ,CAAC;YAED,IAAI,GAAG,CAAC,GAAG,OAAO,EAAE,EAAE,EAAE,IAAI,CAAC,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;YAEzC,6BAA6B;YAC7B,IAAI;gBACF,IAAI;oBACF,oCAAoC;qBACnC,OAAO,CAAC,SAAS,EAAE,EAAE,CAAC;oBACvB,0DAA0D;qBACzD,OAAO,CAAC,SAAS,EAAE,MAAM,CAAC;oBAC3B,6CAA6C;qBAC5C,OAAO,CAAC,uCAAuC,EAAE,UAAU,CAAC;oBAC7D,0CAA0C;qBACzC,IAAI,EAAE,GAAG,IAAI,CAAC;YAEnB,oBAAoB;YACpB,IAAI,GAAG,IAAI,CAAC,OAAO,CAAC,MAAM,EAAE,IAAI,CAAC,CAAC,OAAO,CAAC,MAAM,EAAE,GAAG,CAAC,CAAC,OAAO,CAAC,MAAM,EAAE,GAAG,CAAC,CAAC;YAE5E,6BAA6B;YAC7B,IAAI,GAAG,MAAM,QAAQ,CAAC,UAAU,CAAC,QAAQ,CAAC,IAAI,CAAC,CAAC;YAEhD,IAAI,GAAG,IAAI,CAAC,UAAU,CAAC,mBAAmB,EAAE,cAAc,CAAC,CAAC;YAE5D,OAAO,IAAI,CAAC;QACd,CAAC;KAAA,CAAC;AACJ,CAAC"}
+{"version":3,"file":"replaceImportStatements.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/realize/utils/replaceImportStatements.ts"],"names":[],"mappings":";;;;;;;;;;;AAMA,0DA8HC;AA9HD,SAAgB,uBAAuB,CACrC,GAAyB;IAEzB,OAAO,UACL,SAAuC,EACvC,IAAY,EACZ,aAAsB;;YAEtB,MAAM,cAAc,GAAa,KAAK,CAAC,IAAI,CACzC,IAAI,GAAG,CACL,MAAM,CAAC,IAAI,CAAC,SAAS,CAAC,QAAQ,CAAC,UAAU,CAAC,OAAO,CAAC,CAAC,GAAG,CACpD,CAAC,GAAG,EAAE,EAAE,CAAC,GAAG,CAAC,KAAK,CAAC,GAAG,CAAC,CAAC,CAAC,CAAE,CAC5B,CACF,CACF,CAAC;YAEF,MAAM,QAAQ,GAAoB,MAAM,GAAG,CAAC,QAAQ,EAAE,CAAC;YACvD,IAAI,GAAG,MAAM,QAAQ,CAAC,UAAU,CAAC,QAAQ,CAAC,IAAI,CAAC,CAAC;YAChD,kEAAkE;YAClE,IAAI,GAAG,IAAI;iBACR,OAAO,CACN,qEAAqE,EACrE,EAAE,CACH;iBACA,OAAO,CACN,oEAAoE,EACpE,EAAE,CACH;iBACA,OAAO,CAAC,wDAAwD,EAAE,EAAE,CAAC;iBACrE,OAAO,CACN,oEAAoE,EACpE,EAAE,CACH;iBACA,OAAO,CAAC,iDAAiD,EAAE,EAAE,CAAC;iBAC9D,OAAO,CACN,oEAAoE,EACpE,EAAE,CACH;iBACA,OAAO,CAAC,qDAAqD,EAAE,EAAE,CAAC;iBAClE,OAAO,CACN,yFAAyF,EACzF,EAAE,CACH;gBACD,0DAA0D;iBACzD,OAAO,CAAC,sDAAsD,EAAE,EAAE,CAAC;iBACnE,OAAO,CACN,gEAAgE,EAChE,EAAE,CACH,CAAC;YAEJ,4CAA4C;YAC5C,oCAAoC;YACpC,IAAI,GAAG,IAAI,CAAC,OAAO,CACjB,6FAA6F,EAC7F,EAAE,CACH,CAAC;YACF,2DAA2D;YAC3D,IAAI,GAAG,IAAI,CAAC,OAAO,CACjB,mHAAmH,EACnH,EAAE,CACH,CAAC;YAEF,6DAA6D;YAC7D,KAAK,MAAM,GAAG,IAAI,cAAc,EAAE,CAAC;gBACjC,wDAAwD;gBACxD,MAAM,eAAe,GAAG,IAAI,MAAM,CAChC,+BAA+B,GAAG,2CAA2C,EAC7E,IAAI,CACL,CAAC;gBACF,IAAI,GAAG,IAAI,CAAC,OAAO,CAAC,eAAe,EAAE,EAAE,CAAC,CAAC;YAC3C,CAAC;YAED,yEAAyE;YACzE,IAAI,aAAa,EAAE,CAAC;gBAClB,MAAM,kBAAkB,GAAG,IAAI,MAAM,CACnC,+BAA+B,aAAa,qDAAqD,aAAa,gBAAgB,EAC9H,IAAI,CACL,CAAC;gBACF,IAAI,GAAG,IAAI,CAAC,OAAO,CAAC,kBAAkB,EAAE,EAAE,CAAC,CAAC;YAC9C,CAAC;YAED,6BAA6B;YAC7B,MAAM,OAAO,GAAG;gBACd,iCAAiC;gBACjC,yCAAyC;gBACzC,sCAAsC;gBACtC,0CAA0C;gBAC1C,4BAA4B;gBAC5B,2DAA2D;gBAC3D,GAAG,cAAc,CAAC,GAAG,CACnB,CAAC,GAAG,EAAE,EAAE,CACN,YAAY,GAAG,qDAAqD,GAAG,IAAI,CAC9E;aACF,CAAC;YAEF,6CAA6C;YAC7C,IAAI,aAAa,EAAE,CAAC;gBAClB,OAAO,CAAC,IAAI,CACV,YAAY,aAAa,kCAAkC,aAAa,GAAG,CAC5E,CAAC;YACJ,CAAC;YAED,IAAI,GAAG,CAAC,GAAG,OAAO,EAAE,EAAE,EAAE,IAAI,CAAC,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;YAEzC,6BAA6B;YAC7B,IAAI;gBACF,IAAI;oBACF,oCAAoC;qBACnC,OAAO,CAAC,SAAS,EAAE,EAAE,CAAC;oBACvB,0DAA0D;qBACzD,OAAO,CAAC,SAAS,EAAE,MAAM,CAAC;oBAC3B,6CAA6C;qBAC5C,OAAO,CAAC,uCAAuC,EAAE,UAAU,CAAC;oBAC7D,0CAA0C;qBACzC,IAAI,EAAE,GAAG,IAAI,CAAC;YAEnB,oBAAoB;YACpB,IAAI,GAAG,IAAI,CAAC,OAAO,CAAC,MAAM,EAAE,IAAI,CAAC,CAAC,OAAO,CAAC,MAAM,EAAE,GAAG,CAAC,CAAC,OAAO,CAAC,MAAM,EAAE,GAAG,CAAC,CAAC;YAE5E,6BAA6B;YAC7B,IAAI,GAAG,MAAM,QAAQ,CAAC,UAAU,CAAC,QAAQ,CAAC,IAAI,CAAC,CAAC;YAEhD,IAAI,GAAG,IAAI,CAAC,UAAU,CAAC,mBAAmB,EAAE,cAAc,CAAC,CAAC;YAE5D,OAAO,IAAI,CAAC;QACd,CAAC;KAAA,CAAC;AACJ,CAAC"}