qaa-agent 1.6.3 → 1.7.1

package/{.claude/skills → skills}/qa-bug-detective/SKILL.md

@@ -1,122 +1,122 @@
----
-name: qa-bug-detective
-description: QA Bug Detective. Runs generated tests and classifies failures as APPLICATION BUG, TEST CODE ERROR, ENVIRONMENT ISSUE, or INCONCLUSIVE with evidence and confidence levels. Use when user wants to run tests and classify results, investigate test failures, determine if failures are bugs or test issues, debug failing tests, triage test results, or understand why tests are failing. Triggers on "run tests", "classify failures", "why is this failing", "test failures", "debug tests", "triage results", "is this a bug or test error", "investigate failures".
----
-
-# QA Bug Detective
-
-## Purpose
-
-Run generated tests and classify every failure into one of four categories with evidence and confidence levels. Auto-fix TEST CODE ERRORS when confidence is HIGH.
-
-## Classification Decision Tree
-
-```
-Test fails
-├── Syntax/import error in TEST file?
-│   └── YES → TEST CODE ERROR
-├── Error occurs in PRODUCTION code path?
-│   ├── Known bug / unexpected behavior? → APPLICATION BUG
-│   └── Code works as designed but test expectation wrong? → TEST CODE ERROR
-├── Connection refused / timeout / missing env var?
-│   └── YES → ENVIRONMENT ISSUE
-└── Can't determine?
-    └── INCONCLUSIVE
-```
-
-## Classification Categories
-
-### APPLICATION BUG
-- Error manifests in production code (not test code)
-- Stack trace points to src/ or app/ code
-- Behavior contradicts documented requirements or API contracts
-- **Action**: Report only. NEVER auto-fix application code.
-
-### TEST CODE ERROR
-- Import/require fails (wrong path, missing module)
-- Selector doesn't match current DOM
-- Assertion expects wrong value (test written incorrectly)
-- Missing await, wrong API usage, stale fixture reference
-- **Action**: Auto-fix if HIGH confidence. Report if MEDIUM or lower.
-
-### ENVIRONMENT ISSUE
-- Connection refused (database, API, external service)
-- Timeout waiting for resource
-- Missing environment variable
-- File/directory not found (test infrastructure)
-- **Action**: Report with suggested resolution steps.
-
-### INCONCLUSIVE
-- Error is ambiguous
-- Could be multiple root causes
-- Insufficient data to classify
-- **Action**: Report with what's known, request more info.
-
-## Evidence Requirements
-
-Every classification MUST include:
-1. **File path**: Exact file where error occurs
-2. **Line number**: Specific line of failure
-3. **Error message**: Complete error text
-4. **Code snippet**: The specific code proving the classification
-5. **Confidence level**: HIGH / MEDIUM-HIGH / MEDIUM / LOW
-6. **Reasoning**: Why this classification, not another
-
-## Confidence Levels
-
-| Level | Definition |
-|-------|------------|
-| HIGH | Clear evidence in one direction, no ambiguity |
-| MEDIUM-HIGH | Strong evidence but minor ambiguity |
-| MEDIUM | Evidence points one way but alternatives exist |
-| LOW | Insufficient data, multiple possible causes |
-
-## Auto-Fix Rules
-
-Only auto-fix when:
-- Classification = TEST CODE ERROR
-- Confidence = HIGH
-- Fix is mechanical (import path, selector, assertion value, config)
-
-Fix types:
-- Import path corrections
-- Selector updates (match current DOM/data-testid)
-- Assertion value updates (match current actual behavior)
-- Config fixes (baseURL, timeout values)
-- Missing await keywords
-- Fixture path corrections
-
-**NEVER auto-fix**: Application bugs, environment issues, anything with confidence < HIGH.
-
-## Output: FAILURE_CLASSIFICATION_REPORT.md
-
-```markdown
-# Failure Classification Report
-
-## Summary
-| Classification | Count | Auto-Fixed | Needs Attention |
-|---------------|-------|-----------|----------------|
-| APPLICATION BUG | N | 0 | N |
-| TEST CODE ERROR | N | N | N |
-| ENVIRONMENT ISSUE | N | 0 | N |
-| INCONCLUSIVE | N | 0 | N |
-
-## Detailed Analysis
-
-### Failure 1: [test name]
-- **Classification**: [category]
-- **Confidence**: [level]
-- **File**: [path]:[line]
-- **Error**: [message]
-- **Evidence**: [code snippet + reasoning]
-- **Action Taken**: [auto-fixed / reported]
-- **Resolution**: [what was fixed / what needs human attention]
-```
-
-## Quality Gate
-
-- [ ] Every failure classified with evidence
-- [ ] Confidence level assigned to each
-- [ ] No application bugs auto-fixed
-- [ ] Auto-fixes only applied at HIGH confidence
-- [ ] FAILURE_CLASSIFICATION_REPORT.md produced
+---
+name: qa-bug-detective
+description: QA Bug Detective. Runs generated tests and classifies failures as APPLICATION BUG, TEST CODE ERROR, ENVIRONMENT ISSUE, or INCONCLUSIVE with evidence and confidence levels. Use when user wants to run tests and classify results, investigate test failures, determine if failures are bugs or test issues, debug failing tests, triage test results, or understand why tests are failing. Triggers on "run tests", "classify failures", "why is this failing", "test failures", "debug tests", "triage results", "is this a bug or test error", "investigate failures".
+---
+
+# QA Bug Detective
+
+## Purpose
+
+Run generated tests and classify every failure into one of four categories with evidence and confidence levels. Auto-fix TEST CODE ERRORS when confidence is HIGH.
+
+## Classification Decision Tree
+
+```
+Test fails
+├── Syntax/import error in TEST file?
+│   └── YES → TEST CODE ERROR
+├── Error occurs in PRODUCTION code path?
+│   ├── Known bug / unexpected behavior? → APPLICATION BUG
+│   └── Code works as designed but test expectation wrong? → TEST CODE ERROR
+├── Connection refused / timeout / missing env var?
+│   └── YES → ENVIRONMENT ISSUE
+└── Can't determine?
+    └── INCONCLUSIVE
+```
+
+## Classification Categories
+
+### APPLICATION BUG
+- Error manifests in production code (not test code)
+- Stack trace points to src/ or app/ code
+- Behavior contradicts documented requirements or API contracts
+- **Action**: Report only. NEVER auto-fix application code.
+
+### TEST CODE ERROR
+- Import/require fails (wrong path, missing module)
+- Selector doesn't match current DOM
+- Assertion expects wrong value (test written incorrectly)
+- Missing await, wrong API usage, stale fixture reference
+- **Action**: Auto-fix if HIGH confidence. Report if MEDIUM or lower.
+
+### ENVIRONMENT ISSUE
+- Connection refused (database, API, external service)
+- Timeout waiting for resource
+- Missing environment variable
+- File/directory not found (test infrastructure)
+- **Action**: Report with suggested resolution steps.
+
+### INCONCLUSIVE
+- Error is ambiguous
+- Could be multiple root causes
+- Insufficient data to classify
+- **Action**: Report with what's known, request more info.
+
+## Evidence Requirements
+
+Every classification MUST include:
+1. **File path**: Exact file where error occurs
+2. **Line number**: Specific line of failure
+3. **Error message**: Complete error text
+4. **Code snippet**: The specific code proving the classification
+5. **Confidence level**: HIGH / MEDIUM-HIGH / MEDIUM / LOW
+6. **Reasoning**: Why this classification, not another
+
+## Confidence Levels
+
+| Level | Definition |
+|-------|------------|
+| HIGH | Clear evidence in one direction, no ambiguity |
+| MEDIUM-HIGH | Strong evidence but minor ambiguity |
+| MEDIUM | Evidence points one way but alternatives exist |
+| LOW | Insufficient data, multiple possible causes |
+
+## Auto-Fix Rules
+
+Only auto-fix when:
+- Classification = TEST CODE ERROR
+- Confidence = HIGH
+- Fix is mechanical (import path, selector, assertion value, config)
+
+Fix types:
+- Import path corrections
+- Selector updates (match current DOM/data-testid)
+- Assertion value updates (match current actual behavior)
+- Config fixes (baseURL, timeout values)
+- Missing await keywords
+- Fixture path corrections
+
+**NEVER auto-fix**: Application bugs, environment issues, anything with confidence < HIGH.
+
+## Output: FAILURE_CLASSIFICATION_REPORT.md
+
+```markdown
+# Failure Classification Report
+
+## Summary
+| Classification | Count | Auto-Fixed | Needs Attention |
+|---------------|-------|-----------|----------------|
+| APPLICATION BUG | N | 0 | N |
+| TEST CODE ERROR | N | N | N |
+| ENVIRONMENT ISSUE | N | 0 | N |
+| INCONCLUSIVE | N | 0 | N |
+
+## Detailed Analysis
+
+### Failure 1: [test name]
+- **Classification**: [category]
+- **Confidence**: [level]
+- **File**: [path]:[line]
+- **Error**: [message]
+- **Evidence**: [code snippet + reasoning]
+- **Action Taken**: [auto-fixed / reported]
+- **Resolution**: [what was fixed / what needs human attention]
+```
+
+## Quality Gate
+
+- [ ] Every failure classified with evidence
+- [ ] Confidence level assigned to each
+- [ ] No application bugs auto-fixed
+- [ ] Auto-fixes only applied at HIGH confidence
+- [ ] FAILURE_CLASSIFICATION_REPORT.md produced

