@bugzy-ai/bugzy 1.9.2 → 1.9.4

package/dist/tasks/index.js.map

@@ -1 +1 @@
-{"version":3,"sources":["../../src/tasks/steps/types.ts","../../src/tasks/constants.ts","../../src/tasks/library/generate-test-cases.ts","../../src/tasks/library/generate-test-plan.ts","../../src/tasks/library/handle-message.ts","../../src/tasks/library/process-event.ts","../../src/tasks/library/run-tests.ts","../../src/tasks/library/verify-changes.ts","../../src/tasks/library/onboard-testing.ts","../../src/tasks/library/explore-application.ts","../../src/tasks/index.ts"],"sourcesContent":["/**\r\n * Step Module Types\r\n * Type definitions for atomic, composable task steps\r\n */\r\n\r\nimport type { TaskFrontmatter } from '../types';\r\n\r\n/**\r\n * Step category for organization and filtering\r\n */\r\nexport type StepCategory =\r\n  | 'security' // Security notices and warnings\r\n  | 'setup' // Loading context, reading artifacts\r\n  | 'exploration' // Exploring the application\r\n  | 'clarification' // Handling ambiguity and questions\r\n  | 'execution' // Running tests, parsing results\r\n  | 'generation' // Creating test plans, cases, code\r\n  | 'communication' // Team notifications\r\n  | 'maintenance'; // Knowledge base updates, cleanup\r\n\r\n/**\r\n * TaskStep - Atomic, reusable unit of work within a task\r\n *\r\n * Steps are the building blocks of composed tasks. Each step represents\r\n * a discrete piece of work with clear instructions.\r\n */\r\nexport interface TaskStep {\r\n  /**\r\n   * Unique identifier for the step (kebab-case)\r\n   * Examples: 'read-knowledge-base', 'triage-failures', 'run-playwright-tests'\r\n   */\r\n  id: string;\r\n\r\n  /**\r\n   * Human-readable step title (used in generated markdown headers)\r\n   * Examples: 'Read Knowledge Base', 'Triage Failed Tests'\r\n   */\r\n  title: string;\r\n\r\n  /**\r\n   * Step category for organization\r\n   */\r\n  category: StepCategory;\r\n\r\n  /**\r\n   * Step content - the actual instructions as markdown string.\r\n   *\r\n   * Supported placeholders:\r\n   * - {{STEP_NUMBER}} - Auto-replaced with computed step number during assembly\r\n   * - {{INVOKE_*}} - Subagent invocation placeholders (e.g., {{INVOKE_TEST_DEBUGGER_FIXER}})\r\n   * - $ARGUMENTS - Task arguments from user input\r\n   */\r\n  content: string;\r\n\r\n  /**\r\n   * Optional subagent role this step requires to be included.\r\n   * If specified, step is only included when this subagent is configured.\r\n   *\r\n   * Use for steps that make no sense without the subagent.\r\n   * Example: 'log-product-bugs' step requires 'issue-tracker' subagent\r\n   */\r\n  requiresSubagent?: string;\r\n\r\n  /**\r\n   * Subagent roles that this step invokes (for MCP derivation).\r\n   * Different from requiresSubagent - this lists subagents the step calls\r\n   * via {{INVOKE_*}} placeholders, not what makes the step available.\r\n   */\r\n  invokesSubagents?: string[];\r\n\r\n  /**\r\n   * Tags for categorization, filtering, and step discovery.\r\n   * Examples: ['setup', 'execution', 'optional', 'triage']\r\n   */\r\n  tags?: string[];\r\n}\r\n\r\n/**\r\n * StepReferenceObject - Reference to a step in STEP_LIBRARY with per-usage configuration\r\n */\r\nexport interface StepReferenceObject {\r\n  /**\r\n   * The step ID to include from STEP_LIBRARY\r\n   */\r\n  stepId: string;\r\n\r\n  /**\r\n   * Override the step title for this specific usage\r\n   */\r\n  title?: string;\r\n\r\n  /**\r\n   * Additional content to append after the step\r\n   */\r\n  appendContent?: string;\r\n\r\n  /**\r\n   * Make this step conditional on a subagent being configured.\r\n   * Different from step's requiresSubagent - this is per-task configuration.\r\n   */\r\n  conditionalOnSubagent?: string;\r\n}\r\n\r\n/**\r\n * InlineStep - Step with body defined directly in the task definition\r\n * Use for task-specific content like headers, arguments, or unique steps\r\n */\r\nexport interface InlineStep {\r\n  /**\r\n   * Discriminator to identify inline steps\r\n   */\r\n  inline: true;\r\n\r\n  /**\r\n   * Step title (becomes ### Step N: {title})\r\n   */\r\n  title: string;\r\n\r\n  /**\r\n   * Step body content (markdown)\r\n   */\r\n  content: string;\r\n\r\n  /**\r\n   * Optional category for metadata/filtering\r\n   */\r\n  category?: StepCategory;\r\n\r\n  /**\r\n   * Make this step conditional on a subagent being configured\r\n   */\r\n  conditionalOnSubagent?: string;\r\n}\r\n\r\n/**\r\n * StepReference - How tasks reference steps in their composition\r\n *\r\n * Can be:\r\n * - Simple string (step ID from STEP_LIBRARY)\r\n * - StepReferenceObject (reference with overrides)\r\n * - InlineStep (step with body defined inline)\r\n */\r\nexport type StepReference = string | StepReferenceObject | InlineStep;\r\n\r\n\r\n/**\r\n * ComposedTaskTemplate - Task built from step composition\r\n *\r\n * This is the new task format that replaces monolithic baseContent strings\r\n * with an array of step references.\r\n */\r\nexport interface ComposedTaskTemplate {\r\n  /**\r\n   * Unique task identifier (kebab-case)\r\n   */\r\n  slug: string;\r\n\r\n  /**\r\n   * Human-readable task name\r\n   */\r\n  name: string;\r\n\r\n  /**\r\n   * Brief task description\r\n   */\r\n  description: string;\r\n\r\n  /**\r\n   * Frontmatter for slash command generation\r\n   */\r\n  frontmatter: TaskFrontmatter;\r\n\r\n  /**\r\n   * Ordered list of step references that compose this task.\r\n   * Steps are assembled in order with auto-generated step numbers.\r\n   */\r\n  steps: StepReference[];\r\n\r\n  /**\r\n   * Required subagents - task fails to build without these.\r\n   * Instructions for required subagents should be embedded in step content.\r\n   */\r\n  requiredSubagents: string[];\r\n\r\n  /**\r\n   * Optional subagents - enhance task when configured.\r\n   * Steps using these are conditionally included.\r\n   */\r\n  optionalSubagents?: string[];\r\n\r\n  /**\r\n   * Task slugs that can be invoked during execution.\r\n   */\r\n  dependentTasks?: string[];\r\n}\r\n\r\n/**\r\n * Normalized step reference (internal use for library steps)\r\n */\r\nexport interface NormalizedStepReference {\r\n  stepId: string;\r\n  title?: string;\r\n  appendContent?: string;\r\n  conditionalOnSubagent?: string;\r\n}\r\n\r\n/**\r\n * Type guard to check if a StepReference is an InlineStep\r\n */\r\nexport function isInlineStep(ref: StepReference): ref is InlineStep {\r\n  return typeof ref === 'object' && 'inline' in ref && ref.inline === true;\r\n}\r\n\r\n/**\r\n * Type guard to check if a StepReference is a StepReferenceObject\r\n */\r\nexport function isStepReferenceObject(ref: StepReference): ref is StepReferenceObject {\r\n  return typeof ref === 'object' && 'stepId' in ref;\r\n}\r\n\r\n/**\r\n * Normalize a step reference to its full object form (for library steps only)\r\n * Returns null for inline steps - use isInlineStep to check first\r\n */\r\nexport function normalizeStepReference(ref: StepReference): NormalizedStepReference | null {\r\n  if (isInlineStep(ref)) {\r\n    return null; // Inline steps don't normalize to NormalizedStepReference\r\n  }\r\n  if (typeof ref === 'string') {\r\n    return { stepId: ref };\r\n  }\r\n  return ref as StepReferenceObject;\r\n}\r\n","/**\r\n * Task Slug Constants\r\n * Single source of truth for all task identifiers\r\n *\r\n * These constants should be used throughout the codebase instead of hardcoded strings\r\n * to ensure type safety and prevent typos.\r\n */\r\nexport const TASK_SLUGS = {\r\n  EXPLORE_APPLICATION: 'explore-application',\r\n  ONBOARD_TESTING: 'onboard-testing',\r\n  GENERATE_TEST_CASES: 'generate-test-cases',\r\n  GENERATE_TEST_PLAN: 'generate-test-plan',\r\n  HANDLE_MESSAGE: 'handle-message',\r\n  PROCESS_EVENT: 'process-event',\r\n  RUN_TESTS: 'run-tests',\r\n  VERIFY_CHANGES: 'verify-changes',\r\n  /** @deprecated Use ONBOARD_TESTING instead */\r\n  FULL_TEST_COVERAGE: 'onboard-testing',\r\n} as const;\r\n\r\n/**\r\n * Type for task slugs\r\n * Ensures only valid task slugs can be used\r\n */\r\nexport type TaskSlug = typeof TASK_SLUGS[keyof typeof TASK_SLUGS];\r\n","/**\r\n * Generate Test Cases Task (Composed)\r\n * Generate both manual test case documentation AND automated Playwright test scripts\r\n */\r\n\r\nimport type { ComposedTaskTemplate } from '../steps/types';\r\nimport { TASK_SLUGS } from '../constants';\r\n\r\nexport const generateTestCasesTask: ComposedTaskTemplate = {\r\n  slug: TASK_SLUGS.GENERATE_TEST_CASES,\r\n  name: 'Generate Test Cases',\r\n  description: 'Generate manual test case documentation AND automated Playwright test scripts from test plan',\r\n\r\n  frontmatter: {\r\n    description: 'Generate manual test case documentation AND automated Playwright test scripts from test plan',\r\n    'argument-hint': '--type [exploratory|functional|regression|smoke] --focus [optional-feature]',\r\n  },\r\n\r\n  steps: [\r\n    // Step 1: Overview (inline)\r\n    {\r\n      inline: true,\r\n      title: 'Generate Test Cases Overview',\r\n      content: `Generate comprehensive test artifacts including BOTH manual test case documentation AND automated Playwright test scripts.\r\n\r\nThis command generates:\r\n1. **Manual Test Case Documentation** (in \\`./test-cases/\\`) - Human-readable test cases in markdown format\r\n2. **Automated Playwright Tests** (in \\`./tests/specs/\\`) - Executable TypeScript test scripts\r\n3. **Page Object Models** (in \\`./tests/pages/\\`) - Reusable page classes for automated tests\r\n4. **Supporting Files** (fixtures, helpers, components) - As needed for test automation`,\r\n    },\r\n    // Step 2: Security Notice (library)\r\n    'security-notice',\r\n    // Step 3: Arguments (inline)\r\n    {\r\n      inline: true,\r\n      title: 'Arguments',\r\n      content: `Arguments: $ARGUMENTS\r\n\r\n**Parse Arguments:**\r\nExtract the following from arguments:\r\n- **type**: Test type (exploratory, functional, regression, smoke) - defaults to functional\r\n- **focus**: Optional specific feature or section to focus on`,\r\n    },\r\n    // Step 4: Knowledge Base Read (library)\r\n    'read-knowledge-base',\r\n    // Step 5: Gather Context (inline)\r\n    {\r\n      inline: true,\r\n      title: 'Gather Context',\r\n      content: `**1.1 Read Test Plan**\r\nRead the test plan from \\`test-plan.md\\` to understand:\r\n- Test items and features\r\n- Testing approach and automation strategy\r\n- Test Automation Strategy section (automated vs exploratory)\r\n- Pass/fail criteria\r\n- Test environment and data requirements\r\n- Automation decision criteria\r\n\r\n**1.2 Check Existing Test Cases and Tests**\r\n- List all files in \\`./test-cases/\\` to understand existing manual test coverage\r\n- List all files in \\`./tests/specs/\\` to understand existing automated tests\r\n- Determine next test case ID (TC-XXX format)\r\n- Identify existing Page Objects in \\`./tests/pages/\\`\r\n- Avoid creating overlapping test cases or duplicate automation`,\r\n    },\r\n    // Step 6: Documentation Researcher (conditional inline)\r\n    {\r\n      inline: true,\r\n      title: 'Gather Product Documentation',\r\n      content: `{{INVOKE_DOCUMENTATION_RESEARCHER}} to gather comprehensive product documentation:\r\n\r\n\\`\\`\\`\r\nExplore all available product documentation, specifically focusing on:\r\n- UI elements and workflows\r\n- User interactions and navigation paths\r\n- Form fields and validation rules\r\n- Error messages and edge cases\r\n- Authentication and authorization flows\r\n- Business rules and constraints\r\n- API endpoints for test data setup\r\n\\`\\`\\``,\r\n      conditionalOnSubagent: 'documentation-researcher',\r\n    },\r\n    // Step 7: Exploration Protocol (from library)\r\n    'exploration-protocol',\r\n    // Step 8: Clarification Protocol (from library)\r\n    'clarification-protocol',\r\n    // Step 9: Organize Test Scenarios (inline - task-specific)\r\n    {\r\n      inline: true,\r\n      title: 'Organize Test Scenarios by Area',\r\n      content: `Based on exploration and documentation, organize test scenarios by feature area/component:\r\n\r\n**Group scenarios into areas** (e.g., Authentication, Dashboard, Checkout, Profile Management):\r\n- Each area should be a logical feature grouping\r\n- Areas should be relatively independent for parallel test execution\r\n- Consider the application's navigation structure and user flows\r\n\r\n**For each area, identify scenarios**:\r\n\r\n1. **Critical User Paths** (must automate as smoke tests):\r\n   - Login/authentication flows\r\n   - Core feature workflows\r\n   - Data creation/modification flows\r\n   - Critical business transactions\r\n\r\n2. **Happy Path Scenarios** (automate for regression):\r\n   - Standard user workflows\r\n   - Common use cases\r\n   - Typical data entry patterns\r\n\r\n3. **Error Handling Scenarios** (evaluate automation ROI):\r\n   - Validation error messages\r\n   - Network error handling\r\n   - Permission/authorization errors\r\n\r\n4. **Edge Cases** (consider manual testing):\r\n   - Rare scenarios (<1% occurrence)\r\n   - Complex exploratory scenarios\r\n   - Visual/UX validation requiring judgment\r\n   - Features in heavy flux\r\n\r\n**Output**: Test scenarios organized by area with automation decisions for each\r\n\r\nExample structure:\r\n- **Authentication**: TC-001 Valid login (smoke, automate), TC-002 Invalid password (automate), TC-003 Password reset (automate)\r\n- **Dashboard**: TC-004 View dashboard widgets (smoke, automate), TC-005 Filter data by date (automate), TC-006 Export data (manual - rare use)`,\r\n    },\r\n    // Step 10: Generate Manual Test Cases (inline)\r\n    {\r\n      inline: true,\r\n      title: 'Generate All Manual Test Case Files',\r\n      content: `Generate ALL manual test case markdown files in the \\`./test-cases/\\` directory BEFORE invoking the test-code-generator agent.\r\n\r\n**For each test scenario from the previous step:**\r\n\r\n1. **Create test case file** in \\`./test-cases/\\` with format \\`TC-XXX-feature-description.md\\`\r\n2. **Include frontmatter** with:\r\n   - \\`id:\\` TC-XXX (sequential ID)\r\n   - \\`title:\\` Clear, descriptive title\r\n   - \\`automated:\\` true/false (based on automation decision)\r\n   - \\`automated_test:\\` (leave empty - will be filled by subagent when automated)\r\n   - \\`type:\\` exploratory/functional/regression/smoke\r\n   - \\`area:\\` Feature area/component\r\n3. **Write test case content**:\r\n   - **Objective**: Clear description of what is being tested\r\n   - **Preconditions**: Setup requirements, test data needed\r\n   - **Test Steps**: Numbered, human-readable steps\r\n   - **Expected Results**: What should happen at each step\r\n   - **Test Data**: Environment variables to use (e.g., \\${TEST_BASE_URL}, \\${TEST_OWNER_EMAIL})\r\n   - **Notes**: Any assumptions, clarifications needed, or special considerations\r\n\r\n**Output**: All manual test case markdown files created in \\`./test-cases/\\` with automation flags set`,\r\n    },\r\n    // Step 11: Automate Test Cases (inline - detailed instructions for test-code-generator)\r\n    {\r\n      inline: true,\r\n      title: 'Automate Test Cases Area by Area',\r\n      content: `**IMPORTANT**: Process each feature area separately to enable incremental, focused test creation.\r\n\r\n**For each area**, invoke the test-code-generator agent:\r\n\r\n**Prepare Area Context:**\r\nBefore invoking the agent, identify the test cases for the current area:\r\n- Current area name\r\n- Test case files for this area (e.g., TC-001-valid-login.md, TC-002-invalid-password.md)\r\n- Which test cases are marked for automation (automated: true)\r\n- Test type from arguments\r\n- Test plan reference: test-plan.md\r\n- Existing automated tests in ./tests/specs/\r\n- Existing Page Objects in ./tests/pages/\r\n\r\n**Invoke test-code-generator Agent:**\r\n\r\n{{INVOKE_TEST_CODE_GENERATOR}} for the current area with the following context:\r\n\r\n\"Automate test cases for the [AREA_NAME] area.\r\n\r\n**Context:**\r\n- Area: [AREA_NAME]\r\n- Manual test case files to automate: [list TC-XXX files marked with automated: true]\r\n- Test type: {type}\r\n- Test plan: test-plan.md\r\n- Manual test cases directory: ./test-cases/\r\n- Existing automated tests: ./tests/specs/\r\n- Existing Page Objects: ./tests/pages/\r\n\r\n**The agent should:**\r\n1. Read the manual test case files for this area\r\n2. Check existing Page Object infrastructure for this area\r\n3. Explore the feature area to understand implementation (gather selectors, URLs, flows)\r\n4. Build missing Page Objects and supporting code\r\n5. For each test case marked \\`automated: true\\`:\r\n   - Create automated Playwright test in ./tests/specs/\r\n   - Update the manual test case file to reference the automated test path\r\n6. Run and iterate on each test until it passes or fails with a product bug\r\n7. Update .env.testdata with any new variables\r\n\r\n**Focus only on the [AREA_NAME] area** - do not automate tests for other areas yet.\"\r\n\r\n**Verify Area Completion:**\r\nAfter the agent completes the area, verify:\r\n- Manual test case files updated with automated_test references\r\n- Automated tests created for all test cases marked automated: true\r\n- Tests are passing (or failing with documented product bugs)\r\n- Page Objects created/updated for the area\r\n\r\n**Repeat for Next Area:**\r\nMove to the next area and repeat until all areas are complete.\r\n\r\n**Benefits of area-by-area approach**:\r\n- Agent focuses on one feature at a time\r\n- POMs built incrementally as needed\r\n- Tests verified before moving to next area\r\n- Easier to manage and track progress\r\n- Can pause/resume between areas if needed`,\r\n    },\r\n    // Step 12: Validate Artifacts (library)\r\n    'validate-test-artifacts',\r\n    // Step 13: Create Directories (inline)\r\n    {\r\n      inline: true,\r\n      title: 'Create Directories if Needed',\r\n      content: `Ensure required directories exist:\r\n\\`\\`\\`bash\r\nmkdir -p ./test-cases\r\nmkdir -p ./tests/specs\r\nmkdir -p ./tests/pages\r\nmkdir -p ./tests/components\r\nmkdir -p ./tests/fixtures\r\nmkdir -p ./tests/helpers\r\n\\`\\`\\``,\r\n    },\r\n    // Step 14: Extract Env Variables (library)\r\n    'extract-env-variables',\r\n    // Step 15: Knowledge Base Update (library)\r\n    'update-knowledge-base',\r\n    // Step 16: Team Communication (conditional inline)\r\n    {\r\n      inline: true,\r\n      title: 'Team Communication',\r\n      content: `{{INVOKE_TEAM_COMMUNICATOR}} to notify the product team about the new test cases and automated tests:\r\n\r\n\\`\\`\\`\r\n1. Post an update about test case and automation creation\r\n2. Provide summary of coverage:\r\n   - Number of manual test cases created\r\n   - Number of automated tests created\r\n   - Features covered by automation\r\n   - Areas kept manual-only (and why)\r\n3. Highlight key automated test scenarios\r\n4. Share command to run automated tests: npx playwright test\r\n5. Ask for team review and validation\r\n6. Mention any areas needing exploration or clarification\r\n7. Use appropriate channel and threading for the update\r\n\\`\\`\\`\r\n\r\nThe team communication should include:\r\n- **Test artifacts created**: Manual test cases + automated tests count\r\n- **Automation coverage**: Which features are now automated\r\n- **Manual-only areas**: Why some tests are kept manual (rare scenarios, exploratory)\r\n- **Key automated scenarios**: Critical paths now covered by automation\r\n- **Running tests**: Command to execute automated tests\r\n- **Review request**: Ask team to validate scenarios and review test code\r\n- **Next steps**: Plans for CI/CD integration or additional test coverage\r\n\r\n**Update team communicator memory:**\r\n- Record this communication\r\n- Note test case and automation creation\r\n- Track team feedback on automation approach\r\n- Document any clarifications requested`,\r\n      conditionalOnSubagent: 'team-communicator',\r\n    },\r\n    // Step 17: Final Summary (inline)\r\n    {\r\n      inline: true,\r\n      title: 'Final Summary',\r\n      content: `Provide a comprehensive summary showing:\r\n\r\n**Manual Test Cases:**\r\n- Number of manual test cases created\r\n- List of test case files with IDs and titles\r\n- Automation status for each (automated: yes/no)\r\n\r\n**Automated Tests:**\r\n- Number of automated test scripts created\r\n- List of spec files with test counts\r\n- Page Objects created or updated\r\n- Fixtures and helpers added\r\n\r\n**Test Coverage:**\r\n- Features covered by manual tests\r\n- Features covered by automated tests\r\n- Areas kept manual-only (and why)\r\n\r\n**Next Steps:**\r\n- Command to run automated tests: \\`npx playwright test\\`\r\n- Instructions to run specific test file\r\n- Note about copying .env.testdata to .env\r\n- Mention any exploration needed for edge cases\r\n\r\n**Important Notes:**\r\n- **Both Manual AND Automated**: Generate both artifacts - they serve different purposes\r\n- **Manual Test Cases**: Documentation, reference, can be executed manually when needed\r\n- **Automated Tests**: Fast, repeatable, for CI/CD and regression testing\r\n- **Automation Decision**: Not all test cases need automation - rare edge cases can stay manual\r\n- **Linking**: Manual test cases reference automated tests; automated tests reference manual test case IDs\r\n- **Two-Phase Workflow**: First generate all manual test cases, then automate area-by-area\r\n- **Ambiguity Handling**: Use exploration and clarification protocols before generating\r\n- **Environment Variables**: Use \\`process.env.VAR_NAME\\` in tests, update .env.testdata as needed\r\n- **Test Independence**: Each test must be runnable in isolation and in parallel`,\r\n    },\r\n  ],\r\n\r\n  requiredSubagents: ['test-runner', 'test-code-generator'],\r\n  optionalSubagents: ['documentation-researcher', 'team-communicator'],\r\n  dependentTasks: [],\r\n};\r\n","/**\r\n * Generate Test Plan Task (Composed)\r\n * Generate a comprehensive test plan from product description\r\n */\r\n\r\nimport type { ComposedTaskTemplate } from '../steps/types';\r\nimport { TASK_SLUGS } from '../constants';\r\n\r\nexport const generateTestPlanTask: ComposedTaskTemplate = {\r\n  slug: TASK_SLUGS.GENERATE_TEST_PLAN,\r\n  name: 'Generate Test Plan',\r\n  description: 'Generate a concise feature checklist test plan from product description',\r\n\r\n  frontmatter: {\r\n    description: 'Generate a concise feature checklist test plan (~50-100 lines)',\r\n    'argument-hint': '<product-description>',\r\n  },\r\n\r\n  steps: [\r\n    // Step 1: Overview (inline)\r\n    {\r\n      inline: true,\r\n      title: 'Generate Test Plan Overview',\r\n      content: `Generate a comprehensive test plan from product description following the Brain Module specifications.`,\r\n    },\r\n    // Step 2: Security Notice (library)\r\n    'security-notice',\r\n    // Step 3: Arguments (inline)\r\n    {\r\n      inline: true,\r\n      title: 'Arguments',\r\n      content: `Product description: $ARGUMENTS`,\r\n    },\r\n    // Step 4: Knowledge Base Read (library)\r\n    'read-knowledge-base',\r\n    // Step 5: Load Project Context (library)\r\n    'load-project-context',\r\n    // Step 6: Process Description (inline)\r\n    {\r\n      inline: true,\r\n      title: 'Process the Product Description',\r\n      content: `Use the product description provided directly in the arguments, enriched with project context understanding.`,\r\n    },\r\n    // Step 7: Initialize Env Tracking (inline)\r\n    {\r\n      inline: true,\r\n      title: 'Initialize Environment Variables Tracking',\r\n      content: `Create a list to track all TEST_ prefixed environment variables discovered throughout the process.`,\r\n    },\r\n    // Step 8: Documentation Researcher (conditional inline)\r\n    {\r\n      inline: true,\r\n      title: 'Gather Comprehensive Project Documentation',\r\n      content: `{{INVOKE_DOCUMENTATION_RESEARCHER}} to explore and gather all available project information and other documentation sources. This ensures the test plan is based on complete and current information.\r\n\r\n\\`\\`\\`\r\nExplore all available project documentation related to: $ARGUMENTS\r\n\r\nSpecifically gather:\r\n- Product specifications and requirements\r\n- User stories and acceptance criteria\r\n- Technical architecture documentation\r\n- API documentation and endpoints\r\n- User roles and permissions\r\n- Business rules and validations\r\n- UI/UX specifications\r\n- Known limitations or constraints\r\n- Existing test documentation\r\n- Bug reports or known issues\r\n\\`\\`\\`\r\n\r\nThe agent will:\r\n1. Check its memory for previously discovered documentation\r\n2. Explore workspace for relevant pages and databases\r\n3. Build a comprehensive understanding of the product\r\n4. Return synthesized information about all discovered documentation`,\r\n      conditionalOnSubagent: 'documentation-researcher',\r\n    },\r\n    // Step 9: Exploration Protocol (from library)\r\n    'exploration-protocol',\r\n    // Step 10: Clarification Protocol (from library)\r\n    'clarification-protocol',\r\n    // Step 11: Prepare Context (inline)\r\n    {\r\n      inline: true,\r\n      title: 'Prepare Test Plan Generation Context',\r\n      content: `**After ensuring requirements are clear through exploration and clarification:**\r\n\r\nBased on the gathered information:\r\n- **goal**: Extract the main purpose and objectives from all available documentation\r\n- **knowledge**: Combine product description with discovered documentation insights\r\n- **testPlan**: Use the standard test plan template structure, enriched with documentation findings\r\n- **gaps**: Identify areas lacking documentation that will need exploration`,\r\n    },\r\n    // Step 12: Generate Test Plan (inline - more detailed than library step)\r\n    {\r\n      inline: true,\r\n      title: 'Generate Test Plan Using Simplified Format',\r\n      content: `You are an expert QA Test Plan Writer. Generate a **concise** test plan (~50-100 lines) that serves as a feature checklist for test case generation.\r\n\r\n**CRITICAL - Keep it Simple:**\r\n- The test plan is a **feature checklist**, NOT a comprehensive document\r\n- Detailed UI elements and exploration findings go to \\`./exploration-reports/\\`\r\n- Technical patterns and architecture go to \\`.bugzy/runtime/knowledge-base.md\\`\r\n- Process documentation stays in \\`.bugzy/runtime/project-context.md\\`\r\n\r\n**Writing Instructions:**\r\n- **Use Product Terminology:** Use exact feature names from the product description\r\n- **Feature Checklist Format:** Each feature is a checkbox item with brief description\r\n- **Group by Feature Area:** Organize features into logical sections\r\n- **NO detailed UI elements** - those belong in exploration reports\r\n- **NO test scenarios** - those are generated in test cases\r\n- **NO process documentation** - keep only what's needed for test generation\r\n\r\n**Test Data Handling:**\r\n- Test data goes ONLY to \\`.env.testdata\\` file\r\n- In test plan, reference environment variable NAMES only (e.g., TEST_BASE_URL)\r\n- DO NOT generate values for env vars, only keys\r\n- Track all TEST_ variables for extraction to .env.testdata in the next step`,\r\n    },\r\n    // Step 13: Create Test Plan File (inline)\r\n    {\r\n      inline: true,\r\n      title: 'Create Test Plan File',\r\n      content: `Read the simplified template from \\`.bugzy/runtime/templates/test-plan-template.md\\` and fill it in:\r\n\r\n1. Read the template file\r\n2. Replace placeholders:\r\n   - \\`[PROJECT_NAME]\\` with the actual project name\r\n   - \\`[DATE]\\` with the current date\r\n   - Feature sections with actual features grouped by area\r\n3. Each feature is a **checkbox item** with brief description\r\n4. **Mark ambiguities:**\r\n   - MEDIUM: Mark with [ASSUMED: reason]\r\n   - LOW: Mark with [TO BE EXPLORED: detail]\r\n5. Keep total document under 100 lines`,\r\n    },\r\n    // Step 14: Save Test Plan (inline)\r\n    {\r\n      inline: true,\r\n      title: 'Save Test Plan',\r\n      content: `Save to \\`test-plan.md\\` in project root. The template already includes frontmatter - just fill in the dates.`,\r\n    },\r\n    // Step 15: Extract Env Variables (inline - more detailed than library step)\r\n    {\r\n      inline: true,\r\n      title: 'Extract and Save Environment Variables',\r\n      content: `**CRITICAL**: Test data values must ONLY go to .env.testdata, NOT in the test plan document.\r\n\r\nAfter saving the test plan:\r\n\r\n1. **Parse the test plan** to find all TEST_ prefixed environment variables mentioned:\r\n   - Look in the Testing Environment section\r\n   - Search for any TEST_ variables referenced\r\n   - Extract variables from configuration or setup sections\r\n   - Common patterns include: TEST_BASE_URL, TEST_USER_*, TEST_API_*, TEST_ADMIN_*, etc.\r\n\r\n2. **Create .env.testdata file** with all discovered variables:\r\n   \\`\\`\\`bash\r\n   # Application Configuration\r\n   TEST_BASE_URL=\r\n\r\n   # Test User Credentials\r\n   TEST_USER_EMAIL=\r\n   TEST_USER_PASSWORD=\r\n   TEST_ADMIN_EMAIL=\r\n   TEST_ADMIN_PASSWORD=\r\n\r\n   # API Configuration\r\n   TEST_API_KEY=\r\n   TEST_API_SECRET=\r\n\r\n   # Other Test Data\r\n   TEST_DB_NAME=\r\n   TEST_TIMEOUT=\r\n   \\`\\`\\`\r\n\r\n3. **Add helpful comments** for each variable group to guide users in filling values\r\n\r\n4. **Save the file** as \\`.env.testdata\\` in the project root\r\n\r\n5. **Verify test plan references .env.testdata**:\r\n   - Ensure test plan DOES NOT contain test data values\r\n   - Ensure test plan references \\`.env.testdata\\` for test data requirements\r\n   - Add instruction: \"Fill in actual values in .env.testdata before running tests\"`,\r\n    },\r\n    // Step 16: Knowledge Base Update (library)\r\n    'update-knowledge-base',\r\n    // Step 17: Team Communication (conditional inline)\r\n    {\r\n      inline: true,\r\n      title: 'Team Communication',\r\n      content: `{{INVOKE_TEAM_COMMUNICATOR}} to notify the product team about the new test plan:\r\n\r\n\\`\\`\\`\r\n1. Post an update about the test plan creation\r\n2. Provide a brief summary of coverage areas and key features\r\n3. Mention any areas that need exploration or clarification\r\n4. Ask for team review and feedback on the test plan\r\n5. Include a link or reference to the test-plan.md file\r\n6. Use appropriate channel and threading for the update\r\n\\`\\`\\`\r\n\r\nThe team communication should include:\r\n- **Test plan scope**: Brief overview of what will be tested\r\n- **Coverage highlights**: Key features and user flows included\r\n- **Areas needing clarification**: Any uncertainties discovered during documentation research\r\n- **Review request**: Ask team to review and provide feedback\r\n- **Next steps**: Mention plan to generate test cases after review\r\n\r\n**Update team communicator memory:**\r\n- Record this communication in the team-communicator memory\r\n- Note this as a test plan creation communication\r\n- Track team response to this type of update`,\r\n      conditionalOnSubagent: 'team-communicator',\r\n    },\r\n    // Step 18: Final Summary (inline)\r\n    {\r\n      inline: true,\r\n      title: 'Final Summary',\r\n      content: `Provide a summary of:\r\n- Test plan created successfully at \\`test-plan.md\\`\r\n- Environment variables extracted to \\`.env.testdata\\`\r\n- Number of TEST_ variables discovered\r\n- Instructions for the user to fill in actual values in .env.testdata before running tests`,\r\n    },\r\n  ],\r\n\r\n  requiredSubagents: ['test-runner'],\r\n  optionalSubagents: ['documentation-researcher', 'team-communicator'],\r\n  dependentTasks: [],\r\n};\r\n","/**\r\n * Handle Message Task (Composed)\r\n * Handle team responses and Slack communications, maintaining context for ongoing conversations\r\n *\r\n * Slack messages are processed by the LLM layer (lib/slack/llm-processor.ts)\r\n * which routes feedback/general chat to this task via the 'collect_feedback' action.\r\n * This task must be in SLACK_ALLOWED_TASKS to be Slack-callable.\r\n */\r\n\r\nimport type { ComposedTaskTemplate } from '../steps/types';\r\nimport { TASK_SLUGS } from '../constants';\r\n\r\nexport const handleMessageTask: ComposedTaskTemplate = {\r\n  slug: TASK_SLUGS.HANDLE_MESSAGE,\r\n  name: 'Handle Message',\r\n  description: 'Handle team responses and Slack communications, maintaining context for ongoing conversations (LLM-routed)',\r\n\r\n  frontmatter: {\r\n    description: 'Handle team responses and Slack communications, maintaining context for ongoing conversations',\r\n    'argument-hint': '[slack thread context or team message]',\r\n  },\r\n\r\n  steps: [\r\n    // Step 1: Overview (inline)\r\n    {\r\n      inline: true,\r\n      title: 'Handle Message Overview',\r\n      content: `# Handle Message Command\r\n\r\nProcess team responses from Slack threads and handle multi-turn conversations with the product team about testing clarifications, ambiguities, and questions.`,\r\n    },\r\n    // Step 2: Security Notice (library)\r\n    'security-notice',\r\n    // Step 3: Arguments (inline)\r\n    {\r\n      inline: true,\r\n      title: 'Arguments',\r\n      content: `Team message/thread context: $ARGUMENTS`,\r\n    },\r\n    // Step 4: Knowledge Base Read (library)\r\n    'read-knowledge-base',\r\n    // Step 5: Detect Intent (inline - task-specific)\r\n    {\r\n      inline: true,\r\n      title: 'Detect Message Intent and Load Handler',\r\n      content: `Before processing the message, identify the intent type to load the appropriate handler.\r\n\r\n#### 0.1 Extract Intent from Event Payload\r\n\r\nCheck the event payload for the \\`intent\\` field provided by the LLM layer:\r\n- If \\`intent\\` is present, use it directly\r\n- Valid intent values: \\`question\\`, \\`feedback\\`, \\`status\\`\r\n\r\n#### 0.2 Fallback Intent Detection (if no intent provided)\r\n\r\nIf intent is not in the payload, detect from message patterns:\r\n\r\n| Condition | Intent |\r\n|-----------|--------|\r\n| Keywords: \"status\", \"progress\", \"how did\", \"results\", \"how many passed\" | \\`status\\` |\r\n| Keywords: \"bug\", \"issue\", \"broken\", \"doesn't work\", \"failed\", \"error\" | \\`feedback\\` |\r\n| Question words: \"what\", \"which\", \"do we have\", \"is there\" about tests/project | \\`question\\` |\r\n| Default (none of above) | \\`feedback\\` |\r\n\r\n#### 0.3 Load Handler File\r\n\r\nBased on detected intent, load the handler from:\r\n\\`.bugzy/runtime/handlers/messages/{intent}.md\\`\r\n\r\n**Handler files:**\r\n- \\`question.md\\` - Questions about tests, coverage, project details\r\n- \\`feedback.md\\` - Bug reports, test observations, general information\r\n- \\`status.md\\` - Status checks on test runs, task progress\r\n\r\n#### 0.4 Follow Handler Instructions\r\n\r\n**IMPORTANT**: The handler file is authoritative for this intent type.\r\n\r\n1. Read the handler file completely\r\n2. Follow its processing steps in order\r\n3. Apply its context loading requirements\r\n4. Use its response guidelines\r\n5. Perform any memory updates it specifies\r\n\r\nThe handler file contains all necessary processing logic for the detected intent type. Each handler includes:\r\n- Specific processing steps for that intent\r\n- Context loading requirements\r\n- Response guidelines\r\n- Memory update instructions`,\r\n    },\r\n    // Step 6: Clarification Protocol (for ambiguous intents)\r\n    'clarification-protocol',\r\n    // Step 8: Knowledge Base Update (library)\r\n    'update-knowledge-base',\r\n    // Step 9: Key Principles (inline)\r\n    {\r\n      inline: true,\r\n      title: 'Key Principles',\r\n      content: `## Key Principles\r\n\r\n### Context Preservation\r\n- Always maintain full conversation context\r\n- Link responses back to original uncertainties\r\n- Preserve reasoning chain for future reference\r\n\r\n### Actionable Responses\r\n- Convert team input into concrete actions\r\n- Don't let clarifications sit without implementation\r\n- Follow through on commitments made to team\r\n\r\n### Learning Integration\r\n- Each interaction improves our understanding\r\n- Build knowledge base of team preferences\r\n- Refine communication approaches over time\r\n\r\n### Quality Communication\r\n- Acknowledge team input appropriately\r\n- Provide updates on actions taken\r\n- Ask good follow-up questions when needed`,\r\n    },\r\n    // Step 10: Important Considerations (inline)\r\n    {\r\n      inline: true,\r\n      title: 'Important Considerations',\r\n      content: `## Important Considerations\r\n\r\n### Thread Organization\r\n- Keep related discussions in same thread\r\n- Start new threads for new topics\r\n- Maintain clear conversation boundaries\r\n\r\n### Response Timing\r\n- Acknowledge important messages promptly\r\n- Allow time for implementation before status updates\r\n- Don't spam team with excessive communications\r\n\r\n### Action Prioritization\r\n- Address urgent clarifications first\r\n- Batch related updates when possible\r\n- Focus on high-impact changes\r\n\r\n### Memory Maintenance\r\n- Keep active conversations visible and current\r\n- Archive resolved discussions appropriately\r\n- Maintain searchable history of resolutions`,\r\n    },\r\n  ],\r\n\r\n  requiredSubagents: ['team-communicator'],\r\n  optionalSubagents: [],\r\n  dependentTasks: ['verify-changes'],\r\n};\r\n","/**\r\n * Process Event Task (Composed)\r\n * Process external system events (Jira, GitHub, Linear) using handler-defined rules to extract insights and track issues\r\n */\r\n\r\nimport type { ComposedTaskTemplate } from '../steps/types';\r\nimport { TASK_SLUGS } from '../constants';\r\n\r\nexport const processEventTask: ComposedTaskTemplate = {\r\n  slug: TASK_SLUGS.PROCESS_EVENT,\r\n  name: 'Process Event',\r\n  description: 'Process external system events (Jira, GitHub, Linear) using handler-defined rules to extract insights and track issues',\r\n\r\n  frontmatter: {\r\n    description: 'Process external system events (Jira, GitHub, Linear) using handler-defined rules to extract insights and track issues',\r\n    'argument-hint': '[event payload or description]',\r\n  },\r\n\r\n  steps: [\r\n    // Step 1: Overview (inline)\r\n    {\r\n      inline: true,\r\n      title: 'Process Event Overview',\r\n      content: `# Process Event Command\r\n\r\nProcess various types of events using intelligent pattern matching and historical context to maintain and evolve the testing system.`,\r\n    },\r\n    // Step 2: Security Notice (library)\r\n    'security-notice',\r\n    // Step 3: Arguments (inline)\r\n    {\r\n      inline: true,\r\n      title: 'Arguments',\r\n      content: `Arguments: $ARGUMENTS`,\r\n    },\r\n    // Step 4: Knowledge Base Read (library)\r\n    'read-knowledge-base',\r\n    // Step 5: Understand Event Context (inline)\r\n    {\r\n      inline: true,\r\n      title: 'Understand Event Context',\r\n      content: `Events come from integrated external systems via webhooks or manual input. Common sources include:\r\n- **Issue Trackers**: Jira, Linear, GitHub Issues\r\n- **Source Control**: GitHub, GitLab\r\n- **Communication Tools**: Slack\r\n\r\n**Event structure and semantics vary by source.** Do not interpret events based on generic assumptions. Instead, load the appropriate handler file for system-specific processing rules.\r\n\r\n#### Event Context to Extract:\r\n- **What happened**: The core event (test failed, PR merged, etc.)\r\n- **Where**: Component, service, or area affected\r\n- **Impact**: How this affects testing strategy\r\n- **Action Required**: What needs to be done in response`,\r\n    },\r\n    // Step 6: Clarify Unclear Events (inline - task-specific)\r\n    {\r\n      inline: true,\r\n      title: 'Clarify Unclear Events',\r\n      content: `If the event information is incomplete or ambiguous, seek clarification before processing:\r\n\r\n#### Detect Unclear Events\r\n\r\nEvents may be unclear in several ways:\r\n- **Vague description**: \"Something broke\", \"issue with login\" (what specifically?)\r\n- **Missing context**: Which component, which environment, which user?\r\n- **Contradictory information**: Event data conflicts with other sources\r\n- **Unknown references**: Mentions unfamiliar features, components, or systems\r\n- **Unclear severity**: Impact or priority is ambiguous\r\n\r\n#### Assess Ambiguity Severity\r\n\r\nClassify the ambiguity level to determine appropriate response:\r\n\r\n**🔴 CRITICAL - STOP and seek clarification:**\r\n- Cannot identify which component is affected\r\n- Event data is contradictory or nonsensical\r\n- Unknown system or feature mentioned\r\n- Cannot determine if this requires immediate action\r\n- Example: Event says \"production is down\" but unclear which service\r\n\r\n**🟠 HIGH - STOP and seek clarification:**\r\n- Vague problem description that could apply to multiple areas\r\n- Missing critical context needed for proper response\r\n- Unclear which team or system is responsible\r\n- Example: \"Login issue reported\" (login button? auth service? session? which page?)\r\n\r\n**🟡 MEDIUM - Proceed with documented assumptions:**\r\n- Some details missing but core event is clear\r\n- Can infer likely meaning from context\r\n- Can proceed but should clarify async\r\n- Example: \"Test failed on staging\" (can assume main staging, but clarify which one)\r\n\r\n**🟢 LOW - Mark and proceed:**\r\n- Minor details missing (optional context)\r\n- Cosmetic or non-critical information gaps\r\n- Can document gap and continue\r\n- Example: Missing timestamp or exact user who reported issue\r\n\r\n#### Clarification Approach by Severity\r\n\r\n**For CRITICAL/HIGH ambiguity:**\r\n1. **{{INVOKE_TEAM_COMMUNICATOR}} to ask specific questions**\r\n2. **WAIT for response before proceeding**\r\n3. **Document the clarification request in event history**\r\n\r\nExample clarification messages:\r\n- \"Event mentions 'login issue' - can you clarify if this is:\r\n  • Login button not responding?\r\n  • Authentication service failure?\r\n  • Session management problem?\r\n  • Specific page or global?\"\r\n\r\n- \"Event references component 'XYZ' which is unknown. What system does this belong to?\"\r\n\r\n- \"Event data shows contradictory information: status=success but error_count=15. Which is correct?\"\r\n\r\n**For MEDIUM ambiguity:**\r\n1. **Document assumption** with reasoning\r\n2. **Proceed with processing** based on assumption\r\n3. **Ask for clarification async** (non-blocking)\r\n4. **Mark in event history** for future reference\r\n\r\nExample: [ASSUMED: \"login issue\" refers to login button based on recent similar events]\r\n\r\n**For LOW ambiguity:**\r\n1. **Mark with [TO BE CLARIFIED: detail]**\r\n2. **Continue processing** normally\r\n3. **Document gap** in event history\r\n\r\nExample: [TO BE CLARIFIED: Exact timestamp of when issue was first observed]\r\n\r\n#### Document Clarification Process\r\n\r\nIn event history, record:\r\n- **Ambiguity detected**: What was unclear\r\n- **Severity assessed**: CRITICAL/HIGH/MEDIUM/LOW\r\n- **Clarification requested**: Questions asked (if any)\r\n- **Response received**: Team's clarification\r\n- **Assumption made**: If proceeded with assumption\r\n- **Resolution**: How ambiguity was resolved\r\n\r\nThis ensures future similar events can reference past clarifications and avoid redundant questions.`,\r\n    },\r\n    // Step 7: Load Context and Memory (inline)\r\n    {\r\n      inline: true,\r\n      title: 'Load Context and Memory',\r\n      content: `### Step 2: Load Context and Memory\r\n\r\n#### 2.1 Check Event Processor Memory\r\nRead \\`.bugzy/runtime/memory/event-processor.md\\` to:\r\n- Find similar event patterns\r\n- Load example events with reasoning\r\n- Get system-specific rules\r\n- Retrieve task mapping patterns\r\n\r\n#### 2.2 Check Event History\r\nRead \\`.bugzy/runtime/memory/event-history.md\\` to:\r\n- Ensure event hasn't been processed already (idempotency)\r\n- Find related recent events\r\n- Understand event patterns and trends\r\n\r\n#### 2.3 Read Current State\r\n- Read \\`test-plan.md\\` for current coverage\r\n- List \\`./test-cases/\\` for existing tests\r\n- Check \\`.bugzy/runtime/knowledge-base.md\\` for past insights\r\n\r\n#### 2.4 Load System-Specific Handler (REQUIRED)\r\n\r\nBased on the event source, load the handler from \\`.bugzy/runtime/handlers/\\`:\r\n\r\n**Step 1: Detect Event Source from Payload:**\r\n- \\`com.jira-server.*\\` event type prefix -> \\`.bugzy/runtime/handlers/jira.md\\`\r\n- \\`github.*\\` or GitHub webhook structure -> \\`.bugzy/runtime/handlers/github.md\\`\r\n- \\`linear.*\\` or Linear webhook -> \\`.bugzy/runtime/handlers/linear.md\\`\r\n- Other sources -> Check for matching handler file by source name\r\n\r\n**Step 2: Load and Read the Handler File:**\r\nThe handler file contains system-specific instructions for:\r\n- Event payload structure and field meanings\r\n- Which triggers (status changes, resolutions) require specific actions\r\n- How to interpret different event types\r\n- When to invoke \\`/verify-changes\\`\r\n- How to update the knowledge base\r\n\r\n**Step 3: Follow Handler Instructions:**\r\nThe handler file is authoritative for this event source. Follow its instructions for:\r\n- Interpreting the event payload\r\n- Determining what actions to take\r\n- Formatting responses and updates\r\n\r\n**Step 4: If No Handler Exists:**\r\nDo NOT guess or apply generic logic. Instead:\r\n1. Inform the user that no handler exists for this event source\r\n2. Ask how this event type should be processed\r\n3. Suggest creating a handler file at \\`.bugzy/runtime/handlers/{source}.md\\`\r\n\r\n**Project-Specific Configuration:**\r\nHandlers reference \\`.bugzy/runtime/project-context.md\\` for project-specific rules like:\r\n- Which status transitions trigger verify-changes\r\n- Which resolutions should update the knowledge base\r\n- Which transitions to ignore`,\r\n    },\r\n    // Step 8: Intelligent Event Analysis (inline)\r\n    {\r\n      inline: true,\r\n      title: 'Intelligent Event Analysis',\r\n      content: `### Step 3: Intelligent Event Analysis\r\n\r\n#### 3.1 Contextual Pattern Analysis\r\nDon't just match patterns - analyze the event within the full context:\r\n\r\n**Combine Multiple Signals**:\r\n- Event details + Historical patterns from memory\r\n- Current test plan state + Knowledge base\r\n- External system status + Team activity\r\n- Business priorities + Risk assessment\r\n\r\n**Example Contextual Analysis**:\r\n\\`\\`\\`\r\nEvent: Jira issue PROJ-456 moved to \"Ready for QA\"\r\n+ Handler: jira.md says \"Ready for QA\" triggers /verify-changes\r\n+ History: This issue was previously in \"In Progress\" for 3 days\r\n+ Knowledge: Related PR #123 merged yesterday\r\n= Decision: Invoke /verify-changes with issue context and PR reference\r\n\\`\\`\\`\r\n\r\n**Pattern Recognition with Context**:\r\n- An issue resolution depends on what the handler prescribes for that status\r\n- A duplicate event (same issue, same transition) should be skipped\r\n- Events from different sources about the same change should be correlated\r\n- Handler instructions take precedence over generic assumptions\r\n\r\n#### 3.2 Generate Semantic Queries\r\nBased on event type and content, generate 3-5 specific search queries:\r\n- Search for similar past events\r\n- Look for related test cases\r\n- Find relevant documentation\r\n- Check for known issues`,\r\n    },\r\n    // Step 9: Documentation Research (conditional inline)\r\n    {\r\n      inline: true,\r\n      title: 'Use Documentation Researcher',\r\n      content: `#### 3.3 Use Documentation Researcher if Needed\r\n\r\n{{INVOKE_DOCUMENTATION_RESEARCHER}} to find information about unknown features or components:\r\n\r\nFor events mentioning unknown features or components, ask the agent to explore project documentation and return:\r\n- Feature specifications\r\n- Related test cases\r\n- Known issues or limitations\r\n- Component dependencies`,\r\n      conditionalOnSubagent: 'documentation-researcher',\r\n    },\r\n    // Step 10: Task Planning (inline)\r\n    {\r\n      inline: true,\r\n      title: 'Task Planning with Reasoning',\r\n      content: `### Step 4: Task Planning with Reasoning\r\n\r\nGenerate tasks based on event analysis, using examples from memory as reference.\r\n\r\n#### Task Generation Logic:\r\nAnalyze the event in context of ALL available information to decide what actions to take:\r\n\r\n**Consider the Full Context**:\r\n- What does the handler prescribe for this event type?\r\n- How does this relate to current knowledge?\r\n- What's the state of related issues in external systems?\r\n- Is this part of a larger pattern we've been seeing?\r\n- What's the business impact of this event?\r\n\r\n**Contextual Decision Making**:\r\nThe same event type can require different actions based on context:\r\n- If handler says this status triggers verification -> Invoke /verify-changes\r\n- If this issue was already processed (check event history) -> Skip to avoid duplicates\r\n- If related PR exists in knowledge base -> Include PR context in actions\r\n- If this is a recurring pattern from the same source -> Consider flagging for review\r\n- If handler has no rule for this event type -> Ask user for guidance\r\n\r\n**Dynamic Task Selection**:\r\nBased on the contextual analysis, decide which tasks make sense:\r\n- **extract_learning**: When the event reveals something new about the system\r\n- **update_test_plan**: When our understanding of what to test has changed\r\n- **update_test_cases**: When tests need to reflect new reality\r\n- **report_bug**: When we have a legitimate, impactful, reproducible issue\r\n- **skip_action**: When context shows no action needed (e.g., known issue, already fixed)\r\n\r\nThe key is to use ALL available context - not just react to the event type\r\n\r\n#### Document Reasoning:\r\nFor each task, document WHY it's being executed:\r\n\\`\\`\\`markdown\r\nTask: extract_learning\r\nReasoning: This event reveals a pattern of login failures on Chrome that wasn't previously documented\r\nData: \"Chrome-specific timeout issues with login button\"\r\n\\`\\`\\``,\r\n    },\r\n    // Step 11: Issue Tracking (conditional inline)\r\n    {\r\n      inline: true,\r\n      title: 'Issue Tracking',\r\n      content: `##### For Issue Tracking:\r\n\r\nWhen an issue needs to be tracked (task type: report_bug or update_story):\r\n\r\n{{INVOKE_ISSUE_TRACKER}}\r\n\r\n1. Check for duplicate issues in the tracking system\r\n2. For bugs: Create detailed bug report with:\r\n   - Clear, descriptive title\r\n   - Detailed description with context\r\n   - Step-by-step reproduction instructions\r\n   - Expected vs actual behavior\r\n   - Environment and configuration details\r\n   - Test case reference (if applicable)\r\n   - Screenshots or error logs\r\n3. For stories: Update status and add QA comments\r\n4. Track issue lifecycle and maintain categorization\r\n\r\nThe issue-tracker agent will handle all aspects of issue tracking including duplicate detection, story management, QA workflow transitions, and integration with your project management system (Jira, Linear, Notion, etc.).`,\r\n      conditionalOnSubagent: 'issue-tracker',\r\n    },\r\n    // Step 12: Execute Tasks (inline)\r\n    {\r\n      inline: true,\r\n      title: 'Execute Tasks with Memory Updates',\r\n      content: `### Step 5: Execute Tasks with Memory Updates\r\n\r\n#### 5.1 Execute Each Task\r\nFollow the standard execution logic with added context from memory.\r\n\r\n#### 5.2 Update Event Processor Memory\r\nIf new patterns discovered, append to \\`.bugzy/runtime/memory/event-processor.md\\`:\r\n\\`\\`\\`markdown\r\n### Pattern: [New Pattern Name]\r\n**First Seen**: [Date]\r\n**Indicators**: [What identifies this pattern]\r\n**Typical Tasks**: [Common task responses]\r\n**Example**: [This event]\r\n\\`\\`\\`\r\n\r\n#### 5.3 Update Event History\r\nAppend to \\`.bugzy/runtime/memory/event-history.md\\`:\r\n\\`\\`\\`markdown\r\n## [Timestamp] - Event #[ID]\r\n\r\n**Original Input**: [Raw arguments provided]\r\n**Parsed Event**:\r\n\\`\\`\\`yaml\r\ntype: [type]\r\nsource: [source]\r\n[other fields]\r\n\\`\\`\\`\r\n\r\n**Pattern Matched**: [Pattern name or \"New Pattern\"]\r\n**Tasks Executed**:\r\n1. [Task 1] - Reasoning: [Why]\r\n2. [Task 2] - Reasoning: [Why]\r\n\r\n**Files Modified**:\r\n- [List of files]\r\n\r\n**Outcome**: [Success/Partial/Failed]\r\n**Notes**: [Any additional context]\r\n---\r\n\\`\\`\\``,\r\n    },\r\n    // Step 13: Learning and Maintenance (inline)\r\n    {\r\n      inline: true,\r\n      title: 'Learning from Events',\r\n      content: `### Step 6: Learning from Events\r\n\r\nAfter processing, check if this event teaches us something new:\r\n1. Is this a new type of event we haven't seen?\r\n2. Did our task planning work well?\r\n3. Should we update our patterns?\r\n4. Are there trends across recent events?\r\n\r\nIf yes, update the event processor memory with new patterns or refined rules.\r\n\r\n### Step 7: Create Necessary Files\r\n\r\nEnsure all required files and directories exist:\r\n\\`\\`\\`bash\r\nmkdir -p ./test-cases .claude/memory\r\n\\`\\`\\`\r\n\r\nCreate files if they don't exist:\r\n- \\`.bugzy/runtime/knowledge-base.md\\`\r\n- \\`.bugzy/runtime/memory/event-processor.md\\`\r\n- \\`.bugzy/runtime/memory/event-history.md\\``,\r\n    },\r\n    // Step 14: Knowledge Base Update (library)\r\n    'update-knowledge-base',\r\n    // Step 15: Important Considerations (inline)\r\n    {\r\n      inline: true,\r\n      title: 'Important Considerations',\r\n      content: `## Important Considerations\r\n\r\n### Contextual Intelligence\r\n- Never process events in isolation - always consider full context\r\n- Use knowledge base, history, and external system state to inform decisions\r\n- What seems like a bug might be expected behavior given the context\r\n- A minor event might be critical when seen as part of a pattern\r\n\r\n### Adaptive Response\r\n- Same event type can require different actions based on context\r\n- Learn from each event to improve future decision-making\r\n- Build understanding of system behavior over time\r\n- Adjust responses based on business priorities and risk\r\n\r\n### Smart Task Generation\r\n- Only take actions prescribed by the handler or confirmed by the user\r\n- Document why each decision was made with full context\r\n- Skip redundant actions (e.g., duplicate events, already-processed issues)\r\n- Escalate appropriately based on pattern recognition\r\n\r\n### Continuous Learning\r\n- Each event adds to our understanding of the system\r\n- Update patterns when new correlations are discovered\r\n- Refine decision rules based on outcomes\r\n- Build institutional memory through event history`,\r\n    },\r\n  ],\r\n\r\n  requiredSubagents: ['team-communicator'],\r\n  optionalSubagents: ['documentation-researcher', 'issue-tracker'],\r\n  dependentTasks: ['verify-changes'],\r\n};\r\n","/**\r\n * Run Tests Task (Composed)\r\n * Select and run test cases using the test-runner agent\r\n */\r\n\r\nimport type { ComposedTaskTemplate } from '../steps/types';\r\nimport { TASK_SLUGS } from '../constants';\r\n\r\nexport const runTestsTask: ComposedTaskTemplate = {\r\n  slug: TASK_SLUGS.RUN_TESTS,\r\n  name: 'Run Tests',\r\n  description: 'Execute automated Playwright tests, analyze failures, and fix test issues automatically',\r\n\r\n  frontmatter: {\r\n    description: 'Execute automated Playwright tests, analyze failures, and fix test issues automatically',\r\n    'argument-hint': '[file-pattern|tag|all] (e.g., \"auth\", \"@smoke\", \"tests/specs/login.spec.ts\")',\r\n  },\r\n\r\n  steps: [\r\n    // Step 1: Overview (inline)\r\n    {\r\n      inline: true,\r\n      title: 'Run Tests Overview',\r\n      content: `# Run Tests Command\r\n\r\nExecute automated Playwright tests, analyze failures using JSON reports, automatically fix test issues, and log product bugs.`,\r\n    },\r\n    // Step 2: Security Notice (library)\r\n    'security-notice',\r\n    // Step 3: Arguments (inline)\r\n    {\r\n      inline: true,\r\n      title: 'Arguments',\r\n      content: `Arguments: $ARGUMENTS\r\n\r\n**Parse Arguments:**\r\nExtract the following from arguments:\r\n- **selector**: Test selection criteria\r\n  - File pattern: \"auth\" → finds tests/specs/**/*auth*.spec.ts\r\n  - Tag: \"@smoke\" → runs tests with @smoke annotation\r\n  - Specific file: \"tests/specs/login.spec.ts\"\r\n  - All tests: \"all\" or \"\" → runs entire test suite`,\r\n    },\r\n    // Step 4: Knowledge Base Read (library)\r\n    'read-knowledge-base',\r\n    // Step 5: Test Execution Strategy (library)\r\n    'read-test-strategy',\r\n    // Step 6: Identify Tests (inline - task-specific)\r\n    {\r\n      inline: true,\r\n      title: 'Identify Automated Tests to Run',\r\n      content: `#### Understand Test Selection\r\nParse the selector argument to determine which tests to run:\r\n\r\n**File Pattern** (e.g., \"auth\", \"login\"):\r\n- Find matching test files: \\`tests/specs/**/*[pattern]*.spec.ts\\`\r\n- Example: \"auth\" → finds all test files with \"auth\" in the name\r\n\r\n**Tag** (e.g., \"@smoke\", \"@regression\"):\r\n- Run tests with specific Playwright tag annotation\r\n- Use Playwright's \\`--grep\\` option\r\n\r\n**Specific File** (e.g., \"tests/specs/auth/login.spec.ts\"):\r\n- Run that specific test file\r\n\r\n**All Tests** (\"all\" or no selector):\r\n- Run entire test suite: \\`tests/specs/**/*.spec.ts\\`\r\n\r\n#### Find Matching Test Files\r\nUse glob patterns to find test files:\r\n\\`\\`\\`bash\r\n# For file pattern\r\nls tests/specs/**/*[pattern]*.spec.ts\r\n\r\n# For specific file\r\nls tests/specs/auth/login.spec.ts\r\n\r\n# For all tests\r\nls tests/specs/**/*.spec.ts\r\n\\`\\`\\`\r\n\r\n#### Validate Test Files Exist\r\nCheck that at least one test file was found:\r\n- If no tests found, inform user and suggest available tests\r\n- List available test files if selection was unclear\r\n\r\n#### Confirm Selection Before Execution\r\nBefore running tests, confirm the selection with the user if ambiguous:\r\n- **Clear selection** (specific file or tag): Proceed immediately\r\n- **Pattern match** (multiple files): List matching files and ask for confirmation if count > 5\r\n- **No selector** (all tests): Confirm running full suite before executing`,\r\n    },\r\n    // Step 7-10: Test Execution (library steps)\r\n    'run-playwright-tests',\r\n    'parse-test-results',\r\n    'triage-failures',\r\n    'fix-test-issues',\r\n    // Step 11: Log Product Bugs (conditional - library step)\r\n    {\r\n      stepId: 'log-product-bugs',\r\n      conditionalOnSubagent: 'issue-tracker',\r\n    },\r\n    // Step 12: Knowledge Base Update (library)\r\n    'update-knowledge-base',\r\n    // Step 13: Team Communication (conditional - library step)\r\n    {\r\n      stepId: 'notify-team',\r\n      conditionalOnSubagent: 'team-communicator',\r\n    },\r\n    // Step 14: Handle Special Cases (inline - task-specific)\r\n    {\r\n      inline: true,\r\n      title: 'Handle Special Cases',\r\n      content: `#### If No Test Cases Found\r\nIf no test cases match the selection criteria:\r\n1. Inform user that no matching test cases were found\r\n2. List available test cases or suggest running \\`/generate-test-cases\\` first\r\n3. Provide examples of valid selection criteria\r\n\r\n#### If Test Runner Agent Fails\r\nIf the test-runner agent encounters issues:\r\n1. Report the specific error\r\n2. Suggest troubleshooting steps\r\n3. Offer to run tests individually if batch execution failed\r\n\r\n#### If Test Cases Are Invalid\r\nIf selected test cases have formatting issues:\r\n1. Report which test cases are invalid\r\n2. Specify what's missing or incorrect\r\n3. Offer to fix the issues or skip invalid tests\r\n\r\n### Important Notes\r\n\r\n**Test Selection Strategy**:\r\n- **Always read** \\`.bugzy/runtime/test-execution-strategy.md\\` before selecting tests\r\n- Default to \\`@smoke\\` tests for fast validation unless user explicitly requests otherwise\r\n- Smoke tests provide 100% manual test case coverage with zero redundancy (~2-5 min)\r\n- Full regression includes intentional redundancy for diagnostic value (~10-15 min)\r\n- Use context keywords from user request to choose appropriate tier\r\n\r\n**Test Execution**:\r\n- Automated Playwright tests are executed via bash command, not through agents\r\n- Test execution time varies by tier (see strategy document for details)\r\n- JSON reports provide structured test results for analysis\r\n- Playwright automatically captures traces, screenshots, and videos on failures\r\n- Test artifacts are stored in test-results/ directory\r\n\r\n**Failure Handling**:\r\n- Test failures are automatically triaged (product bugs vs test issues)\r\n- Test issues are automatically fixed by the test-debugger-fixer subagent\r\n- Product bugs are logged via issue tracker after triage\r\n- All results are analyzed for learning opportunities and team communication\r\n- Critical failures trigger immediate team notification\r\n\r\n**Related Documentation**:\r\n- \\`.bugzy/runtime/test-execution-strategy.md\\` - When and why to run specific tests\r\n- \\`.bugzy/runtime/testing-best-practices.md\\` - How to write tests (patterns and anti-patterns)`,\r\n    },\r\n  ],\r\n\r\n  requiredSubagents: ['test-runner', 'test-debugger-fixer'],\r\n  optionalSubagents: ['issue-tracker', 'team-communicator'],\r\n  dependentTasks: [],\r\n};\r\n","/**\r\n * Verify Changes - Unified Multi-Trigger Task (Composed)\r\n * Single dynamic task that handles all trigger sources: manual, Slack, GitHub PR, CI/CD\r\n *\r\n * This task replaces verify-changes-manual and verify-changes-slack with intelligent\r\n * trigger detection and multi-channel output routing.\r\n */\r\n\r\nimport type { ComposedTaskTemplate } from '../steps/types';\r\nimport { TASK_SLUGS } from '../constants';\r\n\r\nexport const verifyChangesTask: ComposedTaskTemplate = {\r\n  slug: TASK_SLUGS.VERIFY_CHANGES,\r\n  name: 'Verify Changes',\r\n  description: 'Unified verification command for all trigger sources with automated tests and manual checklists',\r\n\r\n  frontmatter: {\r\n    description: 'Verify code changes with automated tests and manual verification checklists',\r\n    'argument-hint': '[trigger-auto-detected]',\r\n  },\r\n\r\n  steps: [\r\n    // Step 1: Overview (inline)\r\n    {\r\n      inline: true,\r\n      title: 'Verify Changes Overview',\r\n      content: `# Verify Changes - Unified Multi-Trigger Workflow\r\n\r\n## Overview\r\n\r\nThis task performs comprehensive change verification with:\r\n- **Automated testing**: Execute Playwright tests with automatic triage and fixing\r\n- **Manual verification checklists**: Generate role-specific checklists for non-automatable scenarios\r\n- **Multi-trigger support**: Works from manual CLI, Slack messages, GitHub PRs, and CI/CD\r\n- **Smart output routing**: Results formatted and delivered to the appropriate channel`,\r\n    },\r\n    // Step 2: Security Notice (library)\r\n    'security-notice',\r\n    // Step 3: Arguments (inline)\r\n    {\r\n      inline: true,\r\n      title: 'Arguments',\r\n      content: `**Input**: $ARGUMENTS\r\n\r\nThe input format determines the trigger source and context extraction strategy.`,\r\n    },\r\n    // Step 4: Knowledge Base Read (library)\r\n    'read-knowledge-base',\r\n    // Step 5: Detect Trigger Source (inline)\r\n    {\r\n      inline: true,\r\n      title: 'Detect Trigger Source',\r\n      content: `Analyze the input format to determine how this task was invoked:\r\n\r\n### Identify Trigger Type\r\n\r\n**GitHub PR Webhook:**\r\n- Input contains \\`pull_request\\` object with structure:\r\n  \\`\\`\\`json\r\n  {\r\n    \"pull_request\": {\r\n      \"number\": 123,\r\n      \"title\": \"...\",\r\n      \"body\": \"...\",\r\n      \"changed_files\": [...],\r\n      \"base\": { \"ref\": \"main\" },\r\n      \"head\": { \"ref\": \"feature-branch\" },\r\n      \"user\": { \"login\": \"...\" }\r\n    }\r\n  }\r\n  \\`\\`\\`\r\n-> **Trigger detected: GITHUB_PR**\r\n\r\n**Slack Event:**\r\n- Input contains \\`event\\` object with structure:\r\n  \\`\\`\\`json\r\n  {\r\n    \"eventType\": \"com.slack.message\" or \"com.slack.app_mention\",\r\n    \"event\": {\r\n      \"type\": \"message\",\r\n      \"channel\": \"C123456\",\r\n      \"user\": \"U123456\",\r\n      \"text\": \"message content\",\r\n      \"ts\": \"1234567890.123456\",\r\n      \"thread_ts\": \"...\" (optional)\r\n    }\r\n  }\r\n  \\`\\`\\`\r\n-> **Trigger detected: SLACK_MESSAGE**\r\n\r\n**CI/CD Environment:**\r\n- Environment variables present:\r\n  - \\`CI=true\\`\r\n  - \\`GITHUB_REF\\` (e.g., \"refs/heads/feature-branch\")\r\n  - \\`GITHUB_SHA\\` (commit hash)\r\n  - \\`GITHUB_BASE_REF\\` (base branch)\r\n  - \\`GITHUB_HEAD_REF\\` (head branch)\r\n- Git context available via bash commands\r\n-> **Trigger detected: CI_CD**\r\n\r\n**Manual Invocation:**\r\n- Input is natural language, URL, or issue identifier\r\n- Patterns: \"PR #123\", GitHub URL, \"PROJ-456\", feature description\r\n-> **Trigger detected: MANUAL**\r\n\r\n### Store Trigger Context\r\n\r\nStore the detected trigger for use in output routing:\r\n- Set variable: \\`TRIGGER_SOURCE\\` = [GITHUB_PR | SLACK_MESSAGE | CI_CD | MANUAL]\r\n- This determines output formatting and delivery channel`,\r\n    },\r\n    // Step 6: Extract Context (inline)\r\n    {\r\n      inline: true,\r\n      title: 'Extract Context Based on Trigger',\r\n      content: `Based on the detected trigger source, extract relevant context:\r\n\r\n### GitHub PR Trigger - Extract PR Details\r\n\r\nIf trigger is GITHUB_PR:\r\n- **PR number**: \\`pull_request.number\\`\r\n- **Title**: \\`pull_request.title\\`\r\n- **Description**: \\`pull_request.body\\`\r\n- **Changed files**: \\`pull_request.changed_files\\` (array of file paths)\r\n- **Author**: \\`pull_request.user.login\\`\r\n- **Base branch**: \\`pull_request.base.ref\\`\r\n- **Head branch**: \\`pull_request.head.ref\\`\r\n\r\n### Slack Message Trigger - Parse Natural Language\r\n\r\nIf trigger is SLACK_MESSAGE:\r\n- **Message text**: \\`event.text\\`\r\n- **Channel**: \\`event.channel\\` (for posting results)\r\n- **User**: \\`event.user\\` (requester)\r\n- **Thread**: \\`event.thread_ts\\` or \\`event.ts\\` (for threading replies)\r\n\r\n**Extract references from text:**\r\n- PR numbers: \"#123\", \"PR 123\", \"pull request 123\"\r\n- Issue IDs: \"PROJ-456\", \"BUG-123\"\r\n- URLs: GitHub PR links, deployment URLs\r\n- Feature names: Quoted terms, capitalized phrases\r\n- Environments: \"staging\", \"production\", \"preview\"\r\n\r\n### CI/CD Trigger - Read CI Environment\r\n\r\nIf trigger is CI_CD:\r\n- **CI platform**: Read \\`CI\\` env var\r\n- **Branch**: \\`GITHUB_REF\\` -> extract branch name\r\n- **Commit**: \\`GITHUB_SHA\\`\r\n- **Base branch**: \\`GITHUB_BASE_REF\\` (for PRs)\r\n- **Changed files**: Run \\`git diff --name-only $BASE_SHA...$HEAD_SHA\\`\r\n\r\n### Manual Trigger - Parse User Input\r\n\r\nIf trigger is MANUAL:\r\n- **GitHub PR URL**: Parse to extract PR number, then fetch details via API\r\n- **Issue identifier**: Extract issue ID (patterns: \"PROJ-123\", \"#456\", \"BUG-789\")\r\n- **Feature description**: Use text as-is for verification context\r\n- **Deployment URL**: Extract for testing environment\r\n\r\n### Unified Context Structure\r\n\r\nAfter extraction, create unified context structure:\r\n\\`\\`\\`\r\nCHANGE_CONTEXT = {\r\n  trigger: [GITHUB_PR | SLACK_MESSAGE | CI_CD | MANUAL],\r\n  title: \"...\",\r\n  description: \"...\",\r\n  changedFiles: [\"src/pages/Login.tsx\", ...],\r\n  author: \"...\",\r\n  environment: \"staging\" | \"production\" | URL,\r\n  prNumber: 123 (if available),\r\n  issueId: \"PROJ-456\" (if available),\r\n  slackChannel: \"C123456\" (if Slack trigger),\r\n  slackThread: \"1234567890.123456\" (if Slack trigger),\r\n  githubRepo: \"owner/repo\" (if GitHub trigger)\r\n}\r\n\\`\\`\\``,\r\n    },\r\n    // Step 6b: Retrieve Code Change Details (conditional - changelog-historian)\r\n    {\r\n      inline: true,\r\n      title: 'Retrieve Code Change Details',\r\n      content: `{{INVOKE_CHANGELOG_HISTORIAN}} to gather comprehensive context about recent code changes:\r\n\r\nExplore version control history related to the verification scope.\r\n\r\nSpecifically gather:\r\n- Recent changes merged to the target branch\r\n- Change authors and contributors\r\n- Scope and impact of each change\r\n- Change descriptions and rationale\r\n- Related issues or tickets\r\n- Files and components affected\r\n\r\nThe agent will:\r\n1. Check its memory for previously discovered repository context\r\n2. Explore version control for relevant changes\r\n3. Build comprehensive understanding of the change history\r\n4. Return synthesized change information\r\n\r\nUse this information to:\r\n- Identify which changes may have caused test failures\r\n- Understand the scope and risk of the changes\r\n- Enhance the verification report with change attribution\r\n- Provide better context for manual verification checklist`,\r\n      conditionalOnSubagent: 'changelog-historian',\r\n    },\r\n    // Step 7: Determine Test Scope (inline)\r\n    {\r\n      inline: true,\r\n      title: 'Determine Test Scope (Smart Selection)',\r\n      content: `**IMPORTANT**: You do NOT have access to code files. Infer test scope from change **descriptions** only.\r\n\r\nBased on PR title, description, and commit messages, intelligently select which tests to run:\r\n\r\n### Infer Test Scope from Change Descriptions\r\n\r\nAnalyze the change description to identify affected feature areas:\r\n\r\n**Example mappings from descriptions to test suites:**\r\n\r\n| Description Keywords | Inferred Test Scope | Example |\r\n|---------------------|-------------------|---------|\r\n| \"login\", \"authentication\", \"sign in/up\" | \\`tests/specs/auth/\\` | \"Fix login page validation\" -> Auth tests |\r\n| \"checkout\", \"payment\", \"purchase\" | \\`tests/specs/checkout/\\` | \"Optimize checkout flow\" -> Checkout tests |\r\n| \"cart\", \"shopping cart\", \"add to cart\" | \\`tests/specs/cart/\\` | \"Update cart calculations\" -> Cart tests |\r\n| \"API\", \"endpoint\", \"backend\" | API test suites | \"Add new user API endpoint\" -> User API tests |\r\n| \"profile\", \"account\", \"settings\" | \\`tests/specs/profile/\\` or \\`tests/specs/settings/\\` | \"Profile page redesign\" -> Profile tests |\r\n\r\n**Inference strategy:**\r\n1. **Extract feature keywords** from PR title and description\r\n2. **Analyze commit messages** for conventional commit scopes\r\n3. **Map keywords to test organization**\r\n4. **Identify test scope breadth from description tone**\r\n\r\n### Fallback Strategies Based on Description Analysis\r\n\r\n**Description patterns that indicate full suite:**\r\n- \"Refactor shared/common utilities\" (wide impact)\r\n- \"Update dependencies\" or \"Upgrade framework\" (safety validation)\r\n- \"Merge main into feature\" or \"Sync with main\" (comprehensive validation)\r\n- \"Breaking changes\" or \"Major version update\" (thorough testing)\r\n- \"Database migration\" or \"Schema changes\" (data integrity)\r\n\r\n**Description patterns that indicate smoke tests only:**\r\n- \"Fix typo\" or \"Update copy/text\" (cosmetic change)\r\n- \"Update README\" or \"Documentation only\" (no functional change)\r\n- \"Fix formatting\" or \"Linting fixes\" (no logic change)\r\n\r\n**When description is vague or ambiguous:**\r\n- **ACTION REQUIRED**: Use AskUserQuestion tool to clarify test scope\r\n\r\n**If specific test scope requested:**\r\n- User can override with: \"only smoke tests\", \"full suite\", specific test suite names\r\n- Honor user's explicit scope over smart selection\r\n\r\n### Test Selection Summary\r\n\r\nGenerate summary of test selection based on description analysis:\r\n\\`\\`\\`markdown\r\n### Test Scope Determined\r\n- **Change description**: [PR title or summary]\r\n- **Identified keywords**: [list extracted keywords: \"auth\", \"checkout\", etc.]\r\n- **Affected test suites**: [list inferred test suite paths or names]\r\n- **Scope reasoning**: [explain why this scope was selected]\r\n- **Execution strategy**: [smart selection | full suite | smoke tests | user-specified]\r\n\\`\\`\\``,\r\n    },\r\n    // Step 8-11: Test Execution (library steps)\r\n    'run-playwright-tests',\r\n    'parse-test-results',\r\n    'triage-failures',\r\n    'fix-test-issues',\r\n    // Step 12: Log Product Bugs (conditional library step)\r\n    {\r\n      stepId: 'log-product-bugs',\r\n      conditionalOnSubagent: 'issue-tracker',\r\n    },\r\n    // Step 13: Generate Manual Verification Checklist (inline)\r\n    {\r\n      inline: true,\r\n      title: 'Generate Manual Verification Checklist',\r\n      content: `Generate human-readable checklist for non-automatable scenarios:\r\n\r\n### Analyze Change Context\r\n\r\nReview the provided context to understand what changed:\r\n- Read PR title, description, and commit messages\r\n- Identify change types from descriptions: visual, UX, forms, mobile, accessibility, edge cases\r\n- Understand the scope and impact of changes from the change descriptions\r\n\r\n### Identify Non-Automatable Scenarios\r\n\r\nBased on the change analysis, identify scenarios that require human verification:\r\n\r\n**1. Visual Design Changes** (CSS, styling, design files, graphics)\r\n-> Add **Design Validation** checklist items\r\n\r\n**2. UX Interaction Changes** (animations, transitions, gestures, micro-interactions)\r\n-> Add **UX Feel** checklist items\r\n\r\n**3. Form and Input Changes** (new form fields, input validation, user input)\r\n-> Add **Accessibility** checklist items\r\n\r\n**4. Mobile and Responsive Changes** (media queries, touch interactions, viewport)\r\n-> Add **Mobile Experience** checklist items\r\n\r\n**5. Low ROI or Rare Scenarios** (edge cases, one-time migrations, rare user paths)\r\n-> Add **Exploratory Testing** notes\r\n\r\n### Generate Role-Specific Checklist Items\r\n\r\nFor each identified scenario, create clear, actionable checklist items:\r\n\r\n**Format for each item:**\r\n- Clear, specific task description\r\n- Assigned role (@design-team, @qa-team, @a11y-team, @mobile-team)\r\n- Acceptance criteria (what constitutes pass/fail)\r\n- Reference to standards when applicable (WCAG, iOS HIG, Material Design)\r\n- Priority indicator (red circle critical, yellow circle important, green circle nice-to-have)\r\n\r\n**Example checklist items:**\r\n\r\n**Design Validation (@design-team)**\r\n- [ ] Login button color matches brand guidelines (#FF6B35)\r\n- [ ] Loading spinner animation smooth (60fps, no jank)\r\n\r\n**Accessibility (@a11y-team)**\r\n- [ ] Screen reader announces form errors clearly (tested with VoiceOver/NVDA)\r\n- [ ] Keyboard navigation: Tab through all interactive elements in logical order\r\n- [ ] Color contrast meets WCAG 2.1 AA (4.5:1 for body text, 3:1 for large text)\r\n\r\n**Mobile Experience (@qa-team, @mobile-team)**\r\n- [ ] Touch targets greater than or equal to 44px (iOS Human Interface Guidelines)\r\n- [ ] Mobile keyboard doesn't obscure input fields on iOS/Android\r\n\r\n### When NO Manual Verification Needed\r\n\r\nIf the changes are purely:\r\n- Backend logic (no UI changes)\r\n- Code refactoring (no behavior changes)\r\n- Configuration changes (no user-facing impact)\r\n- Fully covered by automated tests\r\n\r\nOutput:\r\n\\`\\`\\`markdown\r\n**Manual Verification:** Not required for this change.\r\nAll user-facing changes are fully covered by automated tests.\r\n\\`\\`\\``,\r\n    },\r\n    // Step 14: Aggregate Results (inline)\r\n    {\r\n      inline: true,\r\n      title: 'Aggregate Verification Results',\r\n      content: `Combine automated and manual verification results:\r\n\r\n\\`\\`\\`markdown\r\n## Verification Results Summary\r\n\r\n### Automated Tests\r\n- Total tests: [count]\r\n- Passed: [count] ([percentage]%)\r\n- Failed: [count] ([percentage]%)\r\n- Test issues fixed: [count]\r\n- Product bugs logged: [count]\r\n- Duration: [time]\r\n\r\n### Manual Verification Required\r\n[Checklist generated in previous step, or \"Not required\"]\r\n\r\n### Overall Recommendation\r\n[Safe to merge | Review bugs before merging | Do not merge]\r\n\\`\\`\\``,\r\n    },\r\n    // Step 15: Documentation Research (conditional inline)\r\n    {\r\n      inline: true,\r\n      title: 'Understanding the Change (Documentation Research)',\r\n      content: `{{INVOKE_DOCUMENTATION_RESEARCHER}} to gather comprehensive context about the changed features:\r\n\r\nExplore project documentation related to the changes.\r\n\r\nSpecifically gather:\r\n- Product specifications for affected features\r\n- User stories and acceptance criteria\r\n- Technical architecture documentation\r\n- API endpoints and contracts\r\n- User roles and permissions relevant to the change\r\n- Business rules and validations\r\n- UI/UX specifications\r\n- Known limitations or constraints\r\n- Related bug reports or known issues\r\n- Existing test documentation for this area\r\n\r\nThe agent will:\r\n1. Check its memory for previously discovered documentation\r\n2. Explore workspace for relevant pages and databases\r\n3. Build comprehensive understanding of the affected features\r\n4. Return synthesized information to inform testing strategy\r\n\r\nUse this information to:\r\n- Better understand the change context\r\n- Identify comprehensive test scenarios\r\n- Recognize integration points and dependencies\r\n- Spot potential edge cases or risk areas\r\n- Enhance manual verification checklist generation`,\r\n      conditionalOnSubagent: 'documentation-researcher',\r\n    },\r\n    // Step 16: Report Results (inline)\r\n    {\r\n      inline: true,\r\n      title: 'Report Results (Multi-Channel Output)',\r\n      content: `Route output based on trigger source:\r\n\r\n### MANUAL Trigger -> Terminal Output\r\n\r\nFormat as comprehensive markdown report for terminal display with:\r\n- Change Summary (what changed, scope, affected files)\r\n- Automated Test Results (statistics, tests fixed, bugs logged)\r\n- Manual Verification Checklist\r\n- Recommendation (safe to merge / review / do not merge)\r\n- Test Artifacts (JSON report, HTML report, traces, screenshots)\r\n\r\n### SLACK_MESSAGE Trigger -> Thread Reply\r\n\r\n{{INVOKE_TEAM_COMMUNICATOR}} to post concise results to Slack thread with:\r\n- Verification results summary\r\n- Critical failures that need immediate attention\r\n- Bugs logged with issue tracker links\r\n- Manual verification checklist summary\r\n- Recommendation and next steps\r\n- Tag relevant team members for critical issues\r\n\r\n### GITHUB_PR Trigger -> PR Comment\r\n\r\nUse GitHub API to post comprehensive comment on PR with:\r\n- Status (All tests passed / Issues found / Critical failures)\r\n- Automated Tests table (Total, Passed, Failed, Fixed, Bugs, Duration)\r\n- Failed Tests (triaged and with actions taken)\r\n- Tests Fixed Automatically (issue, fix, verified)\r\n- Product Bugs Logged (issue ID, title, test, severity)\r\n- Manual Verification Required (checklist)\r\n- Test Artifacts links\r\n- Recommendation\r\n\r\n### CI_CD Trigger -> Build Log + PR Comment\r\n\r\nOutput to CI build log (print detailed results to stdout) and exit with appropriate code:\r\n- Exit 0: All tests passed (safe to merge)\r\n- Exit 1: Tests failed or critical bugs found (block merge)\r\n\r\nPost PR comment if GitHub context available.`,\r\n      conditionalOnSubagent: 'team-communicator',\r\n    },\r\n    // Step 17: Knowledge Base Update (library)\r\n    'update-knowledge-base',\r\n    // Step 18: Handle Special Cases (inline)\r\n    {\r\n      inline: true,\r\n      title: 'Handle Special Cases',\r\n      content: `**If no tests found for changed files:**\r\n- Inform user: \"No automated tests found for changed files\"\r\n- Recommend: \"Run smoke test suite for basic validation\"\r\n- Still generate manual verification checklist\r\n\r\n**If all tests skipped:**\r\n- Explain why (dependencies, environment issues)\r\n- Recommend: Check test configuration and prerequisites\r\n\r\n**If test execution fails:**\r\n- Report specific error (Playwright not installed, env vars missing)\r\n- Suggest troubleshooting steps\r\n- Don't proceed with triage if tests didn't run\r\n\r\n## Important Notes\r\n\r\n- This task handles **all trigger sources** with a single unified workflow\r\n- Trigger detection is automatic based on input format\r\n- Output is automatically routed to the appropriate channel\r\n- Automated tests are executed with **full triage and automatic fixing**\r\n- Manual verification checklists are generated for **non-automatable scenarios**\r\n- Product bugs are logged with **automatic duplicate detection**\r\n- Test issues are fixed automatically with **verification**\r\n- Results include both automated and manual verification items\r\n\r\n## Success Criteria\r\n\r\nA successful verification includes:\r\n1. Trigger source correctly detected\r\n2. Context extracted completely\r\n3. Tests executed (or skipped with explanation)\r\n4. All failures triaged (product bug vs test issue)\r\n5. Test issues fixed automatically (when possible)\r\n6. Product bugs logged to issue tracker\r\n7. Manual verification checklist generated\r\n8. Results formatted for output channel\r\n9. Results delivered to appropriate destination\r\n10. Clear recommendation provided (merge / review / block)`,\r\n    },\r\n  ],\r\n\r\n  requiredSubagents: ['test-runner', 'test-debugger-fixer'],\r\n  optionalSubagents: ['documentation-researcher', 'issue-tracker', 'team-communicator', 'changelog-historian'],\r\n  dependentTasks: [],\r\n};\r\n","/**\r\n * Onboard Testing Task (Composed)\r\n * End-to-end workflow: explore → plan → cases → test → fix → report\r\n * Renamed from full-test-coverage to better reflect its purpose as a setup/onboarding task\r\n */\r\n\r\nimport type { ComposedTaskTemplate } from '../steps/types';\r\nimport { TASK_SLUGS } from '../constants';\r\n\r\nexport const onboardTestingTask: ComposedTaskTemplate = {\r\n  slug: TASK_SLUGS.ONBOARD_TESTING,\r\n  name: 'Onboard Testing',\r\n  description:\r\n    'Complete workflow: explore application, generate test plan, create test cases, run tests, fix issues, and report results',\r\n\r\n  frontmatter: {\r\n    description: 'Complete test coverage workflow - from exploration to passing tests',\r\n    'argument-hint': '<focus-area-or-feature-description>',\r\n  },\r\n\r\n  steps: [\r\n    // Step 1: Overview (inline)\r\n    {\r\n      inline: true,\r\n      title: 'Onboard Testing Overview',\r\n      content: `## Overview\r\n\r\nThis command orchestrates the complete test coverage workflow in a single execution:\r\n1. **Phase 1**: Read project context and explore application\r\n2. **Phase 2**: Generate lightweight test plan\r\n3. **Phase 3**: Generate and verify test cases (create + fix until passing)\r\n4. **Phase 4**: Triage failures and fix test issues\r\n5. **Phase 5**: Log product bugs\r\n6. **Phase 6**: Final report`,\r\n    },\r\n    // Step 2: Security Notice (from library)\r\n    'security-notice',\r\n    // Step 3: Arguments (inline)\r\n    {\r\n      inline: true,\r\n      title: 'Arguments',\r\n      content: `Focus area: $ARGUMENTS`,\r\n    },\r\n    // Phase 1: Setup\r\n    'read-knowledge-base',\r\n\r\n    // Phase 2: Exploration Protocol\r\n    'exploration-protocol',\r\n\r\n    // Execute exploration via test-runner\r\n    'create-exploration-test-case',\r\n    'run-exploration',\r\n    'process-exploration-results',\r\n\r\n    // Phase 3: Test Plan Generation\r\n    'generate-test-plan',\r\n    'extract-env-variables',\r\n\r\n    // Phase 4: Test Case Generation\r\n    'generate-test-cases',\r\n    'automate-test-cases',\r\n\r\n    // Phase 5: Test Execution\r\n    'run-playwright-tests',\r\n    'parse-test-results',\r\n\r\n    // Phase 6: Triage and Fix (NEW - was missing from full-test-coverage)\r\n    'triage-failures',\r\n    'fix-test-issues',\r\n    {\r\n      stepId: 'log-product-bugs',\r\n      conditionalOnSubagent: 'issue-tracker',\r\n    },\r\n\r\n    // Phase 7: Reporting and Communication\r\n    'update-knowledge-base',\r\n    {\r\n      stepId: 'notify-team',\r\n      conditionalOnSubagent: 'team-communicator',\r\n    },\r\n    'generate-final-report',\r\n  ],\r\n\r\n  requiredSubagents: ['test-runner', 'test-code-generator', 'test-debugger-fixer'],\r\n  optionalSubagents: ['documentation-researcher', 'team-communicator', 'issue-tracker'],\r\n  dependentTasks: ['run-tests', 'generate-test-cases'],\r\n};\r\n","/**\r\n * Explore Application Task (Composed)\r\n * Systematically explore application to discover UI elements, workflows, and behaviors\r\n */\r\n\r\nimport type { ComposedTaskTemplate } from '../steps/types';\r\nimport { TASK_SLUGS } from '../constants';\r\n\r\nexport const exploreApplicationTask: ComposedTaskTemplate = {\r\n  slug: TASK_SLUGS.EXPLORE_APPLICATION,\r\n  name: 'Explore Application',\r\n  description: 'Systematically explore application to discover UI elements, workflows, and behaviors',\r\n\r\n  frontmatter: {\r\n    description: 'Explore application to discover UI, workflows, and behaviors',\r\n    'argument-hint': '--focus [area] --depth [shallow|deep] --system [name]',\r\n  },\r\n\r\n  steps: [\r\n    // Step 1: Overview (inline)\r\n    {\r\n      inline: true,\r\n      title: 'Explore Application Overview',\r\n      content: `Discover actual UI elements, workflows, and behaviors using the test-runner agent. Updates test plan and project documentation with findings.`,\r\n    },\r\n    // Step 2: Security Notice (from library)\r\n    'security-notice',\r\n    // Step 3: Arguments (inline)\r\n    {\r\n      inline: true,\r\n      title: 'Arguments',\r\n      content: `**Arguments**: $ARGUMENTS\r\n\r\n**Parse:**\r\n- **focus**: auth, navigation, search, content, admin (default: comprehensive)\r\n- **depth**: shallow (15-20 min) or deep (45-60 min, default)\r\n- **system**: target system (optional for multi-system setups)`,\r\n    },\r\n    // Setup\r\n    'read-knowledge-base',\r\n    'load-project-context',\r\n\r\n    // Exploration Protocol (adaptive depth)\r\n    'exploration-protocol',\r\n\r\n    // Execute\r\n    'create-exploration-test-case',\r\n    'run-exploration',\r\n    'process-exploration-results',\r\n\r\n    // Update\r\n    'update-exploration-artifacts',\r\n    // Team Communication (conditional inline)\r\n    {\r\n      inline: true,\r\n      title: 'Team Communication',\r\n      content: `{{INVOKE_TEAM_COMMUNICATOR}} to notify the product team about exploration findings:\r\n\r\n\\`\\`\\`\r\n1. Post an update about exploration completion\r\n2. Summarize key discoveries:\r\n   - UI elements and workflows identified\r\n   - Behaviors documented\r\n   - Areas needing further investigation\r\n3. Share exploration report location\r\n4. Ask for team feedback on findings\r\n5. Use appropriate channel and threading\r\n\\`\\`\\``,\r\n      conditionalOnSubagent: 'team-communicator',\r\n    },\r\n    'cleanup-temp-files',\r\n    'update-knowledge-base',\r\n  ],\r\n\r\n  requiredSubagents: ['test-runner'],\r\n  optionalSubagents: ['team-communicator'],\r\n  dependentTasks: [],\r\n};\r\n","/**\r\n * Tasks Module\r\n * Central registry and utilities for all task templates\r\n */\r\n\r\n// Export types and constants\r\nexport * from './types';\r\nexport * from './constants';\r\n\r\n// Import task templates\r\nimport { generateTestCasesTask } from './library/generate-test-cases';\r\nimport { generateTestPlanTask } from './library/generate-test-plan';\r\nimport { handleMessageTask } from './library/handle-message';\r\nimport { processEventTask } from './library/process-event';\r\nimport { runTestsTask } from './library/run-tests';\r\nimport { verifyChangesTask } from './library/verify-changes';\r\nimport { onboardTestingTask } from './library/onboard-testing';\r\nimport { exploreApplicationTask } from './library/explore-application';\r\n\r\nimport type { ComposedTaskTemplate } from './types';\r\nimport { TASK_SLUGS } from './constants';\r\n\r\n/**\r\n * Task Templates Registry\r\n * All tasks use the step-based composition format\r\n */\r\nexport const TASK_TEMPLATES: Record<string, ComposedTaskTemplate> = {\r\n  [TASK_SLUGS.GENERATE_TEST_CASES]: generateTestCasesTask,\r\n  [TASK_SLUGS.GENERATE_TEST_PLAN]: generateTestPlanTask,\r\n  [TASK_SLUGS.HANDLE_MESSAGE]: handleMessageTask,\r\n  [TASK_SLUGS.PROCESS_EVENT]: processEventTask,\r\n  [TASK_SLUGS.RUN_TESTS]: runTestsTask,\r\n  [TASK_SLUGS.VERIFY_CHANGES]: verifyChangesTask,\r\n  [TASK_SLUGS.ONBOARD_TESTING]: onboardTestingTask,\r\n  [TASK_SLUGS.EXPLORE_APPLICATION]: exploreApplicationTask,\r\n};\r\n\r\n/**\r\n * Get task template by slug\r\n */\r\nexport function getTaskTemplate(slug: string): ComposedTaskTemplate | undefined {\r\n  return TASK_TEMPLATES[slug];\r\n}\r\n\r\n/**\r\n * Get all registered task slugs\r\n */\r\nexport function getAllTaskSlugs(): string[] {\r\n  return Object.keys(TASK_TEMPLATES);\r\n}\r\n\r\n/**\r\n * Check if a task slug is registered\r\n */\r\nexport function isTaskRegistered(slug: string): boolean {\r\n  return TASK_TEMPLATES[slug] !== undefined;\r\n}\r\n\r\n/**\r\n * Slash Command Configuration for Cloud Run\r\n * Format expected by cloudrun-claude-code API\r\n */\r\nexport interface SlashCommandConfig {\r\n  frontmatter: Record<string, any>;\r\n  content: string;\r\n}\r\n\r\n"],"mappings":";AAiNO,SAAS,aAAa,KAAuC;AAClE,SAAO,OAAO,QAAQ,YAAY,YAAY,OAAO,IAAI,WAAW;AACtE;AAKO,SAAS,sBAAsB,KAAgD;AACpF,SAAO,OAAO,QAAQ,YAAY,YAAY;AAChD;;;ACnNO,IAAM,aAAa;AAAA,EACxB,qBAAqB;AAAA,EACrB,iBAAiB;AAAA,EACjB,qBAAqB;AAAA,EACrB,oBAAoB;AAAA,EACpB,gBAAgB;AAAA,EAChB,eAAe;AAAA,EACf,WAAW;AAAA,EACX,gBAAgB;AAAA;AAAA,EAEhB,oBAAoB;AACtB;;;ACVO,IAAM,wBAA8C;AAAA,EACzD,MAAM,WAAW;AAAA,EACjB,MAAM;AAAA,EACN,aAAa;AAAA,EAEb,aAAa;AAAA,IACX,aAAa;AAAA,IACb,iBAAiB;AAAA,EACnB;AAAA,EAEA,OAAO;AAAA;AAAA,IAEL;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAOX;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAMX;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAeX;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,MAYT,uBAAuB;AAAA,IACzB;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAoCX;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAqBX;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IA0DX;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IASX;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,MA8BT,uBAAuB;AAAA,IACzB;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAkCX;AAAA,EACF;AAAA,EAEA,mBAAmB,CAAC,eAAe,qBAAqB;AAAA,EACxD,mBAAmB,CAAC,4BAA4B,mBAAmB;AAAA,EACnE,gBAAgB,CAAC;AACnB;;;ACtTO,IAAM,uBAA6C;AAAA,EACxD,MAAM,WAAW;AAAA,EACjB,MAAM;AAAA,EACN,aAAa;AAAA,EAEb,aAAa;AAAA,IACX,aAAa;AAAA,IACb,iBAAiB;AAAA,EACnB;AAAA,EAEA,OAAO;AAAA;AAAA,IAEL;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA,IACX;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA,IACX;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA,IACX;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA,IACX;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,MAuBT,uBAAuB;AAAA,IACzB;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAOX;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAqBX;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAYX;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA,IACX;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAsCX;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,MAsBT,uBAAuB;AAAA,IACzB;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA,IAKX;AAAA,EACF;AAAA,EAEA,mBAAmB,CAAC,aAAa;AAAA,EACjC,mBAAmB,CAAC,4BAA4B,mBAAmB;AAAA,EACnE,gBAAgB,CAAC;AACnB;;;AC3NO,IAAM,oBAA0C;AAAA,EACrD,MAAM,WAAW;AAAA,EACjB,MAAM;AAAA,EACN,aAAa;AAAA,EAEb,aAAa;AAAA,IACX,aAAa;AAAA,IACb,iBAAiB;AAAA,EACnB;AAAA,EAEA,OAAO;AAAA;AAAA,IAEL;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA,IAGX;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA,IACX;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IA4CX;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAqBX;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAqBX;AAAA,EACF;AAAA,EAEA,mBAAmB,CAAC,mBAAmB;AAAA,EACvC,mBAAmB,CAAC;AAAA,EACpB,gBAAgB,CAAC,gBAAgB;AACnC;;;AC/IO,IAAM,mBAAyC;AAAA,EACpD,MAAM,WAAW;AAAA,EACjB,MAAM;AAAA,EACN,aAAa;AAAA,EAEb,aAAa;AAAA,IACX,aAAa;AAAA,IACb,iBAAiB;AAAA,EACnB;AAAA,EAEA,OAAO;AAAA;AAAA,IAEL;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA,IAGX;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA,IACX;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAYX;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAoFX;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAuDX;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAgCX;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,MAST,uBAAuB;AAAA,IACzB;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAuCX;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,MAmBT,uBAAuB;AAAA,IACzB;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAwCX;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAqBX;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAyBX;AAAA,EACF;AAAA,EAEA,mBAAmB,CAAC,mBAAmB;AAAA,EACvC,mBAAmB,CAAC,4BAA4B,eAAe;AAAA,EAC/D,gBAAgB,CAAC,gBAAgB;AACnC;;;ACxaO,IAAM,eAAqC;AAAA,EAChD,MAAM,WAAW;AAAA,EACjB,MAAM;AAAA,EACN,aAAa;AAAA,EAEb,aAAa;AAAA,IACX,aAAa;AAAA,IACb,iBAAiB;AAAA,EACnB;AAAA,EAEA,OAAO;AAAA;AAAA,IAEL;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA,IAGX;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IASX;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAwCX;AAAA;AAAA,IAEA;AAAA,IACA;AAAA,IACA;AAAA,IACA;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,uBAAuB;AAAA,IACzB;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,uBAAuB;AAAA,IACzB;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IA4CX;AAAA,EACF;AAAA,EAEA,mBAAmB,CAAC,eAAe,qBAAqB;AAAA,EACxD,mBAAmB,CAAC,iBAAiB,mBAAmB;AAAA,EACxD,gBAAgB,CAAC;AACnB;;;ACxJO,IAAM,oBAA0C;AAAA,EACrD,MAAM,WAAW;AAAA,EACjB,MAAM;AAAA,EACN,aAAa;AAAA,EAEb,aAAa;AAAA,IACX,aAAa;AAAA,IACb,iBAAiB;AAAA,EACnB;AAAA,EAEA,OAAO;AAAA;AAAA,IAEL;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IASX;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA,IAGX;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IA0DX;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IA+DX;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,MAuBT,uBAAuB;AAAA,IACzB;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAwDX;AAAA;AAAA,IAEA;AAAA,IACA;AAAA,IACA;AAAA,IACA;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,uBAAuB;AAAA,IACzB;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAmEX;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAmBX;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,MA4BT,uBAAuB;AAAA,IACzB;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,MAwCT,uBAAuB;AAAA,IACzB;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAsCX;AAAA,EACF;AAAA,EAEA,mBAAmB,CAAC,eAAe,qBAAqB;AAAA,EACxD,mBAAmB,CAAC,4BAA4B,iBAAiB,qBAAqB,qBAAqB;AAAA,EAC3G,gBAAgB,CAAC;AACnB;;;AChfO,IAAM,qBAA2C;AAAA,EACtD,MAAM,WAAW;AAAA,EACjB,MAAM;AAAA,EACN,aACE;AAAA,EAEF,aAAa;AAAA,IACX,aAAa;AAAA,IACb,iBAAiB;AAAA,EACnB;AAAA,EAEA,OAAO;AAAA;AAAA,IAEL;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IASX;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA,IACX;AAAA;AAAA,IAEA;AAAA;AAAA,IAGA;AAAA;AAAA,IAGA;AAAA,IACA;AAAA,IACA;AAAA;AAAA,IAGA;AAAA,IACA;AAAA;AAAA,IAGA;AAAA,IACA;AAAA;AAAA,IAGA;AAAA,IACA;AAAA;AAAA,IAGA;AAAA,IACA;AAAA,IACA;AAAA,MACE,QAAQ;AAAA,MACR,uBAAuB;AAAA,IACzB;AAAA;AAAA,IAGA;AAAA,IACA;AAAA,MACE,QAAQ;AAAA,MACR,uBAAuB;AAAA,IACzB;AAAA,IACA;AAAA,EACF;AAAA,EAEA,mBAAmB,CAAC,eAAe,uBAAuB,qBAAqB;AAAA,EAC/E,mBAAmB,CAAC,4BAA4B,qBAAqB,eAAe;AAAA,EACpF,gBAAgB,CAAC,aAAa,qBAAqB;AACrD;;;AC9EO,IAAM,yBAA+C;AAAA,EAC1D,MAAM,WAAW;AAAA,EACjB,MAAM;AAAA,EACN,aAAa;AAAA,EAEb,aAAa;AAAA,IACX,aAAa;AAAA,IACb,iBAAiB;AAAA,EACnB;AAAA,EAEA,OAAO;AAAA;AAAA,IAEL;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA,IACX;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAMX;AAAA;AAAA,IAEA;AAAA,IACA;AAAA;AAAA,IAGA;AAAA;AAAA,IAGA;AAAA,IACA;AAAA,IACA;AAAA;AAAA,IAGA;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,MAYT,uBAAuB;AAAA,IACzB;AAAA,IACA;AAAA,IACA;AAAA,EACF;AAAA,EAEA,mBAAmB,CAAC,aAAa;AAAA,EACjC,mBAAmB,CAAC,mBAAmB;AAAA,EACvC,gBAAgB,CAAC;AACnB;;;ACnDO,IAAM,iBAAuD;AAAA,EAClE,CAAC,WAAW,mBAAmB,GAAG;AAAA,EAClC,CAAC,WAAW,kBAAkB,GAAG;AAAA,EACjC,CAAC,WAAW,cAAc,GAAG;AAAA,EAC7B,CAAC,WAAW,aAAa,GAAG;AAAA,EAC5B,CAAC,WAAW,SAAS,GAAG;AAAA,EACxB,CAAC,WAAW,cAAc,GAAG;AAAA,EAC7B,CAAC,WAAW,eAAe,GAAG;AAAA,EAC9B,CAAC,WAAW,mBAAmB,GAAG;AACpC;AAKO,SAAS,gBAAgB,MAAgD;AAC9E,SAAO,eAAe,IAAI;AAC5B;AAKO,SAAS,kBAA4B;AAC1C,SAAO,OAAO,KAAK,cAAc;AACnC;AAKO,SAAS,iBAAiB,MAAuB;AACtD,SAAO,eAAe,IAAI,MAAM;AAClC;","names":[]}
+{"version":3,"sources":["../../src/tasks/steps/types.ts","../../src/tasks/constants.ts","../../src/tasks/library/generate-test-cases.ts","../../src/tasks/library/generate-test-plan.ts","../../src/tasks/library/handle-message.ts","../../src/tasks/library/process-event.ts","../../src/tasks/library/run-tests.ts","../../src/tasks/library/verify-changes.ts","../../src/tasks/library/onboard-testing.ts","../../src/tasks/library/explore-application.ts","../../src/tasks/index.ts"],"sourcesContent":["/**\n * Step Module Types\n * Type definitions for atomic, composable task steps\n */\n\nimport type { TaskFrontmatter } from '../types';\n\n/**\n * Step category for organization and filtering\n */\nexport type StepCategory =\n  | 'security' // Security notices and warnings\n  | 'setup' // Loading context, reading artifacts\n  | 'exploration' // Exploring the application\n  | 'clarification' // Handling ambiguity and questions\n  | 'execution' // Running tests, parsing results\n  | 'generation' // Creating test plans, cases, code\n  | 'communication' // Team notifications\n  | 'maintenance'; // Knowledge base updates, cleanup\n\n/**\n * TaskStep - Atomic, reusable unit of work within a task\n *\n * Steps are the building blocks of composed tasks. Each step represents\n * a discrete piece of work with clear instructions.\n */\nexport interface TaskStep {\n  /**\n   * Unique identifier for the step (kebab-case)\n   * Examples: 'read-knowledge-base', 'triage-failures', 'run-playwright-tests'\n   */\n  id: string;\n\n  /**\n   * Human-readable step title (used in generated markdown headers)\n   * Examples: 'Read Knowledge Base', 'Triage Failed Tests'\n   */\n  title: string;\n\n  /**\n   * Step category for organization\n   */\n  category: StepCategory;\n\n  /**\n   * Step content - the actual instructions as markdown string.\n   *\n   * Supported placeholders:\n   * - {{STEP_NUMBER}} - Auto-replaced with computed step number during assembly\n   * - {{INVOKE_*}} - Subagent invocation placeholders (e.g., {{INVOKE_TEST_DEBUGGER_FIXER}})\n   * - $ARGUMENTS - Task arguments from user input\n   */\n  content: string;\n\n  /**\n   * Optional subagent role this step requires to be included.\n   * If specified, step is only included when this subagent is configured.\n   *\n   * Use for steps that make no sense without the subagent.\n   * Example: 'log-product-bugs' step requires 'issue-tracker' subagent\n   */\n  requiresSubagent?: string;\n\n  /**\n   * Subagent roles that this step invokes (for MCP derivation).\n   * Different from requiresSubagent - this lists subagents the step calls\n   * via {{INVOKE_*}} placeholders, not what makes the step available.\n   */\n  invokesSubagents?: string[];\n\n  /**\n   * Tags for categorization, filtering, and step discovery.\n   * Examples: ['setup', 'execution', 'optional', 'triage']\n   */\n  tags?: string[];\n}\n\n/**\n * StepReferenceObject - Reference to a step in STEP_LIBRARY with per-usage configuration\n */\nexport interface StepReferenceObject {\n  /**\n   * The step ID to include from STEP_LIBRARY\n   */\n  stepId: string;\n\n  /**\n   * Override the step title for this specific usage\n   */\n  title?: string;\n\n  /**\n   * Additional content to append after the step\n   */\n  appendContent?: string;\n\n  /**\n   * Make this step conditional on a subagent being configured.\n   * Different from step's requiresSubagent - this is per-task configuration.\n   */\n  conditionalOnSubagent?: string;\n}\n\n/**\n * InlineStep - Step with body defined directly in the task definition\n * Use for task-specific content like headers, arguments, or unique steps\n */\nexport interface InlineStep {\n  /**\n   * Discriminator to identify inline steps\n   */\n  inline: true;\n\n  /**\n   * Step title (becomes ### Step N: {title})\n   */\n  title: string;\n\n  /**\n   * Step body content (markdown)\n   */\n  content: string;\n\n  /**\n   * Optional category for metadata/filtering\n   */\n  category?: StepCategory;\n\n  /**\n   * Make this step conditional on a subagent being configured\n   */\n  conditionalOnSubagent?: string;\n}\n\n/**\n * StepReference - How tasks reference steps in their composition\n *\n * Can be:\n * - Simple string (step ID from STEP_LIBRARY)\n * - StepReferenceObject (reference with overrides)\n * - InlineStep (step with body defined inline)\n */\nexport type StepReference = string | StepReferenceObject | InlineStep;\n\n\n/**\n * ComposedTaskTemplate - Task built from step composition\n *\n * This is the new task format that replaces monolithic baseContent strings\n * with an array of step references.\n */\nexport interface ComposedTaskTemplate {\n  /**\n   * Unique task identifier (kebab-case)\n   */\n  slug: string;\n\n  /**\n   * Human-readable task name\n   */\n  name: string;\n\n  /**\n   * Brief task description\n   */\n  description: string;\n\n  /**\n   * Frontmatter for slash command generation\n   */\n  frontmatter: TaskFrontmatter;\n\n  /**\n   * Ordered list of step references that compose this task.\n   * Steps are assembled in order with auto-generated step numbers.\n   */\n  steps: StepReference[];\n\n  /**\n   * Required subagents - task fails to build without these.\n   * Instructions for required subagents should be embedded in step content.\n   */\n  requiredSubagents: string[];\n\n  /**\n   * Optional subagents - enhance task when configured.\n   * Steps using these are conditionally included.\n   */\n  optionalSubagents?: string[];\n\n  /**\n   * Task slugs that can be invoked during execution.\n   */\n  dependentTasks?: string[];\n}\n\n/**\n * Normalized step reference (internal use for library steps)\n */\nexport interface NormalizedStepReference {\n  stepId: string;\n  title?: string;\n  appendContent?: string;\n  conditionalOnSubagent?: string;\n}\n\n/**\n * Type guard to check if a StepReference is an InlineStep\n */\nexport function isInlineStep(ref: StepReference): ref is InlineStep {\n  return typeof ref === 'object' && 'inline' in ref && ref.inline === true;\n}\n\n/**\n * Type guard to check if a StepReference is a StepReferenceObject\n */\nexport function isStepReferenceObject(ref: StepReference): ref is StepReferenceObject {\n  return typeof ref === 'object' && 'stepId' in ref;\n}\n\n/**\n * Normalize a step reference to its full object form (for library steps only)\n * Returns null for inline steps - use isInlineStep to check first\n */\nexport function normalizeStepReference(ref: StepReference): NormalizedStepReference | null {\n  if (isInlineStep(ref)) {\n    return null; // Inline steps don't normalize to NormalizedStepReference\n  }\n  if (typeof ref === 'string') {\n    return { stepId: ref };\n  }\n  return ref as StepReferenceObject;\n}\n","/**\n * Task Slug Constants\n * Single source of truth for all task identifiers\n *\n * These constants should be used throughout the codebase instead of hardcoded strings\n * to ensure type safety and prevent typos.\n */\nexport const TASK_SLUGS = {\n  EXPLORE_APPLICATION: 'explore-application',\n  ONBOARD_TESTING: 'onboard-testing',\n  GENERATE_TEST_CASES: 'generate-test-cases',\n  GENERATE_TEST_PLAN: 'generate-test-plan',\n  HANDLE_MESSAGE: 'handle-message',\n  PROCESS_EVENT: 'process-event',\n  RUN_TESTS: 'run-tests',\n  VERIFY_CHANGES: 'verify-changes',\n  /** @deprecated Use ONBOARD_TESTING instead */\n  FULL_TEST_COVERAGE: 'onboard-testing',\n} as const;\n\n/**\n * Type for task slugs\n * Ensures only valid task slugs can be used\n */\nexport type TaskSlug = typeof TASK_SLUGS[keyof typeof TASK_SLUGS];\n","/**\n * Generate Test Cases Task (Composed)\n * Generate both manual test case documentation AND automated Playwright test scripts\n */\n\nimport type { ComposedTaskTemplate } from '../steps/types';\nimport { TASK_SLUGS } from '../constants';\n\nexport const generateTestCasesTask: ComposedTaskTemplate = {\n  slug: TASK_SLUGS.GENERATE_TEST_CASES,\n  name: 'Generate Test Cases',\n  description: 'Generate manual test case documentation AND automated Playwright test scripts from test plan',\n\n  frontmatter: {\n    description: 'Generate manual test case documentation AND automated Playwright test scripts from test plan',\n    'argument-hint': '--type [exploratory|functional|regression|smoke] --focus [optional-feature]',\n  },\n\n  steps: [\n    // Step 1: Overview (inline)\n    {\n      inline: true,\n      title: 'Generate Test Cases Overview',\n      content: `Generate comprehensive test artifacts including BOTH manual test case documentation AND automated Playwright test scripts.\n\nThis command generates:\n1. **Manual Test Case Documentation** (in \\`./test-cases/\\`) - Human-readable test cases in markdown format\n2. **Automated Playwright Tests** (in \\`./tests/specs/\\`) - Executable TypeScript test scripts\n3. **Page Object Models** (in \\`./tests/pages/\\`) - Reusable page classes for automated tests\n4. **Supporting Files** (fixtures, helpers, components) - As needed for test automation`,\n    },\n    // Step 2: Security Notice (library)\n    'security-notice',\n    // Step 3: Arguments (inline)\n    {\n      inline: true,\n      title: 'Arguments',\n      content: `Arguments: $ARGUMENTS\n\n**Parse Arguments:**\nExtract the following from arguments:\n- **type**: Test type (exploratory, functional, regression, smoke) - defaults to functional\n- **focus**: Optional specific feature or section to focus on`,\n    },\n    // Step 4: Load Project Context (library)\n    'load-project-context',\n    // Step 5: Knowledge Base Read (library)\n    'read-knowledge-base',\n    // Step 5: Gather Context (inline)\n    {\n      inline: true,\n      title: 'Gather Context',\n      content: `**1.1 Read Test Plan**\nRead the test plan from \\`test-plan.md\\` to understand:\n- Test items and features\n- Testing approach and automation strategy\n- Test Automation Strategy section (automated vs exploratory)\n- Pass/fail criteria\n- Test environment and data requirements\n- Automation decision criteria\n\n**1.2 Check Existing Test Cases and Tests**\n- List all files in \\`./test-cases/\\` to understand existing manual test coverage\n- List all files in \\`./tests/specs/\\` to understand existing automated tests\n- Determine next test case ID (TC-XXX format)\n- Identify existing Page Objects in \\`./tests/pages/\\`\n- Avoid creating overlapping test cases or duplicate automation`,\n    },\n    // Step 6: Documentation Researcher (conditional inline)\n    {\n      inline: true,\n      title: 'Gather Product Documentation',\n      content: `{{INVOKE_DOCUMENTATION_RESEARCHER}} to gather comprehensive product documentation:\n\n\\`\\`\\`\nExplore all available product documentation, specifically focusing on:\n- UI elements and workflows\n- User interactions and navigation paths\n- Form fields and validation rules\n- Error messages and edge cases\n- Authentication and authorization flows\n- Business rules and constraints\n- API endpoints for test data setup\n\\`\\`\\``,\n      conditionalOnSubagent: 'documentation-researcher',\n    },\n    // Step 7: Exploration Protocol (from library)\n    'exploration-protocol',\n    // Step 8: Clarification Protocol (from library)\n    'clarification-protocol',\n    // Step 9: Organize Test Scenarios (inline - task-specific)\n    {\n      inline: true,\n      title: 'Organize Test Scenarios by Area',\n      content: `Based on exploration and documentation, organize test scenarios by feature area/component:\n\n**Group scenarios into areas** (e.g., Authentication, Dashboard, Checkout, Profile Management):\n- Each area should be a logical feature grouping\n- Areas should be relatively independent for parallel test execution\n- Consider the application's navigation structure and user flows\n\n**For each area, identify scenarios**:\n\n1. **Critical User Paths** (must automate as smoke tests):\n   - Login/authentication flows\n   - Core feature workflows\n   - Data creation/modification flows\n   - Critical business transactions\n\n2. **Happy Path Scenarios** (automate for regression):\n   - Standard user workflows\n   - Common use cases\n   - Typical data entry patterns\n\n3. **Error Handling Scenarios** (evaluate automation ROI):\n   - Validation error messages\n   - Network error handling\n   - Permission/authorization errors\n\n4. **Edge Cases** (consider manual testing):\n   - Rare scenarios (<1% occurrence)\n   - Complex exploratory scenarios\n   - Visual/UX validation requiring judgment\n   - Features in heavy flux\n\n**Output**: Test scenarios organized by area with automation decisions for each\n\nExample structure:\n- **Authentication**: TC-001 Valid login (smoke, automate), TC-002 Invalid password (automate), TC-003 Password reset (automate)\n- **Dashboard**: TC-004 View dashboard widgets (smoke, automate), TC-005 Filter data by date (automate), TC-006 Export data (manual - rare use)`,\n    },\n    // Step 10: Generate Manual Test Cases (inline)\n    {\n      inline: true,\n      title: 'Generate All Manual Test Case Files',\n      content: `Generate ALL manual test case markdown files in the \\`./test-cases/\\` directory BEFORE invoking the test-code-generator agent.\n\n**For each test scenario from the previous step:**\n\n1. **Create test case file** in \\`./test-cases/\\` with format \\`TC-XXX-feature-description.md\\`\n2. **Include frontmatter** with:\n   - \\`id:\\` TC-XXX (sequential ID)\n   - \\`title:\\` Clear, descriptive title\n   - \\`automated:\\` true/false (based on automation decision)\n   - \\`automated_test:\\` (leave empty - will be filled by subagent when automated)\n   - \\`type:\\` exploratory/functional/regression/smoke\n   - \\`area:\\` Feature area/component\n3. **Write test case content**:\n   - **Objective**: Clear description of what is being tested\n   - **Preconditions**: Setup requirements, test data needed\n   - **Test Steps**: Numbered, human-readable steps\n   - **Expected Results**: What should happen at each step\n   - **Test Data**: Environment variables to use (e.g., \\${TEST_BASE_URL}, \\${TEST_OWNER_EMAIL})\n   - **Notes**: Any assumptions, clarifications needed, or special considerations\n\n**Output**: All manual test case markdown files created in \\`./test-cases/\\` with automation flags set`,\n    },\n    // Step 11: Automate Test Cases (inline - detailed instructions for test-code-generator)\n    {\n      inline: true,\n      title: 'Automate Test Cases Area by Area',\n      content: `**IMPORTANT**: Process each feature area separately to enable incremental, focused test creation.\n\n**For each area**, invoke the test-code-generator agent:\n\n**Prepare Area Context:**\nBefore invoking the agent, identify the test cases for the current area:\n- Current area name\n- Test case files for this area (e.g., TC-001-valid-login.md, TC-002-invalid-password.md)\n- Which test cases are marked for automation (automated: true)\n- Test type from arguments\n- Test plan reference: test-plan.md\n- Existing automated tests in ./tests/specs/\n- Existing Page Objects in ./tests/pages/\n\n**Invoke test-code-generator Agent:**\n\n{{INVOKE_TEST_CODE_GENERATOR}} for the current area with the following context:\n\n\"Automate test cases for the [AREA_NAME] area.\n\n**Context:**\n- Area: [AREA_NAME]\n- Manual test case files to automate: [list TC-XXX files marked with automated: true]\n- Test type: {type}\n- Test plan: test-plan.md\n- Manual test cases directory: ./test-cases/\n- Existing automated tests: ./tests/specs/\n- Existing Page Objects: ./tests/pages/\n\n**The agent should:**\n1. Read the manual test case files for this area\n2. Check existing Page Object infrastructure for this area\n3. Explore the feature area to understand implementation (gather selectors, URLs, flows)\n4. Build missing Page Objects and supporting code\n5. For each test case marked \\`automated: true\\`:\n   - Create automated Playwright test in ./tests/specs/\n   - Update the manual test case file to reference the automated test path\n6. Run and iterate on each test until it passes or fails with a product bug\n7. Update .env.testdata with any new variables\n\n**Focus only on the [AREA_NAME] area** - do not automate tests for other areas yet.\"\n\n**Verify Area Completion:**\nAfter the agent completes the area, verify:\n- Manual test case files updated with automated_test references\n- Automated tests created for all test cases marked automated: true\n- Tests are passing (or failing with documented product bugs)\n- Page Objects created/updated for the area\n\n**Repeat for Next Area:**\nMove to the next area and repeat until all areas are complete.\n\n**Benefits of area-by-area approach**:\n- Agent focuses on one feature at a time\n- POMs built incrementally as needed\n- Tests verified before moving to next area\n- Easier to manage and track progress\n- Can pause/resume between areas if needed`,\n    },\n    // Step 12: Validate Artifacts (library)\n    'validate-test-artifacts',\n    // Step 13: Create Directories (inline)\n    {\n      inline: true,\n      title: 'Create Directories if Needed',\n      content: `Ensure required directories exist:\n\\`\\`\\`bash\nmkdir -p ./test-cases\nmkdir -p ./tests/specs\nmkdir -p ./tests/pages\nmkdir -p ./tests/components\nmkdir -p ./tests/fixtures\nmkdir -p ./tests/helpers\n\\`\\`\\``,\n    },\n    // Step 14: Extract Env Variables (library)\n    'extract-env-variables',\n    // Step 15: Knowledge Base Update (library)\n    'update-knowledge-base',\n    // Step 16: Team Communication (conditional inline)\n    {\n      inline: true,\n      title: 'Team Communication',\n      content: `{{INVOKE_TEAM_COMMUNICATOR}} to notify the product team about the new test cases and automated tests:\n\n\\`\\`\\`\n1. Post an update about test case and automation creation\n2. Provide summary of coverage:\n   - Number of manual test cases created\n   - Number of automated tests created\n   - Features covered by automation\n   - Areas kept manual-only (and why)\n3. Highlight key automated test scenarios\n4. Share command to run automated tests: npx playwright test\n5. Ask for team review and validation\n6. Mention any areas needing exploration or clarification\n7. Use appropriate channel and threading for the update\n\\`\\`\\`\n\nThe team communication should include:\n- **Test artifacts created**: Manual test cases + automated tests count\n- **Automation coverage**: Which features are now automated\n- **Manual-only areas**: Why some tests are kept manual (rare scenarios, exploratory)\n- **Key automated scenarios**: Critical paths now covered by automation\n- **Running tests**: Command to execute automated tests\n- **Review request**: Ask team to validate scenarios and review test code\n- **Next steps**: Plans for CI/CD integration or additional test coverage\n\n**Update team communicator memory:**\n- Record this communication\n- Note test case and automation creation\n- Track team feedback on automation approach\n- Document any clarifications requested`,\n      conditionalOnSubagent: 'team-communicator',\n    },\n    // Step 17: Final Summary (inline)\n    {\n      inline: true,\n      title: 'Final Summary',\n      content: `Provide a comprehensive summary showing:\n\n**Manual Test Cases:**\n- Number of manual test cases created\n- List of test case files with IDs and titles\n- Automation status for each (automated: yes/no)\n\n**Automated Tests:**\n- Number of automated test scripts created\n- List of spec files with test counts\n- Page Objects created or updated\n- Fixtures and helpers added\n\n**Test Coverage:**\n- Features covered by manual tests\n- Features covered by automated tests\n- Areas kept manual-only (and why)\n\n**Next Steps:**\n- Command to run automated tests: \\`npx playwright test\\`\n- Instructions to run specific test file\n- Note about copying .env.testdata to .env\n- Mention any exploration needed for edge cases\n\n**Important Notes:**\n- **Both Manual AND Automated**: Generate both artifacts - they serve different purposes\n- **Manual Test Cases**: Documentation, reference, can be executed manually when needed\n- **Automated Tests**: Fast, repeatable, for CI/CD and regression testing\n- **Automation Decision**: Not all test cases need automation - rare edge cases can stay manual\n- **Linking**: Manual test cases reference automated tests; automated tests reference manual test case IDs\n- **Two-Phase Workflow**: First generate all manual test cases, then automate area-by-area\n- **Ambiguity Handling**: Use exploration and clarification protocols before generating\n- **Environment Variables**: Use \\`process.env.VAR_NAME\\` in tests, update .env.testdata as needed\n- **Test Independence**: Each test must be runnable in isolation and in parallel`,\n    },\n  ],\n\n  requiredSubagents: ['test-runner', 'test-code-generator'],\n  optionalSubagents: ['documentation-researcher', 'team-communicator'],\n  dependentTasks: [],\n};\n","/**\n * Generate Test Plan Task (Composed)\n * Generate a comprehensive test plan from product description\n */\n\nimport type { ComposedTaskTemplate } from '../steps/types';\nimport { TASK_SLUGS } from '../constants';\n\nexport const generateTestPlanTask: ComposedTaskTemplate = {\n  slug: TASK_SLUGS.GENERATE_TEST_PLAN,\n  name: 'Generate Test Plan',\n  description: 'Generate a concise feature checklist test plan from product description',\n\n  frontmatter: {\n    description: 'Generate a concise feature checklist test plan (~50-100 lines)',\n    'argument-hint': '<product-description>',\n  },\n\n  steps: [\n    // Step 1: Overview (inline)\n    {\n      inline: true,\n      title: 'Generate Test Plan Overview',\n      content: `Generate a comprehensive test plan from product description following the Brain Module specifications.`,\n    },\n    // Step 2: Security Notice (library)\n    'security-notice',\n    // Step 3: Arguments (inline)\n    {\n      inline: true,\n      title: 'Arguments',\n      content: `Product description: $ARGUMENTS`,\n    },\n    // Step 4: Load Project Context (library)\n    'load-project-context',\n    // Step 5: Knowledge Base Read (library)\n    'read-knowledge-base',\n    // Step 6: Process Description (inline)\n    {\n      inline: true,\n      title: 'Process the Product Description',\n      content: `Use the product description provided directly in the arguments, enriched with project context understanding.`,\n    },\n    // Step 7: Initialize Env Tracking (inline)\n    {\n      inline: true,\n      title: 'Initialize Environment Variables Tracking',\n      content: `Create a list to track all TEST_ prefixed environment variables discovered throughout the process.`,\n    },\n    // Step 8: Documentation Researcher (conditional inline)\n    {\n      inline: true,\n      title: 'Gather Comprehensive Project Documentation',\n      content: `{{INVOKE_DOCUMENTATION_RESEARCHER}} to explore and gather all available project information and other documentation sources. This ensures the test plan is based on complete and current information.\n\n\\`\\`\\`\nExplore all available project documentation related to: $ARGUMENTS\n\nSpecifically gather:\n- Product specifications and requirements\n- User stories and acceptance criteria\n- Technical architecture documentation\n- API documentation and endpoints\n- User roles and permissions\n- Business rules and validations\n- UI/UX specifications\n- Known limitations or constraints\n- Existing test documentation\n- Bug reports or known issues\n\\`\\`\\`\n\nThe agent will:\n1. Check its memory for previously discovered documentation\n2. Explore workspace for relevant pages and databases\n3. Build a comprehensive understanding of the product\n4. Return synthesized information about all discovered documentation`,\n      conditionalOnSubagent: 'documentation-researcher',\n    },\n    // Step 9: Exploration Protocol (from library)\n    'exploration-protocol',\n    // Step 10: Clarification Protocol (from library)\n    'clarification-protocol',\n    // Step 11: Prepare Context (inline)\n    {\n      inline: true,\n      title: 'Prepare Test Plan Generation Context',\n      content: `**After ensuring requirements are clear through exploration and clarification:**\n\nBased on the gathered information:\n- **goal**: Extract the main purpose and objectives from all available documentation\n- **knowledge**: Combine product description with discovered documentation insights\n- **testPlan**: Use the standard test plan template structure, enriched with documentation findings\n- **gaps**: Identify areas lacking documentation that will need exploration`,\n    },\n    // Step 12: Generate Test Plan (inline - more detailed than library step)\n    {\n      inline: true,\n      title: 'Generate Test Plan Using Simplified Format',\n      content: `You are an expert QA Test Plan Writer. Generate a **concise** test plan (~50-100 lines) that serves as a feature checklist for test case generation.\n\n**CRITICAL - Keep it Simple:**\n- The test plan is a **feature checklist**, NOT a comprehensive document\n- Detailed UI elements and exploration findings go to \\`./exploration-reports/\\`\n- Technical patterns and architecture go to \\`.bugzy/runtime/knowledge-base.md\\`\n- Process documentation stays in \\`.bugzy/runtime/project-context.md\\`\n\n**Writing Instructions:**\n- **Use Product Terminology:** Use exact feature names from the product description\n- **Feature Checklist Format:** Each feature is a checkbox item with brief description\n- **Group by Feature Area:** Organize features into logical sections\n- **NO detailed UI elements** - those belong in exploration reports\n- **NO test scenarios** - those are generated in test cases\n- **NO process documentation** - keep only what's needed for test generation\n\n**Test Data Handling:**\n- Test data goes ONLY to \\`.env.testdata\\` file\n- In test plan, reference environment variable NAMES only (e.g., TEST_BASE_URL)\n- DO NOT generate values for env vars, only keys\n- Track all TEST_ variables for extraction to .env.testdata in the next step`,\n    },\n    // Step 13: Create Test Plan File (inline)\n    {\n      inline: true,\n      title: 'Create Test Plan File',\n      content: `Read the simplified template from \\`.bugzy/runtime/templates/test-plan-template.md\\` and fill it in:\n\n1. Read the template file\n2. Replace placeholders:\n   - \\`[PROJECT_NAME]\\` with the actual project name\n   - \\`[DATE]\\` with the current date\n   - Feature sections with actual features grouped by area\n3. Each feature is a **checkbox item** with brief description\n4. **Mark ambiguities:**\n   - MEDIUM: Mark with [ASSUMED: reason]\n   - LOW: Mark with [TO BE EXPLORED: detail]\n5. Keep total document under 100 lines`,\n    },\n    // Step 14: Save Test Plan (inline)\n    {\n      inline: true,\n      title: 'Save Test Plan',\n      content: `Save to \\`test-plan.md\\` in project root. The template already includes frontmatter - just fill in the dates.`,\n    },\n    // Step 15: Extract Env Variables (inline - more detailed than library step)\n    {\n      inline: true,\n      title: 'Extract and Save Environment Variables',\n      content: `**CRITICAL**: Test data values must ONLY go to .env.testdata, NOT in the test plan document.\n\nAfter saving the test plan:\n\n1. **Parse the test plan** to find all TEST_ prefixed environment variables mentioned:\n   - Look in the Testing Environment section\n   - Search for any TEST_ variables referenced\n   - Extract variables from configuration or setup sections\n   - Common patterns include: TEST_BASE_URL, TEST_USER_*, TEST_API_*, TEST_ADMIN_*, etc.\n\n2. **Create .env.testdata file** with all discovered variables:\n   \\`\\`\\`bash\n   # Application Configuration\n   TEST_BASE_URL=\n\n   # Test User Credentials\n   TEST_USER_EMAIL=\n   TEST_USER_PASSWORD=\n   TEST_ADMIN_EMAIL=\n   TEST_ADMIN_PASSWORD=\n\n   # API Configuration\n   TEST_API_KEY=\n   TEST_API_SECRET=\n\n   # Other Test Data\n   TEST_DB_NAME=\n   TEST_TIMEOUT=\n   \\`\\`\\`\n\n3. **Add helpful comments** for each variable group to guide users in filling values\n\n4. **Save the file** as \\`.env.testdata\\` in the project root\n\n5. **Verify test plan references .env.testdata**:\n   - Ensure test plan DOES NOT contain test data values\n   - Ensure test plan references \\`.env.testdata\\` for test data requirements\n   - Add instruction: \"Fill in actual values in .env.testdata before running tests\"`,\n    },\n    // Step 16: Knowledge Base Update (library)\n    'update-knowledge-base',\n    // Step 17: Team Communication (conditional inline)\n    {\n      inline: true,\n      title: 'Team Communication',\n      content: `{{INVOKE_TEAM_COMMUNICATOR}} to notify the product team about the new test plan:\n\n\\`\\`\\`\n1. Post an update about the test plan creation\n2. Provide a brief summary of coverage areas and key features\n3. Mention any areas that need exploration or clarification\n4. Ask for team review and feedback on the test plan\n5. Include a link or reference to the test-plan.md file\n6. Use appropriate channel and threading for the update\n\\`\\`\\`\n\nThe team communication should include:\n- **Test plan scope**: Brief overview of what will be tested\n- **Coverage highlights**: Key features and user flows included\n- **Areas needing clarification**: Any uncertainties discovered during documentation research\n- **Review request**: Ask team to review and provide feedback\n- **Next steps**: Mention plan to generate test cases after review\n\n**Update team communicator memory:**\n- Record this communication in the team-communicator memory\n- Note this as a test plan creation communication\n- Track team response to this type of update`,\n      conditionalOnSubagent: 'team-communicator',\n    },\n    // Step 18: Final Summary (inline)\n    {\n      inline: true,\n      title: 'Final Summary',\n      content: `Provide a summary of:\n- Test plan created successfully at \\`test-plan.md\\`\n- Environment variables extracted to \\`.env.testdata\\`\n- Number of TEST_ variables discovered\n- Instructions for the user to fill in actual values in .env.testdata before running tests`,\n    },\n  ],\n\n  requiredSubagents: ['test-runner'],\n  optionalSubagents: ['documentation-researcher', 'team-communicator'],\n  dependentTasks: [],\n};\n","/**\n * Handle Message Task (Composed)\n * Handle team responses and Slack communications, maintaining context for ongoing conversations\n *\n * Slack messages are processed by the LLM layer (lib/slack/llm-processor.ts)\n * which routes feedback/general chat to this task via the 'collect_feedback' action.\n * This task must be in SLACK_ALLOWED_TASKS to be Slack-callable.\n */\n\nimport type { ComposedTaskTemplate } from '../steps/types';\nimport { TASK_SLUGS } from '../constants';\n\nexport const handleMessageTask: ComposedTaskTemplate = {\n  slug: TASK_SLUGS.HANDLE_MESSAGE,\n  name: 'Handle Message',\n  description: 'Handle team responses and Slack communications, maintaining context for ongoing conversations (LLM-routed)',\n\n  frontmatter: {\n    description: 'Handle team responses and Slack communications, maintaining context for ongoing conversations',\n    'argument-hint': '[slack thread context or team message]',\n  },\n\n  steps: [\n    // Step 1: Overview (inline)\n    {\n      inline: true,\n      title: 'Handle Message Overview',\n      content: `# Handle Message Command\n\nProcess team responses from Slack threads and handle multi-turn conversations with the product team about testing clarifications, ambiguities, and questions.`,\n    },\n    // Step 2: Security Notice (library)\n    'security-notice',\n    // Step 3: Arguments (inline)\n    {\n      inline: true,\n      title: 'Arguments',\n      content: `Team message/thread context: $ARGUMENTS`,\n    },\n    // Step 4: Load Project Context (library)\n    'load-project-context',\n    // Step 5: Knowledge Base Read (library)\n    'read-knowledge-base',\n    // Step 5: Detect Intent (inline - task-specific)\n    {\n      inline: true,\n      title: 'Detect Message Intent and Load Handler',\n      content: `Before processing the message, identify the intent type to load the appropriate handler.\n\n#### 0.1 Extract Intent from Event Payload\n\nCheck the event payload for the \\`intent\\` field provided by the LLM layer:\n- If \\`intent\\` is present, use it directly\n- Valid intent values: \\`question\\`, \\`feedback\\`, \\`status\\`\n\n#### 0.2 Fallback Intent Detection (if no intent provided)\n\nIf intent is not in the payload, detect from message patterns:\n\n| Condition | Intent |\n|-----------|--------|\n| Keywords: \"status\", \"progress\", \"how did\", \"results\", \"how many passed\" | \\`status\\` |\n| Keywords: \"bug\", \"issue\", \"broken\", \"doesn't work\", \"failed\", \"error\" | \\`feedback\\` |\n| Question words: \"what\", \"which\", \"do we have\", \"is there\" about tests/project | \\`question\\` |\n| Default (none of above) | \\`feedback\\` |\n\n#### 0.3 Load Handler File\n\nBased on detected intent, load the handler from:\n\\`.bugzy/runtime/handlers/messages/{intent}.md\\`\n\n**Handler files:**\n- \\`question.md\\` - Questions about tests, coverage, project details\n- \\`feedback.md\\` - Bug reports, test observations, general information\n- \\`status.md\\` - Status checks on test runs, task progress\n\n#### 0.4 Follow Handler Instructions\n\n**IMPORTANT**: The handler file is authoritative for this intent type.\n\n1. Read the handler file completely\n2. Follow its processing steps in order\n3. Apply its context loading requirements\n4. Use its response guidelines\n5. Perform any memory updates it specifies\n\nThe handler file contains all necessary processing logic for the detected intent type. Each handler includes:\n- Specific processing steps for that intent\n- Context loading requirements\n- Response guidelines\n- Memory update instructions`,\n    },\n    // Step 6: Clarification Protocol (for ambiguous intents)\n    'clarification-protocol',\n    // Step 8: Knowledge Base Update (library)\n    'update-knowledge-base',\n    // Step 9: Key Principles (inline)\n    {\n      inline: true,\n      title: 'Key Principles',\n      content: `## Key Principles\n\n### Context Preservation\n- Always maintain full conversation context\n- Link responses back to original uncertainties\n- Preserve reasoning chain for future reference\n\n### Actionable Responses\n- Convert team input into concrete actions\n- Don't let clarifications sit without implementation\n- Follow through on commitments made to team\n\n### Learning Integration\n- Each interaction improves our understanding\n- Build knowledge base of team preferences\n- Refine communication approaches over time\n\n### Quality Communication\n- Acknowledge team input appropriately\n- Provide updates on actions taken\n- Ask good follow-up questions when needed`,\n    },\n    // Step 10: Important Considerations (inline)\n    {\n      inline: true,\n      title: 'Important Considerations',\n      content: `## Important Considerations\n\n### Thread Organization\n- Keep related discussions in same thread\n- Start new threads for new topics\n- Maintain clear conversation boundaries\n\n### Response Timing\n- Acknowledge important messages promptly\n- Allow time for implementation before status updates\n- Don't spam team with excessive communications\n\n### Action Prioritization\n- Address urgent clarifications first\n- Batch related updates when possible\n- Focus on high-impact changes\n\n### Memory Maintenance\n- Keep active conversations visible and current\n- Archive resolved discussions appropriately\n- Maintain searchable history of resolutions`,\n    },\n  ],\n\n  requiredSubagents: ['team-communicator'],\n  optionalSubagents: [],\n  dependentTasks: ['verify-changes'],\n};\n","/**\n * Process Event Task (Composed)\n * Process external system events (Jira, GitHub, Linear) using handler-defined rules to extract insights and track issues\n */\n\nimport type { ComposedTaskTemplate } from '../steps/types';\nimport { TASK_SLUGS } from '../constants';\n\nexport const processEventTask: ComposedTaskTemplate = {\n  slug: TASK_SLUGS.PROCESS_EVENT,\n  name: 'Process Event',\n  description: 'Process external system events (Jira, GitHub, Linear) using handler-defined rules to extract insights and track issues',\n\n  frontmatter: {\n    description: 'Process external system events (Jira, GitHub, Linear) using handler-defined rules to extract insights and track issues',\n    'argument-hint': '[event payload or description]',\n  },\n\n  steps: [\n    // Step 1: Overview (inline)\n    {\n      inline: true,\n      title: 'Process Event Overview',\n      content: `# Process Event Command\n\nProcess various types of events using intelligent pattern matching and historical context to maintain and evolve the testing system.`,\n    },\n    // Step 2: Security Notice (library)\n    'security-notice',\n    // Step 3: Arguments (inline)\n    {\n      inline: true,\n      title: 'Arguments',\n      content: `Arguments: $ARGUMENTS`,\n    },\n    // Step 4: Load Project Context (library)\n    'load-project-context',\n    // Step 5: Knowledge Base Read (library)\n    'read-knowledge-base',\n    // Step 5: Understand Event Context (inline)\n    {\n      inline: true,\n      title: 'Understand Event Context',\n      content: `Events come from integrated external systems via webhooks or manual input. Common sources include:\n- **Issue Trackers**: Jira, Linear, GitHub Issues\n- **Source Control**: GitHub, GitLab\n- **Communication Tools**: Slack\n\n**Event structure and semantics vary by source.** Do not interpret events based on generic assumptions. Instead, load the appropriate handler file for system-specific processing rules.\n\n#### Event Context to Extract:\n- **What happened**: The core event (test failed, PR merged, etc.)\n- **Where**: Component, service, or area affected\n- **Impact**: How this affects testing strategy\n- **Action Required**: What needs to be done in response`,\n    },\n    // Step 6: Clarify Unclear Events (inline - task-specific)\n    {\n      inline: true,\n      title: 'Clarify Unclear Events',\n      content: `If the event information is incomplete or ambiguous, seek clarification before processing:\n\n#### Detect Unclear Events\n\nEvents may be unclear in several ways:\n- **Vague description**: \"Something broke\", \"issue with login\" (what specifically?)\n- **Missing context**: Which component, which environment, which user?\n- **Contradictory information**: Event data conflicts with other sources\n- **Unknown references**: Mentions unfamiliar features, components, or systems\n- **Unclear severity**: Impact or priority is ambiguous\n\n#### Assess Ambiguity Severity\n\nClassify the ambiguity level to determine appropriate response:\n\n**🔴 CRITICAL - STOP and seek clarification:**\n- Cannot identify which component is affected\n- Event data is contradictory or nonsensical\n- Unknown system or feature mentioned\n- Cannot determine if this requires immediate action\n- Example: Event says \"production is down\" but unclear which service\n\n**🟠 HIGH - STOP and seek clarification:**\n- Vague problem description that could apply to multiple areas\n- Missing critical context needed for proper response\n- Unclear which team or system is responsible\n- Example: \"Login issue reported\" (login button? auth service? session? which page?)\n\n**🟡 MEDIUM - Proceed with documented assumptions:**\n- Some details missing but core event is clear\n- Can infer likely meaning from context\n- Can proceed but should clarify async\n- Example: \"Test failed on staging\" (can assume main staging, but clarify which one)\n\n**🟢 LOW - Mark and proceed:**\n- Minor details missing (optional context)\n- Cosmetic or non-critical information gaps\n- Can document gap and continue\n- Example: Missing timestamp or exact user who reported issue\n\n#### Clarification Approach by Severity\n\n**For CRITICAL/HIGH ambiguity:**\n1. **{{INVOKE_TEAM_COMMUNICATOR}} to ask specific questions**\n2. **WAIT for response before proceeding**\n3. **Document the clarification request in event history**\n\nExample clarification messages:\n- \"Event mentions 'login issue' - can you clarify if this is:\n  • Login button not responding?\n  • Authentication service failure?\n  • Session management problem?\n  • Specific page or global?\"\n\n- \"Event references component 'XYZ' which is unknown. What system does this belong to?\"\n\n- \"Event data shows contradictory information: status=success but error_count=15. Which is correct?\"\n\n**For MEDIUM ambiguity:**\n1. **Document assumption** with reasoning\n2. **Proceed with processing** based on assumption\n3. **Ask for clarification async** (non-blocking)\n4. **Mark in event history** for future reference\n\nExample: [ASSUMED: \"login issue\" refers to login button based on recent similar events]\n\n**For LOW ambiguity:**\n1. **Mark with [TO BE CLARIFIED: detail]**\n2. **Continue processing** normally\n3. **Document gap** in event history\n\nExample: [TO BE CLARIFIED: Exact timestamp of when issue was first observed]\n\n#### Document Clarification Process\n\nIn event history, record:\n- **Ambiguity detected**: What was unclear\n- **Severity assessed**: CRITICAL/HIGH/MEDIUM/LOW\n- **Clarification requested**: Questions asked (if any)\n- **Response received**: Team's clarification\n- **Assumption made**: If proceeded with assumption\n- **Resolution**: How ambiguity was resolved\n\nThis ensures future similar events can reference past clarifications and avoid redundant questions.`,\n    },\n    // Step 7: Load Context and Memory (inline)\n    {\n      inline: true,\n      title: 'Load Context and Memory',\n      content: `### Step 2: Load Context and Memory\n\n#### 2.1 Check Event Processor Memory\nRead \\`.bugzy/runtime/memory/event-processor.md\\` to:\n- Find similar event patterns\n- Load example events with reasoning\n- Get system-specific rules\n- Retrieve task mapping patterns\n\n#### 2.2 Check Event History\nRead \\`.bugzy/runtime/memory/event-history.md\\` to:\n- Ensure event hasn't been processed already (idempotency)\n- Find related recent events\n- Understand event patterns and trends\n\n#### 2.3 Read Current State\n- Read \\`test-plan.md\\` for current coverage\n- List \\`./test-cases/\\` for existing tests\n- Check \\`.bugzy/runtime/knowledge-base.md\\` for past insights\n\n#### 2.4 Load System-Specific Handler (REQUIRED)\n\nBased on the event source, load the handler from \\`.bugzy/runtime/handlers/\\`:\n\n**Step 1: Detect Event Source from Payload:**\n- \\`com.jira-server.*\\` event type prefix -> \\`.bugzy/runtime/handlers/jira.md\\`\n- \\`github.*\\` or GitHub webhook structure -> \\`.bugzy/runtime/handlers/github.md\\`\n- \\`linear.*\\` or Linear webhook -> \\`.bugzy/runtime/handlers/linear.md\\`\n- Other sources -> Check for matching handler file by source name\n\n**Step 2: Load and Read the Handler File:**\nThe handler file contains system-specific instructions for:\n- Event payload structure and field meanings\n- Which triggers (status changes, resolutions) require specific actions\n- How to interpret different event types\n- When to invoke \\`/verify-changes\\`\n- How to update the knowledge base\n\n**Step 3: Follow Handler Instructions:**\nThe handler file is authoritative for this event source. Follow its instructions for:\n- Interpreting the event payload\n- Determining what actions to take\n- Formatting responses and updates\n\n**Step 4: If No Handler Exists:**\nDo NOT guess or apply generic logic. Instead:\n1. Inform the user that no handler exists for this event source\n2. Ask how this event type should be processed\n3. Suggest creating a handler file at \\`.bugzy/runtime/handlers/{source}.md\\`\n\n**Project-Specific Configuration:**\nHandlers reference \\`.bugzy/runtime/project-context.md\\` for project-specific rules like:\n- Which status transitions trigger verify-changes\n- Which resolutions should update the knowledge base\n- Which transitions to ignore`,\n    },\n    // Step 8: Intelligent Event Analysis (inline)\n    {\n      inline: true,\n      title: 'Intelligent Event Analysis',\n      content: `### Step 3: Intelligent Event Analysis\n\n#### 3.1 Contextual Pattern Analysis\nDon't just match patterns - analyze the event within the full context:\n\n**Combine Multiple Signals**:\n- Event details + Historical patterns from memory\n- Current test plan state + Knowledge base\n- External system status + Team activity\n- Business priorities + Risk assessment\n\n**Example Contextual Analysis**:\n\\`\\`\\`\nEvent: Jira issue PROJ-456 moved to \"Ready for QA\"\n+ Handler: jira.md says \"Ready for QA\" triggers /verify-changes\n+ History: This issue was previously in \"In Progress\" for 3 days\n+ Knowledge: Related PR #123 merged yesterday\n= Decision: Invoke /verify-changes with issue context and PR reference\n\\`\\`\\`\n\n**Pattern Recognition with Context**:\n- An issue resolution depends on what the handler prescribes for that status\n- A duplicate event (same issue, same transition) should be skipped\n- Events from different sources about the same change should be correlated\n- Handler instructions take precedence over generic assumptions\n\n#### 3.2 Generate Semantic Queries\nBased on event type and content, generate 3-5 specific search queries:\n- Search for similar past events\n- Look for related test cases\n- Find relevant documentation\n- Check for known issues`,\n    },\n    // Step 9: Documentation Research (conditional inline)\n    {\n      inline: true,\n      title: 'Use Documentation Researcher',\n      content: `#### 3.3 Use Documentation Researcher if Needed\n\n{{INVOKE_DOCUMENTATION_RESEARCHER}} to find information about unknown features or components:\n\nFor events mentioning unknown features or components, ask the agent to explore project documentation and return:\n- Feature specifications\n- Related test cases\n- Known issues or limitations\n- Component dependencies`,\n      conditionalOnSubagent: 'documentation-researcher',\n    },\n    // Step 10: Task Planning (inline)\n    {\n      inline: true,\n      title: 'Task Planning with Reasoning',\n      content: `### Step 4: Task Planning with Reasoning\n\nGenerate tasks based on event analysis, using examples from memory as reference.\n\n#### Task Generation Logic:\nAnalyze the event in context of ALL available information to decide what actions to take:\n\n**Consider the Full Context**:\n- What does the handler prescribe for this event type?\n- How does this relate to current knowledge?\n- What's the state of related issues in external systems?\n- Is this part of a larger pattern we've been seeing?\n- What's the business impact of this event?\n\n**Contextual Decision Making**:\nThe same event type can require different actions based on context:\n- If handler says this status triggers verification -> Invoke /verify-changes\n- If this issue was already processed (check event history) -> Skip to avoid duplicates\n- If related PR exists in knowledge base -> Include PR context in actions\n- If this is a recurring pattern from the same source -> Consider flagging for review\n- If handler has no rule for this event type -> Ask user for guidance\n\n**Dynamic Task Selection**:\nBased on the contextual analysis, decide which tasks make sense:\n- **extract_learning**: When the event reveals something new about the system\n- **update_test_plan**: When our understanding of what to test has changed\n- **update_test_cases**: When tests need to reflect new reality\n- **report_bug**: When we have a legitimate, impactful, reproducible issue\n- **skip_action**: When context shows no action needed (e.g., known issue, already fixed)\n\nThe key is to use ALL available context - not just react to the event type\n\n#### Document Reasoning:\nFor each task, document WHY it's being executed:\n\\`\\`\\`markdown\nTask: extract_learning\nReasoning: This event reveals a pattern of login failures on Chrome that wasn't previously documented\nData: \"Chrome-specific timeout issues with login button\"\n\\`\\`\\``,\n    },\n    // Step 11: Issue Tracking (conditional inline)\n    {\n      inline: true,\n      title: 'Issue Tracking',\n      content: `##### For Issue Tracking:\n\nWhen an issue needs to be tracked (task type: report_bug or update_story):\n\n{{INVOKE_ISSUE_TRACKER}}\n\n1. Check for duplicate issues in the tracking system\n2. For bugs: Create detailed bug report with:\n   - Clear, descriptive title\n   - Detailed description with context\n   - Step-by-step reproduction instructions\n   - Expected vs actual behavior\n   - Environment and configuration details\n   - Test case reference (if applicable)\n   - Screenshots or error logs\n3. For stories: Update status and add QA comments\n4. Track issue lifecycle and maintain categorization\n\nThe issue-tracker agent will handle all aspects of issue tracking including duplicate detection, story management, QA workflow transitions, and integration with your project management system (Jira, Linear, Notion, etc.).`,\n      conditionalOnSubagent: 'issue-tracker',\n    },\n    // Step 12: Execute Tasks (inline)\n    {\n      inline: true,\n      title: 'Execute Tasks with Memory Updates',\n      content: `### Step 5: Execute Tasks with Memory Updates\n\n#### 5.1 Execute Each Task\nFollow the standard execution logic with added context from memory.\n\n#### 5.2 Update Event Processor Memory\nIf new patterns discovered, append to \\`.bugzy/runtime/memory/event-processor.md\\`:\n\\`\\`\\`markdown\n### Pattern: [New Pattern Name]\n**First Seen**: [Date]\n**Indicators**: [What identifies this pattern]\n**Typical Tasks**: [Common task responses]\n**Example**: [This event]\n\\`\\`\\`\n\n#### 5.3 Update Event History\nAppend to \\`.bugzy/runtime/memory/event-history.md\\`:\n\\`\\`\\`markdown\n## [Timestamp] - Event #[ID]\n\n**Original Input**: [Raw arguments provided]\n**Parsed Event**:\n\\`\\`\\`yaml\ntype: [type]\nsource: [source]\n[other fields]\n\\`\\`\\`\n\n**Pattern Matched**: [Pattern name or \"New Pattern\"]\n**Tasks Executed**:\n1. [Task 1] - Reasoning: [Why]\n2. [Task 2] - Reasoning: [Why]\n\n**Files Modified**:\n- [List of files]\n\n**Outcome**: [Success/Partial/Failed]\n**Notes**: [Any additional context]\n---\n\\`\\`\\``,\n    },\n    // Step 13: Learning and Maintenance (inline)\n    {\n      inline: true,\n      title: 'Learning from Events',\n      content: `### Step 6: Learning from Events\n\nAfter processing, check if this event teaches us something new:\n1. Is this a new type of event we haven't seen?\n2. Did our task planning work well?\n3. Should we update our patterns?\n4. Are there trends across recent events?\n\nIf yes, update the event processor memory with new patterns or refined rules.\n\n### Step 7: Create Necessary Files\n\nEnsure all required files and directories exist:\n\\`\\`\\`bash\nmkdir -p ./test-cases .claude/memory\n\\`\\`\\`\n\nCreate files if they don't exist:\n- \\`.bugzy/runtime/knowledge-base.md\\`\n- \\`.bugzy/runtime/memory/event-processor.md\\`\n- \\`.bugzy/runtime/memory/event-history.md\\``,\n    },\n    // Step 14: Knowledge Base Update (library)\n    'update-knowledge-base',\n    // Step 15: Important Considerations (inline)\n    {\n      inline: true,\n      title: 'Important Considerations',\n      content: `## Important Considerations\n\n### Contextual Intelligence\n- Never process events in isolation - always consider full context\n- Use knowledge base, history, and external system state to inform decisions\n- What seems like a bug might be expected behavior given the context\n- A minor event might be critical when seen as part of a pattern\n\n### Adaptive Response\n- Same event type can require different actions based on context\n- Learn from each event to improve future decision-making\n- Build understanding of system behavior over time\n- Adjust responses based on business priorities and risk\n\n### Smart Task Generation\n- Only take actions prescribed by the handler or confirmed by the user\n- Document why each decision was made with full context\n- Skip redundant actions (e.g., duplicate events, already-processed issues)\n- Escalate appropriately based on pattern recognition\n\n### Continuous Learning\n- Each event adds to our understanding of the system\n- Update patterns when new correlations are discovered\n- Refine decision rules based on outcomes\n- Build institutional memory through event history`,\n    },\n  ],\n\n  requiredSubagents: ['team-communicator'],\n  optionalSubagents: ['documentation-researcher', 'issue-tracker'],\n  dependentTasks: ['verify-changes'],\n};\n","/**\n * Run Tests Task (Composed)\n * Select and run test cases using the test-runner agent\n */\n\nimport type { ComposedTaskTemplate } from '../steps/types';\nimport { TASK_SLUGS } from '../constants';\n\nexport const runTestsTask: ComposedTaskTemplate = {\n  slug: TASK_SLUGS.RUN_TESTS,\n  name: 'Run Tests',\n  description: 'Execute automated Playwright tests, analyze failures, and fix test issues automatically',\n\n  frontmatter: {\n    description: 'Execute automated Playwright tests, analyze failures, and fix test issues automatically',\n    'argument-hint': '[file-pattern|tag|all] (e.g., \"auth\", \"@smoke\", \"tests/specs/login.spec.ts\")',\n  },\n\n  steps: [\n    // Step 1: Overview (inline)\n    {\n      inline: true,\n      title: 'Run Tests Overview',\n      content: `# Run Tests Command\n\nExecute automated Playwright tests, analyze failures using JSON reports, automatically fix test issues, and log product bugs.`,\n    },\n    // Step 2: Security Notice (library)\n    'security-notice',\n    // Step 3: Arguments (inline)\n    {\n      inline: true,\n      title: 'Arguments',\n      content: `Arguments: $ARGUMENTS\n\n**Parse Arguments:**\nExtract the following from arguments:\n- **selector**: Test selection criteria\n  - File pattern: \"auth\" → finds tests/specs/**/*auth*.spec.ts\n  - Tag: \"@smoke\" → runs tests with @smoke annotation\n  - Specific file: \"tests/specs/login.spec.ts\"\n  - All tests: \"all\" or \"\" → runs entire test suite`,\n    },\n    // Step 4: Load Project Context (library)\n    'load-project-context',\n    // Step 5: Knowledge Base Read (library)\n    'read-knowledge-base',\n    // Step 5: Test Execution Strategy (library)\n    'read-test-strategy',\n    // Step 6: Identify Tests (inline - task-specific)\n    {\n      inline: true,\n      title: 'Identify Automated Tests to Run',\n      content: `#### Understand Test Selection\nParse the selector argument to determine which tests to run:\n\n**File Pattern** (e.g., \"auth\", \"login\"):\n- Find matching test files: \\`tests/specs/**/*[pattern]*.spec.ts\\`\n- Example: \"auth\" → finds all test files with \"auth\" in the name\n\n**Tag** (e.g., \"@smoke\", \"@regression\"):\n- Run tests with specific Playwright tag annotation\n- Use Playwright's \\`--grep\\` option\n\n**Specific File** (e.g., \"tests/specs/auth/login.spec.ts\"):\n- Run that specific test file\n\n**All Tests** (\"all\" or no selector):\n- Run entire test suite: \\`tests/specs/**/*.spec.ts\\`\n\n#### Find Matching Test Files\nUse glob patterns to find test files:\n\\`\\`\\`bash\n# For file pattern\nls tests/specs/**/*[pattern]*.spec.ts\n\n# For specific file\nls tests/specs/auth/login.spec.ts\n\n# For all tests\nls tests/specs/**/*.spec.ts\n\\`\\`\\`\n\n#### Validate Test Files Exist\nCheck that at least one test file was found:\n- If no tests found, inform user and suggest available tests\n- List available test files if selection was unclear\n\n#### Confirm Selection Before Execution\nBefore running tests, confirm the selection with the user if ambiguous:\n- **Clear selection** (specific file or tag): Proceed immediately\n- **Pattern match** (multiple files): List matching files and ask for confirmation if count > 5\n- **No selector** (all tests): Confirm running full suite before executing`,\n    },\n    // Step 7-10: Test Execution (library steps)\n    'run-playwright-tests',\n    'parse-test-results',\n    'triage-failures',\n    'fix-test-issues',\n    // Step 11: Log Product Bugs (conditional - library step)\n    {\n      stepId: 'log-product-bugs',\n      conditionalOnSubagent: 'issue-tracker',\n    },\n    // Step 12: Knowledge Base Update (library)\n    'update-knowledge-base',\n    // Step 13: Team Communication (conditional - library step)\n    {\n      stepId: 'notify-team',\n      conditionalOnSubagent: 'team-communicator',\n    },\n    // Step 14: Handle Special Cases (inline - task-specific)\n    {\n      inline: true,\n      title: 'Handle Special Cases',\n      content: `#### If No Test Cases Found\nIf no test cases match the selection criteria:\n1. Inform user that no matching test cases were found\n2. List available test cases or suggest running \\`/generate-test-cases\\` first\n3. Provide examples of valid selection criteria\n\n#### If Test Runner Agent Fails\nIf the test-runner agent encounters issues:\n1. Report the specific error\n2. Suggest troubleshooting steps\n3. Offer to run tests individually if batch execution failed\n\n#### If Test Cases Are Invalid\nIf selected test cases have formatting issues:\n1. Report which test cases are invalid\n2. Specify what's missing or incorrect\n3. Offer to fix the issues or skip invalid tests\n\n### Important Notes\n\n**Test Selection Strategy**:\n- **Always read** \\`.bugzy/runtime/test-execution-strategy.md\\` before selecting tests\n- Default to \\`@smoke\\` tests for fast validation unless user explicitly requests otherwise\n- Smoke tests provide 100% manual test case coverage with zero redundancy (~2-5 min)\n- Full regression includes intentional redundancy for diagnostic value (~10-15 min)\n- Use context keywords from user request to choose appropriate tier\n\n**Test Execution**:\n- Automated Playwright tests are executed via bash command, not through agents\n- Test execution time varies by tier (see strategy document for details)\n- JSON reports provide structured test results for analysis\n- Playwright automatically captures traces, screenshots, and videos on failures\n- Test artifacts are stored in test-results/ directory\n\n**Failure Handling**:\n- Test failures are automatically triaged (product bugs vs test issues)\n- Test issues are automatically fixed by the test-debugger-fixer subagent\n- Product bugs are logged via issue tracker after triage\n- All results are analyzed for learning opportunities and team communication\n- Critical failures trigger immediate team notification\n\n**Related Documentation**:\n- \\`.bugzy/runtime/test-execution-strategy.md\\` - When and why to run specific tests\n- \\`.bugzy/runtime/testing-best-practices.md\\` - How to write tests (patterns and anti-patterns)`,\n    },\n  ],\n\n  requiredSubagents: ['test-runner', 'test-debugger-fixer'],\n  optionalSubagents: ['issue-tracker', 'team-communicator'],\n  dependentTasks: [],\n};\n","/**\n * Verify Changes - Unified Multi-Trigger Task (Composed)\n * Single dynamic task that handles all trigger sources: manual, Slack, GitHub PR, CI/CD\n *\n * This task replaces verify-changes-manual and verify-changes-slack with intelligent\n * trigger detection and multi-channel output routing.\n */\n\nimport type { ComposedTaskTemplate } from '../steps/types';\nimport { TASK_SLUGS } from '../constants';\n\nexport const verifyChangesTask: ComposedTaskTemplate = {\n  slug: TASK_SLUGS.VERIFY_CHANGES,\n  name: 'Verify Changes',\n  description: 'Unified verification command for all trigger sources with automated tests and manual checklists',\n\n  frontmatter: {\n    description: 'Verify code changes with automated tests and manual verification checklists',\n    'argument-hint': '[trigger-auto-detected]',\n  },\n\n  steps: [\n    // Step 1: Overview (inline)\n    {\n      inline: true,\n      title: 'Verify Changes Overview',\n      content: `# Verify Changes - Unified Multi-Trigger Workflow\n\n## Overview\n\nThis task performs comprehensive change verification with:\n- **Automated testing**: Execute Playwright tests with automatic triage and fixing\n- **Manual verification checklists**: Generate role-specific checklists for non-automatable scenarios\n- **Multi-trigger support**: Works from manual CLI, Slack messages, GitHub PRs, and CI/CD\n- **Smart output routing**: Results formatted and delivered to the appropriate channel`,\n    },\n    // Step 2: Security Notice (library)\n    'security-notice',\n    // Step 3: Arguments (inline)\n    {\n      inline: true,\n      title: 'Arguments',\n      content: `**Input**: $ARGUMENTS\n\nThe input format determines the trigger source and context extraction strategy.`,\n    },\n    // Step 4: Load Project Context (library)\n    'load-project-context',\n    // Step 5: Knowledge Base Read (library)\n    'read-knowledge-base',\n    // Step 5: Detect Trigger Source (inline)\n    {\n      inline: true,\n      title: 'Detect Trigger Source',\n      content: `Analyze the input format to determine how this task was invoked:\n\n### Identify Trigger Type\n\n**GitHub PR Webhook:**\n- Input contains \\`pull_request\\` object with structure:\n  \\`\\`\\`json\n  {\n    \"pull_request\": {\n      \"number\": 123,\n      \"title\": \"...\",\n      \"body\": \"...\",\n      \"changed_files\": [...],\n      \"base\": { \"ref\": \"main\" },\n      \"head\": { \"ref\": \"feature-branch\" },\n      \"user\": { \"login\": \"...\" }\n    }\n  }\n  \\`\\`\\`\n-> **Trigger detected: GITHUB_PR**\n\n**Slack Event:**\n- Input contains \\`event\\` object with structure:\n  \\`\\`\\`json\n  {\n    \"eventType\": \"com.slack.message\" or \"com.slack.app_mention\",\n    \"event\": {\n      \"type\": \"message\",\n      \"channel\": \"C123456\",\n      \"user\": \"U123456\",\n      \"text\": \"message content\",\n      \"ts\": \"1234567890.123456\",\n      \"thread_ts\": \"...\" (optional)\n    }\n  }\n  \\`\\`\\`\n-> **Trigger detected: SLACK_MESSAGE**\n\n**CI/CD Environment:**\n- Environment variables present:\n  - \\`CI=true\\`\n  - \\`GITHUB_REF\\` (e.g., \"refs/heads/feature-branch\")\n  - \\`GITHUB_SHA\\` (commit hash)\n  - \\`GITHUB_BASE_REF\\` (base branch)\n  - \\`GITHUB_HEAD_REF\\` (head branch)\n- Git context available via bash commands\n-> **Trigger detected: CI_CD**\n\n**Manual Invocation:**\n- Input is natural language, URL, or issue identifier\n- Patterns: \"PR #123\", GitHub URL, \"PROJ-456\", feature description\n-> **Trigger detected: MANUAL**\n\n### Store Trigger Context\n\nStore the detected trigger for use in output routing:\n- Set variable: \\`TRIGGER_SOURCE\\` = [GITHUB_PR | SLACK_MESSAGE | CI_CD | MANUAL]\n- This determines output formatting and delivery channel`,\n    },\n    // Step 6: Extract Context (inline)\n    {\n      inline: true,\n      title: 'Extract Context Based on Trigger',\n      content: `Based on the detected trigger source, extract relevant context:\n\n### GitHub PR Trigger - Extract PR Details\n\nIf trigger is GITHUB_PR:\n- **PR number**: \\`pull_request.number\\`\n- **Title**: \\`pull_request.title\\`\n- **Description**: \\`pull_request.body\\`\n- **Changed files**: \\`pull_request.changed_files\\` (array of file paths)\n- **Author**: \\`pull_request.user.login\\`\n- **Base branch**: \\`pull_request.base.ref\\`\n- **Head branch**: \\`pull_request.head.ref\\`\n\n### Slack Message Trigger - Parse Natural Language\n\nIf trigger is SLACK_MESSAGE:\n- **Message text**: \\`event.text\\`\n- **Channel**: \\`event.channel\\` (for posting results)\n- **User**: \\`event.user\\` (requester)\n- **Thread**: \\`event.thread_ts\\` or \\`event.ts\\` (for threading replies)\n\n**Extract references from text:**\n- PR numbers: \"#123\", \"PR 123\", \"pull request 123\"\n- Issue IDs: \"PROJ-456\", \"BUG-123\"\n- URLs: GitHub PR links, deployment URLs\n- Feature names: Quoted terms, capitalized phrases\n- Environments: \"staging\", \"production\", \"preview\"\n\n### CI/CD Trigger - Read CI Environment\n\nIf trigger is CI_CD:\n- **CI platform**: Read \\`CI\\` env var\n- **Branch**: \\`GITHUB_REF\\` -> extract branch name\n- **Commit**: \\`GITHUB_SHA\\`\n- **Base branch**: \\`GITHUB_BASE_REF\\` (for PRs)\n- **Changed files**: Run \\`git diff --name-only $BASE_SHA...$HEAD_SHA\\`\n\n### Manual Trigger - Parse User Input\n\nIf trigger is MANUAL:\n- **GitHub PR URL**: Parse to extract PR number, then fetch details via API\n- **Issue identifier**: Extract issue ID (patterns: \"PROJ-123\", \"#456\", \"BUG-789\")\n- **Feature description**: Use text as-is for verification context\n- **Deployment URL**: Extract for testing environment\n\n### Unified Context Structure\n\nAfter extraction, create unified context structure:\n\\`\\`\\`\nCHANGE_CONTEXT = {\n  trigger: [GITHUB_PR | SLACK_MESSAGE | CI_CD | MANUAL],\n  title: \"...\",\n  description: \"...\",\n  changedFiles: [\"src/pages/Login.tsx\", ...],\n  author: \"...\",\n  environment: \"staging\" | \"production\" | URL,\n  prNumber: 123 (if available),\n  issueId: \"PROJ-456\" (if available),\n  slackChannel: \"C123456\" (if Slack trigger),\n  slackThread: \"1234567890.123456\" (if Slack trigger),\n  githubRepo: \"owner/repo\" (if GitHub trigger)\n}\n\\`\\`\\``,\n    },\n    // Step 6b: Retrieve Code Change Details (conditional - changelog-historian)\n    {\n      inline: true,\n      title: 'Retrieve Code Change Details',\n      content: `{{INVOKE_CHANGELOG_HISTORIAN}} to gather comprehensive context about recent code changes:\n\nExplore version control history related to the verification scope.\n\nSpecifically gather:\n- Recent changes merged to the target branch\n- Change authors and contributors\n- Scope and impact of each change\n- Change descriptions and rationale\n- Related issues or tickets\n- Files and components affected\n\nThe agent will:\n1. Check its memory for previously discovered repository context\n2. Explore version control for relevant changes\n3. Build comprehensive understanding of the change history\n4. Return synthesized change information\n\nUse this information to:\n- Identify which changes may have caused test failures\n- Understand the scope and risk of the changes\n- Enhance the verification report with change attribution\n- Provide better context for manual verification checklist`,\n      conditionalOnSubagent: 'changelog-historian',\n    },\n    // Step 7: Determine Test Scope (inline)\n    {\n      inline: true,\n      title: 'Determine Test Scope (Smart Selection)',\n      content: `**IMPORTANT**: You do NOT have access to code files. Infer test scope from change **descriptions** only.\n\nBased on PR title, description, and commit messages, intelligently select which tests to run:\n\n### Infer Test Scope from Change Descriptions\n\nAnalyze the change description to identify affected feature areas:\n\n**Example mappings from descriptions to test suites:**\n\n| Description Keywords | Inferred Test Scope | Example |\n|---------------------|-------------------|---------|\n| \"login\", \"authentication\", \"sign in/up\" | \\`tests/specs/auth/\\` | \"Fix login page validation\" -> Auth tests |\n| \"checkout\", \"payment\", \"purchase\" | \\`tests/specs/checkout/\\` | \"Optimize checkout flow\" -> Checkout tests |\n| \"cart\", \"shopping cart\", \"add to cart\" | \\`tests/specs/cart/\\` | \"Update cart calculations\" -> Cart tests |\n| \"API\", \"endpoint\", \"backend\" | API test suites | \"Add new user API endpoint\" -> User API tests |\n| \"profile\", \"account\", \"settings\" | \\`tests/specs/profile/\\` or \\`tests/specs/settings/\\` | \"Profile page redesign\" -> Profile tests |\n\n**Inference strategy:**\n1. **Extract feature keywords** from PR title and description\n2. **Analyze commit messages** for conventional commit scopes\n3. **Map keywords to test organization**\n4. **Identify test scope breadth from description tone**\n\n### Fallback Strategies Based on Description Analysis\n\n**Description patterns that indicate full suite:**\n- \"Refactor shared/common utilities\" (wide impact)\n- \"Update dependencies\" or \"Upgrade framework\" (safety validation)\n- \"Merge main into feature\" or \"Sync with main\" (comprehensive validation)\n- \"Breaking changes\" or \"Major version update\" (thorough testing)\n- \"Database migration\" or \"Schema changes\" (data integrity)\n\n**Description patterns that indicate smoke tests only:**\n- \"Fix typo\" or \"Update copy/text\" (cosmetic change)\n- \"Update README\" or \"Documentation only\" (no functional change)\n- \"Fix formatting\" or \"Linting fixes\" (no logic change)\n\n**When description is vague or ambiguous:**\n- **ACTION REQUIRED**: Use AskUserQuestion tool to clarify test scope\n\n**If specific test scope requested:**\n- User can override with: \"only smoke tests\", \"full suite\", specific test suite names\n- Honor user's explicit scope over smart selection\n\n### Test Selection Summary\n\nGenerate summary of test selection based on description analysis:\n\\`\\`\\`markdown\n### Test Scope Determined\n- **Change description**: [PR title or summary]\n- **Identified keywords**: [list extracted keywords: \"auth\", \"checkout\", etc.]\n- **Affected test suites**: [list inferred test suite paths or names]\n- **Scope reasoning**: [explain why this scope was selected]\n- **Execution strategy**: [smart selection | full suite | smoke tests | user-specified]\n\\`\\`\\``,\n    },\n    // Step 8-11: Test Execution (library steps)\n    'run-playwright-tests',\n    'parse-test-results',\n    'triage-failures',\n    'fix-test-issues',\n    // Step 12: Log Product Bugs (conditional library step)\n    {\n      stepId: 'log-product-bugs',\n      conditionalOnSubagent: 'issue-tracker',\n    },\n    // Step 13: Generate Manual Verification Checklist (inline)\n    {\n      inline: true,\n      title: 'Generate Manual Verification Checklist',\n      content: `Generate human-readable checklist for non-automatable scenarios:\n\n### Analyze Change Context\n\nReview the provided context to understand what changed:\n- Read PR title, description, and commit messages\n- Identify change types from descriptions: visual, UX, forms, mobile, accessibility, edge cases\n- Understand the scope and impact of changes from the change descriptions\n\n### Identify Non-Automatable Scenarios\n\nBased on the change analysis, identify scenarios that require human verification:\n\n**1. Visual Design Changes** (CSS, styling, design files, graphics)\n-> Add **Design Validation** checklist items\n\n**2. UX Interaction Changes** (animations, transitions, gestures, micro-interactions)\n-> Add **UX Feel** checklist items\n\n**3. Form and Input Changes** (new form fields, input validation, user input)\n-> Add **Accessibility** checklist items\n\n**4. Mobile and Responsive Changes** (media queries, touch interactions, viewport)\n-> Add **Mobile Experience** checklist items\n\n**5. Low ROI or Rare Scenarios** (edge cases, one-time migrations, rare user paths)\n-> Add **Exploratory Testing** notes\n\n### Generate Role-Specific Checklist Items\n\nFor each identified scenario, create clear, actionable checklist items:\n\n**Format for each item:**\n- Clear, specific task description\n- Assigned role (@design-team, @qa-team, @a11y-team, @mobile-team)\n- Acceptance criteria (what constitutes pass/fail)\n- Reference to standards when applicable (WCAG, iOS HIG, Material Design)\n- Priority indicator (red circle critical, yellow circle important, green circle nice-to-have)\n\n**Example checklist items:**\n\n**Design Validation (@design-team)**\n- [ ] Login button color matches brand guidelines (#FF6B35)\n- [ ] Loading spinner animation smooth (60fps, no jank)\n\n**Accessibility (@a11y-team)**\n- [ ] Screen reader announces form errors clearly (tested with VoiceOver/NVDA)\n- [ ] Keyboard navigation: Tab through all interactive elements in logical order\n- [ ] Color contrast meets WCAG 2.1 AA (4.5:1 for body text, 3:1 for large text)\n\n**Mobile Experience (@qa-team, @mobile-team)**\n- [ ] Touch targets greater than or equal to 44px (iOS Human Interface Guidelines)\n- [ ] Mobile keyboard doesn't obscure input fields on iOS/Android\n\n### When NO Manual Verification Needed\n\nIf the changes are purely:\n- Backend logic (no UI changes)\n- Code refactoring (no behavior changes)\n- Configuration changes (no user-facing impact)\n- Fully covered by automated tests\n\nOutput:\n\\`\\`\\`markdown\n**Manual Verification:** Not required for this change.\nAll user-facing changes are fully covered by automated tests.\n\\`\\`\\``,\n    },\n    // Step 14: Aggregate Results (inline)\n    {\n      inline: true,\n      title: 'Aggregate Verification Results',\n      content: `Combine automated and manual verification results:\n\n\\`\\`\\`markdown\n## Verification Results Summary\n\n### Automated Tests\n- Total tests: [count]\n- Passed: [count] ([percentage]%)\n- Failed: [count] ([percentage]%)\n- Test issues fixed: [count]\n- Product bugs logged: [count]\n- Duration: [time]\n\n### Manual Verification Required\n[Checklist generated in previous step, or \"Not required\"]\n\n### Overall Recommendation\n[Safe to merge | Review bugs before merging | Do not merge]\n\\`\\`\\``,\n    },\n    // Step 15: Documentation Research (conditional inline)\n    {\n      inline: true,\n      title: 'Understanding the Change (Documentation Research)',\n      content: `{{INVOKE_DOCUMENTATION_RESEARCHER}} to gather comprehensive context about the changed features:\n\nExplore project documentation related to the changes.\n\nSpecifically gather:\n- Product specifications for affected features\n- User stories and acceptance criteria\n- Technical architecture documentation\n- API endpoints and contracts\n- User roles and permissions relevant to the change\n- Business rules and validations\n- UI/UX specifications\n- Known limitations or constraints\n- Related bug reports or known issues\n- Existing test documentation for this area\n\nThe agent will:\n1. Check its memory for previously discovered documentation\n2. Explore workspace for relevant pages and databases\n3. Build comprehensive understanding of the affected features\n4. Return synthesized information to inform testing strategy\n\nUse this information to:\n- Better understand the change context\n- Identify comprehensive test scenarios\n- Recognize integration points and dependencies\n- Spot potential edge cases or risk areas\n- Enhance manual verification checklist generation`,\n      conditionalOnSubagent: 'documentation-researcher',\n    },\n    // Step 16: Report Results (inline)\n    {\n      inline: true,\n      title: 'Report Results (Multi-Channel Output)',\n      content: `Route output based on trigger source:\n\n### MANUAL Trigger -> Terminal Output\n\nFormat as comprehensive markdown report for terminal display with:\n- Change Summary (what changed, scope, affected files)\n- Automated Test Results (statistics, tests fixed, bugs logged)\n- Manual Verification Checklist\n- Recommendation (safe to merge / review / do not merge)\n- Test Artifacts (JSON report, HTML report, traces, screenshots)\n\n### SLACK_MESSAGE Trigger -> Thread Reply\n\n{{INVOKE_TEAM_COMMUNICATOR}} to post concise results to Slack thread with:\n- Verification results summary\n- Critical failures that need immediate attention\n- Bugs logged with issue tracker links\n- Manual verification checklist summary\n- Recommendation and next steps\n- Tag relevant team members for critical issues\n\n### GITHUB_PR Trigger -> PR Comment\n\nUse GitHub API to post comprehensive comment on PR with:\n- Status (All tests passed / Issues found / Critical failures)\n- Automated Tests table (Total, Passed, Failed, Fixed, Bugs, Duration)\n- Failed Tests (triaged and with actions taken)\n- Tests Fixed Automatically (issue, fix, verified)\n- Product Bugs Logged (issue ID, title, test, severity)\n- Manual Verification Required (checklist)\n- Test Artifacts links\n- Recommendation\n\n### CI_CD Trigger -> Build Log + PR Comment\n\nOutput to CI build log (print detailed results to stdout) and exit with appropriate code:\n- Exit 0: All tests passed (safe to merge)\n- Exit 1: Tests failed or critical bugs found (block merge)\n\nPost PR comment if GitHub context available.`,\n      conditionalOnSubagent: 'team-communicator',\n    },\n    // Step 17: Knowledge Base Update (library)\n    'update-knowledge-base',\n    // Step 18: Handle Special Cases (inline)\n    {\n      inline: true,\n      title: 'Handle Special Cases',\n      content: `**If no tests found for changed files:**\n- Inform user: \"No automated tests found for changed files\"\n- Recommend: \"Run smoke test suite for basic validation\"\n- Still generate manual verification checklist\n\n**If all tests skipped:**\n- Explain why (dependencies, environment issues)\n- Recommend: Check test configuration and prerequisites\n\n**If test execution fails:**\n- Report specific error (Playwright not installed, env vars missing)\n- Suggest troubleshooting steps\n- Don't proceed with triage if tests didn't run\n\n## Important Notes\n\n- This task handles **all trigger sources** with a single unified workflow\n- Trigger detection is automatic based on input format\n- Output is automatically routed to the appropriate channel\n- Automated tests are executed with **full triage and automatic fixing**\n- Manual verification checklists are generated for **non-automatable scenarios**\n- Product bugs are logged with **automatic duplicate detection**\n- Test issues are fixed automatically with **verification**\n- Results include both automated and manual verification items\n\n## Success Criteria\n\nA successful verification includes:\n1. Trigger source correctly detected\n2. Context extracted completely\n3. Tests executed (or skipped with explanation)\n4. All failures triaged (product bug vs test issue)\n5. Test issues fixed automatically (when possible)\n6. Product bugs logged to issue tracker\n7. Manual verification checklist generated\n8. Results formatted for output channel\n9. Results delivered to appropriate destination\n10. Clear recommendation provided (merge / review / block)`,\n    },\n  ],\n\n  requiredSubagents: ['test-runner', 'test-debugger-fixer'],\n  optionalSubagents: ['documentation-researcher', 'issue-tracker', 'team-communicator', 'changelog-historian'],\n  dependentTasks: [],\n};\n","/**\n * Onboard Testing Task (Composed)\n * End-to-end workflow: explore → plan → cases → test → fix → report\n * Renamed from full-test-coverage to better reflect its purpose as a setup/onboarding task\n */\n\nimport type { ComposedTaskTemplate } from '../steps/types';\nimport { TASK_SLUGS } from '../constants';\n\nexport const onboardTestingTask: ComposedTaskTemplate = {\n  slug: TASK_SLUGS.ONBOARD_TESTING,\n  name: 'Onboard Testing',\n  description:\n    'Complete workflow: explore application, generate test plan, create test cases, run tests, fix issues, and report results',\n\n  frontmatter: {\n    description: 'Complete test coverage workflow - from exploration to passing tests',\n    'argument-hint': '<focus-area-or-feature-description>',\n  },\n\n  steps: [\n    // Step 1: Overview (inline)\n    {\n      inline: true,\n      title: 'Onboard Testing Overview',\n      content: `## Overview\n\nThis command orchestrates the complete test coverage workflow in a single execution:\n1. **Phase 1**: Read project context and explore application\n2. **Phase 2**: Generate lightweight test plan\n3. **Phase 3**: Generate and verify test cases (create + fix until passing)\n4. **Phase 4**: Triage failures and fix test issues\n5. **Phase 5**: Log product bugs\n6. **Phase 6**: Final report`,\n    },\n    // Step 2: Security Notice (from library)\n    'security-notice',\n    // Step 3: Arguments (inline)\n    {\n      inline: true,\n      title: 'Arguments',\n      content: `Focus area: $ARGUMENTS`,\n    },\n    // Phase 1: Setup\n    'load-project-context',\n    'read-knowledge-base',\n\n    // Phase 2: Exploration Protocol\n    'exploration-protocol',\n\n    // Execute exploration via test-runner\n    'create-exploration-test-case',\n    'run-exploration',\n    'process-exploration-results',\n\n    // Phase 3: Test Plan Generation\n    'generate-test-plan',\n    'extract-env-variables',\n\n    // Phase 4: Test Case Generation\n    'generate-test-cases',\n    'automate-test-cases',\n\n    // Phase 5: Test Execution\n    'run-playwright-tests',\n    'parse-test-results',\n\n    // Phase 6: Triage and Fix (NEW - was missing from full-test-coverage)\n    'triage-failures',\n    'fix-test-issues',\n    {\n      stepId: 'log-product-bugs',\n      conditionalOnSubagent: 'issue-tracker',\n    },\n\n    // Phase 7: Reporting and Communication\n    'update-knowledge-base',\n    {\n      stepId: 'notify-team',\n      conditionalOnSubagent: 'team-communicator',\n    },\n    'generate-final-report',\n  ],\n\n  requiredSubagents: ['test-runner', 'test-code-generator', 'test-debugger-fixer'],\n  optionalSubagents: ['documentation-researcher', 'team-communicator', 'issue-tracker'],\n  dependentTasks: ['run-tests', 'generate-test-cases'],\n};\n","/**\n * Explore Application Task (Composed)\n * Systematically explore application to discover UI elements, workflows, and behaviors\n */\n\nimport type { ComposedTaskTemplate } from '../steps/types';\nimport { TASK_SLUGS } from '../constants';\n\nexport const exploreApplicationTask: ComposedTaskTemplate = {\n  slug: TASK_SLUGS.EXPLORE_APPLICATION,\n  name: 'Explore Application',\n  description: 'Systematically explore application to discover UI elements, workflows, and behaviors',\n\n  frontmatter: {\n    description: 'Explore application to discover UI, workflows, and behaviors',\n    'argument-hint': '--focus [area] --depth [shallow|deep] --system [name]',\n  },\n\n  steps: [\n    // Step 1: Overview (inline)\n    {\n      inline: true,\n      title: 'Explore Application Overview',\n      content: `Discover actual UI elements, workflows, and behaviors using the test-runner agent. Updates test plan and project documentation with findings.`,\n    },\n    // Step 2: Security Notice (from library)\n    'security-notice',\n    // Step 3: Arguments (inline)\n    {\n      inline: true,\n      title: 'Arguments',\n      content: `**Arguments**: $ARGUMENTS\n\n**Parse:**\n- **focus**: auth, navigation, search, content, admin (default: comprehensive)\n- **depth**: shallow (15-20 min) or deep (45-60 min, default)\n- **system**: target system (optional for multi-system setups)`,\n    },\n    // Setup\n    'load-project-context',\n    'read-knowledge-base',\n\n    // Exploration Protocol (adaptive depth)\n    'exploration-protocol',\n\n    // Execute\n    'create-exploration-test-case',\n    'run-exploration',\n    'process-exploration-results',\n\n    // Update\n    'update-exploration-artifacts',\n    // Team Communication (conditional inline)\n    {\n      inline: true,\n      title: 'Team Communication',\n      content: `{{INVOKE_TEAM_COMMUNICATOR}} to notify the product team about exploration findings:\n\n\\`\\`\\`\n1. Post an update about exploration completion\n2. Summarize key discoveries:\n   - UI elements and workflows identified\n   - Behaviors documented\n   - Areas needing further investigation\n3. Share exploration report location\n4. Ask for team feedback on findings\n5. Use appropriate channel and threading\n\\`\\`\\``,\n      conditionalOnSubagent: 'team-communicator',\n    },\n    'cleanup-temp-files',\n    'update-knowledge-base',\n  ],\n\n  requiredSubagents: ['test-runner'],\n  optionalSubagents: ['team-communicator'],\n  dependentTasks: [],\n};\n","/**\n * Tasks Module\n * Central registry and utilities for all task templates\n */\n\n// Export types and constants\nexport * from './types';\nexport * from './constants';\n\n// Import task templates\nimport { generateTestCasesTask } from './library/generate-test-cases';\nimport { generateTestPlanTask } from './library/generate-test-plan';\nimport { handleMessageTask } from './library/handle-message';\nimport { processEventTask } from './library/process-event';\nimport { runTestsTask } from './library/run-tests';\nimport { verifyChangesTask } from './library/verify-changes';\nimport { onboardTestingTask } from './library/onboard-testing';\nimport { exploreApplicationTask } from './library/explore-application';\n\nimport type { ComposedTaskTemplate } from './types';\nimport { TASK_SLUGS } from './constants';\n\n/**\n * Task Templates Registry\n * All tasks use the step-based composition format\n */\nexport const TASK_TEMPLATES: Record<string, ComposedTaskTemplate> = {\n  [TASK_SLUGS.GENERATE_TEST_CASES]: generateTestCasesTask,\n  [TASK_SLUGS.GENERATE_TEST_PLAN]: generateTestPlanTask,\n  [TASK_SLUGS.HANDLE_MESSAGE]: handleMessageTask,\n  [TASK_SLUGS.PROCESS_EVENT]: processEventTask,\n  [TASK_SLUGS.RUN_TESTS]: runTestsTask,\n  [TASK_SLUGS.VERIFY_CHANGES]: verifyChangesTask,\n  [TASK_SLUGS.ONBOARD_TESTING]: onboardTestingTask,\n  [TASK_SLUGS.EXPLORE_APPLICATION]: exploreApplicationTask,\n};\n\n/**\n * Get task template by slug\n */\nexport function getTaskTemplate(slug: string): ComposedTaskTemplate | undefined {\n  return TASK_TEMPLATES[slug];\n}\n\n/**\n * Get all registered task slugs\n */\nexport function getAllTaskSlugs(): string[] {\n  return Object.keys(TASK_TEMPLATES);\n}\n\n/**\n * Check if a task slug is registered\n */\nexport function isTaskRegistered(slug: string): boolean {\n  return TASK_TEMPLATES[slug] !== undefined;\n}\n\n/**\n * Slash Command Configuration for Cloud Run\n * Format expected by cloudrun-claude-code API\n */\nexport interface SlashCommandConfig {\n  frontmatter: Record<string, any>;\n  content: string;\n}\n\n"],"mappings":";AAiNO,SAAS,aAAa,KAAuC;AAClE,SAAO,OAAO,QAAQ,YAAY,YAAY,OAAO,IAAI,WAAW;AACtE;AAKO,SAAS,sBAAsB,KAAgD;AACpF,SAAO,OAAO,QAAQ,YAAY,YAAY;AAChD;;;ACnNO,IAAM,aAAa;AAAA,EACxB,qBAAqB;AAAA,EACrB,iBAAiB;AAAA,EACjB,qBAAqB;AAAA,EACrB,oBAAoB;AAAA,EACpB,gBAAgB;AAAA,EAChB,eAAe;AAAA,EACf,WAAW;AAAA,EACX,gBAAgB;AAAA;AAAA,EAEhB,oBAAoB;AACtB;;;ACVO,IAAM,wBAA8C;AAAA,EACzD,MAAM,WAAW;AAAA,EACjB,MAAM;AAAA,EACN,aAAa;AAAA,EAEb,aAAa;AAAA,IACX,aAAa;AAAA,IACb,iBAAiB;AAAA,EACnB;AAAA,EAEA,OAAO;AAAA;AAAA,IAEL;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAOX;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAMX;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAeX;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,MAYT,uBAAuB;AAAA,IACzB;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAoCX;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAqBX;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IA0DX;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IASX;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,MA8BT,uBAAuB;AAAA,IACzB;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAkCX;AAAA,EACF;AAAA,EAEA,mBAAmB,CAAC,eAAe,qBAAqB;AAAA,EACxD,mBAAmB,CAAC,4BAA4B,mBAAmB;AAAA,EACnE,gBAAgB,CAAC;AACnB;;;ACxTO,IAAM,uBAA6C;AAAA,EACxD,MAAM,WAAW;AAAA,EACjB,MAAM;AAAA,EACN,aAAa;AAAA,EAEb,aAAa;AAAA,IACX,aAAa;AAAA,IACb,iBAAiB;AAAA,EACnB;AAAA,EAEA,OAAO;AAAA;AAAA,IAEL;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA,IACX;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA,IACX;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA,IACX;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA,IACX;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,MAuBT,uBAAuB;AAAA,IACzB;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAOX;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAqBX;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAYX;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA,IACX;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAsCX;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,MAsBT,uBAAuB;AAAA,IACzB;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA,IAKX;AAAA,EACF;AAAA,EAEA,mBAAmB,CAAC,aAAa;AAAA,EACjC,mBAAmB,CAAC,4BAA4B,mBAAmB;AAAA,EACnE,gBAAgB,CAAC;AACnB;;;AC3NO,IAAM,oBAA0C;AAAA,EACrD,MAAM,WAAW;AAAA,EACjB,MAAM;AAAA,EACN,aAAa;AAAA,EAEb,aAAa;AAAA,IACX,aAAa;AAAA,IACb,iBAAiB;AAAA,EACnB;AAAA,EAEA,OAAO;AAAA;AAAA,IAEL;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA,IAGX;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA,IACX;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IA4CX;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAqBX;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAqBX;AAAA,EACF;AAAA,EAEA,mBAAmB,CAAC,mBAAmB;AAAA,EACvC,mBAAmB,CAAC;AAAA,EACpB,gBAAgB,CAAC,gBAAgB;AACnC;;;ACjJO,IAAM,mBAAyC;AAAA,EACpD,MAAM,WAAW;AAAA,EACjB,MAAM;AAAA,EACN,aAAa;AAAA,EAEb,aAAa;AAAA,IACX,aAAa;AAAA,IACb,iBAAiB;AAAA,EACnB;AAAA,EAEA,OAAO;AAAA;AAAA,IAEL;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA,IAGX;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA,IACX;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAYX;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAoFX;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAuDX;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAgCX;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,MAST,uBAAuB;AAAA,IACzB;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAuCX;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,MAmBT,uBAAuB;AAAA,IACzB;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAwCX;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAqBX;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAyBX;AAAA,EACF;AAAA,EAEA,mBAAmB,CAAC,mBAAmB;AAAA,EACvC,mBAAmB,CAAC,4BAA4B,eAAe;AAAA,EAC/D,gBAAgB,CAAC,gBAAgB;AACnC;;;AC1aO,IAAM,eAAqC;AAAA,EAChD,MAAM,WAAW;AAAA,EACjB,MAAM;AAAA,EACN,aAAa;AAAA,EAEb,aAAa;AAAA,IACX,aAAa;AAAA,IACb,iBAAiB;AAAA,EACnB;AAAA,EAEA,OAAO;AAAA;AAAA,IAEL;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA,IAGX;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IASX;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAwCX;AAAA;AAAA,IAEA;AAAA,IACA;AAAA,IACA;AAAA,IACA;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,uBAAuB;AAAA,IACzB;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,uBAAuB;AAAA,IACzB;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IA4CX;AAAA,EACF;AAAA,EAEA,mBAAmB,CAAC,eAAe,qBAAqB;AAAA,EACxD,mBAAmB,CAAC,iBAAiB,mBAAmB;AAAA,EACxD,gBAAgB,CAAC;AACnB;;;AC1JO,IAAM,oBAA0C;AAAA,EACrD,MAAM,WAAW;AAAA,EACjB,MAAM;AAAA,EACN,aAAa;AAAA,EAEb,aAAa;AAAA,IACX,aAAa;AAAA,IACb,iBAAiB;AAAA,EACnB;AAAA,EAEA,OAAO;AAAA;AAAA,IAEL;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IASX;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA,IAGX;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IA0DX;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IA+DX;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,MAuBT,uBAAuB;AAAA,IACzB;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAwDX;AAAA;AAAA,IAEA;AAAA,IACA;AAAA,IACA;AAAA,IACA;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,uBAAuB;AAAA,IACzB;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAmEX;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAmBX;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,MA4BT,uBAAuB;AAAA,IACzB;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,MAwCT,uBAAuB;AAAA,IACzB;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAsCX;AAAA,EACF;AAAA,EAEA,mBAAmB,CAAC,eAAe,qBAAqB;AAAA,EACxD,mBAAmB,CAAC,4BAA4B,iBAAiB,qBAAqB,qBAAqB;AAAA,EAC3G,gBAAgB,CAAC;AACnB;;;AClfO,IAAM,qBAA2C;AAAA,EACtD,MAAM,WAAW;AAAA,EACjB,MAAM;AAAA,EACN,aACE;AAAA,EAEF,aAAa;AAAA,IACX,aAAa;AAAA,IACb,iBAAiB;AAAA,EACnB;AAAA,EAEA,OAAO;AAAA;AAAA,IAEL;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IASX;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA,IACX;AAAA;AAAA,IAEA;AAAA,IACA;AAAA;AAAA,IAGA;AAAA;AAAA,IAGA;AAAA,IACA;AAAA,IACA;AAAA;AAAA,IAGA;AAAA,IACA;AAAA;AAAA,IAGA;AAAA,IACA;AAAA;AAAA,IAGA;AAAA,IACA;AAAA;AAAA,IAGA;AAAA,IACA;AAAA,IACA;AAAA,MACE,QAAQ;AAAA,MACR,uBAAuB;AAAA,IACzB;AAAA;AAAA,IAGA;AAAA,IACA;AAAA,MACE,QAAQ;AAAA,MACR,uBAAuB;AAAA,IACzB;AAAA,IACA;AAAA,EACF;AAAA,EAEA,mBAAmB,CAAC,eAAe,uBAAuB,qBAAqB;AAAA,EAC/E,mBAAmB,CAAC,4BAA4B,qBAAqB,eAAe;AAAA,EACpF,gBAAgB,CAAC,aAAa,qBAAqB;AACrD;;;AC/EO,IAAM,yBAA+C;AAAA,EAC1D,MAAM,WAAW;AAAA,EACjB,MAAM;AAAA,EACN,aAAa;AAAA,EAEb,aAAa;AAAA,IACX,aAAa;AAAA,IACb,iBAAiB;AAAA,EACnB;AAAA,EAEA,OAAO;AAAA;AAAA,IAEL;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA,IACX;AAAA;AAAA,IAEA;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAMX;AAAA;AAAA,IAEA;AAAA,IACA;AAAA;AAAA,IAGA;AAAA;AAAA,IAGA;AAAA,IACA;AAAA,IACA;AAAA;AAAA,IAGA;AAAA;AAAA,IAEA;AAAA,MACE,QAAQ;AAAA,MACR,OAAO;AAAA,MACP,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,MAYT,uBAAuB;AAAA,IACzB;AAAA,IACA;AAAA,IACA;AAAA,EACF;AAAA,EAEA,mBAAmB,CAAC,aAAa;AAAA,EACjC,mBAAmB,CAAC,mBAAmB;AAAA,EACvC,gBAAgB,CAAC;AACnB;;;ACnDO,IAAM,iBAAuD;AAAA,EAClE,CAAC,WAAW,mBAAmB,GAAG;AAAA,EAClC,CAAC,WAAW,kBAAkB,GAAG;AAAA,EACjC,CAAC,WAAW,cAAc,GAAG;AAAA,EAC7B,CAAC,WAAW,aAAa,GAAG;AAAA,EAC5B,CAAC,WAAW,SAAS,GAAG;AAAA,EACxB,CAAC,WAAW,cAAc,GAAG;AAAA,EAC7B,CAAC,WAAW,eAAe,GAAG;AAAA,EAC9B,CAAC,WAAW,mBAAmB,GAAG;AACpC;AAKO,SAAS,gBAAgB,MAAgD;AAC9E,SAAO,eAAe,IAAI;AAC5B;AAKO,SAAS,kBAA4B;AAC1C,SAAO,OAAO,KAAK,cAAc;AACnC;AAKO,SAAS,iBAAiB,MAAuB;AACtD,SAAO,eAAe,IAAI,MAAM;AAClC;","names":[]}

