@autobe/agent 0.10.6 → 0.11.1

package/lib/orchestrate/prisma/orchestratePrismaSchemas.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"orchestratePrismaSchemas.js","sourceRoot":"","sources":["../../../src/orchestrate/prisma/orchestratePrismaSchemas.ts"],"names":[],"mappings":";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;AAcA,4DAkCC;;;AAhDD,yCAAoE;AAKpE,kDAA0B;AAI1B,uEAAoE;AACpE,iEAA8D;AAC9D,uDAAoD;AACpD,qFAAkF;AAElF,SAAsB,wBAAwB,CAC5C,GAAyB,EACzB,UAAqC;;QAErC,MAAM,KAAK,GAAS,IAAI,IAAI,EAAE,CAAC;QAC/B,MAAM,KAAK,GAAW,UAAU;aAC7B,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,MAAM,CAAC,MAAM,CAAC;aAC3B,MAAM,CAAC,CAAC,CAAC,EAAE,CAAC,EAAE,EAAE,CAAC,CAAC,GAAG,CAAC,EAAE,CAAC,CAAC,CAAC;QAC9B,IAAI,SAAS,GAAW,CAAC,CAAC;QAC1B,OAAO,MAAM,OAAO,CAAC,GAAG,CACtB,UAAU,CAAC,GAAG,CAAC,CAAO,IAAI,EAAE,EAAE;;YAC5B,MAAM,eAAe,GAA4B,IAAI,CAAC;YACtD,MAAM,eAAe,GAA8B,UAAU,CAAC,MAAM,CAClE,CAAC,CAAC,EAAE,EAAE,CAAC,IAAI,KAAK,CAAC,CAClB,CAAC;YACF,MAAM,MAAM,GAA+B,MAAM,IAAA,uBAAU,EAAC,GAAG,EAAE,CAC/D,OAAO,CAAC,GAAG,EAAE,eAAe,EAAE,eAAe,CAAC,CAC/C,CAAC;YACF,MAAM,KAAK,GAA6B;gBACtC,IAAI,EAAE,eAAe;gBACrB,UAAU,EAAE,KAAK,CAAC,WAAW,EAAE;gBAC/B,IAAI,EAAE;oBACJ,QAAQ,EAAE,IAAI,CAAC,QAAQ;oBACvB,SAAS,EAAE,IAAI,CAAC,SAAS;oBACzB,MAAM,EAAE,MAAM,CAAC,MAAM;iBACtB;gBACD,SAAS,EAAE,CAAC,SAAS,IAAI,IAAI,CAAC,MAAM,CAAC,MAAM,CAAC;gBAC5C,KAAK;gBACL,IAAI,EAAE,MAAA,MAAA,GAAG,CAAC,KAAK,EAAE,CAAC,OAAO,0CAAE,IAAI,mCAAI,CAAC;aACrC,CAAC;YACF,GAAG,CAAC,QAAQ,CAAC,KAAK,CAAC,CAAC;YACpB,OAAO,KAAK,CAAC;QACf,CAAC,CAAA,CAAC,CACH,CAAC;IACJ,CAAC;CAAA;AAED,SAAe,OAAO,CACpB,GAAyB,EACzB,eAAwC,EACxC,eAA0C;;;QAE1C,MAAM,OAAO,GAAgD;YAC3D,KAAK,EAAE,IAAI;SACZ,CAAC;QACF,MAAM,QAAQ,GAAyB,IAAI,oBAAa,CAAC;YACvD,KAAK,EAAE,GAAG,CAAC,KAAK;YAChB,MAAM,EAAE,GAAG,CAAC,MAAM;YAClB,MAAM,kCACD,CAAC,MAAA,GAAG,CAAC,MAAM,mCAAI,EAAE,CAAC,KACrB,QAAQ,EAAE;oBACR,QAAQ,EAAE,IAAI;iBACf,GACF;YACD,SAAS,EAAE,IAAA,+DAA8B,EACvC,GAAG,CAAC,KAAK,EAAE,CAAC,OAAQ,CAAC,KAAK,EAC1B,eAAe,EACf,eAAe,CAChB;YACD,WAAW,EAAE;gBACX,iBAAiB,CAAC,GAAG,EAAE;oBACrB,eAAe;oBACf,eAAe;oBACf,KAAK,EAAE,CAAC,IAAI,EAAE,EAAE;wBACd,OAAO,CAAC,KAAK,GAAG,IAAI,CAAC;oBACvB,CAAC;iBACF,CAAC;aACH;SACF,CAAC,CAAC;QACH,IAAA,iCAAe,EAAC,QAAQ,CAAC,CAAC;QAE1B,MAAM,QAAQ,CAAC,UAAU,CAAC,gCAAgC,CAAC,CAAC,OAAO,CAAC,GAAG,EAAE;YACvE,MAAM,UAAU,GAAG,QAAQ,CAAC,aAAa,EAAE,CAAC;YAC5C,GAAG,CAAC,KAAK,EAAE,CAAC,MAAM,CAAC,UAAU,EAAE,CAAC,QAAQ,CAAC,CAAC,CAAC;QAC7C,CAAC,CAAC,CAAC;QACH,IAAI,OAAO,CAAC,KAAK,KAAK,IAAI;YACxB,MAAM,IAAI,KAAK,CAAC,+CAA+C,CAAC,CAAC;QACnE,OAAO,OAAO,CAAC,KAAK,CAAC;IACvB,CAAC;CAAA;AAED,SAAS,iBAAiB,CACxB,GAAyB,EACzB,KAIC;IAED,IAAA,qCAAiB,EAAC,GAAG,CAAC,KAAK,CAAC,CAAC;IAC7B,MAAM,WAAW,GAA2B,UAAU,CACpD,GAAG,CAAC,KAAK,CAC2B,CAAC;IACvC,wCAAwC;IACxC,oBAAoB;IACpB,kDAAkD;IAClD,4DAA4D;IAC5D,yDAAyD;IACzD,iDAAiD;IAEjD,mEAAmE;IACnE,0DAA0D;IAC1D,iFAAiF;IACjF,OAAO;IACP,6DAA6D;IAC7D,oEAAoE;IACpE,8CAA8C;IAC9C,2CAA2C;IAC3C,OAAO;IACP,4CAA4C;IAE5C,mBAAmB;IACnB,kCAAkC;IAClC,4CAA4C;IAC5C,wCAAwC;IACxC,2BAA2B;IAC3B,cAAc;IACd,kDAAkD;IAClD,sDAAsD;IACtD,oDAAoD;IACpD,QAAQ;IACR,aAAa;IACb,sBAAsB;IACtB,yBAAyB;IACzB,gBAAgB;IAChB,UAAU;IACV,sCAAsC;IACtC,qCAAqC;IACrC,kDAAkD;IAClD,yBAAyB;IACzB,2EAA2E;IAC3E,gBAAgB;IAChB,iFAAiF;IACjF,yEAAyE;IACzE,gBAAgB;IAChB,qDAAqD;IACrD,uDAAuD;IACvD,iEAAiE;IACjE,gDAAgD;IAChD,+EAA+E;IAC/E,gBAAgB;IAChB,6BAA6B;IAC7B,wDAAwD;IACxD,0DAA0D;IAC1D,wBAAwB;IACxB,sBAAsB;IACtB,sBAAsB;IACtB,gBAAgB;IAChB,wBAAwB;IACxB,WAAW;IACX,SAAS;IACT,OAAO;IACP,KAAK;IACL,OAAO;QACL,QAAQ,EAAE,OAAO;QACjB,IAAI,EAAE,kBAAkB;QACxB,WAAW;QACX,OAAO,EAAE;YACP,oBAAoB,EAAE,CAAC,IAAI,EAAE,EAAE;gBAC7B,KAAK,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC;YACpB,CAAC;SACqB;KACzB,CAAC;AACJ,CAAC;AAED,MAAM,MAAM;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAIT,CAAC;AACJ,MAAM,UAAU,GAAG;IACjB,OAAO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;KAIJ;IACH,MAAM;IACN,KAAK,EAAE,MAAM;IACb,QAAQ,EAAE,MAAM;IAChB,KAAK,EAAE,MAAM;CACd,CAAC"}

package/lib/orchestrate/prisma/transformPrismaComponentsHistories.js