package/{.claude/skills → skills}/qa-repo-analyzer/SKILL.md

@@ -1,88 +1,88 @@
----
-name: qa-repo-analyzer
-description: QA Repository Analyzer. Analyzes a dev repository and produces a complete QA baseline package including testability report, test inventory, and repo blueprint. Use when user wants to analyze a repo for testing, assess testability, generate test inventory, create QA baseline, understand test coverage needs, evaluate a codebase for QA, or produce a testing strategy. Triggers on "analyze repo", "testability report", "test inventory", "QA analysis", "QA baseline", "coverage assessment", "what should we test", "testing strategy".
----
-
-# QA Repository Analyzer
-
-## Purpose
-
-Analyze a developer repository and produce a complete QA baseline package: Testability Report, Test Inventory (pyramid-based), and QA Repo Blueprint.
-
-## Core Rule
-
-**Every analysis must be specific to the actual codebase — never generic advice. Every test case must have an explicit expected outcome.**
-
-## Execution Steps
-
-### Step 0: Collect Repo Context
-
-Scan the repository systematically:
-- Folder tree (entry points, structure)
-- Package files (dependencies, scripts, framework detection)
-- Service/controller files (API surface area)
-- Model files (data structures, validation)
-- Database layer (ORM, migrations, schemas)
-- External integrations (payment, email, storage, queues)
-- Existing test coverage (test files, config, CI)
-- Configuration (env vars, feature flags)
-
-### Step 1: Pre-Analysis — Assumptions & Questions
-
-Before generating deliverables, list:
-- **Assumptions**: What you're inferring from the code (e.g., "Auth uses JWT based on middleware")
-- **Questions**: What's ambiguous (e.g., "Is the Stripe integration in production or test mode?")
-
-Present to user for confirmation before proceeding.
-
-### Step 2: Deliverable A — QA_ANALYSIS.md (Testability Report)
-
-Produce with ALL these sections:
-- **Architecture Overview**: System type, language, runtime, entry points table, internal layers
-- **External Dependencies**: Table with purpose and risk level (HIGH/MEDIUM/LOW)
-- **Risk Assessment**: Prioritized risks with justification
-- **Top 10 Unit Test Targets**: Table with module/function, why it's high-priority, complexity assessment
-- **API/Contract Test Targets**: Endpoints that need contract testing
-- **Recommended Testing Pyramid**: Percentages adjusted to this specific app's architecture
-
-### Step 3: Deliverable B — TEST_INVENTORY.md (Test Cases)
-
-Generate pyramid-based test inventory:
-
-**Unit Tests** (60-70%): For each target:
-- Test ID (UT-MODULE-NNN)
-- Target (file path + function)
-- What to validate
-- Concrete inputs
-- Mocks needed
-- Explicit expected outcome
-
-**Integration/Contract Tests** (10-15%): Component interactions, API contracts
-
-**API Tests** (20-25%): For each endpoint:
-- Test ID (API-RESOURCE-NNN)
-- Method + endpoint
-- Request body/params
-- Expected status + response shape
-
-**E2E Smoke Tests** (3-5%): Max 3-8 critical user paths
-
-### Step 4: QA_REPO_BLUEPRINT.md
-
-If no QA repo exists, generate:
-- Suggested repo name and folder structure
-- Recommended stack (framework, runner, reporter)
-- Config files needed
-- Execution scripts (npm scripts, CI commands)
-- CI/CD strategy (smoke on PR, regression nightly)
-- Definition of Done checklist
-
-## Quality Gate
-
-- [ ] Architecture overview matches actual codebase (not generic)
-- [ ] Every test case has explicit expected outcome with concrete values
-- [ ] No vague assertions ("works correctly", "returns proper data")
-- [ ] Test IDs follow naming convention
-- [ ] Priority (P0/P1/P2) assigned to every test case
-- [ ] Risks are specific with evidence from the code
-- [ ] Testing pyramid percentages are justified for this architecture
+---
+name: qa-repo-analyzer
+description: QA Repository Analyzer. Analyzes a dev repository and produces a complete QA baseline package including testability report, test inventory, and repo blueprint. Use when user wants to analyze a repo for testing, assess testability, generate test inventory, create QA baseline, understand test coverage needs, evaluate a codebase for QA, or produce a testing strategy. Triggers on "analyze repo", "testability report", "test inventory", "QA analysis", "QA baseline", "coverage assessment", "what should we test", "testing strategy".
+---
+
+# QA Repository Analyzer
+
+## Purpose
+
+Analyze a developer repository and produce a complete QA baseline package: Testability Report, Test Inventory (pyramid-based), and QA Repo Blueprint.
+
+## Core Rule
+
+**Every analysis must be specific to the actual codebase — never generic advice. Every test case must have an explicit expected outcome.**
+
+## Execution Steps
+
+### Step 0: Collect Repo Context
+
+Scan the repository systematically:
+- Folder tree (entry points, structure)
+- Package files (dependencies, scripts, framework detection)
+- Service/controller files (API surface area)
+- Model files (data structures, validation)
+- Database layer (ORM, migrations, schemas)
+- External integrations (payment, email, storage, queues)
+- Existing test coverage (test files, config, CI)
+- Configuration (env vars, feature flags)
+
+### Step 1: Pre-Analysis — Assumptions & Questions
+
+Before generating deliverables, list:
+- **Assumptions**: What you're inferring from the code (e.g., "Auth uses JWT based on middleware")
+- **Questions**: What's ambiguous (e.g., "Is the Stripe integration in production or test mode?")
+
+Present to user for confirmation before proceeding.
+
+### Step 2: Deliverable A — QA_ANALYSIS.md (Testability Report)
+
+Produce with ALL these sections:
+- **Architecture Overview**: System type, language, runtime, entry points table, internal layers
+- **External Dependencies**: Table with purpose and risk level (HIGH/MEDIUM/LOW)
+- **Risk Assessment**: Prioritized risks with justification
+- **Top 10 Unit Test Targets**: Table with module/function, why it's high-priority, complexity assessment
+- **API/Contract Test Targets**: Endpoints that need contract testing
+- **Recommended Testing Pyramid**: Percentages adjusted to this specific app's architecture
+
+### Step 3: Deliverable B — TEST_INVENTORY.md (Test Cases)
+
+Generate pyramid-based test inventory:
+
+**Unit Tests** (60-70%): For each target:
+- Test ID (UT-MODULE-NNN)
+- Target (file path + function)
+- What to validate
+- Concrete inputs
+- Mocks needed
+- Explicit expected outcome
+
+**Integration/Contract Tests** (10-15%): Component interactions, API contracts
+
+**API Tests** (20-25%): For each endpoint:
+- Test ID (API-RESOURCE-NNN)
+- Method + endpoint
+- Request body/params
+- Expected status + response shape
+
+**E2E Smoke Tests** (3-5%): Max 3-8 critical user paths
+
+### Step 4: QA_REPO_BLUEPRINT.md
+
+If no QA repo exists, generate:
+- Suggested repo name and folder structure
+- Recommended stack (framework, runner, reporter)
+- Config files needed
+- Execution scripts (npm scripts, CI commands)
+- CI/CD strategy (smoke on PR, regression nightly)
+- Definition of Done checklist
+
+## Quality Gate
+
+- [ ] Architecture overview matches actual codebase (not generic)
+- [ ] Every test case has explicit expected outcome with concrete values
+- [ ] No vague assertions ("works correctly", "returns proper data")
+- [ ] Test IDs follow naming convention
+- [ ] Priority (P0/P1/P2) assigned to every test case
+- [ ] Risks are specific with evidence from the code
+- [ ] Testing pyramid percentages are justified for this architecture

