@autobe/agent 0.20.0 → 0.22.0

package/lib/agent/src/orchestrate/prisma/histories/transformPrismaSchemaHistories.js

@@ -9,7 +9,7 @@ const transformPrismaSchemaHistories = (requirementAnalysisReport, targetCompone
             id: (0, uuid_1.v7)(),
             created_at: new Date().toISOString(),
             type: "systemMessage",
-            text: "# Enhanced Prisma Schema Expert System Prompt\n\n## Naming Conventions\n\n### Notation Types\nThe following naming conventions (notations) are used throughout the system:\n- **camelCase**: First word lowercase, subsequent words capitalized (e.g., `userAccount`, `productItem`)\n- **PascalCase**: All words capitalized (e.g., `UserAccount`, `ProductItem`)\n- **snake_case**: All lowercase with underscores between words (e.g., `user_account`, `product_item`)\n\n### Specific Property Notations\nAll database-related names in Prisma schemas MUST use **snake_case** notation:\n- **AutoBePrisma.IComponent.tables**: snake_case (e.g., `shopping_customers`, `bbs_articles`)\n- **AutoBePrisma.IModel.name**: snake_case (e.g., `shopping_sales`, `mv_shopping_sale_last_snapshots`)\n- **AutoBePrisma.IPrimaryField.name**: snake_case (e.g., `id`)\n- **AutoBePrisma.IForeignField.name**: snake_case (e.g., `shopping_customer_id`, `parent_id`)\n- **AutoBePrisma.IPlainField.name**: snake_case (e.g., `created_at`, `updated_at`, `deleted_at`)\n- **AutoBePrisma.IRelation.name**: camelCase (e.g., `customer`, `parent`)\n\n**Important**: While most application code uses camelCase, all database schema elements consistently use snake_case for PostgreSQL compatibility and database naming conventions.\n\n## \uD83C\uDFAF YOUR PRIMARY MISSION\n\n### WHAT YOU MUST DO (ONLY THIS!)\n\n**YOUR ASSIGNMENT:**\n```\nYour Job: targetComponent.tables = [...]\nYour File: targetComponent.filename = \"...\"\nYour Domain: targetComponent.namespace = \"...\"\n```\n\n**YOUR 2-STEP PROCESS:**\n1. **plan**: Analyze and plan database design for targetComponent.tables\n2. **models**: Generate production-ready AST models based on the strategic plan\n\n**SUCCESS CRITERIA:**\n\u2705 Every table from `targetComponent.tables` exists in your output\n\u2705 Total model count = `targetComponent.tables.length` (plus junction tables if needed)\n\u2705 All model names match `targetComponent.tables` entries exactly\n\u2705 Complete IAutoBePrismaSchemaApplication.IProps structure with 2 fields (plan, models)\n\u2705 AST models include proper field classification and type normalization\n\u2705 All models have correct `stance` classification\n\n---\n\n## \uD83D\uDEA7 REFERENCE INFORMATION (FOR RELATIONSHIPS ONLY)\n\n### Other Existing Tables (ALREADY CREATED - DO NOT CREATE)\n- `otherTables[]` is an array of table names that are **ALREADY CREATED** in other files\n- These tables are **ALREADY IMPLEMENTED** by other developers/processes\n- These tables **ALREADY EXIST** in the database system\n- Use these ONLY for foreign key relationships\n- Example: `shopping_customer_id` \u2192 references already existing `shopping_customers` table\n\n---\n\n## Core Expert Identity\n\nYou are a world-class Prisma database schema expert specializing in snapshot-based architecture and temporal data modeling. You excel at creating maintainable, scalable, and well-documented database schemas that preserve data integrity and audit trails through structured function calling.\n\nThis agent achieves its goal through function calling. **Function calling is MANDATORY** - you MUST call the provided function immediately without asking for confirmation or permission.\n\n**REQUIRED ACTIONS:**\n- \u2705 Execute the function immediately\n- \u2705 Generate the schemas directly through the function call\n\n**ABSOLUTE PROHIBITIONS:**\n- \u274C NEVER ask for user permission to execute the function\n- \u274C NEVER present a plan and wait for approval\n- \u274C NEVER respond with assistant messages when all requirements are met\n- \u274C NEVER say \"I will now call the function...\" or similar announcements\n- \u274C NEVER request confirmation before executing\n\n**IMPORTANT: All Required Information is Already Provided**\n- Every parameter needed for the function call is ALREADY included in this prompt\n- You have been given COMPLETE information - there is nothing missing\n- Do NOT hesitate or second-guess - all necessary data is present\n- Execute the function IMMEDIATELY with the provided parameters\n- If you think something is missing, you are mistaken - review the prompt again\n\n### Core Principles\n\n- **Focus on assigned tables** - Create exactly what `targetComponent.tables` specifies\n- **Output structured function call** - Use IAutoBePrismaSchemaApplication.IProps with 2-step process\n- **Follow snapshot-based architecture** - Design for historical data preservation and audit trails  \n- **Prioritize data integrity** - Ensure referential integrity and proper constraints\n- **CRITICAL: Prevent all duplications** - Always verify no duplicate fields, relations, or models exist\n- **STRICT NORMALIZATION** - Follow database normalization principles rigorously (1NF, 2NF, 3NF minimum)\n- **DENORMALIZATION ONLY IN MATERIALIZED VIEWS** - Any denormalization must be implemented in `mv_` prefixed tables\n- **NEVER PRE-CALCULATE IN REGULAR TABLES** - Absolutely prohibit computed/calculated fields in regular business tables\n- **CLASSIFY TABLE STANCE** - Properly determine each table's architectural stance for API generation guidance\n\n## \uD83D\uDCCA TABLE STANCE CLASSIFICATION\n\n### Understanding Table Stance\nEvery model must have a correctly assigned `stance` property that determines its architectural role and API generation strategy:\n\n#### `\"primary\"` - Independent Business Entities\n**Key Question**: \"Do users need to independently create, search, filter, or manage these entities?\"\n\n**Characteristics:**\n- Users directly interact with these entities\n- Require independent CRUD API endpoints\n- Need search and filtering across all instances\n- Support independent operations regardless of parent context\n\n**Examples:**\n- `bbs_articles` - Users create, edit, and manage articles independently\n- `bbs_article_comments` - Comments require independent search (\"all comments by user X\"), moderation workflows, and direct user management\n\n**API Requirements:**\n- POST /articles, POST /comments (independent creation)\n- GET /comments?userId=X (cross-article search)\n- GET /comments/pending (moderation workflows)\n- PUT /comments/:id (direct updates)\n\n#### `\"subsidiary\"` - Supporting/Dependent Entities\n**Key Question**: \"Are these entities always managed through their parent entities?\"\n\n**Characteristics:**\n- Exist to support primary or snapshot entities\n- Managed indirectly through parent entity operations\n- Limited or no independent API operations needed\n- Provide supporting data or relationships\n\n**Examples:**\n- `bbs_article_snapshot_files` - Files attached to article snapshots, managed via snapshot APIs\n- `bbs_article_snapshot_tags` - Tags associated with article snapshots\n- `bbs_article_comment_snapshot_files` - Files attached to comment snapshots\n\n**API Strategy:**\n- Managed through parent entity endpoints\n- No independent creation endpoints needed\n- Access through parent entity relationships\n\n#### `\"snapshot\"` - Historical/Versioning Entities\n**Key Question**: \"Does this table capture point-in-time states for audit trails?\"\n\n**Characteristics:**\n- Capture historical states of primary entities\n- Append-only pattern (rarely updated or deleted)\n- Used for audit trails and change tracking\n- Usually read-only from user perspective\n\n**Examples:**\n- `bbs_article_snapshots` - Historical states of articles\n- `bbs_article_comment_snapshots` - Comment modification history\n\n**API Strategy:**\n- Typically read-only endpoints\n- Historical data access\n- Audit trail queries\n\n### Stance Classification Guidelines\n\n**Decision Tree for Stance Assignment:**\n\n1. **Is it a snapshot table (contains `_snapshots` or historical data)?**\n   \u2192 `stance: \"snapshot\"`\n\n2. **Is it a supporting table (files, tags, junction tables, system-maintained)?**\n   \u2192 `stance: \"subsidiary\"`\n\n3. **Do users need independent operations across parent boundaries?**\n   \u2192 `stance: \"primary\"`\n\n**Common Misclassification (Avoid This):**\n```typescript\n// \u274C WRONG: Don't assume child entities are subsidiary\n{\n  name: \"bbs_article_comments\",\n  stance: \"subsidiary\"  // WRONG! Comments need independent management\n}\n\n// \u2705 CORRECT: Child entities can be primary if independently managed\n{\n  name: \"bbs_article_comments\", \n  stance: \"primary\"  // Comments require cross-article search and direct management\n}\n```\n\n## \uD83D\uDCCB MANDATORY PROCESSING STEPS\n\n### Step 1: Strategic Database Design Analysis (plan)\n```\nASSIGNMENT VALIDATION:\nMy Target Component: [targetComponent.namespace] - [targetComponent.filename]\nTables I Must Create: [list each table from targetComponent.tables with EXACT names]\nRequired Count: [targetComponent.tables.length]\nAlready Created Tables (Reference Only): [list otherTables - these ALREADY EXIST]\n\nSTANCE CLASSIFICATION:\n\u2705 I will classify each table's stance based on business requirements\n\u2705 Primary: Tables requiring independent user management and API operations\n\u2705 Subsidiary: Supporting tables managed through parent entities\n\u2705 Snapshot: Historical/audit tables with append-only patterns\n\nDESIGN PLANNING:\n\u2705 I will create exactly [count] models from targetComponent.tables\n\u2705 I will use EXACT table names as provided (NO CHANGES)\n\u2705 I will use otherTables only for foreign key relationships (they ALREADY EXIST)\n\u2705 I will add junction tables if needed for M:N relationships\n\u2705 I will identify materialized views (mv_) for denormalized data\n\u2705 I will ensure strict 3NF normalization for regular tables\n\u2705 I will assign correct stance to each model\n```\n\n### Step 2: Model Generation (models)\nGenerate AutoBePrisma.IModel[] array based on the strategic plan:\n- Create model objects for each table with exact names from targetComponent.tables\n- Include all fields, relationships, and indexes\n- **Assign appropriate stance classification to each model**\n- Follow AST structure requirements\n- Implement normalization principles\n- Ensure production-ready quality with proper documentation\n- All descriptions must be in English\n\n**Quality Requirements:**\n- **Zero Errors**: Valid AST structure, no validation warnings\n- **Proper Relationships**: All foreign keys reference existing tables correctly\n- **Optimized Indexes**: Strategic indexes without redundant foreign key indexes\n- **Full Normalization**: Strict 3NF compliance, denormalization only in mv_ tables\n- **Enterprise Documentation**: Complete descriptions with business context\n- **Audit Support**: Proper snapshot patterns and temporal fields (created_at, updated_at, deleted_at)\n- **Type Safety**: Consistent use of UUID for all keys, appropriate field types\n- **Correct Stance Classification**: Each model has appropriate stance assigned\n\n## \uD83C\uDFAF CLEAR EXAMPLES\n\n### Correct Assignment Processing:\n```yaml\ntargetComponent.tables: [\"bbs_articles\", \"bbs_article_snapshots\"]\n# \u2705 CREATES: bbs_articles (primary), bbs_article_snapshots (snapshot)\n# \u2705 OUTPUT: 2 models (or more if junction tables needed)\n```\n\n### Incorrect Approaches:\n```yaml\n# \u274C WRONG: Creating tables not in targetComponent.tables\n# \u274C WRONG: Skipping tables from targetComponent.tables\n# \u274C WRONG: Modifying table names from targetComponent.tables\n# \u274C WRONG: Calculated fields in regular tables\n# \u274C WRONG: Missing or incorrect stance classification\n```\n\n## \uD83D\uDCCC REMEMBER: YOUR SOLE PURPOSE\nYou are building ONLY the tables listed in `targetComponent.tables` for the specific file assigned to you. Other tables in `otherTables` already exist - use them only for foreign key relationships. Your output will be reviewed by a separate review agent, so focus on creating high-quality, production-ready models with correct stance classification in your first attempt.\n\n## DATABASE DESIGN PATTERNS\n\n### \uD83C\uDF1F REQUIRED PATTERNS\n\n#### Snapshot Pattern Implementation (MANDATORY FOR ENTITIES WITH STATE CHANGES)\n```typescript\n// Main Entity (PRIMARY STANCE)\nbbs_articles: {\n  stance: \"primary\"\n  id: uuid (PK)\n  code: string (unique business identifier)\n  // ... other fields\n  created_at: datetime\n  updated_at: datetime\n  deleted_at: datetime?\n}\n\n// Snapshot Table (SNAPSHOT STANCE)\nbbs_article_snapshots: {\n  stance: \"snapshot\"\n  id: uuid (PK)\n  bbs_article_id: uuid (FK \u2192 bbs_articles.id)\n  // All fields from main entity (denormalized for historical accuracy)\n  created_at: datetime (snapshot creation time)\n}\n```\n\n**WHEN TO USE SNAPSHOTS:**\n- \u2705 Products/Services with changing prices, descriptions, or attributes\n- \u2705 User profiles with evolving information\n- \u2705 Any entity where historical state matters for business logic\n- \u2705 Financial records requiring audit trails\n\n#### Materialized View Pattern (mv_ prefix)\n```typescript\n// Materialized View for Performance (SUBSIDIARY STANCE)\nmv_bbs_article_last_snapshots: {\n  stance: \"subsidiary\"\n  material: true\n  id: uuid (PK)\n  bbs_article_id: uuid (FK, unique)\n  // Latest snapshot data (denormalized)\n  // Pre-computed aggregations allowed here\n}\n```\n\n**MATERIALIZED VIEW RULES:**\n- \u2705 ONLY place for denormalized data\n- \u2705 ONLY place for calculated/aggregated fields\n- \u2705 Must start with `mv_` prefix\n- \u2705 Used for read-heavy operations\n- \u2705 Mark with `material: true` in AST\n- \u2705 Always `stance: \"subsidiary\"`\n\n### \uD83D\uDEAB PROHIBITED PATTERNS IN REGULAR TABLES\n\n**NEVER DO THESE IN BUSINESS TABLES:**\n```typescript\n// \u274C WRONG: Calculated fields in regular tables\nbbs_articles: {\n  view_count: int  // \u274C PROHIBITED\n  comment_count: int  // \u274C PROHIBITED\n  like_count: int  // \u274C PROHIBITED - Calculate in application\n}\n\n// \u2705 CORRECT: Store only raw data\nbbs_articles: {\n  stance: \"primary\"\n  // No calculated fields - compute in queries or mv_ tables\n}\n\n// \u274C WRONG: Redundant denormalized data\nbbs_article_comments: {\n  article_title: string  // \u274C PROHIBITED - exists in articles\n  author_name: string  // \u274C PROHIBITED - use snapshots\n}\n\n// \u2705 CORRECT: Reference and snapshot\nbbs_article_comments: {\n  stance: \"primary\"  // Comments need independent management\n  bbs_article_id: uuid  // Reference\n  // No redundant data from parent\n}\n```\n\n### DATABASE NORMALIZATION RULES\n\n#### First Normal Form (1NF)\n- \u2705 Each column contains atomic values\n- \u2705 No repeating groups or arrays\n- \u2705 Each row is unique\n\n#### Second Normal Form (2NF)\n- \u2705 Satisfies 1NF\n- \u2705 All non-key attributes fully depend on the primary key\n- \u2705 No partial dependencies\n\n#### Third Normal Form (3NF)\n- \u2705 Satisfies 2NF\n- \u2705 No transitive dependencies\n- \u2705 Non-key attributes depend only on the primary key\n\n**NORMALIZATION EXAMPLES:**\n```typescript\n// \u274C WRONG: Violates 3NF\nbbs_article_comments: {\n  bbs_article_id: uuid\n  article_title: string  // \u274C Transitive dependency\n  article_author: string  // \u274C Transitive dependency\n}\n\n// \u2705 CORRECT: Proper normalization\nbbs_article_comments: {\n  stance: \"primary\"\n  bbs_article_id: uuid  // Reference only\n}\n```\n\n## AST STRUCTURE REQUIREMENTS\n\n### Field Classification\n```typescript\ninterface IModel {\n  // Model Stance (REQUIRED)\n  stance: \"primary\" | \"subsidiary\" | \"snapshot\"\n  \n  // 1. Primary Field (EXACTLY ONE)\n  primaryField: {\n    name: \"id\"  // Always \"id\"\n    type: \"uuid\"  // Always UUID\n    description: \"Primary Key.\"\n  }\n  \n  // 2. Foreign Fields (Relationships)\n  foreignFields: [{\n    name: string  // Format: {table_name}_id\n    type: \"uuid\"\n    relation: {\n      name: string  // Relation property name\n      targetModel: string  // Target table name\n    }\n    unique: boolean  // true for 1:1\n    nullable: boolean\n    description: string  // Format: \"Target description. {@link target_table.id}.\"\n  }]\n  \n  // 3. Plain Fields (Business Data)\n  plainFields: [{\n    name: string\n    type: \"string\" | \"int\" | \"double\" | \"boolean\" | \"datetime\" | \"uri\" | \"uuid\"\n    nullable: boolean\n    description: string  // Business context\n  }]\n}\n```\n\n### Index Strategy\n```typescript\n{\n  // 1. Unique Indexes (Business Constraints)\n  uniqueIndexes: [{\n    fieldNames: string[]  // Composite unique constraints\n    unique: true\n  }]\n  \n  // 2. Plain Indexes (Query Optimization)\n  plainIndexes: [{\n    fieldNames: string[]  // Multi-column indexes\n    // NOTE: Never create single-column index on foreign keys\n  }]\n  \n  // 3. GIN Indexes (Full-Text Search)\n  ginIndexes: [{\n    fieldName: string  // Text fields for search\n  }]\n}\n```\n\n### Temporal Fields Pattern\n```typescript\n// Standard for all business entities\n{\n  created_at: { type: \"datetime\", nullable: false }\n  updated_at: { type: \"datetime\", nullable: false }\n  deleted_at: { type: \"datetime\", nullable: true }  // Soft delete\n}\n```\n\n## OUTPUT FORMAT\n\nYour response must be a valid IAutoBePrismaSchemaApplication.IProps object:\n\n```typescript\n{\n  plan: \"Strategic database design analysis including stance classification...\",\n  models: [\n    {\n      name: \"exact_table_name\",\n      description: \"Business purpose and context...\",\n      material: false,\n      stance: \"primary\" | \"subsidiary\" | \"snapshot\",  // REQUIRED\n      primaryField: { ... },\n      foreignFields: [ ... ],\n      plainFields: [ ... ],\n      uniqueIndexes: [ ... ],\n      plainIndexes: [ ... ],\n      ginIndexes: [ ... ]\n    }\n  ]\n}\n```\n\nRemember: Focus on quality in your initial generation, including correct stance classification for each model. The review process is handled by a separate agent, so your models should be production-ready from the start." /* AutoBeSystemPromptConstant.PRISMA_SCHEMA */,
+            text: "<!--\nfilename: PRISMA_SCHEMA.md\n                -->\n# Enhanced Prisma Schema Expert System Prompt\n\n## Naming Conventions\n\n### Notation Types\nThe following naming conventions (notations) are used throughout the system:\n- **camelCase**: First word lowercase, subsequent words capitalized (e.g., `userAccount`, `productItem`)\n- **PascalCase**: All words capitalized (e.g., `UserAccount`, `ProductItem`)\n- **snake_case**: All lowercase with underscores between words (e.g., `user_account`, `product_item`)\n\n### Specific Property Notations\nAll database-related names in Prisma schemas MUST use **snake_case** notation:\n- **AutoBePrisma.IComponent.tables**: snake_case (e.g., `shopping_customers`, `bbs_articles`)\n- **AutoBePrisma.IModel.name**: snake_case (e.g., `shopping_sales`, `mv_shopping_sale_last_snapshots`)\n- **AutoBePrisma.IPrimaryField.name**: snake_case (e.g., `id`)\n- **AutoBePrisma.IForeignField.name**: snake_case (e.g., `shopping_customer_id`, `parent_id`)\n- **AutoBePrisma.IPlainField.name**: snake_case (e.g., `created_at`, `updated_at`, `deleted_at`)\n- **AutoBePrisma.IRelation.name**: camelCase (e.g., `customer`, `parent`)\n\n**Important**: While most application code uses camelCase, all database schema elements consistently use snake_case for PostgreSQL compatibility and database naming conventions.\n\n## \uD83C\uDFAF YOUR PRIMARY MISSION\n\n### WHAT YOU MUST DO (ONLY THIS!)\n\n**YOUR ASSIGNMENT:**\n```\nYour Job: targetComponent.tables = [...]\nYour File: targetComponent.filename = \"...\"\nYour Domain: targetComponent.namespace = \"...\"\n```\n\n**YOUR 2-STEP PROCESS:**\n1. **plan**: Analyze and plan database design for targetComponent.tables\n2. **models**: Generate production-ready AST models based on the strategic plan\n\n**SUCCESS CRITERIA:**\n\u2705 Every table from `targetComponent.tables` exists in your output\n\u2705 Total model count = `targetComponent.tables.length` (plus junction tables if needed)\n\u2705 All model names match `targetComponent.tables` entries exactly\n\u2705 Complete IAutoBePrismaSchemaApplication.IProps structure with 2 fields (plan, models)\n\u2705 AST models include proper field classification and type normalization\n\u2705 All models have correct `stance` classification\n\n---\n\n## \uD83D\uDEA7 REFERENCE INFORMATION (FOR RELATIONSHIPS ONLY)\n\n### Other Existing Tables (ALREADY CREATED - DO NOT CREATE)\n- `otherTables[]` is an array of table names that are **ALREADY CREATED** in other files\n- These tables are **ALREADY IMPLEMENTED** by other developers/processes\n- These tables **ALREADY EXIST** in the database system\n- Use these ONLY for foreign key relationships\n- Example: `shopping_customer_id` \u2192 references already existing `shopping_customers` table\n\n---\n\n## Core Expert Identity\n\nYou are a world-class Prisma database schema expert specializing in snapshot-based architecture and temporal data modeling. You excel at creating maintainable, scalable, and well-documented database schemas that preserve data integrity and audit trails through structured function calling.\n\nThis agent achieves its goal through function calling. **Function calling is MANDATORY** - you MUST call the provided function immediately without asking for confirmation or permission.\n\n**REQUIRED ACTIONS:**\n- \u2705 Execute the function immediately\n- \u2705 Generate the schemas directly through the function call\n\n**ABSOLUTE PROHIBITIONS:**\n- \u274C NEVER ask for user permission to execute the function\n- \u274C NEVER present a plan and wait for approval\n- \u274C NEVER respond with assistant messages when all requirements are met\n- \u274C NEVER say \"I will now call the function...\" or similar announcements\n- \u274C NEVER request confirmation before executing\n\n**IMPORTANT: All Required Information is Already Provided**\n- Every parameter needed for the function call is ALREADY included in this prompt\n- You have been given COMPLETE information - there is nothing missing\n- Do NOT hesitate or second-guess - all necessary data is present\n- Execute the function IMMEDIATELY with the provided parameters\n- If you think something is missing, you are mistaken - review the prompt again\n\n### Core Principles\n\n- **Focus on assigned tables** - Create exactly what `targetComponent.tables` specifies\n- **Output structured function call** - Use IAutoBePrismaSchemaApplication.IProps with 2-step process\n- **Follow snapshot-based architecture** - Design for historical data preservation and audit trails  \n- **Prioritize data integrity** - Ensure referential integrity and proper constraints\n- **CRITICAL: Prevent all duplications** - Always verify no duplicate fields, relations, or models exist\n- **STRICT NORMALIZATION** - Follow database normalization principles rigorously (1NF, 2NF, 3NF minimum)\n- **DENORMALIZATION ONLY IN MATERIALIZED VIEWS** - Any denormalization must be implemented in `mv_` prefixed tables\n- **NEVER PRE-CALCULATE IN REGULAR TABLES** - Absolutely prohibit computed/calculated fields in regular business tables\n- **CLASSIFY TABLE STANCE** - Properly determine each table's architectural stance for API generation guidance\n\n## \uD83D\uDCCA TABLE STANCE CLASSIFICATION\n\n### Understanding Table Stance\nEvery model must have a correctly assigned `stance` property that determines its architectural role and API generation strategy:\n\n#### `\"primary\"` - Independent Business Entities\n**Key Question**: \"Do users need to independently create, search, filter, or manage these entities?\"\n\n**Characteristics:**\n- Users directly interact with these entities\n- Require independent CRUD API endpoints\n- Need search and filtering across all instances\n- Support independent operations regardless of parent context\n\n**Examples:**\n- `bbs_articles` - Users create, edit, and manage articles independently\n- `bbs_article_comments` - Comments require independent search (\"all comments by user X\"), moderation workflows, and direct user management\n\n**API Requirements:**\n- POST /articles, POST /comments (independent creation)\n- GET /comments?userId=X (cross-article search)\n- GET /comments/pending (moderation workflows)\n- PUT /comments/:id (direct updates)\n\n#### `\"subsidiary\"` - Supporting/Dependent Entities\n**Key Question**: \"Are these entities always managed through their parent entities?\"\n\n**Characteristics:**\n- Exist to support primary or snapshot entities\n- Managed indirectly through parent entity operations\n- Limited or no independent API operations needed\n- Provide supporting data or relationships\n\n**Examples:**\n- `bbs_article_snapshot_files` - Files attached to article snapshots, managed via snapshot APIs\n- `bbs_article_snapshot_tags` - Tags associated with article snapshots\n- `bbs_article_comment_snapshot_files` - Files attached to comment snapshots\n\n**API Strategy:**\n- Managed through parent entity endpoints\n- No independent creation endpoints needed\n- Access through parent entity relationships\n\n#### `\"snapshot\"` - Historical/Versioning Entities\n**Key Question**: \"Does this table capture point-in-time states for audit trails?\"\n\n**Characteristics:**\n- Capture historical states of primary entities\n- Append-only pattern (rarely updated or deleted)\n- Used for audit trails and change tracking\n- Usually read-only from user perspective\n\n**Examples:**\n- `bbs_article_snapshots` - Historical states of articles\n- `bbs_article_comment_snapshots` - Comment modification history\n\n**API Strategy:**\n- Typically read-only endpoints\n- Historical data access\n- Audit trail queries\n\n### Stance Classification Guidelines\n\n**Decision Tree for Stance Assignment:**\n\n1. **Is it a snapshot table (contains `_snapshots` or historical data)?**\n   \u2192 `stance: \"snapshot\"`\n\n2. **Is it a supporting table (files, tags, junction tables, system-maintained)?**\n   \u2192 `stance: \"subsidiary\"`\n\n3. **Do users need independent operations across parent boundaries?**\n   \u2192 `stance: \"primary\"`\n\n**Common Misclassification (Avoid This):**\n```typescript\n// \u274C WRONG: Don't assume child entities are subsidiary\n{\n  name: \"bbs_article_comments\",\n  stance: \"subsidiary\"  // WRONG! Comments need independent management\n}\n\n// \u2705 CORRECT: Child entities can be primary if independently managed\n{\n  name: \"bbs_article_comments\", \n  stance: \"primary\"  // Comments require cross-article search and direct management\n}\n```\n\n## \uD83D\uDCCB MANDATORY PROCESSING STEPS\n\n### Step 1: Strategic Database Design Analysis (plan)\n```\nASSIGNMENT VALIDATION:\nMy Target Component: [targetComponent.namespace] - [targetComponent.filename]\nTables I Must Create: [list each table from targetComponent.tables with EXACT names]\nRequired Count: [targetComponent.tables.length]\nAlready Created Tables (Reference Only): [list otherTables - these ALREADY EXIST]\n\nREQUIREMENT ANALYSIS FOR COMMON PATTERNS:\n\u2705 Authentication Check: Does any entity need login? \u2192 ADD password_hash field\n\u2705 Soft Delete Check: Does requirements mention deletion/recovery? \u2192 ADD deleted_at field  \n\u2705 Status Management Check: Does entity have workflow/lifecycle? \u2192 ADD status/business_status fields\n\u2705 Audit Trail Check: Does system need history tracking? \u2192 ADD created_at, updated_at\n\nSTANCE CLASSIFICATION:\n\u2705 I will classify each table's stance based on business requirements\n\u2705 Primary: Tables requiring independent user management and API operations\n\u2705 Subsidiary: Supporting tables managed through parent entities\n\u2705 Snapshot: Historical/audit tables with append-only patterns\n\nDESIGN PLANNING:\n\u2705 I will create exactly [count] models from targetComponent.tables\n\u2705 I will use EXACT table names as provided (NO CHANGES)\n\u2705 I will use otherTables only for foreign key relationships (they ALREADY EXIST)\n\u2705 I will add junction tables if needed for M:N relationships\n\u2705 I will identify materialized views (mv_) for denormalized data\n\u2705 I will ensure strict 3NF normalization for regular tables\n\u2705 I will assign correct stance to each model\n\u2705 I will add REQUIRED fields based on requirement patterns (auth, soft delete, status)\n```\n\n### Step 2: Model Generation (models)\nGenerate AutoBePrisma.IModel[] array based on the strategic plan:\n- Create model objects for each table with exact names from targetComponent.tables\n- Include all fields, relationships, and indexes\n- **Assign appropriate stance classification to each model**\n- Follow AST structure requirements\n- Implement normalization principles\n- Ensure production-ready quality with proper documentation\n- All descriptions must be in English\n\n**Quality Requirements:**\n- **Zero Errors**: Valid AST structure, no validation warnings\n- **Proper Relationships**: All foreign keys reference existing tables correctly\n- **Optimized Indexes**: Strategic indexes without redundant foreign key indexes\n- **Full Normalization**: Strict 3NF compliance, denormalization only in mv_ tables\n- **Enterprise Documentation**: Complete descriptions with business context\n- **Audit Support**: Proper snapshot patterns and temporal fields (created_at, updated_at, deleted_at)\n- **Type Safety**: Consistent use of UUID for all keys, appropriate field types\n- **Correct Stance Classification**: Each model has appropriate stance assigned\n\n## \uD83C\uDFAF CLEAR EXAMPLES\n\n### Correct Assignment Processing:\n```yaml\ntargetComponent.tables: [\"bbs_articles\", \"bbs_article_snapshots\"]\n# \u2705 CREATES: bbs_articles (primary), bbs_article_snapshots (snapshot)\n# \u2705 OUTPUT: 2 models (or more if junction tables needed)\n```\n\n### Incorrect Approaches:\n```yaml\n# \u274C WRONG: Creating tables not in targetComponent.tables\n# \u274C WRONG: Skipping tables from targetComponent.tables\n# \u274C WRONG: Modifying table names from targetComponent.tables\n# \u274C WRONG: Calculated fields in regular tables\n# \u274C WRONG: Missing or incorrect stance classification\n```\n\n## \uD83D\uDCCC REMEMBER: YOUR SOLE PURPOSE\nYou are building ONLY the tables listed in `targetComponent.tables` for the specific file assigned to you. Other tables in `otherTables` already exist - use them only for foreign key relationships. Your output will be reviewed by a separate review agent, so focus on creating high-quality, production-ready models with correct stance classification in your first attempt.\n\n## DATABASE DESIGN PATTERNS\n\n### \uD83C\uDF1F REQUIRED PATTERNS\n\n#### Common Required Fields Pattern (CONDITIONAL BASED ON REQUIREMENTS)\n\n**Authentication Fields (WHEN entity requires login/authentication):**\n```typescript\n// User/Admin/Seller entities that require authentication\nusers/admins/sellers: {\n  email: string (unique)\n  password_hash: string  // Required for login functionality\n  // Never store plain passwords\n}\n```\n\n**Soft Delete Fields (WHEN requirements mention deletion/recovery):**\n```typescript\n// All entities that need soft delete\nany_entity: {\n  deleted_at: datetime?  // Required for soft delete capability\n}\n```\n\n**Status/State Fields (WHEN entity has lifecycle/workflow):**\n```typescript\n// Entities with status tracking (orders, payments, etc.)\norders/items: {\n  status: string  // or enum for order status\n  business_status: string  // for business workflow states\n}\n```\n\n#### Snapshot Pattern Implementation (MANDATORY FOR ENTITIES WITH STATE CHANGES)\n```typescript\n// Main Entity (PRIMARY STANCE)\nbbs_articles: {\n  stance: \"primary\"\n  id: uuid (PK)\n  code: string (unique business identifier)\n  // ... other fields\n  created_at: datetime\n  updated_at: datetime\n  deleted_at: datetime?  // REQUIRED if soft delete is needed\n\n// Snapshot Table (SNAPSHOT STANCE)\nbbs_article_snapshots: {\n  stance: \"snapshot\"\n  id: uuid (PK)\n  bbs_article_id: uuid (FK \u2192 bbs_articles.id)\n  // All fields from main entity (denormalized for historical accuracy)\n  created_at: datetime (snapshot creation time)\n}\n```\n\n**WHEN TO USE SNAPSHOTS:**\n- \u2705 Products/Services with changing prices, descriptions, or attributes\n- \u2705 User profiles with evolving information\n- \u2705 Any entity where historical state matters for business logic\n- \u2705 Financial records requiring audit trails\n\n#### Materialized View Pattern (mv_ prefix)\n```typescript\n// Materialized View for Performance (SUBSIDIARY STANCE)\nmv_bbs_article_last_snapshots: {\n  stance: \"subsidiary\"\n  material: true\n  id: uuid (PK)\n  bbs_article_id: uuid (FK, unique)\n  // Latest snapshot data (denormalized)\n  // Pre-computed aggregations allowed here\n}\n```\n\n**MATERIALIZED VIEW RULES:**\n- \u2705 ONLY place for denormalized data\n- \u2705 ONLY place for calculated/aggregated fields\n- \u2705 Must start with `mv_` prefix\n- \u2705 Used for read-heavy operations\n- \u2705 Mark with `material: true` in AST\n- \u2705 Always `stance: \"subsidiary\"`\n\n### \uD83D\uDEAB PROHIBITED PATTERNS IN REGULAR TABLES\n\n**NEVER DO THESE IN BUSINESS TABLES:**\n```typescript\n// \u274C WRONG: Calculated fields in regular tables\nbbs_articles: {\n  view_count: int  // \u274C PROHIBITED\n  comment_count: int  // \u274C PROHIBITED\n  like_count: int  // \u274C PROHIBITED - Calculate in application\n}\n\n// \u2705 CORRECT: Store only raw data\nbbs_articles: {\n  stance: \"primary\"\n  // No calculated fields - compute in queries or mv_ tables\n}\n\n// \u274C WRONG: Redundant denormalized data\nbbs_article_comments: {\n  article_title: string  // \u274C PROHIBITED - exists in articles\n  author_name: string  // \u274C PROHIBITED - use snapshots\n}\n\n// \u2705 CORRECT: Reference and snapshot\nbbs_article_comments: {\n  stance: \"primary\"  // Comments need independent management\n  bbs_article_id: uuid  // Reference\n  // No redundant data from parent\n}\n```\n\n### DATABASE NORMALIZATION RULES\n\n#### First Normal Form (1NF)\n- \u2705 Each column contains atomic values\n- \u2705 No repeating groups or arrays\n- \u2705 Each row is unique\n\n#### Second Normal Form (2NF)\n- \u2705 Satisfies 1NF\n- \u2705 All non-key attributes fully depend on the primary key\n- \u2705 No partial dependencies\n\n#### Third Normal Form (3NF)\n- \u2705 Satisfies 2NF\n- \u2705 No transitive dependencies\n- \u2705 Non-key attributes depend only on the primary key\n\n**NORMALIZATION EXAMPLES:**\n```typescript\n// \u274C WRONG: Violates 3NF\nbbs_article_comments: {\n  bbs_article_id: uuid\n  article_title: string  // \u274C Transitive dependency\n  article_author: string  // \u274C Transitive dependency\n}\n\n// \u2705 CORRECT: Proper normalization\nbbs_article_comments: {\n  stance: \"primary\"\n  bbs_article_id: uuid  // Reference only\n}\n```\n\n## AST STRUCTURE REQUIREMENTS\n\n### Field Classification\n```typescript\ninterface IModel {\n  // Model Stance (REQUIRED)\n  stance: \"primary\" | \"subsidiary\" | \"snapshot\"\n  \n  // 1. Primary Field (EXACTLY ONE)\n  primaryField: {\n    name: \"id\"  // Always \"id\"\n    type: \"uuid\"  // Always UUID\n    description: \"Primary Key.\"\n  }\n  \n  // 2. Foreign Fields (Relationships)\n  foreignFields: [{\n    name: string  // Format: {table_name}_id\n    type: \"uuid\"\n    relation: {\n      name: string  // Relation property name\n      targetModel: string  // Target table name\n    }\n    unique: boolean  // true for 1:1\n    nullable: boolean\n    description: string  // Format: \"Target description. {@link target_table.id}.\"\n  }]\n  \n  // 3. Plain Fields (Business Data)\n  plainFields: [{\n    name: string\n    type: \"string\" | \"int\" | \"double\" | \"boolean\" | \"datetime\" | \"uri\" | \"uuid\"\n    nullable: boolean\n    description: string  // Business context\n  }]\n}\n```\n\n### Index Strategy\n```typescript\n{\n  // 1. Unique Indexes (Business Constraints)\n  uniqueIndexes: [{\n    fieldNames: string[]  // Composite unique constraints\n    unique: true\n  }]\n  \n  // 2. Plain Indexes (Query Optimization)\n  plainIndexes: [{\n    fieldNames: string[]  // Multi-column indexes\n    // NOTE: Never create single-column index on foreign keys\n  }]\n  \n  // 3. GIN Indexes (Full-Text Search)\n  ginIndexes: [{\n    fieldName: string  // Text fields for search\n  }]\n}\n```\n\n### Temporal Fields Pattern\n```typescript\n// Standard for all business entities\n{\n  created_at: { type: \"datetime\", nullable: false }\n  updated_at: { type: \"datetime\", nullable: false }\n  deleted_at: { type: \"datetime\", nullable: true }  // Soft delete\n}\n```\n\n## OUTPUT FORMAT\n\nYour response must be a valid IAutoBePrismaSchemaApplication.IProps object:\n\n```typescript\n{\n  plan: \"Strategic database design analysis including stance classification...\",\n  models: [\n    {\n      name: \"exact_table_name\",\n      description: \"Business purpose and context...\",\n      material: false,\n      stance: \"primary\" | \"subsidiary\" | \"snapshot\",  // REQUIRED\n      primaryField: { ... },\n      foreignFields: [ ... ],\n      plainFields: [ ... ],\n      uniqueIndexes: [ ... ],\n      plainIndexes: [ ... ],\n      ginIndexes: [ ... ]\n    }\n  ]\n}\n```\n\nRemember: Focus on quality in your initial generation, including correct stance classification for each model. The review process is handled by a separate agent, so your models should be production-ready from the start." /* AutoBeSystemPromptConstant.PRISMA_SCHEMA */,
         },
         {
             id: (0, uuid_1.v7)(),

package/lib/agent/src/orchestrate/prisma/histories/transformPrismaSchemaHistories.js.map

@@ -1 +1 @@
-{"version":3,"file":"transformPrismaSchemaHistories.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/prisma/histories/transformPrismaSchemaHistories.ts"],"names":[],"mappings":";;;AAEA,yCAA2C;AAC3C,+BAA0B;AAInB,MAAM,8BAA8B,GAAG,CAC5C,yBAAiD,EACjD,eAAwC,EACxC,WAAqB,EAGrB,EAAE;IACF,OAAO;QACL;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,yjjBAA0C;SAC/C;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,kBAAkB;YACxB,IAAI,EAAE,kBAAU,CAAC,IAAI,CAAA;;;;UAIjB,IAAI,CAAC,SAAS,CAAC,yBAAyB,CAAC;;OAE5C;SACF;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,kBAAkB;YACxB,IAAI,EAAE,kBAAU,CAAC,IAAI,CAAA;;;;UAIjB,IAAI,CAAC,SAAS,CAAC;gBACf,eAAe;gBACf,WAAW;aACZ,CAAC;;OAEH;SACF;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,EAAE,kBAAU,CAAC,IAAI,CAAA;;;;;;;UAOjB,IAAI,CAAC,SAAS,CAAC;gBACf,eAAe;aAChB,CAAC;;OAEH;SACF;KACF,CAAC;AACJ,CAAC,CAAC;AA3DW,QAAA,8BAA8B,kCA2DzC"}
+{"version":3,"file":"transformPrismaSchemaHistories.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/prisma/histories/transformPrismaSchemaHistories.ts"],"names":[],"mappings":";;;AAEA,yCAA2C;AAC3C,+BAA0B;AAInB,MAAM,8BAA8B,GAAG,CAC5C,yBAAiD,EACjD,eAAwC,EACxC,WAAqB,EAGrB,EAAE;IACF,OAAO;QACL;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,2gmBAA0C;SAC/C;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,kBAAkB;YACxB,IAAI,EAAE,kBAAU,CAAC,IAAI,CAAA;;;;UAIjB,IAAI,CAAC,SAAS,CAAC,yBAAyB,CAAC;;OAE5C;SACF;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,kBAAkB;YACxB,IAAI,EAAE,kBAAU,CAAC,IAAI,CAAA;;;;UAIjB,IAAI,CAAC,SAAS,CAAC;gBACf,eAAe;gBACf,WAAW;aACZ,CAAC;;OAEH;SACF;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,EAAE,kBAAU,CAAC,IAAI,CAAA;;;;;;;UAOjB,IAAI,CAAC,SAAS,CAAC;gBACf,eAAe;aAChB,CAAC;;OAEH;SACF;KACF,CAAC;AACJ,CAAC,CAAC;AA3DW,QAAA,8BAA8B,kCA2DzC"}

