qaa-agent 1.6.2 → 1.6.3

package/.claude/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

package/.claude/skills/qa-template-engine/SKILL.md

@@ -1,113 +1,113 @@
----
-name: qa-template-engine
-description: QA Template Engine. Creates production-ready test files with POM pattern, explicit assertions, and proper structure. Use when user wants to generate test files, create test templates, write test code, scaffold test suites, produce executable tests, or create test specs from an inventory. Triggers on "generate tests", "create test files", "write tests", "scaffold tests", "test templates", "produce test code", "executable tests", "create test spec".
----
-
-# QA Template Engine
-
-## Purpose
-
-Create definitive, production-ready test files with explicit expected outcomes, proper POM architecture, and framework-specific best practices.
-
-## Core Rule
-
-**NO test case is complete without an expected outcome that a junior QA engineer could verify without asking questions.**
-
-## Framework Detection
-
-Before generating ANY code:
-1. Check for existing config: playwright.config.ts, cypress.config.ts, jest.config.ts, vitest.config.ts, pytest.ini
-2. Check package.json/requirements.txt for test dependencies
-3. Check existing test files for patterns and conventions
-4. **Always match the project's existing framework**
-
-If no framework exists, ask the user.
-
-## Test Template Categories
-
-### Unit Test Template
-```
-Test ID: UT-[MODULE]-[NNN]
-Target: [file]:[function]
-Priority: P[0-2]
-
-// Arrange
-const input = [concrete value];
-const expected = [concrete value];
-
-// Act
-const result = functionUnderTest(input);
-
-// Assert
-expect(result).toBe(expected); // NEVER toBeTruthy/toBeDefined
-```
-
-### API Test Template
-```
-Test ID: API-[RESOURCE]-[NNN]
-Target: [METHOD] [endpoint]
-Priority: P[0-2]
-
-// Arrange
-const payload = { [concrete data] };
-
-// Act
-const response = await api.[method]('[endpoint]', payload);
-
-// Assert
-expect(response.status).toBe([exact code]);
-expect(response.body.[field]).toBe('[exact value]');
-```
-
-### E2E Test Template (Playwright)
-```
-Test ID: E2E-[FLOW]-[NNN]
-Target: [user flow description]
-Priority: P[0-2]
-
-// Arrange
-await loginPage.navigate();
-
-// Act
-await loginPage.login('[email]', '[password]');
-
-// Assert
-await expect(dashboardPage.welcomeMessage).toHaveText('Welcome, Test User');
-```
-
-## POM Generation Rules
-
-Following CLAUDE.md strictly:
-1. One class per page — no god objects
-2. No assertions in page objects — assertions in test specs ONLY
-3. Locators as readonly properties — Tier 1 preferred (data-testid, ARIA roles)
-4. Actions return void or next page
-5. State queries return data
-6. Every POM extends BasePage
-
-## Locator Priority
-
-Always use this order:
-1. data-testid: `page.getByTestId('login-submit-btn')`
-2. ARIA role: `page.getByRole('button', { name: 'Log in' })`
-3. Label/placeholder: `page.getByLabel('Email')`
-4. CSS selector: `page.locator('.btn')` + `// TODO: Request test ID`
-
-## Expected Outcome Rules
-
-- **Be specific**: Exact values, status codes, text content
-- **Be measurable**: Timing thresholds, counts, lengths
-- **Be negative too**: What should NOT happen
-- **Include state transitions**: Before/after states
-- **Reference test data**: Use fixture values, not magic strings
-
-## Quality Gate
-
-- [ ] Every test has explicit expected outcome with concrete value
-- [ ] No vague words: "correct", "proper", "appropriate", "works"
-- [ ] All locators follow tier hierarchy
-- [ ] No assertions inside page objects
-- [ ] No hardcoded credentials
-- [ ] File naming follows project conventions
-- [ ] Test IDs are unique and follow convention
-- [ ] Priority (P0/P1/P2) assigned to every test
+---
+name: qa-template-engine
+description: QA Template Engine. Creates production-ready test files with POM pattern, explicit assertions, and proper structure. Use when user wants to generate test files, create test templates, write test code, scaffold test suites, produce executable tests, or create test specs from an inventory. Triggers on "generate tests", "create test files", "write tests", "scaffold tests", "test templates", "produce test code", "executable tests", "create test spec".
+---
+
+# QA Template Engine
+
+## Purpose
+
+Create definitive, production-ready test files with explicit expected outcomes, proper POM architecture, and framework-specific best practices.
+
+## Core Rule
+
+**NO test case is complete without an expected outcome that a junior QA engineer could verify without asking questions.**
+
+## Framework Detection
+
+Before generating ANY code:
+1. Check for existing config: playwright.config.ts, cypress.config.ts, jest.config.ts, vitest.config.ts, pytest.ini
+2. Check package.json/requirements.txt for test dependencies
+3. Check existing test files for patterns and conventions
+4. **Always match the project's existing framework**
+
+If no framework exists, ask the user.
+
+## Test Template Categories
+
+### Unit Test Template
+```
+Test ID: UT-[MODULE]-[NNN]
+Target: [file]:[function]
+Priority: P[0-2]
+
+// Arrange
+const input = [concrete value];
+const expected = [concrete value];
+
+// Act
+const result = functionUnderTest(input);
+
+// Assert
+expect(result).toBe(expected); // NEVER toBeTruthy/toBeDefined
+```
+
+### API Test Template
+```
+Test ID: API-[RESOURCE]-[NNN]
+Target: [METHOD] [endpoint]
+Priority: P[0-2]
+
+// Arrange
+const payload = { [concrete data] };
+
+// Act
+const response = await api.[method]('[endpoint]', payload);
+
+// Assert
+expect(response.status).toBe([exact code]);
+expect(response.body.[field]).toBe('[exact value]');
+```
+
+### E2E Test Template (Playwright)
+```
+Test ID: E2E-[FLOW]-[NNN]
+Target: [user flow description]
+Priority: P[0-2]
+
+// Arrange
+await loginPage.navigate();
+
+// Act
+await loginPage.login('[email]', '[password]');
+
+// Assert
+await expect(dashboardPage.welcomeMessage).toHaveText('Welcome, Test User');
+```
+
+## POM Generation Rules
+
+Following CLAUDE.md strictly:
+1. One class per page — no god objects
+2. No assertions in page objects — assertions in test specs ONLY
+3. Locators as readonly properties — Tier 1 preferred (data-testid, ARIA roles)
+4. Actions return void or next page
+5. State queries return data
+6. Every POM extends BasePage
+
+## Locator Priority
+
+Always use this order:
+1. data-testid: `page.getByTestId('login-submit-btn')`
+2. ARIA role: `page.getByRole('button', { name: 'Log in' })`
+3. Label/placeholder: `page.getByLabel('Email')`
+4. CSS selector: `page.locator('.btn')` + `// TODO: Request test ID`
+
+## Expected Outcome Rules
+
+- **Be specific**: Exact values, status codes, text content
+- **Be measurable**: Timing thresholds, counts, lengths
+- **Be negative too**: What should NOT happen
+- **Include state transitions**: Before/after states
+- **Reference test data**: Use fixture values, not magic strings
+
+## Quality Gate
+
+- [ ] Every test has explicit expected outcome with concrete value
+- [ ] No vague words: "correct", "proper", "appropriate", "works"
+- [ ] All locators follow tier hierarchy
+- [ ] No assertions inside page objects
+- [ ] No hardcoded credentials
+- [ ] File naming follows project conventions
+- [ ] Test IDs are unique and follow convention
+- [ ] Priority (P0/P1/P2) assigned to every test

