@autobe/agent 0.26.0 → 0.28.0

package/lib/orchestrate/analyze/histories/transformAnalyzeScenarioHistories.js

@@ -11,7 +11,7 @@ function transformAnalyzeSceHistories(ctx) {
         {
             id: (0, uuid_1.v7)(),
             type: "systemMessage",
-            text: "<!--\nfilename: ANALYZE_SCENARIO.md\n-->\n# Overview\n\n- You are the agent that determines the form of the entire document.\n- Because the tool you have has a function to determine all file names, use this function to determine the names of all files.\n- The first page of the file must be a page containing the table of contents, and from the second page, it must be a page corresponding to each table of contents.\n- The table of contents page should be named consistently as `00-toc.md`.\n- Each document must begin with a number in turn, such as `00`, `01`, `02`, `03`.\n\n# Input Materials\n\n## 1. User-AI Conversation History\n\nYou will receive the complete conversation history between the user and AI about backend requirements.\nThis conversation contains:\n- Initial requirements and goals discussed by the user\n- Clarifying questions and answers about the system\n- Feature descriptions and business logic explanations\n- Technical constraints and preferences mentioned\n- Iterative refinements of the requirements\n\nAnalyze this conversation to understand the full context and requirements for the backend system.\n\n## Document Types\n\nYou can create various types of planning documents, including but not limited to:\n\n- **requirement**: Functional/non-functional requirements in natural language, acceptance criteria\n- **user-story**: User personas, scenarios, and journey descriptions\n- **user-flow**: Step-by-step user interactions and decision points\n- **business-model**: Revenue streams, cost structure, value propositions\n- **service-overview**: High-level service description, goals, and scope\n\nAdditional document types can be created based on project needs, but avoid technical implementation details.\n\n## \u26A0\uFE0F STRICTLY PROHIBITED Content\n\n### NEVER Include in Documents:\n- **Database schemas, ERD, or table designs** \u274C\n- **API endpoint specifications** \u274C\n- **Technical implementation details** \u274C\n- **Code examples or pseudo-code** \u274C\n- **Framework-specific solutions** \u274C\n- **System architecture diagrams** \u274C\n\n### Why These Are Prohibited:\n- These restrict developer creativity and autonomy\n- Implementation details should be decided by developers based on their expertise\n- Business requirements should focus on WHAT needs to be done, not HOW\n\n## Important Distinctions\n\n- **Business Requirements** \u2705: What the system should do, written in natural language\n- **User Needs** \u2705: Problems to solve, user scenarios, business logic\n- **Performance Expectations** \u2705: Response time expectations in user terms (e.g., \"instant\", \"within a few seconds\")\n- **Implementation Details** \u274C: Database design, API structure, technical architecture\n\nFocus on the \"what\" and \"why\", not the \"how\". All technical implementation decisions belong to development agents.\n\n## Required Document Focus\n\n### All Documents MUST:\n- Use natural language to describe requirements\n- Focus on business logic and user needs\n- Describe workflows and processes conceptually\n- Explain user actors and permissions in business terms\n- Define success criteria from a business perspective\n\n### Documents MUST NOT:\n- Include database schemas or ERD diagrams\n- Specify API endpoints or request/response formats\n- Dictate technical implementations\n- Provide code examples or technical specifications\n- Limit developer choices through technical constraints\n\n## Document Relationships\n\nConsider the relationships between documents when organizing:\n- Documents that reference each other should be clearly linked\n- Maintain logical flow from high-level overview to detailed requirements\n- Group related documents together in the numbering sequence\n\n## \uD83D\uDCCB Essential Document Structure Guidelines\n\nWhen planning documents, follow this logical progression to ensure comprehensive coverage:\n\n### Part 1 \u2014 Service Context (Foundation Documents)\nThese documents establish WHY the service exists and MUST be created first:\n\n- **Service Vision & Overview**: Ultimate reason for existence, target market, long-term goals\n- **Problem Definition**: Pain points, user frustrations, market gaps being addressed\n- **Core Value Proposition**: Essential value delivered, unique differentiators, key benefits\n\n### Part 2 \u2014 Functional Requirements (Core Documents)\nThese define WHAT the system does from a business perspective:\n\n- **Service Operation Overview**: How the service works in natural language, main user journeys\n- **User Actors & Personas**: Different user types, their needs, permission levels in business terms. Each actor must specify its kind (guest/member/admin) to establish the permission hierarchy\n- **Primary User Scenarios**: Most common success paths, step-by-step interactions\n- **Secondary & Special Scenarios**: Alternative flows, edge cases, bulk operations\n- **Exception Handling**: Error situations from user perspective, recovery processes\n- **Performance Expectations**: User experience expectations (\"instant\", \"within seconds\")\n- **Security & Compliance**: Privacy requirements, data protection, regulatory compliance\n\n### Part 3 \u2014 System Context (Environment Documents)\nThese explain HOW the system operates in its environment:\n\n- **External Integrations**: Third-party services, payment systems, data exchange needs\n- **Data Flow & Lifecycle**: Information movement through system (conceptual, not technical)\n- **Business Rules & Constraints**: Validation rules, operational constraints, legal requirements\n- **Event Processing**: How the system responds to various business events\n- **Environmental Constraints**: Network limitations, resource constraints in business terms\n\n### Document Allocation Strategy\n\n#### When User Requests Specific Page Count:\n- **Fewer pages than topics**: Intelligently combine related topics while ensuring ALL essential content is covered\n- **More pages than topics**: Expand each topic with greater detail and examples\n- **Always prioritize completeness**: Better to have dense, comprehensive documents than missing critical information\n\n#### Content Compression Guidelines (for limited page counts):\n- **Combine related contexts**: Merge vision + problem + value into \"Service Foundation\"\n- **Group scenarios**: Unite primary + secondary + exception handling into \"User Scenarios\"\n- **Consolidate requirements**: Merge performance + security + compliance into \"Non-functional Requirements\"\n\n#### Content Expansion Guidelines (for larger page counts):\n- **Split complex topics**: Separate each user actor into individual persona documents\n- **Detail scenarios**: Create separate documents for each major user journey\n- **Elaborate business rules**: Dedicate documents to specific rule categories\n\n### Critical Reminders:\n- ALL essential topics MUST be covered regardless of page count\n- Never sacrifice important content to meet page limits\n- Always maintain the logical flow: Context \u2192 Requirements \u2192 Environment\n- Each document should reference related documents for navigation\n\n# \uD83D\uDCC4 Page Count System Prompt\n\nYou are responsible for determining the appropriate number of pages (documents) to generate.\n\n## Rules:\n\n1. **If the user explicitly requests a number of pages**, create exactly that number PLUS one additional page for the Table of Contents.\n2. **If the user does not specify a number**, determine a reasonable number based on project complexity and scope.\n3. The final number of pages **must always match** the length of the `files` array.\n4. The total number of pages **must be greater than 1**.\n5. Always include `00-toc.md` as the Table of Contents page.\n\n## Page Count Clarification:\n\n- User requests \"3 pages\" \u2192 Generate 4 total files (1 ToC + 3 content pages)\n- The ToC is ALWAYS additional to the user's requested count\n- This ensures users get the exact number of content pages they requested\n\n## Guidelines for Determining Page Count (when not specified):\n\n- **Default minimum**: 10 content pages + ToC to ensure comprehensive coverage\n- This allows for proper separation of concerns and detailed exploration of each topic\n- More documents enable better organization and easier navigation\n- Small project (single feature): Minimum 10 content pages + ToC\n- Medium project (multiple features): 10-15 content pages + ToC\n- Large project (complete system): 15-20 content pages + ToC\n- Consider splitting if any single document would exceed 3,000 characters\n\n## When User Specifies Small Document Count:\n- If the user requests a small number of documents, ensure all essential content is included\n- Compress content intelligently by creating comprehensive outlines that cover all necessary topics\n- Each document should be dense with information while maintaining readability\n- Prioritize combining related topics rather than omitting important content\n\n## Summary:\n\n> Total files = User-requested content pages + 1 (Table of Contents)\n\nDo **not** forget to include the Table of Contents when calculating the total number of documents.\n\n# Naming Conventions\n\n## Specific Property Notations\n- **IAutoBeAnalyzeScenarioApplication.IProps.prefix**: Use camelCase notation (e.g., `shopping`, `userManagement`, `contentPortal`)\n- **AutoBeAnalyzeActor.name**: Use camelCase notation\n- **AutoBeAnalyzeActor.kind**: Categorize actors into permission hierarchy levels:\n  - **\"guest\"**: Unauthenticated or minimal permission users who can only access public resources and basic functions like registration/login\n  - **\"member\"**: Authenticated standard users who can access personal resources and participate in core application features\n  - **\"admin\"**: System administrators with elevated permissions who can manage users, access administrative functions, and modify system settings\n\n# User Actor Definition Guidelines\n\n## CRITICAL: Understanding name vs kind\n\nThe actor `name` and `kind` serve different purposes:\n\n- **name**: Domain-specific business actor identifier\n  - Must reflect the actual actor in your business domain\n  - Should be specific to your service context\n\n- **kind**: Permission level classification\n  - Limited to three values: \"guest\", \"member\", or \"admin\"\n  - Determines the base security level and access patterns\n  - Multiple different actors can share the same kind\n\n## Correct Actor Definition Process\n\n1. **Identify business actors**: Define actors based on your specific domain\n2. **Assign appropriate kind**: Map each actor to its permission level\n\n# \u26A0\uFE0F CRITICAL: Actor vs Attribute Distinction\n\n## Understanding What Constitutes a True Actor\n\nThis is one of the most critical decisions in requirements analysis. Misidentifying table attributes or organizational properties as actors will fundamentally break the system architecture.\n\n### Core Principle: Architectural Necessity\n\n**Actors are defined by architectural necessity, not organizational hierarchy.**\n\nAn actor represents a fundamentally different user type that requires:\n- **Separate database table** with distinct authentication schema\n- **Different authentication flow** (registration, login, session management)\n- **Distinct data model** with actor-specific fields and relationships\n- **Separate authorization logic** throughout the application\n\nIf you can implement something as a simple column in a table, it's NOT an actor \u2014 it's an attribute.\n\n### The Architectural Test\n\nAsk yourself these questions to determine if something is truly an actor:\n\n1. **Table Structure Test**: Would these users require completely different table structures?\n   - \u2705 YES \u2192 Different actors\n   - \u274C NO \u2192 Same actor with different attributes\n\n2. **Authentication Flow Test**: Do these users authenticate through fundamentally different flows?\n   - \u2705 YES \u2192 Different actors\n   - \u274C NO \u2192 Same actor with different permissions\n\n3. **Data Model Test**: Do these users have fundamentally different data that cannot be expressed through nullable fields or enum values?\n   - \u2705 YES \u2192 Different actors\n   - \u274C NO \u2192 Same actor with attribute variations\n\n4. **Business Logic Test**: Does the core business logic completely change based on which user type is acting?\n   - \u2705 YES \u2192 Different actors\n   - \u274C NO \u2192 Same actor with conditional logic\n\n### \u2705 TRUE ACTORS: Examples\n\n#### Example 1: E-Commerce Platform\n```typescript\n// These are TRUE ACTORS - fundamentally different user types\nactors: [\n  { name: \"customer\", kind: \"member\" },\n  { name: \"seller\", kind: \"member\" },\n  { name: \"admin\", kind: \"admin\" }\n]\n```\n\n**Why these are actors:**\n- **Customer table**: Contains shipping addresses, payment methods, order history\n- **Seller table**: Contains bank accounts, business registration, product inventory\n- **Admin table**: Contains access permissions, audit logs, administrative settings\n- Each has **completely different database schemas**\n- Each has **different authentication requirements** and flows\n- Each interacts with **different sets of API endpoints**\n\n#### Example 2: BBS (Bulletin Board System)\n```typescript\n// These are TRUE ACTORS - different authentication and capabilities\nactors: [\n  { name: \"citizen\", kind: \"member\" },\n  { name: \"moderator\", kind: \"admin\" }\n]\n```\n\n**Why these are actors:**\n- **Citizen table**: Basic profile, voting history, participation records\n- **Moderator table**: Administrative credentials, moderation history, elevated permissions\n- Different authentication scopes and JWT token structures\n- Moderators can access administrative endpoints citizens cannot\n\n### \u274C NOT ACTORS: Common Mistakes\n\n#### Mistake 1: Organizational Hierarchy as Actors\n\n**WRONG** \u274C:\n```typescript\n// DO NOT DO THIS - These are attributes, not actors\nactors: [\n  { name: \"enterpriseOwner\", kind: \"admin\" },\n  { name: \"enterpriseManager\", kind: \"member\" },\n  { name: \"enterpriseMember\", kind: \"member\" },\n  { name: \"enterpriseObserver\", kind: \"guest\" }\n]\n```\n\n**WHY THIS IS WRONG:**\nThese are all the same actor type (enterprise employees) with different **titles/roles within the organization**. They all:\n- Share the **same authentication table** (`enterprise_employees`)\n- Have the **same authentication flow** (employee login)\n- Use the **same data model** with a `title` column: `enum('owner', 'manager', 'member', 'observer')`\n- Differ only in **permission levels**, which is just a table attribute\n\n**CORRECT** \u2705:\n```typescript\n// These are part of ONE actor with a title attribute\nactors: [\n  { name: \"enterpriseEmployee\", kind: \"member\" }\n]\n\n// In Prisma schema (generated later):\nmodel enterprise_employees {\n  id       String @id\n  email    String @unique\n  password String\n  title    EnterpriseEmployeeTitle  // owner | manager | member | observer\n  // ... other employee fields\n}\n```\n\n**Permission logic** is handled through the `title` attribute:\n```typescript\n// Business logic handles title-based permissions\nif (employee.title === 'owner') {\n  // Can delete the enterprise\n}\nif (['owner', 'manager'].includes(employee.title)) {\n  // Can invite new members\n}\n```\n\n#### Mistake 2: Relational Attributes as Actors\n\n**WRONG** \u274C:\n```typescript\n// DO NOT DO THIS - These are relationship attributes\nactors: [\n  { name: \"teamLeader\", kind: \"admin\" },\n  { name: \"teamMember\", kind: \"member\" }\n]\n```\n\n**WHY THIS IS WRONG:**\nThe same employee can be a leader in one team and a member in another team. This is a **many-to-many relationship attribute**, not an actor type:\n\n```typescript\n// This is a relationship, not an actor\nmodel enterprise_employee_team_companions {\n  employee_id String\n  team_id     String\n  role        String  // 'leader' or 'member' - contextual to the team\n\n  @@id([employee_id, team_id])\n}\n```\n\n**CORRECT** \u2705:\n```typescript\n// Use ONE actor for all enterprise employees\nactors: [\n  { name: \"enterpriseEmployee\", kind: \"member\" }\n]\n\n// Team leadership is a relationship property, not an actor type\n```\n\n#### Mistake 3: Permission Levels as Actors\n\n**WRONG** \u274C:\n```typescript\n// DO NOT DO THIS - Permission levels are not actors\nactors: [\n  { name: \"readOnlyUser\", kind: \"member\" },\n  { name: \"readWriteUser\", kind: \"member\" },\n  { name: \"fullAccessUser\", kind: \"admin\" }\n]\n```\n\n**WHY THIS IS WRONG:**\nThese are permission scopes, not different user types. Use a single actor with permission attributes:\n\n**CORRECT** \u2705:\n```typescript\nactors: [\n  { name: \"user\", kind: \"member\" }\n]\n\n// Permissions handled via attribute:\nmodel users {\n  id              String\n  permission_level String  // 'read_only' | 'read_write' | 'full_access'\n}\n```\n\n### Decision Framework: Is This an Actor?\n\nUse this step-by-step framework when uncertain:\n\n```\n\u250C\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n\u2502 Question 1: Can this be a column in an existing table?  \u2502\n\u251C\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2524\n\u2502 YES \u2192 It's an ATTRIBUTE, not an actor                   \u2502\n\u2502 NO  \u2192 Continue to Question 2                            \u2502\n\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n\n\u250C\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n\u2502 Question 2: Do they authenticate the same way?          \u2502\n\u251C\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2524\n\u2502 YES \u2192 Probably the SAME ACTOR with different attributes \u2502\n\u2502 NO  \u2192 Continue to Question 3                            \u2502\n\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n\n\u250C\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n\u2502 Question 3: Do they need completely different tables?   \u2502\n\u251C\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2524\n\u2502 NO  \u2192 It's an ATTRIBUTE, not an actor                   \u2502\n\u2502 YES \u2192 This is likely a TRUE ACTOR                       \u2502\n\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n\n\u250C\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n\u2502 Final Check: Would table schemas be radically different?\u2502\n\u251C\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2524\n\u2502 NO  \u2192 It's an ATTRIBUTE                                 \u2502\n\u2502 YES \u2192 It's a TRUE ACTOR                                 \u2502\n\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n```\n\n### Real-World Scenario: Enterprise Management System\n\nLet's apply the framework to a complex real-world scenario:\n\n**Scenario**: An enterprise management system where:\n- Companies can register on the platform\n- Each company has employees with different titles (owner, manager, member, observer)\n- Employees can be part of multiple teams\n- Each team has leaders and regular members\n- Some employees can also be customers of other companies\n\n**Analysis**:\n\n1. **Company Admin/Employee** \u2014 ONE ACTOR\n   - All employees authenticate through the same enterprise employee table\n   - Differences in `owner/manager/member/observer` are handled via `title` attribute\n   - Team leadership is a relationship attribute in the junction table\n\n2. **Customer** \u2014 SEPARATE ACTOR\n   - Different authentication table (customer accounts)\n   - Different data model (shipping addresses, payment methods)\n   - Different authentication flow (customer registration vs employee invitation)\n\n**CORRECT** \u2705:\n```typescript\nactors: [\n  { name: \"enterpriseEmployee\", kind: \"member\" },\n  { name: \"customer\", kind: \"member\" }\n]\n```\n\n**WRONG** \u274C:\n```typescript\n// DO NOT separate organizational hierarchy into actors\nactors: [\n  { name: \"enterpriseOwner\", kind: \"admin\" },\n  { name: \"enterpriseManager\", kind: \"member\" },\n  { name: \"enterpriseMember\", kind: \"member\" },\n  { name: \"teamLeader\", kind: \"admin\" },\n  { name: \"teamMember\", kind: \"member\" },\n  { name: \"customer\", kind: \"member\" }\n]\n```\n\n### Verification Checklist\n\nBefore finalizing your actor list, verify each actor against this checklist:\n\n- [ ] **Separate Table**: This actor requires a distinct database table with unique fields\n- [ ] **Different Auth Flow**: This actor has a fundamentally different registration/login process\n- [ ] **Distinct Data Model**: This actor stores completely different types of data\n- [ ] **Cannot Be Attribute**: This cannot be represented as a simple column (enum, boolean, string)\n- [ ] **Not Organizational**: This is not just a title, rank, or permission level within same organization\n- [ ] **Not Relational**: This is not a contextual attribute in a many-to-many relationship\n- [ ] **Business Justification**: There is a clear business reason why these users must be architecturally separated\n\nIf any actor fails this checklist, reconsider whether it's truly an actor or just an attribute of an existing actor.\n\n### Summary: The Golden Rule\n\n**\"If tables would be designed very differently, it's an actor. If it's just a table attribute, it's not an actor.\"**\n\nWhen in doubt:\n- **Default to fewer actors** with rich attribute sets\n- **Only create separate actors** when architectural necessity demands it\n- **Remember**: Organizational hierarchy \u2260 System actors\n- **Think**: Would a senior developer design separate tables for these, or use one table with attributes?\n\n# File Metadata Requirements\n\nWhen creating files using the AutoBeAnalyzeFile.Scenario structure, follow these strict guidelines:\n\n## documentType Property\n- Use types like \"requirement\", \"user-story\", \"business-model\", \"service-overview\"\n- NEVER use types suggesting technical implementation (e.g., \"api-spec\", \"database-design\", \"architecture\")\n\n## outline Property\n- Include sections for business requirements and user needs\n- PROHIBITED sections: \"API Design\", \"Database Schema\", \"Technical Architecture\", \"Implementation Details\"\n- Example of GOOD outline: [\"Business Overview\", \"User Scenarios\", \"Functional Requirements\", \"Success Criteria\"]\n- Example of BAD outline: [\"API Endpoints\", \"Database Tables\", \"System Architecture\"]\n\n## constraints Property\nWhen specifying constraints, focus on business constraints ONLY:\n- \u2705 GOOD: \"Must support 10,000 concurrent users\", \"Must comply with GDPR\", \"Must integrate with payment systems\"\n- \u274C BAD: \"Must use PostgreSQL\", \"Must implement REST API\", \"Must use microservices architecture\"\n\n## keyQuestions Property\nQuestions should focus on business and user needs:\n- \u2705 GOOD: \"What problems does this solve for users?\", \"What are the business goals?\"\n- \u274C BAD: \"What database should we use?\", \"How should we structure the API?\"\n\n## CRITICAL REMINDER\nAll file properties must guide the creation of business-focused, natural language documentation. Any property value that suggests technical implementation details, database design, or API specifications must be rejected and replaced with business-appropriate alternatives.\n\n# Mermaid Diagram Guidelines\n\n## \u26A0\uFE0F CRITICAL: Mermaid Syntax Rules\n\n### 1. Double Quote Usage\n- **NEVER use double quotes inside double quotes** \u274C\n- **Wrong**: `subgraph \"Internal Service(\\\"service-name\\\")\"`\n- **Correct**: `subgraph \"Internal Service (service-name)\"`\n- **Alternative**: Use single quotes for inner text if needed\n\n### 2. Label Formatting\n- All labels MUST use double quotes for the outer wrapper\n- NO nested double quotes allowed\n- Use parentheses, brackets, or single quotes for inner text\n- Examples:\n  - \u274C BAD: `A[\"User Login(\\\"Email\\\")\"]`\n  - \u2705 GOOD: `A[\"User Login (Email)\"]`\n  - \u2705 GOOD: `A[\"User Login - Email\"]`\n\n### 3. Reading and Writing \"Mermaid\"\n- **documents**: Write down Mermaid in English when writing it down.\n- **Never write**: \"mermaid\", \"MERMAID\", or other variations\n- **In diagram code blocks**: Use ` ```mermaid ` (lowercase for code block identifier only)\n\n### 4. Common Mermaid Pitfalls to Avoid\n- Escaped quotes inside quotes will break the diagram\n- Special characters should be avoided or properly handled\n- Keep labels simple and clear without complex punctuation\n- Test all diagrams mentally before including them\n\n### 5. Safe Mermaid Patterns\n```mermaid\ngraph LR\n    A[\"Service Start\"] --> B[\"User Authentication\"]\n    B --> C{\"Is Valid?\"}\n    C -->|\"Yes\"| D[\"Grant Access\"]\n    C -->|\"No\"| E[\"Deny Access\"]\n```\n\nNote: Always prefer simple, clear labels over complex nested structures." /* AutoBeSystemPromptConstant.ANALYZE_SCENARIO */,
+            text: "<!--\nfilename: ANALYZE_SCENARIO.md\n-->\n# Overview\n\n- You are the agent that determines the form of the entire document.\n- Because the tool you have has a function to determine all file names, use this function to determine the names of all files.\n- The first page of the file must be a page containing the table of contents, and from the second page, it must be a page corresponding to each table of contents.\n- The table of contents page should be named consistently as `00-toc.md`.\n- Each document must begin with a number in turn, such as `00`, `01`, `02`, `03`.\n\n# Input Materials\n\n## 1. User-AI Conversation History\n\nYou will receive the complete conversation history between the user and AI about backend requirements.\nThis conversation contains:\n- Initial requirements and goals discussed by the user\n- Clarifying questions and answers about the system\n- Feature descriptions and business logic explanations\n- Technical constraints and preferences mentioned\n- Iterative refinements of the requirements\n\nAnalyze this conversation to understand the full context and requirements for the backend system.\n\n## Document Types\n\nYou can create various types of planning documents, including but not limited to:\n\n- **requirement**: Functional/non-functional requirements in natural language, acceptance criteria\n- **user-story**: User personas, scenarios, and journey descriptions\n- **user-flow**: Step-by-step user interactions and decision points\n- **business-model**: Revenue streams, cost structure, value propositions\n- **service-overview**: High-level service description, goals, and scope\n\nAdditional document types can be created based on project needs, but avoid technical implementation details.\n\n## \u26A0\uFE0F STRICTLY PROHIBITED Content\n\n### NEVER Include in Documents:\n- **Database schemas, ERD, or table designs** \u274C\n- **API endpoint specifications** \u274C\n- **Technical implementation details** \u274C\n- **Code examples or pseudo-code** \u274C\n- **Framework-specific solutions** \u274C\n- **System architecture diagrams** \u274C\n\n### Why These Are Prohibited:\n- These restrict developer creativity and autonomy\n- Implementation details should be decided by developers based on their expertise\n- Business requirements should focus on WHAT needs to be done, not HOW\n\n## Important Distinctions\n\n- **Business Requirements** \u2705: What the system should do, written in natural language\n- **User Needs** \u2705: Problems to solve, user scenarios, business logic\n- **Performance Expectations** \u2705: Response time expectations in user terms (e.g., \"instant\", \"within a few seconds\")\n- **Implementation Details** \u274C: Database design, API structure, technical architecture\n\nFocus on the \"what\" and \"why\", not the \"how\". All technical implementation decisions belong to development agents.\n\n## Required Document Focus\n\n### All Documents MUST:\n- Use natural language to describe requirements\n- Focus on business logic and user needs\n- Describe workflows and processes conceptually\n- Explain user actors and permissions in business terms\n- Define success criteria from a business perspective\n\n### Documents MUST NOT:\n- Include database schemas or ERD diagrams\n- Specify API endpoints or request/response formats\n- Dictate technical implementations\n- Provide code examples or technical specifications\n- Limit developer choices through technical constraints\n\n## Document Relationships\n\nConsider the relationships between documents when organizing:\n- Documents that reference each other should be clearly linked\n- Maintain logical flow from high-level overview to detailed requirements\n- Group related documents together in the numbering sequence\n\n## \uD83D\uDCCB Essential Document Structure Guidelines\n\nWhen planning documents, follow this logical progression to ensure comprehensive coverage:\n\n### Part 1 \u2014 Service Context (Foundation Documents)\nThese documents establish WHY the service exists and MUST be created first:\n\n- **Service Vision & Overview**: Ultimate reason for existence, target market, long-term goals\n- **Problem Definition**: Pain points, user frustrations, market gaps being addressed\n- **Core Value Proposition**: Essential value delivered, unique differentiators, key benefits\n\n### Part 2 \u2014 Functional Requirements (Core Documents)\nThese define WHAT the system does from a business perspective:\n\n- **Service Operation Overview**: How the service works in natural language, main user journeys\n- **User Actors & Personas**: Different user types, their needs, permission levels in business terms. Each actor must specify its kind (guest/member/admin) to establish the permission hierarchy\n- **Primary User Scenarios**: Most common success paths, step-by-step interactions\n- **Secondary & Special Scenarios**: Alternative flows, edge cases, bulk operations\n- **Exception Handling**: Error situations from user perspective, recovery processes\n- **Performance Expectations**: User experience expectations (\"instant\", \"within seconds\")\n- **Security & Compliance**: Privacy requirements, data protection, regulatory compliance\n\n### Part 3 \u2014 System Context (Environment Documents)\nThese explain HOW the system operates in its environment:\n\n- **External Integrations**: Third-party services, payment systems, data exchange needs\n- **Data Flow & Lifecycle**: Information movement through system (conceptual, not technical)\n- **Business Rules & Constraints**: Validation rules, operational constraints, legal requirements\n- **Event Processing**: How the system responds to various business events\n- **Environmental Constraints**: Network limitations, resource constraints in business terms\n\n### Document Allocation Strategy\n\n#### When User Requests Specific Page Count:\n- **Fewer pages than topics**: Intelligently combine related topics while ensuring ALL essential content is covered\n- **More pages than topics**: Expand each topic with greater detail and examples\n- **Always prioritize completeness**: Better to have dense, comprehensive documents than missing critical information\n\n#### Content Compression Guidelines (for limited page counts):\n- **Combine related contexts**: Merge vision + problem + value into \"Service Foundation\"\n- **Group scenarios**: Unite primary + secondary + exception handling into \"User Scenarios\"\n- **Consolidate requirements**: Merge performance + security + compliance into \"Non-functional Requirements\"\n\n#### Content Expansion Guidelines (for larger page counts):\n- **Split complex topics**: Separate each user actor into individual persona documents\n- **Detail scenarios**: Create separate documents for each major user journey\n- **Elaborate business rules**: Dedicate documents to specific rule categories\n\n### Critical Reminders:\n- ALL essential topics MUST be covered regardless of page count\n- Never sacrifice important content to meet page limits\n- Always maintain the logical flow: Context \u2192 Requirements \u2192 Environment\n- Each document should reference related documents for navigation\n\n# \uD83D\uDCC4 Page Count System Prompt\n\nYou are responsible for determining the appropriate number of pages (documents) to generate.\n\n## Rules:\n\n1. **If the user explicitly requests a number of pages**, create exactly that number PLUS one additional page for the Table of Contents.\n2. **If the user does not specify a number**, determine a reasonable number based on project complexity and scope.\n3. The final number of pages **must always match** the length of the `files` array.\n4. The total number of pages **must be greater than 1**.\n5. Always include `00-toc.md` as the Table of Contents page.\n\n## Page Count Clarification:\n\n- User requests \"3 pages\" \u2192 Generate 4 total files (1 ToC + 3 content pages)\n- The ToC is ALWAYS additional to the user's requested count\n- This ensures users get the exact number of content pages they requested\n\n## Guidelines for Determining Page Count (when not specified):\n\n- **Default minimum**: 10 content pages + ToC to ensure comprehensive coverage\n- This allows for proper separation of concerns and detailed exploration of each topic\n- More documents enable better organization and easier navigation\n- Small project (single feature): Minimum 10 content pages + ToC\n- Medium project (multiple features): 10-15 content pages + ToC\n- Large project (complete system): 15-20 content pages + ToC\n- Consider splitting if any single document would exceed 3,000 characters\n\n## When User Specifies Small Document Count:\n- If the user requests a small number of documents, ensure all essential content is included\n- Compress content intelligently by creating comprehensive outlines that cover all necessary topics\n- Each document should be dense with information while maintaining readability\n- Prioritize combining related topics rather than omitting important content\n\n## Summary:\n\n> Total files = User-requested content pages + 1 (Table of Contents)\n\nDo **not** forget to include the Table of Contents when calculating the total number of documents.\n\n# Naming Conventions\n\n## Specific Property Notations\n- **IAutoBeAnalyzeScenarioApplication.IProps.prefix**: Use camelCase notation (e.g., `shopping`, `userManagement`, `contentPortal`)\n- **AutoBeAnalyzeActor.name**: Use camelCase notation\n- **AutoBeAnalyzeActor.kind**: Categorize actors into permission hierarchy levels:\n  - **\"guest\"**: Unauthenticated or minimal permission users who can only access public resources and basic functions like registration/login\n  - **\"member\"**: Authenticated standard users who can access personal resources and participate in core application features\n  - **\"admin\"**: System administrators with elevated permissions who can manage users, access administrative functions, and modify system settings\n\n# User Actor Definition Guidelines\n\n## CRITICAL: Understanding name vs kind\n\nThe actor `name` and `kind` serve different purposes:\n\n- **name**: Domain-specific business actor identifier\n  - Must reflect the actual actor in your business domain\n  - Should be specific to your service context\n\n- **kind**: Permission level classification\n  - Limited to three values: \"guest\", \"member\", or \"admin\"\n  - Determines the base security level and access patterns\n  - Multiple different actors can share the same kind\n\n## Correct Actor Definition Process\n\n1. **Identify business actors**: Define actors based on your specific domain\n2. **Assign appropriate kind**: Map each actor to its permission level\n\n# \u26A0\uFE0F CRITICAL: Actor vs Attribute Distinction\n\n## Understanding What Constitutes a True Actor\n\nThis is one of the most critical decisions in requirements analysis. Misidentifying table attributes or organizational properties as actors will fundamentally break the system architecture.\n\n### Core Principle: Architectural Necessity\n\n**Actors are defined by architectural necessity, not organizational hierarchy.**\n\nAn actor represents a fundamentally different user type that requires:\n- **Separate database table** with distinct authentication schema\n- **Different authentication flow** (registration, login, session management)\n- **Distinct data model** with actor-specific fields and relationships\n- **Separate authorization logic** throughout the application\n\nIf you can implement something as a simple column in a table, it's NOT an actor \u2014 it's an attribute.\n\n### The Architectural Test\n\nAsk yourself these questions to determine if something is truly an actor:\n\n1. **Table Structure Test**: Would these users require completely different table structures?\n   - \u2705 YES \u2192 Different actors\n   - \u274C NO \u2192 Same actor with different attributes\n\n2. **Authentication Flow Test**: Do these users authenticate through fundamentally different flows?\n   - \u2705 YES \u2192 Different actors\n   - \u274C NO \u2192 Same actor with different permissions\n\n3. **Data Model Test**: Do these users have fundamentally different data that cannot be expressed through nullable fields or enum values?\n   - \u2705 YES \u2192 Different actors\n   - \u274C NO \u2192 Same actor with attribute variations\n\n4. **Business Logic Test**: Does the core business logic completely change based on which user type is acting?\n   - \u2705 YES \u2192 Different actors\n   - \u274C NO \u2192 Same actor with conditional logic\n\n### \u2705 TRUE ACTORS: Examples\n\n#### Example 1: E-Commerce Platform\n```typescript\n// These are TRUE ACTORS - fundamentally different user types\nactors: [\n  { name: \"customer\", kind: \"member\" },\n  { name: \"seller\", kind: \"member\" },\n  { name: \"admin\", kind: \"admin\" }\n]\n```\n\n**Why these are actors:**\n- **Customer table**: Contains shipping addresses, payment methods, order history\n- **Seller table**: Contains bank accounts, business registration, product inventory\n- **Admin table**: Contains access permissions, audit logs, administrative settings\n- Each has **completely different database schemas**\n- Each has **different authentication requirements** and flows\n- Each interacts with **different sets of API endpoints**\n\n#### Example 2: BBS (Bulletin Board System)\n```typescript\n// These are TRUE ACTORS - different authentication and capabilities\nactors: [\n  { name: \"citizen\", kind: \"member\" },\n  { name: \"moderator\", kind: \"admin\" }\n]\n```\n\n**Why these are actors:**\n- **Citizen table**: Basic profile, voting history, participation records\n- **Moderator table**: Administrative credentials, moderation history, elevated permissions\n- Different authentication scopes and JWT token structures\n- Moderators can access administrative endpoints citizens cannot\n\n### \u274C NOT ACTORS: Common Mistakes\n\n#### Mistake 1: Organizational Hierarchy as Actors\n\n**WRONG** \u274C:\n```typescript\n// DO NOT DO THIS - These are attributes, not actors\nactors: [\n  { name: \"enterpriseOwner\", kind: \"admin\" },\n  { name: \"enterpriseManager\", kind: \"member\" },\n  { name: \"enterpriseMember\", kind: \"member\" },\n  { name: \"enterpriseObserver\", kind: \"guest\" }\n]\n```\n\n**WHY THIS IS WRONG:**\nThese are all the same actor type (enterprise employees) with different **titles/roles within the organization**. They all:\n- Share the **same authentication table** (`enterprise_employees`)\n- Have the **same authentication flow** (employee login)\n- Use the **same data model** with a `title` column: `enum('owner', 'manager', 'member', 'observer')`\n- Differ only in **permission levels**, which is just a table attribute\n\n**CORRECT** \u2705:\n```typescript\n// These are part of ONE actor with a title attribute\nactors: [\n  { name: \"enterpriseEmployee\", kind: \"member\" }\n]\n\n// In Prisma schema (generated later):\nmodel enterprise_employees {\n  id       String @id\n  email    String @unique\n  password String\n  title    EnterpriseEmployeeTitle  // owner | manager | member | observer\n  // ... other employee fields\n}\n```\n\n**Permission logic** is handled through the `title` attribute:\n```typescript\n// Business logic handles title-based permissions\nif (employee.title === 'owner') {\n  // Can delete the enterprise\n}\nif (['owner', 'manager'].includes(employee.title)) {\n  // Can invite new members\n}\n```\n\n#### Mistake 2: Relational Attributes as Actors\n\n**WRONG** \u274C:\n```typescript\n// DO NOT DO THIS - These are relationship attributes\nactors: [\n  { name: \"teamLeader\", kind: \"admin\" },\n  { name: \"teamMember\", kind: \"member\" }\n]\n```\n\n**WHY THIS IS WRONG:**\nThe same employee can be a leader in one team and a member in another team. This is a **many-to-many relationship attribute**, not an actor type:\n\n```typescript\n// This is a relationship, not an actor\nmodel enterprise_employee_team_companions {\n  employee_id String\n  team_id     String\n  role        String  // 'leader' or 'member' - contextual to the team\n\n  @@id([employee_id, team_id])\n}\n```\n\n**CORRECT** \u2705:\n```typescript\n// Use ONE actor for all enterprise employees\nactors: [\n  { name: \"enterpriseEmployee\", kind: \"member\" }\n]\n\n// Team leadership is a relationship property, not an actor type\n```\n\n#### Mistake 3: Permission Levels as Actors\n\n**WRONG** \u274C:\n```typescript\n// DO NOT DO THIS - Permission levels are not actors\nactors: [\n  { name: \"readOnlyUser\", kind: \"member\" },\n  { name: \"readWriteUser\", kind: \"member\" },\n  { name: \"fullAccessUser\", kind: \"admin\" }\n]\n```\n\n**WHY THIS IS WRONG:**\nThese are permission scopes, not different user types. Use a single actor with permission attributes:\n\n**CORRECT** \u2705:\n```typescript\nactors: [\n  { name: \"user\", kind: \"member\" }\n]\n\n// Permissions handled via attribute:\nmodel users {\n  id              String\n  permission_level String  // 'read_only' | 'read_write' | 'full_access'\n}\n```\n\n### Decision Framework: Is This an Actor?\n\nUse this step-by-step framework when uncertain:\n\n```\n\u250C\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n\u2502 Question 1: Can this be a column in an existing table?  \u2502\n\u251C\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2524\n\u2502 YES \u2192 It's an ATTRIBUTE, not an actor                   \u2502\n\u2502 NO  \u2192 Continue to Question 2                            \u2502\n\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n\n\u250C\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n\u2502 Question 2: Do they authenticate the same way?          \u2502\n\u251C\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2524\n\u2502 YES \u2192 Probably the SAME ACTOR with different attributes \u2502\n\u2502 NO  \u2192 Continue to Question 3                            \u2502\n\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n\n\u250C\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n\u2502 Question 3: Do they need completely different tables?   \u2502\n\u251C\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2524\n\u2502 NO  \u2192 It's an ATTRIBUTE, not an actor                   \u2502\n\u2502 YES \u2192 This is likely a TRUE ACTOR                       \u2502\n\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n\n\u250C\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n\u2502 Final Check: Would table schemas be radically different?\u2502\n\u251C\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2524\n\u2502 NO  \u2192 It's an ATTRIBUTE                                 \u2502\n\u2502 YES \u2192 It's a TRUE ACTOR                                 \u2502\n\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n```\n\n### Real-World Scenario: Enterprise Management System\n\nLet's apply the framework to a complex real-world scenario:\n\n**Scenario**: An enterprise management system where:\n- Companies can register on the platform\n- Each company has employees with different titles (owner, manager, member, observer)\n- Employees can be part of multiple teams\n- Each team has leaders and regular members\n- Some employees can also be customers of other companies\n\n**Analysis**:\n\n1. **Company Admin/Employee** \u2014 ONE ACTOR\n   - All employees authenticate through the same enterprise employee table\n   - Differences in `owner/manager/member/observer` are handled via `title` attribute\n   - Team leadership is a relationship attribute in the junction table\n\n2. **Customer** \u2014 SEPARATE ACTOR\n   - Different authentication table (customer accounts)\n   - Different data model (shipping addresses, payment methods)\n   - Different authentication flow (customer registration vs employee invitation)\n\n**CORRECT** \u2705:\n```typescript\nactors: [\n  { name: \"enterpriseEmployee\", kind: \"member\" },\n  { name: \"customer\", kind: \"member\" }\n]\n```\n\n**WRONG** \u274C:\n```typescript\n// DO NOT separate organizational hierarchy into actors\nactors: [\n  { name: \"enterpriseOwner\", kind: \"admin\" },\n  { name: \"enterpriseManager\", kind: \"member\" },\n  { name: \"enterpriseMember\", kind: \"member\" },\n  { name: \"teamLeader\", kind: \"admin\" },\n  { name: \"teamMember\", kind: \"member\" },\n  { name: \"customer\", kind: \"member\" }\n]\n```\n\n### Verification Checklist\n\nBefore finalizing your actor list, verify each actor against this checklist:\n\n- [ ] **Separate Table**: This actor requires a distinct database table with unique fields\n- [ ] **Different Auth Flow**: This actor has a fundamentally different registration/login process\n- [ ] **Distinct Data Model**: This actor stores completely different types of data\n- [ ] **Cannot Be Attribute**: This cannot be represented as a simple column (enum, boolean, string)\n- [ ] **Not Organizational**: This is not just a title, rank, or permission level within same organization\n- [ ] **Not Relational**: This is not a contextual attribute in a many-to-many relationship\n- [ ] **Business Justification**: There is a clear business reason why these users must be architecturally separated\n\nIf any actor fails this checklist, reconsider whether it's truly an actor or just an attribute of an existing actor.\n\n### Summary: The Golden Rule\n\n**\"If tables would be designed very differently, it's an actor. If it's just a table attribute, it's not an actor.\"**\n\nWhen in doubt:\n- **Default to fewer actors** with rich attribute sets\n- **Only create separate actors** when architectural necessity demands it\n- **Remember**: Organizational hierarchy \u2260 System actors\n- **Think**: Would a senior developer design separate tables for these, or use one table with attributes?\n\n# File Metadata Guidelines for AutoBeAnalyzeFile.Scenario Objects\n\nEach object in the `files` array represents metadata for a single document to be generated. The metadata properties guide content creation while maintaining business focus.\n\n## Property Usage Guidelines\n\n### documentType Property\nSpecify the document category to guide content structure:\n- Use business-oriented types: \"requirement\", \"user-story\", \"business-model\", \"service-overview\"\n- AVOID technical categories: \"api-spec\", \"database-design\", \"architecture\"\n\n### outline Property\nDefine the major sections that will structure the document content:\n- Focus on business requirements and user needs sections\n- EXCLUDE technical sections: \"API Design\", \"Database Schema\", \"Technical Architecture\", \"Implementation Details\"\n\n### constraints Property\nSpecify business constraints and operational requirements:\n- Business constraints: \"Must support 10,000 concurrent users\", \"Must comply with GDPR\"\n- AVOID technical mandates: \"Must use PostgreSQL\", \"Must implement REST API\"\n\n### keyQuestions Property\nList questions that the document content should answer:\n- Business-focused: \"What problems does this solve for users?\", \"What are the business goals?\"\n- AVOID implementation-focused: \"What database should we use?\", \"How should we structure the API?\"\n\n## Content Direction\nAll metadata properties should guide the creation of business-focused, natural language documentation. Avoid any metadata that suggests technical implementation details, database design, or API specifications.\n\n# Mermaid Diagram Guidelines\n\n## \u26A0\uFE0F CRITICAL: Mermaid Syntax Rules\n\n### 1. Double Quote Usage\n- **NEVER use double quotes inside double quotes** \u274C\n- **Wrong**: `subgraph \"Internal Service(\\\"service-name\\\")\"`\n- **Correct**: `subgraph \"Internal Service (service-name)\"`\n- **Alternative**: Use single quotes for inner text if needed\n\n### 2. Label Formatting\n- All labels MUST use double quotes for the outer wrapper\n- NO nested double quotes allowed\n- Use parentheses, brackets, or single quotes for inner text\n- Examples:\n  - \u274C BAD: `A[\"User Login(\\\"Email\\\")\"]`\n  - \u2705 GOOD: `A[\"User Login (Email)\"]`\n  - \u2705 GOOD: `A[\"User Login - Email\"]`\n\n### 3. Reading and Writing \"Mermaid\"\n- **documents**: Write down Mermaid in English when writing it down.\n- **Never write**: \"mermaid\", \"MERMAID\", or other variations\n- **In diagram code blocks**: Use ` ```mermaid ` (lowercase for code block identifier only)\n\n### 4. Common Mermaid Pitfalls to Avoid\n- Escaped quotes inside quotes will break the diagram\n- Special characters should be avoided or properly handled\n- Keep labels simple and clear without complex punctuation\n- Test all diagrams mentally before including them\n\n### 5. Safe Mermaid Patterns\n```mermaid\ngraph LR\n    A[\"Service Start\"] --> B[\"User Authentication\"]\n    B --> C{\"Is Valid?\"}\n    C -->|\"Yes\"| D[\"Grant Access\"]\n    C -->|\"No\"| E[\"Deny Access\"]\n```\n\nNote: Always prefer simple, clear labels over complex nested structures." /* AutoBeSystemPromptConstant.ANALYZE_SCENARIO */,
             created_at: new Date().toISOString(),
         },
         {

package/lib/orchestrate/analyze/histories/transformAnalyzeScenarioHistories.js.map

@@ -1 +1 @@
-{"version":3,"file":"transformAnalyzeScenarioHistories.js","sourceRoot":"","sources":["../../../../src/orchestrate/analyze/histories/transformAnalyzeScenarioHistories.ts"],"names":[],"mappings":";;AAQA,oEA4BC;AAnCD,yCAA2C;AAE3C,+BAA0B;AAK1B,SAAgB,4BAA4B,CAC1C,GAAyB;IAEzB,OAAO;QACL,GAAG,GAAG;aACH,SAAS,EAAE;aACX,MAAM,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,IAAI,KAAK,aAAa,IAAI,CAAC,CAAC,IAAI,KAAK,kBAAkB,CAAC;QAC3E;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,IAAI,EAAE,eAAe;YACrB,IAAI,o23BAA6C;YACjD,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;SACrC;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,IAAI,EAAE,eAAe;YACrB,IAAI,EAAE,kBAAU,CAAC,IAAI,CAAA;;;;;;;UAOjB,k8vCAAwC;OAC3C;YACD,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;SACrC;KACF,CAAC;AACJ,CAAC"}
+{"version":3,"file":"transformAnalyzeScenarioHistories.js","sourceRoot":"","sources":["../../../../src/orchestrate/analyze/histories/transformAnalyzeScenarioHistories.ts"],"names":[],"mappings":";;AAQA,oEA4BC;AAnCD,yCAA2C;AAE3C,+BAA0B;AAK1B,SAAgB,4BAA4B,CAC1C,GAAyB;IAEzB,OAAO;QACL,GAAG,GAAG;aACH,SAAS,EAAE;aACX,MAAM,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,IAAI,KAAK,aAAa,IAAI,CAAC,CAAC,IAAI,KAAK,kBAAkB,CAAC;QAC3E;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,IAAI,EAAE,eAAe;YACrB,IAAI,4y3BAA6C;YACjD,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;SACrC;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,IAAI,EAAE,eAAe;YACrB,IAAI,EAAE,kBAAU,CAAC,IAAI,CAAA;;;;;;;UAOjB,k8vCAAwC;OAC3C;YACD,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;SACrC;KACF,CAAC;AACJ,CAAC"}

package/lib/orchestrate/analyze/orchestrateAnalyze.js

@@ -73,6 +73,7 @@ const orchestrateAnalyze = (ctx) => __awaiter(void 0, void 0, void 0, function*
         actors: scenario.actors,
         prefix: scenario.prefix,
         files: newFiles,
+        aggregates: ctx.getCurrentAggregates("analyze"),
         step,
         elapsed: new Date().getTime() - startTime.getTime(),
         created_at: new Date().toISOString(),

package/lib/orchestrate/analyze/orchestrateAnalyze.js.map

@@ -1 +1 @@
-{"version":3,"file":"orchestrateAnalyze.js","sourceRoot":"","sources":["../../../src/orchestrate/analyze/orchestrateAnalyze.ts"],"names":[],"mappings":";;;;;;;;;;;;AAUA,+BAA0B;AAG1B,uEAAoE;AACpE,yEAAsE;AACtE,6EAA0E;AAC1E,uEAAoE;AAE7D,MAAM,kBAAkB,GAAG,CAChC,GAAyB,EACsC,EAAE;;IACjE,4BAA4B;IAC5B,MAAM,IAAI,GAAW,CAAC,MAAA,MAAA,GAAG,CAAC,KAAK,EAAE,CAAC,OAAO,0CAAE,IAAI,mCAAI,CAAC,CAAC,CAAC,GAAG,CAAC,CAAC;IAC3D,MAAM,SAAS,GAAS,IAAI,IAAI,EAAE,CAAC;IAEnC,GAAG,CAAC,QAAQ,CAAC;QACX,IAAI,EAAE,cAAc;QACpB,EAAE,EAAE,IAAA,SAAE,GAAE;QACR,IAAI;QACJ,UAAU,EAAE,SAAS,CAAC,WAAW,EAAE;KACpC,CAAC,CAAC;IAEH,6BAA6B;IAC7B,MAAM,QAAQ,GACZ,MAAM,IAAA,uDAA0B,EAAC,GAAG,CAAC,CAAC;IACxC,IAAI,QAAQ,CAAC,IAAI,KAAK,kBAAkB;QACtC,OAAO,GAAG,CAAC,gBAAgB,CAAC,QAAQ,CAAC,CAAC;;QACnC,GAAG,CAAC,QAAQ,CAAC,QAAQ,CAAC,CAAC;IAE5B,kBAAkB;IAClB,MAAM,aAAa,GAA4B;QAC7C,KAAK,EAAE,QAAQ,CAAC,KAAK,CAAC,MAAM;QAC5B,SAAS,EAAE,CAAC;KACb,CAAC;IACF,MAAM,QAAQ,GAAwB,MAAM,IAAA,uCAAkB,EAC5D,QAAQ,CAAC,KAAK,CAAC,GAAG,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,CAAO,cAAc,EAAE,EAAE;QACpD,MAAM,KAAK,GAA4B,MAAM,IAAA,iDAAuB,EAClE,GAAG,EACH;YACE,QAAQ;YACR,IAAI;YACJ,QAAQ,EAAE,aAAa;YACvB,cAAc;SACf,CACF,CAAC;QACF,OAAO,KAAK,CAAC,IAAI,CAAC;IACpB,CAAC,CAAA,CAAC,CACH,CAAC;IAEF,mBAAmB;IACnB,MAAM,cAAc,GAA4B;QAC9C,KAAK,EAAE,QAAQ,CAAC,MAAM;QACtB,SAAS,EAAE,CAAC;KACb,CAAC;IACF,MAAM,QAAQ,GAAwB,MAAM,IAAA,uCAAkB,EAC5D,QAAQ,CAAC,GAAG,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,CAAO,cAAc,EAAE,EAAE;QAC9C,IAAI,CAAC;YACH,MAAM,KAAK,GAA6B,MAAM,IAAA,mDAAwB,EACpE,GAAG,EACH;gBACE,QAAQ;gBACR,QAAQ,EAAE,QAAQ,EAAE,YAAY;gBAChC,MAAM,EAAE,IAAI;gBACZ,QAAQ,EAAE,cAAc;gBACxB,cAAc;aACf,CACF,CAAC;YACF,uCACK,KAAK,CAAC,IAAI,KACb,OAAO,EAAE,KAAK,CAAC,OAAO,IACtB;QACJ,CAAC;QAAC,WAAM,CAAC;YACP,OAAO,IAAI,CAAC;QACd,CAAC;IACH,CAAC,CAAA,CAAC,CACH,CAAC;IAEF,wBAAwB;IACxB,OAAO,GAAG,CAAC,QAAQ,CAAC;QAClB,IAAI,EAAE,iBAAiB;QACvB,EAAE,EAAE,IAAA,SAAE,GAAE;QACR,MAAM,EAAE,QAAQ,CAAC,MAAM;QACvB,MAAM,EAAE,QAAQ,CAAC,MAAM;QACvB,KAAK,EAAE,QAAQ;QACf,IAAI;QACJ,OAAO,EAAE,IAAI,IAAI,EAAE,CAAC,OAAO,EAAE,GAAG,SAAS,CAAC,OAAO,EAAE;QACnD,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;KACrC,CAAgC,CAAC;AACpC,CAAC,CAAA,CAAC;AAhFW,QAAA,kBAAkB,sBAgF7B"}
+{"version":3,"file":"orchestrateAnalyze.js","sourceRoot":"","sources":["../../../src/orchestrate/analyze/orchestrateAnalyze.ts"],"names":[],"mappings":";;;;;;;;;;;;AAUA,+BAA0B;AAG1B,uEAAoE;AACpE,yEAAsE;AACtE,6EAA0E;AAC1E,uEAAoE;AAE7D,MAAM,kBAAkB,GAAG,CAChC,GAAyB,EACsC,EAAE;;IACjE,4BAA4B;IAC5B,MAAM,IAAI,GAAW,CAAC,MAAA,MAAA,GAAG,CAAC,KAAK,EAAE,CAAC,OAAO,0CAAE,IAAI,mCAAI,CAAC,CAAC,CAAC,GAAG,CAAC,CAAC;IAC3D,MAAM,SAAS,GAAS,IAAI,IAAI,EAAE,CAAC;IAEnC,GAAG,CAAC,QAAQ,CAAC;QACX,IAAI,EAAE,cAAc;QACpB,EAAE,EAAE,IAAA,SAAE,GAAE;QACR,IAAI;QACJ,UAAU,EAAE,SAAS,CAAC,WAAW,EAAE;KACpC,CAAC,CAAC;IAEH,6BAA6B;IAC7B,MAAM,QAAQ,GACZ,MAAM,IAAA,uDAA0B,EAAC,GAAG,CAAC,CAAC;IACxC,IAAI,QAAQ,CAAC,IAAI,KAAK,kBAAkB;QACtC,OAAO,GAAG,CAAC,gBAAgB,CAAC,QAAQ,CAAC,CAAC;;QACnC,GAAG,CAAC,QAAQ,CAAC,QAAQ,CAAC,CAAC;IAE5B,kBAAkB;IAClB,MAAM,aAAa,GAA4B;QAC7C,KAAK,EAAE,QAAQ,CAAC,KAAK,CAAC,MAAM;QAC5B,SAAS,EAAE,CAAC;KACb,CAAC;IACF,MAAM,QAAQ,GAAwB,MAAM,IAAA,uCAAkB,EAC5D,QAAQ,CAAC,KAAK,CAAC,GAAG,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,CAAO,cAAc,EAAE,EAAE;QACpD,MAAM,KAAK,GAA4B,MAAM,IAAA,iDAAuB,EAClE,GAAG,EACH;YACE,QAAQ;YACR,IAAI;YACJ,QAAQ,EAAE,aAAa;YACvB,cAAc;SACf,CACF,CAAC;QACF,OAAO,KAAK,CAAC,IAAI,CAAC;IACpB,CAAC,CAAA,CAAC,CACH,CAAC;IAEF,mBAAmB;IACnB,MAAM,cAAc,GAA4B;QAC9C,KAAK,EAAE,QAAQ,CAAC,MAAM;QACtB,SAAS,EAAE,CAAC;KACb,CAAC;IACF,MAAM,QAAQ,GAAwB,MAAM,IAAA,uCAAkB,EAC5D,QAAQ,CAAC,GAAG,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,CAAO,cAAc,EAAE,EAAE;QAC9C,IAAI,CAAC;YACH,MAAM,KAAK,GAA6B,MAAM,IAAA,mDAAwB,EACpE,GAAG,EACH;gBACE,QAAQ;gBACR,QAAQ,EAAE,QAAQ,EAAE,YAAY;gBAChC,MAAM,EAAE,IAAI;gBACZ,QAAQ,EAAE,cAAc;gBACxB,cAAc;aACf,CACF,CAAC;YACF,uCACK,KAAK,CAAC,IAAI,KACb,OAAO,EAAE,KAAK,CAAC,OAAO,IACtB;QACJ,CAAC;QAAC,WAAM,CAAC;YACP,OAAO,IAAI,CAAC;QACd,CAAC;IACH,CAAC,CAAA,CAAC,CACH,CAAC;IAEF,wBAAwB;IACxB,OAAO,GAAG,CAAC,QAAQ,CAAC;QAClB,IAAI,EAAE,iBAAiB;QACvB,EAAE,EAAE,IAAA,SAAE,GAAE;QACR,MAAM,EAAE,QAAQ,CAAC,MAAM;QACvB,MAAM,EAAE,QAAQ,CAAC,MAAM;QACvB,KAAK,EAAE,QAAQ;QACf,UAAU,EAAE,GAAG,CAAC,oBAAoB,CAAC,SAAS,CAAC;QAC/C,IAAI;QACJ,OAAO,EAAE,IAAI,IAAI,EAAE,CAAC,OAAO,EAAE,GAAG,SAAS,CAAC,OAAO,EAAE;QACnD,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;KACrC,CAAgC,CAAC;AACpC,CAAC,CAAA,CAAC;AAjFW,QAAA,kBAAkB,sBAiF7B"}

package/lib/orchestrate/analyze/orchestrateAnalyzeReview.js

@@ -56,7 +56,7 @@ const orchestrateAnalyzeReview = (ctx, props) => __awaiter(void 0, void 0, void
     const pointer = {
         value: null,
     };
-    const { tokenUsage } = yield ctx.conversate({
+    const { metric, tokenUsage } = yield ctx.conversate({
         source: "analyzeReview",
         controller: createController({
             model: ctx.model,
@@ -79,6 +79,7 @@ const orchestrateAnalyzeReview = (ctx, props) => __awaiter(void 0, void 0, void
         review: pointer.value.review,
         content: pointer.value.content,
         tokenUsage,
+        metric,
         total: props.progress.total,
         completed: ++props.progress.completed,
         step: ((_b = (_a = ctx.state().analyze) === null || _a === void 0 ? void 0 : _a.step) !== null && _b !== void 0 ? _b : -1) + 1,
@@ -90,7 +91,11 @@ const orchestrateAnalyzeReview = (ctx, props) => __awaiter(void 0, void 0, void
 exports.orchestrateAnalyzeReview = orchestrateAnalyzeReview;
 function createController(props) {
     (0, assertSchemaModel_1.assertSchemaModel)(props.model);
-    const application = collection[props.model === "chatgpt" ? "chatgpt" : "claude"];
+    const application = collection[props.model === "chatgpt"
+        ? "chatgpt"
+        : props.model === "gemini"
+            ? "gemini"
+            : "claude"];
     return {
         protocol: "class",
         name: "Reviewer",
@@ -102,101 +107,179 @@ function createController(props) {
         },
     };
 }
-const claude = {
-    model: "claude",
-    options: {
-        reference: true,
-        separate: null
-    },
-    functions: [
-        {
-            name: "review",
-            parameters: {
-                description: " - The properties containing the document to enhance along with\nplan and review criteria for guidance\n\n------------------------------\n\nCurrent Type: {@link IAutoBeAnalyzeReviewApplication.IProps}",
-                type: "object",
-                properties: {
-                    review: {
-                        description: "Step 1 (CoT: Review Phase) - Enhancement Criteria\n\nThe enhancement criteria and guidelines that the agent must follow.\n\nThis includes:\n\n- Minimum document length requirements\n- Section completeness checks\n- Link validation rules\n- Mermaid syntax validation (especially parentheses in labels)\n- Content specificity requirements\n- EARS format compliance\n\nThe review criteria ensure that documentation is implementation-ready and\nremoves all ambiguity for backend developers.\n\nCritical review points:\n\n- DO: Use double quotes for ALL labels in Mermaid diagrams\n- DO NOT: Use spaces between brackets and quotes in Mermaid\n- DO: Make requirements specific and measurable in natural language\n- DO: Focus on business requirements and user scenarios\n- DO NOT: Accept documents containing database schemas or API specifications\n- DO: Describe business model and authentication requirements in natural language",
-                        type: "string"
-                    },
-                    plan: {
-                        description: "Step 2 (CoT: Plan Phase) - Original Document Plan\n\nThe document plan that was used to create the content.\n\nThis helps the reviewer understand:\n\n- What sections should be present\n- The intended structure and organization\n- The target audience and purpose\n- Expected level of detail\n\nThe enhancer uses this to ensure the improved content aligns with the\noriginal plan and covers all required topics comprehensively.",
-                        type: "string"
+const collection = {
+    chatgpt: {
+        model: "chatgpt",
+        options: {
+            reference: true,
+            strict: false,
+            separate: null
+        },
+        functions: [
+            {
+                name: "review",
+                parameters: {
+                    description: " - Document content, plan, and review criteria\n\n------------------------------\n\nCurrent Type: {@link IAutoBeAnalyzeReviewApplication.IProps}",
+                    type: "object",
+                    properties: {
+                        review: {
+                            description: "Step 1 (CoT: Review Phase) - Enhancement Criteria\n\nThe enhancement criteria and guidelines that the agent must follow.\n\nThis includes:\n\n- Minimum document length requirements\n- Section completeness checks\n- Link validation rules\n- Mermaid syntax validation (especially parentheses in labels)\n- Content specificity requirements\n- EARS format compliance\n\nThe review criteria ensure that documentation is implementation-ready and\nremoves all ambiguity for backend developers.\n\nCritical review points:\n\n- DO: Use double quotes for ALL labels in Mermaid diagrams\n- DO NOT: Use spaces between brackets and quotes in Mermaid\n- DO: Make requirements specific and measurable in natural language\n- DO: Focus on business requirements and user scenarios\n- DO NOT: Accept documents containing database schemas or API\n  specifications\n- DO: Describe business model and authentication requirements in natural\n  language",
+                            type: "string"
+                        },
+                        plan: {
+                            description: "Step 2 (CoT: Plan Phase) - Original Document Plan\n\nThe document plan that was used to create the content.\n\nThis helps the reviewer understand:\n\n- What sections should be present\n- The intended structure and organization\n- The target audience and purpose\n- Expected level of detail\n\nThe enhancer uses this to ensure the improved content aligns with the\noriginal plan and covers all required topics comprehensively.",
+                            type: "string"
+                        },
+                        content: {
+                            description: "Step 3 (CoT: Content Phase) - Document Content (INPUT \u2192 OUTPUT)\n\nINPUT: The document written by Write Agent (may have issues) OUTPUT: The\nenhanced, complete markdown document to be saved\n\nEnhancement requirements:\n\n- Fix Mermaid syntax errors (add quotes, fix arrows)\n- Convert vague statements to EARS format\n- Expand sections that are too brief\n- Add missing business processes\n\nOutput must be the actual document content (not review comments).",
+                            type: "string"
+                        }
                     },
-                    content: {
-                        description: "Step 3 (CoT: Content Phase) - Complete Document Content\n\nThe actual markdown document content that incorporates review feedback.\n\nThis field contains a COMPLETE MARKDOWN DOCUMENT that has already \nincorporated the review criteria and plan requirements.\n\nDO: Treat this as the final, production-ready document.\nDO NOT: Treat this as raw input to be reviewed.\n\nThis content represents:\n- A fully-formed markdown document (.md file)\n- The result of applying review criteria to the original plan\n- A production-ready document for immediate deployment\n- Complete business requirements ready for developers\n\nThe enhancer should treat this as the actual document content:\n\n- Length and completeness (minimum 2,000 characters, more for technical\n  docs)\n- All sections from the plan are fully written\n- No vague or abstract statements\n- Proper use of EARS format for requirements\n- Correct Mermaid diagram syntax (double quotes mandatory)\n- Appropriate level of detail for backend implementation\n- Proper document linking (descriptive text, not raw filenames)\n\nThe enhancer outputs the document itself:\n\n- If content is provided, it represents the actual document\n- The enhancer outputs the enhanced version AS the document itself\n- No meta-commentary or review feedback should be in the output\n- The output becomes the saved .md file directly\n\nExample of what this field contains:\n\"# Service Overview\\n## Vision\\nThe service provides...\" (actual document)\nNOT: \"This document should cover service overview...\" (review comment)",
-                        type: "string"
-                    }
+                    required: [
+                        "review",
+                        "plan",
+                        "content"
+                    ],
+                    additionalProperties: false,
+                    $defs: {}
                 },
-                required: [
-                    "review",
-                    "plan",
-                    "content"
-                ],
-                additionalProperties: false,
-                $defs: {}
-            },
-            description: "Enhances planning documentation to meet all quality standards and requirements.\n\nThis function receives a document and outputs an improved version directly.\nThe output IS the enhanced document itself, NOT review comments or feedback.\n\nThe enhancement process includes:\n- Expanding sections that are too brief\n- Converting vague statements to specific EARS format requirements\n- Fixing Mermaid diagram syntax errors\n- Adding missing business processes and workflows\n- Ensuring proper document structure and completeness\n\nDO: Output the actual document content that will be saved.\nDO NOT: Output review comments or analysis of the document.\n\nNote: Any text output becomes part of the final document.",
-            validate: (() => { const _io0 = input => "string" === typeof input.review && "string" === typeof input.plan && "string" === typeof input.content; const _vo0 = (input, _path, _exceptionable = true) => ["string" === typeof input.review || _report(_exceptionable, {
-                    path: _path + ".review",
-                    expected: "string",
-                    value: input.review
-                }), "string" === typeof input.plan || _report(_exceptionable, {
-                    path: _path + ".plan",
-                    expected: "string",
-                    value: input.plan
-                }), "string" === typeof input.content || _report(_exceptionable, {
-                    path: _path + ".content",
-                    expected: "string",
-                    value: input.content
-                })].every(flag => flag); const __is = input => "object" === typeof input && null !== input && _io0(input); let errors; let _report; return input => {
-                if (false === __is(input)) {
-                    errors = [];
-                    _report = __typia_transform__validateReport._validateReport(errors);
-                    ((input, _path, _exceptionable = true) => ("object" === typeof input && null !== input || _report(true, {
-                        path: _path + "",
-                        expected: "IAutoBeAnalyzeReviewApplication.IProps",
-                        value: input
-                    })) && _vo0(input, _path + "", true) || _report(true, {
-                        path: _path + "",
-                        expected: "IAutoBeAnalyzeReviewApplication.IProps",
-                        value: input
-                    }))(input, "$input", true);
-                    const success = 0 === errors.length;
-                    return success ? {
-                        success,
+                description: "Enhances and finalizes planning documentation.\n\nReceives a draft document and outputs the improved version. The output is\nthe enhanced document itself, not review comments.",
+                validate: (() => { const _io0 = input => "string" === typeof input.review && "string" === typeof input.plan && "string" === typeof input.content; const _vo0 = (input, _path, _exceptionable = true) => ["string" === typeof input.review || _report(_exceptionable, {
+                        path: _path + ".review",
+                        expected: "string",
+                        value: input.review
+                    }), "string" === typeof input.plan || _report(_exceptionable, {
+                        path: _path + ".plan",
+                        expected: "string",
+                        value: input.plan
+                    }), "string" === typeof input.content || _report(_exceptionable, {
+                        path: _path + ".content",
+                        expected: "string",
+                        value: input.content
+                    })].every(flag => flag); const __is = input => "object" === typeof input && null !== input && _io0(input); let errors; let _report; return input => {
+                    if (false === __is(input)) {
+                        errors = [];
+                        _report = __typia_transform__validateReport._validateReport(errors);
+                        ((input, _path, _exceptionable = true) => ("object" === typeof input && null !== input || _report(true, {
+                            path: _path + "",
+                            expected: "IAutoBeAnalyzeReviewApplication.IProps",
+                            value: input
+                        })) && _vo0(input, _path + "", true) || _report(true, {
+                            path: _path + "",
+                            expected: "IAutoBeAnalyzeReviewApplication.IProps",
+                            value: input
+                        }))(input, "$input", true);
+                        const success = 0 === errors.length;
+                        return success ? {
+                            success,
+                            data: input
+                        } : {
+                            success,
+                            errors,
+                            data: input
+                        };
+                    }
+                    return {
+                        success: true,
                         data: input
-                    } : {
-                        success,
-                        errors,
+                    };
+                }; })()
+            }
+        ]
+    },
+    claude: {
+        model: "claude",
+        options: {
+            reference: true,
+            separate: null
+        },
+        functions: [
+            {
+                name: "review",
+                parameters: {
+                    description: " - Document content, plan, and review criteria\n\n------------------------------\n\nCurrent Type: {@link IAutoBeAnalyzeReviewApplication.IProps}",
+                    type: "object",
+                    properties: {
+                        review: {
+                            description: "Step 1 (CoT: Review Phase) - Enhancement Criteria\n\nThe enhancement criteria and guidelines that the agent must follow.\n\nThis includes:\n\n- Minimum document length requirements\n- Section completeness checks\n- Link validation rules\n- Mermaid syntax validation (especially parentheses in labels)\n- Content specificity requirements\n- EARS format compliance\n\nThe review criteria ensure that documentation is implementation-ready and\nremoves all ambiguity for backend developers.\n\nCritical review points:\n\n- DO: Use double quotes for ALL labels in Mermaid diagrams\n- DO NOT: Use spaces between brackets and quotes in Mermaid\n- DO: Make requirements specific and measurable in natural language\n- DO: Focus on business requirements and user scenarios\n- DO NOT: Accept documents containing database schemas or API\n  specifications\n- DO: Describe business model and authentication requirements in natural\n  language",
+                            type: "string"
+                        },
+                        plan: {
+                            description: "Step 2 (CoT: Plan Phase) - Original Document Plan\n\nThe document plan that was used to create the content.\n\nThis helps the reviewer understand:\n\n- What sections should be present\n- The intended structure and organization\n- The target audience and purpose\n- Expected level of detail\n\nThe enhancer uses this to ensure the improved content aligns with the\noriginal plan and covers all required topics comprehensively.",
+                            type: "string"
+                        },
+                        content: {
+                            description: "Step 3 (CoT: Content Phase) - Document Content (INPUT \u2192 OUTPUT)\n\nINPUT: The document written by Write Agent (may have issues) OUTPUT: The\nenhanced, complete markdown document to be saved\n\nEnhancement requirements:\n\n- Fix Mermaid syntax errors (add quotes, fix arrows)\n- Convert vague statements to EARS format\n- Expand sections that are too brief\n- Add missing business processes\n\nOutput must be the actual document content (not review comments).",
+                            type: "string"
+                        }
+                    },
+                    required: [
+                        "review",
+                        "plan",
+                        "content"
+                    ],
+                    additionalProperties: false,
+                    $defs: {}
+                },
+                description: "Enhances and finalizes planning documentation.\n\nReceives a draft document and outputs the improved version. The output is\nthe enhanced document itself, not review comments.",
+                validate: (() => { const _io0 = input => "string" === typeof input.review && "string" === typeof input.plan && "string" === typeof input.content; const _vo0 = (input, _path, _exceptionable = true) => ["string" === typeof input.review || _report(_exceptionable, {
+                        path: _path + ".review",
+                        expected: "string",
+                        value: input.review
+                    }), "string" === typeof input.plan || _report(_exceptionable, {
+                        path: _path + ".plan",
+                        expected: "string",
+                        value: input.plan
+                    }), "string" === typeof input.content || _report(_exceptionable, {
+                        path: _path + ".content",
+                        expected: "string",
+                        value: input.content
+                    })].every(flag => flag); const __is = input => "object" === typeof input && null !== input && _io0(input); let errors; let _report; return input => {
+                    if (false === __is(input)) {
+                        errors = [];
+                        _report = __typia_transform__validateReport._validateReport(errors);
+                        ((input, _path, _exceptionable = true) => ("object" === typeof input && null !== input || _report(true, {
+                            path: _path + "",
+                            expected: "IAutoBeAnalyzeReviewApplication.IProps",
+                            value: input
+                        })) && _vo0(input, _path + "", true) || _report(true, {
+                            path: _path + "",
+                            expected: "IAutoBeAnalyzeReviewApplication.IProps",
+                            value: input
+                        }))(input, "$input", true);
+                        const success = 0 === errors.length;
+                        return success ? {
+                            success,
+                            data: input
+                        } : {
+                            success,
+                            errors,
+                            data: input
+                        };
+                    }
+                    return {
+                        success: true,
                         data: input
                     };
-                }
-                return {
-                    success: true,
-                    data: input
-                };
-            }; })()
-        }
-    ]
-};
-const collection = {
-    chatgpt: {
-        model: "chatgpt",
+                }; })()
+            }
+        ]
+    },
+    gemini: {
+        model: "gemini",
         options: {
             reference: true,
-            strict: false,
             separate: null
         },
         functions: [
             {
                 name: "review",
                 parameters: {
-                    description: " - The properties containing the document to enhance along with\nplan and review criteria for guidance\n\n------------------------------\n\nCurrent Type: {@link IAutoBeAnalyzeReviewApplication.IProps}",
+                    description: " - Document content, plan, and review criteria\n\n------------------------------\n\nCurrent Type: {@link IAutoBeAnalyzeReviewApplication.IProps}",
                     type: "object",
                     properties: {
                         review: {
-                            description: "Step 1 (CoT: Review Phase) - Enhancement Criteria\n\nThe enhancement criteria and guidelines that the agent must follow.\n\nThis includes:\n\n- Minimum document length requirements\n- Section completeness checks\n- Link validation rules\n- Mermaid syntax validation (especially parentheses in labels)\n- Content specificity requirements\n- EARS format compliance\n\nThe review criteria ensure that documentation is implementation-ready and\nremoves all ambiguity for backend developers.\n\nCritical review points:\n\n- DO: Use double quotes for ALL labels in Mermaid diagrams\n- DO NOT: Use spaces between brackets and quotes in Mermaid\n- DO: Make requirements specific and measurable in natural language\n- DO: Focus on business requirements and user scenarios\n- DO NOT: Accept documents containing database schemas or API specifications\n- DO: Describe business model and authentication requirements in natural language",
+                            description: "Step 1 (CoT: Review Phase) - Enhancement Criteria\n\nThe enhancement criteria and guidelines that the agent must follow.\n\nThis includes:\n\n- Minimum document length requirements\n- Section completeness checks\n- Link validation rules\n- Mermaid syntax validation (especially parentheses in labels)\n- Content specificity requirements\n- EARS format compliance\n\nThe review criteria ensure that documentation is implementation-ready and\nremoves all ambiguity for backend developers.\n\nCritical review points:\n\n- DO: Use double quotes for ALL labels in Mermaid diagrams\n- DO NOT: Use spaces between brackets and quotes in Mermaid\n- DO: Make requirements specific and measurable in natural language\n- DO: Focus on business requirements and user scenarios\n- DO NOT: Accept documents containing database schemas or API\n  specifications\n- DO: Describe business model and authentication requirements in natural\n  language",
                             type: "string"
                         },
                         plan: {
@@ -204,7 +287,7 @@ const collection = {
                             type: "string"
                         },
                         content: {
-                            description: "Step 3 (CoT: Content Phase) - Complete Document Content\n\nThe actual markdown document content that incorporates review feedback.\n\nThis field contains a COMPLETE MARKDOWN DOCUMENT that has already \nincorporated the review criteria and plan requirements.\n\nDO: Treat this as the final, production-ready document.\nDO NOT: Treat this as raw input to be reviewed.\n\nThis content represents:\n- A fully-formed markdown document (.md file)\n- The result of applying review criteria to the original plan\n- A production-ready document for immediate deployment\n- Complete business requirements ready for developers\n\nThe enhancer should treat this as the actual document content:\n\n- Length and completeness (minimum 2,000 characters, more for technical\n  docs)\n- All sections from the plan are fully written\n- No vague or abstract statements\n- Proper use of EARS format for requirements\n- Correct Mermaid diagram syntax (double quotes mandatory)\n- Appropriate level of detail for backend implementation\n- Proper document linking (descriptive text, not raw filenames)\n\nThe enhancer outputs the document itself:\n\n- If content is provided, it represents the actual document\n- The enhancer outputs the enhanced version AS the document itself\n- No meta-commentary or review feedback should be in the output\n- The output becomes the saved .md file directly\n\nExample of what this field contains:\n\"# Service Overview\\n## Vision\\nThe service provides...\" (actual document)\nNOT: \"This document should cover service overview...\" (review comment)",
+                            description: "Step 3 (CoT: Content Phase) - Document Content (INPUT \u2192 OUTPUT)\n\nINPUT: The document written by Write Agent (may have issues) OUTPUT: The\nenhanced, complete markdown document to be saved\n\nEnhancement requirements:\n\n- Fix Mermaid syntax errors (add quotes, fix arrows)\n- Convert vague statements to EARS format\n- Expand sections that are too brief\n- Add missing business processes\n\nOutput must be the actual document content (not review comments).",
                             type: "string"
                         }
                     },
@@ -216,7 +299,7 @@ const collection = {
                     additionalProperties: false,
                     $defs: {}
                 },
-                description: "Enhances planning documentation to meet all quality standards and requirements.\n\nThis function receives a document and outputs an improved version directly.\nThe output IS the enhanced document itself, NOT review comments or feedback.\n\nThe enhancement process includes:\n- Expanding sections that are too brief\n- Converting vague statements to specific EARS format requirements\n- Fixing Mermaid diagram syntax errors\n- Adding missing business processes and workflows\n- Ensuring proper document structure and completeness\n\nDO: Output the actual document content that will be saved.\nDO NOT: Output review comments or analysis of the document.\n\nNote: Any text output becomes part of the final document.",
+                description: "Enhances and finalizes planning documentation.\n\nReceives a draft document and outputs the improved version. The output is\nthe enhanced document itself, not review comments.",
                 validate: (() => { const _io0 = input => "string" === typeof input.review && "string" === typeof input.plan && "string" === typeof input.content; const _vo0 = (input, _path, _exceptionable = true) => ["string" === typeof input.review || _report(_exceptionable, {
                         path: _path + ".review",
                         expected: "string",
@@ -260,9 +343,5 @@ const collection = {
             }
         ]
     },
-    claude,
-    llama: claude,
-    deepseek: claude,
-    "3.1": claude,
 };
 //# sourceMappingURL=orchestrateAnalyzeReview.js.map

package/lib/orchestrate/analyze/orchestrateAnalyzeReview.js.map

@@ -1 +1 @@
-{"version":3,"file":"orchestrateAnalyzeReview.js","sourceRoot":"","sources":["../../../src/orchestrate/analyze/orchestrateAnalyzeReview.ts"],"names":[],"mappings":";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;AASA,kDAA0B;AAC1B,+BAA0B;AAG1B,uEAAoE;AACpE,iGAA8F;AAGvF,MAAM,wBAAwB,GAAG,CACtC,GAAyB,EACzB,KAMC,EACkC,EAAE;;IACrC,MAAM,OAAO,GAA4D;QACvE,KAAK,EAAE,IAAI;KACZ,CAAC;IACF,MAAM,EAAE,UAAU,EAAE,GAAG,MAAM,GAAG,CAAC,UAAU,CAAC;QAC1C,MAAM,EAAE,eAAe;QACvB,UAAU,EAAE,gBAAgB,CAAC;YAC3B,KAAK,EAAE,GAAG,CAAC,KAAK;YAChB,OAAO;SACR,CAAC;QACF,SAAS,EAAE;YACT,GAAG,IAAA,iEAA+B,EAChC,GAAG,EACH,KAAK,CAAC,QAAQ,EACd,KAAK,CAAC,QAAQ,EACd,KAAK,CAAC,MAAM,CACb;SACF;QACD,mBAAmB,EAAE,IAAI;QACzB,cAAc,EAAE,KAAK,CAAC,cAAc;QACpC,OAAO,EAAE,iCAAiC;KAC3C,CAAC,CAAC;IACH,IAAI,OAAO,CAAC,KAAK,KAAK,IAAI;QACxB,MAAM,IAAI,KAAK,CAAC,uCAAuC,CAAC,CAAC;IAE3D,MAAM,KAAK,GAA6B;QACtC,IAAI,EAAE,eAAe;QACrB,EAAE,EAAE,IAAA,SAAE,GAAE;QACR,IAAI,EAAE,KAAK,CAAC,MAAM;QAClB,IAAI,EAAE,OAAO,CAAC,KAAK,CAAC,IAAI;QACxB,MAAM,EAAE,OAAO,CAAC,KAAK,CAAC,MAAM;QAC5B,OAAO,EAAE,OAAO,CAAC,KAAK,CAAC,OAAO;QAC9B,UAAU;QACV,KAAK,EAAE,KAAK,CAAC,QAAQ,CAAC,KAAK;QAC3B,SAAS,EAAE,EAAE,KAAK,CAAC,QAAQ,CAAC,SAAS;QACrC,IAAI,EAAE,CAAC,MAAA,MAAA,GAAG,CAAC,KAAK,EAAE,CAAC,OAAO,0CAAE,IAAI,mCAAI,CAAC,CAAC,CAAC,GAAG,CAAC;QAC3C,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;KACrC,CAAC;IACF,GAAG,CAAC,QAAQ,CAAC,KAAK,CAAC,CAAC;IACpB,OAAO,KAAK,CAAC;AACf,CAAC,CAAA,CAAC;AAjDW,QAAA,wBAAwB,4BAiDnC;AAEF,SAAS,gBAAgB,CAAiC,KAGzD;IACC,IAAA,qCAAiB,EAAC,KAAK,CAAC,KAAK,CAAC,CAAC;IAE/B,MAAM,WAAW,GAA2B,UAAU,CACpD,KAAK,CAAC,KAAK,KAAK,SAAS,CAAC,CAAC,CAAC,SAAS,CAAC,CAAC,CAAC,QAAQ,CACmB,CAAC;IACtE,OAAO;QACL,QAAQ,EAAE,OAAO;QACjB,IAAI,EAAE,UAAU;QAChB,WAAW;QACX,OAAO,EAAE;YACP,MAAM,EAAE,CAAC,KAAK,EAAE,EAAE;gBAChB,KAAK,CAAC,OAAO,CAAC,KAAK,GAAG,KAAK,CAAC;YAC9B,CAAC;SACwC;KAC5C,CAAC;AACJ,CAAC;AAED,MAAM,MAAM;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAGT,CAAC;AACJ,MAAM,UAAU,GAAG;IACjB,OAAO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;KAAqE;IAC5E,MAAM;IACN,KAAK,EAAE,MAAM;IACb,QAAQ,EAAE,MAAM;IAChB,KAAK,EAAE,MAAM;CACd,CAAC"}
+{"version":3,"file":"orchestrateAnalyzeReview.js","sourceRoot":"","sources":["../../../src/orchestrate/analyze/orchestrateAnalyzeReview.ts"],"names":[],"mappings":";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;AASA,kDAA0B;AAC1B,+BAA0B;AAG1B,uEAAoE;AACpE,iGAA8F;AAGvF,MAAM,wBAAwB,GAAG,CACtC,GAAyB,EACzB,KAMC,EACkC,EAAE;;IACrC,MAAM,OAAO,GAA4D;QACvE,KAAK,EAAE,IAAI;KACZ,CAAC;IACF,MAAM,EAAE,MAAM,EAAE,UAAU,EAAE,GAAG,MAAM,GAAG,CAAC,UAAU,CAAC;QAClD,MAAM,EAAE,eAAe;QACvB,UAAU,EAAE,gBAAgB,CAAC;YAC3B,KAAK,EAAE,GAAG,CAAC,KAAK;YAChB,OAAO;SACR,CAAC;QACF,SAAS,EAAE;YACT,GAAG,IAAA,iEAA+B,EAChC,GAAG,EACH,KAAK,CAAC,QAAQ,EACd,KAAK,CAAC,QAAQ,EACd,KAAK,CAAC,MAAM,CACb;SACF;QACD,mBAAmB,EAAE,IAAI;QACzB,cAAc,EAAE,KAAK,CAAC,cAAc;QACpC,OAAO,EAAE,iCAAiC;KAC3C,CAAC,CAAC;IACH,IAAI,OAAO,CAAC,KAAK,KAAK,IAAI;QACxB,MAAM,IAAI,KAAK,CAAC,uCAAuC,CAAC,CAAC;IAE3D,MAAM,KAAK,GAA6B;QACtC,IAAI,EAAE,eAAe;QACrB,EAAE,EAAE,IAAA,SAAE,GAAE;QACR,IAAI,EAAE,KAAK,CAAC,MAAM;QAClB,IAAI,EAAE,OAAO,CAAC,KAAK,CAAC,IAAI;QACxB,MAAM,EAAE,OAAO,CAAC,KAAK,CAAC,MAAM;QAC5B,OAAO,EAAE,OAAO,CAAC,KAAK,CAAC,OAAO;QAC9B,UAAU;QACV,MAAM;QACN,KAAK,EAAE,KAAK,CAAC,QAAQ,CAAC,KAAK;QAC3B,SAAS,EAAE,EAAE,KAAK,CAAC,QAAQ,CAAC,SAAS;QACrC,IAAI,EAAE,CAAC,MAAA,MAAA,GAAG,CAAC,KAAK,EAAE,CAAC,OAAO,0CAAE,IAAI,mCAAI,CAAC,CAAC,CAAC,GAAG,CAAC;QAC3C,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;KACrC,CAAC;IACF,GAAG,CAAC,QAAQ,CAAC,KAAK,CAAC,CAAC;IACpB,OAAO,KAAK,CAAC;AACf,CAAC,CAAA,CAAC;AAlDW,QAAA,wBAAwB,4BAkDnC;AAEF,SAAS,gBAAgB,CAAiC,KAGzD;IACC,IAAA,qCAAiB,EAAC,KAAK,CAAC,KAAK,CAAC,CAAC;IAE/B,MAAM,WAAW,GAA2B,UAAU,CACpD,KAAK,CAAC,KAAK,KAAK,SAAS;QACvB,CAAC,CAAC,SAAS;QACX,CAAC,CAAC,KAAK,CAAC,KAAK,KAAK,QAAQ;YACxB,CAAC,CAAC,QAAQ;YACV,CAAC,CAAC,QAAQ,CACqD,CAAC;IACtE,OAAO;QACL,QAAQ,EAAE,OAAO;QACjB,IAAI,EAAE,UAAU;QAChB,WAAW;QACX,OAAO,EAAE;YACP,MAAM,EAAE,CAAC,KAAK,EAAE,EAAE;gBAChB,KAAK,CAAC,OAAO,CAAC,KAAK,GAAG,KAAK,CAAC;YAC9B,CAAC;SACwC;KAC5C,CAAC;AACJ,CAAC;AAED,MAAM,UAAU,GAAG;IACjB,OAAO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;KAAqE;IAC5E,MAAM;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;KAAoE;IAC1E,MAAM;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;KAAoE;CAC3E,CAAC"}