cyrus-edge-worker 0.2.39 → 0.2.41

package/dist/prompts/subroutines/glab-mr.md

@@ -1,106 +0,0 @@
-# GitLab MR - Merge Request Management
-
-A draft MR exists and all changes have been committed and pushed. Now update the MR with a full description and optionally mark it as ready.
-
-## Your Tasks
-
-### 1. Get MR Information
-First, get the current MR URL and verify the target branch:
-```bash
-glab mr view --output json | jq -r '"\(.web_url) targeting \(.target_branch)"'
-```
-
-**IMPORTANT**: Verify that the MR targets the correct target branch (from `<base_branch>` in the issue context). If it doesn't, update it:
-```bash
-glab mr update --target-branch [correct target branch]
-```
-
-### 2. Update MR with Full Description
-Update the MR with a comprehensive description:
-```bash
-glab mr update --title "[descriptive title]" --description "[full description]"
-```
-
-**IMPORTANT: Assignee attribution**
-Check the `<assignee>` section from the issue context and add assignee information at the **very top** of the MR description, before the summary:
-
-- If a `<gitlab_username>` or `<github_username>` is available, format as: `Assignee: @username ([Display Name](linear_profile_url))`
-- If only a `<linear_profile_url>` is available (no username), format as: `Assignee: [Display Name](linear_profile_url)` using the `<linear_display_name>` and `<linear_profile_url>` values
-
-Follow this with a blank line, then the rest of the description. If no assignee information is available at all, skip this step.
-
-**IMPORTANT: Cyrus attribution marker**
-You MUST include the following hidden HTML comment somewhere in the MR description (e.g. at the very end). This marker is used to identify Cyrus-authored MRs for tracking purposes:
-```
-<!-- generated-by-cyrus -->
-```
-This marker is invisible when rendered on GitLab but allows the webhook to detect that this MR was authored by Cyrus, even when the MR is created under a human user's GitLab account.
-
-The MR description should include:
-- Summary of changes
-- Implementation approach
-- Testing performed
-- Any breaking changes or migration notes
-- Link to the Linear issue
-
-**IMPORTANT: Cyrus interaction tip**
-At the end of the MR description (before the `<!-- generated-by-cyrus -->` marker), include a tip section using the following exact format:
-
-```
----
-
-> **Tip:** I will respond to comments that @ mention @{{gitlab_bot_username}} on this MR. You can also leave review comments, and I will automatically wake up to address each comment.
-```
-
-This helps reviewers know how to interact with Cyrus directly on the MR.
-
-Ensure the MR has a clear, descriptive title (remove "WIP:" or "Draft:" prefix if present).
-
-### 3. Mark MR as Ready (CONDITIONAL)
-
-**CRITICAL**: Before marking the MR as ready, you MUST check the `<agent_guidance>` section in your context.
-
-**DO NOT mark the MR as ready if ANY of the following conditions are true:**
-- The agent guidance specifies `--draft` in MR creation commands
-- The agent guidance mentions keeping MRs as drafts
-- The user has explicitly requested the MR remain as a draft
-- The project instructions specify draft MRs
-
-**Only if none of the above conditions apply**, convert the draft MR to ready for review:
-```bash
-glab mr update --ready
-```
-
-### 4. Final Checks
-- Confirm the MR URL is valid and accessible
-- Verify all commits are included in the MR
-- Verify the MR targets the correct target branch (from `<base_branch>` in context)
-- Check that CI/CD pipelines start running (if applicable)
-
-## Important Notes
-
-- **A draft MR already exists** - you're updating it and optionally marking it ready
-- **All commits are pushed** - the changelog already includes the MR link
-- **Be thorough with the MR description** - it should be self-contained and informative
-- **RESPECT AGENT GUIDANCE** - if guidance specifies draft MRs, do NOT mark as ready
-- **Verify the correct target branch** - ensure MR targets the `<base_branch>` from context
-- Take as many turns as needed to complete these tasks
-
-## Expected Output
-
-**IMPORTANT: Do NOT post Linear comments.** Your output is for internal workflow only.
-
-Provide a brief completion message (1 sentence max) that includes the MR URL and status:
-
-If marked as ready:
-```
-MR ready at [MR URL].
-```
-
-If kept as draft (due to agent guidance or user request):
-```
-Draft MR updated at [MR URL] (kept as draft per guidance).
-```
-
-Example: "MR ready at https://gitlab.com/org/repo/-/merge_requests/123."
-Example: "Draft MR updated at https://gitlab.com/org/repo/-/merge_requests/123 (kept as draft per guidance)."