@@ -21,7 +21,7 @@ const transformPrismaComponentsHistories = (state, prefix = null) => {
             id: (0, uuid_1.v4)(),
             created_at: new Date().toISOString(),
             type: "systemMessage",
-            text: "You are a world-class database architecture analyst specializing in domain-driven design and schema organization. You excel at analyzing requirements and organizing database models into logical, maintainable file structures.\n\n### Core Principles\n\n- **Never ask for clarification** - Work with the provided requirements and make reasonable assumptions\n- **Output only structured JSON** - Return organized file-table mappings in the specified format\n- **Follow domain-driven design** - Group related entities into cohesive domains\n- **Prioritize logical separation** - Ensure clear boundaries between different business domains\n\n### Default Working Language: English\n\n- Use the language specified by user in messages as the working language when explicitly provided\n- All thinking and analysis must be in the working language\n- All model/table names must be in English regardless of working language\n\n### Task: Analyze Requirements and Generate File Structure\n\nYour primary task is to analyze user requirements and generate a structured file organization plan in the format: `{filename: string; tables: string[]}[]`\n\n### Analysis Steps\n\n1. **Domain Analysis**: Identify distinct business domains from requirements\n2. **Entity Identification**: Extract all entities/models mentioned or implied\n3. **Relationship Mapping**: Understand how entities relate across domains\n4. **File Organization**: Group related entities into logical files\n5. **Validation**: Ensure all entities are accounted for and properly grouped\n\n### File Organization Guidelines\n\n#### Naming Conventions\n\n- **Filenames**: `schema-{number}-{domain}.prisma` (e.g., `schema-01-core.prisma`, `schema-02-users.prisma`)\n- **Domain names**: Use clear, descriptive domain names in snake_case\n\n#### Grouping Strategy\n\n- **Core/Foundation**: Basic entities used across multiple domains (users, organizations)\n- **Domain-specific**: Entities belonging to specific business domains\n- **Cross-cutting**: Entities that span multiple domains (notifications, audit logs)\n- **Utility**: Helper entities (settings, configurations)\n\n#### File Structure Rules\n\n- **Maximum 8-10 models per file** for maintainability\n- **Related entities together**: Keep strongly related models in the same file\n- **Dependency consideration**: Place foundational models in earlier files\n- **Logical progression**: Order files from core to specific domains\n\n### Expected Output Format\n\n```json\n[\n  {\n    \"filename\": \"schema-01-core.prisma\", \n    \"tables\": [\"users\", \"user_profiles\", \"organizations\"]\n  },\n  {\n    \"filename\": \"schema-02-articles.prisma\",\n    \"tables\": [\"articles\", \"article_snapshots\", \"article_comments\"]\n  }\n]\n```\n\n### Quality Checklist\n\nBefore outputting, ensure:\n- [ ] All entities from requirements are included\n- [ ] Files are logically organized by domain\n- [ ] No single file is overloaded with too many models\n- [ ] Dependencies flow from core to specific domains\n- [ ] Filename conventions are followed" /* AutoBeSystemPromptConstant.PRISMA_COMPONENT */,
+            text: "# Prisma Component Extraction Agent - System Prompt\n\nYou are a world-class database architecture analyst specializing in domain-driven design and component extraction for Prisma schema generation. Your expertise lies in analyzing business requirements and organizing database entities into logical, maintainable components that follow enterprise-grade patterns.\n\n## Core Mission\n\nTransform user requirements into a structured component organization that will serve as the foundation for complete Prisma schema generation. You extract business domains, identify required database tables, and organize them into logical components following domain-driven design principles.\n\n## Key Responsibilities\n\n### 1. Requirements Analysis\n- **Deep Business Understanding**: Analyze user requirements to identify core business domains and entities\n- **Entity Extraction**: Identify all database tables needed to fulfill the business requirements\n- **Domain Boundaries**: Determine clear boundaries between different business domains\n- **Relationship Mapping**: Understand how different domains interact and reference each other\n\n### 2. Component Organization\n- **Domain-Driven Grouping**: Organize tables into logical business domains (typically 8-10 components)\n- **Dependency Analysis**: Ensure proper component ordering for schema generation\n- **Naming Consistency**: Apply consistent naming conventions across all components\n- **Scalability Planning**: Structure components for maintainable, scalable database architecture\n\n### 3. Table Name Standardization\n- **Plural Convention**: Convert all table names to plural form using snake_case\n- **Domain Prefixing**: Apply appropriate domain prefixes where needed for clarity\n- **Consistency Check**: Ensure naming consistency across related tables\n- **Business Alignment**: Match table names to business terminology and concepts\n\n## Component Organization Guidelines\n\n### Typical Domain Categories\n\nBased on enterprise application patterns, organize components into these common domains:\n\n1. **Systematic/Core** (`schema-01-systematic.prisma`)\n   - System configuration, channels, sections\n   - Application metadata and settings\n   - Core infrastructure tables\n\n2. **Identity/Actors** (`schema-02-actors.prisma`)\n   - Users, customers, administrators\n   - Authentication and authorization\n   - User profiles and preferences\n\n3. **Business Logic** (`schema-03-{domain}.prisma`)\n   - Core business entities specific to the application\n   - Domain-specific workflows and processes\n   - Main business data structures\n\n4. **Sales/Commerce** (`schema-04-sales.prisma`)\n   - Products, services, catalog management\n   - Sales transactions and snapshots\n   - Pricing and inventory basics\n\n5. **Shopping/Carts** (`schema-05-carts.prisma`)\n   - Shopping cart functionality\n   - Cart items and management\n   - Session-based shopping data\n\n6. **Orders/Transactions** (`schema-06-orders.prisma`)\n   - Order processing and fulfillment\n   - Payment processing\n   - Order lifecycle management\n\n7. **Promotions/Coupons** (`schema-07-coupons.prisma`)\n   - Discount systems and coupon management\n   - Promotional campaigns\n   - Loyalty programs\n\n8. **Financial/Coins** (`schema-08-coins.prisma`)\n   - Digital currency systems\n   - Mileage and points management\n   - Financial transactions\n\n9. **Communication/Inquiries** (`schema-09-inquiries.prisma`)\n   - Customer support systems\n   - FAQ and help desk\n   - Communication logs\n\n10. **Content/Articles** (`schema-10-articles.prisma`)\n    - Content management systems\n    - Blog and article publishing\n    - User-generated content\n\n### Component Structure Principles\n\n- **Single Responsibility**: Each component should represent one cohesive business domain\n- **Logical Grouping**: Tables within a component should be closely related\n- **Dependency Order**: Components should be ordered to minimize cross-dependencies\n- **Balanced Size**: Aim for 3-15 tables per component for maintainability\n\n## Table Naming Standards\n\n### Required Naming Conventions\n\n1. **Plural Forms**: All table names must be plural\n   - `user` \u2192 `users`\n   - `product` \u2192 `products`\n   - `order_item` \u2192 `order_items`\n\n2. **Snake Case**: Use snake_case for all table names\n   - `UserProfile` \u2192 `user_profiles`\n   - `OrderItem` \u2192 `order_items`\n   - `ShoppingCart` \u2192 `shopping_carts`\n\n3. **Domain Prefixes**: Apply consistent prefixes within domains\n   - Shopping domain: `shopping_customers`, `shopping_carts`, `shopping_orders`\n   - BBS domain: `bbs_articles`, `bbs_comments`, `bbs_categories`\n\n4. **Special Table Types**:\n   - **Snapshots**: Add `_snapshots` suffix for versioning tables\n   - **Junction Tables**: Use both entity names: `user_roles`, `product_categories`\n   - **Materialized Views**: Will be handled by the second agent with `mv_` prefix\n\n### Business Entity Patterns\n\nCommon table patterns to identify:\n\n- **Core Entities**: Main business objects (users, products, orders)\n- **Snapshot Tables**: For audit trails and versioning (user_snapshots, order_snapshots)\n- **Junction Tables**: For many-to-many relationships (user_roles, product_tags)\n- **Configuration Tables**: For system settings and parameters\n- **Log Tables**: For tracking and audit purposes\n\n## Function Calling Requirements\n\n### Output Structure\n\nYou must generate a structured function call using the `IExtractComponentsProps` interface:\n\n```typescript\ninterface IExtractComponentsProps {\n  components: AutoBePrisma.IComponent[];\n}\n```\n\n### Component Interface Compliance\n\nEach component must follow the `AutoBePrisma.IComponent` structure:\n\n```typescript\ninterface IComponent {\n  filename: string & tags.Pattern<\"^[a-zA-Z0-9._-]+\\\\.prisma$\">;\n  namespace: string;\n  tables: Array<string & tags.Pattern<\"^[a-z][a-z0-9_]*$\">>;\n}\n```\n\n### Quality Requirements\n\n- **Filename Format**: `schema-{number}-{domain}.prisma` with proper numbering\n- **Namespace Clarity**: Use PascalCase for namespace names that clearly represent the domain\n- **Table Completeness**: Include ALL tables required by the business requirements\n- **Pattern Compliance**: All table names must match the regex pattern `^[a-z][a-z0-9_]*$`\n\n## Analysis Process\n\n### Step 1: Requirements Deep Dive\n1. **Business Domain Analysis**: Identify all business domains mentioned in requirements\n2. **Entity Extraction**: List all database entities needed to fulfill requirements\n3. **Relationship Mapping**: Understand how entities relate across domains\n4. **Scope Validation**: Ensure all functional requirements are covered\n\n### Step 2: Domain Organization\n1. **Component Identification**: Group related entities into logical components\n2. **Dependency Analysis**: Order components to minimize cross-dependencies\n3. **Naming Standardization**: Apply consistent naming conventions\n4. **Balance Check**: Ensure reasonable distribution of tables across components\n\n### Step 3: Validation\n1. **Coverage Verification**: Confirm all requirements are addressed\n2. **Consistency Check**: Verify naming and organization consistency\n3. **Scalability Assessment**: Ensure the structure supports future growth\n4. **Business Alignment**: Validate alignment with business terminology\n\n## Critical Success Factors\n\n### Must-Have Qualities\n\n1. **Complete Coverage**: Every business requirement must be reflected in table organization\n2. **Logical Grouping**: Related tables must be in the same component\n3. **Consistent Naming**: All table names must follow the established conventions\n4. **Proper Ordering**: Components must be ordered to handle dependencies correctly\n5. **Domain Clarity**: Each component must represent a clear business domain\n\n### Common Pitfalls to Avoid\n\n- **Over-Fragmentation**: Don't create too many small components\n- **Under-Organization**: Don't put unrelated tables in the same component\n- **Naming Inconsistency**: Don't mix naming conventions\n- **Missing Entities**: Don't overlook entities mentioned in requirements\n- **Circular Dependencies**: Don't create component dependency cycles\n\n## Working Language\n\n- **Default Language**: English for all technical terms, model names, and field names\n- **User Language**: Use the language specified by the user for thinking and responses\n- **Technical Consistency**: Maintain English for all database-related terminology regardless of user language\n\n## Output Format\n\nAlways respond with a single function call that provides the complete component organization:\n\n```typescript\n// Example function call structure\nconst componentExtraction: IExtractComponentsProps = {\n  components: [\n    {\n      filename: \"schema-01-systematic.prisma\",\n      namespace: \"Systematic\",\n      tables: [\"channels\", \"sections\", \"configurations\"]\n    },\n    {\n      filename: \"schema-02-actors.prisma\", \n      namespace: \"Actors\",\n      tables: [\"users\", \"customers\", \"administrators\"]\n    }\n    // ... more components\n  ]\n};\n```\n\n## Final Validation Checklist\n\nBefore generating the function call, ensure:\n\n- [ ] All business requirements are covered by the table organization\n- [ ] All table names are plural and follow snake_case convention\n- [ ] Components are logically grouped by business domain\n- [ ] Component dependencies are properly ordered\n- [ ] Filenames follow the schema-{number}-{domain}.prisma convention\n- [ ] Namespaces use clear PascalCase domain names\n- [ ] No duplicate table names across all components\n- [ ] Each component contains 3-15 tables for maintainability\n- [ ] All patterns match the required regex constraints\n\nYour output will serve as the foundation for the complete Prisma schema generation, so accuracy and completeness are critical." /* AutoBeSystemPromptConstant.PRISMA_COMPONENT */,
         },
         {
             id: (0, uuid_1.v4)(),

package/lib/orchestrate/prisma/transformPrismaComponentsHistories.js.map

@@ -1 +1 @@
-{"version":3,"file":"transformPrismaComponentsHistories.js","sourceRoot":"","sources":["../../../src/orchestrate/prisma/transformPrismaComponentsHistories.ts"],"names":[],"mappings":";;;AACA,+BAA0B;AAKnB,MAAM,kCAAkC,GAAG,CAChD,KAAkB,EAClB,SAAwB,IAAI,EAG5B,EAAE;IACF,IAAI,KAAK,CAAC,OAAO,KAAK,IAAI;QACxB,OAAO;YACL;gBACE,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;gBACpC,IAAI,EAAE,eAAe;gBACrB,IAAI,EAAE;oBACJ,4CAA4C;oBAC5C,+BAA+B;oBAC/B,8CAA8C;iBAC/C,CAAC,IAAI,CAAC,GAAG,CAAC;aACZ;SACF,CAAC;IACJ,OAAO;QACL;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,iiGAA6C;SAClD;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,kBAAkB;YACxB,IAAI,EAAE;gBACJ,0CAA0C;gBAC1C,EAAE;gBACF,8DAA8D;gBAC9D,gDAAgD;gBAChD,EAAE;gBACF,iBAAiB;gBACjB,KAAK,CAAC,OAAO,CAAC,MAAM;gBACpB,EAAE;gBACF,gCAAgC;gBAChC,EAAE;gBACF,SAAS;gBACT,IAAI,CAAC,SAAS,CAAC,KAAK,CAAC,OAAO,CAAC,KAAK,CAAC;gBACnC,KAAK;gBACL,WAAW;gBACX,EAAE;gBACF,kCAAkC,MAAM,EAAE;gBAC1C,EAAE;gBACF,2FAA2F;gBAC3F,gDAAgD;gBAChD,kEAAkE;gBAClE,yHAAyH;gBACzH,EAAE;gBACF,mBAAmB;gBACnB,EAAE;gBACF,+DAA+D;gBAC/D,EAAE;gBACF,oBAAoB;gBACpB,2BAA2B;gBAC3B,EAAE;gBACF,uIAAuI;gBACvI,cAAc;gBACd,EAAE;gBACF,6BAA6B;gBAC7B,EAAE;gBACF,uBAAuB;gBACvB,EAAE;gBACF,yHAAyH;gBACzH,uFAAuF;gBACvF,EAAE;gBACF,4EAA4E;gBAC5E,EAAE;gBACF,kIAAkI;aACnI,CAAC,IAAI,CAAC,IAAI,CAAC;SACb;KACF,CAAC;AACJ,CAAC,CAAC;AA5EW,QAAA,kCAAkC,sCA4E7C"}
+{"version":3,"file":"transformPrismaComponentsHistories.js","sourceRoot":"","sources":["../../../src/orchestrate/prisma/transformPrismaComponentsHistories.ts"],"names":[],"mappings":";;;AACA,+BAA0B;AAKnB,MAAM,kCAAkC,GAAG,CAChD,KAAkB,EAClB,SAAwB,IAAI,EAG5B,EAAE;IACF,IAAI,KAAK,CAAC,OAAO,KAAK,IAAI;QACxB,OAAO;YACL;gBACE,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;gBACpC,IAAI,EAAE,eAAe;gBACrB,IAAI,EAAE;oBACJ,4CAA4C;oBAC5C,+BAA+B;oBAC/B,8CAA8C;iBAC/C,CAAC,IAAI,CAAC,GAAG,CAAC;aACZ;SACF,CAAC;IACJ,OAAO;QACL;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,mtTAA6C;SAClD;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,kBAAkB;YACxB,IAAI,EAAE;gBACJ,0CAA0C;gBAC1C,EAAE;gBACF,8DAA8D;gBAC9D,gDAAgD;gBAChD,EAAE;gBACF,iBAAiB;gBACjB,KAAK,CAAC,OAAO,CAAC,MAAM;gBACpB,EAAE;gBACF,gCAAgC;gBAChC,EAAE;gBACF,SAAS;gBACT,IAAI,CAAC,SAAS,CAAC,KAAK,CAAC,OAAO,CAAC,KAAK,CAAC;gBACnC,KAAK;gBACL,WAAW;gBACX,EAAE;gBACF,kCAAkC,MAAM,EAAE;gBAC1C,EAAE;gBACF,2FAA2F;gBAC3F,gDAAgD;gBAChD,kEAAkE;gBAClE,yHAAyH;gBACzH,EAAE;gBACF,mBAAmB;gBACnB,EAAE;gBACF,+DAA+D;gBAC/D,EAAE;gBACF,oBAAoB;gBACpB,2BAA2B;gBAC3B,EAAE;gBACF,uIAAuI;gBACvI,cAAc;gBACd,EAAE;gBACF,6BAA6B;gBAC7B,EAAE;gBACF,uBAAuB;gBACvB,EAAE;gBACF,yHAAyH;gBACzH,uFAAuF;gBACvF,EAAE;gBACF,4EAA4E;gBAC5E,EAAE;gBACF,kIAAkI;aACnI,CAAC,IAAI,CAAC,IAAI,CAAC;SACb;KACF,CAAC;AACJ,CAAC,CAAC;AA5EW,QAAA,kCAAkC,sCA4E7C"}

package/lib/orchestrate/prisma/transformPrismaCorrectHistories.js

@@ -43,7 +43,7 @@ const transformPrismaCorrectHistories = (result) => {
                 "study about Prisma schema language",
                 "from the best practices and examples",
                 "",
-                "Study the following comprehensive BBS (bullet-in board system) project schema as a reference for implementing all the patterns and best practices outlined above. \n\nThis enterprise-level implementation demonstrates proper domain organization, relationship modeling, documentation standards, and advanced patterns like snapshots, inheritance, and materialized views.\n\n## Input (Requirement Analysis)\n\n```json\n{% EXAMPLE_BBS_REQUIREMENT_ANALYSIS %}\n```\n\nWhen such requirement analysis report comes\n\n## Output (Prisma Schema Files)\n\n```json\n{\"main.prisma\":\"datasource db {\\n  provider = \\\"postgresql\\\"\\n  url      = env(\\\"BBS_POSTGRES_URL\\\")\\n}\\n\\ngenerator client {\\n  provider        = \\\"prisma-client-js\\\"\\n  previewFeatures = [\\\"views\\\"]\\n  binaryTargets   = [\\\"native\\\"]\\n}\\n\\ngenerator markdown {\\n  provider = \\\"prisma-markdown\\\"\\n  title    = \\\"Bullet-in Board System\\\"\\n  output   = \\\"../../docs/ERD.md\\\"\\n}\\n\\n//-----------------------------------------------------------\\n// ARTICLES\\n//-----------------------------------------------------------\\n/// Attachment File.\\n///\\n/// Every attachment files that are managed in current system.\\n///\\n/// @namespace Articles\\n/// @author Samchon\\nmodel attachment_files {\\n  //----\\n  // COLUMNS\\n  //----\\n  /// Primary Key.\\n  id String @id @db.Uuid\\n\\n  /// File name, except extension.\\n  name String @db.VarChar\\n\\n  /// Extension.\\n  ///\\n  /// Possible to omit like `README` case.\\n  extension String? @db.VarChar\\n\\n  /// URL path of the real file.\\n  url String @db.VarChar\\n\\n  /// Creation time of file.\\n  created_at DateTime @db.Timestamptz\\n\\n  //----\\n  // RELATIONS\\n  //----\\n  bbs_article_snapshot_files          bbs_article_snapshot_files[]\\n  bbs_article_comment_snapshots_files bbs_article_comment_snapshot_files[]\\n}\\n\\n/// Article entity.\\n/// \\n/// `bbs_articles` is a super-type entity of all kinds of articles in the \\n/// current backend system, literally shaping individual articles of \\n/// the bulletin board.\\n///\\n/// And, as you can see, the elements that must inevitably exist in the \\n/// article, such as the title or the body, do not exist in the `bbs_articles`, \\n/// but exist in the subsidiary entity, {@link bbs_article_snapshots}, as a \\n/// 1: N relationship, which is because a new snapshot record is published \\n/// every time the article is modified.\\n///\\n/// The reason why a new snapshot record is published every time the article \\n/// is modified is to preserve the evidence. Due to the nature of e-community, \\n/// there is always a threat of dispute among the participants. And it can \\n/// happen that disputes arise through articles or comments, and to prevent \\n/// such things as modifying existing articles to manipulate the situation, \\n/// the article is designed in this structure.\\n///\\n/// In other words, to keep evidence, and prevent fraud.\\n///\\n/// @namespace Articles\\n/// @author Samchon\\nmodel bbs_articles {\\n  /// Primary Key.\\n  id String @id @db.Uuid\\n\\n  /// Writer's name.\\n  writer String @db.VarChar\\n\\n  /// Password for modification.\\n  password String @db.VarChar\\n\\n  /// Creation time of article.\\n  created_at DateTime @db.Timestamptz\\n\\n  /// Deletion time of article.\\n  ///\\n  /// To keep evidence, do not delete the article, but just mark it as \\n  /// deleted.\\n  deleted_at DateTime? @db.Timestamptz\\n\\n  //----\\n  // RELATIONS\\n  //----\\n  /// List of snapshots.\\n  ///\\n  /// It is created for the first time when an article is created, and is\\n  /// accumulated every time the article is modified.\\n  snapshots bbs_article_snapshots[]\\n\\n  /// List of comments.\\n  comments bbs_article_comments[]\\n\\n  mv_last mv_bbs_article_last_snapshots?\\n\\n  @@index([created_at])\\n}\\n\\n/// Snapshot of article.\\n///\\n/// `bbs_article_snapshots` is a snapshot entity that contains the contents of\\n/// the article, as mentioned in {@link bbs_articles}, the contents of the \\n/// article are separated from the article record to keep evidence and prevent \\n/// fraud.\\n///\\n/// @namespace Articles\\n/// @author Samchon\\nmodel bbs_article_snapshots {\\n  //----\\n  // COLUMNS\\n  //----\\n  /// Primary Key.\\n  id String @id @db.Uuid\\n\\n  /// Belong article's {@link bbs_articles.id}\\n  bbs_article_id String @db.Uuid\\n\\n  /// Format of body.\\n  ///\\n  /// Same meaning with extension like `html`, `md`, `txt`.\\n  format String @db.VarChar\\n\\n  /// Title of article.\\n  title String @db.VarChar\\n\\n  /// Content body of article.\\n  body String\\n\\n  /// IP address of the snapshot writer.\\n  ip String @db.VarChar\\n\\n  /// Creation time of record.\\n  ///\\n  /// It means creation time or update time or article.\\n  created_at DateTime @db.Timestamptz\\n\\n  //----\\n  // RELATIONS\\n  //----\\n  /// Belong article info.\\n  article bbs_articles @relation(fields: [bbs_article_id], references: [id], onDelete: Cascade)\\n\\n  /// List of wrappers of attachment files.\\n  to_files bbs_article_snapshot_files[]\\n\\n  mv_last mv_bbs_article_last_snapshots?\\n\\n  @@index([bbs_article_id, created_at])\\n}\\n\\n/// Attachment file of article snapshot.\\n///\\n/// `bbs_article_snapshot_files` is an entity that shapes the attached files of\\n/// the article snapshot.\\n///\\n/// `bbs_article_snapshot_files` is a typical pair relationship table to \\n/// resolve the M: N relationship between {@link bbs_article_snapshots} and\\n/// {@link attachment_files} tables. Also, to ensure the order of the attached\\n/// files, it has an additional `sequence` attribute, which we will continue to\\n/// see in this documents.\\n///\\n/// @namespace Articles\\n/// @author Samchon\\nmodel bbs_article_snapshot_files {\\n  //----\\n  // COLUMNS\\n  //----\\n  /// Primary Key.\\n  id String @id @db.Uuid\\n\\n  /// Belonged snapshot's {@link bbs_article_snapshots.id}\\n  bbs_article_snapshot_id String @db.Uuid\\n\\n  /// Belonged file's {@link attachment_files.id}\\n  attachment_file_id String @db.Uuid\\n\\n  /// Sequence of attachment file in the snapshot.\\n  sequence Int @db.Integer\\n\\n  //----\\n  // RELATIONS\\n  //----\\n  /// Belonged article.\\n  snapshot bbs_article_snapshots @relation(fields: [bbs_article_snapshot_id], references: [id], onDelete: Cascade)\\n\\n  /// Belonged file.\\n  file attachment_files @relation(fields: [attachment_file_id], references: [id], onDelete: Cascade)\\n\\n  @@index([bbs_article_snapshot_id])\\n  @@index([attachment_file_id])\\n}\\n\\n/// Comment written on an article.\\n///\\n/// `bbs_article_comments` is an entity that shapes the comments written on an\\n/// article.\\n///\\n/// And for this comment, as in the previous relationship between \\n/// {@link bbs_articles} and {@link bbs_article_snapshots}, the content body \\n/// of the comment is stored in the sub {@link bbs_article_comment_snapshots} \\n/// table for evidentialism, and a new snapshot record is issued every time \\n/// the comment is modified.\\n///\\n/// Also, `bbs_article_comments` is expressing the relationship of the \\n/// hierarchical reply structure through the `parent_id` attribute.\\n///\\n/// @namespace Articles\\n/// @author Samchon\\nmodel bbs_article_comments {\\n  //----\\n  // COLUMNS\\n  //----\\n  /// Primary Key.\\n  id String @id @db.Uuid\\n\\n  /// Belonged article's {@link bbs_articles.id}\\n  bbs_article_id String @db.Uuid\\n\\n  /// Parent comment's {@link bbs_article_comments.id}\\n  ///\\n  /// Used to express the hierarchical reply structure.\\n  parent_id String? @db.Uuid\\n\\n  /// Writer's name.\\n  writer String @db.VarChar\\n\\n  /// Password for modification.\\n  password String @db.VarChar\\n\\n  /// Creation time of comment.\\n  created_at DateTime @db.Timestamptz\\n\\n  /// Deletion time of comment.\\n  ///\\n  /// Do not allow to delete the comment, but just mark it as deleted, \\n  /// to keep evidence.\\n  deleted_at DateTime? @db.Timestamptz\\n\\n  //----\\n  // RELATIONS\\n  //----\\n  /// Belonged article.\\n  article bbs_articles @relation(fields: [bbs_article_id], references: [id], onDelete: Cascade)\\n\\n  /// Parent comment.\\n  ///\\n  /// Only when reply case.\\n  parent bbs_article_comments? @relation(\\\"bbs_article_comments_reply\\\", fields: [parent_id], references: [id], onDelete: Cascade)\\n\\n  /// List of children comments.\\n  ///\\n  /// Reply comments of current.\\n  children bbs_article_comments[] @relation(\\\"bbs_article_comments_reply\\\")\\n\\n  /// List of snapshots.\\n  ///\\n  /// It is created for the first time when a comment is created, and is\\n  /// accumulated every time the comment is modified.\\n  snapshots bbs_article_comment_snapshots[]\\n\\n  @@index([bbs_article_id, parent_id, created_at])\\n}\\n\\n/// Snapshot of comment.\\n///\\n/// `bbs_article_comment_snapshots` is a snapshot entity that contains the \\n/// contents of the comment.\\n///\\n/// As mentioned in {@link bbs_article_comments}, designed to keep evidence \\n/// and prevent fraud.\\n///\\n/// @namespace Articles\\n/// @author Samchon\\nmodel bbs_article_comment_snapshots {\\n  //----\\n  // COLUMNS\\n  //----\\n  /// Primary Key.\\n  id String @id @db.Uuid\\n\\n  /// Belonged article's {@link bbs_article_comments.id}\\n  bbs_article_comment_id String @db.Uuid\\n\\n  /// Format of content body.\\n  ///\\n  /// Same meaning with extension like `html`, `md`, `txt`.\\n  format String @db.VarChar\\n\\n  /// Content body of comment.\\n  body String\\n\\n  /// IP address of the snapshot writer.\\n  ip String @db.VarChar\\n\\n  /// Creation time of record.\\n  ///\\n  /// It means creation time or update time or comment.\\n  created_at DateTime @db.Timestamptz\\n\\n  //----\\n  // RELATIONS\\n  //----\\n  /// Belong comment info.\\n  comment bbs_article_comments @relation(fields: [bbs_article_comment_id], references: [id], onDelete: Cascade)\\n\\n  /// List of wrappers of attachment files.\\n  to_files bbs_article_comment_snapshot_files[]\\n\\n  @@index([bbs_article_comment_id, created_at])\\n}\\n\\n/// Attachment file of comment snapshot.\\n/// \\n/// `bbs_article_comment_snapshot_files` is an entity resolving the M:N \\n/// relationship between {@link bbs_article_comment_snapshots} and \\n/// {@link attachment_files} tables.\\n/// \\n/// @namespace Articles\\n/// @author Samchon\\nmodel bbs_article_comment_snapshot_files {\\n  //----\\n  // COLUMNS\\n  //----\\n  /// Primary Key.\\n  id String @id @db.Uuid\\n\\n  /// Belonged snapshot's {@link bbs_article_comment_snapshots.id}\\n  bbs_article_comment_snapshot_id String @db.Uuid\\n\\n  /// Belonged file's {@link attachment_files.id}\\n  attachment_file_id String @db.Uuid\\n\\n  /// Sequence order.\\n  ///\\n  /// Sequence order of the attached file in the belonged snapshot.\\n  sequence Int @db.Integer\\n\\n  //----\\n  // RELATIONS\\n  //----\\n  /// Belonged article.\\n  snapshot bbs_article_comment_snapshots @relation(fields: [bbs_article_comment_snapshot_id], references: [id], onDelete: Cascade)\\n\\n  /// Belonged file.\\n  file attachment_files @relation(fields: [attachment_file_id], references: [id], onDelete: Cascade)\\n\\n  @@index([bbs_article_comment_snapshot_id])\\n  @@index([attachment_file_id])\\n}\\n\\n/// @hidden\\n/// @author Samchon\\nmodel mv_bbs_article_last_snapshots {\\n  bbs_article_id          String @id @db.Uuid\\n  bbs_article_snapshot_id String @db.Uuid\\n\\n  article  bbs_articles          @relation(fields: [bbs_article_id], references: [id], onDelete: Cascade)\\n  snapshot bbs_article_snapshots @relation(fields: [bbs_article_snapshot_id], references: [id], onDelete: Cascade)\\n\\n  @@unique([bbs_article_snapshot_id])\\n}\\n\"}\n```\n\nYou have to make above like prisma schema files.\n\nStudy the above schema files, and follow its coding style." /* AutoBeSystemPromptConstant.PRISMA_EXAMPLE */,
+                "Study the following comprehensive BBS (bullet-in board system) project schema as a reference for implementing all the patterns and best practices outlined above. \n\nThis enterprise-level implementation demonstrates proper domain organization, relationship modeling, documentation standards, and advanced patterns like snapshots, inheritance, and materialized views.\n\n## Input (Requirement Analysis)\n\n```json\n{% EXAMPLE_BBS_REQUIREMENT_ANALYSIS %}\n```\n\nWhen such requirement analysis report comes\n\n## Output (Prisma Schema Files)\n\n```json\n{\"main.prisma\":\"generator client {\\n  provider = \\\"prisma-client-js\\\"\\n}\\n\\ndatasource db {\\n  provider = \\\"sqlite\\\"\\n  url      = \\\"file:../bbs.db\\\"\\n}\\n\\ngenerator markdown {\\n  provider = \\\"prisma-markdown\\\"\\n  output   = \\\"../../docs/ERD.md\\\"\\n}\\n\\n//-----------------------------------------------------------\\n// ARTICLES\\n//-----------------------------------------------------------\\n/// Attachment File.\\n///\\n/// Every attachment files that are managed in current system.\\n///\\n/// @namespace Articles\\n/// @author Samchon\\nmodel attachment_files {\\n  //----\\n  // COLUMNS\\n  //----\\n  /// Primary Key.\\n  id String @id\\n\\n  /// File name, except extension.\\n  name String\\n\\n  /// Extension.\\n  ///\\n  /// Possible to omit like `README` case.\\n  extension String?\\n\\n  /// URL path of the real file.\\n  url String\\n\\n  /// Creation time of file.\\n  created_at DateTime\\n\\n  //----\\n  // RELATIONS\\n  //----\\n  bbs_article_snapshot_files          bbs_article_snapshot_files[]\\n  bbs_article_comment_snapshots_files bbs_article_comment_snapshot_files[]\\n}\\n\\n/// Article entity.\\n/// \\n/// `bbs_articles` is a super-type entity of all kinds of articles in the \\n/// current backend system, literally shaping individual articles of \\n/// the bulletin board.\\n///\\n/// And, as you can see, the elements that must inevitably exist in the \\n/// article, such as the title or the body, do not exist in the `bbs_articles`, \\n/// but exist in the subsidiary entity, {@link bbs_article_snapshots}, as a \\n/// 1: N relationship, which is because a new snapshot record is published \\n/// every time the article is modified.\\n///\\n/// The reason why a new snapshot record is published every time the article \\n/// is modified is to preserve the evidence. Due to the nature of e-community, \\n/// there is always a threat of dispute among the participants. And it can \\n/// happen that disputes arise through articles or comments, and to prevent \\n/// such things as modifying existing articles to manipulate the situation, \\n/// the article is designed in this structure.\\n///\\n/// In other words, to keep evidence, and prevent fraud.\\n///\\n/// @namespace Articles\\n/// @author Samchon\\nmodel bbs_articles {\\n  /// Primary Key.\\n  id String @id\\n\\n  /// Writer's name.\\n  writer String\\n\\n  /// Password for modification.\\n  password String\\n\\n  /// Creation time of article.\\n  created_at DateTime\\n\\n  /// Deletion time of article.\\n  ///\\n  /// To keep evidence, do not delete the article, but just mark it as \\n  /// deleted.\\n  deleted_at DateTime?\\n\\n  //----\\n  // RELATIONS\\n  //----\\n  /// List of snapshots.\\n  ///\\n  /// It is created for the first time when an article is created, and is\\n  /// accumulated every time the article is modified.\\n  snapshots bbs_article_snapshots[]\\n\\n  /// List of comments.\\n  comments bbs_article_comments[]\\n\\n  mv_last mv_bbs_article_last_snapshots?\\n\\n  @@index([created_at])\\n}\\n\\n/// Snapshot of article.\\n///\\n/// `bbs_article_snapshots` is a snapshot entity that contains the contents of\\n/// the article, as mentioned in {@link bbs_articles}, the contents of the \\n/// article are separated from the article record to keep evidence and prevent \\n/// fraud.\\n///\\n/// @namespace Articles\\n/// @author Samchon\\nmodel bbs_article_snapshots {\\n  //----\\n  // COLUMNS\\n  //----\\n  /// Primary Key.\\n  id String @id\\n\\n  /// Belong article's {@link bbs_articles.id}\\n  bbs_article_id String\\n\\n  /// Format of body.\\n  ///\\n  /// Same meaning with extension like `html`, `md`, `txt`.\\n  format String\\n\\n  /// Title of article.\\n  title String\\n\\n  /// Content body of article.\\n  body String\\n\\n  /// IP address of the snapshot writer.\\n  ip String\\n\\n  /// Creation time of record.\\n  ///\\n  /// It means creation time or update time or article.\\n  created_at DateTime\\n\\n  //----\\n  // RELATIONS\\n  //----\\n  /// Belong article info.\\n  article bbs_articles @relation(fields: [bbs_article_id], references: [id], onDelete: Cascade)\\n\\n  /// List of wrappers of attachment files.\\n  to_files bbs_article_snapshot_files[]\\n\\n  mv_last mv_bbs_article_last_snapshots?\\n\\n  @@index([bbs_article_id, created_at])\\n}\\n\\n/// Attachment file of article snapshot.\\n///\\n/// `bbs_article_snapshot_files` is an entity that shapes the attached files of\\n/// the article snapshot.\\n///\\n/// `bbs_article_snapshot_files` is a typical pair relationship table to \\n/// resolve the M: N relationship between {@link bbs_article_snapshots} and\\n/// {@link attachment_files} tables. Also, to ensure the order of the attached\\n/// files, it has an additional `sequence` attribute, which we will continue to\\n/// see in this documents.\\n///\\n/// @namespace Articles\\n/// @author Samchon\\nmodel bbs_article_snapshot_files {\\n  //----\\n  // COLUMNS\\n  //----\\n  /// Primary Key.\\n  id String @id\\n\\n  /// Belonged snapshot's {@link bbs_article_snapshots.id}\\n  bbs_article_snapshot_id String\\n\\n  /// Belonged file's {@link attachment_files.id}\\n  attachment_file_id String\\n\\n  /// Sequence of attachment file in the snapshot.\\n  sequence Int\\n\\n  //----\\n  // RELATIONS\\n  //----\\n  /// Belonged article.\\n  snapshot bbs_article_snapshots @relation(fields: [bbs_article_snapshot_id], references: [id], onDelete: Cascade)\\n\\n  /// Belonged file.\\n  file attachment_files @relation(fields: [attachment_file_id], references: [id], onDelete: Cascade)\\n\\n  @@index([bbs_article_snapshot_id])\\n  @@index([attachment_file_id])\\n}\\n\\n/// Comment written on an article.\\n///\\n/// `bbs_article_comments` is an entity that shapes the comments written on an\\n/// article.\\n///\\n/// And for this comment, as in the previous relationship between \\n/// {@link bbs_articles} and {@link bbs_article_snapshots}, the content body \\n/// of the comment is stored in the sub {@link bbs_article_comment_snapshots} \\n/// table for evidentialism, and a new snapshot record is issued every time \\n/// the comment is modified.\\n///\\n/// Also, `bbs_article_comments` is expressing the relationship of the \\n/// hierarchical reply structure through the `parent_id` attribute.\\n///\\n/// @namespace Articles\\n/// @author Samchon\\nmodel bbs_article_comments {\\n  //----\\n  // COLUMNS\\n  //----\\n  /// Primary Key.\\n  id String @id\\n\\n  /// Belonged article's {@link bbs_articles.id}\\n  bbs_article_id String\\n\\n  /// Parent comment's {@link bbs_article_comments.id}\\n  ///\\n  /// Used to express the hierarchical reply structure.\\n  parent_id String?\\n\\n  /// Writer's name.\\n  writer String\\n\\n  /// Password for modification.\\n  password String\\n\\n  /// Creation time of comment.\\n  created_at DateTime\\n\\n  /// Deletion time of comment.\\n  ///\\n  /// Do not allow to delete the comment, but just mark it as deleted, \\n  /// to keep evidence.\\n  deleted_at DateTime?\\n\\n  //----\\n  // RELATIONS\\n  //----\\n  /// Belonged article.\\n  article bbs_articles @relation(fields: [bbs_article_id], references: [id], onDelete: Cascade)\\n\\n  /// Parent comment.\\n  ///\\n  /// Only when reply case.\\n  parent bbs_article_comments? @relation(\\\"bbs_article_comments_reply\\\", fields: [parent_id], references: [id], onDelete: Cascade)\\n\\n  /// List of children comments.\\n  ///\\n  /// Reply comments of current.\\n  children bbs_article_comments[] @relation(\\\"bbs_article_comments_reply\\\")\\n\\n  /// List of snapshots.\\n  ///\\n  /// It is created for the first time when a comment is created, and is\\n  /// accumulated every time the comment is modified.\\n  snapshots bbs_article_comment_snapshots[]\\n\\n  @@index([bbs_article_id, parent_id, created_at])\\n}\\n\\n/// Snapshot of comment.\\n///\\n/// `bbs_article_comment_snapshots` is a snapshot entity that contains the \\n/// contents of the comment.\\n///\\n/// As mentioned in {@link bbs_article_comments}, designed to keep evidence \\n/// and prevent fraud.\\n///\\n/// @namespace Articles\\n/// @author Samchon\\nmodel bbs_article_comment_snapshots {\\n  //----\\n  // COLUMNS\\n  //----\\n  /// Primary Key.\\n  id String @id\\n\\n  /// Belonged article's {@link bbs_article_comments.id}\\n  bbs_article_comment_id String\\n\\n  /// Format of content body.\\n  ///\\n  /// Same meaning with extension like `html`, `md`, `txt`.\\n  format String\\n\\n  /// Content body of comment.\\n  body String\\n\\n  /// IP address of the snapshot writer.\\n  ip String\\n\\n  /// Creation time of record.\\n  ///\\n  /// It means creation time or update time or comment.\\n  created_at DateTime\\n\\n  //----\\n  // RELATIONS\\n  //----\\n  /// Belong comment info.\\n  comment bbs_article_comments @relation(fields: [bbs_article_comment_id], references: [id], onDelete: Cascade)\\n\\n  /// List of wrappers of attachment files.\\n  to_files bbs_article_comment_snapshot_files[]\\n\\n  @@index([bbs_article_comment_id, created_at])\\n}\\n\\n/// Attachment file of comment snapshot.\\n/// \\n/// `bbs_article_comment_snapshot_files` is an entity resolving the M:N \\n/// relationship between {@link bbs_article_comment_snapshots} and \\n/// {@link attachment_files} tables.\\n/// \\n/// @namespace Articles\\n/// @author Samchon\\nmodel bbs_article_comment_snapshot_files {\\n  //----\\n  // COLUMNS\\n  //----\\n  /// Primary Key.\\n  id String @id\\n\\n  /// Belonged snapshot's {@link bbs_article_comment_snapshots.id}\\n  bbs_article_comment_snapshot_id String\\n\\n  /// Belonged file's {@link attachment_files.id}\\n  attachment_file_id String\\n\\n  /// Sequence order.\\n  ///\\n  /// Sequence order of the attached file in the belonged snapshot.\\n  sequence Int\\n\\n  //----\\n  // RELATIONS\\n  //----\\n  /// Belonged article.\\n  snapshot bbs_article_comment_snapshots @relation(fields: [bbs_article_comment_snapshot_id], references: [id], onDelete: Cascade)\\n\\n  /// Belonged file.\\n  file attachment_files @relation(fields: [attachment_file_id], references: [id], onDelete: Cascade)\\n\\n  @@index([bbs_article_comment_snapshot_id])\\n  @@index([attachment_file_id])\\n}\\n\\n/// @hidden\\n/// @author Samchon\\nmodel mv_bbs_article_last_snapshots {\\n  bbs_article_id          String @id\\n  bbs_article_snapshot_id String\\n\\n  article  bbs_articles          @relation(fields: [bbs_article_id], references: [id], onDelete: Cascade)\\n  snapshot bbs_article_snapshots @relation(fields: [bbs_article_snapshot_id], references: [id], onDelete: Cascade)\\n\\n  @@unique([bbs_article_snapshot_id])\\n}\\n\"}\n```\n\nYou have to make above like prisma schema files.\n\nStudy the above schema files, and follow its coding style." /* AutoBeSystemPromptConstant.PRISMA_EXAMPLE */,
             ].join("\n"),
         },
     ];

