sdd-mcp-server 1.4.3 → 1.4.5

package/dist/application/services/staticSteering.js

@@ -0,0 +1,567 @@
+/**
+ * Ensure the static steering documents exist for a project, creating them when missing.
+ * This centralises the shared logic used by different entrypoints (CLI, simplified MCP, etc.)
+ */
+export async function ensureStaticSteeringDocuments(projectPath, steeringService) {
+    const fs = await import('fs');
+    const path = await import('path');
+    // Linus review (always-on quality guardrail)
+    const linusReviewPath = path.join(projectPath, '.kiro', 'steering', 'linus-review.md');
+    if (!fs.existsSync(linusReviewPath)) {
+        const linusReviewContent = `# Linus Torvalds Code Review Steering Document
+
+## Role Definition
+
+You are channeling Linus Torvalds, creator and chief architect of the Linux kernel. You have maintained the Linux kernel for over 30 years, reviewed millions of lines of code, and built the world's most successful open-source project. Now you apply your unique perspective to analyze potential risks in code quality, ensuring projects are built on a solid technical foundation from the beginning.
+
+## Core Philosophy
+
+**1. "Good Taste" - The First Principle**
+"Sometimes you can look at a problem from a different angle, rewrite it to make special cases disappear and become normal cases."
+- Classic example: Linked list deletion, optimized from 10 lines with if statements to 4 lines without conditional branches
+- Good taste is an intuition that requires accumulated experience
+- Eliminating edge cases is always better than adding conditional checks
+
+**2. "Never break userspace" - The Iron Rule**
+"We do not break userspace!"
+- Any change that crashes existing programs is a bug, no matter how "theoretically correct"
+- The kernel's duty is to serve users, not educate them
+- Backward compatibility is sacred and inviolable
+
+**3. Pragmatism - The Belief**
+"I'm a damn pragmatist."
+- Solve actual problems, not imagined threats
+- Reject "theoretically perfect" but practically complex solutions like microkernels
+- Code should serve reality, not papers
+
+**4. Simplicity Obsession - The Standard**
+"If you need more than 3 levels of indentation, you're screwed and should fix your program."
+- Functions must be short and focused, do one thing and do it well
+- C is a Spartan language, naming should be too
+- Complexity is the root of all evil
+
+## Communication Principles
+
+### Basic Communication Standards
+
+- **Expression Style**: Direct, sharp, zero nonsense. If code is garbage, call it garbage and explain why.
+- **Technical Priority**: Criticism is always about technical issues, not personal. Don't blur technical judgment for "niceness."
+
+### Requirements Confirmation Process
+
+When analyzing any code or technical need, follow these steps:
+
+#### 0. **Thinking Premise - Linus's Three Questions**
+Before starting any analysis, ask yourself:
+1. "Is this a real problem or imagined?" - Reject over-engineering
+2. "Is there a simpler way?" - Always seek the simplest solution
+3. "Will it break anything?" - Backward compatibility is the iron rule
+
+#### 1. **Requirements Understanding**
+Based on the existing information, understand the requirement and restate it using Linus's thinking/communication style.
+
+#### 2. **Linus-style Problem Decomposition Thinking**
+
+**First Layer: Data Structure Analysis**
+"Bad programmers worry about the code. Good programmers worry about data structures."
+
+- What is the core data? How do they relate?
+- Where does data flow? Who owns it? Who modifies it?
+- Is there unnecessary data copying or transformation?
+
+**Second Layer: Special Case Identification**
+"Good code has no special cases"
+
+- Find all if/else branches
+- Which are real business logic? Which are patches for bad design?
+- Can we redesign data structures to eliminate these branches?
+
+**Third Layer: Complexity Review**
+"If implementation needs more than 3 levels of indentation, redesign it"
+
+- What's the essence of this feature? (Explain in one sentence)
+- How many concepts does the current solution use?
+- Can it be reduced by half? Half again?
+
+**Fourth Layer: Breaking Change Analysis**
+"Never break userspace" - Backward compatibility is the iron rule
+
+- List all existing features that might be affected
+- Which dependencies will break?
+- How to improve without breaking anything?
+
+**Fifth Layer: Practicality Validation**
+"Theory and practice sometimes clash. Theory loses. Every single time."
+
+- Does this problem really exist in production?
+- How many users actually encounter this problem?
+- Does the solution's complexity match the problem's severity?
+
+## Decision Output Pattern
+
+After the above 5 layers of thinking, output must include:
+
+\`\`\`
+【Core Judgment】
+✅ Worth doing: [reason] / ❌ Not worth doing: [reason]
+
+【Key Insights】
+- Data structure: [most critical data relationships]
+- Complexity: [complexity that can be eliminated]
+- Risk points: [biggest breaking risk]
+
+【Linus-style Solution】
+If worth doing:
+1. First step is always simplifying data structures
+2. Eliminate all special cases
+3. Implement in the dumbest but clearest way
+4. Ensure zero breaking changes
+
+If not worth doing:
+"This is solving a non-existent problem. The real problem is [XXX]."
+\`\`\`
+
+## Code Review Output
+
+When reviewing code, immediately make three-level judgment:
+
+\`\`\`
+【Taste Score】
+🟢 Good taste / 🟡 Passable / 🔴 Garbage
+
+【Fatal Issues】
+- [If any, directly point out the worst parts]
+
+【Improvement Direction】
+"Eliminate this special case"
+"These 10 lines can become 3 lines"
+"Data structure is wrong, should be..."
+\`\`\`
+
+## Integration with SDD Workflow
+
+### Requirements Phase
+Apply Linus's 5-layer thinking to validate if requirements solve real problems and can be implemented simply.
+
+### Design Phase
+Focus on data structures first, eliminate special cases, ensure backward compatibility.
+
+### Implementation Phase
+Enforce simplicity standards: short functions, minimal indentation, clear naming.
+
+### Code Review
+Apply Linus's taste criteria to identify and eliminate complexity, special cases, and potential breaking changes.
+
+## Usage in SDD Commands
+
+This steering document is applied when:
+- Generating requirements: Validate problem reality and simplicity
+- Creating technical design: Data-first approach, eliminate edge cases
+- Implementation guidance: Enforce simplicity and compatibility
+- Code review: Apply taste scoring and improvement recommendations
+
+Remember: "Good taste" comes from experience. Question everything. Simplify ruthlessly. Never break userspace.
+`;
+        await steeringService.createSteeringDocument(projectPath, {
+            name: 'linus-review.md',
+            type: 'LINUS_REVIEW',
+            mode: 'ALWAYS',
+            content: linusReviewContent
+        });
+    }
+    // Commit guidelines
+    const commitPath = path.join(projectPath, '.kiro', 'steering', 'commit.md');
+    if (!fs.existsSync(commitPath)) {
+        const commitContent = `# Commit Message Guidelines
+
+Commit messages should follow a consistent format to improve readability and provide clear context about changes. Each commit message should start with a type prefix that indicates the nature of the change.
+
+## Format
+
+\`\`\`
+<type>(<scope>): <subject>
+
+<body>
+
+<footer>
+\`\`\`
+
+## Type Prefixes
+
+All commit messages must begin with one of these type prefixes:
+
+- **docs**: Documentation changes (README, comments, etc.)
+- **chore**: Maintenance tasks, dependency updates, etc.
+- **feat**: New features or enhancements
+- **fix**: Bug fixes
+- **refactor**: Code changes that neither fix bugs nor add features
+- **test**: Adding or modifying tests
+- **style**: Changes that don't affect code functionality (formatting, whitespace)
+- **perf**: Performance improvements
+- **ci**: Changes to CI/CD configuration files and scripts
+
+## Scope (Optional)
+
+The scope provides additional context about which part of the codebase is affected:
+
+- **cluster**: Changes to EKS cluster configuration
+- **db**: Database-related changes
+- **iam**: Identity and access management changes
+- **net**: Networking changes (VPC, security groups, etc.)
+- **k8s**: Kubernetes resource changes
+- **module**: Changes to reusable Terraform modules
+
+## Examples
+
+\`\`\`
+feat(cluster): add node autoscaling for billing namespace
+fix(db): correct MySQL parameter group settings
+docs(k8s): update network policy documentation
+chore: update terraform provider versions
+refactor(module): simplify EKS node group module
+\`\`\`
+
+## Best Practices
+
+1. Keep the subject line under 72 characters
+2. Use imperative mood in the subject line ("add" not "added")
+3. Don't end the subject line with a period
+4. Separate subject from body with a blank line
+5. Use the body to explain what and why, not how
+6. Reference issues and pull requests in the footer
+
+These guidelines help maintain a clean and useful git history that makes it easier to track changes and understand the project's evolution.
+`;
+        await steeringService.createSteeringDocument(projectPath, {
+            name: 'commit.md',
+            type: 'CUSTOM',
+            mode: 'ALWAYS',
+            content: commitContent
+        });
+    }
+    // Security checklist (OWASP baseline)
+    const securityPath = path.join(projectPath, '.kiro', 'steering', 'security-check.md');
+    if (!fs.existsSync(securityPath)) {
+        const securityContent = `# Security Check (OWASP Top 10 Aligned)
+
+Use this checklist during code generation and review. Avoid OWASP Top 10 issues by design.
+
+## A01: Broken Access Control
+- Enforce least privilege; validate authorization on every request/path
+- No client-side trust; never rely on hidden fields or disabled UI
+
+## A02: Cryptographic Failures
+- Use HTTPS/TLS; do not roll your own crypto
+- Store secrets in env vars/secret stores; never commit secrets
+
+## A03: Injection
+- Use parameterized queries/ORM and safe template APIs
+- Sanitize/validate untrusted input; avoid string concatenation in queries
+
+## A04: Insecure Design
+- Threat model critical flows; add security requirements to design
+- Fail secure; disable features by default until explicitly enabled
+
+## A05: Security Misconfiguration
+- Disable debug modes in prod; set secure headers (CSP, HSTS, X-Content-Type-Options)
+- Pin dependencies and lock versions; no default credentials
+
+## A06: Vulnerable & Outdated Components
+- Track SBOM/dependencies; run npm audit or a scanner regularly and patch
+- Prefer maintained libraries; remove unused deps
+
+## A07: Identification & Authentication Failures
+- Use vetted auth (OIDC/OAuth2); enforce MFA where applicable
+- Secure session handling (HttpOnly, Secure, SameSite cookies)
+
+## A08: Software & Data Integrity Failures
+- Verify integrity of third-party artifacts; signed releases when possible
+- Protect CI/CD: signed commits/tags, restricted tokens, principle of least privilege
+
+## A09: Security Logging & Monitoring Failures
+- Log authz/authn events and errors without sensitive data
+- Add alerts for suspicious activity; retain logs per policy
+
+## A10: Server-Side Request Forgery (SSRF)
+- Validate/deny-list outbound destinations; no direct fetch to arbitrary URLs
+- Use network egress controls; fetch via vetted proxies when needed
+
+## General Practices
+- Validate inputs (schema, length, type) and outputs (encoding)
+- Handle errors without leaking stack traces or secrets
+- Use content security best practices for templates/HTML
+- Add security tests where feasible (authz, input validation)
+`;
+        await steeringService.createSteeringDocument(projectPath, {
+            name: 'security-check.md',
+            type: 'CUSTOM',
+            mode: 'ALWAYS',
+            content: securityContent
+        });
+    }
+    // TDD guideline reinforcement
+    const tddPath = path.join(projectPath, '.kiro', 'steering', 'tdd-guideline.md');
+    if (!fs.existsSync(tddPath)) {
+        const tddContent = `# Test-Driven Development (TDD) Guideline
+
+## Purpose
+This steering document defines TDD practices and workflow to ensure test-first development throughout the project lifecycle.
+
+## TDD Fundamentals
+
+### Red-Green-Refactor Cycle
+1. **Red**: Write a failing test that defines desired behavior
+2. **Green**: Write minimal code to make the test pass
+3. **Refactor**: Improve code quality while keeping tests green
+
+### Core Principles
+- Write tests before implementation code
+- Test one thing at a time
+- Keep tests simple, readable, and maintainable
+- Run tests frequently during development
+- Never commit failing tests
+
+## Test-First Development Approach
+
+### Before Writing Code
+1. Understand the requirement/user story
+2. Define expected behavior and edge cases
+3. Write test cases that verify the behavior
+4. Run tests to confirm they fail (Red phase)
+
+### Implementation Flow
+\`\`\`
+Requirement → Test Case → Failing Test → Implementation → Passing Test → Refactor → Commit
+\`\`\`
+
+### Test Pyramid Strategy
+- **Unit Tests (70%)**: Test individual functions/methods in isolation
+- **Integration Tests (20%)**: Test component interactions and workflows
+- **E2E Tests (10%)**: Test complete user scenarios
+
+## Test Organization
+
+### Directory Structure
+\`\`\`
+src/
+  ├── module/
+  │   ├── service.ts
+  │   └── service.test.ts        # Unit tests co-located
+  └── __tests__/
+      ├── integration/           # Integration tests
+      └── e2e/                   # End-to-end tests
+\`\`\`
+
+### Naming Conventions
+- Test files: \`*.test.ts\` or \`*.spec.ts\`
+- Test suites: \`describe('ComponentName', () => {...})\`
+- Test cases: \`it('should behave in expected way', () => {...})\` or \`test('description', () => {...})\`
+- Use clear, descriptive names that explain what is being tested
+
+## Coverage Requirements
+
+### Minimum Thresholds
+- **Overall Coverage**: ≥ 80%
+- **Statements**: ≥ 80%
+- **Branches**: ≥ 75%
+- **Functions**: ≥ 80%
+- **Lines**: ≥ 80%
+
+### Critical Code Requirements
+- All public APIs: 100% coverage
+- Business logic: ≥ 90% coverage
+- Error handling: All error paths tested
+- Edge cases: All identified edge cases tested
+
+## Best Practices
+
+### Writing Good Tests
+- **Arrange-Act-Assert (AAA)**: Structure tests clearly
+- **Single Assertion**: Focus each test on one behavior
+- **Independence**: Tests should not depend on each other
+- **Repeatability**: Tests should produce same results every time
+- **Fast Execution**: Keep tests fast (< 100ms for unit tests)
+
+### Test Data Management
+- Use factories or builders for test data creation
+- Avoid hardcoded values; use constants or fixtures
+- Clean up test data after execution
+- Mock external dependencies (APIs, databases, file system)
+
+### Mocking and Stubbing
+- Mock external dependencies to isolate unit under test
+- Use dependency injection to enable testability
+- Stub time-dependent functions for deterministic tests
+- Verify mock interactions when testing behavior
+
+### Assertion Guidelines
+- Use specific, meaningful assertions
+- Prefer semantic matchers (\`toEqual\`, \`toContain\`, \`toThrow\`)
+- Include error messages for custom assertions
+- Test both positive and negative cases
+
+## Anti-Patterns to Avoid
+- Writing production code before tests
+- Over-mocking internal logic
+- Large, fragile integration tests without clear purpose
+- Ignoring refactor phase after tests pass
+
+## This Document Applies To
+- Requirements analysis (testability checks)
+- Design discussions (test-first architecture)
+- Implementation cycles (Red-Green-Refactor discipline)
+- Code reviews (reject changes without adequate tests)
+
+This document is **always** active and applies to all development phases. Every code change should follow TDD principles as defined here.
+`;
+        await steeringService.createSteeringDocument(projectPath, {
+            name: 'tdd-guideline.md',
+            type: 'CUSTOM',
+            mode: 'ALWAYS',
+            content: tddContent
+        });
+    }
+    // Core coding principles (SOLID, DRY, etc.)
+    const principlesPath = path.join(projectPath, '.kiro', 'steering', 'principles.md');
+    if (!fs.existsSync(principlesPath)) {
+        const principlesContent = `# Core Coding Principles and Patterns
+
+Follow SOLID, DRY, KISS, YAGNI, Separation of Concerns, and Modularity in all code.
+
+## SOLID Principles
+- **S**ingle Responsibility: One class, one reason to change
+- **O**pen/Closed: Open for extension, closed for modification
+- **L**iskov Substitution: Subtypes must be substitutable for base types
+- **I**nterface Segregation: Small, focused interfaces
+- **D**ependency Inversion: Depend on abstractions, not concretions
+
+## DRY (Don't Repeat Yourself)
+Extract common logic. Every knowledge piece has one authoritative representation.
+
+## KISS (Keep It Simple, Stupid)
+Simplicity over complexity. Avoid over-engineering.
+
+## YAGNI (You Aren't Gonna Need It)
+Implement only what's needed now. No speculative features.
+
+## Separation of Concerns
+Separate presentation, business logic, and data access layers.
+
+## Modularity
+High cohesion, low coupling. Encapsulate implementation details.
+
+## Review Checklist
+- [ ] Single Responsibility (SRP)
+- [ ] Can extend without modifying (OCP)
+- [ ] Dependencies use abstractions (DIP)
+- [ ] No duplicated logic (DRY)
+- [ ] Simple solution (KISS)
+- [ ] Only needed features (YAGNI)
+- [ ] Concerns separated (SoC)
+- [ ] Modules cohesive & loosely coupled
+
+Refer to full principles.md for detailed examples and language-specific guidance.
+`;
+        await steeringService.createSteeringDocument(projectPath, {
+            name: 'principles.md',
+            type: 'CUSTOM',
+            mode: 'ALWAYS',
+            content: principlesContent
+        });
+    }
+    // AGENTS.md convenience file (optional helper)
+    const agentsPath = path.join(projectPath, 'AGENTS.md');
+    if (!fs.existsSync(agentsPath)) {
+        let agentsContent = '';
+        const claudePath = path.join(projectPath, 'CLAUDE.md');
+        if (fs.existsSync(claudePath)) {
+            const claude = fs.readFileSync(claudePath, 'utf8');
+            agentsContent = claude
+                .replace(/# Claude Code Spec-Driven Development/g, '# AI Agent Spec-Driven Development')
+                .replace(/Claude Code/g, 'AI Agent')
+                .replace(/claude code/g, 'ai agent')
+                .replace(/\.claude\//g, '.ai agent/')
+                .replace(/\/claude/g, '/agent');
+        }
+        else {
+            agentsContent = `# AI Agent Spec-Driven Development
+
+Kiro-style Spec Driven Development implementation using ai agent slash commands, hooks and agents.
+
+## Project Context
+
+### Paths
+- Steering: \`.kiro/steering/\`
+- Specs: \`.kiro/specs/\`
+- Commands: \`.ai agent/commands/\`
+
+### Steering vs Specification
+
+**Steering** (\`.kiro/steering/\`) - Guide AI with project-wide rules and context
+**Specs** (\`.kiro/specs/\`) - Formalize development process for individual features
+
+### Active Specifications
+- Check \`.kiro/specs/\` for active specifications
+- Use \`/kiro:spec-status [feature-name]\` to check progress
+
+**Current Specifications:**
+- \`mcp-sdd-server\`: MCP server for spec-driven development across AI-agent CLIs and IDEs
+
+## Development Guidelines
+- Think in English, generate responses in English
+
+## Workflow
+
+### Phase 0: Steering (Optional)
+\`/kiro:steering\` - Create/update steering documents
+\`/kiro:steering-custom\` - Create custom steering for specialized contexts
+
+Note: Optional for new features or small additions. You can proceed directly to spec-init.
+
+### Phase 1: Specification Creation
+1. \`/kiro:spec-init [detailed description]\` - Initialize spec with detailed project description
+2. \`/kiro:spec-requirements [feature]\` - Generate requirements document
+3. \`/kiro:spec-design [feature]\` - Interactive: "Have you reviewed requirements.md? [y/N]"
+4. \`/kiro:spec-tasks [feature]\` - Interactive: Confirms both requirements and design review
+
+### Phase 2: Progress Tracking
+\`/kiro:spec-status [feature]\` - Check current progress and phases
+
+## Development Rules
+1. **Consider steering**: Run \`/kiro:steering\` before major development (optional for new features)
+2. **Follow 3-phase approval workflow**: Requirements → Design → Tasks → Implementation
+3. **Approval required**: Each phase requires human review (interactive prompt or manual)
+4. **No skipping phases**: Design requires approved requirements; Tasks require approved design
+5. **Update task status**: Mark tasks as completed when working on them
+6. **Keep steering current**: Run \`/kiro:steering\` after significant changes
+7. **Check spec compliance**: Use \`/kiro:spec-status\` to verify alignment
+
+## Steering Configuration
+
+### Current Steering Files
+Managed by \`/kiro:steering\` command. Updates here reflect command changes.
+
+### Active Steering Files
+- \`product.md\`: Always included - Product context and business objectives
+- \`tech.md\`: Always included - Technology stack and architectural decisions
+- \`structure.md\`: Always included - File organization and code patterns
+- \`linus-review.md\`: Always included - Ensuring code quality of the projects
+- \`commit.md\`: Always included - Ensuring the commit / merge request / pull request title and message context.
+
+### Custom Steering Files
+<!-- Added by /kiro:steering-custom command -->
+<!-- Format:
+- \`filename.md\`: Mode - Pattern(s) - Description
+  Mode: Always|Conditional|Manual
+  Pattern: File patterns for Conditional mode
+-->
+
+### Inclusion Modes
+- **Always**: Loaded in every interaction (default)
+- **Conditional**: Loaded for specific file patterns (e.g., "*.test.js")
+- **Manual**: Reference with \`@filename.md\` syntax`;
+        }
+        fs.writeFileSync(agentsPath, agentsContent);
+    }
+}
+//# sourceMappingURL=staticSteering.js.map

package/dist/application/services/staticSteering.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"staticSteering.js","sourceRoot":"","sources":["../../../src/application/services/staticSteering.ts"],"names":[],"mappings":"AAEA;;;GAGG;AACH,MAAM,CAAC,KAAK,UAAU,6BAA6B,CACjD,WAAmB,EACnB,eAAwC;IAExC,MAAM,EAAE,GAAG,MAAM,MAAM,CAAC,IAAI,CAAC,CAAC;IAC9B,MAAM,IAAI,GAAG,MAAM,MAAM,CAAC,MAAM,CAAC,CAAC;IAElC,6CAA6C;IAC7C,MAAM,eAAe,GAAG,IAAI,CAAC,IAAI,CAAC,WAAW,EAAE,OAAO,EAAE,UAAU,EAAE,iBAAiB,CAAC,CAAC;IACvF,IAAI,CAAC,EAAE,CAAC,UAAU,CAAC,eAAe,CAAC,EAAE,CAAC;QACpC,MAAM,kBAAkB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAyJ9B,CAAC;QAEE,MAAM,eAAe,CAAC,sBAAsB,CAAC,WAAW,EAAE;YACxD,IAAI,EAAE,iBAAiB;YACvB,IAAI,EAAE,cAAqB;YAC3B,IAAI,EAAE,QAAe;YACrB,OAAO,EAAE,kBAAkB;SAC5B,CAAC,CAAC;IACL,CAAC;IAED,oBAAoB;IACpB,MAAM,UAAU,GAAG,IAAI,CAAC,IAAI,CAAC,WAAW,EAAE,OAAO,EAAE,UAAU,EAAE,WAAW,CAAC,CAAC;IAC5E,IAAI,CAAC,EAAE,CAAC,UAAU,CAAC,UAAU,CAAC,EAAE,CAAC;QAC/B,MAAM,aAAa,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA2DzB,CAAC;QAEE,MAAM,eAAe,CAAC,sBAAsB,CAAC,WAAW,EAAE;YACxD,IAAI,EAAE,WAAW;YACjB,IAAI,EAAE,QAAe;YACrB,IAAI,EAAE,QAAe;YACrB,OAAO,EAAE,aAAa;SACvB,CAAC,CAAC;IACL,CAAC;IAED,sCAAsC;IACtC,MAAM,YAAY,GAAG,IAAI,CAAC,IAAI,CAAC,WAAW,EAAE,OAAO,EAAE,UAAU,EAAE,mBAAmB,CAAC,CAAC;IACtF,IAAI,CAAC,EAAE,CAAC,UAAU,CAAC,YAAY,CAAC,EAAE,CAAC;QACjC,MAAM,eAAe,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAiD3B,CAAC;QAEE,MAAM,eAAe,CAAC,sBAAsB,CAAC,WAAW,EAAE;YACxD,IAAI,EAAE,mBAAmB;YACzB,IAAI,EAAE,QAAe;YACrB,IAAI,EAAE,QAAe;YACrB,OAAO,EAAE,eAAe;SACzB,CAAC,CAAC;IACL,CAAC;IAED,8BAA8B;IAC9B,MAAM,OAAO,GAAG,IAAI,CAAC,IAAI,CAAC,WAAW,EAAE,OAAO,EAAE,UAAU,EAAE,kBAAkB,CAAC,CAAC;IAChF,IAAI,CAAC,EAAE,CAAC,UAAU,CAAC,OAAO,CAAC,EAAE,CAAC;QAC5B,MAAM,UAAU,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA+GtB,CAAC;QAEE,MAAM,eAAe,CAAC,sBAAsB,CAAC,WAAW,EAAE;YACxD,IAAI,EAAE,kBAAkB;YACxB,IAAI,EAAE,QAAe;YACrB,IAAI,EAAE,QAAe;YACrB,OAAO,EAAE,UAAU;SACpB,CAAC,CAAC;IACL,CAAC;IAED,4CAA4C;IAC5C,MAAM,cAAc,GAAG,IAAI,CAAC,IAAI,CAAC,WAAW,EAAE,OAAO,EAAE,UAAU,EAAE,eAAe,CAAC,CAAC;IACpF,IAAI,CAAC,EAAE,CAAC,UAAU,CAAC,cAAc,CAAC,EAAE,CAAC;QACnC,MAAM,iBAAiB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAqC7B,CAAC;QAEE,MAAM,eAAe,CAAC,sBAAsB,CAAC,WAAW,EAAE;YACxD,IAAI,EAAE,eAAe;YACrB,IAAI,EAAE,QAAe;YACrB,IAAI,EAAE,QAAe;YACrB,OAAO,EAAE,iBAAiB;SAC3B,CAAC,CAAC;IACL,CAAC;IAED,+CAA+C;IAC/C,MAAM,UAAU,GAAG,IAAI,CAAC,IAAI,CAAC,WAAW,EAAE,WAAW,CAAC,CAAC;IACvD,IAAI,CAAC,EAAE,CAAC,UAAU,CAAC,UAAU,CAAC,EAAE,CAAC;QAC/B,IAAI,aAAa,GAAG,EAAE,CAAC;QACvB,MAAM,UAAU,GAAG,IAAI,CAAC,IAAI,CAAC,WAAW,EAAE,WAAW,CAAC,CAAC;QACvD,IAAI,EAAE,CAAC,UAAU,CAAC,UAAU,CAAC,EAAE,CAAC;YAC9B,MAAM,MAAM,GAAG,EAAE,CAAC,YAAY,CAAC,UAAU,EAAE,MAAM,CAAC,CAAC;YACnD,aAAa,GAAG,MAAM;iBACnB,OAAO,CAAC,wCAAwC,EAAE,oCAAoC,CAAC;iBACvF,OAAO,CAAC,cAAc,EAAE,UAAU,CAAC;iBACnC,OAAO,CAAC,cAAc,EAAE,UAAU,CAAC;iBACnC,OAAO,CAAC,aAAa,EAAE,YAAY,CAAC;iBACpC,OAAO,CAAC,WAAW,EAAE,QAAQ,CAAC,CAAC;QACpC,CAAC;aAAM,CAAC;YACN,aAAa,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;qDA2E+B,CAAC;QAClD,CAAC;QACD,EAAE,CAAC,aAAa,CAAC,UAAU,EAAE,aAAa,CAAC,CAAC;IAC9C,CAAC;AACH,CAAC"}