package/{.claude/skills → skills}/qa-self-validator/SKILL.md

@@ -1,109 +1,109 @@
----
-name: qa-self-validator
-description: QA Self Validator. Closed-loop agent that validates generated test code across 4 layers (syntax, structure, dependencies, logic) and auto-fixes issues. Use when user wants to validate tests, check test quality, verify test code compiles, ensure tests follow standards, run quality checks on test suite, or verify generated tests before delivery. Triggers on "validate tests", "check test quality", "verify tests", "test validation", "quality check", "does it compile", "are tests valid", "check my tests".
----
-
-# QA Self Validator
-
-## Purpose
-
-Closed-loop validation agent: Generate -> Validate -> Fix -> Deliver. Never deliver test code without at least one validation pass.
-
-## Core Rule
-
-**NEVER deliver generated QA code without running at least one validation pass. Max 3 fix loops before escalating.**
-
-## Validation Layers
-
-### Layer 1: Syntax
-Run the appropriate checker based on language:
-- TypeScript: `tsc --noEmit`
-- JavaScript: `node --check [file]`
-- Python: `python -m py_compile [file]`
-- C#: `dotnet build --no-restore`
-- Also run project linter if configured (eslint, flake8, etc.)
-
-**Pass criteria**: Zero syntax errors.
-
-### Layer 2: Structure
-Check each test file for:
-- Correct directory placement (e2e in e2e/, unit in unit/, etc.)
-- Naming convention compliance (CLAUDE.md patterns)
-- Has actual test functions (not empty describe blocks)
-- Imports reference real modules in the codebase
-- No hardcoded secrets/credentials/tokens
-- Page objects in pages/ directory, tests in tests/
-
-**Pass criteria**: All structural checks pass.
-
-### Layer 3: Dependencies
-Verify:
-- All imports resolvable (modules exist at the referenced paths)
-- Packages listed in package.json/requirements.txt
-- No missing dependencies
-- No circular dependencies in test helpers
-- Test fixtures reference existing fixture files
-
-**Pass criteria**: All imports resolve, all packages available.
-
-### Layer 4: Logic Quality
-Check test logic:
-- Happy path tests have positive assertions (toBe, toEqual, toHaveText)
-- Error/negative tests have negative assertions (not.toBe, toThrow, status >= 400)
-- Setup and teardown are symmetric (what's created is cleaned up)
-- No duplicate test IDs across the suite
-- Assertions are concrete — reject: toBeTruthy(), toBeDefined(), .should('exist')
-- Each test has at least one assertion
-
-**Pass criteria**: All logic checks pass.
-
-## Fix Loop Protocol
-
-```
-Loop 1: Generate tests
-     -> Run all 4 validation layers
-     -> If PASS: Deliver
-     -> If FAIL: Identify issues, fix, continue
-
-Loop 2: Re-validate after fixes
-     -> If PASS: Deliver
-     -> If FAIL: Identify remaining issues, fix
-
-Loop 3: Final validation
-     -> If PASS: Deliver
-     -> If FAIL: Deliver with VALIDATION_REPORT noting unresolved issues
-```
-
-## Output: VALIDATION_REPORT.md
-
-```markdown
-# Validation Report
-
-## Summary
-| Layer | Status | Issues Found | Issues Fixed |
-|-------|--------|-------------|-------------|
-| Syntax | PASS/FAIL | N | N |
-| Structure | PASS/FAIL | N | N |
-| Dependencies | PASS/FAIL | N | N |
-| Logic | PASS/FAIL | N | N |
-
-## File Details
-### [filename]
-| Layer | Status | Details |
-|-------|--------|---------|
-| ... | ... | ... |
-
-## Unresolved Issues
-[Any issues that couldn't be auto-fixed after 3 loops]
-
-## Confidence Level
-[HIGH/MEDIUM/LOW with reasoning]
-```
-
-## Quality Gate
-
-- [ ] All 4 layers checked for every file
-- [ ] Fix loop executed (max 3 iterations)
-- [ ] VALIDATION_REPORT.md produced
-- [ ] No test delivered with syntax errors
-- [ ] Unresolved issues clearly documented
+---
+name: qa-self-validator
+description: QA Self Validator. Closed-loop agent that validates generated test code across 4 layers (syntax, structure, dependencies, logic) and auto-fixes issues. Use when user wants to validate tests, check test quality, verify test code compiles, ensure tests follow standards, run quality checks on test suite, or verify generated tests before delivery. Triggers on "validate tests", "check test quality", "verify tests", "test validation", "quality check", "does it compile", "are tests valid", "check my tests".
+---
+
+# QA Self Validator
+
+## Purpose
+
+Closed-loop validation agent: Generate -> Validate -> Fix -> Deliver. Never deliver test code without at least one validation pass.
+
+## Core Rule
+
+**NEVER deliver generated QA code without running at least one validation pass. Max 3 fix loops before escalating.**
+
+## Validation Layers
+
+### Layer 1: Syntax
+Run the appropriate checker based on language:
+- TypeScript: `tsc --noEmit`
+- JavaScript: `node --check [file]`
+- Python: `python -m py_compile [file]`
+- C#: `dotnet build --no-restore`
+- Also run project linter if configured (eslint, flake8, etc.)
+
+**Pass criteria**: Zero syntax errors.
+
+### Layer 2: Structure
+Check each test file for:
+- Correct directory placement (e2e in e2e/, unit in unit/, etc.)
+- Naming convention compliance (CLAUDE.md patterns)
+- Has actual test functions (not empty describe blocks)
+- Imports reference real modules in the codebase
+- No hardcoded secrets/credentials/tokens
+- Page objects in pages/ directory, tests in tests/
+
+**Pass criteria**: All structural checks pass.
+
+### Layer 3: Dependencies
+Verify:
+- All imports resolvable (modules exist at the referenced paths)
+- Packages listed in package.json/requirements.txt
+- No missing dependencies
+- No circular dependencies in test helpers
+- Test fixtures reference existing fixture files
+
+**Pass criteria**: All imports resolve, all packages available.
+
+### Layer 4: Logic Quality
+Check test logic:
+- Happy path tests have positive assertions (toBe, toEqual, toHaveText)
+- Error/negative tests have negative assertions (not.toBe, toThrow, status >= 400)
+- Setup and teardown are symmetric (what's created is cleaned up)
+- No duplicate test IDs across the suite
+- Assertions are concrete — reject: toBeTruthy(), toBeDefined(), .should('exist')
+- Each test has at least one assertion
+
+**Pass criteria**: All logic checks pass.
+
+## Fix Loop Protocol
+
+```
+Loop 1: Generate tests
+     -> Run all 4 validation layers
+     -> If PASS: Deliver
+     -> If FAIL: Identify issues, fix, continue
+
+Loop 2: Re-validate after fixes
+     -> If PASS: Deliver
+     -> If FAIL: Identify remaining issues, fix
+
+Loop 3: Final validation
+     -> If PASS: Deliver
+     -> If FAIL: Deliver with VALIDATION_REPORT noting unresolved issues
+```
+
+## Output: VALIDATION_REPORT.md
+
+```markdown
+# Validation Report
+
+## Summary
+| Layer | Status | Issues Found | Issues Fixed |
+|-------|--------|-------------|-------------|
+| Syntax | PASS/FAIL | N | N |
+| Structure | PASS/FAIL | N | N |
+| Dependencies | PASS/FAIL | N | N |
+| Logic | PASS/FAIL | N | N |
+
+## File Details
+### [filename]
+| Layer | Status | Details |
+|-------|--------|---------|
+| ... | ... | ... |
+
+## Unresolved Issues
+[Any issues that couldn't be auto-fixed after 3 loops]
+
+## Confidence Level
+[HIGH/MEDIUM/LOW with reasoning]
+```
+
+## Quality Gate
+
+- [ ] All 4 layers checked for every file
+- [ ] Fix loop executed (max 3 iterations)
+- [ ] VALIDATION_REPORT.md produced
+- [ ] No test delivered with syntax errors
+- [ ] Unresolved issues clearly documented