aigroup-workflow 2.1.1 → 2.2.0

package/skills/test-master/references/qa-methodology.md

@@ -1,247 +0,0 @@
-# QA Methodology
-
-## Manual Testing Types
-
-### Exploratory Testing
-```markdown
-**Charter**: Explore {feature} with focus on {aspect}
-**Duration**: 60-90 min
-**Mission**: Find defects in {specific functionality}
-
-Test Ideas:
-- Boundary conditions & edge cases
-- Error handling & recovery
-- User workflow variations
-- Integration points
-
-Findings:
-1. [HIGH] {Issue + impact}
-2. [MED] {Issue + impact}
-
-Coverage: {Areas explored} | Risks: {Identified risks}
-```
-
-### Usability Testing
-```markdown
-**Task**: Can users complete {action} intuitively?
-**Metrics**: Time to complete, errors made, satisfaction (1-5)
-**Success**: 80% complete without help in <5 min
-
-Observations:
-- Navigation confusing at {step}
-- Users expect {A} but get {B}
-- Positive: {feature feedback}
-```
-
-### Accessibility Testing (WCAG 2.1 AA)
-```typescript
-test('accessibility compliance', async ({ page }) => {
-  // Keyboard navigation
-  await page.keyboard.press('Tab');
-  expect(['A', 'BUTTON', 'INPUT']).toContain(
-    await page.evaluate(() => document.activeElement.tagName)
-  );
-  
-  // ARIA labels
-  expect(await page.getByRole('button').first().getAttribute('aria-label')).toBeTruthy();
-  
-  // Color contrast (axe-core)
-  const violations = await page.evaluate(async () => {
-    const axe = await import('axe-core');
-    return (await axe.run()).violations;
-  });
-  expect(violations).toHaveLength(0);
-});
-```
-
-### Localization Testing
-```markdown
-**Test**: {Feature} in {language/locale}
-- [ ] Text displays without truncation
-- [ ] Date/time/currency formats correct
-- [ ] Right-to-left layout (Arabic, Hebrew)
-- [ ] Character encoding UTF-8
-- [ ] Sort order respects locale
-```
-
-### Compatibility Matrix
-```markdown
-| Browser | Version | OS | Status |
-|---------|---------|----|----- --|
-| Chrome | Latest | Win/Mac | ✓ |
-| Firefox | Latest | Win/Mac | ✓ |
-| Safari | Latest | macOS/iOS | ✓ |
-| Edge | Latest | Windows | ✓ |
-```
-
-## Test Design Techniques
-
-### Pairwise Testing
-```typescript
-// Test all parameter pairs efficiently
-const pairwiseTests = [
-  { browser: 'chrome', os: 'windows', lang: 'en' },
-  { browser: 'firefox', os: 'mac', lang: 'es' },
-  { browser: 'safari', os: 'windows', lang: 'fr' },
-  // Covers all pairs with minimal tests
-];
-```
-
-### Risk-Based Testing
-```markdown
-| Risk | Probability | Impact | Priority | Test Effort |
-|------|-------------|--------|----------|-------------|
-| Critical | High | High | P0 | Exhaustive |
-| High | Med-High | High | P1 | Comprehensive |
-| Medium | Low-Med | Med | P2 | Standard |
-| Low | Low | Low | P3 | Smoke only |
-```
-
-## Defect Management
-
-### Root Cause Analysis (5 Whys)
-```markdown
-1. Why did defect occur? {User input not validated}
-2. Why wasn't it validated? {Validation logic missing}
-3. Why was it missing? {Requirement unclear}
-4. Why was requirement unclear? {Acceptance criteria incomplete}
-5. Why incomplete? {No QA review in planning}
-
-**Root Cause**: QA not involved in requirements phase
-**Prevention**: Add QA to all planning meetings
-```
-
-### Defect Report Template
-```markdown
-## [CRITICAL] {Defect Title}
-
-**Steps to Reproduce**:
-1. {Step 1}
-2. {Step 2}
-
-**Expected**: {Should happen}
-**Actual**: {Actually happens}
-**Impact**: {Business/user impact}
-**Root Cause**: {Why it happened}
-**Fix**: {Recommended solution}
-```
-
-## Quality Metrics
-
-### Key Calculations
-```typescript
-// Defect Removal Efficiency (target: >95%)
-const dre = (defectsInTesting / (defectsInTesting + defectsInProd)) * 100;
-
-// Defect Leakage (target: <5%)
-const leakage = (defectsInProd / totalDefects) * 100;
-
-// Test Effectiveness (target: >90%)
-const effectiveness = (defectsFoundByTests / totalDefects) * 100;
-
-// Automation ROI
-const roi = (timeSaved - maintenanceCost - developmentCost) / developmentCost;
-```
-
-### Quality Dashboard
-```markdown
-| Metric | Target | Actual | Trend | Status |
-|--------|--------|--------|-------|--------|
-| Coverage | >80% | 87% | ↑ | ✓ |
-| Defect Leakage | <5% | 3% | ↓ | ✓ |
-| Automation | >70% | 68% | ↑ | ⚠ |
-| Critical Defects | 0 | 0 | → | ✓ |
-| MTTR | <48h | 36h | ↓ | ✓ |
-```
-
-## Continuous Testing & Shift-Left
-
-### Shift-Left Activities
-```markdown
-**Early Testing**:
-- Review requirements for testability
-- Create test cases during design
-- TDD: unit tests with code
-- Automated tests in CI pipeline
-- Static analysis on commit
-- Security scanning pre-merge
-
-**Benefits**: 10x cheaper defect fixes, faster feedback
-```
-
-### Feedback Cycle Targets
-```typescript
-const feedbackCycle = {
-  unitTests: '< 5 min',       // On save
-  integration: '< 15 min',    // On commit
-  e2e: '< 30 min',            // On PR
-  regression: '< 2 hours',    // Nightly
-};
-```
-
-## Quality Advocacy
-
-### Quality Gates
-```markdown
-## Production Release Gate
-
-**Must Pass (Blockers)**:
-- [ ] Zero critical defects
-- [ ] Coverage >80%
-- [ ] All P0/P1 tests passing
-- [ ] Performance SLA met
-- [ ] Security scan clean
-- [ ] Accessibility WCAG AA
-
-**Decision**: GO | NO-GO | GO with exceptions
-```
-
-### Team Education Program
-```markdown
-**Week 1-2**: Test fundamentals
-**Week 3-4**: Automation basics
-**Week 5-6**: Advanced topics (perf, security, API)
-**Ongoing**: Best practices, tool updates
-```
-
-## Test Planning
-
-### Test Plan Template
-```markdown
-## Test Plan: {Feature}
-
-**Scope**: {What to test}
-**Types**: Unit, Integration, E2E, Perf, Security
-**Resources**: {Team allocation}
-**Dependencies**: {Prerequisites}
-**Schedule**: {Timeline}
-**Entry Criteria**: {Start conditions}
-**Exit Criteria**: {Completion conditions}
-**Risks**: {Identified risks + mitigation}
-```
-
-### Environment Strategy
-```markdown
-| Env | Purpose | Data | Refresh | Access |
-|-----|---------|------|---------|--------|
-| Dev | Development | Synthetic | On-demand | All |
-| Test | QA testing | Test data | Daily | QA |
-| Stage | Pre-prod | Prod-like | Weekly | Limited |
-| Prod | Live | Real | N/A | Ops |
-```
-
-## Quick Reference
-
-| Testing Type | When | Duration |
-|--------------|------|----------|
-| Exploratory | New features | 60-120 min |
-| Usability | UI changes | 2-4 hours |
-| Accessibility | Every release | 1-2 hours |
-| Localization | Multi-region | 1 day/locale |
-
-| Metric | Excellent | Good | Needs Work |
-|--------|-----------|------|------------|
-| Coverage | >90% | 70-90% | <70% |
-| Leakage | <2% | 2-5% | >5% |
-| Automation | >80% | 60-80% | <60% |
-| MTTR | <24h | 24-48h | >48h |