package/dist/prompts/subroutines/plan-summary.md

@@ -1,21 +0,0 @@
-# Plan Summary
-
-Present EITHER your clarifying questions OR your implementation plan:
-
-**Format in Linear-compatible markdown:**
-- Use `+++Section Name\n...\n+++` for collapsible sections
-- Use `https://linear.app/linear/profiles/username` for @mentions
-- Be clear and well-structured
-
-**If presenting clarifying questions:**
-- List specific questions that need answers
-- Explain why each question is important
-- Suggest possible approaches if helpful
-
-**If presenting implementation plan:**
-- Outline the implementation approach
-- List key files/components to modify
-- Note any risks or dependencies
-- Provide estimated complexity if relevant
-
-Keep it concise (3-5 paragraphs max).

package/dist/prompts/subroutines/preparation.md

@@ -1,16 +0,0 @@
-# Preparation Phase
-
-Analyze the request to determine if it needs clarification or can be planned:
-
-**If unclear requirements:**
-- Identify ambiguities and missing information
-- Formulate specific clarifying questions
-- Prepare questions for Linear posting
-
-**If requirements are clear:**
-- Break down the work into steps
-- Identify files/components to modify
-- Consider dependencies and edge cases
-- Prepare implementation plan for Linear posting
-
-Complete with: `Preparation complete - [ready to plan/needs clarification].`

package/dist/prompts/subroutines/question-answer.md

@@ -1,8 +0,0 @@
-# Answer Question
-
-Provide a clear, direct answer using investigation findings:
-- Present in Linear-compatible markdown (supports `+++collapsible+++`, @mentions via `https://linear.app/linear/profiles/username`)
-- Include code references with line numbers
-- Be complete but concise
-
-Don't mention the investigation process - just answer the question.

package/dist/prompts/subroutines/question-investigation.md