package/.claude/skills/qa-testid-injector/SKILL.md

@@ -1,93 +1,93 @@
----
-name: qa-testid-injector
-description: QA Test ID Injector. Scans source code to find interactive UI elements missing data-testid attributes and injects them following naming convention. Use when user wants to add test IDs, improve testability, audit missing test hooks, prepare for E2E automation, or add data-testid attributes before writing Playwright/Cypress tests. Triggers on "add test IDs", "add data-testid", "test hooks", "missing testid", "testability audit", "prepare for automation", "inject test attributes", "make components testable".
----
-
-# QA Test ID Injector
-
-## Purpose
-
-Scan application source code, identify interactive UI elements lacking stable test selectors, and inject `data-testid` attributes following a consistent naming convention. Runs as **Step 0** — before any test generation.
-
-## Core Rule
-
-**Every interactive element MUST have a stable, unique `data-testid` before E2E tests are generated against it.**
-
-## Naming Convention
-
-Pattern: `{context}-{description}-{element-type}` in kebab-case.
-
-### Element Type Suffixes
-
-| Element | Suffix | Example |
-|---------|--------|---------|
-| button | -btn | login-submit-btn |
-| input | -input | login-email-input |
-| select | -select | settings-language-select |
-| textarea | -textarea | feedback-comment-textarea |
-| link | -link | navbar-profile-link |
-| form | -form | checkout-payment-form |
-| img | -img | product-hero-img |
-| table | -table | users-list-table |
-| row | -row | users-item-row |
-| modal | -modal | confirm-delete-modal |
-| container | -container | dashboard-stats-container |
-| list | -list | notifications-list |
-| item | -item | notifications-item |
-| dropdown | -dropdown | navbar-user-dropdown |
-| tab | -tab | settings-security-tab |
-| checkbox | -checkbox | terms-accept-checkbox |
-| radio | -radio | shipping-express-radio |
-| toggle | -toggle | notifications-enabled-toggle |
-| badge | -badge | cart-count-badge |
-| alert | -alert | error-validation-alert |
-
-### Context Derivation
-
-1. **Page-level**: From component filename or route (LoginPage.tsx -> login)
-2. **Component-level**: From component name (<NavBar> -> navbar)
-3. **Nested**: Parent -> child hierarchy, max 3 levels deep
-4. **Dynamic lists**: Use template literals with unique keys
-
-## Execution Phases
-
-### Phase 1: SCAN
-- Detect framework (React/Vue/Angular/HTML) from package.json and file extensions
-- List all component files (exclude test/spec/stories)
-- Prioritize by interaction density (forms > pages > layouts)
-- Output: SCAN_MANIFEST.md
-
-### Phase 2: AUDIT
-- For each file, identify interactive elements
-- Classify: P0 (must have), P1 (should have), P2 (nice to have)
-- Record existing data-testid as EXISTING (don't modify)
-- Record missing as MISSING with proposed value
-- Output: TESTID_AUDIT_REPORT.md
-
-### Phase 3: INJECT
-- Add data-testid as LAST attribute before closing >
-- Preserve all existing formatting
-- Only add the attribute — change nothing else
-- Framework-specific handling (JSX, Vue, Angular, HTML)
-- Output: INJECTION_CHANGELOG.md + modified source files
-
-### Phase 4: VALIDATE
-- Syntax check all modified files
-- Uniqueness check (no duplicate testids per page)
-- Convention compliance check
-- Output: INJECTION_VALIDATION.md
-
-## Third-Party Components
-
-1. Props passthrough (if library supports it) — direct data-testid
-2. Wrapper div (if no passthrough) — wrap with data-testid div
-3. inputProps/slotProps (MUI-specific) — use component-specific prop APIs
-
-## Quality Gate
-
-- [ ] Every interactive element has a data-testid
-- [ ] All values follow {context}-{description}-{element-type} convention
-- [ ] No duplicate data-testid values in same page/route scope
-- [ ] No existing code modified beyond adding the attribute
-- [ ] Syntax validation passes on all modified files
-- [ ] Dynamic list items use template literals with unique keys
+---
+name: qa-testid-injector
+description: QA Test ID Injector. Scans source code to find interactive UI elements missing data-testid attributes and injects them following naming convention. Use when user wants to add test IDs, improve testability, audit missing test hooks, prepare for E2E automation, or add data-testid attributes before writing Playwright/Cypress tests. Triggers on "add test IDs", "add data-testid", "test hooks", "missing testid", "testability audit", "prepare for automation", "inject test attributes", "make components testable".
+---
+
+# QA Test ID Injector
+
+## Purpose
+
+Scan application source code, identify interactive UI elements lacking stable test selectors, and inject `data-testid` attributes following a consistent naming convention. Runs as **Step 0** — before any test generation.
+
+## Core Rule
+
+**Every interactive element MUST have a stable, unique `data-testid` before E2E tests are generated against it.**
+
+## Naming Convention
+
+Pattern: `{context}-{description}-{element-type}` in kebab-case.
+
+### Element Type Suffixes
+
+| Element | Suffix | Example |
+|---------|--------|---------|
+| button | -btn | login-submit-btn |
+| input | -input | login-email-input |
+| select | -select | settings-language-select |
+| textarea | -textarea | feedback-comment-textarea |
+| link | -link | navbar-profile-link |
+| form | -form | checkout-payment-form |
+| img | -img | product-hero-img |
+| table | -table | users-list-table |
+| row | -row | users-item-row |
+| modal | -modal | confirm-delete-modal |
+| container | -container | dashboard-stats-container |
+| list | -list | notifications-list |
+| item | -item | notifications-item |
+| dropdown | -dropdown | navbar-user-dropdown |
+| tab | -tab | settings-security-tab |
+| checkbox | -checkbox | terms-accept-checkbox |
+| radio | -radio | shipping-express-radio |
+| toggle | -toggle | notifications-enabled-toggle |
+| badge | -badge | cart-count-badge |
+| alert | -alert | error-validation-alert |
+
+### Context Derivation
+
+1. **Page-level**: From component filename or route (LoginPage.tsx -> login)
+2. **Component-level**: From component name (<NavBar> -> navbar)
+3. **Nested**: Parent -> child hierarchy, max 3 levels deep
+4. **Dynamic lists**: Use template literals with unique keys
+
+## Execution Phases
+
+### Phase 1: SCAN
+- Detect framework (React/Vue/Angular/HTML) from package.json and file extensions
+- List all component files (exclude test/spec/stories)
+- Prioritize by interaction density (forms > pages > layouts)
+- Output: SCAN_MANIFEST.md
+
+### Phase 2: AUDIT
+- For each file, identify interactive elements
+- Classify: P0 (must have), P1 (should have), P2 (nice to have)
+- Record existing data-testid as EXISTING (don't modify)
+- Record missing as MISSING with proposed value
+- Output: TESTID_AUDIT_REPORT.md
+
+### Phase 3: INJECT
+- Add data-testid as LAST attribute before closing >
+- Preserve all existing formatting
+- Only add the attribute — change nothing else
+- Framework-specific handling (JSX, Vue, Angular, HTML)
+- Output: INJECTION_CHANGELOG.md + modified source files
+
+### Phase 4: VALIDATE
+- Syntax check all modified files
+- Uniqueness check (no duplicate testids per page)
+- Convention compliance check
+- Output: INJECTION_VALIDATION.md
+
+## Third-Party Components
+
+1. Props passthrough (if library supports it) — direct data-testid
+2. Wrapper div (if no passthrough) — wrap with data-testid div
+3. inputProps/slotProps (MUI-specific) — use component-specific prop APIs
+
+## Quality Gate
+
+- [ ] Every interactive element has a data-testid
+- [ ] All values follow {context}-{description}-{element-type} convention
+- [ ] No duplicate data-testid values in same page/route scope
+- [ ] No existing code modified beyond adding the attribute
+- [ ] Syntax validation passes on all modified files
+- [ ] Dynamic list items use template literals with unique keys