package/skills/test-master/references/security-testing.md

@@ -1,127 +0,0 @@
-# Security Testing
-
-## Authentication Tests
-
-```typescript
-describe('Authentication Security', () => {
-  it('rejects invalid credentials', async () => {
-    await request(app)
-      .post('/api/login')
-      .send({ email: 'user@test.com', password: 'wrong' })
-      .expect(401);
-  });
-
-  it('rejects expired tokens', async () => {
-    const expiredToken = createExpiredToken();
-    await request(app)
-      .get('/api/protected')
-      .set('Authorization', `Bearer ${expiredToken}`)
-      .expect(401);
-  });
-
-  it('rejects tampered tokens', async () => {
-    const tamperedToken = validToken.slice(0, -5) + 'xxxxx';
-    await request(app)
-      .get('/api/protected')
-      .set('Authorization', `Bearer ${tamperedToken}`)
-      .expect(401);
-  });
-
-  it('enforces rate limiting on login', async () => {
-    for (let i = 0; i < 6; i++) {
-      await request(app)
-        .post('/api/login')
-        .send({ email: 'user@test.com', password: 'wrong' });
-    }
-
-    await request(app)
-      .post('/api/login')
-      .send({ email: 'user@test.com', password: 'correct' })
-      .expect(429);
-  });
-});
-```
-
-## Authorization Tests
-
-```typescript
-describe('Authorization', () => {
-  it('denies access to other users resources', async () => {
-    await request(app)
-      .get('/api/users/other-user-id/data')
-      .set('Authorization', `Bearer ${userAToken}`)
-      .expect(403);
-  });
-
-  it('denies admin routes to regular users', async () => {
-    await request(app)
-      .delete('/api/admin/users/123')
-      .set('Authorization', `Bearer ${regularUserToken}`)
-      .expect(403);
-  });
-});
-```
-
-## Input Validation Tests
-
-```typescript
-describe('Input Validation', () => {
-  it('rejects SQL injection attempts', async () => {
-    await request(app)
-      .get('/api/users')
-      .query({ search: "'; DROP TABLE users; --" })
-      .expect(400);
-  });
-
-  it('rejects XSS in input fields', async () => {
-    const response = await request(app)
-      .post('/api/posts')
-      .send({ title: '<script>alert("xss")</script>' })
-      .expect(201);
-
-    expect(response.body.title).not.toContain('<script>');
-  });
-
-  it('validates file upload types', async () => {
-    await request(app)
-      .post('/api/upload')
-      .attach('file', 'malicious.exe')
-      .expect(400);
-  });
-});
-```
-
-## Security Headers Test
-
-```typescript
-describe('Security Headers', () => {
-  it('sets security headers', async () => {
-    const response = await request(app).get('/');
-
-    expect(response.headers['x-content-type-options']).toBe('nosniff');
-    expect(response.headers['x-frame-options']).toBe('DENY');
-    expect(response.headers['strict-transport-security']).toBeDefined();
-  });
-});
-```
-
-## Security Test Checklist
-
-| Category | Tests |
-|----------|-------|
-| **Auth** | Invalid creds, token expiry, tampering |
-| **Input** | SQL injection, XSS, command injection |
-| **Access** | IDOR, privilege escalation |
-| **Rate Limit** | Brute force, API abuse |
-| **Headers** | CSP, HSTS, X-Frame-Options |
-| **Data** | PII exposure, error messages |
-
-## Quick Reference
-
-| Vulnerability | Test Approach |
-|---------------|---------------|
-| SQL Injection | `'; DROP TABLE--` in inputs |
-| XSS | `<script>alert(1)</script>` |
-| IDOR | Access other user's resources |
-| CSRF | Missing/invalid tokens |
-| Auth Bypass | Missing auth, expired tokens |