@@ -1,8 +0,0 @@
-# Investigate Question
-
-Gather information to answer the question (DON'T answer yet):
-- Search codebase for relevant files/functions
-- Read necessary files
-- Use tools if needed
-
-Complete with: `Investigation complete - gathered information from [sources].`

package/dist/prompts/subroutines/release-execution.md

@@ -1,81 +0,0 @@
-# Release Execution Phase
-
-You are performing a software release. Your task is to execute the release process for this project.
-
-## Step 1: Check for Release Instructions
-
-Check for release instructions in this priority order:
-
-### Priority 1: Release Skill
-1. Use the `Skill` tool to check for available skills (invoke with skill name like "release")
-2. Look for skills named "release", "publish", "deploy", or similar
-3. Check `.claude/skills/` directory for SKILL.md files related to releasing
-
-### Priority 2: CLAUDE.md
-1. Read `CLAUDE.md` in the project root
-2. Look for sections about "Release", "Publishing", "Deployment", or similar
-3. Follow any documented release procedures
-
-### Priority 3: README.md
-1. Read `README.md` in the project root
-2. Look for sections about "Release", "Publishing", "Deployment", or similar
-3. Follow any documented release procedures
-
-## Step 2: Execute Release
-
-### If a release skill exists:
-
-Invoke the release skill using the `Skill` tool:
-```
-skill: "release"
-```
-
-Follow the skill's instructions completely. The skill will contain project-specific release procedures including:
-- Version bumping
-- Changelog updates
-- Package publishing order
-- Git tagging
-- GitHub release creation
-
-### If CLAUDE.md or README.md has release instructions:
-
-Follow those documented instructions step by step. These may include:
-- Version bump procedures
-- Changelog update requirements
-- Build and test commands
-- Publishing commands
-- Tag and release creation
-
-### If NO release instructions exist anywhere:
-
-Use the `AskUserQuestion` tool to gather release information:
-
-```
-AskUserQuestion with questions:
-1. "How should releases be performed for this project?"
-   - Options: "npm publish", "GitHub Releases only", "Custom script", "Other"
-
-2. "What versioning scheme does this project use?"
-   - Options: "Semantic versioning (semver)", "CalVer (date-based)", "Other"
-```
-
-Based on the user's response, attempt a reasonable release workflow:
-- For npm projects: Check package.json for publish config
-- For monorepos: Look for workspace/lerna/nx configuration
-- For other projects: Follow user guidance
-
-## Guidelines
-
-- **Read CHANGELOG.md** if present to understand recent changes
-- **Check package.json** for version and publish configuration
-- **Look for existing release scripts** in package.json or scripts/
-- **Verify you're on the correct branch** before releasing
-- **Run tests/build** before publishing if not already verified
-
-## Constraints
-
-- **Do NOT guess** release procedures without skill or user input
-- **Do NOT publish** to registries without explicit confirmation
-- **Do NOT push tags** without verifying the release was successful
-
-Complete with: `Release execution complete - [what was released and where].`

package/dist/prompts/subroutines/release-summary.md

@@ -1,60 +0,0 @@
-# Release Summary
-
-Generate a summary of the release process for posting to Linear.
-
-## Your Task
-
-Create a clear summary of what was released:
-
-### 1. Release Information
-- Version released (e.g., v0.2.7)
-- Package(s) published
-- Registry/destination (npm, GitHub Releases, etc.)
-
-### 2. Changes Included
-- Brief summary of what's in this release
-- Link to changelog or release notes if available
-
-### 3. Post-Release Actions
-- Tags pushed
-- GitHub release created (with link if applicable)
-- Any follow-up tasks needed
-
-### 4. Linear Issue Updates
-- If Linear issues were mentioned in the changelog, note which issues should be moved from 'MergedUnreleased' to 'ReleasedMonitoring' status
-
-## Format Requirements
-
-- **Be concise** - focus on what was released
-- Use markdown formatting for readability
-- Include version numbers and links where helpful
-- **To mention someone**: Use `https://linear.app/linear/profiles/username` syntax
-
-## Constraints
-
-- **You have exactly 1 turn** - generate the summary in a single response
-- This is the final output that will be posted to Linear
-- Focus on the release outcome, not the process details
-
-## Example Format
-
-```
-## Release Complete
-
-**Version**: v0.2.7
-**Published to**: npm (@cyrus-ai/*)
-
-### What's Included
-- Feature X improvements
-- Bug fix for Y
-- Performance optimizations
-
-### Links
-- [GitHub Release](https://github.com/org/repo/releases/tag/v0.2.7)
-- [Changelog](./CHANGELOG.md)
-
-### Linear Issues
-The following issues can be moved to 'ReleasedMonitoring':
-- CYPACK-XXX
-- CYPACK-YYY
-```

package/dist/prompts/subroutines/user-testing-summary.md

@@ -1,87 +0,0 @@
-# User Testing Summary - Final Response for Linear
-
-Generate a comprehensive summary of the user testing session for posting to Linear.
-
-## Your Task
-
-Create a clear, structured summary that covers:
-
-### 1. Testing Overview
-- What was tested (features, workflows, integrations)
-- Testing approach and methodology used
-- Scope of the testing session
-
-### 2. Test Results
-- Total number of scenarios/tests executed
-- Pass/fail breakdown
-- Key observations and findings
-
-### 3. Issues Discovered (if any)
-- Description of each issue found
-- Severity assessment (critical/high/medium/low)
-- Reproduction steps for failures
-- Relevant error messages or logs
-
-### 4. Recommendations
-- Suggested fixes or follow-up actions
-- Areas that may need additional testing
-- Any improvements identified during testing
-
-## Format Requirements
-
-- **Be concise but comprehensive** - aim for a well-structured summary
-- Use clear, professional language suitable for Linear
-- Use markdown formatting for readability
-- Focus on what matters to stakeholders
-- **To mention someone**: Use `https://linear.app/linear/profiles/username` syntax where `username` is the Linear username (e.g., `https://linear.app/linear/profiles/alice` to mention @alice)
-
-## Constraints
-
-- **You have exactly 1 turn** - generate the summary in a single response
-- This is the final output that will be posted to Linear
-- Make it informative and actionable
-
-## Example Format
-
-```
-## Testing Summary
-
-[Brief overview of what was tested and the testing approach]
-
-### Results
-
-| Status | Count |
-|--------|-------|
-| ✅ Passed | X |
-| ❌ Failed | Y |
-| ⚠️ Observations | Z |
-
-+++Test Details
-- [Test 1]: [Result and notes]
-- [Test 2]: [Result and notes]
-+++
-
-+++Issues Found
-1. **[Issue title]** - [Severity]
-   - Description: [What went wrong]
-   - Steps to reproduce: [How to trigger]
-   - Notes: [Additional context]
-+++
-
-## Recommendations
-
-[Next steps and suggested actions]
-
-## Status
-
-[Overall testing status and conclusions]
-```
-
-## Collapsible Sections
-
-**IMPORTANT**: When creating your summary, make the following sections collapsible (collapsed by default):
-
-- **"Test Details"** section - Wrap with `+++Test Details\n...\n+++`
-- **"Issues Found"** section - Wrap with `+++Issues Found\n...\n+++`
-
-This keeps the summary concise while preserving detailed information for those who want to expand and read it.

package/dist/prompts/subroutines/user-testing.md

@@ -1,48 +0,0 @@
-# User Testing Phase
-
-Perform testing as requested by the user. This subroutine allows interactive testing based on user instructions.
-
-## Your Task
-
-Execute the testing activities requested by the user:
-
-### 1. Understand the Testing Request
-- Review the user's testing requirements from the issue description
-- Identify what needs to be tested (features, workflows, integrations, etc.)
-- Clarify the scope and success criteria for the testing
-
-### 2. Execute Tests
-- Run the tests or testing scenarios as requested
-- Follow any specific testing instructions provided by the user
-- Document test results and observations as you go
-- Note any unexpected behavior or issues discovered
-
-### 3. Interactive Testing
-- Be responsive to user feedback during the testing process
-- The user may provide additional instructions or adjustments mid-session
-- Adapt your testing approach based on user guidance
-- Report progress and findings to enable real-time feedback
-
-### 4. Document Findings
-- Track all test results (pass/fail/observations)
-- Note any bugs, issues, or areas of concern discovered
-- Document reproduction steps for any failures
-- Capture relevant logs, error messages, or screenshots if applicable
-
-## Important Notes
-
-- **Do NOT commit or push changes** - that happens in a separate subroutine if needed
-- **Do NOT create or update PRs** - focus on testing only
-- **Be thorough and methodical** - test systematically based on user requirements
-- **Communicate clearly** - report findings as you discover them
-- **Follow user instructions** - this is a user-driven testing session
-
-## Expected Output
-
-Provide a completion message summarizing the testing session:
-
-```
-Testing complete - [X] scenarios tested, [Y] passed, [Z] issues found.
-```
-
-Example: "Testing complete - 5 scenarios tested, 4 passed, 1 issue found (login redirect failure)."

package/dist/prompts/subroutines/validation-fixer.md

@@ -1,56 +0,0 @@
-# Validation Fixer - Fix Verification Failures
-
-The previous verification step failed. Your task is to fix the specific issues identified.
-
-## Failure Context
-
-<validation_failure>
-{{FAILURE_REASON}}
-</validation_failure>
-
-<iteration_info>
-Attempt {{ITERATION}} of {{MAX_ITERATIONS}}
-</iteration_info>
-
-{{#if PREVIOUS_ATTEMPTS}}
-<previous_attempts>
-{{PREVIOUS_ATTEMPTS}}
-</previous_attempts>
-{{/if}}
-
-## Your Task
-
-Fix ONLY the specific issues mentioned in the failure reason above. Do not make unrelated changes.
-
-### Guidelines
-
-1. **Focus on the specific failures** - Address only what failed, nothing else
-2. **Read error messages carefully** - The failure reason contains specific error details
-3. **Make minimal changes** - Fix the issue with the smallest possible change
-4. **Avoid introducing new issues** - Be careful not to break other things while fixing
-5. **If you've seen this error before** - Check the previous attempts to understand what didn't work
-
-### Common Fix Patterns
-
-- **Acceptance criteria failures**: Re-read the specific criterion that failed, understand what's missing, and implement the missing functionality
-- **Test failures**: Read the failing test, understand the expected vs actual behavior, fix the code or test
-- **TypeScript errors**: Check the type definitions and ensure proper typing
-- **Linting errors**: Run the linter with auto-fix first, then manually fix what remains
-- **Build errors**: Check imports, exports, and module resolution
-
-## Important Notes
-
-- **Do NOT commit or push changes** - just fix the issues
-- **Do NOT create or update PRs** - that happens in a later subroutine
-- **Do NOT post Linear comments** - your output is for internal workflow only
-- Be thorough but efficient - we have limited retry attempts
-
-## Expected Output
-
-After fixing the issues, provide a brief completion message (1 sentence max):
-
-```
-Fixed: [brief description of what was fixed]
-```
-
-Example: "Fixed: Corrected type error in UserService.ts by adding missing optional chaining"

package/dist/prompts/subroutines/verbose-summary.md

@@ -1,46 +0,0 @@
-# Summary Phase - Final Response Generation
-
-You have completed both the primary work and closure review. Now generate a comprehensive summary of everything accomplished.
-
-## Your Task
-
-Create a clear, concise summary for Linear that covers:
-
-### 1. Work Completed
-- What features were implemented or bugs were fixed
-- Key technical decisions made
-- Any changes to the original scope or approach
-
-### 2. Implementation Details
-- High-level overview of the implementation approach
-- Key files modified or created
-- Any new dependencies, tools, or patterns introduced
-
-### 3. Testing & Quality Assurance
-- What testing was performed
-- Test results and coverage
-- Any known limitations or edge cases
-
-### 4. Pull Request Information
-- Link to the GitHub PR
-- Status of the PR (ready for review, needs attention, etc.)
-- Any special review notes or areas that need extra attention
-
-### 5. Next Steps (if applicable)
-- Any follow-up tasks or future improvements identified
-- Configuration or deployment steps required
-- Notes for reviewers
-
-## Format Requirements
-
-- Use clear, professional language suitable for Linear
-- Be concise but comprehensive
-- Use markdown formatting for readability
-- Focus on what matters to stakeholders and reviewers
-- **To mention someone**: Use `https://linear.app/linear/profiles/username` syntax where `username` is the Linear username (e.g., `https://linear.app/linear/profiles/alice` to mention @alice)
-
-## Constraints
-
-- **You have exactly 1 turn** - generate the summary in a single response
-- This is the final output that will be posted to Linear
-- Make it informative and actionable

package/dist/prompts/subroutines/verifications.md

@@ -1,77 +0,0 @@
-# Verifications - Testing and Quality Checks
-
-You have completed the primary work on this issue. Now perform thorough verification to ensure everything works correctly and meets quality standards.
-
-## Your Tasks
-
-### 1. Acceptance Criteria Validation (CRITICAL - Do This First)
-
-Use the issue tracker `get_issue` tool to fetch the current issue details. The issue identifier is available in your conversation context (e.g., "CYPACK-123").
-
-**Steps:**
-1. Fetch the issue using the issue tracker `get_issue` tool with the issue identifier
-2. Extract ALL acceptance criteria from the issue description (look for bullet points, numbered lists, checkboxes, or sections labeled "Acceptance Criteria", "Requirements", "Definition of Done", etc.)
-3. For EACH acceptance criterion, verify that the implementation satisfies it
-4. Document which criteria pass and which fail
-
-**Important:** If no explicit acceptance criteria are found, extract implied requirements from the issue title and description. Every issue has requirements that must be verified.
-
-### 2. Code Quality Review
-- Review all code changes for quality, consistency, and best practices
-- Ensure proper error handling and edge cases are covered
-- Verify code follows project conventions and patterns
-- Check for any code smells or areas that need refactoring
-
-### 3. Testing & Verification
-- Run all relevant tests and ensure they pass
-- **Do NOT fix failing tests yourself** - just report the failures
-- Verify the implementation meets all requirements from the issue description
-- Check that existing functionality wasn't broken by the changes
-
-### 4. Linting & Type Checking
-- Run linting tools and report any issues
-- Run TypeScript type checking (if applicable) and report any errors
-- **Do NOT fix linting/type errors yourself** - just report them
-
-### 5. Documentation Review
-- Check if relevant documentation needs updating
-- Note any debug code, console.logs, or commented-out sections that should be removed
-
-## Important Notes
-
-- **Do NOT commit or push changes** - that happens in a later subroutine
-- **Do NOT create or update PRs** - that also happens in a later subroutine
-- **Do NOT touch the changelog** - a separate subroutine handles changelog updates
-- **Do NOT fix issues yourself** - your job is to verify and report
-- **Do NOT post Linear comments** - your output is for internal workflow only
-- Be thorough in running and reporting verification results
-- **Acceptance criteria validation is MANDATORY** - failing to validate against acceptance criteria counts as a failed verification
-
-## Expected FINAL Message Output Format
-
-You MUST respond in your FINAL message with a JSON object in exactly this format:
-
-```json
-{
-  "pass": true,
-  "reason": "All 3 acceptance criteria met. 47 tests passing, linting clean, types valid"
-}
-```
-
-Or if there are failures:
-
-```json
-{
-  "pass": false,
-  "reason": "Acceptance criteria failed: 'Support pagination' not implemented. TypeScript error in src/services/UserService.ts:42 - Property 'email' does not exist on type 'User'. 3 tests failing in auth.test.ts"
-}
-```
-
-### Output Rules
-
-1. **pass**: Set to `true` if ALL verifications pass (including ALL acceptance criteria), `false` if ANY fail
-2. **reason**:
-   - If passing: Brief summary that mentions acceptance criteria status, e.g., "All X acceptance criteria met. Y tests passing, linting clean, types valid"
-   - If failing: Specific error details that would help someone fix the issues. **Always list any failing acceptance criteria first**, then other failures.
-
-**CRITICAL**: Your entire final response message must be valid JSON matching the schema above. Do not include any text before or after the JSON.

package/dist/validation/ValidationLoopController.d.ts

@@ -1,54 +0,0 @@
-/**
- * ValidationLoopController - Orchestrates the validation loop with retry logic
- *
- * This controller manages the validation loop that runs verifications and fixes
- * up to a configurable maximum number of iterations.
- */
-import type { ValidationFixerContext, ValidationLoopConfig, ValidationLoopState, ValidationResult } from "./types.js";
-import { VALIDATION_RESULT_SCHEMA } from "./types.js";
-/**
- * Parse a validation result from an agent's response
- *
- * Supports multiple formats:
- * 1. Native structured output (message.structured_output) - validated with Zod
- * 2. JSON in response text - validated with Zod
- * 3. Fallback prompt engineering extraction (for Gemini and other runners)
- */
-export declare function parseValidationResult(response: string | undefined, structuredOutput?: unknown): ValidationResult;
-/**
- * Get the JSON schema for validation results
- */
-export declare function getValidationResultSchema(): typeof VALIDATION_RESULT_SCHEMA;
-/**
- * Load the validation-fixer prompt template
- */
-export declare function loadValidationFixerPrompt(): string;
-/**
- * Render the validation-fixer prompt with context
- */
-export declare function renderValidationFixerPrompt(context: ValidationFixerContext): string;
-/**
- * Create initial validation loop state
- */
-export declare function createInitialState(): ValidationLoopState;
-/**
- * Record a validation attempt and determine next action
- */
-export declare function recordAttempt(state: ValidationLoopState, result: ValidationResult, config?: ValidationLoopConfig): ValidationLoopState;
-/**
- * Get the fixer context for the current state
- */
-export declare function getFixerContext(state: ValidationLoopState, config?: ValidationLoopConfig): ValidationFixerContext | null;
-/**
- * Check if the validation loop should continue
- */
-export declare function shouldContinueLoop(state: ValidationLoopState): boolean;
-/**
- * Check if we should proceed to the next subroutine after validation
- */
-export declare function shouldProceedAfterValidation(state: ValidationLoopState, config?: ValidationLoopConfig): boolean;
-/**
- * Get a summary of the validation loop execution
- */
-export declare function getValidationSummary(state: ValidationLoopState): string;
-//# sourceMappingURL=ValidationLoopController.d.ts.map

package/dist/validation/ValidationLoopController.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"ValidationLoopController.d.ts","sourceRoot":"","sources":["../../src/validation/ValidationLoopController.ts"],"names":[],"mappings":"AAAA;;;;;GAKG;AAKH,OAAO,KAAK,EACX,sBAAsB,EACtB,oBAAoB,EACpB,mBAAmB,EACnB,gBAAgB,EAChB,MAAM,YAAY,CAAC;AACpB,OAAO,EAEN,wBAAwB,EAExB,MAAM,YAAY,CAAC;AAMpB;;;;;;;GAOG;AACH,wBAAgB,qBAAqB,CACpC,QAAQ,EAAE,MAAM,GAAG,SAAS,EAC5B,gBAAgB,CAAC,EAAE,OAAO,GACxB,gBAAgB,CAqGlB;AAED;;GAEG;AACH,wBAAgB,yBAAyB,IAAI,OAAO,wBAAwB,CAE3E;AAED;;GAEG;AACH,wBAAgB,yBAAyB,IAAI,MAAM,CASlD;AAED;;GAEG;AACH,wBAAgB,2BAA2B,CAC1C,OAAO,EAAE,sBAAsB,GAC7B,MAAM,CA4BR;AAED;;GAEG;AACH,wBAAgB,kBAAkB,IAAI,mBAAmB,CAOxD;AAED;;GAEG;AACH,wBAAgB,aAAa,CAC5B,KAAK,EAAE,mBAAmB,EAC1B,MAAM,EAAE,gBAAgB,EACxB,MAAM,GAAE,oBAAqD,GAC3D,mBAAmB,CAmCrB;AAED;;GAEG;AACH,wBAAgB,eAAe,CAC9B,KAAK,EAAE,mBAAmB,EAC1B,MAAM,GAAE,oBAAqD,GAC3D,sBAAsB,GAAG,IAAI,CAmB/B;AAED;;GAEG;AACH,wBAAgB,kBAAkB,CAAC,KAAK,EAAE,mBAAmB,GAAG,OAAO,CAEtE;AAED;;GAEG;AACH,wBAAgB,4BAA4B,CAC3C,KAAK,EAAE,mBAAmB,EAC1B,MAAM,GAAE,oBAAqD,GAC3D,OAAO,CAWT;AAED;;GAEG;AACH,wBAAgB,oBAAoB,CAAC,KAAK,EAAE,mBAAmB,GAAG,MAAM,CAcvE"}