@autobe/agent 0.12.0 → 0.14.2

package/lib/orchestrate/realize/orchestrateRealizeCoder.js

@@ -55,6 +55,7 @@ const enforceToolCall_1 = require("../../utils/enforceToolCall");
 const getTestScenarioArtifacts_1 = require("../test/compile/getTestScenarioArtifacts");
 const IAutoBeRealizeFailedSymbol_1 = require("./structures/IAutoBeRealizeFailedSymbol");
 const transformRealizeCoderHistories_1 = require("./transformRealizeCoderHistories");
+const replaceImportStatements_1 = require("./utils/replaceImportStatements");
 /**
  * Generates a TypeScript function implementation based on the given plan.
  *
@@ -74,6 +75,7 @@ const transformRealizeCoderHistories_1 = require("./transformRealizeCoderHistori
  * @returns The generated function name and TypeScript code
  */
 const orchestrateRealizeCoder = (ctx, operation, props, previous, total, diagnostics) => __awaiter(void 0, void 0, void 0, function* () {
+    var _a;
     total;
     const artifacts = yield (0, getTestScenarioArtifacts_1.getTestScenarioArtifacts)(ctx, {
         endpoint: {
@@ -120,37 +122,12 @@ const orchestrateRealizeCoder = (ctx, operation, props, previous, total, diagnos
     if (pointer.value === null) {
         return IAutoBeRealizeFailedSymbol_1.FAILED;
     }
-    pointer.value.implementationCode = yield replaceImportStatements(ctx)(pointer.value.implementationCode);
+    pointer.value.implementationCode = yield (0, replaceImportStatements_1.replaceImportStatements)(ctx)(pointer.value.implementationCode, (_a = props.decoratorEvent) === null || _a === void 0 ? void 0 : _a.payload.name);
+    pointer.value.implementationCode =
+        pointer.value.implementationCode.replaceAll("typia.tags.assert", "typia.assert");
     return Object.assign(Object.assign({}, pointer.value), { filename: `src/providers/${props.functionName}.ts` });
 });
 exports.orchestrateRealizeCoder = orchestrateRealizeCoder;
-function replaceImportStatements(ctx) {
-    return function (code) {
-        return __awaiter(this, void 0, void 0, function* () {
-            const compiler = yield ctx.compiler();
-            code = yield compiler.typescript.beautify(code);
-            code = code
-                .replaceAll('import { MyGlobal } from "../MyGlobal";', "")
-                .replaceAll('import typia, { tags } from "typia";', "")
-                .replaceAll('import { tags } from "typia";', "")
-                .replaceAll('import { tags, typia } from "typia";', "")
-                .replaceAll('import typia from "typia";', "")
-                .replaceAll('import { Prisma } from "@prisma/client";', "")
-                .replaceAll('import { jwtDecode } from "./jwtDecode"', "")
-                .replaceAll('import { v4 } from "uuid"', "");
-            code = [
-                'import { MyGlobal } from "../MyGlobal";',
-                'import typia, { tags } from "typia";',
-                'import { Prisma } from "@prisma/client";',
-                'import { jwtDecode } from "./jwtDecode";',
-                'import { v4 } from "uuid";',
-                "",
-                code,
-            ].join("\n");
-            return code;
-        });
-    };
-}
 function createApplication(props) {
     (0, assertSchemaModel_1.assertSchemaModel)(props.model);
     const application = collection[props.model];
@@ -195,30 +172,39 @@ const claude = {
                             filename: {
                                 type: "string"
                             },
+                            errorAnalysis: {
+                                description: "Error Analysis Phase (Optional)\n\n\uD83D\uDD0D Analyzes TypeScript compilation errors from previous attempts.\n\nThis field should contain a detailed analysis of any TypeScript errors\nencountered, with root cause identification and resolution strategies:\n\nCommon Error Patterns to Analyze:\n\n1. **\"Property does not exist\" (TS2353)**:\n\n   - Root Cause: Using fields that don't exist in Prisma schema\n   - Example: Using `deleted_at` when the field doesn't exist in the model\n   - Resolution: Remove the non-existent field or use hard delete instead\n2. **\"Type 'void' is not assignable\" (TS2322)**:\n\n   - Root Cause: Using `typia.assertGuard` instead of `typia.assert`\n   - `assertGuard` returns void, `assert` returns the validated value\n   - Resolution: Change `typia.assertGuard<T>()` to `typia.assert<T>()`\n3. **\"Type 'Date' is not assignable to type 'string &\n   Format<'date-time'>'\"**:\n\n   - Root Cause: Assigning native Date objects to string fields\n   - Resolution: Use `toISOStringSafe(dateValue)` for all date conversions\n4. **Complex Prisma Type Errors**:\n\n   - Root Cause: Nested operations with incompatible types\n   - Resolution: Use separate queries and application-level joins\n\nAnalysis Format:\n\n- List each error with its TypeScript error code\n- Identify the root cause (schema mismatch, wrong function usage, etc.)\n- Provide specific resolution steps\n- Note any schema limitations discovered",
+                                type: "string"
+                            },
                             plan: {
-                                description: "\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 consider:\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)\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  to ISO strings with `.toISOString()` 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\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 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",
+                                type: "string"
+                            },
+                            prisma_schemas: {
+                                description: "Step 2.\n\nThe Prisma schema string that will be used to validate the implementation\nlogic in this file.\n\nYou must **explicitly specify only the relevant models and fields** from\nyour full schema that are used in this implementation. This ensures that\nyour logic is aligned with the expected database structure without\naccidentally introducing unrelated fields or models.\n\n\u26A0\uFE0F Important: The value of this field must be a valid Prisma schema\nstring containing only the models used in this code \u2014 not the entire\nschema.\n\nThis acts as a safeguard against:\n\n- Forgetting required fields used in this implementation\n- Including fields or models that are not actually used",
                                 type: "string"
                             },
                             draft_without_date_type: {
-                                description: "\u270F\uFE0F Phase 1: Draft code\n\nThis is the initial drafting phase where you outline the basic skeleton\nof the function.\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- Do NOT assign native `Date` objects directly; always convert dates using\n  `.toISOString()` before assignment and apply proper branding.\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. 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.",
                                 type: "string"
                             },
                             review: {
-                                description: "\uD83D\uDD0D Phase 2: Review code\n\nA refined version of the draft with improved completeness.\n\n- Replace placeholder logic with real DTO-conformant operations.\n- Add error handling (`throw new Error(...)`) where necessary.\n- Begin resolving structural or type mismatches.\n\n\u2705 Requirements:\n\n- Use `satisfies` to ensure DTO conformity.\n- Avoid unsafe `as` casts unless only for branding or literal narrowing.\n- Include `.toISOString()` for all date fields.\n- Ensure all object keys strictly conform to the expected type definitions.",
+                                description: "Step 4.\n\nA refined version of the draft with improved completeness.\n\n- Replace placeholder logic with real DTO-conformant operations.\n- Add error handling (`throw new Error(...)`) where necessary.\n- Begin resolving structural or type mismatches.\n\n\u2705 Requirements:\n\n- Use `satisfies` to ensure DTO conformity.\n- Avoid unsafe `as` casts unless only for branding or literal narrowing.\n- Use `toISOStringSafe()` for all date conversions (NOT `.toISOString()`).\n- Ensure all object keys strictly conform to the expected type definitions.",
                                 type: "string"
                             },
                             withCompilerFeedback: {
-                                description: "\uD83D\uDEE0 Phase 3: With compiler feedback (optional)\n\nA correction pass that applies fixes for compile-time errors that arose\nduring the review stage (if any).\n\n\u2705 Must:\n\n- Only include this field if TypeScript errors are detected in the Review\n  phase.\n- Resolve all TypeScript errors without using `as any`.\n- Provide safe brand casting only if required (e.g., `as string &\n  tags.Format<'uuid'>`).",
+                                description: "\uD83D\uDEE0 Phase 4-2: With compiler feedback (optional)\n\nA correction pass that applies fixes for compile-time errors that arose\nduring the review stage (if any).\n\n\u2705 Must:\n\n- Only include this field if TypeScript errors are detected in the Review\n  phase.\n- Resolve all TypeScript errors without using `as any`.\n- Provide safe brand casting only if required (e.g., `as string &\n  tags.Format<'uuid'>`).",
                                 type: "string"
                             },
                             implementationCode: {
-                                description: "\u2705 Phase 4: Final implementation\n\nThe complete and fully correct TypeScript function implementation.\n\n- Passes strict type checking without errors.\n- Uses only safe branding or literal type assertions.\n- Converts all date values properly to ISO string format.\n- Follows DTO structures using `satisfies`.\n- Avoids any weak typing such as `any`, `as any`, or `satisfies any`.\n- Uses only allowed imports (e.g., from `src/api/structures` and\n  `MyGlobal.prisma`).\n\n\u26A0\uFE0F Prohibited Practices:\n\n- Do NOT add or modify import statements manually. Imports are handled\n  automatically by the system.\n- Do NOT use `any`, `as any`, or `satisfies any` to bypass type checking.\n- Do NOT assign native `Date` objects directly; always convert them to ISO\n  strings with `.toISOString()`.\n- Do NOT use unsafe type assertions except for safe branding or literal\n  narrowing.\n- Do NOT write code outside the single async function structure (e.g., no\n  classes or multiple functions).\n- Do NOT perform any input validation \u2014 assume all inputs are already\n  validated.\n- Do NOT use dynamic import expressions (`import()`); all imports must be\n  static.\n- Do NOT rely on DTO types for database update input; always use\n  Prisma-generated input types.",
+                                description: "Step 5.\n\nThe complete and fully correct TypeScript function implementation.\n\n- Passes strict type checking without errors.\n- Uses only safe branding or literal type assertions.\n- Converts all date values properly using `toISOStringSafe()`.\n- Follows DTO structures using `satisfies`.\n- Avoids any weak typing such as `any`, `as any`, or `satisfies any`.\n- Uses only allowed imports (e.g., from `../api/structures` and\n  `MyGlobal.prisma`).\n- NEVER creates intermediate variables for Prisma operations.\n\n\u26A0\uFE0F Fallback Behavior:\n\n- If the `plan` phase explicitly determines that the requested logic is\n  **not feasible** due to mismatches or limitations in the provided\n  Prisma schema and DTO types:\n\n  - The implementation must still return a syntactically valid function.\n  - In such cases, return mock data using `typia.random<T>()` wrapped in the\n      correct structure, along with a comment explaining the limitation.\n\n  Example fallback:\n\n```ts\n  // \u26A0\uFE0F Cannot implement logic due to missing relation between A and B\n  export async function someFunction(...) {\n    return typia.random<IReturn>(); // mocked output\n  }\n```\n\n\u26A0\uFE0F Prohibited Practices:\n\n- Do NOT add or modify import statements manually. Imports are handled\n  automatically by the system.\n- Do NOT use `any`, `as any`, or `satisfies any` to bypass type checking.\n- Do NOT assign native `Date` objects directly; always convert them using\n  `toISOStringSafe()`.\n- Do NOT use unsafe type assertions except for safe branding or literal\n  narrowing.\n- Do NOT write code outside the single async function structure (e.g., no\n  classes or multiple functions).\n- Do NOT perform any input validation \u2014 assume all inputs are already\n  validated.\n- Do NOT use dynamic import expressions (`import()`); all imports must be\n  static.\n- Do NOT use Prisma-generated input types; always use types from\n  `../api/structures`.\n- Do NOT use `Object.prototype.hasOwnProperty.call()` for field checks.\n- Do NOT escape newlines or quotes in the implementation string (e.g., no\n  `\\\\n` or `\\\"`); use a properly formatted template literal with actual\n  line breaks instead.",
                                 type: "string"
                             }
                         },
                         required: [
                             "filename",
                             "plan",
+                            "prisma_schemas",
                             "draft_without_date_type",
                             "review",
                             "implementationCode"
@@ -226,7 +212,7 @@ const claude = {
                     }
                 }
             },
-            validate: (() => { const _io0 = input => "object" === typeof input.output && null !== input.output && _io1(input.output); const _io1 = input => "string" === typeof input.filename && "string" === typeof input.plan && "string" === typeof input.draft_without_date_type && "string" === typeof input.review && (undefined === input.withCompilerFeedback || "string" === typeof input.withCompilerFeedback) && "string" === typeof input.implementationCode; const _vo0 = (input, _path, _exceptionable = true) => [("object" === typeof input.output && null !== input.output || _report(_exceptionable, {
+            validate: (() => { const _io0 = input => "object" === typeof input.output && null !== input.output && _io1(input.output); const _io1 = input => "string" === typeof input.filename && (undefined === input.errorAnalysis || "string" === typeof input.errorAnalysis) && "string" === typeof input.plan && "string" === typeof input.prisma_schemas && "string" === typeof input.draft_without_date_type && "string" === typeof input.review && (undefined === input.withCompilerFeedback || "string" === typeof input.withCompilerFeedback) && "string" === typeof input.implementationCode; const _vo0 = (input, _path, _exceptionable = true) => [("object" === typeof input.output && null !== input.output || _report(_exceptionable, {
                     path: _path + ".output",
                     expected: "IAutoBeRealizeCoderApplication.RealizeCoderOutput",
                     value: input.output
@@ -238,10 +224,18 @@ const claude = {
                     path: _path + ".filename",
                     expected: "string",
                     value: input.filename
+                }), undefined === input.errorAnalysis || "string" === typeof input.errorAnalysis || _report(_exceptionable, {
+                    path: _path + ".errorAnalysis",
+                    expected: "(string | undefined)",
+                    value: input.errorAnalysis
                 }), "string" === typeof input.plan || _report(_exceptionable, {
                     path: _path + ".plan",
                     expected: "string",
                     value: input.plan
+                }), "string" === typeof input.prisma_schemas || _report(_exceptionable, {
+                    path: _path + ".prisma_schemas",
+                    expected: "string",
+                    value: input.prisma_schemas
                 }), "string" === typeof input.draft_without_date_type || _report(_exceptionable, {
                     path: _path + ".draft_without_date_type",
                     expected: "string",
@@ -320,30 +314,39 @@ const collection = {
                                 filename: {
                                     type: "string"
                                 },
+                                errorAnalysis: {
+                                    description: "Error Analysis Phase (Optional)\n\n\uD83D\uDD0D Analyzes TypeScript compilation errors from previous attempts.\n\nThis field should contain a detailed analysis of any TypeScript errors\nencountered, with root cause identification and resolution strategies:\n\nCommon Error Patterns to Analyze:\n\n1. **\"Property does not exist\" (TS2353)**:\n\n   - Root Cause: Using fields that don't exist in Prisma schema\n   - Example: Using `deleted_at` when the field doesn't exist in the model\n   - Resolution: Remove the non-existent field or use hard delete instead\n2. **\"Type 'void' is not assignable\" (TS2322)**:\n\n   - Root Cause: Using `typia.assertGuard` instead of `typia.assert`\n   - `assertGuard` returns void, `assert` returns the validated value\n   - Resolution: Change `typia.assertGuard<T>()` to `typia.assert<T>()`\n3. **\"Type 'Date' is not assignable to type 'string &\n   Format<'date-time'>'\"**:\n\n   - Root Cause: Assigning native Date objects to string fields\n   - Resolution: Use `toISOStringSafe(dateValue)` for all date conversions\n4. **Complex Prisma Type Errors**:\n\n   - Root Cause: Nested operations with incompatible types\n   - Resolution: Use separate queries and application-level joins\n\nAnalysis Format:\n\n- List each error with its TypeScript error code\n- Identify the root cause (schema mismatch, wrong function usage, etc.)\n- Provide specific resolution steps\n- Note any schema limitations discovered",
+                                    type: "string"
+                                },
                                 plan: {
-                                    description: "\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 consider:\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)\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  to ISO strings with `.toISOString()` 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\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 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",
+                                    type: "string"
+                                },
+                                prisma_schemas: {
+                                    description: "Step 2.\n\nThe Prisma schema string that will be used to validate the implementation\nlogic in this file.\n\nYou must **explicitly specify only the relevant models and fields** from\nyour full schema that are used in this implementation. This ensures that\nyour logic is aligned with the expected database structure without\naccidentally introducing unrelated fields or models.\n\n\u26A0\uFE0F Important: The value of this field must be a valid Prisma schema\nstring containing only the models used in this code \u2014 not the entire\nschema.\n\nThis acts as a safeguard against:\n\n- Forgetting required fields used in this implementation\n- Including fields or models that are not actually used",
                                     type: "string"
                                 },
                                 draft_without_date_type: {
-                                    description: "\u270F\uFE0F Phase 1: Draft code\n\nThis is the initial drafting phase where you outline the basic skeleton\nof the function.\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- Do NOT assign native `Date` objects directly; always convert dates using\n  `.toISOString()` before assignment and apply proper branding.\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. 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.",
                                     type: "string"
                                 },
                                 review: {
-                                    description: "\uD83D\uDD0D Phase 2: Review code\n\nA refined version of the draft with improved completeness.\n\n- Replace placeholder logic with real DTO-conformant operations.\n- Add error handling (`throw new Error(...)`) where necessary.\n- Begin resolving structural or type mismatches.\n\n\u2705 Requirements:\n\n- Use `satisfies` to ensure DTO conformity.\n- Avoid unsafe `as` casts unless only for branding or literal narrowing.\n- Include `.toISOString()` for all date fields.\n- Ensure all object keys strictly conform to the expected type definitions.",
+                                    description: "Step 4.\n\nA refined version of the draft with improved completeness.\n\n- Replace placeholder logic with real DTO-conformant operations.\n- Add error handling (`throw new Error(...)`) where necessary.\n- Begin resolving structural or type mismatches.\n\n\u2705 Requirements:\n\n- Use `satisfies` to ensure DTO conformity.\n- Avoid unsafe `as` casts unless only for branding or literal narrowing.\n- Use `toISOStringSafe()` for all date conversions (NOT `.toISOString()`).\n- Ensure all object keys strictly conform to the expected type definitions.",
                                     type: "string"
                                 },
                                 withCompilerFeedback: {
-                                    description: "\uD83D\uDEE0 Phase 3: With compiler feedback (optional)\n\nA correction pass that applies fixes for compile-time errors that arose\nduring the review stage (if any).\n\n\u2705 Must:\n\n- Only include this field if TypeScript errors are detected in the Review\n  phase.\n- Resolve all TypeScript errors without using `as any`.\n- Provide safe brand casting only if required (e.g., `as string &\n  tags.Format<'uuid'>`).",
+                                    description: "\uD83D\uDEE0 Phase 4-2: With compiler feedback (optional)\n\nA correction pass that applies fixes for compile-time errors that arose\nduring the review stage (if any).\n\n\u2705 Must:\n\n- Only include this field if TypeScript errors are detected in the Review\n  phase.\n- Resolve all TypeScript errors without using `as any`.\n- Provide safe brand casting only if required (e.g., `as string &\n  tags.Format<'uuid'>`).",
                                     type: "string"
                                 },
                                 implementationCode: {
-                                    description: "\u2705 Phase 4: Final implementation\n\nThe complete and fully correct TypeScript function implementation.\n\n- Passes strict type checking without errors.\n- Uses only safe branding or literal type assertions.\n- Converts all date values properly to ISO string format.\n- Follows DTO structures using `satisfies`.\n- Avoids any weak typing such as `any`, `as any`, or `satisfies any`.\n- Uses only allowed imports (e.g., from `src/api/structures` and\n  `MyGlobal.prisma`).\n\n\u26A0\uFE0F Prohibited Practices:\n\n- Do NOT add or modify import statements manually. Imports are handled\n  automatically by the system.\n- Do NOT use `any`, `as any`, or `satisfies any` to bypass type checking.\n- Do NOT assign native `Date` objects directly; always convert them to ISO\n  strings with `.toISOString()`.\n- Do NOT use unsafe type assertions except for safe branding or literal\n  narrowing.\n- Do NOT write code outside the single async function structure (e.g., no\n  classes or multiple functions).\n- Do NOT perform any input validation \u2014 assume all inputs are already\n  validated.\n- Do NOT use dynamic import expressions (`import()`); all imports must be\n  static.\n- Do NOT rely on DTO types for database update input; always use\n  Prisma-generated input types.",
+                                    description: "Step 5.\n\nThe complete and fully correct TypeScript function implementation.\n\n- Passes strict type checking without errors.\n- Uses only safe branding or literal type assertions.\n- Converts all date values properly using `toISOStringSafe()`.\n- Follows DTO structures using `satisfies`.\n- Avoids any weak typing such as `any`, `as any`, or `satisfies any`.\n- Uses only allowed imports (e.g., from `../api/structures` and\n  `MyGlobal.prisma`).\n- NEVER creates intermediate variables for Prisma operations.\n\n\u26A0\uFE0F Fallback Behavior:\n\n- If the `plan` phase explicitly determines that the requested logic is\n  **not feasible** due to mismatches or limitations in the provided\n  Prisma schema and DTO types:\n\n  - The implementation must still return a syntactically valid function.\n  - In such cases, return mock data using `typia.random<T>()` wrapped in the\n      correct structure, along with a comment explaining the limitation.\n\n  Example fallback:\n\n```ts\n  // \u26A0\uFE0F Cannot implement logic due to missing relation between A and B\n  export async function someFunction(...) {\n    return typia.random<IReturn>(); // mocked output\n  }\n```\n\n\u26A0\uFE0F Prohibited Practices:\n\n- Do NOT add or modify import statements manually. Imports are handled\n  automatically by the system.\n- Do NOT use `any`, `as any`, or `satisfies any` to bypass type checking.\n- Do NOT assign native `Date` objects directly; always convert them using\n  `toISOStringSafe()`.\n- Do NOT use unsafe type assertions except for safe branding or literal\n  narrowing.\n- Do NOT write code outside the single async function structure (e.g., no\n  classes or multiple functions).\n- Do NOT perform any input validation \u2014 assume all inputs are already\n  validated.\n- Do NOT use dynamic import expressions (`import()`); all imports must be\n  static.\n- Do NOT use Prisma-generated input types; always use types from\n  `../api/structures`.\n- Do NOT use `Object.prototype.hasOwnProperty.call()` for field checks.\n- Do NOT escape newlines or quotes in the implementation string (e.g., no\n  `\\\\n` or `\\\"`); use a properly formatted template literal with actual\n  line breaks instead.",
                                     type: "string"
                                 }
                             },
                             required: [
                                 "filename",
                                 "plan",
+                                "prisma_schemas",
                                 "draft_without_date_type",
                                 "review",
                                 "implementationCode"
@@ -351,7 +354,7 @@ const collection = {
                         }
                     }
                 },
-                validate: (() => { const _io0 = input => "object" === typeof input.output && null !== input.output && _io1(input.output); const _io1 = input => "string" === typeof input.filename && "string" === typeof input.plan && "string" === typeof input.draft_without_date_type && "string" === typeof input.review && (undefined === input.withCompilerFeedback || "string" === typeof input.withCompilerFeedback) && "string" === typeof input.implementationCode; const _vo0 = (input, _path, _exceptionable = true) => [("object" === typeof input.output && null !== input.output || _report(_exceptionable, {
+                validate: (() => { const _io0 = input => "object" === typeof input.output && null !== input.output && _io1(input.output); const _io1 = input => "string" === typeof input.filename && (undefined === input.errorAnalysis || "string" === typeof input.errorAnalysis) && "string" === typeof input.plan && "string" === typeof input.prisma_schemas && "string" === typeof input.draft_without_date_type && "string" === typeof input.review && (undefined === input.withCompilerFeedback || "string" === typeof input.withCompilerFeedback) && "string" === typeof input.implementationCode; const _vo0 = (input, _path, _exceptionable = true) => [("object" === typeof input.output && null !== input.output || _report(_exceptionable, {
                         path: _path + ".output",
                         expected: "IAutoBeRealizeCoderApplication.RealizeCoderOutput",
                         value: input.output
@@ -363,10 +366,18 @@ const collection = {
                         path: _path + ".filename",
                         expected: "string",
                         value: input.filename
+                    }), undefined === input.errorAnalysis || "string" === typeof input.errorAnalysis || _report(_exceptionable, {
+                        path: _path + ".errorAnalysis",
+                        expected: "(string | undefined)",
+                        value: input.errorAnalysis
                     }), "string" === typeof input.plan || _report(_exceptionable, {
                         path: _path + ".plan",
                         expected: "string",
                         value: input.plan
+                    }), "string" === typeof input.prisma_schemas || _report(_exceptionable, {
+                        path: _path + ".prisma_schemas",
+                        expected: "string",
+                        value: input.prisma_schemas
                     }), "string" === typeof input.draft_without_date_type || _report(_exceptionable, {
                         path: _path + ".draft_without_date_type",
                         expected: "string",

package/lib/orchestrate/realize/orchestrateRealizeCoder.js.map

@@ -1 +1 @@
-{"version":3,"file":"orchestrateRealizeCoder.js","sourceRoot":"","sources":["../../../src/orchestrate/realize/orchestrateRealizeCoder.ts"],"names":[],"mappings":";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;AAAA,yCAAoE;AAQpE,kDAA0B;AAG1B,uEAAoE;AACpE,2DAGkC;AAClC,iEAA8D;AAC9D,uFAAoF;AAIpF,wFAAiE;AACjE,qFAAkF;AAElF;;;;;;;;;;;;;;;;;GAiBG;AACI,MAAM,uBAAuB,GAAG,CACrC,GAAyB,EACzB,SAAmC,EACnC,KAA2B,EAC3B,QAAuB,EACvB,KAAmD,EACnD,WAAyD,EAOzD,EAAE;IACF,KAAK,CAAC;IACN,MAAM,SAAS,GACb,MAAM,IAAA,mDAAwB,EAAC,GAAG,EAAE;QAClC,QAAQ,EAAE;YACR,MAAM,EAAE,SAAS,CAAC,MAAM;YACxB,IAAI,EAAE,SAAS,CAAC,IAAI;SACrB;QACD,YAAY,EAAE,EAAE;KACjB,CAAC,CAAC;IAEL,MAAM,OAAO,GAGD;QACV,KAAK,EAAE,IAAI;KACZ,CAAC;IAEF,MAAM,UAAU,GAAG,iBAAiB,CAAC;QACnC,KAAK,EAAE,GAAG,CAAC,KAAK;QAChB,KAAK,EAAE,CAAC,KAAK,EAAE,EAAE;YACf,OAAO,CAAC,KAAK,GAAG,KAAK,CAAC,MAAM,CAAC;QAC/B,CAAC;KACF,CAAC,CAAC;IAEH,MAAM,KAAK,GAAG,IAAI,oBAAa,CAAC;QAC9B,WAAW,EAAE,CAAC,UAAU,CAAC;QACzB,KAAK,EAAE,GAAG,CAAC,KAAK;QAChB,MAAM,EAAE,GAAG,CAAC,MAAM;QAClB,MAAM,kCACD,GAAG,CAAC,MAAM,KACb,eAAe,EAAE,oCAAqB,EACtC,QAAQ,EAAE;gBACR,QAAQ,EAAE,IAAI;aACf,GACF;QACD,SAAS,EAAE,IAAA,+DAA8B,EACvC,GAAG,CAAC,KAAK,EAAE,EACX,KAAK,EACL,SAAS,EACT,QAAQ,EACR,WAAW,CACZ;KACF,CAAC,CAAC;IACH,IAAA,iCAAe,EAAC,KAAK,CAAC,CAAC;IAEvB,MAAM,IAAA,iCAAkB,EAAC,GAAG,EAAE,CAC5B,KAAK,CAAC,UAAU,CACd;QACE,qFAAqF;QACrF,EAAE;QACF,sDAAsD;QACtD,0FAA0F;QAC1F,0FAA0F;QAC1F,oEAAoE;QACpE,6EAA6E;QAC7E,+DAA+D;QAC/D,iEAAiE;QACjE,EAAE;QACF,iDAAiD;KAClD,CAAC,IAAI,CAAC,IAAI,CAAC,CACb,CACF,CAAC,OAAO,CAAC,GAAG,EAAE;QACb,MAAM,UAAU,GAAG,KAAK,CAAC,aAAa,EAAE,CAAC;QACzC,GAAG,CAAC,KAAK,EAAE,CAAC,MAAM,CAAC,UAAU,EAAE,CAAC,SAAS,CAAC,CAAC,CAAC;IAC9C,CAAC,CAAC,CAAC;IAEH,IAAI,OAAO,CAAC,KAAK,KAAK,IAAI,EAAE,CAAC;QAC3B,OAAO,mCAAM,CAAC;IAChB,CAAC;IAED,OAAO,CAAC,KAAK,CAAC,kBAAkB,GAAG,MAAM,uBAAuB,CAAC,GAAG,CAAC,CACnE,OAAO,CAAC,KAAK,CAAC,kBAAkB,CACjC,CAAC;IAEF,uCACK,OAAO,CAAC,KAAK,KAChB,QAAQ,EAAE,iBAAiB,KAAK,CAAC,YAAY,KAAK,IAClD;AACJ,CAAC,CAAA,CAAC;AA5FW,QAAA,uBAAuB,2BA4FlC;AAEF,SAAS,uBAAuB,CAC9B,GAAyB;IAEzB,OAAO,UAAgB,IAAY;;YACjC,MAAM,QAAQ,GAAoB,MAAM,GAAG,CAAC,QAAQ,EAAE,CAAC;YACvD,IAAI,GAAG,MAAM,QAAQ,CAAC,UAAU,CAAC,QAAQ,CAAC,IAAI,CAAC,CAAC;YAChD,IAAI,GAAG,IAAI;iBACR,UAAU,CAAC,yCAAyC,EAAE,EAAE,CAAC;iBACzD,UAAU,CAAC,sCAAsC,EAAE,EAAE,CAAC;iBACtD,UAAU,CAAC,+BAA+B,EAAE,EAAE,CAAC;iBAC/C,UAAU,CAAC,sCAAsC,EAAE,EAAE,CAAC;iBACtD,UAAU,CAAC,4BAA4B,EAAE,EAAE,CAAC;iBAC5C,UAAU,CAAC,0CAA0C,EAAE,EAAE,CAAC;iBAC1D,UAAU,CAAC,yCAAyC,EAAE,EAAE,CAAC;iBACzD,UAAU,CAAC,2BAA2B,EAAE,EAAE,CAAC,CAAC;YAC/C,IAAI,GAAG;gBACL,yCAAyC;gBACzC,sCAAsC;gBACtC,0CAA0C;gBAC1C,0CAA0C;gBAC1C,4BAA4B;gBAC5B,EAAE;gBACF,IAAI;aACL,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;YAEb,OAAO,IAAI,CAAC;QACd,CAAC;KAAA,CAAC;AACJ,CAAC;AAED,SAAS,iBAAiB,CAAiC,KAG1D;IACC,IAAA,qCAAiB,EAAC,KAAK,CAAC,KAAK,CAAC,CAAC;IAE/B,MAAM,WAAW,GAA2B,UAAU,CACpD,KAAK,CAAC,KAAK,CACyB,CAAC;IAEvC,OAAO;QACL,QAAQ,EAAE,OAAO;QACjB,IAAI,EAAE,YAAY;QAClB,WAAW;QACX,OAAO,EAAE;YACP,WAAW,EAAE,CAAC,IAAI,EAAE,EAAE;gBACpB,KAAK,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC;YACpB,CAAC;SACuC;KAC3C,CAAC;AACJ,CAAC;AAED,MAAM,MAAM;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAMT,CAAC;AACJ,MAAM,UAAU,GAAG;IACjB,OAAO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;KAIJ;IACH,MAAM;IACN,KAAK,EAAE,MAAM;IACb,QAAQ,EAAE,MAAM;IAChB,KAAK,EAAE,MAAM;CACd,CAAC"}
+{"version":3,"file":"orchestrateRealizeCoder.js","sourceRoot":"","sources":["../../../src/orchestrate/realize/orchestrateRealizeCoder.ts"],"names":[],"mappings":";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;AAAA,yCAAoE;AAOpE,kDAA0B;AAG1B,uEAAoE;AACpE,2DAGkC;AAClC,iEAA8D;AAC9D,uFAAoF;AAIpF,wFAAiE;AACjE,qFAAkF;AAClF,6EAA0E;AAE1E;;;;;;;;;;;;;;;;;GAiBG;AACI,MAAM,uBAAuB,GAAG,CACrC,GAAyB,EACzB,SAAmC,EACnC,KAA2B,EAC3B,QAAuB,EACvB,KAAmD,EACnD,WAAyD,EAOzD,EAAE;;IACF,KAAK,CAAC;IAEN,MAAM,SAAS,GACb,MAAM,IAAA,mDAAwB,EAAC,GAAG,EAAE;QAClC,QAAQ,EAAE;YACR,MAAM,EAAE,SAAS,CAAC,MAAM;YACxB,IAAI,EAAE,SAAS,CAAC,IAAI;SACrB;QACD,YAAY,EAAE,EAAE;KACjB,CAAC,CAAC;IAEL,MAAM,OAAO,GAGD;QACV,KAAK,EAAE,IAAI;KACZ,CAAC;IAEF,MAAM,UAAU,GAAG,iBAAiB,CAAC;QACnC,KAAK,EAAE,GAAG,CAAC,KAAK;QAChB,KAAK,EAAE,CAAC,KAAK,EAAE,EAAE;YACf,OAAO,CAAC,KAAK,GAAG,KAAK,CAAC,MAAM,CAAC;QAC/B,CAAC;KACF,CAAC,CAAC;IAEH,MAAM,KAAK,GAAG,IAAI,oBAAa,CAAC;QAC9B,WAAW,EAAE,CAAC,UAAU,CAAC;QACzB,KAAK,EAAE,GAAG,CAAC,KAAK;QAChB,MAAM,EAAE,GAAG,CAAC,MAAM;QAClB,MAAM,kCACD,GAAG,CAAC,MAAM,KACb,eAAe,EAAE,oCAAqB,EACtC,QAAQ,EAAE;gBACR,QAAQ,EAAE,IAAI;aACf,GACF;QACD,SAAS,EAAE,IAAA,+DAA8B,EACvC,GAAG,CAAC,KAAK,EAAE,EACX,KAAK,EACL,SAAS,EACT,QAAQ,EACR,WAAW,CACZ;KACF,CAAC,CAAC;IACH,IAAA,iCAAe,EAAC,KAAK,CAAC,CAAC;IAEvB,MAAM,IAAA,iCAAkB,EAAC,GAAG,EAAE,CAC5B,KAAK,CAAC,UAAU,CACd;QACE,qFAAqF;QACrF,EAAE;QACF,sDAAsD;QACtD,0FAA0F;QAC1F,0FAA0F;QAC1F,oEAAoE;QACpE,6EAA6E;QAC7E,+DAA+D;QAC/D,iEAAiE;QACjE,EAAE;QACF,iDAAiD;KAClD,CAAC,IAAI,CAAC,IAAI,CAAC,CACb,CACF,CAAC,OAAO,CAAC,GAAG,EAAE;QACb,MAAM,UAAU,GAAG,KAAK,CAAC,aAAa,EAAE,CAAC;QACzC,GAAG,CAAC,KAAK,EAAE,CAAC,MAAM,CAAC,UAAU,EAAE,CAAC,SAAS,CAAC,CAAC,CAAC;IAC9C,CAAC,CAAC,CAAC;IAEH,IAAI,OAAO,CAAC,KAAK,KAAK,IAAI,EAAE,CAAC;QAC3B,OAAO,mCAAM,CAAC;IAChB,CAAC;IAED,OAAO,CAAC,KAAK,CAAC,kBAAkB,GAAG,MAAM,IAAA,iDAAuB,EAAC,GAAG,CAAC,CACnE,OAAO,CAAC,KAAK,CAAC,kBAAkB,EAChC,MAAA,KAAK,CAAC,cAAc,0CAAE,OAAO,CAAC,IAAI,CACnC,CAAC;IAEF,OAAO,CAAC,KAAK,CAAC,kBAAkB;QAC9B,OAAO,CAAC,KAAK,CAAC,kBAAkB,CAAC,UAAU,CACzC,mBAAmB,EACnB,cAAc,CACf,CAAC;IAEJ,uCACK,OAAO,CAAC,KAAK,KAChB,QAAQ,EAAE,iBAAiB,KAAK,CAAC,YAAY,KAAK,IAClD;AACJ,CAAC,CAAA,CAAC;AApGW,QAAA,uBAAuB,2BAoGlC;AAEF,SAAS,iBAAiB,CAAiC,KAG1D;IACC,IAAA,qCAAiB,EAAC,KAAK,CAAC,KAAK,CAAC,CAAC;IAE/B,MAAM,WAAW,GAA2B,UAAU,CACpD,KAAK,CAAC,KAAK,CACyB,CAAC;IAEvC,OAAO;QACL,QAAQ,EAAE,OAAO;QACjB,IAAI,EAAE,YAAY;QAClB,WAAW;QACX,OAAO,EAAE;YACP,WAAW,EAAE,CAAC,IAAI,EAAE,EAAE;gBACpB,KAAK,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC;YACpB,CAAC;SACuC;KAC3C,CAAC;AACJ,CAAC;AAED,MAAM,MAAM;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAMT,CAAC;AACJ,MAAM,UAAU,GAAG;IACjB,OAAO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;KAIJ;IACH,MAAM;IACN,KAAK,EAAE,MAAM;IACb,QAAQ,EAAE,MAAM;IAChB,KAAK,EAAE,MAAM;CACd,CAAC"}

package/lib/orchestrate/realize/orchestrateRealizePlanner.d.ts

@@ -1,4 +1,4 @@
-import { AutoBeOpenApi } from "@autobe/interface";
+import { AutoBeOpenApi, AutoBeRealizeAuthorization } from "@autobe/interface";
 import { ILlmSchema } from "@samchon/openapi";
 import { AutoBeContext } from "../../context/AutoBeContext";
 export interface RealizePlannerOutput {
@@ -57,6 +57,15 @@ export interface RealizePlannerOutput {
      * 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
@@ -77,4 +86,4 @@ export interface RealizePlannerOutput {
  * @returns A planning object containing all structural information needed to
  *   generate the function
  */
-export declare const orchestrateRealizePlanner: <Model extends ILlmSchema.Model>(ctx: AutoBeContext<Model>, operation: AutoBeOpenApi.IOperation) => Promise<RealizePlannerOutput>;
+export declare const orchestrateRealizePlanner: <Model extends ILlmSchema.Model>(ctx: AutoBeContext<Model>, operation: AutoBeOpenApi.IOperation, authorization?: AutoBeRealizeAuthorization) => Promise<RealizePlannerOutput>;

package/lib/orchestrate/realize/orchestrateRealizePlanner.js

@@ -29,7 +29,7 @@ exports.orchestrateRealizePlanner = void 0;
  * @returns A planning object containing all structural information needed to
  *   generate the function
  */
-const orchestrateRealizePlanner = (ctx, operation) => __awaiter(void 0, void 0, void 0, function* () {
+const orchestrateRealizePlanner = (ctx, operation, authorization) => __awaiter(void 0, void 0, void 0, function* () {
     var _a, _b;
     const testScenarios = (_b = (_a = ctx
         .state()
@@ -47,6 +47,7 @@ const orchestrateRealizePlanner = (ctx, operation) => __awaiter(void 0, void 0,
             .replaceAll("-", "_")
             .replaceAll("{", "$")
             .replaceAll("}", "")}`,
+        decoratorEvent: authorization,
     };
 });
 exports.orchestrateRealizePlanner = orchestrateRealizePlanner;

package/lib/orchestrate/realize/orchestrateRealizePlanner.js.map

@@ -1 +1 @@
-{"version":3,"file":"orchestrateRealizePlanner.js","sourceRoot":"","sources":["../../../src/orchestrate/realize/orchestrateRealizePlanner.ts"],"names":[],"mappings":";;;;;;;;;;;;AAqEA;;;;;;;;;;;;;;;;;;GAkBG;AACI,MAAM,yBAAyB,GAAG,CACvC,GAAyB,EACzB,SAAmC,EACJ,EAAE;;IACjC,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,OAAO;QACL,WAAW,EAAE,SAAS,CAAC,WAAW;QAClC,UAAU,EAAE,SAAS,CAAC,UAAU;QAChC,WAAW,EAAE,SAAS,CAAC,WAAW;QAClC,YAAY,EAAE,SAAS,CAAC,YAAY;QACpC,aAAa,EAAE,SAAS,CAAC,MAAM;QAC/B,aAAa,EAAE,aAAa,CAAC,GAAG,CAAC,CAAC,EAAE,EAAE,EAAE,CAAC,EAAE,CAAC,QAAQ,CAAC,KAAK,CAAC;QAC3D,YAAY,EAAE,GAAG,SAAS,CAAC,MAAM,IAAI,SAAS,CAAC,IAAI;aAChD,UAAU,CAAC,GAAG,EAAE,GAAG,CAAC;aACpB,UAAU,CAAC,GAAG,EAAE,GAAG,CAAC;aACpB,UAAU,CAAC,GAAG,EAAE,GAAG,CAAC;aACpB,UAAU,CAAC,GAAG,EAAE,EAAE,CAAC,EAAE;KACM,CAAC;AACnC,CAAC,CAAA,CAAC;AA1BW,QAAA,yBAAyB,6BA0BpC"}
+{"version":3,"file":"orchestrateRealizePlanner.js","sourceRoot":"","sources":["../../../src/orchestrate/realize/orchestrateRealizePlanner.ts"],"names":[],"mappings":";;;;;;;;;;;;AA+EA;;;;;;;;;;;;;;;;;;GAkBG;AACI,MAAM,yBAAyB,GAAG,CACvC,GAAyB,EACzB,SAAmC,EACnC,aAA0C,EACX,EAAE;;IACjC,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,OAAO;QACL,WAAW,EAAE,SAAS,CAAC,WAAW;QAClC,UAAU,EAAE,SAAS,CAAC,UAAU;QAChC,WAAW,EAAE,SAAS,CAAC,WAAW;QAClC,YAAY,EAAE,SAAS,CAAC,YAAY;QACpC,aAAa,EAAE,SAAS,CAAC,MAAM;QAC/B,aAAa,EAAE,aAAa,CAAC,GAAG,CAAC,CAAC,EAAE,EAAE,EAAE,CAAC,EAAE,CAAC,QAAQ,CAAC,KAAK,CAAC;QAC3D,YAAY,EAAE,GAAG,SAAS,CAAC,MAAM,IAAI,SAAS,CAAC,IAAI;aAChD,UAAU,CAAC,GAAG,EAAE,GAAG,CAAC;aACpB,UAAU,CAAC,GAAG,EAAE,GAAG,CAAC;aACpB,UAAU,CAAC,GAAG,EAAE,GAAG,CAAC;aACpB,UAAU,CAAC,GAAG,EAAE,EAAE,CAAC,EAAE;QACxB,cAAc,EAAE,aAAa;KACC,CAAC;AACnC,CAAC,CAAA,CAAC;AA5BW,QAAA,yBAAyB,6BA4BpC"}

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

@@ -31,18 +31,88 @@ export declare namespace IAutoBeRealizeCoderApplication {
         /** @ignore */
         filename: string;
         /**
+         * Error Analysis Phase (Optional)
+         *
+         * 🔍 Analyzes TypeScript compilation errors from previous attempts.
+         *
+         * This field should contain a detailed analysis of any TypeScript errors
+         * encountered, with root cause identification and resolution strategies:
+         *
+         * Common Error Patterns to Analyze:
+         *
+         * 1. **"Property does not exist" (TS2353)**:
+         *
+         *    - Root Cause: Using fields that don't exist in Prisma schema
+         *    - Example: Using `deleted_at` when the field doesn't exist in the model
+         *    - Resolution: Remove the non-existent field or use hard delete instead
+         * 2. **"Type 'void' is not assignable" (TS2322)**:
+         *
+         *    - Root Cause: Using `typia.assertGuard` instead of `typia.assert`
+         *    - `assertGuard` returns void, `assert` returns the validated value
+         *    - Resolution: Change `typia.assertGuard<T>()` to `typia.assert<T>()`
+         * 3. **"Type 'Date' is not assignable to type 'string &
+         *    Format<'date-time'>'"**:
+         *
+         *    - Root Cause: Assigning native Date objects to string fields
+         *    - Resolution: Use `toISOStringSafe(dateValue)` for all date conversions
+         * 4. **Complex Prisma Type Errors**:
+         *
+         *    - Root Cause: Nested operations with incompatible types
+         *    - Resolution: Use separate queries and application-level joins
+         *
+         * Analysis Format:
+         *
+         * - List each error with its TypeScript error code
+         * - Identify the root cause (schema mismatch, wrong function usage, etc.)
+         * - Provide specific resolution steps
+         * - Note any schema limitations discovered
+         */
+        errorAnalysis?: string;
+        /**
+         * Step 1.
+         *
          * 🧠 Provider Function Implementation Plan
          *
          * This field outlines the strategic plan for implementing the provider
          * function according to the Realize Coder Agent specification. Before
          * writing the actual code, think through the logic and structure.
          *
-         * The plan must consider:
+         * The plan MUST follow MANDATORY SCHEMA-FIRST APPROACH:
+         *
+         * 📋 STEP 1 - PRISMA SCHEMA VERIFICATION (MOST CRITICAL):
+         *
+         * - 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`
+         *
+         * 📋 STEP 2 - FIELD INVENTORY:
+         *
+         * - List ONLY fields confirmed to exist in schema
+         * - Example: "Verified fields in user model: id (String), email (String),
+         *   created_at (DateTime), updated_at (DateTime)"
+         * - Example: "Fields that DO NOT exist: deleted_at, is_active, created_by"
+         *
+         * 📋 STEP 3 - FIELD ACCESS STRATEGY:
+         *
+         * - Plan which verified fields will be used in select, update, create
+         *   operations
+         * - For complex operations with type errors, plan to use separate queries
+         *   instead of nested operations
+         *
+         * 📋 STEP 4 - TYPE COMPATIBILITY:
+         *
+         * - Plan DateTime to ISO string conversions using toISOStringSafe()
+         * - Plan handling of nullable vs required fields
+         *
+         * 📋 STEP 5 - IMPLEMENTATION APPROACH:
          *
          * - 🧩 Required business entities (e.g., users, posts, logs) and their
          *   relationships
          * - 🛠 Operations needed to fulfill the business scenario (e.g., fetch,
-         *   create, update)
+         *   create, update) using ONLY verified fields
          * - 🔄 Data dependencies between steps (e.g., use userId to fetch related
          *   data)
          * - ✅ Validation points (based on business rules, not field presence)
@@ -64,7 +134,7 @@ export declare namespace IAutoBeRealizeCoderApplication {
          * ⚠️ TypeScript-specific considerations:
          *
          * - Do **not** use native `Date` objects directly; always convert all dates
-         *   to ISO strings with `.toISOString()` and brand as `string &
+         *   using `toISOStringSafe()` and brand as `string &
          *   tags.Format<'date-time'>`. This rule applies throughout all phases.
          * - Prefer `satisfies` for DTO conformance instead of unsafe `as` casts
          * - Avoid weak typing such as `any`, `as any`, or `satisfies any`
@@ -88,6 +158,18 @@ export declare namespace IAutoBeRealizeCoderApplication {
          * }
          * ```
          *
+         * 🔍 Feasibility Analysis Requirement:
+         *
+         * - Before generating any code, the agent **must analyze** whether the
+         *   requested implementation is **feasible based on the given Prisma schema
+         *   and DTO types**.
+         * - If required fields or relationships are **missing or incompatible**, the
+         *   plan should explicitly state that the implementation is **not
+         *   possible** with the current schema/DTO, and no code should be generated
+         *   in later stages.
+         * - In such cases, only a detailed **comment in the `implementationCode`**
+         *   should be returned explaining why the logic cannot be implemented.
+         *
          * 🔥 Error Handling Plan:
          *
          * If an error is expected or encountered during implementation:
@@ -112,10 +194,34 @@ export declare namespace IAutoBeRealizeCoderApplication {
          */
         plan: string;
         /**
-         * ✏️ Phase 1: Draft code
+         * Step 2.
+         *
+         * The Prisma schema string that will be used to validate the implementation
+         * logic in this file.
+         *
+         * You must **explicitly specify only the relevant models and fields** from
+         * your full schema that are used in this implementation. This ensures that
+         * your logic is aligned with the expected database structure without
+         * accidentally introducing unrelated fields or models.
+         *
+         * ⚠️ Important: The value of this field must be a valid Prisma schema
+         * string containing only the models used in this code — not the entire
+         * schema.
+         *
+         * This acts as a safeguard against:
+         *
+         * - Forgetting required fields used in this implementation
+         * - Including fields or models that are not actually used
+         */
+        prisma_schemas: string;
+        /**
+         * Step 3.
+         *
+         * Draft WITHOUT using native Date type.
          *
          * This is the initial drafting phase where you outline the basic skeleton
-         * of the function.
+         * of the function. CRITICAL: This draft must NEVER use the native Date
+         * type.
          *
          * - The function signature must correctly include `user`, `parameters`, and
          *   `body` arguments.
@@ -135,13 +241,14 @@ export declare namespace IAutoBeRealizeCoderApplication {
          * ✅ Requirements:
          *
          * - Avoid using the `any` type at all costs to ensure type safety.
-         * - Do NOT assign native `Date` objects directly; always convert dates using
-         *   `.toISOString()` before assignment and apply proper branding.
+         * - NEVER declare variables with `: Date` type
+         * - ALWAYS use `string & tags.Format<'date-time'>` for date values
+         * - Use `toISOStringSafe(new Date())` for current timestamps
          * - Maintain a single-function structure; avoid using classes.
          */
         draft_without_date_type: string;
         /**
-         * 🔍 Phase 2: Review code
+         * Step 4.
          *
          * A refined version of the draft with improved completeness.
          *
@@ -153,12 +260,12 @@ export declare namespace IAutoBeRealizeCoderApplication {
          *
          * - Use `satisfies` to ensure DTO conformity.
          * - Avoid unsafe `as` casts unless only for branding or literal narrowing.
-         * - Include `.toISOString()` for all date fields.
+         * - Use `toISOStringSafe()` for all date conversions (NOT `.toISOString()`).
          * - Ensure all object keys strictly conform to the expected type definitions.
          */
         review: string;
         /**
-         * 🛠 Phase 3: With compiler feedback (optional)
+         * 🛠 Phase 4-2: With compiler feedback (optional)
          *
          * A correction pass that applies fixes for compile-time errors that arose
          * during the review stage (if any).
@@ -173,25 +280,45 @@ export declare namespace IAutoBeRealizeCoderApplication {
          */
         withCompilerFeedback?: string;
         /**
-         * ✅ Phase 4: Final implementation
+         * Step 5.
          *
          * The complete and fully correct TypeScript function implementation.
          *
          * - Passes strict type checking without errors.
          * - Uses only safe branding or literal type assertions.
-         * - Converts all date values properly to ISO string format.
+         * - Converts all date values properly using `toISOStringSafe()`.
          * - Follows DTO structures using `satisfies`.
          * - Avoids any weak typing such as `any`, `as any`, or `satisfies any`.
-         * - Uses only allowed imports (e.g., from `src/api/structures` and
+         * - Uses only allowed imports (e.g., from `../api/structures` and
          *   `MyGlobal.prisma`).
+         * - NEVER creates intermediate variables for Prisma operations.
+         *
+         * ⚠️ Fallback Behavior:
+         *
+         * - If the `plan` phase explicitly determines that the requested logic is
+         *   **not feasible** due to mismatches or limitations in the provided
+         *   Prisma schema and DTO types:
+         *
+         *   - The implementation must still return a syntactically valid function.
+         *   - In such cases, return mock data using `typia.random<T>()` wrapped in the
+         *       correct structure, along with a comment explaining the limitation.
+         *
+         *   Example fallback:
+         *
+         * ```ts
+         *   // ⚠️ Cannot implement logic due to missing relation between A and B
+         *   export async function someFunction(...) {
+         *     return typia.random<IReturn>(); // mocked output
+         *   }
+         * ```
          *
          * ⚠️ Prohibited Practices:
          *
          * - Do NOT add or modify import statements manually. Imports are handled
          *   automatically by the system.
          * - Do NOT use `any`, `as any`, or `satisfies any` to bypass type checking.
-         * - Do NOT assign native `Date` objects directly; always convert them to ISO
-         *   strings with `.toISOString()`.
+         * - Do NOT assign native `Date` objects directly; always convert them using
+         *   `toISOStringSafe()`.
          * - Do NOT use unsafe type assertions except for safe branding or literal
          *   narrowing.
          * - Do NOT write code outside the single async function structure (e.g., no
@@ -200,8 +327,12 @@ export declare namespace IAutoBeRealizeCoderApplication {
          *   validated.
          * - Do NOT use dynamic import expressions (`import()`); all imports must be
          *   static.
-         * - Do NOT rely on DTO types for database update input; always use
-         *   Prisma-generated input types.
+         * - Do NOT use Prisma-generated input types; always use types from
+         *   `../api/structures`.
+         * - Do NOT use `Object.prototype.hasOwnProperty.call()` for field checks.
+         * - Do NOT escape newlines or quotes in the implementation string (e.g., no
+         *   `\\n` or `\"`); use a properly formatted template literal with actual
+         *   line breaks instead.
          */
         implementationCode: string;
     }