package/skills/test-master/references/tdd-iron-laws.md

@@ -1,174 +0,0 @@
-# TDD Iron Laws
-
----
-
-## The Fundamental Principle
-
-> **NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST.**
-
-This is non-negotiable. If you wrote production code before writing a failing test, delete it and start over. No exceptions.
-
----
-
-## The Three Iron Laws
-
-### Iron Law 1: The Fundamental Rule
-
-> "You shall not write any production code unless it is to make a failing test pass."
-
-Every line of production code must have a corresponding test that:
-1. Was written first
-2. Was observed to fail
-3. Now passes because of that code
-
-### Iron Law 2: Proof Through Observation
-
-> "If you didn't watch the test fail, you don't know if it tests the right thing."
-
-Mandatory verification steps:
-- Write the test
-- Run it and **observe the failure**
-- Verify the failure message is meaningful
-- Only then implement the fix
-
-A test you've never seen fail proves nothing.
-
-### Iron Law 3: The Final Rule
-
-> "Production code exists → A test exists that failed first. Otherwise → It's not TDD."
-
-There is no middle ground. Code written without a prior failing test is not test-driven development, regardless of how many tests exist afterward.
-
----
-
-## The RED-GREEN-REFACTOR Cycle
-
-### RED: Write One Minimal Failing Test
-
-```typescript
-// Start with the smallest possible failing test
-it('should return 0 for empty array', () => {
-  expect(sum([])).toBe(0);
-});
-// Run: ✗ FAIL - sum is not defined
-```
-
-**Requirements:**
-- One test at a time
-- Minimal scope
-- Clear failure message
-- Observe the red
-
-### GREEN: Implement Simplest Passing Code
-
-```typescript
-// Write only enough code to pass this specific test
-function sum(numbers: number[]): number {
-  return 0;
-}
-// Run: ✓ PASS
-```
-
-**Requirements:**
-- Simplest possible implementation
-- No extra features
-- No optimization
-- Just make it pass
-
-### REFACTOR: Improve While Keeping Tests Green
-
-```typescript
-// Now improve the code while tests stay green
-function sum(numbers: number[]): number {
-  return numbers.reduce((acc, n) => acc + n, 0);
-}
-// Run: ✓ PASS (still)
-```
-
-**Requirements:**
-- Tests must stay green
-- Remove duplication
-- Improve clarity
-- No new functionality
-
----
-
-## Common Rationalizations to Reject
-
-These thoughts indicate you're about to violate TDD:
-
-| Rationalization | Why It's Wrong |
-|-----------------|----------------|
-| "I can manually test this quickly" | Manual testing doesn't prevent regression |
-| "I'll write tests after to save time" | You'll skip edge cases and test implementation |
-| "This is too simple to need a test" | Simple code changes; tests document expectations |
-| "I've already written the code, I can't delete it now" | Sunk cost fallacy; delete it |
-| "I know this works, I've done it before" | Your memory isn't documentation |
-| "We're in a hurry" | Technical debt costs more than TDD |
-
----
-
-## Practical Application
-
-### Starting a New Feature
-
-```typescript
-// 1. RED: Write failing test for simplest behavior
-describe('UserValidator', () => {
-  it('should reject empty email', () => {
-    expect(validateEmail('')).toBe(false);
-  });
-});
-
-// 2. GREEN: Implement minimal passing code
-function validateEmail(email: string): boolean {
-  return email.length > 0;
-}
-
-// 3. RED: Add next failing test
-it('should reject email without @', () => {
-  expect(validateEmail('invalid')).toBe(false);
-});
-
-// 4. GREEN: Extend to pass both tests
-function validateEmail(email: string): boolean {
-  return email.length > 0 && email.includes('@');
-}
-
-// Continue cycle...
-```
-
-### Fixing a Bug
-
-```typescript
-// 1. RED: Write test that exposes the bug
-it('should handle negative numbers in sum', () => {
-  expect(sum([-1, -2, -3])).toBe(-6);
-});
-// Run: ✗ FAIL - got 0 instead of -6
-
-// 2. GREEN: Fix the bug
-function sum(numbers: number[]): number {
-  return numbers.reduce((acc, n) => acc + n, 0);
-}
-// Run: ✓ PASS
-
-// Bug is now fixed AND protected against regression
-```
-
----
-
-## Verification Checklist
-
-Before claiming any code is complete:
-
-- [ ] Every production function has corresponding tests
-- [ ] Each test was written before its implementation
-- [ ] Each test was observed to fail first
-- [ ] Tests verify behavior, not implementation
-- [ ] Refactoring kept all tests green
-- [ ] No production code exists without a test
-
----
-
-*Content adapted from [obra/superpowers](https://github.com/obra/superpowers) by Jesse Vincent (@obra), MIT License.*

package/skills/test-master/references/test-reports.md

@@ -1,104 +0,0 @@
-# Test Reports
-
-## Test Report Template
-
-```markdown
-# Test Report: {Feature Name}
-
-**Date**: YYYY-MM-DD
-**Tester**: {Name}
-**Version**: {App Version}
-
-## Summary
-
-| Metric | Value |
-|--------|-------|
-| Total Tests | X |
-| Passed | X |
-| Failed | X |
-| Skipped | X |
-| Coverage | X% |
-
-## Test Scope
-
-- [x] Unit tests
-- [x] Integration tests
-- [x] E2E tests
-- [ ] Performance tests
-- [ ] Security tests
-
-## Findings
-
-### [CRITICAL] {Issue Title}
-- **Location**: src/api/users.ts:45
-- **Steps to Reproduce**:
-  1. Send POST to /api/users without auth
-  2. Request succeeds with 201
-- **Expected**: 401 Unauthorized
-- **Actual**: 201 Created
-- **Impact**: Unauthorized user creation
-- **Fix**: Add auth middleware
-
-### [HIGH] {Issue Title}
-- **Location**: src/services/orders.ts:123
-- **Description**: N+1 query in order list
-- **Impact**: 3s response time with 100 orders
-- **Fix**: Add eager loading for order items
-
-### [MEDIUM] {Issue Title}
-- **Details**: ...
-
-### [LOW] {Issue Title}
-- **Details**: ...
-
-## Coverage Analysis
-
-| Module | Lines | Branches | Functions |
-|--------|-------|----------|-----------|
-| api/ | 85% | 78% | 90% |
-| services/ | 92% | 85% | 95% |
-| utils/ | 100% | 100% | 100% |
-
-### Coverage Gaps
-- `src/api/admin.ts` - 0% (no tests)
-- `src/services/payment.ts:45-60` - Error handling untested
-
-## Recommendations
-
-1. **Immediate**: Add auth middleware to admin routes
-2. **High Priority**: Optimize order queries
-3. **Medium Priority**: Add tests for payment error handling
-4. **Low Priority**: Increase branch coverage in api/
-
-## Performance Results
-
-| Endpoint | p50 | p95 | p99 |
-|----------|-----|-----|-----|
-| GET /users | 45ms | 120ms | 250ms |
-| POST /orders | 150ms | 400ms | 800ms |
-
-## Sign-off
-
-- [ ] All critical issues addressed
-- [ ] Coverage meets threshold (80%)
-- [ ] Performance meets SLA
-```
-
-## Severity Definitions
-
-| Severity | Criteria |
-|----------|----------|
-| **CRITICAL** | Security vulnerability, data loss, system crash |
-| **HIGH** | Major functionality broken, severe performance |
-| **MEDIUM** | Feature partially working, workaround exists |
-| **LOW** | Minor issue, cosmetic, edge case |
-
-## Quick Reference
-
-| Section | Content |
-|---------|---------|
-| Summary | High-level metrics |
-| Findings | Issues by severity |
-| Coverage | Code coverage analysis |
-| Recommendations | Prioritized actions |
-| Sign-off | Approval criteria |