package/lib/orchestrate/prisma/transformPrismaHistories.js

@@ -27,7 +27,7 @@ const transformPrismaHistories = (state) => {
             id: (0, uuid_1.v4)(),
             created_at: new Date().toISOString(),
             type: "assistantMessage",
-            text: "Study the following comprehensive BBS (bullet-in board system) project schema as a reference for implementing all the patterns and best practices outlined above. \n\nThis enterprise-level implementation demonstrates proper domain organization, relationship modeling, documentation standards, and advanced patterns like snapshots, inheritance, and materialized views.\n\n## Input (Requirement Analysis)\n\n```json\n{% EXAMPLE_BBS_REQUIREMENT_ANALYSIS %}\n```\n\nWhen such requirement analysis report comes\n\n## Output (Prisma Schema Files)\n\n```json\n{\"main.prisma\":\"datasource db {\\n  provider = \\\"postgresql\\\"\\n  url      = env(\\\"BBS_POSTGRES_URL\\\")\\n}\\n\\ngenerator client {\\n  provider        = \\\"prisma-client-js\\\"\\n  previewFeatures = [\\\"views\\\"]\\n  binaryTargets   = [\\\"native\\\"]\\n}\\n\\ngenerator markdown {\\n  provider = \\\"prisma-markdown\\\"\\n  title    = \\\"Bullet-in Board System\\\"\\n  output   = \\\"../../docs/ERD.md\\\"\\n}\\n\\n//-----------------------------------------------------------\\n// ARTICLES\\n//-----------------------------------------------------------\\n/// Attachment File.\\n///\\n/// Every attachment files that are managed in current system.\\n///\\n/// @namespace Articles\\n/// @author Samchon\\nmodel attachment_files {\\n  //----\\n  // COLUMNS\\n  //----\\n  /// Primary Key.\\n  id String @id @db.Uuid\\n\\n  /// File name, except extension.\\n  name String @db.VarChar\\n\\n  /// Extension.\\n  ///\\n  /// Possible to omit like `README` case.\\n  extension String? @db.VarChar\\n\\n  /// URL path of the real file.\\n  url String @db.VarChar\\n\\n  /// Creation time of file.\\n  created_at DateTime @db.Timestamptz\\n\\n  //----\\n  // RELATIONS\\n  //----\\n  bbs_article_snapshot_files          bbs_article_snapshot_files[]\\n  bbs_article_comment_snapshots_files bbs_article_comment_snapshot_files[]\\n}\\n\\n/// Article entity.\\n/// \\n/// `bbs_articles` is a super-type entity of all kinds of articles in the \\n/// current backend system, literally shaping individual articles of \\n/// the bulletin board.\\n///\\n/// And, as you can see, the elements that must inevitably exist in the \\n/// article, such as the title or the body, do not exist in the `bbs_articles`, \\n/// but exist in the subsidiary entity, {@link bbs_article_snapshots}, as a \\n/// 1: N relationship, which is because a new snapshot record is published \\n/// every time the article is modified.\\n///\\n/// The reason why a new snapshot record is published every time the article \\n/// is modified is to preserve the evidence. Due to the nature of e-community, \\n/// there is always a threat of dispute among the participants. And it can \\n/// happen that disputes arise through articles or comments, and to prevent \\n/// such things as modifying existing articles to manipulate the situation, \\n/// the article is designed in this structure.\\n///\\n/// In other words, to keep evidence, and prevent fraud.\\n///\\n/// @namespace Articles\\n/// @author Samchon\\nmodel bbs_articles {\\n  /// Primary Key.\\n  id String @id @db.Uuid\\n\\n  /// Writer's name.\\n  writer String @db.VarChar\\n\\n  /// Password for modification.\\n  password String @db.VarChar\\n\\n  /// Creation time of article.\\n  created_at DateTime @db.Timestamptz\\n\\n  /// Deletion time of article.\\n  ///\\n  /// To keep evidence, do not delete the article, but just mark it as \\n  /// deleted.\\n  deleted_at DateTime? @db.Timestamptz\\n\\n  //----\\n  // RELATIONS\\n  //----\\n  /// List of snapshots.\\n  ///\\n  /// It is created for the first time when an article is created, and is\\n  /// accumulated every time the article is modified.\\n  snapshots bbs_article_snapshots[]\\n\\n  /// List of comments.\\n  comments bbs_article_comments[]\\n\\n  mv_last mv_bbs_article_last_snapshots?\\n\\n  @@index([created_at])\\n}\\n\\n/// Snapshot of article.\\n///\\n/// `bbs_article_snapshots` is a snapshot entity that contains the contents of\\n/// the article, as mentioned in {@link bbs_articles}, the contents of the \\n/// article are separated from the article record to keep evidence and prevent \\n/// fraud.\\n///\\n/// @namespace Articles\\n/// @author Samchon\\nmodel bbs_article_snapshots {\\n  //----\\n  // COLUMNS\\n  //----\\n  /// Primary Key.\\n  id String @id @db.Uuid\\n\\n  /// Belong article's {@link bbs_articles.id}\\n  bbs_article_id String @db.Uuid\\n\\n  /// Format of body.\\n  ///\\n  /// Same meaning with extension like `html`, `md`, `txt`.\\n  format String @db.VarChar\\n\\n  /// Title of article.\\n  title String @db.VarChar\\n\\n  /// Content body of article.\\n  body String\\n\\n  /// IP address of the snapshot writer.\\n  ip String @db.VarChar\\n\\n  /// Creation time of record.\\n  ///\\n  /// It means creation time or update time or article.\\n  created_at DateTime @db.Timestamptz\\n\\n  //----\\n  // RELATIONS\\n  //----\\n  /// Belong article info.\\n  article bbs_articles @relation(fields: [bbs_article_id], references: [id], onDelete: Cascade)\\n\\n  /// List of wrappers of attachment files.\\n  to_files bbs_article_snapshot_files[]\\n\\n  mv_last mv_bbs_article_last_snapshots?\\n\\n  @@index([bbs_article_id, created_at])\\n}\\n\\n/// Attachment file of article snapshot.\\n///\\n/// `bbs_article_snapshot_files` is an entity that shapes the attached files of\\n/// the article snapshot.\\n///\\n/// `bbs_article_snapshot_files` is a typical pair relationship table to \\n/// resolve the M: N relationship between {@link bbs_article_snapshots} and\\n/// {@link attachment_files} tables. Also, to ensure the order of the attached\\n/// files, it has an additional `sequence` attribute, which we will continue to\\n/// see in this documents.\\n///\\n/// @namespace Articles\\n/// @author Samchon\\nmodel bbs_article_snapshot_files {\\n  //----\\n  // COLUMNS\\n  //----\\n  /// Primary Key.\\n  id String @id @db.Uuid\\n\\n  /// Belonged snapshot's {@link bbs_article_snapshots.id}\\n  bbs_article_snapshot_id String @db.Uuid\\n\\n  /// Belonged file's {@link attachment_files.id}\\n  attachment_file_id String @db.Uuid\\n\\n  /// Sequence of attachment file in the snapshot.\\n  sequence Int @db.Integer\\n\\n  //----\\n  // RELATIONS\\n  //----\\n  /// Belonged article.\\n  snapshot bbs_article_snapshots @relation(fields: [bbs_article_snapshot_id], references: [id], onDelete: Cascade)\\n\\n  /// Belonged file.\\n  file attachment_files @relation(fields: [attachment_file_id], references: [id], onDelete: Cascade)\\n\\n  @@index([bbs_article_snapshot_id])\\n  @@index([attachment_file_id])\\n}\\n\\n/// Comment written on an article.\\n///\\n/// `bbs_article_comments` is an entity that shapes the comments written on an\\n/// article.\\n///\\n/// And for this comment, as in the previous relationship between \\n/// {@link bbs_articles} and {@link bbs_article_snapshots}, the content body \\n/// of the comment is stored in the sub {@link bbs_article_comment_snapshots} \\n/// table for evidentialism, and a new snapshot record is issued every time \\n/// the comment is modified.\\n///\\n/// Also, `bbs_article_comments` is expressing the relationship of the \\n/// hierarchical reply structure through the `parent_id` attribute.\\n///\\n/// @namespace Articles\\n/// @author Samchon\\nmodel bbs_article_comments {\\n  //----\\n  // COLUMNS\\n  //----\\n  /// Primary Key.\\n  id String @id @db.Uuid\\n\\n  /// Belonged article's {@link bbs_articles.id}\\n  bbs_article_id String @db.Uuid\\n\\n  /// Parent comment's {@link bbs_article_comments.id}\\n  ///\\n  /// Used to express the hierarchical reply structure.\\n  parent_id String? @db.Uuid\\n\\n  /// Writer's name.\\n  writer String @db.VarChar\\n\\n  /// Password for modification.\\n  password String @db.VarChar\\n\\n  /// Creation time of comment.\\n  created_at DateTime @db.Timestamptz\\n\\n  /// Deletion time of comment.\\n  ///\\n  /// Do not allow to delete the comment, but just mark it as deleted, \\n  /// to keep evidence.\\n  deleted_at DateTime? @db.Timestamptz\\n\\n  //----\\n  // RELATIONS\\n  //----\\n  /// Belonged article.\\n  article bbs_articles @relation(fields: [bbs_article_id], references: [id], onDelete: Cascade)\\n\\n  /// Parent comment.\\n  ///\\n  /// Only when reply case.\\n  parent bbs_article_comments? @relation(\\\"bbs_article_comments_reply\\\", fields: [parent_id], references: [id], onDelete: Cascade)\\n\\n  /// List of children comments.\\n  ///\\n  /// Reply comments of current.\\n  children bbs_article_comments[] @relation(\\\"bbs_article_comments_reply\\\")\\n\\n  /// List of snapshots.\\n  ///\\n  /// It is created for the first time when a comment is created, and is\\n  /// accumulated every time the comment is modified.\\n  snapshots bbs_article_comment_snapshots[]\\n\\n  @@index([bbs_article_id, parent_id, created_at])\\n}\\n\\n/// Snapshot of comment.\\n///\\n/// `bbs_article_comment_snapshots` is a snapshot entity that contains the \\n/// contents of the comment.\\n///\\n/// As mentioned in {@link bbs_article_comments}, designed to keep evidence \\n/// and prevent fraud.\\n///\\n/// @namespace Articles\\n/// @author Samchon\\nmodel bbs_article_comment_snapshots {\\n  //----\\n  // COLUMNS\\n  //----\\n  /// Primary Key.\\n  id String @id @db.Uuid\\n\\n  /// Belonged article's {@link bbs_article_comments.id}\\n  bbs_article_comment_id String @db.Uuid\\n\\n  /// Format of content body.\\n  ///\\n  /// Same meaning with extension like `html`, `md`, `txt`.\\n  format String @db.VarChar\\n\\n  /// Content body of comment.\\n  body String\\n\\n  /// IP address of the snapshot writer.\\n  ip String @db.VarChar\\n\\n  /// Creation time of record.\\n  ///\\n  /// It means creation time or update time or comment.\\n  created_at DateTime @db.Timestamptz\\n\\n  //----\\n  // RELATIONS\\n  //----\\n  /// Belong comment info.\\n  comment bbs_article_comments @relation(fields: [bbs_article_comment_id], references: [id], onDelete: Cascade)\\n\\n  /// List of wrappers of attachment files.\\n  to_files bbs_article_comment_snapshot_files[]\\n\\n  @@index([bbs_article_comment_id, created_at])\\n}\\n\\n/// Attachment file of comment snapshot.\\n/// \\n/// `bbs_article_comment_snapshot_files` is an entity resolving the M:N \\n/// relationship between {@link bbs_article_comment_snapshots} and \\n/// {@link attachment_files} tables.\\n/// \\n/// @namespace Articles\\n/// @author Samchon\\nmodel bbs_article_comment_snapshot_files {\\n  //----\\n  // COLUMNS\\n  //----\\n  /// Primary Key.\\n  id String @id @db.Uuid\\n\\n  /// Belonged snapshot's {@link bbs_article_comment_snapshots.id}\\n  bbs_article_comment_snapshot_id String @db.Uuid\\n\\n  /// Belonged file's {@link attachment_files.id}\\n  attachment_file_id String @db.Uuid\\n\\n  /// Sequence order.\\n  ///\\n  /// Sequence order of the attached file in the belonged snapshot.\\n  sequence Int @db.Integer\\n\\n  //----\\n  // RELATIONS\\n  //----\\n  /// Belonged article.\\n  snapshot bbs_article_comment_snapshots @relation(fields: [bbs_article_comment_snapshot_id], references: [id], onDelete: Cascade)\\n\\n  /// Belonged file.\\n  file attachment_files @relation(fields: [attachment_file_id], references: [id], onDelete: Cascade)\\n\\n  @@index([bbs_article_comment_snapshot_id])\\n  @@index([attachment_file_id])\\n}\\n\\n/// @hidden\\n/// @author Samchon\\nmodel mv_bbs_article_last_snapshots {\\n  bbs_article_id          String @id @db.Uuid\\n  bbs_article_snapshot_id String @db.Uuid\\n\\n  article  bbs_articles          @relation(fields: [bbs_article_id], references: [id], onDelete: Cascade)\\n  snapshot bbs_article_snapshots @relation(fields: [bbs_article_snapshot_id], references: [id], onDelete: Cascade)\\n\\n  @@unique([bbs_article_snapshot_id])\\n}\\n\"}\n```\n\nYou have to make above like prisma schema files.\n\nStudy the above schema files, and follow its coding style." /* AutoBeSystemPromptConstant.PRISMA_EXAMPLE */,
+            text: "Study the following comprehensive BBS (bullet-in board system) project schema as a reference for implementing all the patterns and best practices outlined above. \n\nThis enterprise-level implementation demonstrates proper domain organization, relationship modeling, documentation standards, and advanced patterns like snapshots, inheritance, and materialized views.\n\n## Input (Requirement Analysis)\n\n```json\n{% EXAMPLE_BBS_REQUIREMENT_ANALYSIS %}\n```\n\nWhen such requirement analysis report comes\n\n## Output (Prisma Schema Files)\n\n```json\n{\"main.prisma\":\"generator client {\\n  provider = \\\"prisma-client-js\\\"\\n}\\n\\ndatasource db {\\n  provider = \\\"sqlite\\\"\\n  url      = \\\"file:../bbs.db\\\"\\n}\\n\\ngenerator markdown {\\n  provider = \\\"prisma-markdown\\\"\\n  output   = \\\"../../docs/ERD.md\\\"\\n}\\n\\n//-----------------------------------------------------------\\n// ARTICLES\\n//-----------------------------------------------------------\\n/// Attachment File.\\n///\\n/// Every attachment files that are managed in current system.\\n///\\n/// @namespace Articles\\n/// @author Samchon\\nmodel attachment_files {\\n  //----\\n  // COLUMNS\\n  //----\\n  /// Primary Key.\\n  id String @id\\n\\n  /// File name, except extension.\\n  name String\\n\\n  /// Extension.\\n  ///\\n  /// Possible to omit like `README` case.\\n  extension String?\\n\\n  /// URL path of the real file.\\n  url String\\n\\n  /// Creation time of file.\\n  created_at DateTime\\n\\n  //----\\n  // RELATIONS\\n  //----\\n  bbs_article_snapshot_files          bbs_article_snapshot_files[]\\n  bbs_article_comment_snapshots_files bbs_article_comment_snapshot_files[]\\n}\\n\\n/// Article entity.\\n/// \\n/// `bbs_articles` is a super-type entity of all kinds of articles in the \\n/// current backend system, literally shaping individual articles of \\n/// the bulletin board.\\n///\\n/// And, as you can see, the elements that must inevitably exist in the \\n/// article, such as the title or the body, do not exist in the `bbs_articles`, \\n/// but exist in the subsidiary entity, {@link bbs_article_snapshots}, as a \\n/// 1: N relationship, which is because a new snapshot record is published \\n/// every time the article is modified.\\n///\\n/// The reason why a new snapshot record is published every time the article \\n/// is modified is to preserve the evidence. Due to the nature of e-community, \\n/// there is always a threat of dispute among the participants. And it can \\n/// happen that disputes arise through articles or comments, and to prevent \\n/// such things as modifying existing articles to manipulate the situation, \\n/// the article is designed in this structure.\\n///\\n/// In other words, to keep evidence, and prevent fraud.\\n///\\n/// @namespace Articles\\n/// @author Samchon\\nmodel bbs_articles {\\n  /// Primary Key.\\n  id String @id\\n\\n  /// Writer's name.\\n  writer String\\n\\n  /// Password for modification.\\n  password String\\n\\n  /// Creation time of article.\\n  created_at DateTime\\n\\n  /// Deletion time of article.\\n  ///\\n  /// To keep evidence, do not delete the article, but just mark it as \\n  /// deleted.\\n  deleted_at DateTime?\\n\\n  //----\\n  // RELATIONS\\n  //----\\n  /// List of snapshots.\\n  ///\\n  /// It is created for the first time when an article is created, and is\\n  /// accumulated every time the article is modified.\\n  snapshots bbs_article_snapshots[]\\n\\n  /// List of comments.\\n  comments bbs_article_comments[]\\n\\n  mv_last mv_bbs_article_last_snapshots?\\n\\n  @@index([created_at])\\n}\\n\\n/// Snapshot of article.\\n///\\n/// `bbs_article_snapshots` is a snapshot entity that contains the contents of\\n/// the article, as mentioned in {@link bbs_articles}, the contents of the \\n/// article are separated from the article record to keep evidence and prevent \\n/// fraud.\\n///\\n/// @namespace Articles\\n/// @author Samchon\\nmodel bbs_article_snapshots {\\n  //----\\n  // COLUMNS\\n  //----\\n  /// Primary Key.\\n  id String @id\\n\\n  /// Belong article's {@link bbs_articles.id}\\n  bbs_article_id String\\n\\n  /// Format of body.\\n  ///\\n  /// Same meaning with extension like `html`, `md`, `txt`.\\n  format String\\n\\n  /// Title of article.\\n  title String\\n\\n  /// Content body of article.\\n  body String\\n\\n  /// IP address of the snapshot writer.\\n  ip String\\n\\n  /// Creation time of record.\\n  ///\\n  /// It means creation time or update time or article.\\n  created_at DateTime\\n\\n  //----\\n  // RELATIONS\\n  //----\\n  /// Belong article info.\\n  article bbs_articles @relation(fields: [bbs_article_id], references: [id], onDelete: Cascade)\\n\\n  /// List of wrappers of attachment files.\\n  to_files bbs_article_snapshot_files[]\\n\\n  mv_last mv_bbs_article_last_snapshots?\\n\\n  @@index([bbs_article_id, created_at])\\n}\\n\\n/// Attachment file of article snapshot.\\n///\\n/// `bbs_article_snapshot_files` is an entity that shapes the attached files of\\n/// the article snapshot.\\n///\\n/// `bbs_article_snapshot_files` is a typical pair relationship table to \\n/// resolve the M: N relationship between {@link bbs_article_snapshots} and\\n/// {@link attachment_files} tables. Also, to ensure the order of the attached\\n/// files, it has an additional `sequence` attribute, which we will continue to\\n/// see in this documents.\\n///\\n/// @namespace Articles\\n/// @author Samchon\\nmodel bbs_article_snapshot_files {\\n  //----\\n  // COLUMNS\\n  //----\\n  /// Primary Key.\\n  id String @id\\n\\n  /// Belonged snapshot's {@link bbs_article_snapshots.id}\\n  bbs_article_snapshot_id String\\n\\n  /// Belonged file's {@link attachment_files.id}\\n  attachment_file_id String\\n\\n  /// Sequence of attachment file in the snapshot.\\n  sequence Int\\n\\n  //----\\n  // RELATIONS\\n  //----\\n  /// Belonged article.\\n  snapshot bbs_article_snapshots @relation(fields: [bbs_article_snapshot_id], references: [id], onDelete: Cascade)\\n\\n  /// Belonged file.\\n  file attachment_files @relation(fields: [attachment_file_id], references: [id], onDelete: Cascade)\\n\\n  @@index([bbs_article_snapshot_id])\\n  @@index([attachment_file_id])\\n}\\n\\n/// Comment written on an article.\\n///\\n/// `bbs_article_comments` is an entity that shapes the comments written on an\\n/// article.\\n///\\n/// And for this comment, as in the previous relationship between \\n/// {@link bbs_articles} and {@link bbs_article_snapshots}, the content body \\n/// of the comment is stored in the sub {@link bbs_article_comment_snapshots} \\n/// table for evidentialism, and a new snapshot record is issued every time \\n/// the comment is modified.\\n///\\n/// Also, `bbs_article_comments` is expressing the relationship of the \\n/// hierarchical reply structure through the `parent_id` attribute.\\n///\\n/// @namespace Articles\\n/// @author Samchon\\nmodel bbs_article_comments {\\n  //----\\n  // COLUMNS\\n  //----\\n  /// Primary Key.\\n  id String @id\\n\\n  /// Belonged article's {@link bbs_articles.id}\\n  bbs_article_id String\\n\\n  /// Parent comment's {@link bbs_article_comments.id}\\n  ///\\n  /// Used to express the hierarchical reply structure.\\n  parent_id String?\\n\\n  /// Writer's name.\\n  writer String\\n\\n  /// Password for modification.\\n  password String\\n\\n  /// Creation time of comment.\\n  created_at DateTime\\n\\n  /// Deletion time of comment.\\n  ///\\n  /// Do not allow to delete the comment, but just mark it as deleted, \\n  /// to keep evidence.\\n  deleted_at DateTime?\\n\\n  //----\\n  // RELATIONS\\n  //----\\n  /// Belonged article.\\n  article bbs_articles @relation(fields: [bbs_article_id], references: [id], onDelete: Cascade)\\n\\n  /// Parent comment.\\n  ///\\n  /// Only when reply case.\\n  parent bbs_article_comments? @relation(\\\"bbs_article_comments_reply\\\", fields: [parent_id], references: [id], onDelete: Cascade)\\n\\n  /// List of children comments.\\n  ///\\n  /// Reply comments of current.\\n  children bbs_article_comments[] @relation(\\\"bbs_article_comments_reply\\\")\\n\\n  /// List of snapshots.\\n  ///\\n  /// It is created for the first time when a comment is created, and is\\n  /// accumulated every time the comment is modified.\\n  snapshots bbs_article_comment_snapshots[]\\n\\n  @@index([bbs_article_id, parent_id, created_at])\\n}\\n\\n/// Snapshot of comment.\\n///\\n/// `bbs_article_comment_snapshots` is a snapshot entity that contains the \\n/// contents of the comment.\\n///\\n/// As mentioned in {@link bbs_article_comments}, designed to keep evidence \\n/// and prevent fraud.\\n///\\n/// @namespace Articles\\n/// @author Samchon\\nmodel bbs_article_comment_snapshots {\\n  //----\\n  // COLUMNS\\n  //----\\n  /// Primary Key.\\n  id String @id\\n\\n  /// Belonged article's {@link bbs_article_comments.id}\\n  bbs_article_comment_id String\\n\\n  /// Format of content body.\\n  ///\\n  /// Same meaning with extension like `html`, `md`, `txt`.\\n  format String\\n\\n  /// Content body of comment.\\n  body String\\n\\n  /// IP address of the snapshot writer.\\n  ip String\\n\\n  /// Creation time of record.\\n  ///\\n  /// It means creation time or update time or comment.\\n  created_at DateTime\\n\\n  //----\\n  // RELATIONS\\n  //----\\n  /// Belong comment info.\\n  comment bbs_article_comments @relation(fields: [bbs_article_comment_id], references: [id], onDelete: Cascade)\\n\\n  /// List of wrappers of attachment files.\\n  to_files bbs_article_comment_snapshot_files[]\\n\\n  @@index([bbs_article_comment_id, created_at])\\n}\\n\\n/// Attachment file of comment snapshot.\\n/// \\n/// `bbs_article_comment_snapshot_files` is an entity resolving the M:N \\n/// relationship between {@link bbs_article_comment_snapshots} and \\n/// {@link attachment_files} tables.\\n/// \\n/// @namespace Articles\\n/// @author Samchon\\nmodel bbs_article_comment_snapshot_files {\\n  //----\\n  // COLUMNS\\n  //----\\n  /// Primary Key.\\n  id String @id\\n\\n  /// Belonged snapshot's {@link bbs_article_comment_snapshots.id}\\n  bbs_article_comment_snapshot_id String\\n\\n  /// Belonged file's {@link attachment_files.id}\\n  attachment_file_id String\\n\\n  /// Sequence order.\\n  ///\\n  /// Sequence order of the attached file in the belonged snapshot.\\n  sequence Int\\n\\n  //----\\n  // RELATIONS\\n  //----\\n  /// Belonged article.\\n  snapshot bbs_article_comment_snapshots @relation(fields: [bbs_article_comment_snapshot_id], references: [id], onDelete: Cascade)\\n\\n  /// Belonged file.\\n  file attachment_files @relation(fields: [attachment_file_id], references: [id], onDelete: Cascade)\\n\\n  @@index([bbs_article_comment_snapshot_id])\\n  @@index([attachment_file_id])\\n}\\n\\n/// @hidden\\n/// @author Samchon\\nmodel mv_bbs_article_last_snapshots {\\n  bbs_article_id          String @id\\n  bbs_article_snapshot_id String\\n\\n  article  bbs_articles          @relation(fields: [bbs_article_id], references: [id], onDelete: Cascade)\\n  snapshot bbs_article_snapshots @relation(fields: [bbs_article_snapshot_id], references: [id], onDelete: Cascade)\\n\\n  @@unique([bbs_article_snapshot_id])\\n}\\n\"}\n```\n\nYou have to make above like prisma schema files.\n\nStudy the above schema files, and follow its coding style." /* AutoBeSystemPromptConstant.PRISMA_EXAMPLE */,
         },
         {
             id: (0, uuid_1.v4)(),

package/lib/orchestrate/prisma/transformPrismaHistories.js.map

@@ -1 +1 @@
-{"version":3,"file":"transformPrismaHistories.js","sourceRoot":"","sources":["../../../src/orchestrate/prisma/transformPrismaHistories.ts"],"names":[],"mappings":";;;AACA,+BAA0B;AAKnB,MAAM,wBAAwB,GAAG,CACtC,KAAkB,EAGlB,EAAE;IACF,IAAI,KAAK,CAAC,OAAO,KAAK,IAAI;QACxB,OAAO;YACL;gBACE,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;gBACpC,IAAI,EAAE,eAAe;gBACrB,IAAI,EAAE;oBACJ,4CAA4C;oBAC5C,+BAA+B;oBAC/B,8CAA8C;iBAC/C,CAAC,IAAI,CAAC,GAAG,CAAC;aACZ;SACF,CAAC;IACJ,OAAO;QACL;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,2qRAAmC;SACxC;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,kBAAkB;YACxB,IAAI,wqXAA2C;SAChD;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,kBAAkB;YACxB,IAAI,EAAE;gBACJ,0CAA0C;gBAC1C,EAAE;gBACF,8DAA8D;gBAC9D,gDAAgD;gBAChD,EAAE;gBACF,iBAAiB;gBACjB,KAAK,CAAC,OAAO,CAAC,MAAM;gBACpB,EAAE;gBACF,gCAAgC;gBAChC,EAAE;gBACF,SAAS;gBACT,IAAI,CAAC,SAAS,CAAC,KAAK,CAAC,OAAO,CAAC,KAAK,CAAC;gBACnC,KAAK;aACN,CAAC,IAAI,CAAC,IAAI,CAAC;SACb;KACF,CAAC;AACJ,CAAC,CAAC;AApDW,QAAA,wBAAwB,4BAoDnC"}
+{"version":3,"file":"transformPrismaHistories.js","sourceRoot":"","sources":["../../../src/orchestrate/prisma/transformPrismaHistories.ts"],"names":[],"mappings":";;;AACA,+BAA0B;AAKnB,MAAM,wBAAwB,GAAG,CACtC,KAAkB,EAGlB,EAAE;IACF,IAAI,KAAK,CAAC,OAAO,KAAK,IAAI;QACxB,OAAO;YACL;gBACE,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;gBACpC,IAAI,EAAE,eAAe;gBACrB,IAAI,EAAE;oBACJ,4CAA4C;oBAC5C,+BAA+B;oBAC/B,8CAA8C;iBAC/C,CAAC,IAAI,CAAC,GAAG,CAAC;aACZ;SACF,CAAC;IACJ,OAAO;QACL;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,2qRAAmC;SACxC;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,kBAAkB;YACxB,IAAI,0mWAA2C;SAChD;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,kBAAkB;YACxB,IAAI,EAAE;gBACJ,0CAA0C;gBAC1C,EAAE;gBACF,8DAA8D;gBAC9D,gDAAgD;gBAChD,EAAE;gBACF,iBAAiB;gBACjB,KAAK,CAAC,OAAO,CAAC,MAAM;gBACpB,EAAE;gBACF,gCAAgC;gBAChC,EAAE;gBACF,SAAS;gBACT,IAAI,CAAC,SAAS,CAAC,KAAK,CAAC,OAAO,CAAC,KAAK,CAAC;gBACnC,KAAK;aACN,CAAC,IAAI,CAAC,IAAI,CAAC;SACb;KACF,CAAC;AACJ,CAAC,CAAC;AApDW,QAAA,wBAAwB,4BAoDnC"}

package/lib/orchestrate/prisma/transformPrismaSchemaHistories.d.ts

@@ -1,7 +1,3 @@
 import { IAgenticaHistoryJson } from "@agentica/core";
-import { AutoBeAnalyzeHistory } from "@autobe/interface";
-export declare const transformPrismaSchemaHistories: (analyze: AutoBeAnalyzeHistory, component: {
-    filename: string;
-    tables: string[];
-    entireTables: string[];
-}) => Array<IAgenticaHistoryJson.IAssistantMessage | IAgenticaHistoryJson.ISystemMessage>;
+import { AutoBePrisma } from "@autobe/interface";
+export declare const transformPrismaSchemaHistories: (requirementAnalysisReport: Record<string, string>, targetComponent: AutoBePrisma.IComponent, otherComponents: AutoBePrisma.IComponent[]) => Array<IAgenticaHistoryJson.IAssistantMessage | IAgenticaHistoryJson.ISystemMessage>;

package/lib/orchestrate/prisma/transformPrismaSchemaHistories.js

@@ -2,52 +2,44 @@
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.transformPrismaSchemaHistories = void 0;
 const uuid_1 = require("uuid");
-const transformPrismaSchemaHistories = (analyze, component) => {
+const transformPrismaSchemaHistories = (requirementAnalysisReport, targetComponent, otherComponents) => {
     return [
         {
             id: (0, uuid_1.v4)(),
             created_at: new Date().toISOString(),
             type: "systemMessage",
-            text: "You 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\n### Core Principles\n\n- **Never ask for clarification** - Work with the provided requirements and analyze them thoroughly\n- **Output structured function call** - Use AutoBePrisma namespace types for precise schema definition\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 review and 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\n### Normalization Requirements\n\n#### First Normal Form (1NF)\n- Each field contains atomic values only\n- No repeating groups or arrays in regular tables\n- Each row must be unique\n\n#### Second Normal Form (2NF)\n- Must be in 1NF\n- All non-key attributes fully depend on the entire primary key\n- No partial dependencies on composite keys\n\n#### Third Normal Form (3NF)\n- Must be in 2NF\n- No transitive dependencies\n- All non-key attributes depend only on the primary key\n\n#### Denormalization Rules\n- **ONLY allowed in materialized views** with `mv_` prefix\n- Regular business tables MUST remain fully normalized\n- Pre-calculated totals, counts, summaries \u2192 `mv_` tables only\n- Cached data for performance \u2192 `mv_` tables only\n- Redundant data for reporting \u2192 `mv_` tables only\n\n### Default Working Language: English\n\n- Use the language specified by user in messages as the working language when explicitly provided\n- All thinking and responses must be in the working language\n- All model/field names must be in English regardless of working language\n\n### Input Format\n\nYou will receive:\n1. **User requirements specification** - Detailed business requirements document\n2. **AutoBePrisma types** - Structured interfaces for schema generation\n\n### Task: Generate Structured Prisma Schema Definition\n\nTransform user requirements into a complete AutoBePrisma.IApplication structure that represents the entire Prisma schema system.\n\n### Schema Design Guidelines\n\n#### Naming Conventions\n\n- **Models**: `snake_case` and MUST be plural (e.g., `user_profiles`, `order_items`, `shopping_customers`)\n- **Fields**: `snake_case` (e.g., `created_at`, `user_id`, `shopping_customer_id`)  \n- **Relations**: `snake_case` (e.g., `customer`, `order_items`, `user_profile`)\n- **Foreign Keys**: `{target_model_name}_id` pattern (e.g., `shopping_customer_id`, `bbs_article_id`)\n- **Materialized Views**: `mv_` prefix (e.g., `mv_shopping_sale_last_snapshots`)\n\n#### File Organization Principles\n\n- Organize by business domains (8-10 files typical)\n- Follow dependency order in numbering: `schema-{number}-{domain}.prisma`\n- Common domains: Systematic, Actors, Sales, Carts, Orders, Coupons, Coins, Inquiries, Favorites, Articles\n- Each file should contain 3-15 related models\n\n#### Data Type Mapping\n\n- **Primary Keys**: Always `\"uuid\"` type\n- **Foreign Keys**: Always `\"uuid\"` type  \n- **Timestamps**: Use `\"datetime\"` type\n- **Monetary Values**: Use `\"double\"` type\n- **Quantities/Counts**: Use `\"int\"` type\n- **Text Content**: Use `\"string\"` type\n- **URLs/Links**: Use `\"uri\"` type\n- **Flags/Booleans**: Use `\"boolean\"` type\n- **Dates Only**: Use `\"date\"` type (rare)\n\n#### Prohibited Field Types in Regular Tables\n\n**NEVER include these in regular business tables:**\n- Pre-calculated totals (e.g., `total_amount`, `item_count`)\n- Cached values (e.g., `last_purchase_date`, `total_spent`)\n- Aggregated data (e.g., `average_rating`, `review_count`)\n- Derived values (e.g., `full_name` from first/last name)\n- Summary fields (e.g., `order_summary`, `customer_status`)\n\n**These belong ONLY in `mv_` materialized views!**\n\n#### Description Writing Standards\n\nEach description MUST include:\n\n1. **Requirements Mapping**: Which specific requirement from the requirements analysis this implements\n2. **Business Purpose**: What business problem this solves in simple, understandable language\n3. **Technical Context**: How it relates to other models and system architecture\n4. **Normalization Compliance**: How this maintains normalized structure\n5. **Usage Examples**: Clear examples of how this will be used\n6. **Behavioral Notes**: Important constraints, rules, or special behaviors\n\n**Model Description Format:**\n```\n\"[Model Purpose] - This implements the [specific requirement] from the requirements document. \n\n[Business explanation in simple terms]. Maintains [normalization level] compliance by [explanation]. For example, [concrete usage example].\n\nKey relationships: [important connections to other models].\nSpecial behaviors: [any important constraints or rules].\"\n```\n\n**Field Description Format:**\n```\n\"[Field purpose] - Implements the [requirement aspect]. \n\n[Business meaning]. Ensures normalization by [explanation]. For example, [usage example].\n[Any constraints or special behaviors].\"\n```\n\n#### Relationship Design Patterns\n\n- **1:1 Relationships**: Set `unique: true` on foreign key\n- **1:N Relationships**: Set `unique: false` on foreign key  \n- **M:N Relationships**: Create junction tables with composite keys\n- **Self-References**: Use `parent_id` field name\n- **Snapshot Relationships**: Link current entity to its snapshot history\n- **Optional Relationships**: Set `nullable: true` when relationship is optional\n\n#### Index Strategy\n\n- **NO single foreign key indexes** - Prisma auto-creates these\n- **Composite indexes OK** - Include foreign keys with other fields for query patterns\n- **Unique indexes**: For business constraints (emails, codes, composite keys)\n- **Performance indexes**: For common query patterns (timestamps, search fields)\n- **GIN indexes**: For full-text search on string fields\n\n#### Materialized View Patterns\n\n- Set `material: true` for computed/cached tables\n- Prefix names with `mv_`\n- Common patterns: `mv_*_last_snapshots`, `mv_*_prices`, `mv_*_balances`, `mv_*_inventories`\n- **ONLY place for denormalized data**\n- **ONLY place for pre-calculated fields**\n- **ONLY place for aggregated values**\n\n### Requirements Analysis Process\n\n#### 1. Domain Identification\n- Identify major business domains from requirements\n- Group related functionality into coherent domains\n- Determine file organization and dependencies\n\n#### 2. Entity Extraction\n- Extract all business entities mentioned in requirements\n- Identify main entities vs snapshot entities vs junction tables\n- Determine materialized views needed for performance\n- **Separate normalized entities from denormalized reporting needs**\n\n#### 3. Relationship Mapping\n- Map all relationships between entities\n- Identify cardinality (1:1, 1:N, M:N)\n- Determine optional vs required relationships\n- **Ensure relationships maintain normalization**\n\n#### 4. Attribute Analysis\n- Extract all data attributes from requirements\n- Determine data types and constraints\n- Identify nullable vs required fields\n- **Separate atomic data from calculated data**\n\n#### 5. Business Rule Implementation\n- Identify unique constraints from business rules\n- Determine audit trail requirements (snapshot pattern)\n- Map performance requirements to indexes\n- **Map denormalization needs to materialized views**\n\n### MANDATORY REVIEW PROCESS\n\n#### Pre-Output Validation Checklist\n\n**ALWAYS perform this comprehensive review before generating the function call:**\n\n1. **Normalization Validation**\n   - All regular tables comply with 3NF minimum\n   - No calculated fields in regular business tables\n   - All denormalized data is in `mv_` tables only\n   - No transitive dependencies in regular tables\n\n2. **Model Validation**\n   - All model names are plural and unique across all files\n   - All models have exactly one primary key field named \"id\" of type \"uuid\"\n   - All materialized views have `material: true` and \"mv_\" prefix\n   - Regular tables contain only atomic, normalized data\n\n3. **Field Validation**  \n   - No duplicate field names within any model\n   - All foreign key fields follow `{target_model}_id` pattern\n   - All foreign key fields have type \"uuid\"\n   - All field descriptions map to specific requirements\n   - **NO calculated fields in regular tables**\n\n4. **Relationship Validation**\n   - All foreign fields have corresponding relation definitions\n   - Target models exist in the schema structure\n   - No duplicate relation names within any model\n   - Cardinality correctly reflected in `unique` property\n\n5. **Index Validation**\n   - No single foreign key indexes in plain or unique indexes\n   - All composite indexes serve clear query patterns\n   - All referenced field names exist in their models\n   - GIN indexes only on string type fields\n\n6. **Cross-File Validation**\n   - All referenced models exist in appropriate files\n   - File dependencies are properly ordered\n   - No circular dependencies between files\n\n#### Quality Assurance Questions\n\nBefore finalizing, verify:\n- Does each model clearly implement a specific business requirement?\n- Are all relationships bidirectionally consistent?\n- Do all descriptions provide clear requirement traceability?\n- Are naming conventions consistently applied?\n- Is the snapshot architecture properly implemented?\n- Are all business constraints captured in unique indexes?\n- **Is every regular table properly normalized?**\n- **Are ALL calculated/aggregated fields in `mv_` tables only?**\n\n### Expected Output\n\nGenerate a single function call using the AutoBePrisma.IApplication structure:\n\n```typescript\n// Function call format\nconst application: AutoBePrisma.IApplication = {\n  files: [\n    {\n      filename: \"schema-01-articles.prisma\",\n      namespace: \"Articles\", \n      models: [...]\n    },\n    // ... more files\n  ]\n};\n```\n\n### Final Quality Checklist\n\nBefore outputting, ensure:\n- [ ] All models implement specific requirements with clear traceability\n- [ ] All field descriptions explain business purpose and requirement mapping\n- [ ] All model names are plural and follow naming conventions\n- [ ] **NO duplicate fields within any model**\n- [ ] **NO duplicate relations within any model** \n- [ ] **NO duplicate model names across all files**\n- [ ] All foreign keys have proper relations defined\n- [ ] No single foreign key indexes in index arrays\n- [ ] All cross-file references are valid\n- [ ] Snapshot architecture properly implemented where needed\n- [ ] **ALL REGULAR TABLES FULLY NORMALIZED (3NF minimum)**\n- [ ] **NO PRE-CALCULATED FIELDS IN REGULAR TABLES**\n- [ ] **ALL DENORMALIZATION IN `mv_` TABLES ONLY**\n- [ ] **COMPREHENSIVE VALIDATION COMPLETED**" /* AutoBeSystemPromptConstant.PRISMA_SCHEMA */,
+            text: "# Enhanced Prisma Schema Expert System Prompt\n\n## \uD83C\uDFAF YOUR PRIMARY MISSION\n\n### WHAT YOU MUST DO (ONLY THIS!)\n\n**STEP 1: EXTRACT YOUR ASSIGNMENT**\n```\nYour Job: targetComponent.tables = [...]\nYour File: targetComponent.filename = \"...\"\nYour Domain: targetComponent.namespace = \"...\"\n```\n\n**STEP 2: CREATE EXACTLY THESE TABLES**\n- Create ALL tables from `targetComponent.tables` \n- Use EXACT table names as provided (NO CHANGES)\n- This is your COMPLETE and ONLY specification\n- Count: `targetComponent.tables.length` models required\n\n**STEP 3: 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\n---\n\n## \uD83D\uDEA7 REFERENCE INFORMATION (FOR RELATIONSHIPS ONLY)\n\n### Other Existing Tables (ALREADY CREATED - DO NOT CREATE)\n- `otherComponents[]` lists tables 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\n### Core Principles\n\n- **Focus on assigned tables** - Create exactly what `targetComponent.tables` specifies\n- **Output structured function call** - Use AutoBePrisma namespace types for precise schema definition\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 review and 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\n## \uD83D\uDCCB MANDATORY PROCESSING STEPS\n\n### Step 1: Assignment Extraction\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 otherComponents tables - these ALREADY EXIST]\n\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 otherComponents tables only for foreign key relationships (they ALREADY EXIST)\n\u2705 I will add junction tables if needed for M:N relationships\n```\n\n### Step 2: Table Creation\nFor each table in `targetComponent.tables`:\n1. Create model with exact name as provided (NO CHANGES)\n2. Add primary key field \"id\" of type \"uuid\"  \n3. Add business fields based on requirements\n4. Add foreign keys to reference other tables\n5. Add proper relationships and constraints\n\n### Step 3: Success Verification\n- \u2705 All `targetComponent.tables` entries created with exact names\n- \u2705 No missing tables from assignment\n- \u2705 All models have proper structure\n- \u2705 Foreign keys reference existing tables correctly\n\n## \uD83C\uDFAF CLEAR EXAMPLES\n\n### Example Input\n```typescript\nconst targetComponent: AutoBePrisma.IComponent = {\n  filename: \"schema-02-sales.prisma\",\n  namespace: \"Sales\", \n  tables: [\"shopping_goods\", \"shopping_goods_options\"]\n};\nconst otherComponents: AutoBePrisma.IComponent[] = [\n  {\n    filename: \"schema-01-actors.prisma\", // ALREADY CREATED FILE\n    namespace: \"Actors\",\n    tables: [\"shopping_customers\", \"shopping_sellers\"] // ALREADY CREATED TABLES\n  }\n];\n```\n\n### \u2705 CORRECT OUTPUT\n```typescript\nmodels: [\n  { \n    name: \"shopping_goods\",\n    // ... fields and relationships\n  },\n  { \n    name: \"shopping_goods_options\", \n    // ... fields and relationships\n  }\n]\n```\n\n**Why this is correct:**\n- \u2705 Created `shopping_goods` (from targetComponent.tables)\n- \u2705 Created `shopping_goods_options` (from targetComponent.tables)  \n- \u2705 Total: 2 models = targetComponent.tables.length\n- \u2705 Can reference `shopping_customers` via foreign key (ALREADY EXISTS in otherComponents)\n\n### \u274C COMMON MISTAKE\n```typescript\nmodels: [\n  { name: \"shopping_customers\" }, // \u274C ALREADY CREATED in otherComponents!\n  { name: \"shopping_sellers\" }    // \u274C ALREADY CREATED in otherComponents!\n]\n```\n\n**Why this is wrong:**\n- \u274C Created tables from otherComponents that are ALREADY CREATED\n- \u274C Missing required tables from targetComponent.tables\n- \u274C Completely ignored the actual assignment\n- \u274C Duplicated already existing tables\n\n## \uD83D\uDD27 TECHNICAL SPECIFICATIONS\n\n### Default Working Language: English\n\n- Use the language specified by user in messages as the working language when explicitly provided\n- All thinking and responses must be in the working language\n- All model/field names must be in English regardless of working language\n\n### Normalization Requirements\n\n#### First Normal Form (1NF)\n- Each field contains atomic values only\n- No repeating groups or arrays in regular tables\n- Each row must be unique\n\n#### Second Normal Form (2NF)\n- Must be in 1NF\n- All non-key attributes fully depend on the entire primary key\n- No partial dependencies on composite keys\n\n#### Third Normal Form (3NF)\n- Must be in 2NF\n- No transitive dependencies\n- All non-key attributes depend only on the primary key\n\n#### Denormalization Rules\n- **ONLY allowed in materialized views** with `mv_` prefix\n- Regular business tables MUST remain fully normalized\n- Pre-calculated totals, counts, summaries \u2192 `mv_` tables only\n- Cached data for performance \u2192 `mv_` tables only\n- Redundant data for reporting \u2192 `mv_` tables only\n\n### Input Format\nYou will receive:\n1. **User requirements specification** - Detailed business requirements document\n2. **AutoBePrisma types** - Structured interfaces for schema generation\n3. **Context information in messages** - Structured as `AutoBePrisma.IComponent` objects:\n   - **Target Component** - Your assignment (create these tables)\n   - **Other Components** - Already created tables (use for foreign keys only)\n\n### Schema Design Guidelines\n\n#### Naming Conventions\n- **Models**: Use exact names from `targetComponent.tables` (NO CHANGES)\n- **Fields**: `snake_case` (e.g., `created_at`, `user_id`, `shopping_customer_id`)  \n- **Relations**: `snake_case` (e.g., `customer`, `order_items`, `user_profile`)\n- **Foreign Keys**: `{target_model_name}_id` pattern (e.g., `shopping_customer_id`, `bbs_article_id`)\n- **Materialized Views**: `mv_` prefix (e.g., `mv_shopping_sale_last_snapshots`)\n\n#### File Organization Principles\n- Organize by business domains (8-10 files typical)\n- Follow dependency order in numbering: `schema-{number}-{domain}.prisma`\n- Common domains: Systematic, Actors, Sales, Carts, Orders, Coupons, Coins, Inquiries, Favorites, Articles\n- Each file should contain 3-15 related models\n\n#### Data Type Mapping\n- **Primary Keys**: Always `\"uuid\"` type\n- **Foreign Keys**: Always `\"uuid\"` type  \n- **Timestamps**: Use `\"datetime\"` type\n- **Monetary Values**: Use `\"double\"` type\n- **Quantities/Counts**: Use `\"int\"` type\n- **Text Content**: Use `\"string\"` type\n- **URLs/Links**: Use `\"uri\"` type\n- **Flags/Booleans**: Use `\"boolean\"` type\n- **Dates Only**: Use `\"date\"` type (rare)\n\n#### Prohibited Field Types in Regular Tables\n**NEVER include these in regular business tables:**\n- Pre-calculated totals (e.g., `total_amount`, `item_count`)\n- Cached values (e.g., `last_purchase_date`, `total_spent`)\n- Aggregated data (e.g., `average_rating`, `review_count`)\n- Derived values (e.g., `full_name` from first/last name)\n- Summary fields (e.g., `order_summary`, `customer_status`)\n\n**These belong ONLY in `mv_` materialized views!**\n\n#### Description Writing Standards\n\nEach description MUST include:\n\n1. **Requirements Mapping**: Which specific requirement from the requirements analysis this implements\n2. **Business Purpose**: What business problem this solves in simple, understandable language\n3. **Technical Context**: How it relates to other models and system architecture\n4. **Normalization Compliance**: How this maintains normalized structure\n5. **Usage Examples**: Clear examples of how this will be used\n6. **Behavioral Notes**: Important constraints, rules, or special behaviors\n\n**Model Description Format:**\n```\n\"[Model Purpose] - This implements the [specific requirement] from the requirements document. \n\n[Business explanation in simple terms]. Maintains [normalization level] compliance by [explanation]. For example, [concrete usage example].\n\nKey relationships: [important connections to other models].\nSpecial behaviors: [any important constraints or rules].\"\n```\n\n**Field Description Format:**\n```\n\"[Field purpose] - Implements the [requirement aspect]. \n\n[Business meaning]. Ensures normalization by [explanation]. For example, [usage example].\n[Any constraints or special behaviors].\"\n```\n\n#### Relationship Design Patterns\n- **1:1 Relationships**: Set `unique: true` on foreign key\n- **1:N Relationships**: Set `unique: false` on foreign key  \n- **M:N Relationships**: Create junction tables with composite keys\n- **Self-References**: Use `parent_id` field name\n- **Snapshot Relationships**: Link current entity to its snapshot history\n- **Optional Relationships**: Set `nullable: true` when relationship is optional\n\n**Junction Table Guidelines:**\n- Name pattern: `{table1}_{table2}` (alphabetical order preferred)\n- Always include composite primary key from both foreign keys\n- Include `created_at` timestamp for audit trail\n- May include additional attributes specific to the relationship\n\n#### Materialized View Patterns\n- Set `material: true` for computed/cached tables\n- Prefix names with `mv_`\n- Common patterns: `mv_*_last_snapshots`, `mv_*_prices`, `mv_*_balances`, `mv_*_inventories`\n- **ONLY place for denormalized data**\n- **ONLY place for pre-calculated fields**\n- **ONLY place for aggregated values**\n\n#### Index Strategy\n- **NO single foreign key indexes** - Prisma auto-creates these\n- **Composite indexes OK** - Include foreign keys with other fields for query patterns\n- **Unique indexes**: For business constraints (emails, codes, composite keys)\n- **Performance indexes**: For common query patterns (timestamps, search fields)\n- **GIN indexes**: For full-text search on string fields\n\n### Requirements Analysis Process\n\n#### 1. Assignment Validation (FIRST PRIORITY)\n- Extract `targetComponent.tables` - This is your complete specification\n- Count required tables: `targetComponent.tables.length`\n- Identify domain: `targetComponent.namespace`\n- Note already created tables from `otherComponents[]` for foreign keys\n\n#### 2. Domain Understanding\n- Understand the business domain from `targetComponent.namespace`\n- Analyze how your tables fit within the overall system\n- Plan relationships with already created tables from other components\n\n#### 3. Entity Extraction\n- Extract all business entities from `targetComponent.tables`\n- Identify main entities vs snapshot entities vs junction tables\n- Determine materialized views needed for performance\n- **Separate normalized entities from denormalized reporting needs**\n\n#### 4. Relationship Mapping\n- Map all relationships between entities within your domain\n- Identify relationships to already created tables (foreign keys only)\n- Determine cardinality (1:1, 1:N, M:N)\n- Determine optional vs required relationships\n- **Ensure relationships maintain normalization**\n\n#### 5. Attribute Analysis\n- Extract all data attributes from requirements for your domain\n- Determine data types and constraints\n- Identify nullable vs required fields\n- **Separate atomic data from calculated data**\n\n#### 6. Business Rule Implementation\n- Identify unique constraints from business rules within your domain\n- Determine audit trail requirements (snapshot pattern)\n- Map performance requirements to indexes\n- **Map denormalization needs to materialized views**\n\n### MANDATORY REVIEW PROCESS\n\n#### Pre-Output Validation Checklist\n\n**ALWAYS perform this comprehensive review before generating the function call:**\n\n1. **Component Compliance Validation**\n   - All models from `targetComponent.tables` are included\n   - No models from `otherComponents[].tables` are created\n   - Additional tables are only for M:N relationships within domain\n   - All model names are exact matches to `targetComponent.tables`\n\n2. **Normalization Validation**\n   - All regular tables comply with 3NF minimum\n   - No calculated fields in regular business tables\n   - All denormalized data is in `mv_` tables only\n   - No transitive dependencies in regular tables\n\n3. **Model Validation**\n   - All model names are unique within the schema\n   - All models have exactly one primary key field named \"id\" of type \"uuid\"\n   - All materialized views have `material: true` and \"mv_\" prefix\n   - Regular tables contain only atomic, normalized data\n\n4. **Field Validation**  \n   - No duplicate field names within any model\n   - All foreign key fields follow `{target_model}_id` pattern\n   - All foreign key fields have type \"uuid\"\n   - All field descriptions map to specific requirements\n   - **NO calculated fields in regular tables**\n\n5. **Relationship Validation**\n   - All foreign fields have corresponding relation definitions\n   - Target models exist in the schema structure or `otherComponents`\n   - No duplicate relation names within any model\n   - Cardinality correctly reflected in `unique` property\n\n6. **Index Validation**\n   - No single foreign key indexes in plain or unique indexes\n   - All composite indexes serve clear query patterns\n   - All referenced field names exist in their models\n   - GIN indexes only on string type fields\n\n#### Quality Assurance Questions\n\nBefore finalizing, verify:\n- Does each model clearly implement a specific business requirement?\n- Are all relationships bidirectionally consistent?\n- Do all descriptions provide clear requirement traceability?\n- Are naming conventions consistently applied?\n- Is the snapshot architecture properly implemented?\n- Are all business constraints captured in unique indexes?\n- **Is every regular table properly normalized?**\n- **Are ALL calculated/aggregated fields in `mv_` tables only?**\n- **Are ALL required tables from `targetComponent.tables` created?**\n- **Are ZERO tables from `otherComponents[].tables` created?**\n\n### Expected Output\n\nGenerate a single function call using the AutoBePrisma.IMakePrismaSchemaFileProps structure:\n\n```typescript\n// Function call format\n{\n  tablesToCreate: string[];           // Step 1: List tables from targetComponent.tables\n  validationReview: string;           // Step 2: Validate against requirements\n  confirmedTables: string[];          // Step 3: Final confirmed list\n  models: AutoBePrisma.IModel[];      // Step 4: Create models\n}\n```\n\n## \uD83C\uDFAF FINAL SUCCESS CHECKLIST\n\n**Before generating output, verify:**\n- \u2705 Created model for every table in `targetComponent.tables`\n- \u2705 Model count matches `targetComponent.tables.length` (plus junction tables if needed)\n- \u2705 All model names are EXACT matches to `targetComponent.tables` entries\n- \u2705 All models have proper structure (id, fields, relationships)\n- \u2705 Foreign keys reference already created tables correctly\n- \u2705 No duplicate models or fields\n- \u2705 Proper normalization maintained\n- \u2705 **ALL REGULAR TABLES FULLY NORMALIZED (3NF minimum)**\n- \u2705 **NO PRE-CALCULATED FIELDS IN REGULAR TABLES**\n- \u2705 **ALL DENORMALIZATION IN `mv_` TABLES ONLY**\n- \u2705 **NO TABLES FROM `otherComponents[].tables` CREATED**\n- \u2705 **COMPREHENSIVE VALIDATION COMPLETED**\n\n### Task: Generate Structured Prisma Schema Definition\n\nTransform user requirements into a complete AutoBePrisma.IMakePrismaSchemaFileProps structure that implements the 4-step validation process:\n\n1. **tablesToCreate**: List all tables from `targetComponent.tables`\n2. **validationReview**: Validate against requirements and component boundaries  \n3. **confirmedTables**: Final confirmed list after validation\n4. **models**: Create models for each confirmed table\n\n**\uD83C\uDFAF REMEMBER: Your job is to create exactly the tables specified in `targetComponent.tables` with their exact names - nothing more, nothing less!**" /* AutoBeSystemPromptConstant.PRISMA_SCHEMA */,
         },
-        // {
-        //   id: v4(),
-        //   created_at: new Date().toISOString(),
-        //   type: "systemMessage",
-        //   text: [
-        //     "Before making prisma schema files,",
-        //     "learn about the prisma schema language",
-        //     "from the best practices and examples",
-        //     "",
-        //     AutoBeSystemPromptConstant.PRISMA_EXAMPLE,
-        //   ].join("\n"),
-        // },
         {
             id: (0, uuid_1.v4)(),
             created_at: new Date().toISOString(),
-            type: "systemMessage",
+            type: "assistantMessage",
             text: [
-                "Here is the requirement analysis report.",
-                "",
-                "Call the provided tool function to generate Prisma DB schema",
-                "referencing below requirement analysis report.",
+                "Here is the input data for generating Prisma DB schema.",
                 "",
-                "## User Request",
-                analyze.reason,
-                "",
-                `## Requirement Analysis Report`,
+                "```",
+                JSON.stringify({
+                    requirementAnalysisReport,
+                    otherComponents,
+                    targetComponent,
+                }),
+                "```",
+            ].join("\n"),
+        },
+        {
+            id: (0, uuid_1.v4)(),
+            created_at: new Date().toISOString(),
+            type: "systemMessage",
+            text: [
+                "You've already taken a mistake that creating models from the other components.",
+                "Note that, you have to make models from the target component only. Never make",
+                "models from the other components. The other components' models are already made.",
                 "",
                 "```json",
-                JSON.stringify(analyze.files),
+                JSON.stringify({
+                    targetComponent,
+                }),
                 "```",
-                "",
-                "## Context",
-                "",
-                `  - Target filename: ${component.filename}`,
-                `  - Tables what you have to make:`,
-                ...component.tables.map((table) => `    - ${table}`),
-                `  - Entire tables you can reference:`,
-                ...component.entireTables.map((table) => `    - ${table}`),
             ].join("\n"),
         },
     ];

package/lib/orchestrate/prisma/transformPrismaSchemaHistories.js.map

@@ -1 +1 @@
-{"version":3,"file":"transformPrismaSchemaHistories.js","sourceRoot":"","sources":["../../../src/orchestrate/prisma/transformPrismaSchemaHistories.ts"],"names":[],"mappings":";;;AAEA,+BAA0B;AAInB,MAAM,8BAA8B,GAAG,CAC5C,OAA6B,EAC7B,SAIC,EAGD,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,8oWAA0C;SAC/C;QACD,IAAI;QACJ,cAAc;QACd,0CAA0C;QAC1C,2BAA2B;QAC3B,YAAY;QACZ,4CAA4C;QAC5C,gDAAgD;QAChD,8CAA8C;QAC9C,UAAU;QACV,iDAAiD;QACjD,kBAAkB;QAClB,KAAK;QACL;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,EAAE;gBACJ,0CAA0C;gBAC1C,EAAE;gBACF,8DAA8D;gBAC9D,gDAAgD;gBAChD,EAAE;gBACF,iBAAiB;gBACjB,OAAO,CAAC,MAAM;gBACd,EAAE;gBACF,gCAAgC;gBAChC,EAAE;gBACF,SAAS;gBACT,IAAI,CAAC,SAAS,CAAC,OAAO,CAAC,KAAK,CAAC;gBAC7B,KAAK;gBACL,EAAE;gBACF,YAAY;gBACZ,EAAE;gBACF,wBAAwB,SAAS,CAAC,QAAQ,EAAE;gBAC5C,mCAAmC;gBACnC,GAAG,SAAS,CAAC,MAAM,CAAC,GAAG,CAAC,CAAC,KAAK,EAAE,EAAE,CAAC,SAAS,KAAK,EAAE,CAAC;gBACpD,sCAAsC;gBACtC,GAAG,SAAS,CAAC,YAAY,CAAC,GAAG,CAAC,CAAC,KAAK,EAAE,EAAE,CAAC,SAAS,KAAK,EAAE,CAAC;aAC3D,CAAC,IAAI,CAAC,IAAI,CAAC;SACb;KACF,CAAC;AACJ,CAAC,CAAC;AA1DW,QAAA,8BAA8B,kCA0DzC"}
+{"version":3,"file":"transformPrismaSchemaHistories.js","sourceRoot":"","sources":["../../../src/orchestrate/prisma/transformPrismaSchemaHistories.ts"],"names":[],"mappings":";;;AAEA,+BAA0B;AAInB,MAAM,8BAA8B,GAAG,CAC5C,yBAAiD,EACjD,eAAwC,EACxC,eAA0C,EAG1C,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,q/hBAA0C;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;gBACJ,yDAAyD;gBACzD,EAAE;gBACF,KAAK;gBACL,IAAI,CAAC,SAAS,CAAC;oBACb,yBAAyB;oBACzB,eAAe;oBACf,eAAe;iBAChB,CAAC;gBACF,KAAK;aACN,CAAC,IAAI,CAAC,IAAI,CAAC;SACb;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,EAAE;gBACJ,gFAAgF;gBAChF,+EAA+E;gBAC/E,kFAAkF;gBAClF,EAAE;gBACF,SAAS;gBACT,IAAI,CAAC,SAAS,CAAC;oBACb,eAAe;iBAChB,CAAC;gBACF,KAAK;aACN,CAAC,IAAI,CAAC,IAAI,CAAC;SACb;KACF,CAAC;AACJ,CAAC,CAAC;AA/CW,QAAA,8BAA8B,kCA+CzC"}

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

@@ -0,0 +1,5 @@
+import { FAILED } from "./structures/IAutoBeRealizeFailedSymbol";
+export declare function pipe<A, B>(a: A, ab: (a: A) => Promise<B | FAILED>): Promise<B | FAILED>;
+export declare function pipe<A, B, C>(a: A, ab: (a: A) => Promise<B | FAILED>, bc: (b: B) => Promise<C | FAILED>): Promise<C | FAILED>;
+export declare function pipe<A, B, C, D>(a: A, ab: (a: A) => Promise<B | FAILED>, bc: (b: B) => Promise<C | FAILED>, cd: (c: C) => Promise<D | FAILED>): Promise<D | FAILED>;
+export declare function pipe<A, B, C, D, E>(a: A, ab: (a: A) => Promise<B | FAILED>, bc: (b: B) => Promise<C | FAILED>, cd: (c: C) => Promise<D | FAILED>, de: (d: D) => Promise<E | FAILED>): Promise<E | FAILED>;

package/lib/orchestrate/realize/RealizePipe.js

@@ -0,0 +1,14 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.pipe = pipe;
+const IAutoBeRealizeFailedSymbol_1 = require("./structures/IAutoBeRealizeFailedSymbol");
+function pipe(a, ...fns) {
+    return fns.reduce((prev, fn) => {
+        return prev.then((result) => {
+            if (result === IAutoBeRealizeFailedSymbol_1.FAILED)
+                return IAutoBeRealizeFailedSymbol_1.FAILED;
+            return fn(result);
+        });
+    }, Promise.resolve(a));
+}
+//# sourceMappingURL=RealizePipe.js.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"RealizePipe.js","sourceRoot":"","sources":["../../../src/orchestrate/realize/RealizePipe.ts"],"names":[],"mappings":";;AA4BA,oBAUC;AAtCD,wFAAiE;AA4BjE,SAAgB,IAAI,CAClB,CAAM,EACN,GAAG,GAAsC;IAEzC,OAAO,GAAG,CAAC,MAAM,CAAC,CAAC,IAAI,EAAE,EAAE,EAAE,EAAE;QAC7B,OAAO,IAAI,CAAC,IAAI,CAAC,CAAC,MAAM,EAAE,EAAE;YAC1B,IAAI,MAAM,KAAK,mCAAM;gBAAE,OAAO,mCAAM,CAAC;YACrC,OAAO,EAAE,CAAC,MAAM,CAAC,CAAC;QACpB,CAAC,CAAC,CAAC;IACL,CAAC,EAAE,OAAO,CAAC,OAAO,CAAC,CAAC,CAAC,CAAC,CAAC;AACzB,CAAC"}

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

@@ -3,9 +3,3 @@ import { ILlmSchema } from "@samchon/openapi";
 import { AutoBeContext } from "../../context/AutoBeContext";
 import { IAutoBeApplicationProps } from "../../context/IAutoBeApplicationProps";
 export declare const orchestrateRealize: <Model extends ILlmSchema.Model>(ctx: AutoBeContext<Model>) => (props: IAutoBeApplicationProps) => Promise<AutoBeAssistantMessageHistory | AutoBeRealizeHistory>;
-export declare const FAILED: unique symbol;
-export type FAILED = typeof FAILED;
-export declare function pipe<A, B>(a: A, ab: (a: A) => Promise<B | FAILED>): Promise<B | FAILED>;
-export declare function pipe<A, B, C>(a: A, ab: (a: A) => Promise<B | FAILED>, bc: (b: B) => Promise<C | FAILED>): Promise<C | FAILED>;
-export declare function pipe<A, B, C, D>(a: A, ab: (a: A) => Promise<B | FAILED>, bc: (b: B) => Promise<C | FAILED>, cd: (c: C) => Promise<D | FAILED>): Promise<D | FAILED>;
-export declare function pipe<A, B, C, D>(a: A, ab: (a: A) => Promise<B | FAILED>, bc: (b: B) => Promise<C | FAILED>, cd: (c: C) => Promise<D | FAILED>): Promise<D | FAILED>;

package/lib/orchestrate/realize/orchestrateRealize.js

@@ -9,44 +9,17 @@ var __awaiter = (this && this.__awaiter) || function (thisArg, _arguments, P, ge
     });
 };
 Object.defineProperty(exports, "__esModule", { value: true });
-exports.FAILED = exports.orchestrateRealize = void 0;
-exports.pipe = pipe;
+exports.orchestrateRealize = void 0;
 const uuid_1 = require("uuid");
-const orchestrateRealizeCoder_1 = require("./orchestrateRealizeCoder");
-const orchestrateRealizePlanner_1 = require("./orchestrateRealizePlanner");
+const writeCodeUntilCompilePassed_1 = require("./writeCodeUntilCompilePassed");
 const orchestrateRealize = (ctx) => (props) => __awaiter(void 0, void 0, void 0, function* () {
-    var _a, _b, _c, _d, _e;
+    var _a, _b, _c;
     props;
     const ops = (_a = ctx.state().interface) === null || _a === void 0 ? void 0 : _a.document.operations;
     if (!ops) {
-        throw new Error();
-    }
-    const files = Object.assign(Object.assign({}, (_b = ctx.state().interface) === null || _b === void 0 ? void 0 : _b.files), (_c = ctx.state().test) === null || _c === void 0 ? void 0 : _c.files.reduce((acc, file) => {
-        acc[file.location] = file.content;
-        return acc;
-    }, {}));
-    const codes = yield Promise.all(ops.map((op) => __awaiter(void 0, void 0, void 0, function* () {
-        return ({
-            operation: op,
-            result: yield pipe(op, (op) => (0, orchestrateRealizePlanner_1.orchestrateRealizePlanner)(ctx, op), (p) => (0, orchestrateRealizeCoder_1.orchestrateRealizeCoder)(ctx, op, p, files)),
-        });
-    })));
-    const successes = [];
-    const failures = [];
-    for (const code of codes) {
-        if (code.result === exports.FAILED) {
-            failures.push({
-                operation: code.operation,
-                result: code.result,
-            });
-        }
-        else {
-            successes.push({
-                operation: code.operation,
-                result: code.result,
-            });
-        }
+        throw new Error("Can't do realize agent because operations are nothing.");
     }
+    yield (0, writeCodeUntilCompilePassed_1.writeCodeUntilCompilePassed)(ctx, ops, 3);
     const now = new Date().toISOString();
     ctx.dispatch({
         type: "assistantMessage",
@@ -61,18 +34,8 @@ const orchestrateRealize = (ctx) => (props) => __awaiter(void 0, void 0, void 0,
         created_at: now,
         id: (0, uuid_1.v4)(),
         reason: props.reason,
-        step: (_e = (_d = ctx.state().test) === null || _d === void 0 ? void 0 : _d.step) !== null && _e !== void 0 ? _e : 0,
+        step: (_c = (_b = ctx.state().test) === null || _b === void 0 ? void 0 : _b.step) !== null && _c !== void 0 ? _c : 0,
     };
 });
 exports.orchestrateRealize = orchestrateRealize;
-exports.FAILED = Symbol("FAILED");
-function pipe(a, ...fns) {
-    return fns.reduce((prev, fn) => {
-        return prev.then((result) => {
-            if (result === exports.FAILED)
-                return exports.FAILED;
-            return fn(result);
-        });
-    }, Promise.resolve(a));
-}
 //# sourceMappingURL=orchestrateRealize.js.map

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

@@ -1 +1 @@
-{"version":3,"file":"orchestrateRealize.js","sourceRoot":"","sources":["../../../src/orchestrate/realize/orchestrateRealize.ts"],"names":[],"mappings":";;;;;;;;;;;;AAsHA,oBAUC;AA1HD,+BAA0B;AAI1B,uEAAoE;AACpE,2EAAwE;AAGjE,MAAM,kBAAkB,GAC7B,CAAiC,GAAyB,EAAE,EAAE,CAC9D,CACE,KAA8B,EACiC,EAAE;;IACjE,KAAK,CAAC;IACN,MAAM,GAAG,GAAG,MAAA,GAAG,CAAC,KAAK,EAAE,CAAC,SAAS,0CAAE,QAAQ,CAAC,UAAU,CAAC;IACvD,IAAI,CAAC,GAAG,EAAE,CAAC;QACT,MAAM,IAAI,KAAK,EAAE,CAAC;IACpB,CAAC;IAED,MAAM,KAAK,mCACN,MAAA,GAAG,CAAC,KAAK,EAAE,CAAC,SAAS,0CAAE,KAAK,GAC5B,MAAA,GAAG,CAAC,KAAK,EAAE,CAAC,IAAI,0CAAE,KAAK,CAAC,MAAM,CAC/B,CAAC,GAAG,EAAE,IAAI,EAAE,EAAE;QACZ,GAAG,CAAC,IAAI,CAAC,QAAQ,CAAC,GAAG,IAAI,CAAC,OAAO,CAAC;QAClC,OAAO,GAAG,CAAC;IACb,CAAC,EACD,EAA4B,CAC7B,CACF,CAAC;IAEF,MAAM,KAAK,GACT,MAAM,OAAO,CAAC,GAAG,CACf,GAAG,CAAC,GAAG,CAAC,CAAO,EAAE,EAAE,EAAE;QAAC,OAAA,CAAC;YACrB,SAAS,EAAE,EAAE;YACb,MAAM,EAAE,MAAM,IAAI,CAChB,EAAE,EACF,CAAC,EAAE,EAAE,EAAE,CAAC,IAAA,qDAAyB,EAAC,GAAG,EAAE,EAAE,CAAC,EAC1C,CAAC,CAAC,EAAE,EAAE,CAAC,IAAA,iDAAuB,EAAC,GAAG,EAAE,EAAE,EAAE,CAAC,EAAE,KAAK,CAAC,CAClD;SACF,CAAC,CAAA;MAAA,CAAC,CACJ,CAAC;IAEJ,MAAM,SAAS,GAGV,EAAE,CAAC;IACR,MAAM,QAAQ,GAGT,EAAE,CAAC;IAER,KAAK,MAAM,IAAI,IAAI,KAAK,EAAE,CAAC;QACzB,IAAI,IAAI,CAAC,MAAM,KAAK,cAAM,EAAE,CAAC;YAC3B,QAAQ,CAAC,IAAI,CAAC;gBACZ,SAAS,EAAE,IAAI,CAAC,SAAS;gBACzB,MAAM,EAAE,IAAI,CAAC,MAAM;aACpB,CAAC,CAAC;QACL,CAAC;aAAM,CAAC;YACN,SAAS,CAAC,IAAI,CAAC;gBACb,SAAS,EAAE,IAAI,CAAC,SAAS;gBACzB,MAAM,EAAE,IAAI,CAAC,MAAM;aACpB,CAAC,CAAC;QACL,CAAC;IACH,CAAC;IAED,MAAM,GAAG,GAAG,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE,CAAC;IACrC,GAAG,CAAC,QAAQ,CAAC;QACX,IAAI,EAAE,kBAAkB;QACxB,IAAI,EAAE,iCAAiC;QACvC,UAAU,EAAE,GAAG;KAChB,CAAC,CAAC;IAEH,OAAO;QACL,IAAI,EAAE,SAAS;QACf,QAAQ,EAAE,CAAQ;QAClB,KAAK,EAAE,EAAE;QACT,YAAY,EAAE,GAAG;QACjB,UAAU,EAAE,GAAG;QACf,EAAE,EAAE,IAAA,SAAE,GAAE;QACR,MAAM,EAAE,KAAK,CAAC,MAAM;QACpB,IAAI,EAAE,MAAA,MAAA,GAAG,CAAC,KAAK,EAAE,CAAC,IAAI,0CAAE,IAAI,mCAAI,CAAC;KAClC,CAAC;AACJ,CAAC,CAAA,CAAC;AA1ES,QAAA,kBAAkB,sBA0E3B;AAES,QAAA,MAAM,GAAG,MAAM,CAAC,QAAQ,CAAC,CAAC;AA4BvC,SAAgB,IAAI,CAClB,CAAM,EACN,GAAG,GAAsC;IAEzC,OAAO,GAAG,CAAC,MAAM,CAAC,CAAC,IAAI,EAAE,EAAE,EAAE,EAAE;QAC7B,OAAO,IAAI,CAAC,IAAI,CAAC,CAAC,MAAM,EAAE,EAAE;YAC1B,IAAI,MAAM,KAAK,cAAM;gBAAE,OAAO,cAAM,CAAC;YACrC,OAAO,EAAE,CAAC,MAAM,CAAC,CAAC;QACpB,CAAC,CAAC,CAAC;IACL,CAAC,EAAE,OAAO,CAAC,OAAO,CAAC,CAAC,CAAC,CAAC,CAAC;AACzB,CAAC"}
+{"version":3,"file":"orchestrateRealize.js","sourceRoot":"","sources":["../../../src/orchestrate/realize/orchestrateRealize.ts"],"names":[],"mappings":";;;;;;;;;;;;AAKA,+BAA0B;AAI1B,+EAA4E;AAErE,MAAM,kBAAkB,GAC7B,CAAiC,GAAyB,EAAE,EAAE,CAC9D,CACE,KAA8B,EACiC,EAAE;;IACjE,KAAK,CAAC;IACN,MAAM,GAAG,GAAG,MAAA,GAAG,CAAC,KAAK,EAAE,CAAC,SAAS,0CAAE,QAAQ,CAAC,UAAU,CAAC;IACvD,IAAI,CAAC,GAAG,EAAE,CAAC;QACT,MAAM,IAAI,KAAK,CAAC,wDAAwD,CAAC,CAAC;IAC5E,CAAC;IAED,MAAM,IAAA,yDAA2B,EAAC,GAAG,EAAE,GAAG,EAAE,CAAC,CAAC,CAAC;IAC/C,MAAM,GAAG,GAAG,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE,CAAC;IACrC,GAAG,CAAC,QAAQ,CAAC;QACX,IAAI,EAAE,kBAAkB;QACxB,IAAI,EAAE,iCAAiC;QACvC,UAAU,EAAE,GAAG;KAChB,CAAC,CAAC;IAEH,OAAO;QACL,IAAI,EAAE,SAAS;QACf,QAAQ,EAAE,CAAQ;QAClB,KAAK,EAAE,EAAE;QACT,YAAY,EAAE,GAAG;QACjB,UAAU,EAAE,GAAG;QACf,EAAE,EAAE,IAAA,SAAE,GAAE;QACR,MAAM,EAAE,KAAK,CAAC,MAAM;QACpB,IAAI,EAAE,MAAA,MAAA,GAAG,CAAC,KAAK,EAAE,CAAC,IAAI,0CAAE,IAAI,mCAAI,CAAC;KAClC,CAAC;AACJ,CAAC,CAAA,CAAC;AA7BS,QAAA,kBAAkB,sBA6B3B"}

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

@@ -1,9 +1,9 @@
-import { AutoBeOpenApi } from "@autobe/interface";
+import { AutoBeOpenApi, IAutoBeTypeScriptCompileResult } from "@autobe/interface";
 import { ILlmSchema } from "@samchon/openapi";
 import { AutoBeContext } from "../../context/AutoBeContext";
-import { FAILED } from "./orchestrateRealize";
 import { RealizePlannerOutput } from "./orchestrateRealizePlanner";
 import { IAutoBeRealizeCoderApplication } from "./structures/IAutoBeRealizeCoderApplication";
+import { FAILED } from "./structures/IAutoBeRealizeFailedSymbol";
 /**
  * Generates a TypeScript function implementation based on the given plan.
  *
@@ -22,4 +22,4 @@ import { IAutoBeRealizeCoderApplication } from "./structures/IAutoBeRealizeCoder
  * @param props - Planning result describing what function to generate
  * @returns The generated function name and TypeScript code
  */
-export declare const orchestrateRealizeCoder: <Model extends ILlmSchema.Model>(ctx: AutoBeContext<Model>, operation: AutoBeOpenApi.IOperation, props: RealizePlannerOutput, files: Record<string, string>) => Promise<IAutoBeRealizeCoderApplication.RealizeCoderOutput | FAILED>;
+export declare const orchestrateRealizeCoder: <Model extends ILlmSchema.Model>(ctx: AutoBeContext<Model>, operation: AutoBeOpenApi.IOperation, props: RealizePlannerOutput, previous: string | null, total: IAutoBeTypeScriptCompileResult.IDiagnostic[], diagnostics: IAutoBeTypeScriptCompileResult.IDiagnostic[]) => Promise<Pick<IAutoBeRealizeCoderApplication.RealizeCoderOutput, "filename" | "implementationCode"> | FAILED>;