package/dist/templates/init/.bugzy/runtime/knowledge-base.md

@@ -0,0 +1,61 @@
+# Knowledge Base
+
+> A curated collection of factual knowledge about this project - what we currently know and believe to be true. This is NOT a historical log, but a living reference that evolves as understanding improves.
+
+**Maintenance Guide**: See `knowledge-maintenance-guide.md` for instructions on how to maintain this knowledge base.
+
+**Core Principle**: This document represents current understanding, not a history. When knowledge evolves, update existing entries rather than appending new ones.
+
+---
+
+## Project Knowledge
+
+_This knowledge base will be populated as you work. Add new discoveries, update existing understanding, and remove outdated information following the maintenance guide principles._
+
+### When to Update This File
+
+- **ADD**: New factual information discovered, new patterns emerge, new areas become relevant
+- **UPDATE**: Facts change, understanding deepens, multiple facts can be consolidated, language can be clarified
+- **REMOVE**: Information becomes irrelevant, facts proven incorrect, entries superseded by better content
+
+### Format Guidelines
+
+- Use clear, declarative statements in present tense
+- State facts confidently when known; flag uncertainty when it exists
+- Write for someone reading this 6 months from now
+- Keep entries relevant and actionable
+- Favor consolidation over accumulation
+
+---
+
+## Example Structure
+
+Below is an example structure. Feel free to organize knowledge in the way that makes most sense for this project:
+
+### Architecture & Infrastructure
+
+_System architecture, deployment patterns, infrastructure details_
+
+### Testing Patterns
+
+_Test strategies, common test scenarios, testing conventions_
+
+### UI/UX Patterns
+
+_User interface conventions, interaction patterns, design system details_
+
+### Data & APIs
+
+_Data models, API behaviors, integration patterns_
+
+### Known Issues & Workarounds
+
+_Current limitations, known bugs, and their workarounds_
+
+### Domain Knowledge
+
+_Business domain facts, terminology, rules, and context_
+
+---
+
+**Remember**: Every entry should answer "Will this help someone working on this project in 6 months?"