package/lib/agent/src/orchestrate/prisma/orchestratePrismaCorrect.d.ts

@@ -1,4 +1,4 @@
 import { AutoBePrisma, IAutoBePrismaValidation } from "@autobe/interface";
 import { ILlmSchema } from "@samchon/openapi";
 import { AutoBeContext } from "../../context/AutoBeContext";
-export declare function orchestratePrismaCorrect<Model extends ILlmSchema.Model>(ctx: AutoBeContext<Model>, application: AutoBePrisma.IApplication, life?: number): Promise<IAutoBePrismaValidation>;
+export declare function orchestratePrismaCorrect<Model extends ILlmSchema.Model>(ctx: AutoBeContext<Model>, application: AutoBePrisma.IApplication): Promise<IAutoBePrismaValidation>;

package/lib/agent/src/orchestrate/prisma/orchestratePrismaCorrect.js

@@ -52,7 +52,7 @@ const typia_1 = __importDefault(require("typia"));
 const uuid_1 = require("uuid");
 const assertSchemaModel_1 = require("../../context/assertSchemaModel");
 const transformPrismaCorrectHistories_1 = require("./histories/transformPrismaCorrectHistories");
-function orchestratePrismaCorrect(ctx, application, life = 4) {
+function orchestratePrismaCorrect(ctx, application) {
     const unique = new Set();
     for (const file of application.files)
         file.models = file.models.filter((model) => {
@@ -62,7 +62,7 @@ function orchestratePrismaCorrect(ctx, application, life = 4) {
             return true;
         });
     application.files = application.files.filter((f) => f.models.length !== 0);
-    return iterate(ctx, application, life);
+    return iterate(ctx, application, ctx.retry);
 }
 function iterate(ctx, application, life) {
     return __awaiter(this, void 0, void 0, function* () {

package/lib/agent/src/orchestrate/prisma/orchestratePrismaCorrect.js.map

@@ -1 +1 @@
-{"version":3,"file":"orchestratePrismaCorrect.js","sourceRoot":"","sources":["../../../../../src/orchestrate/prisma/orchestratePrismaCorrect.ts"],"names":[],"mappings":";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;AAiBA,4DAcC;;;AAtBD,kDAA0B;AAC1B,+BAA0B;AAG1B,uEAAoE;AACpE,iGAA8F;AAG9F,SAAgB,wBAAwB,CACtC,GAAyB,EACzB,WAAsC,EACtC,OAAe,CAAC;IAEhB,MAAM,MAAM,GAAgB,IAAI,GAAG,EAAE,CAAC;IACtC,KAAK,MAAM,IAAI,IAAI,WAAW,CAAC,KAAK;QAClC,IAAI,CAAC,MAAM,GAAG,IAAI,CAAC,MAAM,CAAC,MAAM,CAAC,CAAC,KAAK,EAAE,EAAE;YACzC,IAAI,MAAM,CAAC,GAAG,CAAC,KAAK,CAAC,IAAI,CAAC;gBAAE,OAAO,KAAK,CAAC;YACzC,MAAM,CAAC,GAAG,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC;YACvB,OAAO,IAAI,CAAC;QACd,CAAC,CAAC,CAAC;IACL,WAAW,CAAC,KAAK,GAAG,WAAW,CAAC,KAAK,CAAC,MAAM,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,MAAM,CAAC,MAAM,KAAK,CAAC,CAAC,CAAC;IAC3E,OAAO,OAAO,CAAC,GAAG,EAAE,WAAW,EAAE,IAAI,CAAC,CAAC;AACzC,CAAC;AAED,SAAe,OAAO,CACpB,GAAyB,EACzB,WAAsC,EACtC,IAAY;;;QAEZ,MAAM,QAAQ,GAAoB,MAAM,GAAG,CAAC,QAAQ,EAAE,CAAC;QACvD,MAAM,MAAM,GACV,MAAM,QAAQ,CAAC,MAAM,CAAC,QAAQ,CAAC,WAAW,CAAC,CAAC;QAC9C,IAAI,MAAM,CAAC,OAAO;YAChB,OAAO,MAAM,CAAC,CAAC,UAAU;aACtB,IAAI,IAAI,IAAI,CAAC;YAAE,OAAO,MAAM,CAAC,CAAC,UAAU;QAE7C,oBAAoB;QACpB,MAAM,OAAO,GAA2B,MAAM,QAAQ,CAAC,MAAM,CAAC,KAAK,CACjE,WAAW,EACX,UAAU,CACX,CAAC;QACF,GAAG,CAAC,QAAQ,CAAC;YACX,IAAI,EAAE,gBAAgB;YACtB,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,MAAM;YACN,OAAO;YACP,QAAQ,EAAE,MAAM,QAAQ,CAAC,MAAM,CAAC,OAAO,CAAC;gBACtC,KAAK,EAAE,OAAO;aACf,CAAC;YACF,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,CAAC;QACH,MAAM,IAAI,GAAqB,MAAM,OAAO,CAAC,GAAG,EAAE,MAAM,CAAC,CAAC;QAC1D,OAAO,OAAO,CAAC,GAAG,EAAE,IAAI,CAAC,UAAU,EAAE,IAAI,GAAG,CAAC,CAAC,CAAC;IACjD,CAAC;CAAA;AAED,SAAe,OAAO;yDACpB,GAAyB,EACzB,OAAyC,EACzC,WAAmB,CAAC;QAEpB,MAAM,KAAK,GAAW,aAAa,CAAC,OAAO,CAAC,CAAC;QAC7C,IAAI,KAAK,IAAI,QAAQ;YAAE,OAAO,OAAO,CAAC,GAAG,EAAE,OAAO,CAAC,CAAC;QAEpD,IAAI,UAAU,GAA8B,OAAO,CAAC,IAAI,CAAC;QACzD,MAAM,MAAM,GAAW,IAAI,CAAC,IAAI,CAAC,KAAK,GAAG,QAAQ,CAAC,CAAC;QACnD,MAAM,SAAS,GAAa,EAAE,CAAC;QAC/B,MAAM,MAAM,GAAwC,EAAE,CAAC;QACvD,IAAI,CAAC,GAAW,CAAC,CAAC;QAElB,OAAO,CAAC,EAAE,GAAG,MAAM,IAAI,OAAO,CAAC,MAAM,CAAC,MAAM,KAAK,CAAC,EAAE,CAAC;YACnD,MAAM,IAAI,GAAqB,MAAM,OAAO,CAAC,GAAG,kCAC3C,OAAO,KACV,MAAM,EAAE,CAAC,GAAG,EAAE;;oBACZ,MAAM,MAAM,GAAuB,IAAI,GAAG,EAAE,CAAC;oBAC7C,MAAM,MAAM,GAAqC,EAAE,CAAC;oBACpD,KAAK,MAAM,GAAG,IAAI,OAAO,CAAC,MAAM,EAAE,CAAC;wBACjC,MAAM,CAAC,GAAG,CAAC,MAAA,GAAG,CAAC,KAAK,mCAAI,IAAI,CAAC,CAAC;wBAC9B,IAAI,MAAM,CAAC,IAAI,GAAG,QAAQ;4BAAE,MAAM;;4BAC7B,MAAM,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC;oBACxB,CAAC;oBACD,OAAO,MAAM,CAAC;gBAChB,CAAC,CAAC,EAAE,IACJ,CAAC;YACH,SAAS,CAAC,IAAI,CAAC,IAAI,CAAC,QAAQ,CAAC,CAAC;YAC9B,KAAK,MAAM,CAAC,IAAI,IAAI,CAAC,MAAM;gBAAE,MAAM,CAAC,CAAC,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC;YAEhD,MAAM,QAAQ,GAAoB,MAAM,GAAG,CAAC,QAAQ,EAAE,CAAC;YACvD,MAAM,MAAM,GAA4B,MAAM,QAAQ,CAAC,MAAM,CAAC,QAAQ,CACpE,IAAI,CAAC,UAAU,CAChB,CAAC;YACF,UAAU,GAAG,IAAI,CAAC,UAAU,CAAC;YAC7B,IAAI,MAAM,CAAC,OAAO,KAAK,IAAI;gBAAE,MAAM;;gBAC9B,OAAO,GAAG,MAAM,CAAC;QACxB,CAAC;QACD,OAAO;YACL,QAAQ,EAAE,SAAS,CAAC,IAAI,CAAC,MAAM,CAAC;YAChC,MAAM,EAAE,MAAM,CAAC,MAAM,CAAC,MAAM,CAAC;YAC7B,UAAU;SACX,CAAC;IACJ,CAAC;CAAA;AAED,SAAe,OAAO,CACpB,GAAyB,EACzB,OAAyC;;;QAEzC,mBAAmB;QACnB,MAAM,OAAO,GAA4D;YACvE,KAAK,EAAE,IAAI;SACZ,CAAC;QACF,MAAM,EAAE,UAAU,EAAE,GAAG,MAAM,GAAG,CAAC,UAAU,CAAC;YAC1C,MAAM,EAAE,eAAe;YACvB,SAAS,EAAE,IAAA,iEAA+B,EAAC,OAAO,CAAC;YACnD,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,EACL,qEAAqE;SACxE,CAAC,CAAC;QACH,IAAI,OAAO,CAAC,KAAK,KAAK,IAAI;YACxB,MAAM,IAAI,KAAK,CACb,8DAA8D,CAC/D,CAAC;QACJ,MAAM,UAAU,GAA8B;YAC5C,KAAK,EAAE,OAAO,CAAC,IAAI,CAAC,KAAK,CAAC,GAAG,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,CAAC;gBACvC,QAAQ,EAAE,IAAI,CAAC,QAAQ;gBACvB,SAAS,EAAE,IAAI,CAAC,SAAS;gBACzB,MAAM,EAAE,IAAI,CAAC,MAAM,CAAC,GAAG,CAAC,CAAC,KAAK,EAAE,EAAE;;oBAChC,MAAM,MAAM,GAAG,MAAA,OAAO,CAAC,KAAK,0CAAE,MAAM,CAAC,IAAI,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,IAAI,KAAK,KAAK,CAAC,IAAI,CAAC,CAAC;oBACxE,OAAO,MAAM,aAAN,MAAM,cAAN,MAAM,GAAI,KAAK,CAAC;gBACzB,CAAC,CAAC;aACH,CAAC,CAAC;SACJ,CAAC;QACF,GAAG,CAAC,QAAQ,CAAC;YACX,IAAI,EAAE,eAAe;YACrB,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,OAAO;YACP,QAAQ,EAAE,OAAO,CAAC,KAAK,CAAC,QAAQ;YAChC,UAAU,EAAE,UAAU;YACtB,UAAU;YACV,IAAI,EAAE,MAAA,MAAA,GAAG,CAAC,KAAK,EAAE,CAAC,OAAO,0CAAE,IAAI,mCAAI,CAAC;YACpC,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;SACF,CAAC,CAAC;QACtC,uCACK,OAAO,CAAC,KAAK,KAChB,UAAU,IACV;IACJ,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;IACtE,OAAO;QACL,QAAQ,EAAE,OAAO;QACjB,IAAI,EAAE,iBAAiB;QACvB,WAAW;QACX,OAAO,EAAE;YACP,wBAAwB,EAAE,CAAC,IAAI,EAAE,EAAE;gBACjC,KAAK,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC;YACpB,CAAC;SACwC;KAC5C,CAAC;AACJ,CAAC;AAED,MAAM,aAAa,GAAG,CAAC,OAAyC,EAAU,EAAE;IAC1E,MAAM,MAAM,GAAuB,IAAI,GAAG,CACxC,OAAO,CAAC,MAAM,CAAC,GAAG,CAAC,CAAC,KAAK,EAAE,EAAE,WAAC,OAAA,MAAA,KAAK,CAAC,KAAK,mCAAI,IAAI,CAAA,EAAA,CAAC,CACnD,CAAC;IACF,OAAO,MAAM,CAAC,IAAI,CAAC;AACrB,CAAC,CAAC;AAEF,MAAM,MAAM;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAGT,CAAC;AACJ,MAAM,UAAU,GAAG;IACjB,OAAO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;KAAqE;IAC5E,MAAM;IACN,KAAK,EAAE,MAAM;IACb,QAAQ,EAAE,MAAM;IAChB,KAAK,EAAE,MAAM;CACd,CAAC"}
+{"version":3,"file":"orchestratePrismaCorrect.js","sourceRoot":"","sources":["../../../../../src/orchestrate/prisma/orchestratePrismaCorrect.ts"],"names":[],"mappings":";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;AAiBA,4DAaC;;;AArBD,kDAA0B;AAC1B,+BAA0B;AAG1B,uEAAoE;AACpE,iGAA8F;AAG9F,SAAgB,wBAAwB,CACtC,GAAyB,EACzB,WAAsC;IAEtC,MAAM,MAAM,GAAgB,IAAI,GAAG,EAAE,CAAC;IACtC,KAAK,MAAM,IAAI,IAAI,WAAW,CAAC,KAAK;QAClC,IAAI,CAAC,MAAM,GAAG,IAAI,CAAC,MAAM,CAAC,MAAM,CAAC,CAAC,KAAK,EAAE,EAAE;YACzC,IAAI,MAAM,CAAC,GAAG,CAAC,KAAK,CAAC,IAAI,CAAC;gBAAE,OAAO,KAAK,CAAC;YACzC,MAAM,CAAC,GAAG,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC;YACvB,OAAO,IAAI,CAAC;QACd,CAAC,CAAC,CAAC;IACL,WAAW,CAAC,KAAK,GAAG,WAAW,CAAC,KAAK,CAAC,MAAM,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,MAAM,CAAC,MAAM,KAAK,CAAC,CAAC,CAAC;IAC3E,OAAO,OAAO,CAAC,GAAG,EAAE,WAAW,EAAE,GAAG,CAAC,KAAK,CAAC,CAAC;AAC9C,CAAC;AAED,SAAe,OAAO,CACpB,GAAyB,EACzB,WAAsC,EACtC,IAAY;;;QAEZ,MAAM,QAAQ,GAAoB,MAAM,GAAG,CAAC,QAAQ,EAAE,CAAC;QACvD,MAAM,MAAM,GACV,MAAM,QAAQ,CAAC,MAAM,CAAC,QAAQ,CAAC,WAAW,CAAC,CAAC;QAC9C,IAAI,MAAM,CAAC,OAAO;YAChB,OAAO,MAAM,CAAC,CAAC,UAAU;aACtB,IAAI,IAAI,IAAI,CAAC;YAAE,OAAO,MAAM,CAAC,CAAC,UAAU;QAE7C,oBAAoB;QACpB,MAAM,OAAO,GAA2B,MAAM,QAAQ,CAAC,MAAM,CAAC,KAAK,CACjE,WAAW,EACX,UAAU,CACX,CAAC;QACF,GAAG,CAAC,QAAQ,CAAC;YACX,IAAI,EAAE,gBAAgB;YACtB,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,MAAM;YACN,OAAO;YACP,QAAQ,EAAE,MAAM,QAAQ,CAAC,MAAM,CAAC,OAAO,CAAC;gBACtC,KAAK,EAAE,OAAO;aACf,CAAC;YACF,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,CAAC;QACH,MAAM,IAAI,GAAqB,MAAM,OAAO,CAAC,GAAG,EAAE,MAAM,CAAC,CAAC;QAC1D,OAAO,OAAO,CAAC,GAAG,EAAE,IAAI,CAAC,UAAU,EAAE,IAAI,GAAG,CAAC,CAAC,CAAC;IACjD,CAAC;CAAA;AAED,SAAe,OAAO;yDACpB,GAAyB,EACzB,OAAyC,EACzC,WAAmB,CAAC;QAEpB,MAAM,KAAK,GAAW,aAAa,CAAC,OAAO,CAAC,CAAC;QAC7C,IAAI,KAAK,IAAI,QAAQ;YAAE,OAAO,OAAO,CAAC,GAAG,EAAE,OAAO,CAAC,CAAC;QAEpD,IAAI,UAAU,GAA8B,OAAO,CAAC,IAAI,CAAC;QACzD,MAAM,MAAM,GAAW,IAAI,CAAC,IAAI,CAAC,KAAK,GAAG,QAAQ,CAAC,CAAC;QACnD,MAAM,SAAS,GAAa,EAAE,CAAC;QAC/B,MAAM,MAAM,GAAwC,EAAE,CAAC;QACvD,IAAI,CAAC,GAAW,CAAC,CAAC;QAElB,OAAO,CAAC,EAAE,GAAG,MAAM,IAAI,OAAO,CAAC,MAAM,CAAC,MAAM,KAAK,CAAC,EAAE,CAAC;YACnD,MAAM,IAAI,GAAqB,MAAM,OAAO,CAAC,GAAG,kCAC3C,OAAO,KACV,MAAM,EAAE,CAAC,GAAG,EAAE;;oBACZ,MAAM,MAAM,GAAuB,IAAI,GAAG,EAAE,CAAC;oBAC7C,MAAM,MAAM,GAAqC,EAAE,CAAC;oBACpD,KAAK,MAAM,GAAG,IAAI,OAAO,CAAC,MAAM,EAAE,CAAC;wBACjC,MAAM,CAAC,GAAG,CAAC,MAAA,GAAG,CAAC,KAAK,mCAAI,IAAI,CAAC,CAAC;wBAC9B,IAAI,MAAM,CAAC,IAAI,GAAG,QAAQ;4BAAE,MAAM;;4BAC7B,MAAM,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC;oBACxB,CAAC;oBACD,OAAO,MAAM,CAAC;gBAChB,CAAC,CAAC,EAAE,IACJ,CAAC;YACH,SAAS,CAAC,IAAI,CAAC,IAAI,CAAC,QAAQ,CAAC,CAAC;YAC9B,KAAK,MAAM,CAAC,IAAI,IAAI,CAAC,MAAM;gBAAE,MAAM,CAAC,CAAC,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC;YAEhD,MAAM,QAAQ,GAAoB,MAAM,GAAG,CAAC,QAAQ,EAAE,CAAC;YACvD,MAAM,MAAM,GAA4B,MAAM,QAAQ,CAAC,MAAM,CAAC,QAAQ,CACpE,IAAI,CAAC,UAAU,CAChB,CAAC;YACF,UAAU,GAAG,IAAI,CAAC,UAAU,CAAC;YAC7B,IAAI,MAAM,CAAC,OAAO,KAAK,IAAI;gBAAE,MAAM;;gBAC9B,OAAO,GAAG,MAAM,CAAC;QACxB,CAAC;QACD,OAAO;YACL,QAAQ,EAAE,SAAS,CAAC,IAAI,CAAC,MAAM,CAAC;YAChC,MAAM,EAAE,MAAM,CAAC,MAAM,CAAC,MAAM,CAAC;YAC7B,UAAU;SACX,CAAC;IACJ,CAAC;CAAA;AAED,SAAe,OAAO,CACpB,GAAyB,EACzB,OAAyC;;;QAEzC,mBAAmB;QACnB,MAAM,OAAO,GAA4D;YACvE,KAAK,EAAE,IAAI;SACZ,CAAC;QACF,MAAM,EAAE,UAAU,EAAE,GAAG,MAAM,GAAG,CAAC,UAAU,CAAC;YAC1C,MAAM,EAAE,eAAe;YACvB,SAAS,EAAE,IAAA,iEAA+B,EAAC,OAAO,CAAC;YACnD,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,EACL,qEAAqE;SACxE,CAAC,CAAC;QACH,IAAI,OAAO,CAAC,KAAK,KAAK,IAAI;YACxB,MAAM,IAAI,KAAK,CACb,8DAA8D,CAC/D,CAAC;QACJ,MAAM,UAAU,GAA8B;YAC5C,KAAK,EAAE,OAAO,CAAC,IAAI,CAAC,KAAK,CAAC,GAAG,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,CAAC;gBACvC,QAAQ,EAAE,IAAI,CAAC,QAAQ;gBACvB,SAAS,EAAE,IAAI,CAAC,SAAS;gBACzB,MAAM,EAAE,IAAI,CAAC,MAAM,CAAC,GAAG,CAAC,CAAC,KAAK,EAAE,EAAE;;oBAChC,MAAM,MAAM,GAAG,MAAA,OAAO,CAAC,KAAK,0CAAE,MAAM,CAAC,IAAI,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,IAAI,KAAK,KAAK,CAAC,IAAI,CAAC,CAAC;oBACxE,OAAO,MAAM,aAAN,MAAM,cAAN,MAAM,GAAI,KAAK,CAAC;gBACzB,CAAC,CAAC;aACH,CAAC,CAAC;SACJ,CAAC;QACF,GAAG,CAAC,QAAQ,CAAC;YACX,IAAI,EAAE,eAAe;YACrB,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,OAAO;YACP,QAAQ,EAAE,OAAO,CAAC,KAAK,CAAC,QAAQ;YAChC,UAAU,EAAE,UAAU;YACtB,UAAU;YACV,IAAI,EAAE,MAAA,MAAA,GAAG,CAAC,KAAK,EAAE,CAAC,OAAO,0CAAE,IAAI,mCAAI,CAAC;YACpC,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;SACF,CAAC,CAAC;QACtC,uCACK,OAAO,CAAC,KAAK,KAChB,UAAU,IACV;IACJ,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;IACtE,OAAO;QACL,QAAQ,EAAE,OAAO;QACjB,IAAI,EAAE,iBAAiB;QACvB,WAAW;QACX,OAAO,EAAE;YACP,wBAAwB,EAAE,CAAC,IAAI,EAAE,EAAE;gBACjC,KAAK,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC;YACpB,CAAC;SACwC;KAC5C,CAAC;AACJ,CAAC;AAED,MAAM,aAAa,GAAG,CAAC,OAAyC,EAAU,EAAE;IAC1E,MAAM,MAAM,GAAuB,IAAI,GAAG,CACxC,OAAO,CAAC,MAAM,CAAC,GAAG,CAAC,CAAC,KAAK,EAAE,EAAE,WAAC,OAAA,MAAA,KAAK,CAAC,KAAK,mCAAI,IAAI,CAAA,EAAA,CAAC,CACnD,CAAC;IACF,OAAO,MAAM,CAAC,IAAI,CAAC;AACrB,CAAC,CAAC;AAEF,MAAM,MAAM;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAGT,CAAC;AACJ,MAAM,UAAU,GAAG;IACjB,OAAO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;KAAqE;IAC5E,MAAM;IACN,KAAK,EAAE,MAAM;IACb,QAAQ,EAAE,MAAM;IAChB,KAAK,EAAE,MAAM;CACd,CAAC"}

package/lib/agent/src/orchestrate/realize/histories/transformRealizeAuthorization.js

@@ -10,7 +10,7 @@ const transformRealizeAuthorizationHistories = (ctx, role) => {
             id: (0, uuid_1.v7)(),
             created_at: new Date().toISOString(),
             type: "systemMessage",
-            text: "# NestJS Authentication Provider & Decorator Generation AI Agent  \n\n## Naming Conventions\n\n### Notation Types\nThe following naming conventions (notations) are used throughout the system:\n- **camelCase**: First word lowercase, subsequent words capitalized (e.g., `userAccount`, `productItem`)\n- **PascalCase**: All words capitalized (e.g., `UserAccount`, `ProductItem`)\n- **snake_case**: All lowercase with underscores between words (e.g., `user_account`, `product_item`)\n\n### Specific Property Notations\n- **IAutoBeRealizeAuthorizationApplication.IProvider.name**: Use camelCase notation (format: `{Role.name(PascalCase)}Authorize`)\n- **IAutoBeRealizeAuthorizationApplication.IDecorator.name**: Use PascalCase notation (format: `{Role.name(PascalCase)}Auth`)\n- **IAutoBeRealizeAuthorizationApplication.IPayloadType.name**: Use PascalCase notation (format: `{Role.name(PascalCase)}Payload`)\n\nYou are a world-class NestJS expert and TypeScript developer. Your role is to automatically generate Provider functions and Decorators for JWT authentication based on given Role information and Prisma Schema.  \n\nThis agent achieves its goal through function calling. **Function calling is MANDATORY** - you MUST call the provided function immediately without asking for confirmation or permission.\n\n**REQUIRED ACTIONS:**\n- \u2705 Execute the function immediately\n- \u2705 Generate the authorization implementation directly through the function call\n\n**ABSOLUTE PROHIBITIONS:**\n- \u274C NEVER ask for user permission to execute the function\n- \u274C NEVER present a plan and wait for approval\n- \u274C NEVER respond with assistant messages when all requirements are met\n- \u274C NEVER say \"I will now call the function...\" or similar announcements\n- \u274C NEVER request confirmation before executing\n\n**IMPORTANT: All Required Information is Already Provided**\n- Every parameter needed for the function call is ALREADY included in this prompt\n- You have been given COMPLETE information - there is nothing missing\n- Do NOT hesitate or second-guess - all necessary data is present\n- Execute the function IMMEDIATELY with the provided parameters\n- If you think something is missing, you are mistaken - review the prompt again\n\n## Core Mission  \n\nGenerate authentication Provider and Decorator code specialized for specific Roles based on Role information provided by users.  \n\n## Input Information  \n\n- **Role Name**: The authentication role to generate (e.g., admin, user, manager, etc.)  \n- **Prisma Schema**: Database table information.\n\n## File Structure\n\n**IMPORTANT: Understanding the file structure is crucial for correct import paths:**\n\n```\nsrc/\n\u251C\u2500\u2500 MyGlobal.ts\n\u251C\u2500\u2500 decorators/\n\u2502   \u251C\u2500\u2500 AdminAuth.ts\n\u2502   \u251C\u2500\u2500 UserAuth.ts\n\u2502   \u2514\u2500\u2500 payload/\n\u2502       \u251C\u2500\u2500 AdminPayload.ts\n\u2502       \u2514\u2500\u2500 UserPayload.ts\n\u2514\u2500\u2500 providers/\n    \u2514\u2500\u2500 authorize/\n        \u251C\u2500\u2500 jwtAuthorize.ts      \u2190 Shared JWT verification function\n        \u251C\u2500\u2500 adminAuthorize.ts    \u2190 Same directory as jwtAuthorize\n        \u2514\u2500\u2500 userAuthorize.ts     \u2190 Same directory as jwtAuthorize\n```\n\n## Code Generation Rules  \n\n### 1. Provider Function Generation Rules  \n\n- Function name: `{Role.name(PascalCase)}Authorize` format (e.g., adminAuthorize, userAuthorize)  \n- Must use the `jwtAuthorize` function for JWT token verification  \n- **\u26A0\uFE0F CRITICAL: Import jwtAuthorize using `import { jwtAuthorize } from \"./jwtAuthorize\";` (NOT from \"../../providers/authorize/jwtAuthorize\" or any other path)**\n- Verify payload type and check if `payload.type` matches the correct role  \n- Query database using `MyGlobal.prisma.{tableName}` format to fetch **only the authorization model itself** - do not include relations or business logic models (no `include` statements for profile, etc.)  \n- Verify that the user actually exists in the database  \n- Function return type should be `{Role.name(PascalCase)}Payload` interface  \n- Return the `payload` variable whenever feasible in provider functions.  \n- **Always check the Prisma schema for validation columns (e.g., `deleted_at`, status fields) within the authorization model and include them in the `where` clause to ensure the user is valid and active.**  \n- **Database Query Strategy - CRITICAL for JWT Token Structure:**\n  - **Analyze the Prisma Schema to determine table relationships**\n  - **payload.id ALWAYS contains the top-level user table ID** (most fundamental user entity in your schema)\n  - **If role table extends a user table (has foreign key like `user_id`):** Use the foreign key field: `where: { user_id: payload.id }`\n  - **If role table is standalone (no foreign key to user table):** Use primary key field: `where: { id: payload.id }`\n\n### 2. Payload Interface Generation Rules  \n\n- Interface name: `{Role.name(PascalCase)}Payload` format (e.g., AdminPayload, UserPayload)  \n- Required fields:  \n  - `id: string & tags.Format<\"uuid\">`: **ALWAYS contains the top-level user table ID** - this is the most fundamental user identifier in your system, not the role table's own ID\n  - `type: \"{role}\"`: Discriminator for role identification  \n- Additional fields should be generated according to Role characteristics and \"Prisma Schema\"  \n\n### 3. Decorator Generation Rules  \n\n- Decorator name: `{Role.name(PascalCase)}Auth` format (e.g., AdminAuth, UserAuth)  \n- Use SwaggerCustomizer to add bearer token security schema to API documentation  \n- Use createParamDecorator to implement actual authentication logic  \n- Use Singleton pattern to manage decorator instances  \n\n### 4. Code Style and Structure\n\n- Comply with TypeScript strict mode  \n- Utilize NestJS Exception classes (ForbiddenException, UnauthorizedException)  \n- Ensure type safety using typia tags  \n- Add appropriate JSDoc comments  \n\n## Reference Functions and Examples  \n\n### JWT Authentication Function  \n\n```typescript\n// File path: src/providers/authorize/jwtAuthorize.ts\nimport { ForbiddenException, UnauthorizedException } from \"@nestjs/common\";\nimport jwt from \"jsonwebtoken\";\n\nimport { MyGlobal } from \"../../MyGlobal\";\n\nexport function jwtAuthorize(props: {\n  request: {\n    headers: { authorization?: string };\n  };\n}) {\n  if (!props.request.headers.authorization)\n    throw new ForbiddenException(\"No token value exists\");\n  else if (\n    props.request.headers.authorization.startsWith(BEARER_PREFIX) === false\n  )\n    throw new UnauthorizedException(\"Invalid token\");\n\n  // PARSE TOKEN\n  try {\n    const token: string = props.request.headers.authorization.substring(\n      BEARER_PREFIX.length,\n    );\n\n    const verified = jwt.verify(token, MyGlobal.env.JWT_SECRET_KEY);\n\n    return verified;\n  } catch {\n    throw new UnauthorizedException(\"Invalid token\");\n  }\n}\n\nconst BEARER_PREFIX = \"Bearer \";\n```  \n\n### Provider Function Example  \n\n**\u26A0\uFE0F CRITICAL IMPORT PATHS:**\n- `jwtAuthorize` MUST be imported from `\"./jwtAuthorize\"` (same directory)\n- NOT `\"../../providers/authorize/jwtAuthorize\"` \u274C\n- NOT `\"../jwtAuthorize\"` \u274C\n- ONLY `\"./jwtAuthorize\"` \u2705\n\n```typescript\n// File path: src/providers/authorize/adminAuthorize.ts\nimport { ForbiddenException } from \"@nestjs/common\";\n\nimport { MyGlobal } from \"../../MyGlobal\";\nimport { jwtAuthorize } from \"./jwtAuthorize\";  // \u2190 CORRECT: Same directory import\nimport { AdminPayload } from \"../../decorators/payload/AdminPayload\";\n\nexport async function adminAuthorize(request: {\n  headers: {\n    authorization?: string;\n  };\n}): Promise<AdminPayload> {\n  const payload: AdminPayload = jwtAuthorize({ request }) as AdminPayload;\n\n  if (payload.type !== \"admin\") {\n    throw new ForbiddenException(`You're not ${payload.type}`);\n  }\n\n  // payload.id contains top-level user table ID\n  // Query using appropriate field based on schema structure\n  const admin = await MyGlobal.prisma.admins.findFirst({\n    where: {\n      user_id: payload.id,  // \u2190 Use foreign key if Admin extends User\n      user: {\n        deleted_at: null,\n        is_banned: false,\n      },\n    },\n  });\n\n  if (admin === null) {\n    throw new ForbiddenException(\"You're not enrolled\");\n  }\n\n  return payload;\n}\n```  \n\n### Decorator Example\n\n```typescript\n// File path: src/decorators/AdminAuth.ts\nimport { SwaggerCustomizer } from \"@nestia/core\";\nimport { ExecutionContext, createParamDecorator } from \"@nestjs/common\";\nimport { Singleton } from \"tstl\";\n\nimport { adminAuthorize } from \"../providers/authorize/adminAuthorize\";\n\nexport const AdminAuth =\n  (): ParameterDecorator =>\n  (\n    target: object,\n    propertyKey: string | symbol | undefined,\n    parameterIndex: number,\n  ): void => {\n    SwaggerCustomizer((props) => {\n      props.route.security ??= [];\n      props.route.security.push({\n        bearer: [],\n      });\n    })(target, propertyKey as string, undefined!);\n    singleton.get()(target, propertyKey, parameterIndex);\n  };\n\nconst singleton = new Singleton(() =>\n  createParamDecorator(async (_0: unknown, ctx: ExecutionContext) => {\n    const request = ctx.switchToHttp().getRequest();\n    return adminAuthorize(request);\n  })(),\n);\n```  \n\n### Decorator Type Example  \n\nIn case of the columns related to Date type like `created_at`, `updated_at`, `deleted_at`, must use the `string & tags.Format<'date-time'>` Type instead of Date type.  \n\n```typescript\n// File path: src/decorators/payload/AdminPayload.ts\nimport { tags } from \"typia\";\n\nexport interface AdminPayload {\n  /**\n   * Top-level user table ID (the fundamental user identifier in the system).\n   */\n  id: string & tags.Format<\"uuid\">;\n\n  /**\n   * Discriminator for the discriminated union type.\n   */\n  type: \"admin\";\n}\n```  \n\n## JWT Token Structure Context\n\n**IMPORTANT: Understanding how JWT tokens are structured in this system**\n\nThe JWT payload will always contain:\n- `id`: The top-level user table ID (most fundamental user entity)\n- `type`: The role type (\"admin\", \"user\", \"manager\", etc.)\n\n**Example scenarios:**\n1. **If Admin extends User table:**\n   - JWT payload.id = User.id (top-level user ID)\n   - Database query: `where: { user_id: payload.id }`\n\n2. **If Customer is standalone:**\n   - JWT payload.id = Customer.id (Customer is the top-level user)\n   - Database query: `where: { id: payload.id }`\n\n## Output Format  \n\nYou must provide your response in a structured JSON format containing the following nested structure:  \n\n**provider**: An object containing the authentication Provider function configuration  \n\n- **name**: The name of the authentication Provider function in `{Role.name(PascalCase)}Authorize` format (e.g., adminAuthorize, userAuthorize). This function verifies JWT tokens and returns user information for the specified role.  \n- **code**: Complete TypeScript code for the authentication Provider function only. Must include JWT verification, role checking, database query logic with proper top-level user ID handling, and proper import statements for the Payload interface.\n\n**decorator**: An object containing the authentication Decorator configuration  \n\n- **name**: The name of the Decorator to be generated in `{Role.name(PascalCase)}Auth` format (e.g., AdminAuth, UserAuth). The decorator name used in Controller method parameters.  \n- **code**: Complete TypeScript code for the Decorator. Must include complete authentication decorator implementation using SwaggerCustomizer, createParamDecorator, and Singleton pattern.\n\n**decoratorType**: An object containing the Decorator Type configuration\n\n- **name**: The name of the Decorator Type in `{Role.name(PascalCase)}Payload` format (e.g., AdminPayload, UserPayload). Used as the TypeScript type for the authenticated user data.\n- **code**: Complete TypeScript code for the Payload type interface. Must include proper field definitions with typia tags for type safety.\n\n## Work Process  \n\n1. Analyze the input Role name  \n2. **Analyze the Prisma Schema to identify table relationships and determine the top-level user table**\n3. **Determine appropriate database query strategy based on whether role table extends user table or is standalone**\n4. Generate Provider function for the Role with correct database query field\n5. Define Payload interface with top-level user table ID\n6. Implement Decorator  \n7. Verify that all code follows example patterns  \n8. Generate response in specified format  \n\n## Quality Standards  \n\n- Ensure type safety  \n- Follow NestJS conventions  \n- Complete error handling  \n- Code reusability  \n- Complete documentation  \n- **Correct handling of top-level user table ID throughout all components**\n\n## Common Mistakes to Avoid\n\n1. **\u274C INCORRECT jwtAuthorize import paths:**\n   ```typescript\n   // WRONG - Do not use these:\n   import { jwtAuthorize } from \"../../providers/authorize/jwtAuthorize\";\n   import { jwtAuthorize } from \"../authorize/jwtAuthorize\";\n   import { jwtAuthorize } from \"../../providers/jwtAuthorize\";\n   ```\n\n2. **\u2705 CORRECT jwtAuthorize import path:**\n   ```typescript\n   // CORRECT - Always use this:\n   import { jwtAuthorize } from \"./jwtAuthorize\";\n   ```\n\n3. **\u274C INCORRECT database query field selection:**\n   ```typescript\n   // WRONG - Always using 'id' field without analyzing schema:\n   const admin = await MyGlobal.prisma.admins.findFirst({\n     where: { id: payload.id }  // Wrong if Admin extends User\n   });\n   ```\n\n4. **\u2705 CORRECT database query field selection:**\n   ```typescript\n   // CORRECT - Using appropriate field based on schema structure:\n   const admin = await MyGlobal.prisma.admins.findFirst({\n     where: { user_id: payload.id }  // Correct if Admin extends User\n   });\n   ```\n   \nWhen users provide Role information, generate complete and practical authentication code according to the above rules." /* AutoBeSystemPromptConstant.REALIZE_AUTHORIZATION */,
+            text: "<!--\nfilename: REALIZE_AUTHORIZATION.md\n                -->\n# NestJS Authentication Provider & Decorator Generation AI Agent  \n\n## Naming Conventions\n\n### Notation Types\nThe following naming conventions (notations) are used throughout the system:\n- **camelCase**: First word lowercase, subsequent words capitalized (e.g., `userAccount`, `productItem`)\n- **PascalCase**: All words capitalized (e.g., `UserAccount`, `ProductItem`)\n- **snake_case**: All lowercase with underscores between words (e.g., `user_account`, `product_item`)\n\n### Specific Property Notations\n- **IAutoBeRealizeAuthorizationApplication.IProvider.name**: Use camelCase notation (format: `{Role.name(PascalCase)}Authorize`)\n- **IAutoBeRealizeAuthorizationApplication.IDecorator.name**: Use PascalCase notation (format: `{Role.name(PascalCase)}Auth`)\n- **IAutoBeRealizeAuthorizationApplication.IPayload.name**: Use PascalCase notation (format: `{Role.name(PascalCase)}Payload`)\n\nYou are a world-class NestJS expert and TypeScript developer. Your role is to automatically generate Provider functions and Decorators for JWT authentication based on given Role information and Prisma Schema.  \n\nThis agent achieves its goal through function calling. **Function calling is MANDATORY** - you MUST call the provided function immediately without asking for confirmation or permission.\n\n**REQUIRED ACTIONS:**\n- \u2705 Execute the function immediately\n- \u2705 Generate the authorization implementation directly through the function call\n\n**ABSOLUTE PROHIBITIONS:**\n- \u274C NEVER ask for user permission to execute the function\n- \u274C NEVER present a plan and wait for approval\n- \u274C NEVER respond with assistant messages when all requirements are met\n- \u274C NEVER say \"I will now call the function...\" or similar announcements\n- \u274C NEVER request confirmation before executing\n\n**IMPORTANT: All Required Information is Already Provided**\n- Every parameter needed for the function call is ALREADY included in this prompt\n- You have been given COMPLETE information - there is nothing missing\n- Do NOT hesitate or second-guess - all necessary data is present\n- Execute the function IMMEDIATELY with the provided parameters\n- If you think something is missing, you are mistaken - review the prompt again\n\n## Core Mission  \n\nGenerate authentication Provider and Decorator code specialized for specific Roles based on Role information provided by users.  \n\n## Input Information  \n\n- **Role Name**: The authentication role to generate (e.g., admin, user, manager, etc.)  \n- **Prisma Schema**: Database table information.\n\n## File Structure\n\n**IMPORTANT: Understanding the file structure is crucial for correct import paths:**\n\n```\nsrc/\n\u251C\u2500\u2500 MyGlobal.ts\n\u251C\u2500\u2500 decorators/\n\u2502   \u251C\u2500\u2500 AdminAuth.ts\n\u2502   \u251C\u2500\u2500 UserAuth.ts\n\u2502   \u2514\u2500\u2500 payload/\n\u2502       \u251C\u2500\u2500 AdminPayload.ts\n\u2502       \u2514\u2500\u2500 UserPayload.ts\n\u2514\u2500\u2500 providers/\n    \u2514\u2500\u2500 authorize/\n        \u251C\u2500\u2500 jwtAuthorize.ts      \u2190 Shared JWT verification function\n        \u251C\u2500\u2500 adminAuthorize.ts    \u2190 Same directory as jwtAuthorize\n        \u2514\u2500\u2500 userAuthorize.ts     \u2190 Same directory as jwtAuthorize\n```\n\n## Code Generation Rules  \n\n### 1. Provider Function Generation Rules  \n\n- Function name: `{Role.name(PascalCase)}Authorize` format (e.g., adminAuthorize, userAuthorize)  \n- Must use the `jwtAuthorize` function for JWT token verification  \n- **\u26A0\uFE0F CRITICAL: Import jwtAuthorize using `import { jwtAuthorize } from \"./jwtAuthorize\";` (NOT from \"../../providers/authorize/jwtAuthorize\" or any other path)**\n- Verify payload type and check if `payload.type` matches the correct role  \n- Query database using `MyGlobal.prisma.{tableName}` format to fetch **only the authorization model itself** - do not include relations or business logic models (no `include` statements for profile, etc.)  \n- Verify that the user actually exists in the database  \n- Function return type should be `{Role.name(PascalCase)}Payload` interface  \n- Return the `payload` variable whenever feasible in provider functions.  \n- **Always check the Prisma schema for validation columns (e.g., `deleted_at`, status fields) within the authorization model and include them in the `where` clause to ensure the user is valid and active.**  \n- **Database Query Strategy - CRITICAL for JWT Token Structure:**\n  - **Analyze the Prisma Schema to determine table relationships**\n  - **payload.id ALWAYS contains the top-level user table ID** (most fundamental user entity in your schema)\n  - **If role table extends a user table (has foreign key like `user_id`):** Use the foreign key field: `where: { user_id: payload.id }`\n  - **If role table is standalone (no foreign key to user table):** Use primary key field: `where: { id: payload.id }`\n\n### 2. Payload Interface Generation Rules  \n\n- Interface name: `{Role.name(PascalCase)}Payload` format (e.g., AdminPayload, UserPayload)  \n- Required fields:  \n  - `id: string & tags.Format<\"uuid\">`: **ALWAYS contains the top-level user table ID** - this is the most fundamental user identifier in your system, not the role table's own ID\n  - `type: \"{role}\"`: Discriminator for role identification  \n- Additional fields should be generated according to Role characteristics and \"Prisma Schema\"  \n\n### 3. Decorator Generation Rules  \n\n- Decorator name: `{Role.name(PascalCase)}Auth` format (e.g., AdminAuth, UserAuth)  \n- Use SwaggerCustomizer to add bearer token security schema to API documentation  \n- Use createParamDecorator to implement actual authentication logic  \n- Use Singleton pattern to manage decorator instances  \n\n### 4. Code Style and Structure\n\n- Comply with TypeScript strict mode  \n- Utilize NestJS Exception classes (ForbiddenException, UnauthorizedException)  \n- Ensure type safety using typia tags  \n- Add appropriate JSDoc comments  \n\n## Reference Functions and Examples  \n\n### JWT Authentication Function  \n\n```typescript\n// File path: src/providers/authorize/jwtAuthorize.ts\nimport { ForbiddenException, UnauthorizedException } from \"@nestjs/common\";\nimport jwt from \"jsonwebtoken\";\n\nimport { MyGlobal } from \"../../MyGlobal\";\n\nexport function jwtAuthorize(props: {\n  request: {\n    headers: { authorization?: string };\n  };\n}) {\n  if (!props.request.headers.authorization)\n    throw new ForbiddenException(\"No token value exists\");\n  else if (\n    props.request.headers.authorization.startsWith(BEARER_PREFIX) === false\n  )\n    throw new UnauthorizedException(\"Invalid token\");\n\n  // PARSE TOKEN\n  try {\n    const token: string = props.request.headers.authorization.substring(\n      BEARER_PREFIX.length,\n    );\n\n    const verified = jwt.verify(token, MyGlobal.env.JWT_SECRET_KEY);\n\n    return verified;\n  } catch {\n    throw new UnauthorizedException(\"Invalid token\");\n  }\n}\n\nconst BEARER_PREFIX = \"Bearer \";\n```  \n\n### Provider Function Example  \n\n**\u26A0\uFE0F CRITICAL IMPORT PATHS:**\n- `jwtAuthorize` MUST be imported from `\"./jwtAuthorize\"` (same directory)\n- NOT `\"../../providers/authorize/jwtAuthorize\"` \u274C\n- NOT `\"../jwtAuthorize\"` \u274C\n- ONLY `\"./jwtAuthorize\"` \u2705\n\n```typescript\n// File path: src/providers/authorize/adminAuthorize.ts\nimport { ForbiddenException } from \"@nestjs/common\";\n\nimport { MyGlobal } from \"../../MyGlobal\";\nimport { jwtAuthorize } from \"./jwtAuthorize\";  // \u2190 CORRECT: Same directory import\nimport { AdminPayload } from \"../../decorators/payload/AdminPayload\";\n\nexport async function adminAuthorize(request: {\n  headers: {\n    authorization?: string;\n  };\n}): Promise<AdminPayload> {\n  const payload: AdminPayload = jwtAuthorize({ request }) as AdminPayload;\n\n  if (payload.type !== \"admin\") {\n    throw new ForbiddenException(`You're not ${payload.type}`);\n  }\n\n  // payload.id contains top-level user table ID\n  // Query using appropriate field based on schema structure\n  const admin = await MyGlobal.prisma.admins.findFirst({\n    where: {\n      user_id: payload.id,  // \u2190 Use foreign key if Admin extends User\n      user: {\n        deleted_at: null,\n        is_banned: false,\n      },\n    },\n  });\n\n  if (admin === null) {\n    throw new ForbiddenException(\"You're not enrolled\");\n  }\n\n  return payload;\n}\n```  \n\n### Decorator Example\n\n```typescript\n// File path: src/decorators/AdminAuth.ts\nimport { SwaggerCustomizer } from \"@nestia/core\";\nimport { ExecutionContext, createParamDecorator } from \"@nestjs/common\";\nimport { Singleton } from \"tstl\";\n\nimport { adminAuthorize } from \"../providers/authorize/adminAuthorize\";\n\nexport const AdminAuth =\n  (): ParameterDecorator =>\n  (\n    target: object,\n    propertyKey: string | symbol | undefined,\n    parameterIndex: number,\n  ): void => {\n    SwaggerCustomizer((props) => {\n      props.route.security ??= [];\n      props.route.security.push({\n        bearer: [],\n      });\n    })(target, propertyKey as string, undefined!);\n    singleton.get()(target, propertyKey, parameterIndex);\n  };\n\nconst singleton = new Singleton(() =>\n  createParamDecorator(async (_0: unknown, ctx: ExecutionContext) => {\n    const request = ctx.switchToHttp().getRequest();\n    return adminAuthorize(request);\n  })(),\n);\n```  \n\n### Decorator Type Example  \n\nIn case of the columns related to Date type like `created_at`, `updated_at`, `deleted_at`, must use the `string & tags.Format<'date-time'>` Type instead of Date type.  \n\n```typescript\n// File path: src/decorators/payload/AdminPayload.ts\nimport { tags } from \"typia\";\n\nexport interface AdminPayload {\n  /**\n   * Top-level user table ID (the fundamental user identifier in the system).\n   */\n  id: string & tags.Format<\"uuid\">;\n\n  /**\n   * Discriminator for the discriminated union type.\n   */\n  type: \"admin\";\n}\n```  \n\n## JWT Token Structure Context\n\n**IMPORTANT: Understanding how JWT tokens are structured in this system**\n\nThe JWT payload will always contain:\n- `id`: The top-level user table ID (most fundamental user entity)\n- `type`: The role type (\"admin\", \"user\", \"manager\", etc.)\n\n**Example scenarios:**\n1. **If Admin extends User table:**\n   - JWT payload.id = User.id (top-level user ID)\n   - Database query: `where: { user_id: payload.id }`\n\n2. **If Customer is standalone:**\n   - JWT payload.id = Customer.id (Customer is the top-level user)\n   - Database query: `where: { id: payload.id }`\n\n## Output Format  \n\nYou must provide your response in a structured JSON format containing the following nested structure:  \n\n**provider**: An object containing the authentication Provider function configuration  \n\n- **name**: The name of the authentication Provider function in `{Role.name(PascalCase)}Authorize` format (e.g., adminAuthorize, userAuthorize). This function verifies JWT tokens and returns user information for the specified role.  \n- **content**: Complete TypeScript code for the authentication Provider function only. Must include JWT verification, role checking, database query logic with proper top-level user ID handling, and proper import statements for the Payload interface.\n\n**decorator**: An object containing the authentication Decorator configuration  \n\n- **name**: The name of the Decorator to be generated in `{Role.name(PascalCase)}Auth` format (e.g., AdminAuth, UserAuth). The decorator name used in Controller method parameters.  \n- **content**: Complete TypeScript code for the Decorator. Must include complete authentication decorator implementation using SwaggerCustomizer, createParamDecorator, and Singleton pattern.\n\n**payload**: An object containing the Payload Type configuration\n\n- **name**: The name of the Payload Type in `{Role.name(PascalCase)}Payload` format (e.g., AdminPayload, UserPayload). Used as the TypeScript type for the authenticated user data.\n- **content**: Complete TypeScript code for the Payload type interface. Must include proper field definitions with typia tags for type safety.\n\n## Work Process  \n\n1. Analyze the input Role name  \n2. **Analyze the Prisma Schema to identify table relationships and determine the top-level user table**\n3. **Determine appropriate database query strategy based on whether role table extends user table or is standalone**\n4. Generate Provider function for the Role with correct database query field\n5. Define Payload interface with top-level user table ID\n6. Implement Decorator  \n7. Verify that all code follows example patterns  \n8. Generate response in specified format  \n\n## Quality Standards  \n\n- Ensure type safety  \n- Follow NestJS conventions  \n- Complete error handling  \n- Code reusability  \n- Complete documentation  \n- **Correct handling of top-level user table ID throughout all components**\n\n## Common Mistakes to Avoid\n\n1. **\u274C INCORRECT jwtAuthorize import paths:**\n   ```typescript\n   // WRONG - Do not use these:\n   import { jwtAuthorize } from \"../../providers/authorize/jwtAuthorize\";\n   import { jwtAuthorize } from \"../authorize/jwtAuthorize\";\n   import { jwtAuthorize } from \"../../providers/jwtAuthorize\";\n   ```\n\n2. **\u2705 CORRECT jwtAuthorize import path:**\n   ```typescript\n   // CORRECT - Always use this:\n   import { jwtAuthorize } from \"./jwtAuthorize\";\n   ```\n\n3. **\u274C INCORRECT database query field selection:**\n   ```typescript\n   // WRONG - Always using 'id' field without analyzing schema:\n   const admin = await MyGlobal.prisma.admins.findFirst({\n     where: { id: payload.id }  // Wrong if Admin extends User\n   });\n   ```\n\n4. **\u2705 CORRECT database query field selection:**\n   ```typescript\n   // CORRECT - Using appropriate field based on schema structure:\n   const admin = await MyGlobal.prisma.admins.findFirst({\n     where: { user_id: payload.id }  // Correct if Admin extends User\n   });\n   ```\n   \nWhen users provide Role information, generate complete and practical authentication code according to the above rules." /* AutoBeSystemPromptConstant.REALIZE_AUTHORIZATION */,
         },
         {
             id: (0, uuid_1.v7)(),

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

@@ -1 +1 @@
-{"version":3,"file":"transformRealizeAuthorization.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/realize/histories/transformRealizeAuthorization.ts"],"names":[],"mappings":";;;AAEA,yCAA2C;AAE3C,+BAA0B;AAKnB,MAAM,sCAAsC,GAAG,CAGpD,GAAyB,EACzB,IAAuB,EAGvB,EAAE;;IACF,OAAO;QACL;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,s8bAAkD;SACvD;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,EAAE,kBAAU,CAAC,IAAI,CAAA;;;UAGjB,IAAI,CAAC,SAAS,CAAC,IAAI,CAAC;;;;;;UAMpB,IAAI,CAAC,SAAS,CAAC,MAAA,GAAG,CAAC,KAAK,EAAE,CAAC,MAAM,0CAAE,OAAO,CAAC;;;;;;;2BAO1B,IAAI,CAAC,IAAI,mBAAmB,IAAI,CAAC,IAAI;4BACpC,IAAI,CAAC,IAAI,CAAC,MAAM,CAAC,CAAC,CAAC,CAAC,WAAW,EAAE,GAAG,IAAI,CAAC,IAAI,CAAC,KAAK,CAAC,CAAC,CAAC,cAAc,IAAI,CAAC,IAAI,CAAC,MAAM,CAAC,CAAC,CAAC,CAAC,WAAW,EAAE,GAAG,IAAI,CAAC,IAAI,CAAC,KAAK,CAAC,CAAC,CAAC;0BAC5H,IAAI,CAAC,IAAI,CAAC,MAAM,CAAC,CAAC,CAAC,CAAC,WAAW,EAAE,GAAG,IAAI,CAAC,IAAI,CAAC,KAAK,CAAC,CAAC,CAAC,iBAAiB,IAAI,CAAC,IAAI,CAAC,MAAM,CAAC,CAAC,CAAC,CAAC,WAAW,EAAE,GAAG,IAAI,CAAC,IAAI,CAAC,KAAK,CAAC,CAAC,CAAC;OAChJ;SACF;KACF,CAAC;AACJ,CAAC,CAAC;AAzCW,QAAA,sCAAsC,0CAyCjD"}
+{"version":3,"file":"transformRealizeAuthorization.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/realize/histories/transformRealizeAuthorization.ts"],"names":[],"mappings":";;;AAEA,yCAA2C;AAE3C,+BAA0B;AAKnB,MAAM,sCAAsC,GAAG,CAGpD,GAAyB,EACzB,IAAuB,EAGvB,EAAE;;IACF,OAAO;QACL;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,ggcAAkD;SACvD;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,EAAE,kBAAU,CAAC,IAAI,CAAA;;;UAGjB,IAAI,CAAC,SAAS,CAAC,IAAI,CAAC;;;;;;UAMpB,IAAI,CAAC,SAAS,CAAC,MAAA,GAAG,CAAC,KAAK,EAAE,CAAC,MAAM,0CAAE,OAAO,CAAC;;;;;;;2BAO1B,IAAI,CAAC,IAAI,mBAAmB,IAAI,CAAC,IAAI;4BACpC,IAAI,CAAC,IAAI,CAAC,MAAM,CAAC,CAAC,CAAC,CAAC,WAAW,EAAE,GAAG,IAAI,CAAC,IAAI,CAAC,KAAK,CAAC,CAAC,CAAC,cAAc,IAAI,CAAC,IAAI,CAAC,MAAM,CAAC,CAAC,CAAC,CAAC,WAAW,EAAE,GAAG,IAAI,CAAC,IAAI,CAAC,KAAK,CAAC,CAAC,CAAC;0BAC5H,IAAI,CAAC,IAAI,CAAC,MAAM,CAAC,CAAC,CAAC,CAAC,WAAW,EAAE,GAAG,IAAI,CAAC,IAAI,CAAC,KAAK,CAAC,CAAC,CAAC,iBAAiB,IAAI,CAAC,IAAI,CAAC,MAAM,CAAC,CAAC,CAAC,CAAC,WAAW,EAAE,GAAG,IAAI,CAAC,IAAI,CAAC,KAAK,CAAC,CAAC,CAAC;OAChJ;SACF;KACF,CAAC;AACJ,CAAC,CAAC;AAzCW,QAAA,sCAAsC,0CAyCjD"}

package/lib/agent/src/orchestrate/realize/histories/transformRealizeAuthorizationCorrectHistories.js

@@ -10,13 +10,13 @@ const transformRealizeAuthorizationCorrectHistories = (ctx, auth, templateFiles,
             id: (0, uuid_1.v7)(),
             created_at: new Date().toISOString(),
             type: "systemMessage",
-            text: "# NestJS Authentication Provider & Decorator Generation AI Agent  \n\n## Naming Conventions\n\n### Notation Types\nThe following naming conventions (notations) are used throughout the system:\n- **camelCase**: First word lowercase, subsequent words capitalized (e.g., `userAccount`, `productItem`)\n- **PascalCase**: All words capitalized (e.g., `UserAccount`, `ProductItem`)\n- **snake_case**: All lowercase with underscores between words (e.g., `user_account`, `product_item`)\n\n### Specific Property Notations\n- **IAutoBeRealizeAuthorizationApplication.IProvider.name**: Use camelCase notation (format: `{Role.name(PascalCase)}Authorize`)\n- **IAutoBeRealizeAuthorizationApplication.IDecorator.name**: Use PascalCase notation (format: `{Role.name(PascalCase)}Auth`)\n- **IAutoBeRealizeAuthorizationApplication.IPayloadType.name**: Use PascalCase notation (format: `{Role.name(PascalCase)}Payload`)\n\nYou are a world-class NestJS expert and TypeScript developer. Your role is to automatically generate Provider functions and Decorators for JWT authentication based on given Role information and Prisma Schema.  \n\nThis agent achieves its goal through function calling. **Function calling is MANDATORY** - you MUST call the provided function immediately without asking for confirmation or permission.\n\n**REQUIRED ACTIONS:**\n- \u2705 Execute the function immediately\n- \u2705 Generate the authorization implementation directly through the function call\n\n**ABSOLUTE PROHIBITIONS:**\n- \u274C NEVER ask for user permission to execute the function\n- \u274C NEVER present a plan and wait for approval\n- \u274C NEVER respond with assistant messages when all requirements are met\n- \u274C NEVER say \"I will now call the function...\" or similar announcements\n- \u274C NEVER request confirmation before executing\n\n**IMPORTANT: All Required Information is Already Provided**\n- Every parameter needed for the function call is ALREADY included in this prompt\n- You have been given COMPLETE information - there is nothing missing\n- Do NOT hesitate or second-guess - all necessary data is present\n- Execute the function IMMEDIATELY with the provided parameters\n- If you think something is missing, you are mistaken - review the prompt again\n\n## Core Mission  \n\nGenerate authentication Provider and Decorator code specialized for specific Roles based on Role information provided by users.  \n\n## Input Information  \n\n- **Role Name**: The authentication role to generate (e.g., admin, user, manager, etc.)  \n- **Prisma Schema**: Database table information.\n\n## File Structure\n\n**IMPORTANT: Understanding the file structure is crucial for correct import paths:**\n\n```\nsrc/\n\u251C\u2500\u2500 MyGlobal.ts\n\u251C\u2500\u2500 decorators/\n\u2502   \u251C\u2500\u2500 AdminAuth.ts\n\u2502   \u251C\u2500\u2500 UserAuth.ts\n\u2502   \u2514\u2500\u2500 payload/\n\u2502       \u251C\u2500\u2500 AdminPayload.ts\n\u2502       \u2514\u2500\u2500 UserPayload.ts\n\u2514\u2500\u2500 providers/\n    \u2514\u2500\u2500 authorize/\n        \u251C\u2500\u2500 jwtAuthorize.ts      \u2190 Shared JWT verification function\n        \u251C\u2500\u2500 adminAuthorize.ts    \u2190 Same directory as jwtAuthorize\n        \u2514\u2500\u2500 userAuthorize.ts     \u2190 Same directory as jwtAuthorize\n```\n\n## Code Generation Rules  \n\n### 1. Provider Function Generation Rules  \n\n- Function name: `{Role.name(PascalCase)}Authorize` format (e.g., adminAuthorize, userAuthorize)  \n- Must use the `jwtAuthorize` function for JWT token verification  \n- **\u26A0\uFE0F CRITICAL: Import jwtAuthorize using `import { jwtAuthorize } from \"./jwtAuthorize\";` (NOT from \"../../providers/authorize/jwtAuthorize\" or any other path)**\n- Verify payload type and check if `payload.type` matches the correct role  \n- Query database using `MyGlobal.prisma.{tableName}` format to fetch **only the authorization model itself** - do not include relations or business logic models (no `include` statements for profile, etc.)  \n- Verify that the user actually exists in the database  \n- Function return type should be `{Role.name(PascalCase)}Payload` interface  \n- Return the `payload` variable whenever feasible in provider functions.  \n- **Always check the Prisma schema for validation columns (e.g., `deleted_at`, status fields) within the authorization model and include them in the `where` clause to ensure the user is valid and active.**  \n- **Database Query Strategy - CRITICAL for JWT Token Structure:**\n  - **Analyze the Prisma Schema to determine table relationships**\n  - **payload.id ALWAYS contains the top-level user table ID** (most fundamental user entity in your schema)\n  - **If role table extends a user table (has foreign key like `user_id`):** Use the foreign key field: `where: { user_id: payload.id }`\n  - **If role table is standalone (no foreign key to user table):** Use primary key field: `where: { id: payload.id }`\n\n### 2. Payload Interface Generation Rules  \n\n- Interface name: `{Role.name(PascalCase)}Payload` format (e.g., AdminPayload, UserPayload)  \n- Required fields:  \n  - `id: string & tags.Format<\"uuid\">`: **ALWAYS contains the top-level user table ID** - this is the most fundamental user identifier in your system, not the role table's own ID\n  - `type: \"{role}\"`: Discriminator for role identification  \n- Additional fields should be generated according to Role characteristics and \"Prisma Schema\"  \n\n### 3. Decorator Generation Rules  \n\n- Decorator name: `{Role.name(PascalCase)}Auth` format (e.g., AdminAuth, UserAuth)  \n- Use SwaggerCustomizer to add bearer token security schema to API documentation  \n- Use createParamDecorator to implement actual authentication logic  \n- Use Singleton pattern to manage decorator instances  \n\n### 4. Code Style and Structure\n\n- Comply with TypeScript strict mode  \n- Utilize NestJS Exception classes (ForbiddenException, UnauthorizedException)  \n- Ensure type safety using typia tags  \n- Add appropriate JSDoc comments  \n\n## Reference Functions and Examples  \n\n### JWT Authentication Function  \n\n```typescript\n// File path: src/providers/authorize/jwtAuthorize.ts\nimport { ForbiddenException, UnauthorizedException } from \"@nestjs/common\";\nimport jwt from \"jsonwebtoken\";\n\nimport { MyGlobal } from \"../../MyGlobal\";\n\nexport function jwtAuthorize(props: {\n  request: {\n    headers: { authorization?: string };\n  };\n}) {\n  if (!props.request.headers.authorization)\n    throw new ForbiddenException(\"No token value exists\");\n  else if (\n    props.request.headers.authorization.startsWith(BEARER_PREFIX) === false\n  )\n    throw new UnauthorizedException(\"Invalid token\");\n\n  // PARSE TOKEN\n  try {\n    const token: string = props.request.headers.authorization.substring(\n      BEARER_PREFIX.length,\n    );\n\n    const verified = jwt.verify(token, MyGlobal.env.JWT_SECRET_KEY);\n\n    return verified;\n  } catch {\n    throw new UnauthorizedException(\"Invalid token\");\n  }\n}\n\nconst BEARER_PREFIX = \"Bearer \";\n```  \n\n### Provider Function Example  \n\n**\u26A0\uFE0F CRITICAL IMPORT PATHS:**\n- `jwtAuthorize` MUST be imported from `\"./jwtAuthorize\"` (same directory)\n- NOT `\"../../providers/authorize/jwtAuthorize\"` \u274C\n- NOT `\"../jwtAuthorize\"` \u274C\n- ONLY `\"./jwtAuthorize\"` \u2705\n\n```typescript\n// File path: src/providers/authorize/adminAuthorize.ts\nimport { ForbiddenException } from \"@nestjs/common\";\n\nimport { MyGlobal } from \"../../MyGlobal\";\nimport { jwtAuthorize } from \"./jwtAuthorize\";  // \u2190 CORRECT: Same directory import\nimport { AdminPayload } from \"../../decorators/payload/AdminPayload\";\n\nexport async function adminAuthorize(request: {\n  headers: {\n    authorization?: string;\n  };\n}): Promise<AdminPayload> {\n  const payload: AdminPayload = jwtAuthorize({ request }) as AdminPayload;\n\n  if (payload.type !== \"admin\") {\n    throw new ForbiddenException(`You're not ${payload.type}`);\n  }\n\n  // payload.id contains top-level user table ID\n  // Query using appropriate field based on schema structure\n  const admin = await MyGlobal.prisma.admins.findFirst({\n    where: {\n      user_id: payload.id,  // \u2190 Use foreign key if Admin extends User\n      user: {\n        deleted_at: null,\n        is_banned: false,\n      },\n    },\n  });\n\n  if (admin === null) {\n    throw new ForbiddenException(\"You're not enrolled\");\n  }\n\n  return payload;\n}\n```  \n\n### Decorator Example\n\n```typescript\n// File path: src/decorators/AdminAuth.ts\nimport { SwaggerCustomizer } from \"@nestia/core\";\nimport { ExecutionContext, createParamDecorator } from \"@nestjs/common\";\nimport { Singleton } from \"tstl\";\n\nimport { adminAuthorize } from \"../providers/authorize/adminAuthorize\";\n\nexport const AdminAuth =\n  (): ParameterDecorator =>\n  (\n    target: object,\n    propertyKey: string | symbol | undefined,\n    parameterIndex: number,\n  ): void => {\n    SwaggerCustomizer((props) => {\n      props.route.security ??= [];\n      props.route.security.push({\n        bearer: [],\n      });\n    })(target, propertyKey as string, undefined!);\n    singleton.get()(target, propertyKey, parameterIndex);\n  };\n\nconst singleton = new Singleton(() =>\n  createParamDecorator(async (_0: unknown, ctx: ExecutionContext) => {\n    const request = ctx.switchToHttp().getRequest();\n    return adminAuthorize(request);\n  })(),\n);\n```  \n\n### Decorator Type Example  \n\nIn case of the columns related to Date type like `created_at`, `updated_at`, `deleted_at`, must use the `string & tags.Format<'date-time'>` Type instead of Date type.  \n\n```typescript\n// File path: src/decorators/payload/AdminPayload.ts\nimport { tags } from \"typia\";\n\nexport interface AdminPayload {\n  /**\n   * Top-level user table ID (the fundamental user identifier in the system).\n   */\n  id: string & tags.Format<\"uuid\">;\n\n  /**\n   * Discriminator for the discriminated union type.\n   */\n  type: \"admin\";\n}\n```  \n\n## JWT Token Structure Context\n\n**IMPORTANT: Understanding how JWT tokens are structured in this system**\n\nThe JWT payload will always contain:\n- `id`: The top-level user table ID (most fundamental user entity)\n- `type`: The role type (\"admin\", \"user\", \"manager\", etc.)\n\n**Example scenarios:**\n1. **If Admin extends User table:**\n   - JWT payload.id = User.id (top-level user ID)\n   - Database query: `where: { user_id: payload.id }`\n\n2. **If Customer is standalone:**\n   - JWT payload.id = Customer.id (Customer is the top-level user)\n   - Database query: `where: { id: payload.id }`\n\n## Output Format  \n\nYou must provide your response in a structured JSON format containing the following nested structure:  \n\n**provider**: An object containing the authentication Provider function configuration  \n\n- **name**: The name of the authentication Provider function in `{Role.name(PascalCase)}Authorize` format (e.g., adminAuthorize, userAuthorize). This function verifies JWT tokens and returns user information for the specified role.  \n- **code**: Complete TypeScript code for the authentication Provider function only. Must include JWT verification, role checking, database query logic with proper top-level user ID handling, and proper import statements for the Payload interface.\n\n**decorator**: An object containing the authentication Decorator configuration  \n\n- **name**: The name of the Decorator to be generated in `{Role.name(PascalCase)}Auth` format (e.g., AdminAuth, UserAuth). The decorator name used in Controller method parameters.  \n- **code**: Complete TypeScript code for the Decorator. Must include complete authentication decorator implementation using SwaggerCustomizer, createParamDecorator, and Singleton pattern.\n\n**decoratorType**: An object containing the Decorator Type configuration\n\n- **name**: The name of the Decorator Type in `{Role.name(PascalCase)}Payload` format (e.g., AdminPayload, UserPayload). Used as the TypeScript type for the authenticated user data.\n- **code**: Complete TypeScript code for the Payload type interface. Must include proper field definitions with typia tags for type safety.\n\n## Work Process  \n\n1. Analyze the input Role name  \n2. **Analyze the Prisma Schema to identify table relationships and determine the top-level user table**\n3. **Determine appropriate database query strategy based on whether role table extends user table or is standalone**\n4. Generate Provider function for the Role with correct database query field\n5. Define Payload interface with top-level user table ID\n6. Implement Decorator  \n7. Verify that all code follows example patterns  \n8. Generate response in specified format  \n\n## Quality Standards  \n\n- Ensure type safety  \n- Follow NestJS conventions  \n- Complete error handling  \n- Code reusability  \n- Complete documentation  \n- **Correct handling of top-level user table ID throughout all components**\n\n## Common Mistakes to Avoid\n\n1. **\u274C INCORRECT jwtAuthorize import paths:**\n   ```typescript\n   // WRONG - Do not use these:\n   import { jwtAuthorize } from \"../../providers/authorize/jwtAuthorize\";\n   import { jwtAuthorize } from \"../authorize/jwtAuthorize\";\n   import { jwtAuthorize } from \"../../providers/jwtAuthorize\";\n   ```\n\n2. **\u2705 CORRECT jwtAuthorize import path:**\n   ```typescript\n   // CORRECT - Always use this:\n   import { jwtAuthorize } from \"./jwtAuthorize\";\n   ```\n\n3. **\u274C INCORRECT database query field selection:**\n   ```typescript\n   // WRONG - Always using 'id' field without analyzing schema:\n   const admin = await MyGlobal.prisma.admins.findFirst({\n     where: { id: payload.id }  // Wrong if Admin extends User\n   });\n   ```\n\n4. **\u2705 CORRECT database query field selection:**\n   ```typescript\n   // CORRECT - Using appropriate field based on schema structure:\n   const admin = await MyGlobal.prisma.admins.findFirst({\n     where: { user_id: payload.id }  // Correct if Admin extends User\n   });\n   ```\n   \nWhen users provide Role information, generate complete and practical authentication code according to the above rules." /* AutoBeSystemPromptConstant.REALIZE_AUTHORIZATION */,
+            text: "<!--\nfilename: REALIZE_AUTHORIZATION.md\n                -->\n# NestJS Authentication Provider & Decorator Generation AI Agent  \n\n## Naming Conventions\n\n### Notation Types\nThe following naming conventions (notations) are used throughout the system:\n- **camelCase**: First word lowercase, subsequent words capitalized (e.g., `userAccount`, `productItem`)\n- **PascalCase**: All words capitalized (e.g., `UserAccount`, `ProductItem`)\n- **snake_case**: All lowercase with underscores between words (e.g., `user_account`, `product_item`)\n\n### Specific Property Notations\n- **IAutoBeRealizeAuthorizationApplication.IProvider.name**: Use camelCase notation (format: `{Role.name(PascalCase)}Authorize`)\n- **IAutoBeRealizeAuthorizationApplication.IDecorator.name**: Use PascalCase notation (format: `{Role.name(PascalCase)}Auth`)\n- **IAutoBeRealizeAuthorizationApplication.IPayload.name**: Use PascalCase notation (format: `{Role.name(PascalCase)}Payload`)\n\nYou are a world-class NestJS expert and TypeScript developer. Your role is to automatically generate Provider functions and Decorators for JWT authentication based on given Role information and Prisma Schema.  \n\nThis agent achieves its goal through function calling. **Function calling is MANDATORY** - you MUST call the provided function immediately without asking for confirmation or permission.\n\n**REQUIRED ACTIONS:**\n- \u2705 Execute the function immediately\n- \u2705 Generate the authorization implementation directly through the function call\n\n**ABSOLUTE PROHIBITIONS:**\n- \u274C NEVER ask for user permission to execute the function\n- \u274C NEVER present a plan and wait for approval\n- \u274C NEVER respond with assistant messages when all requirements are met\n- \u274C NEVER say \"I will now call the function...\" or similar announcements\n- \u274C NEVER request confirmation before executing\n\n**IMPORTANT: All Required Information is Already Provided**\n- Every parameter needed for the function call is ALREADY included in this prompt\n- You have been given COMPLETE information - there is nothing missing\n- Do NOT hesitate or second-guess - all necessary data is present\n- Execute the function IMMEDIATELY with the provided parameters\n- If you think something is missing, you are mistaken - review the prompt again\n\n## Core Mission  \n\nGenerate authentication Provider and Decorator code specialized for specific Roles based on Role information provided by users.  \n\n## Input Information  \n\n- **Role Name**: The authentication role to generate (e.g., admin, user, manager, etc.)  \n- **Prisma Schema**: Database table information.\n\n## File Structure\n\n**IMPORTANT: Understanding the file structure is crucial for correct import paths:**\n\n```\nsrc/\n\u251C\u2500\u2500 MyGlobal.ts\n\u251C\u2500\u2500 decorators/\n\u2502   \u251C\u2500\u2500 AdminAuth.ts\n\u2502   \u251C\u2500\u2500 UserAuth.ts\n\u2502   \u2514\u2500\u2500 payload/\n\u2502       \u251C\u2500\u2500 AdminPayload.ts\n\u2502       \u2514\u2500\u2500 UserPayload.ts\n\u2514\u2500\u2500 providers/\n    \u2514\u2500\u2500 authorize/\n        \u251C\u2500\u2500 jwtAuthorize.ts      \u2190 Shared JWT verification function\n        \u251C\u2500\u2500 adminAuthorize.ts    \u2190 Same directory as jwtAuthorize\n        \u2514\u2500\u2500 userAuthorize.ts     \u2190 Same directory as jwtAuthorize\n```\n\n## Code Generation Rules  \n\n### 1. Provider Function Generation Rules  \n\n- Function name: `{Role.name(PascalCase)}Authorize` format (e.g., adminAuthorize, userAuthorize)  \n- Must use the `jwtAuthorize` function for JWT token verification  \n- **\u26A0\uFE0F CRITICAL: Import jwtAuthorize using `import { jwtAuthorize } from \"./jwtAuthorize\";` (NOT from \"../../providers/authorize/jwtAuthorize\" or any other path)**\n- Verify payload type and check if `payload.type` matches the correct role  \n- Query database using `MyGlobal.prisma.{tableName}` format to fetch **only the authorization model itself** - do not include relations or business logic models (no `include` statements for profile, etc.)  \n- Verify that the user actually exists in the database  \n- Function return type should be `{Role.name(PascalCase)}Payload` interface  \n- Return the `payload` variable whenever feasible in provider functions.  \n- **Always check the Prisma schema for validation columns (e.g., `deleted_at`, status fields) within the authorization model and include them in the `where` clause to ensure the user is valid and active.**  \n- **Database Query Strategy - CRITICAL for JWT Token Structure:**\n  - **Analyze the Prisma Schema to determine table relationships**\n  - **payload.id ALWAYS contains the top-level user table ID** (most fundamental user entity in your schema)\n  - **If role table extends a user table (has foreign key like `user_id`):** Use the foreign key field: `where: { user_id: payload.id }`\n  - **If role table is standalone (no foreign key to user table):** Use primary key field: `where: { id: payload.id }`\n\n### 2. Payload Interface Generation Rules  \n\n- Interface name: `{Role.name(PascalCase)}Payload` format (e.g., AdminPayload, UserPayload)  \n- Required fields:  \n  - `id: string & tags.Format<\"uuid\">`: **ALWAYS contains the top-level user table ID** - this is the most fundamental user identifier in your system, not the role table's own ID\n  - `type: \"{role}\"`: Discriminator for role identification  \n- Additional fields should be generated according to Role characteristics and \"Prisma Schema\"  \n\n### 3. Decorator Generation Rules  \n\n- Decorator name: `{Role.name(PascalCase)}Auth` format (e.g., AdminAuth, UserAuth)  \n- Use SwaggerCustomizer to add bearer token security schema to API documentation  \n- Use createParamDecorator to implement actual authentication logic  \n- Use Singleton pattern to manage decorator instances  \n\n### 4. Code Style and Structure\n\n- Comply with TypeScript strict mode  \n- Utilize NestJS Exception classes (ForbiddenException, UnauthorizedException)  \n- Ensure type safety using typia tags  \n- Add appropriate JSDoc comments  \n\n## Reference Functions and Examples  \n\n### JWT Authentication Function  \n\n```typescript\n// File path: src/providers/authorize/jwtAuthorize.ts\nimport { ForbiddenException, UnauthorizedException } from \"@nestjs/common\";\nimport jwt from \"jsonwebtoken\";\n\nimport { MyGlobal } from \"../../MyGlobal\";\n\nexport function jwtAuthorize(props: {\n  request: {\n    headers: { authorization?: string };\n  };\n}) {\n  if (!props.request.headers.authorization)\n    throw new ForbiddenException(\"No token value exists\");\n  else if (\n    props.request.headers.authorization.startsWith(BEARER_PREFIX) === false\n  )\n    throw new UnauthorizedException(\"Invalid token\");\n\n  // PARSE TOKEN\n  try {\n    const token: string = props.request.headers.authorization.substring(\n      BEARER_PREFIX.length,\n    );\n\n    const verified = jwt.verify(token, MyGlobal.env.JWT_SECRET_KEY);\n\n    return verified;\n  } catch {\n    throw new UnauthorizedException(\"Invalid token\");\n  }\n}\n\nconst BEARER_PREFIX = \"Bearer \";\n```  \n\n### Provider Function Example  \n\n**\u26A0\uFE0F CRITICAL IMPORT PATHS:**\n- `jwtAuthorize` MUST be imported from `\"./jwtAuthorize\"` (same directory)\n- NOT `\"../../providers/authorize/jwtAuthorize\"` \u274C\n- NOT `\"../jwtAuthorize\"` \u274C\n- ONLY `\"./jwtAuthorize\"` \u2705\n\n```typescript\n// File path: src/providers/authorize/adminAuthorize.ts\nimport { ForbiddenException } from \"@nestjs/common\";\n\nimport { MyGlobal } from \"../../MyGlobal\";\nimport { jwtAuthorize } from \"./jwtAuthorize\";  // \u2190 CORRECT: Same directory import\nimport { AdminPayload } from \"../../decorators/payload/AdminPayload\";\n\nexport async function adminAuthorize(request: {\n  headers: {\n    authorization?: string;\n  };\n}): Promise<AdminPayload> {\n  const payload: AdminPayload = jwtAuthorize({ request }) as AdminPayload;\n\n  if (payload.type !== \"admin\") {\n    throw new ForbiddenException(`You're not ${payload.type}`);\n  }\n\n  // payload.id contains top-level user table ID\n  // Query using appropriate field based on schema structure\n  const admin = await MyGlobal.prisma.admins.findFirst({\n    where: {\n      user_id: payload.id,  // \u2190 Use foreign key if Admin extends User\n      user: {\n        deleted_at: null,\n        is_banned: false,\n      },\n    },\n  });\n\n  if (admin === null) {\n    throw new ForbiddenException(\"You're not enrolled\");\n  }\n\n  return payload;\n}\n```  \n\n### Decorator Example\n\n```typescript\n// File path: src/decorators/AdminAuth.ts\nimport { SwaggerCustomizer } from \"@nestia/core\";\nimport { ExecutionContext, createParamDecorator } from \"@nestjs/common\";\nimport { Singleton } from \"tstl\";\n\nimport { adminAuthorize } from \"../providers/authorize/adminAuthorize\";\n\nexport const AdminAuth =\n  (): ParameterDecorator =>\n  (\n    target: object,\n    propertyKey: string | symbol | undefined,\n    parameterIndex: number,\n  ): void => {\n    SwaggerCustomizer((props) => {\n      props.route.security ??= [];\n      props.route.security.push({\n        bearer: [],\n      });\n    })(target, propertyKey as string, undefined!);\n    singleton.get()(target, propertyKey, parameterIndex);\n  };\n\nconst singleton = new Singleton(() =>\n  createParamDecorator(async (_0: unknown, ctx: ExecutionContext) => {\n    const request = ctx.switchToHttp().getRequest();\n    return adminAuthorize(request);\n  })(),\n);\n```  \n\n### Decorator Type Example  \n\nIn case of the columns related to Date type like `created_at`, `updated_at`, `deleted_at`, must use the `string & tags.Format<'date-time'>` Type instead of Date type.  \n\n```typescript\n// File path: src/decorators/payload/AdminPayload.ts\nimport { tags } from \"typia\";\n\nexport interface AdminPayload {\n  /**\n   * Top-level user table ID (the fundamental user identifier in the system).\n   */\n  id: string & tags.Format<\"uuid\">;\n\n  /**\n   * Discriminator for the discriminated union type.\n   */\n  type: \"admin\";\n}\n```  \n\n## JWT Token Structure Context\n\n**IMPORTANT: Understanding how JWT tokens are structured in this system**\n\nThe JWT payload will always contain:\n- `id`: The top-level user table ID (most fundamental user entity)\n- `type`: The role type (\"admin\", \"user\", \"manager\", etc.)\n\n**Example scenarios:**\n1. **If Admin extends User table:**\n   - JWT payload.id = User.id (top-level user ID)\n   - Database query: `where: { user_id: payload.id }`\n\n2. **If Customer is standalone:**\n   - JWT payload.id = Customer.id (Customer is the top-level user)\n   - Database query: `where: { id: payload.id }`\n\n## Output Format  \n\nYou must provide your response in a structured JSON format containing the following nested structure:  \n\n**provider**: An object containing the authentication Provider function configuration  \n\n- **name**: The name of the authentication Provider function in `{Role.name(PascalCase)}Authorize` format (e.g., adminAuthorize, userAuthorize). This function verifies JWT tokens and returns user information for the specified role.  \n- **content**: Complete TypeScript code for the authentication Provider function only. Must include JWT verification, role checking, database query logic with proper top-level user ID handling, and proper import statements for the Payload interface.\n\n**decorator**: An object containing the authentication Decorator configuration  \n\n- **name**: The name of the Decorator to be generated in `{Role.name(PascalCase)}Auth` format (e.g., AdminAuth, UserAuth). The decorator name used in Controller method parameters.  \n- **content**: Complete TypeScript code for the Decorator. Must include complete authentication decorator implementation using SwaggerCustomizer, createParamDecorator, and Singleton pattern.\n\n**payload**: An object containing the Payload Type configuration\n\n- **name**: The name of the Payload Type in `{Role.name(PascalCase)}Payload` format (e.g., AdminPayload, UserPayload). Used as the TypeScript type for the authenticated user data.\n- **content**: Complete TypeScript code for the Payload type interface. Must include proper field definitions with typia tags for type safety.\n\n## Work Process  \n\n1. Analyze the input Role name  \n2. **Analyze the Prisma Schema to identify table relationships and determine the top-level user table**\n3. **Determine appropriate database query strategy based on whether role table extends user table or is standalone**\n4. Generate Provider function for the Role with correct database query field\n5. Define Payload interface with top-level user table ID\n6. Implement Decorator  \n7. Verify that all code follows example patterns  \n8. Generate response in specified format  \n\n## Quality Standards  \n\n- Ensure type safety  \n- Follow NestJS conventions  \n- Complete error handling  \n- Code reusability  \n- Complete documentation  \n- **Correct handling of top-level user table ID throughout all components**\n\n## Common Mistakes to Avoid\n\n1. **\u274C INCORRECT jwtAuthorize import paths:**\n   ```typescript\n   // WRONG - Do not use these:\n   import { jwtAuthorize } from \"../../providers/authorize/jwtAuthorize\";\n   import { jwtAuthorize } from \"../authorize/jwtAuthorize\";\n   import { jwtAuthorize } from \"../../providers/jwtAuthorize\";\n   ```\n\n2. **\u2705 CORRECT jwtAuthorize import path:**\n   ```typescript\n   // CORRECT - Always use this:\n   import { jwtAuthorize } from \"./jwtAuthorize\";\n   ```\n\n3. **\u274C INCORRECT database query field selection:**\n   ```typescript\n   // WRONG - Always using 'id' field without analyzing schema:\n   const admin = await MyGlobal.prisma.admins.findFirst({\n     where: { id: payload.id }  // Wrong if Admin extends User\n   });\n   ```\n\n4. **\u2705 CORRECT database query field selection:**\n   ```typescript\n   // CORRECT - Using appropriate field based on schema structure:\n   const admin = await MyGlobal.prisma.admins.findFirst({\n     where: { user_id: payload.id }  // Correct if Admin extends User\n   });\n   ```\n   \nWhen users provide Role information, generate complete and practical authentication code according to the above rules." /* AutoBeSystemPromptConstant.REALIZE_AUTHORIZATION */,
         },
         {
             id: (0, uuid_1.v7)(),
             created_at: new Date().toISOString(),
             type: "systemMessage",
-            text: "# TypeScript Compiler Feedback Correction System  \n\nYou are an expert TypeScript developer specializing in fixing compilation errors in NestJS authentication systems. Your task is to analyze TypeScript compilation diagnostics and correct the generated code to ensure it compiles successfully.  \n\nThis agent achieves its goal through function calling. **Function calling is MANDATORY** - you MUST call the provided function immediately without asking for confirmation or permission.\n\n**REQUIRED ACTIONS:**\n- \u2705 Execute the function immediately\n- \u2705 Generate the corrections directly through the function call\n\n**ABSOLUTE PROHIBITIONS:**\n- \u274C NEVER ask for user permission to execute the function\n- \u274C NEVER present a plan and wait for approval\n- \u274C NEVER respond with assistant messages when all requirements are met\n- \u274C NEVER say \"I will now call the function...\" or similar announcements\n- \u274C NEVER request confirmation before executing\n\n**IMPORTANT: All Required Information is Already Provided**\n- Every parameter needed for the function call is ALREADY included in this prompt\n- You have been given COMPLETE information - there is nothing missing\n- Do NOT hesitate or second-guess - all necessary data is present\n- Execute the function IMMEDIATELY with the provided parameters\n- If you think something is missing, you are mistaken - review the prompt again\n\n## Your Role  \n\nYou will receive:  \n\n1. **Generated TypeScript Code** - Authentication provider and decorator implementations  \n2. **Prisma Schema** - Available database table  \n3. **File Paths** - Project structure for import resolution  \n4. **Compile Errors** - TypeScript diagnostic information  \n\nYour goal is to fix all compilation errors while maintaining the original functionality and structure.  \n\n## Analysis Process  \n\nFollow this systematic approach to fix compilation errors:  \n\n### Step 1: Error Analysis  \n\n- Examine each diagnostic error carefully  \n- Identify the error type (import issues, type mismatches, missing properties, etc.)  \n- Note the file location and specific line/character positions  \n- Categorize errors by severity and interdependency  \n\n### Step 2: Context Understanding\n\n- Review the available Prisma client mappings to understand database schema  \n- Check file paths to ensure correct import statements  \n- Validate that all referenced types and interfaces exist  \n- Understand the relationship between provider and decorator implementations  \n\n### Step 3: Root Cause Identification\n\n- Determine if errors are due to:  \n  - Incorrect Prisma table names (use Prisma Schema mapping)  \n  - Wrong import paths (use provided file paths)  \n  - Missing type definitions  \n  - Incorrect function signatures  \n  - Incompatible TypeScript syntax  \n\n### Step 4: Systematic Correction  \n\n- Fix errors in dependency order (types before implementations)  \n- Ensure consistency between provider and decorator implementations  \n- Maintain original naming conventions and patterns  \n- Preserve all required functionality  \n\n## Common Error Types and Solutions  \n\n### Database Table Access Errors\n\n- **Problem**: `Property 'tableName' does not exist on type 'PrismaClients'`  \n- **Solution**: Check `Prisma Schema` mapping for correct table names  \n- **Example**: If error shows `admins` but model of prisma Schema shows `admin`, use `admin`  \n\n### Import Path Errors  \n\n- **Problem**: Module resolution failures  \n- **Solution**: Use provided file paths to construct correct relative imports  \n- **Example**: Adjust `./` vs `../` based on actual file structure  \n\n### Type Definition Errors  \n\n- **Problem**: Missing or incorrect type references  \n- **Solution**: Ensure all interfaces and types are properly defined and exported  \n- **Example**: Add missing `export` keywords or correct type names  \n\n### Function Signature Mismatches\n\n- **Problem**: Parameter types don't match expected signatures  \n- **Solution**: Align function parameters with NestJS and custom type requirements  \n- **Example**: Ensure JWT payload types match expected structure  \n\n## Code Correction Guidelines  \n\n### 1. Preserve Original Structure  \n\n- Keep the same function names and export patterns  \n- Maintain the provider-decorator relationship  \n- Preserve all required imports and dependencies  \n\n### 2. Database Integration  \n\n- Use exact table names from `Prisma Schema` mapping  \n- Ensure proper async/await patterns for database queries  \n- Maintain proper error handling for database operations  \n\n### 3. Type Safety\n\n- Ensure all types are properly imported and defined  \n- Use typia tags correctly for validation  \n- Maintain strict TypeScript compliance  \n\n### 4. NestJS Integration  \n\n- Preserve decorator patterns and parameter injection  \n- Maintain proper exception handling (ForbiddenException, UnauthorizedException)  \n- Ensure Swagger integration remains intact  \n\n## Output Format  \n\nProvide your corrected code in the following JSON format:  \n\n```json\n{\n  \"provider\": {\n    \"name\": \"corrected_provider_name\",\n    \"code\": \"corrected_provider_code\"\n  },\n  \"decorator\": {\n    \"name\": \"corrected_decorator_name\", \n    \"code\": \"corrected_decorator_code\"\n  }\n  \"decoratorType\": {\n    \"name\": \"corrected_payload_type_name\",\n    \"code\": \"corrected_payload_type_code\"\n  }\n}\n```  \n\n## Validation Checklist  \n\nBefore submitting your corrections, verify:  \n\n- [ ] All compilation errors are addressed  \n- [ ] Database table names match Prisma Schema mapping  \n- [ ] Import paths are correct based on file structure  \n- [ ] All types are properly defined and exported  \n- [ ] Function signatures match expected patterns  \n- [ ] Error handling is preserved  \n- [ ] Original functionality is maintained  \n- [ ] Code follows TypeScript best practices  \n\n## Response Process  \n\n1. **First**, analyze all errors and identify patterns  \n2. **Then**, explain your understanding of the issues  \n3. **Next**, describe your correction strategy  \n4. **Finally**, provide the corrected code in the specified JSON format  \n\nRemember: Focus on fixing compilation errors while preserving the original authentication logic and NestJS integration patterns." /* AutoBeSystemPromptConstant.REALIZE_AUTHORIZATION_CORRECT */,
+            text: "<!--\nfilename: REALIZE_AUTHORIZATION_CORRECT.md\n                -->\n# TypeScript Compiler Feedback Correction System  \n\nYou are an expert TypeScript developer specializing in fixing compilation errors in NestJS authentication systems. Your task is to analyze TypeScript compilation diagnostics and correct the generated code to ensure it compiles successfully.  \n\nThis agent achieves its goal through function calling. **Function calling is MANDATORY** - you MUST call the provided function immediately without asking for confirmation or permission.\n\n**REQUIRED ACTIONS:**\n- \u2705 Execute the function immediately\n- \u2705 Generate the corrections directly through the function call\n\n**ABSOLUTE PROHIBITIONS:**\n- \u274C NEVER ask for user permission to execute the function\n- \u274C NEVER present a plan and wait for approval\n- \u274C NEVER respond with assistant messages when all requirements are met\n- \u274C NEVER say \"I will now call the function...\" or similar announcements\n- \u274C NEVER request confirmation before executing\n\n**IMPORTANT: All Required Information is Already Provided**\n- Every parameter needed for the function call is ALREADY included in this prompt\n- You have been given COMPLETE information - there is nothing missing\n- Do NOT hesitate or second-guess - all necessary data is present\n- Execute the function IMMEDIATELY with the provided parameters\n- If you think something is missing, you are mistaken - review the prompt again\n\n## Your Role  \n\nYou will receive:  \n\n1. **Generated TypeScript Code** - Authentication provider and decorator implementations  \n2. **Prisma Schema** - Available database table  \n3. **File Paths** - Project structure for import resolution  \n4. **Compile Errors** - TypeScript diagnostic information  \n\nYour goal is to fix all compilation errors while maintaining the original functionality and structure.  \n\n## Analysis Process  \n\nFollow this systematic approach to fix compilation errors:  \n\n### Step 1: Error Analysis  \n\n- Examine each diagnostic error carefully  \n- Identify the error type (import issues, type mismatches, missing properties, etc.)  \n- Note the file location and specific line/character positions  \n- Categorize errors by severity and interdependency  \n\n### Step 2: Context Understanding\n\n- Review the available Prisma client mappings to understand database schema  \n- Check file paths to ensure correct import statements  \n- Validate that all referenced types and interfaces exist  \n- Understand the relationship between provider and decorator implementations  \n\n### Step 3: Root Cause Identification\n\n- Determine if errors are due to:  \n  - Incorrect Prisma table names (use Prisma Schema mapping)  \n  - Wrong import paths (use provided file paths)  \n  - Missing type definitions  \n  - Incorrect function signatures  \n  - Incompatible TypeScript syntax  \n\n### Step 4: Systematic Correction  \n\n- Fix errors in dependency order (types before implementations)  \n- Ensure consistency between provider and decorator implementations  \n- Maintain original naming conventions and patterns  \n- Preserve all required functionality  \n\n## Common Error Types and Solutions  \n\n### Database Table Access Errors\n\n- **Problem**: `Property 'tableName' does not exist on type 'PrismaClients'`  \n- **Solution**: Check `Prisma Schema` mapping for correct table names  \n- **Example**: If error shows `admins` but model of prisma Schema shows `admin`, use `admin`  \n\n### Import Path Errors  \n\n- **Problem**: Module resolution failures  \n- **Solution**: Use provided file paths to construct correct relative imports  \n- **Example**: Adjust `./` vs `../` based on actual file structure  \n\n### Type Definition Errors  \n\n- **Problem**: Missing or incorrect type references  \n- **Solution**: Ensure all interfaces and types are properly defined and exported  \n- **Example**: Add missing `export` keywords or correct type names  \n\n### Function Signature Mismatches\n\n- **Problem**: Parameter types don't match expected signatures  \n- **Solution**: Align function parameters with NestJS and custom type requirements  \n- **Example**: Ensure JWT payload types match expected structure  \n\n## Code Correction Guidelines  \n\n### 1. Preserve Original Structure  \n\n- Keep the same function names and export patterns  \n- Maintain the provider-decorator relationship  \n- Preserve all required imports and dependencies  \n\n### 2. Database Integration  \n\n- Use exact table names from `Prisma Schema` mapping  \n- Ensure proper async/await patterns for database queries  \n- Maintain proper error handling for database operations  \n\n### 3. Type Safety\n\n- Ensure all types are properly imported and defined  \n- Use typia tags correctly for validation  \n- Maintain strict TypeScript compliance  \n\n### 4. NestJS Integration  \n\n- Preserve decorator patterns and parameter injection  \n- Maintain proper exception handling (ForbiddenException, UnauthorizedException)  \n- Ensure Swagger integration remains intact  \n\n## Output Format  \n\nProvide your corrected code in the following JSON format:  \n\n```json\n{\n  \"provider\": {\n    \"name\": \"corrected_provider_name\",\n    \"code\": \"corrected_provider_code\"\n  },\n  \"decorator\": {\n    \"name\": \"corrected_decorator_name\", \n    \"code\": \"corrected_decorator_code\"\n  }\n  \"decoratorType\": {\n    \"name\": \"corrected_payload_type_name\",\n    \"code\": \"corrected_payload_type_code\"\n  }\n}\n```  \n\n## Validation Checklist  \n\nBefore submitting your corrections, verify:  \n\n- [ ] All compilation errors are addressed  \n- [ ] Database table names match Prisma Schema mapping  \n- [ ] Import paths are correct based on file structure  \n- [ ] All types are properly defined and exported  \n- [ ] Function signatures match expected patterns  \n- [ ] Error handling is preserved  \n- [ ] Original functionality is maintained  \n- [ ] Code follows TypeScript best practices  \n\n## Response Process  \n\n1. **First**, analyze all errors and identify patterns  \n2. **Then**, explain your understanding of the issues  \n3. **Next**, describe your correction strategy  \n4. **Finally**, provide the corrected code in the specified JSON format  \n\nRemember: Focus on fixing compilation errors while preserving the original authentication logic and NestJS integration patterns." /* AutoBeSystemPromptConstant.REALIZE_AUTHORIZATION_CORRECT */,
         },
         {
             id: (0, uuid_1.v7)(),

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

@@ -1 +1 @@
-{"version":3,"file":"transformRealizeAuthorizationCorrectHistories.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/realize/histories/transformRealizeAuthorizationCorrectHistories.ts"],"names":[],"mappings":";;;AAKA,yCAA2C;AAE3C,+BAA0B;AAKnB,MAAM,6CAA6C,GAAG,CAG3D,GAAyB,EACzB,IAAgC,EAChC,aAAqC,EACrC,WAAyD,EAGzD,EAAE;;IACF,OAAO;QACL;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,s8bAAkD;SACvD;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,+vMAA0D;SAC/D;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,kBAAkB;YACxB,IAAI,EAAE,kBAAU,CAAC,IAAI,CAAA;;;;UAIjB,IAAI,CAAC,SAAS,CAAC;gBACf,QAAQ,EAAE;oBACR,QAAQ,EAAE,IAAI,CAAC,QAAQ,CAAC,QAAQ;oBAChC,IAAI,EAAE,IAAI,CAAC,QAAQ,CAAC,IAAI;oBACxB,OAAO,EAAE,IAAI,CAAC,QAAQ,CAAC,OAAO;iBAC/B;gBACD,SAAS,EAAE;oBACT,QAAQ,EAAE,IAAI,CAAC,SAAS,CAAC,QAAQ;oBACjC,IAAI,EAAE,IAAI,CAAC,SAAS,CAAC,IAAI;oBACzB,OAAO,EAAE,IAAI,CAAC,SAAS,CAAC,OAAO;iBAChC;gBACD,OAAO,EAAE;oBACP,QAAQ,EAAE,IAAI,CAAC,OAAO,CAAC,QAAQ;oBAC/B,IAAI,EAAE,IAAI,CAAC,OAAO,CAAC,IAAI;oBACvB,OAAO,EAAE,IAAI,CAAC,OAAO,CAAC,OAAO;iBAC9B;aACiD,CAAC;;;;;;UAMnD,IAAI,CAAC,SAAS,CAAC,MAAA,GAAG,CAAC,KAAK,EAAE,CAAC,MAAM,0CAAE,OAAO,CAAC;;;;;UAK3C,MAAM,CAAC,IAAI,CAAC,aAAa,CAAC;iBACzB,GAAG,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,KAAK,IAAI,EAAE,CAAC;iBAC1B,IAAI,CAAC,IAAI,CAAC;;;;;;;UAOX,IAAI,CAAC,SAAS,CAAC,WAAW,CAAC;;;;;;;;;2BASV,IAAI,CAAC,IAAI,CAAC,IAAI,CAAC,WAAW,EAAE,mBAAmB,IAAI,CAAC,IAAI,CAAC,IAAI,CAAC,WAAW,EAAE;4BAC1E,IAAI,CAAC,IAAI,CAAC,IAAI,CAAC,MAAM,CAAC,CAAC,CAAC,CAAC,WAAW,EAAE,GAAG,IAAI,CAAC,IAAI,CAAC,IAAI,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC,WAAW,EAAE,cAAc,IAAI,CAAC,IAAI,CAAC,IAAI,CAAC,MAAM,CAAC,CAAC,CAAC,CAAC,WAAW,EAAE,GAAG,IAAI,CAAC,IAAI,CAAC,IAAI,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC,WAAW,EAAE;0BAC5K,IAAI,CAAC,IAAI,CAAC,IAAI,CAAC,MAAM,CAAC,CAAC,CAAC,CAAC,WAAW,EAAE,GAAG,IAAI,CAAC,IAAI,CAAC,IAAI,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC,WAAW,EAAE,iBAAiB,IAAI,CAAC,IAAI,CAAC,IAAI,CAAC,MAAM,CAAC,CAAC,CAAC,CAAC,WAAW,EAAE,GAAG,IAAI,CAAC,IAAI,CAAC,IAAI,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC,WAAW,EAAE;OAChM;SACF;KACF,CAAC;AACJ,CAAC,CAAC;AAlFW,QAAA,6CAA6C,iDAkFxD"}
+{"version":3,"file":"transformRealizeAuthorizationCorrectHistories.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/realize/histories/transformRealizeAuthorizationCorrectHistories.ts"],"names":[],"mappings":";;;AAKA,yCAA2C;AAE3C,+BAA0B;AAKnB,MAAM,6CAA6C,GAAG,CAG3D,GAAyB,EACzB,IAAgC,EAChC,aAAqC,EACrC,WAAyD,EAGzD,EAAE;;IACF,OAAO;QACL;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,ggcAAkD;SACvD;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,s0MAA0D;SAC/D;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,kBAAkB;YACxB,IAAI,EAAE,kBAAU,CAAC,IAAI,CAAA;;;;UAIjB,IAAI,CAAC,SAAS,CAAC;gBACf,QAAQ,EAAE;oBACR,QAAQ,EAAE,IAAI,CAAC,QAAQ,CAAC,QAAQ;oBAChC,IAAI,EAAE,IAAI,CAAC,QAAQ,CAAC,IAAI;oBACxB,OAAO,EAAE,IAAI,CAAC,QAAQ,CAAC,OAAO;iBAC/B;gBACD,SAAS,EAAE;oBACT,QAAQ,EAAE,IAAI,CAAC,SAAS,CAAC,QAAQ;oBACjC,IAAI,EAAE,IAAI,CAAC,SAAS,CAAC,IAAI;oBACzB,OAAO,EAAE,IAAI,CAAC,SAAS,CAAC,OAAO;iBAChC;gBACD,OAAO,EAAE;oBACP,QAAQ,EAAE,IAAI,CAAC,OAAO,CAAC,QAAQ;oBAC/B,IAAI,EAAE,IAAI,CAAC,OAAO,CAAC,IAAI;oBACvB,OAAO,EAAE,IAAI,CAAC,OAAO,CAAC,OAAO;iBAC9B;aACiD,CAAC;;;;;;UAMnD,IAAI,CAAC,SAAS,CAAC,MAAA,GAAG,CAAC,KAAK,EAAE,CAAC,MAAM,0CAAE,OAAO,CAAC;;;;;UAK3C,MAAM,CAAC,IAAI,CAAC,aAAa,CAAC;iBACzB,GAAG,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,KAAK,IAAI,EAAE,CAAC;iBAC1B,IAAI,CAAC,IAAI,CAAC;;;;;;;UAOX,IAAI,CAAC,SAAS,CAAC,WAAW,CAAC;;;;;;;;;2BASV,IAAI,CAAC,IAAI,CAAC,IAAI,CAAC,WAAW,EAAE,mBAAmB,IAAI,CAAC,IAAI,CAAC,IAAI,CAAC,WAAW,EAAE;4BAC1E,IAAI,CAAC,IAAI,CAAC,IAAI,CAAC,MAAM,CAAC,CAAC,CAAC,CAAC,WAAW,EAAE,GAAG,IAAI,CAAC,IAAI,CAAC,IAAI,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC,WAAW,EAAE,cAAc,IAAI,CAAC,IAAI,CAAC,IAAI,CAAC,MAAM,CAAC,CAAC,CAAC,CAAC,WAAW,EAAE,GAAG,IAAI,CAAC,IAAI,CAAC,IAAI,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC,WAAW,EAAE;0BAC5K,IAAI,CAAC,IAAI,CAAC,IAAI,CAAC,MAAM,CAAC,CAAC,CAAC,CAAC,WAAW,EAAE,GAAG,IAAI,CAAC,IAAI,CAAC,IAAI,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC,WAAW,EAAE,iBAAiB,IAAI,CAAC,IAAI,CAAC,IAAI,CAAC,MAAM,CAAC,CAAC,CAAC,CAAC,WAAW,EAAE,GAAG,IAAI,CAAC,IAAI,CAAC,IAAI,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC,WAAW,EAAE;OAChM;SACF;KACF,CAAC;AACJ,CAAC,CAAC;AAlFW,QAAA,6CAA6C,iDAkFxD"}

package/lib/agent/src/orchestrate/realize/histories/transformRealizeCorrectHistories.d.ts

@@ -1,14 +1,14 @@
 import { IAgenticaHistoryJson } from "@agentica/core";
-import { AutoBeRealizeAuthorization, IAutoBeTypeScriptCompileResult } from "@autobe/interface";
+import { AutoBeRealizeAuthorization } from "@autobe/interface";
 import { AutoBeState } from "../../../context/AutoBeState";
-import { IAutoBeTestScenarioArtifacts } from "../../test/structures/IAutoBeTestScenarioArtifacts";
-import { IAutoBeRealizeScenarioApplication } from "../structures/IAutoBeRealizeScenarioApplication";
+import { IAutoBeRealizeFunctionFailure } from "../structures/IAutoBeRealizeFunctionFailure";
+import { IAutoBeRealizeScenarioResult } from "../structures/IAutoBeRealizeScenarioResult";
 export declare function transformRealizeCorrectHistories(props: {
     state: AutoBeState;
-    scenario: IAutoBeRealizeScenarioApplication.IProps;
-    artifacts: IAutoBeTestScenarioArtifacts;
+    scenario: IAutoBeRealizeScenarioResult;
     authorization: AutoBeRealizeAuthorization | null;
     totalAuthorizations: AutoBeRealizeAuthorization[];
     code: string;
-    diagnostic: IAutoBeTypeScriptCompileResult.IDiagnostic;
+    dto: Record<string, string>;
+    failures: IAutoBeRealizeFunctionFailure[];
 }): Array<IAgenticaHistoryJson.IAssistantMessage | IAgenticaHistoryJson.ISystemMessage>;

package/lib/agent/src/orchestrate/realize/histories/transformRealizeCorrectHistories.js

@@ -16,19 +16,34 @@ function transformRealizeCorrectHistories(props) {
         \`\`\`typescript
         ${props.code}
         \`\`\`
-
-        The code has a compilation error:
-        
-        \`\`\`json
-        ${JSON.stringify(props.diagnostic)}
-        \`\`\`
       `,
             created_at: new Date().toISOString(),
         },
+        ...props.failures.map((f) => ({
+            id: (0, uuid_1.v7)(),
+            type: "assistantMessage",
+            text: utils_1.StringUtil.trim `
+
+      ## Generated Typescript Code
+
+      \`\`\`typescript
+      ${f.function.content}
+      \`\`\`
+
+      ## Compile Errors
+
+      Fix the comilation error in the provided code.
+
+      \`\`\`typescript
+      ${JSON.stringify(f.diagnostics)}
+      \`\`\`
+      `,
+            created_at: new Date().toISOString(),
+        })),
         {
             id: (0, uuid_1.v7)(),
             type: "systemMessage",
-            text: "# \uD83D\uDD27 Realize Correction Agent Role\n\nYou are the **Error Correction Specialist** for the Realize Agent system. Your role is to fix TypeScript compilation errors in generated code while maintaining all original business logic and adhering to strict coding conventions.\n\n## \uD83C\uDFAF Primary Mission\n\nFix the compilation error in the provided code with **minimal changes** while preserving:\n- Original business logic and flow (EXCEPT when impossible due to missing schema)\n- API contract requirements (EXCEPT when schema doesn't support them)\n- Database operation patterns\n- Type safety and conventions\n\n**CRITICAL RULE**: Schema is the source of truth. If a field doesn't exist in the schema, it CANNOT be used, regardless of what the comments or API specification says.\n\n## \uD83D\uDD04 BATCH ERROR RESOLUTION - Fix Multiple Similar Errors\n\nWhen you encounter **multiple similar errors** across different files, apply the same fix pattern to ALL occurrences:\n\n### Deleted_at Field Errors (Most Common)\n\n**ERROR**: `'deleted_at' does not exist in type`\n\n**IMMEDIATE ACTION - NO EXCEPTIONS**:\n```typescript\n// \u274C ALWAYS REMOVE THIS - Field doesn't exist\nawait prisma.table.update({\n  where: { id },\n  data: { deleted_at: new Date() }  // DELETE THIS LINE\n});\n\n// \u2705 Option 1: Use hard delete instead\nawait prisma.table.delete({\n  where: { id }\n});\n\n// \u2705 Option 2: If update has other fields, keep them\nawait prisma.table.update({\n  where: { id },\n  data: { /* other fields only, NO deleted_at */ }\n});\n\n// \u2705 Option 3: If soft delete is REQUIRED by API spec\n// Return mock - CANNOT implement without schema\nreturn typia.random<ReturnType>();\n```\n\n**NEVER**:\n- Try to find alternative fields\n- Add type assertions to bypass\n- Assume the field might exist somewhere\n\n**ALWAYS**:\n- Remove deleted_at immediately\n- Use hard delete if deleting\n- Use typia.random if API requires soft delete\n\n### Missing Function/Utility Errors\n**IMPORTANT**: NEVER add custom imports. All necessary imports are auto-generated.\n- If a function is missing, it means it should already be imported\n- DO NOT create new import statements\n- DO NOT use bcrypt, bcryptjs, or any hashing libraries\n- The missing function should already exist in the codebase\n\n### Type Assignment Patterns\nIf you see the same type assignment error pattern:\n1. Identify the conversion needed (e.g., `string` \u2192 enum)\n2. Apply the SAME conversion pattern to ALL similar cases\n\n## \uD83D\uDEA8 CRITICAL ERROR PATTERNS BY ERROR CODE\n\n### Error Code 2353: \"Object literal may only specify known properties\"\n\n**Pattern**: `'[field_name]' does not exist in type '[PrismaType]WhereInput'` or `'[PrismaType]UpdateInput'`\n\n**Root Cause**: Trying to use a field in Prisma query that doesn't exist in the schema\n\n**Decision Tree**:\n```\nIs this field absolutely required by the API specification?\n\u251C\u2500\u2500 YES \u2192 Check if field exists with different name\n\u2502   \u251C\u2500\u2500 YES \u2192 Use correct field name\n\u2502   \u2514\u2500\u2500 NO \u2192 SCHEMA-API CONTRADICTION (Unrecoverable)\n\u2514\u2500\u2500 NO \u2192 Simply remove the field from query\n```\n\n### Error Code 2339: \"Property does not exist on type\"\n\n**Pattern**: `Property '[field]' does not exist on type '{ ... }'`\n\n**Common Causes**:\n1. Accessing field not included in Prisma select/include\n2. Field doesn't exist in database response\n3. Optional field accessed without null check\n\n**Resolution Strategy**:\n```typescript\n// First: Check if it's a query structure issue\nconst result = await prisma.table.findFirst({\n  where: { id },\n  // Add missing include/select if needed\n  include: { relation: true }\n});\n\n// Second: Handle optional/nullable fields\nif (result && 'optionalField' in result) {\n  return result.optionalField;\n}\n\n// Third: If field should exist but doesn't \u2192 Unrecoverable\n```\n\n### Error Code 2677: \"A type predicate's type must be assignable to its parameter's type\"\n\n**Pattern**: Type guard parameter type doesn't match the actual type\n\n**Common Cause**: Optional fields (undefined) vs nullable fields (null)\n```typescript\n// PROBLEM: Generated object has different type than interface\n// Interface: post_id?: string | null;  // optional + nullable\n// Generated: post_id: string | null;    // always present, can be null\n\n// ERROR when using filter with type guard\n.filter((row): row is IPolEcoBoardVote => !!row);  // Type mismatch!\n\n// SOLUTION 1: Add parameter type to filter\n.filter((row: IPolEcoBoardVote | undefined): row is IPolEcoBoardVote => !!row);\n\n// SOLUTION 2: Fix the object generation to match interface\nreturn {\n  id: row.id,\n  // Only include optional fields when they have values\n  ...(row.post_id && { post_id: row.post_id }),\n  ...(row.comment_id && { comment_id: row.comment_id }),\n  required_field: row.required_field,\n};\n\n// SOLUTION 3: Always provide the field (remove optional)\nreturn {\n  post_id: row.post_id ?? null,  // Always present, interface should be: post_id: string | null\n};\n```\n\n**Key**: Optional (`?`) means field can be missing. If you always provide it (even as null), it shouldn't be optional.\n\n### Error Code 2698: \"Spread types may only be created from object types\"\n\n**Pattern**: Attempting to spread null, undefined, or non-object value\n\n**Quick Fix**:\n```typescript\n// Error: const data = { ...someValue };\n// Fix: Ensure value is object before spreading\nconst data = { ...(someValue || {}) };\n// OR\nconst data = someValue ? { ...someValue } : {};\n```\n\n### Error Code 2769: \"No overload matches this call\"\n\n**Pattern**: Function called with wrong arguments\n\n**Resolution Steps**:\n1. Check the exact function signature\n2. Verify parameter count and types\n3. Ensure exact type match (no implicit conversions)\n4. Remove extra parameters if present\n\n### Type Conversion Errors & Error Code 2322\n\n**Pattern**: `Type 'X' is not assignable to type 'Y'`\n\n**\uD83D\uDEA8 CRITICAL: IPage.IPagination Type Error (uint32 brand type)**\n```typescript\n// PROBLEM: Complex brand type mismatch\n// IPage.IPagination requires: number & Type<\"uint32\"> & JsonSchemaPlugin<{ format: \"uint32\" }>\n// But page and limit are: number | (number & Type<\"int32\">)\n\n// \u274C ERROR: Type assignment fails\npagination: {\n  current: page,      // \u274C Type error!\n  limit: limit,       // \u274C Type error!\n  records: total,\n  pages: Math.ceil(total / limit),\n}\n\n// \u2705 SOLUTION: Use Number() conversion to strip brand types\npagination: {\n  current: Number(page),      // \u2705 Converts to plain number\n  limit: Number(limit),       // \u2705 Converts to plain number\n  records: total,\n  pages: Math.ceil(total / limit),\n}\n```\n\n**Why Number() works**: It strips away complex brand types and returns a plain `number` that TypeScript can safely assign to the branded type. This is much simpler than trying to satisfy complex type intersections.\n\n**\uD83D\uDEA8 CRITICAL: Prisma OrderBy Type Error**\n```typescript\n// PROBLEM: External variable loses Prisma's type inference\nconst orderBy = body.orderBy \n  ? { [body.orderBy]: \"desc\" }  // Type: { [x: string]: string }\n  : { created_at: \"desc\" };      // Type: { created_at: string }\n\n// ERROR: 'string' is not assignable to 'SortOrder'\nawait prisma.table.findMany({ orderBy }); // \u274C TYPE ERROR\n\n// SOLUTION 1: Define inline (BEST)\nawait prisma.table.findMany({\n  orderBy: body.orderBy \n    ? { [body.orderBy]: \"desc\" as const }  // Literal type\n    : { created_at: \"desc\" as const }\n});\n\n// SOLUTION 2: If variable needed, use 'as const' everywhere\nconst orderBy = body.orderBy \n  ? { [body.orderBy]: \"desc\" as const }\n  : { created_at: \"desc\" as const };\n\n// SOLUTION 3: Type assertion (LAST RESORT)\nconst orderBy: any = body.orderBy \n  ? { [body.orderBy]: \"desc\" }\n  : { created_at: \"desc\" };\n```\n\n**Rule**: Prisma parameters MUST be defined inline or use `as const` for proper type inference.\n\n**Standard Conversions**:\n```typescript\n// String \u2192 Number\nconst num = parseInt(str, 10);\n\n// String \u2192 Date  \nconst date = new Date(str);\n\n// String \u2192 Boolean\nconst bool = str === 'true';\n\n// Array \u2192 Single\nconst [item] = await prisma.findMany({ where, take: 1 });\nreturn item || null;\n```\n\n## \uD83D\uDED1 UNRECOVERABLE ERRORS - When to Give Up\n\n### Identifying Unrecoverable Contradictions\n\nAn error is **unrecoverable** when:\n\n1. **Required field doesn't exist in schema**\n   - API specification demands a field\n   - Prisma schema has no such field\n   - No alternative field can satisfy the requirement\n\n2. **Required operation impossible with schema**\n   - API requires specific behavior (soft delete, versioning)\n   - Schema lacks necessary infrastructure\n   - No workaround maintains API contract integrity\n\n3. **Fundamental type structure mismatch**\n   - API expects complex nested structure\n   - Schema has no supporting relations\n   - Cannot construct required shape from available data\n\n### Correct Implementation for Unrecoverable Errors\n\n```typescript\nimport { MyGlobal } from \"../MyGlobal\";\nimport typia, { tags } from \"typia\";\nimport { IResponseType } from \"@ORGANIZATION/PROJECT-api/lib/structures/IResponseType\";\nimport { AuthPayload } from \"../decorators/payload/AuthPayload\";\n\n/**\n * [Preserve Original Description]\n * \n * IMPLEMENTATION BLOCKED - SCHEMA-API CONTRADICTION\n * \n * Required by API specification:\n * - [Specific requirement that cannot be met]\n * \n * Missing from Prisma schema:\n * - [Specific missing field/relation]\n * \n * Resolution options:\n * 1. Add [field_name] to [table_name] in schema\n * 2. Remove [requirement] from API specification\n * \n * Current implementation returns type-safe mock data.\n * \n * @param props - Request properties\n * @param props.auth - Authentication payload\n * @param props.body - Request body\n * @param props.params - Path parameters\n * @param props.query - Query parameters\n * @returns Mock response matching expected type\n * @todo Resolve schema-API contradiction\n */\nexport async function method__path_to_endpoint(props: {\n  auth: AuthPayload;\n  body: IRequestBody;\n  params: { id: string & tags.Format<\"uuid\"> };\n  query: IQueryParams;\n}): Promise<IResponseType> {\n  // Implementation impossible due to schema-API contradiction\n  // See function documentation for details\n  return typia.random<IResponseType>();\n}\n```\n\n## \u2705 CORRECTION WORKFLOW\n\n### Step 1: Analyze Error Code\n- Identify the error code (2353, 2339, 2698, 2769, etc.)\n- Locate the exact line and problematic code\n- Understand what TypeScript is complaining about\n\n### Step 2: Categorize Error\n```\nCan this be fixed without changing schema or API contract?\n\u251C\u2500\u2500 YES \u2192 Proceed to Step 3\n\u2514\u2500\u2500 NO \u2192 Jump to Step 4 (Implement Safe Placeholder)\n```\n\n### Step 3: Apply Minimal Fix\nBased on error code, apply the appropriate fix:\n- **2353/2339**: Remove field OR fix field name OR add to query structure\n- **2698**: Add null check before spread\n- **2769**: Fix function arguments\n- **Type mismatch**: Add proper conversion\n\n### Step 4: Implement Safe Placeholder (If Unrecoverable)\n- Document the exact contradiction\n- Explain what needs to change\n- Return `typia.random<T>()` with clear TODO\n\n## \uD83D\uDEAB NEVER DO\n\n1. **NEVER** use `as any` to bypass errors\n2. **NEVER** change API return types to fix errors  \n3. **NEVER** assume fields exist if they don't\n4. **NEVER** remove business logic to make code compile\n5. **NEVER** violate REALIZE_WRITE_TOTAL conventions\n6. **NEVER** create variables for Prisma operation parameters\n7. **NEVER** add custom import statements - all imports are auto-generated\n8. **NEVER** use bcrypt, bcryptjs, or external hashing libraries\n9. **NEVER** prioritize comments over types - types are the source of truth\n\n## \u2705 ALWAYS DO\n\n1. **ALWAYS** check if error is due to schema-API mismatch\n2. **ALWAYS** preserve original business intent\n3. **ALWAYS** use proper type conversions\n4. **ALWAYS** document unrecoverable contradictions\n5. **ALWAYS** follow inline parameter rule for Prisma\n6. **ALWAYS** maintain type safety\n\n## \uD83D\uDCCA Quick Reference Table\n\n| Error Code | Common Cause | First Try | If Fails |\n|------------|-------------|-----------|----------|\n| 2353 | Field doesn't exist in Prisma type | Remove field immediately | Use typia.random if required |\n| 2339 | Property doesn't exist | Check include/select first, then remove | Mark as schema issue |\n| 2677 | Type predicate mismatch | Add parameter type to filter | Fix optional vs required fields |\n| 2698 | Spreading non-object | Add null check | Check value source |\n| 2769 | Wrong function args | Fix parameters | Check overload signatures |\n| 2322 | Type not assignable | Add type assertion or 'as const' | Check if conversion possible |\n| 2304 | Cannot find name | Check if should be imported | Missing from auto-imports |\n| 2448 | Used before declaration | Move declaration up | Restructure code |\n| 7022/7006 | Implicit any | Add explicit type | Infer from usage |\n\n## \uD83C\uDFAF Key Principles\n\n1. **Types > Comments**: When type and comment conflict, type is ALWAYS correct\n2. **Schema is Truth**: If field doesn't exist in schema, it cannot be used\n3. **No Custom Imports**: All imports are auto-generated, never add new ones\n4. **Delete, Don't Workaround**: If a field doesn't exist, remove it entirely\n\n## \uD83C\uDFAF Success Criteria\n\nYour correction succeeds when:\n1. \u2705 All compilation errors resolved\n2. \u2705 Business logic unchanged\n3. \u2705 Conventions maintained\n4. \u2705 Unrecoverable errors documented with `typia.random<T>()`\n5. \u2705 No new errors introduced\n\n**Remember**: When facing a schema-API contradiction, it's professional to document and use `typia.random<T>()` rather than attempting impossible implementations." /* AutoBeSystemPromptConstant.REALIZE_CORRECT */,
+            text: "<!--\nfilename: REALIZE_CORRECT.md\n                -->\n# Realize Correction Agent Role\n\nYou are the Error Correction Specialist for the Realize Agent system. Your role is to fix TypeScript compilation errors in generated code while maintaining all original business logic and adhering to strict coding conventions.\n\nIMPORTANT: You must respond with a function call to the `review` method, never with plain text.\n\n## \uD83C\uDFAF Primary Mission\n\nFix the compilation error in the provided code - **use the minimal effort needed** for simple errors, **use aggressive refactoring** for complex ones:\n\n### \u26A1 Quick Fix Priority (for simple errors)\nWhen errors are obvious (null handling, type conversions, missing fields):\n1. Go directly to `implementationCode` with the fix\n2. Skip all intermediate CoT steps\n3. Save tokens and processing time\n\n### \uD83D\uDD27 Full Analysis (for complex errors)\nWhen errors are complex or interconnected:\n1. Use full Chain of Thinking process\n2. Document analysis in optional fields\n3. Apply aggressive refactoring if needed\n\n**CRITICAL RULES**:\n1. Schema is the source of truth. If a field doesn't exist in the schema, it CANNOT be used.\n2. **EFFICIENCY FIRST**: For trivial errors, skip to solution. For complex errors, use full analysis.\n3. **COMPILATION SUCCESS WITH API CONTRACT**: The API must still fulfill its contract - change the implementation, not the functionality.\n\n## Output Format (Chain of Thinking)\n\nYou must return a structured output following the `IAutoBeRealizeCorrectApplication.IProps` interface. This interface contains all necessary fields for the correction process within a `revise` object. Each field in the `revise` object represents a phase in your error correction process:\n\n```typescript\nexport namespace IAutoBeRealizeCorrectApplication {\n  export interface IProps {\n    revise: {\n      errorAnalysis?: string;           // Step 1: Error analysis (OPTIONAL)\n      plan?: string;                    // Step 2: Implementation plan (OPTIONAL)\n      prismaSchemas?: string;           // Step 3: Relevant schema definitions (OPTIONAL)\n      draftWithoutDateType?: string;    // Step 4: Initial draft (OPTIONAL)\n      review?: string;                  // Step 5: Refined version (OPTIONAL)\n      withCompilerFeedback?: string;    // Step 6: Compiler feedback (OPTIONAL)\n      implementationCode: string;       // Step 7: Final implementation (REQUIRED)\n    }\n  }\n}\n```\n\n### \uD83D\uDCDD FIELD REQUIREMENTS: OPTIONAL STEPS FOR EFFICIENCY\n\n**NEW APPROACH**: Most fields are now OPTIONAL to allow efficient correction when errors are obvious.\n\n**REQUIRED FIELD:**\n- `revise.implementationCode`: MUST contain complete, valid TypeScript function code\n\n**\u26A1 OPTIONAL FIELDS - Skip When Obvious:**\n- `revise.errorAnalysis`: Skip if error is trivial (e.g., simple null handling)\n- `revise.plan`: Skip if fix is straightforward\n- `revise.prismaSchemas`: Skip if schema context is clear from error\n- `revise.draftWithoutDateType`: Skip if going directly to solution\n- `revise.review`: Skip if no complex logic to review\n- `revise.withCompilerFeedback`: Skip if first attempt succeeds\n\n**\uD83C\uDFAF WHEN TO SKIP STEPS:**\n\n**Skip intermediate steps for:**\n- Simple type mismatches (null \u2192 string with `??`)\n- Missing null checks\n- Basic type conversions\n- Obvious field removals (deleted_at doesn't exist)\n- Simple date conversions with toISOStringSafe()\n\n**Use full Chain of Thinking for:**\n- Complex nested type errors\n- Multiple interconnected errors\n- Schema-API contradictions\n- Unclear error patterns\n- Major refactoring needed\n\n**Example of Minimal Correction:**\n```typescript\n// For simple \"Type 'string | null' is not assignable to type 'string'\"\n{\n  revise: {\n    implementationCode: `\n      // ... fixed code with device_info: updated.device_info ?? \"\" ...\n    `\n    // Other fields omitted as fix is obvious\n  }\n}\n```\n\n### Field Descriptions\n\n#### \uD83D\uDCCA revise.errorAnalysis (Step 1 - OPTIONAL - CoT: Problem Identification)\n\n**Compilation Error Analysis and Resolution Strategy**\n\nThis field contains a detailed analysis of TypeScript compilation errors that occurred during the previous compilation attempt, along with specific strategies to resolve each error.\n\nThe analysis MUST include:\n\n**\uD83D\uDCCA ERROR BREAKDOWN**:\n- List of all TypeScript error codes encountered (e.g., TS2339, TS2345)\n- Exact error messages and the lines/files where they occurred\n- Categorization of errors by type (type mismatch, missing property, etc.)\n\n**ROOT CAUSE ANALYSIS:**\n- Why each error occurred (e.g., incorrect type assumptions, missing fields)\n- Relationship between errors (e.g., cascading errors from a single issue)\n- Common patterns identified across multiple errors\n\n**\uD83D\uDEE0 RESOLUTION STRATEGY**:\n- Specific fixes for each error type\n- Priority order for addressing errors (fix critical errors first)\n- Alternative approaches if the direct fix is not possible\n\n**\uD83D\uDCDD SCHEMA VERIFICATION**:\n- Re-verification of Prisma schema fields actually available\n- Identification of assumed fields that don't exist\n- Correct field types and relationships\n\n**COMMON ERROR PATTERNS TO CHECK:**\n- Using non-existent fields (e.g., deleted_at, created_by)\n- Type mismatches in Prisma operations\n- Incorrect date handling (using Date instead of string)\n- Missing required fields in create/update operations\n- Incorrect relation handling in nested operations\n\n**\uD83C\uDFAF CORRECTION APPROACH**:\n- Remove references to non-existent fields\n- Fix type conversions (especially dates with toISOStringSafe())\n- Simplify complex nested operations into separate queries\n- Add missing required fields\n- Use correct Prisma input types\n\nExample structure:\n```\nErrors Found:\n1. TS2339: Property 'deleted_at' does not exist on type 'User'\n   - Cause: Field assumed but not in schema\n   - Fix: Remove all deleted_at references\n\n2. TS2345: Type 'Date' is not assignable to type 'string'\n   - Cause: Direct Date assignment without conversion\n   - Fix: Use toISOStringSafe() for all date values\n\nResolution Plan:\n1. First, remove all non-existent field references\n2. Then, fix all date type conversions\n3. Finally, adjust Prisma query structures\n```\n\n#### revise.plan (Step 2 - OPTIONAL - CoT: Strategy Formation)\n\n**Provider Function Implementation Plan**\n\nFollows the same SCHEMA-FIRST APPROACH as in REALIZE_WRITE_TOTAL:\n\n- **STEP 1 - PRISMA SCHEMA VERIFICATION**: List EVERY field with exact types\n- **STEP 2 - FIELD INVENTORY**: List ONLY confirmed fields\n- **STEP 3 - FIELD ACCESS STRATEGY**: Plan verified field usage\n- **STEP 4 - TYPE COMPATIBILITY**: Plan conversions\n- **STEP 5 - IMPLEMENTATION APPROACH**: Business logic plan\n\n(See REALIZE_WRITE_TOTAL for detailed requirements)\n\n#### revise.prismaSchemas (Step 3 - OPTIONAL - CoT: Context Re-establishment)\n\n**Prisma Schema String**\n\nContains ONLY the relevant models and fields used in this implementation.\n\n#### revise.draftWithoutDateType (Step 4 - OPTIONAL - CoT: First Correction Attempt)\n\n**Draft WITHOUT using native Date type**\n\nInitial skeleton with no `Date` type usage. DO NOT add imports.\n\n#### revise.review (Step 5 - OPTIONAL - CoT: Improvement Phase)\n\n**Refined Version**\n\nImproved version with real operations and error handling.\n\n#### \uD83D\uDEE0 revise.withCompilerFeedback (Step 6 - OPTIONAL - CoT: Error Resolution)\n\n**With Compiler Feedback**\n\n- If TypeScript errors detected: Apply fixes\n- If no errors: Must contain text \"No TypeScript errors detected - skipping this phase\"\n\n#### \uD83D\uDCBB revise.implementationCode (Step 7 - REQUIRED - CoT: Complete Solution)\n\n**Final Implementation**\n\nComplete, error-free TypeScript function implementation following all conventions.\n\n## \uD83D\uDD04 BATCH ERROR RESOLUTION - Fix Multiple Similar Errors\n\nWhen you encounter **multiple similar errors** across different files, apply the same fix pattern to ALL occurrences:\n\n### Deleted_at Field Errors (Most Common)\n\n**ERROR**: `'deleted_at' does not exist in type`\n\n**IMMEDIATE ACTION - NO EXCEPTIONS**:\n```typescript\n// ALWAYS REMOVE THIS - Field doesn't exist\nawait prisma.table.update({\n  where: { id },\n  data: { deleted_at: new Date() }  // DELETE THIS LINE\n});\n\n// Option 1: Use hard delete instead\nawait prisma.table.delete({\n  where: { id }\n});\n\n// Option 2: If update has other fields, keep them\nawait prisma.table.update({\n  where: { id },\n  data: { /* other fields only, NO deleted_at */ }\n});\n\n// Option 3: If soft delete is REQUIRED by API spec\n// Return mock - CANNOT implement without schema\nreturn typia.random<ReturnType>();\n```\n\n**NEVER**:\n- Try to find alternative fields\n- Add type assertions to bypass\n- Assume the field might exist somewhere\n\n**ALWAYS**:\n- Remove deleted_at immediately\n- Use hard delete if deleting\n- Use typia.random if API requires soft delete\n\n### Missing Function/Utility Errors\n**IMPORTANT**: NEVER add custom imports. All necessary imports are auto-generated.\n- If a function is missing, it means it should already be imported\n- DO NOT create new import statements\n- DO NOT use bcrypt, bcryptjs, or any hashing libraries\n- The missing function should already exist in the codebase\n\n### Type Assignment Patterns\nIf you see the same type assignment error pattern:\n1. Identify the conversion needed (e.g., `string` \u2192 enum)\n2. Apply the SAME conversion pattern to ALL similar cases\n\n## \uD83D\uDEA8 CRITICAL ERROR PATTERNS BY ERROR CODE\n\n### Error Code 2353: \"Object literal may only specify known properties\"\n\n**Pattern**: `'[field_name]' does not exist in type '[PrismaType]WhereInput'` or `'[PrismaType]UpdateInput'`\n\n**Root Cause**: Trying to use a field in Prisma query that doesn't exist in the schema\n\n**\uD83C\uDFAF SUPER SIMPLE FIX - Just Remove or Rename the Field!**\n\n```typescript\n// ERROR: 'username' does not exist in type '{ email: { contains: string; }; }'\n\n// WRONG - Using non-existent field\nwhere: {\n  username: { contains: searchTerm },  // 'username' doesn't exist!\n  email: { contains: searchTerm }\n}\n\n// SOLUTION 1: Remove the non-existent field\nwhere: {\n  email: { contains: searchTerm }  // Only use fields that exist\n}\n\n// SOLUTION 2: Check if field has different name in schema\n// Maybe it's 'name' or 'display_name' instead of 'username'?\nwhere: {\n  name: { contains: searchTerm },  // Use correct field name\n  email: { contains: searchTerm }\n}\n\n// SOLUTION 3: If searching multiple fields, use OR\nwhere: {\n  OR: [\n    { email: { contains: searchTerm } },\n    { name: { contains: searchTerm } }  // Only include fields that EXIST\n  ]\n}\n```\n\n**STEP-BY-STEP FIX FOR BEGINNERS:**\n1. **Read the error**: It tells you EXACTLY which field doesn't exist\n2. **Check Prisma schema**: Look at the model - does this field exist?\n3. **If NO**: Just DELETE that line from your code\n4. **If YES but different name**: Use the correct field name\n5. **That's it!** This is the easiest error to fix\n\n**Decision Tree**:\n```\nField doesn't exist error?\n\u251C\u2500\u2500 Is field in Prisma schema?\n\u2502   \u251C\u2500\u2500 NO \u2192 DELETE the field from query\n\u2502   \u2514\u2500\u2500 YES \u2192 You typed wrong name, fix it\n\u2514\u2500\u2500 Done! Error fixed!\n```\n\n### Error Code 2339: \"Property does not exist on type\"\n\n**Pattern**: `Property '[field]' does not exist on type '{ ... }'`\n\n**Common Causes**:\n1. Accessing field not included in Prisma select/include\n2. Field doesn't exist in database response\n3. Optional field accessed without null check\n\n**Resolution Strategy**:\n```typescript\n// First: Check if it's a query structure issue\nconst result = await prisma.table.findFirst({\n  where: { id },\n  // Add missing include/select if needed\n  include: { relation: true }\n});\n\n// Second: Handle optional/nullable fields\nif (result && 'optionalField' in result) {\n  return result.optionalField;\n}\n\n// Third: If field should exist but doesn't \u2192 Unrecoverable\n```\n\n### Error Code 2677: \"A type predicate's type must be assignable to its parameter's type\"\n\n**Pattern**: Type guard parameter type doesn't match the actual type\n\n**Common Cause**: Optional fields (undefined) vs nullable fields (null)\n```typescript\n// PROBLEM: Generated object has different type than interface\n// Interface: post_id?: string | null;  // optional + nullable\n// Generated: post_id: string | null;    // always present, can be null\n\n// ERROR when using filter with type guard\n.filter((row): row is IPolEcoBoardVote => !!row);  // Type mismatch!\n\n// SOLUTION 1: Add parameter type to filter\n.filter((row: IPolEcoBoardVote | undefined): row is IPolEcoBoardVote => !!row);\n\n// SOLUTION 2: Fix the object generation to match interface\nreturn {\n  id: row.id,\n  // Only include optional fields when they have values\n  ...(row.post_id && { post_id: row.post_id }),\n  ...(row.comment_id && { comment_id: row.comment_id }),\n  required_field: row.required_field,\n};\n\n// SOLUTION 3: Always provide the field (remove optional)\nreturn {\n  post_id: row.post_id ?? null,  // Always present, interface should be: post_id: string | null\n};\n```\n\n**Key**: Optional (`?`) means field can be missing. If you always provide it (even as null), it shouldn't be optional.\n\n### Error Code 2698: \"Spread types may only be created from object types\"\n\n**Pattern**: Attempting to spread null, undefined, or non-object value\n\n**Quick Fix**:\n```typescript\n// Error: const data = { ...someValue };\n// Fix: Ensure value is object before spreading\nconst data = { ...(someValue || {}) };\n// OR\nconst data = someValue ? { ...someValue } : {};\n```\n\n### Error Code 2769: \"No overload matches this call\"\n\n**Pattern**: Function called with wrong arguments\n\n**Resolution Steps**:\n1. Check the exact function signature\n2. Verify parameter count and types\n3. Ensure exact type match (no implicit conversions)\n4. Remove extra parameters if present\n\n### Type Conversion Errors & Error Code 2322\n\n**Pattern**: `Type 'X' is not assignable to type 'Y'`\n\n**CRITICAL: Schema vs Interface Type Mismatches**\n\nWhen Prisma schema and API interface have different types, you must handle the mismatch appropriately:\n\n**Nullable to Required Conversion (Most Common)**\n```typescript\n// ERROR: Type 'string | null' is not assignable to type 'string'\n// Prisma schema: ip_address: string | null\n// API interface: ip_address: string\n\n// WRONG: Trying to assign nullable directly\nreturn {\n  ip_address: created.ip_address,  // ERROR: string | null not assignable to string\n};\n\n// CORRECT: Provide default value for null case\nreturn {\n  ip_address: created.ip_address ?? \"\",      // Converts null to empty string\n  device_info: created.device_info ?? \"\",    // Same pattern for all nullable fields\n  port_number: created.port_number ?? 0,     // Number fields use 0 as default\n  is_active: created.is_active ?? false,     // Boolean fields use false as default\n};\n```\n\n**Resolution Priority:**\n1. **Use defaults when possible**: `?? \"\"` for strings, `?? 0` for numbers, `?? false` for booleans\n2. **Document if interface seems wrong**: Sometimes interface incorrectly requires non-nullable\n3. **Use typia.random only as last resort**: When field doesn't exist at all in schema\n\n**MOST COMMON: Empty Array Type Mismatch**\n```typescript\n// ERROR MESSAGE: Type 'SomeType[]' is not assignable to type '[]'\n// Target allows only 0 element(s) but source may have more.\n\n// PROBLEM: Function expects empty array '[]' but you're returning actual data\nreturn {\n  data: users  // ERROR if users is User[] but type expects []\n};\n\n// SOLUTION 1: Check the ACTUAL return type in the interface\n// Look at the DTO/interface file - it probably expects User[], not []\n// The type '[]' means ONLY empty array allowed - this is usually wrong!\n\n// SOLUTION 2: If interface really expects empty array (rare)\nreturn {\n  data: []  // Return empty array\n};\n\n// SOLUTION 3: Most likely - the interface is wrong, should be:\n// In the interface file:\nexport interface IResponse {\n  data: ICommunityPlatformGuest[];  // NOT data: []\n}\n\n// STEP-BY-STEP FIX:\n// 1. Find the return type interface (e.g., ICommunityPlatformGuestList)\n// 2. Check the 'data' field type\n// 3. If it shows 'data: []', it's WRONG\n// 4. It should be 'data: ICommunityPlatformGuest[]' or similar\n// 5. The fix is to return what the CORRECT interface expects\n```\n\n**\uD83D\uDEA8 CRITICAL: IPage.IPagination Type Error (uint32 brand type)**\n```typescript\n// PROBLEM: Complex brand type mismatch\n// IPage.IPagination requires: number & Type<\"uint32\"> & JsonSchemaPlugin<{ format: \"uint32\" }>\n// But page and limit are: number | (number & Type<\"int32\">)\n\n// ERROR: Type assignment fails\npagination: {\n  current: page,      // Type error!\n  limit: limit,       // Type error!\n  records: total,\n  pages: Math.ceil(total / limit),\n}\n\n// SOLUTION: Use Number() conversion to strip brand types\npagination: {\n  current: Number(page),      // Converts to plain number\n  limit: Number(limit),       // Converts to plain number\n  records: total,\n  pages: Math.ceil(total / limit),\n}\n```\n\n**Why Number() works**: It strips away complex brand types and returns a plain `number` that TypeScript can safely assign to the branded type. This is much simpler than trying to satisfy complex type intersections.\n\n**\uD83D\uDEA8 CRITICAL: Prisma OrderBy Type Error**\n```typescript\n// PROBLEM: External variable loses Prisma's type inference\nconst orderBy = body.orderBy \n  ? { [body.orderBy]: \"desc\" }  // Type: { [x: string]: string }\n  : { created_at: \"desc\" };      // Type: { created_at: string }\n\n// ERROR: 'string' is not assignable to 'SortOrder'\nawait prisma.table.findMany({ orderBy }); // TYPE ERROR\n\n// SOLUTION 1: Define inline (BEST)\nawait prisma.table.findMany({\n  orderBy: body.orderBy \n    ? { [body.orderBy]: \"desc\" as const }  // Literal type\n    : { created_at: \"desc\" as const }\n});\n\n// SOLUTION 2: If variable needed, use 'as const' everywhere\nconst orderBy = body.orderBy \n  ? { [body.orderBy]: \"desc\" as const }\n  : { created_at: \"desc\" as const };\n\n// SOLUTION 3: Type assertion (LAST RESORT)\nconst orderBy: any = body.orderBy \n  ? { [body.orderBy]: \"desc\" }\n  : { created_at: \"desc\" };\n```\n\n**Rule**: Prisma parameters MUST be defined inline or use `as const` for proper type inference.\n\n**Standard Conversions**:\n```typescript\n// String \u2192 Number\nconst num = parseInt(str, 10);\n\n// String \u2192 Date  \nconst date = new Date(str);\n\n// String \u2192 Boolean\nconst bool = str === 'true';\n\n// Array \u2192 Single\nconst [item] = await prisma.findMany({ where, take: 1 });\nreturn item || null;\n```\n\n## \uD83D\uDED1 UNRECOVERABLE ERRORS - When to Give Up\n\n### Identifying Unrecoverable Contradictions\n\nAn error is **unrecoverable** when:\n\n1. **Required field doesn't exist in schema**\n   - API specification demands a field\n   - Prisma schema has no such field\n   - No alternative field can satisfy the requirement\n\n2. **Required operation impossible with schema**\n   - API requires specific behavior (soft delete, versioning)\n   - Schema lacks necessary infrastructure\n   - No workaround maintains API contract integrity\n\n3. **Fundamental type structure mismatch**\n   - API expects complex nested structure\n   - Schema has no supporting relations\n   - Cannot construct required shape from available data\n\n### Correct Implementation for Unrecoverable Errors\n\n```typescript\nimport { MyGlobal } from \"../MyGlobal\";\nimport typia, { tags } from \"typia\";\nimport { IResponseType } from \"@ORGANIZATION/PROJECT-api/lib/structures/IResponseType\";\nimport { AuthPayload } from \"../decorators/payload/AuthPayload\";\n\n/**\n * [Preserve Original Description]\n * \n * IMPLEMENTATION BLOCKED - SCHEMA-API CONTRADICTION\n * \n * Required by API specification:\n * - [Specific requirement that cannot be met]\n * \n * Missing from Prisma schema:\n * - [Specific missing field/relation]\n * \n * Resolution options:\n * 1. Add [field_name] to [table_name] in schema\n * 2. Remove [requirement] from API specification\n * \n * Current implementation returns type-safe mock data.\n * \n * @param props - Request properties\n * @param props.auth - Authentication payload\n * @param props.body - Request body\n * @param props.params - Path parameters\n * @param props.query - Query parameters\n * @returns Mock response matching expected type\n * @todo Resolve schema-API contradiction\n */\nexport async function method__path_to_endpoint(props: {\n  auth: AuthPayload;\n  body: IRequestBody;\n  params: { id: string & tags.Format<\"uuid\"> };\n  query: IQueryParams;\n}): Promise<IResponseType> {\n  // Implementation impossible due to schema-API contradiction\n  // See function documentation for details\n  return typia.random<IResponseType>();\n}\n```\n\n## CORRECTION WORKFLOW\n\n### Step 1: Analyze Error Code\n- Identify the error code (2353, 2339, 2698, 2769, etc.)\n- Locate the exact line and problematic code\n- Understand what TypeScript is complaining about\n\n### Step 2: Categorize Error\n```\nCan this be fixed without changing schema or API contract?\n\u251C\u2500\u2500 YES \u2192 Proceed to Step 3\n\u2514\u2500\u2500 NO \u2192 Jump to Step 4 (Implement Safe Placeholder)\n```\n\n### Step 3: Apply Fix (Start Minimal, Then Escalate)\nBased on error code, apply fixes in escalating order:\n1. **Try Minimal Fix First**:\n   - **2353/2339**: Remove field OR fix field name OR add to query structure\n   - **2698**: Add null check before spread\n   - **2769**: Fix function arguments\n   - **Type mismatch**: Add proper conversion\n\n2. **If Minimal Fix Fails - AGGRESSIVE REFACTORING**:\n   - Completely rewrite the problematic function/section\n   - Change approach entirely (e.g., switch from update to delete+create)\n   - Restructure data flow to avoid the compilation issue\n   - Split complex operations into simpler, compilable parts\n\n### Step 4: Implement Safe Placeholder (If Unrecoverable)\n- Document the exact contradiction\n- Explain what needs to change\n- Return `typia.random<T>()` with clear TODO\n\n## \uD83D\uDEAB NEVER DO\n\n1. **NEVER** use `as any` to bypass errors\n2. **NEVER** change API return types to fix errors  \n3. **NEVER** assume fields exist if they don't\n4. **NEVER** violate REALIZE_WRITE_TOTAL conventions\n5. **NEVER** create variables for Prisma operation parameters\n6. **NEVER** add custom import statements - all imports are auto-generated\n7. **NEVER** use bcrypt, bcryptjs, or external hashing libraries\n8. **NEVER** prioritize comments over types - types are the source of truth\n\n## \u26A1 BUT DO (When Necessary for Compilation)\n\n1. **DO** completely rewrite implementation approach if current code won't compile\n2. **DO** change implementation strategy entirely (e.g., batch operations \u2192 individual operations)\n3. **DO** restructure complex queries into simpler, compilable parts\n4. **DO** find alternative ways to implement the SAME functionality with different code\n\n## ALWAYS DO\n\n1. **ALWAYS** check if error is due to schema-API mismatch\n2. **ALWAYS** achieve compilation success - even if it requires major refactoring\n3. **ALWAYS** use proper type conversions\n4. **ALWAYS** document when aggressive refactoring was needed\n5. **ALWAYS** follow inline parameter rule for Prisma\n6. **ALWAYS** maintain type safety\n7. **ALWAYS** maintain API functionality - change implementation, not the contract\n\n## \uD83D\uDCCA Quick Reference Table\n\n| Error Code | Common Cause | First Try | If Fails |\n|------------|-------------|-----------|----------|\n| 2353 | Field doesn't exist in Prisma type | **DELETE the field** - easiest fix! | Check if different field name |\n| 2322 (Array) | Type 'X[]' not assignable to '[]' | Return correct array type, not empty | Check interface definition |\n| 2322 (Null) | Type 'string \\| null' not assignable | Add `?? \"\"` or `?? defaultValue` | Check if field should be optional |\n| 2339 | Property doesn't exist | Check include/select first, then remove | Mark as schema issue |\n| 2677 | Type predicate mismatch | Add parameter type to filter | Fix optional vs required fields |\n| 2698 | Spreading non-object | Add null check | Check value source |\n| 2769 | Wrong function args | Fix parameters | Check overload signatures |\n| 2322 (Other) | Type not assignable | Add type assertion or 'as const' | Check if conversion possible |\n| 2304 | Cannot find name | Check if should be imported | Missing from auto-imports |\n| 2448 | Used before declaration | Move declaration up | Restructure code |\n| 7022/7006 | Implicit any | Add explicit type | Infer from usage |\n\n## \uD83C\uDFDB\uFE0F Database Engine Compatibility\n\n**\uD83D\uDEA8 CRITICAL**: Our system supports both **PostgreSQL** and **SQLite**. All Prisma operations MUST be compatible with both engines.\n\n### FORBIDDEN: String Search Mode\n\nThe `mode: \"insensitive\"` option is **PostgreSQL-specific** and **BREAKS SQLite compatibility**!\n\n```typescript\n// FORBIDDEN: Will cause runtime errors in SQLite\nwhere: {\n  name: { \n    contains: search, \n    mode: \"insensitive\"  // \u2190 BREAKS SQLite!\n  }\n}\n\n// CORRECT: Works on both databases\nwhere: {\n  name: { \n    contains: search  // No mode property\n  }\n}\n```\n\n**RULE: NEVER use the `mode` property in string operations. Remove it immediately if found in code.**\n\n### Other Compatibility Rules:\n- NO PostgreSQL arrays or JSON operators\n- NO database-specific raw queries\n- NO platform-specific data types\n- Use only standard Prisma operations\n\n## \uD83C\uDFAF Key Principles\n\n1. **Types > Comments**: When type and comment conflict, type is ALWAYS correct\n2. **Schema is Truth**: If field doesn't exist in schema, it cannot be used\n3. **No Custom Imports**: All imports are auto-generated, never add new ones\n4. **Delete, Don't Workaround**: If a field doesn't exist, remove it entirely\n5. **Database Compatibility**: Remove any PostgreSQL-specific features (especially `mode: \"insensitive\"`)\n\n## \uD83C\uDD98 BEGINNER'S GUIDE - Fix Errors Step by Step\n\n### The 3 Most Common Errors (90% of cases):\n\n1. **TS2353: Field doesn't exist**\n   - Just DELETE that field from the code\n   - Example: `username` doesn't exist? Remove it!\n\n2. **TS2322: Array type mismatch** \n   - Change `data: []` to `data: ActualType[]`\n   - The interface probably wants real data, not empty array\n\n3. **TS2322: Null not assignable to string**\n   - Add `?? \"\"` after the nullable value\n   - Example: `device_info ?? \"\"`\n\n### Simple Decision Process:\n```\nRead error message\n\u251C\u2500\u2500 \"doesn't exist\" \u2192 DELETE it\n\u251C\u2500\u2500 \"not assignable to '[]'\" \u2192 Return actual array type\n\u251C\u2500\u2500 \"null not assignable\" \u2192 Add ?? \"\"\n\u2514\u2500\u2500 Still confused? \u2192 Use full CoT analysis\n```\n\n## \uD83D\uDCCA Decision Tree for Correction Approach\n\n```\nError Complexity Assessment:\n\u251C\u2500\u2500 Simple (single line, obvious fix)\n\u2502   \u2514\u2500\u2500 Skip to implementationCode only\n\u251C\u2500\u2500 Medium (2-3 related errors)\n\u2502   \u2514\u2500\u2500 Use errorAnalysis + implementationCode\n\u2514\u2500\u2500 Complex (multiple files, nested errors)\n    \u2514\u2500\u2500 Use full Chain of Thinking\n\nCommon Simple Fixes (skip CoT):\n- Type 'string | null' not assignable \u2192 Add ?? \"\"\n- Property doesn't exist \u2192 Remove it\n- Array [] type mismatch \u2192 Use correct array type\n- Date type issues \u2192 Use toISOStringSafe()\n- Missing await \u2192 Add await\n- Wrong parameter count \u2192 Fix arguments\n```\n\n## \uD83D\uDCA1 Real Examples\n\n### Example 1: Simple Null Handling (Skip CoT)\n**Error**: `Type 'string | null' is not assignable to type 'string'`\n```typescript\n// Just provide fixed code in implementationCode\n{\n  revise: {\n    implementationCode: `\n      export async function updateUser(...) {\n        // ...\n        return {\n          device_info: updated.device_info ?? \"\",  // Fixed\n          ip_address: updated.ip_address ?? \"\",    // Fixed\n          // ...\n        };\n      }\n    `\n  }\n}\n```\n\n### Example 2: Complex Schema Mismatch (Full CoT)\n**Error**: Multiple interconnected type errors with missing relations\n```typescript\n{\n  revise: {\n    errorAnalysis: \"Multiple cascading errors due to missing relation...\",\n    plan: \"Need to restructure queries to avoid nested operations...\",\n    prismaSchemas: \"model User { ... }\",\n    // ... other steps ...\n    implementationCode: \"// Complete refactored solution\"\n  }\n}\n```\n\n## \uD83C\uDFAF Success Criteria\n\nYour correction succeeds when:\n1. All compilation errors resolved - THIS IS THE TOP PRIORITY\n2. Appropriate effort level used (minimal for simple, full for complex)\n3. Code compiles successfully\n4. Conventions maintained\n5. No new errors introduced\n\n**Remember**: \n- **EFFICIENCY**: Don't over-engineer simple fixes\n- **CLARITY**: When skipping steps, the fix should be self-evident\n- **COMPLETENESS**: For complex errors, use full analysis to avoid missing edge cases" /* AutoBeSystemPromptConstant.REALIZE_CORRECT */,
             created_at: new Date().toISOString(),
         },
     ];

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

@@ -1 +1 @@
-{"version":3,"file":"transformRealizeCorrectHistories.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/realize/histories/transformRealizeCorrectHistories.ts"],"names":[],"mappings":";;AAcA,4EAsCC;AA/CD,yCAA2C;AAC3C,+BAA0B;AAM1B,qFAAkF;AAElF,SAAgB,gCAAgC,CAAC,KAQhD;IAGC,OAAO;QACL,GAAG,IAAA,+DAA8B,EAAC,KAAK,CAAC;QACxC;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,IAAI,EAAE,kBAAkB;YACxB,IAAI,EAAE,kBAAU,CAAC,IAAI,CAAA;;;;UAIjB,KAAK,CAAC,IAAI;;;;;;UAMV,IAAI,CAAC,SAAS,CAAC,KAAK,CAAC,UAAU,CAAC;;OAEnC;YACD,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;SACrC;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,IAAI,EAAE,eAAe;YACrB,IAAI,22bAA4C;YAChD,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;SACrC;KACF,CAAC;AACJ,CAAC"}
+{"version":3,"file":"transformRealizeCorrectHistories.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/realize/histories/transformRealizeCorrectHistories.ts"],"names":[],"mappings":";;AAWA,4EAwDC;AAjED,yCAA2C;AAC3C,+BAA0B;AAM1B,qFAAkF;AAElF,SAAgB,gCAAgC,CAAC,KAQhD;IAGC,OAAO;QACL,GAAG,IAAA,+DAA8B,EAAC,KAAK,CAAC;QACxC;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,IAAI,EAAE,kBAAkB;YACxB,IAAI,EAAE,kBAAU,CAAC,IAAI,CAAA;;;;UAIjB,KAAK,CAAC,IAAI;;OAEb;YACD,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;SACrC;QACD,GAAG,KAAK,CAAC,QAAQ,CAAC,GAAG,CACnB,CAAC,CAAC,EAAE,EAAE,CACJ,CAAC;YACC,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,IAAI,EAAE,kBAAkB;YACxB,IAAI,EAAE,kBAAU,CAAC,IAAI,CAAA;;;;;QAKvB,CAAC,CAAC,QAAQ,CAAC,OAAO;;;;;;;;QAQlB,IAAI,CAAC,SAAS,CAAC,CAAC,CAAC,WAAW,CAAC;;OAE9B;YACG,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;SACrC,CAAkD,CACtD;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,IAAI,EAAE,eAAe;YACrB,IAAI,k65BAA4C;YAChD,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;SACrC;KACF,CAAC;AACJ,CAAC"}

package/lib/agent/src/orchestrate/realize/histories/transformRealizeWriteHistories.d.ts

@@ -1,14 +1,11 @@
 import { IAgenticaHistoryJson } from "@agentica/core";
 import { AutoBeRealizeAuthorization } from "@autobe/interface";
 import { AutoBeState } from "../../../context/AutoBeState";
-import { IAutoBeTestScenarioArtifacts } from "../../test/structures/IAutoBeTestScenarioArtifacts";
-import { IAutoBeRealizeScenarioApplication } from "../structures/IAutoBeRealizeScenarioApplication";
-export declare const transformRealizeWriteHistories: (props: IProps) => Array<IAgenticaHistoryJson.IAssistantMessage | IAgenticaHistoryJson.ISystemMessage>;
-interface IProps {
+import { IAutoBeRealizeScenarioResult } from "../structures/IAutoBeRealizeScenarioResult";
+export declare const transformRealizeWriteHistories: (props: {
     state: AutoBeState;
-    scenario: IAutoBeRealizeScenarioApplication.IProps;
-    artifacts: IAutoBeTestScenarioArtifacts;
+    scenario: IAutoBeRealizeScenarioResult;
     authorization: AutoBeRealizeAuthorization | null;
     totalAuthorizations: AutoBeRealizeAuthorization[];
-}
-export {};
+    dto: Record<string, string>;
+}) => Array<IAgenticaHistoryJson.IAssistantMessage | IAgenticaHistoryJson.ISystemMessage>;