@alanwang-merit/meritdata-platform-skill-package 1.0.10 → 1.0.11

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 |

package/skills/test-master/references/testing-anti-patterns.md

@@ -1,231 +0,0 @@
-# Testing Anti-Patterns
-
----
-
-## Core Principle
-
-> **"Test what the code does, not what the mocks do."**
-
-When tests verify mock behavior instead of actual functionality, they provide false confidence while catching zero real bugs.
-
----
-
-## The Five Anti-Patterns
-
-### Anti-Pattern 1: Testing Mock Behavior
-
-**The Problem:** Verifying that mocks exist and were called, rather than testing actual component output.
-
-```typescript
-// ❌ BAD: Testing the mock, not the behavior
-it('should call the API', () => {
-  const mockApi = jest.fn().mockResolvedValue({ data: 'test' });
-  const service = new UserService(mockApi);
-
-  service.getUser(1);
-
-  expect(mockApi).toHaveBeenCalledWith(1); // Testing mock, not result
-});
-```
-
-```typescript
-// ✅ GOOD: Testing actual behavior
-it('should return user data from API', async () => {
-  const mockApi = jest.fn().mockResolvedValue({ id: 1, name: 'Alice' });
-  const service = new UserService(mockApi);
-
-  const user = await service.getUser(1);
-
-  expect(user.name).toBe('Alice'); // Testing actual output
-});
-```
-
-**Solution:** Test the genuine component output. If you can only verify mock calls, reconsider whether the test adds value.
-
----
-
-### Anti-Pattern 2: Test-Only Methods in Production
-
-**The Problem:** Adding methods to production classes solely for test setup or cleanup.
-
-```typescript
-// ❌ BAD: Production code polluted with test concerns
-class UserCache {
-  private cache: Map<number, User> = new Map();
-
-  getUser(id: number): User | undefined {
-    return this.cache.get(id);
-  }
-
-  // This method exists ONLY for tests
-  _resetForTesting(): void {
-    this.cache.clear();
-  }
-}
-```
-
-```typescript
-// ✅ GOOD: Test utilities separate from production
-// production/UserCache.ts
-class UserCache {
-  private cache: Map<number, User> = new Map();
-
-  getUser(id: number): User | undefined {
-    return this.cache.get(id);
-  }
-}
-
-// test/helpers.ts
-function createFreshCache(): UserCache {
-  return new UserCache(); // Fresh instance per test
-}
-```
-
-**Solution:** Relocate cleanup logic to test utility functions. Use fresh instances per test instead of reset methods.
-
----
-
-### Anti-Pattern 3: Mocking Without Understanding
-
-**The Problem:** Over-mocking without grasping side effects, leading to tests that pass but hide real issues.
-
-```typescript
-// ❌ BAD: Mocking everything without understanding
-it('should process order', async () => {
-  jest.mock('./inventory');
-  jest.mock('./payment');
-  jest.mock('./shipping');
-  jest.mock('./notifications');
-
-  const result = await processOrder(order);
-
-  expect(result.success).toBe(true); // What did we actually test?
-});
-```
-
-```typescript
-// ✅ GOOD: Strategic mocking with real components where possible
-it('should process order with real inventory check', async () => {
-  // Real inventory service against test database
-  const inventory = new InventoryService(testDb);
-
-  // Mock only external services
-  const payment = mockPaymentGateway();
-
-  const processor = new OrderProcessor(inventory, payment);
-  const result = await processor.process(order);
-
-  expect(result.success).toBe(true);
-  expect(await inventory.getStock(order.itemId)).toBe(originalStock - 1);
-});
-```
-
-**Solution:** Run tests with real implementations first to understand behavior. Then mock at the appropriate level - external services, not internal logic.
-
----
-
-### Anti-Pattern 4: Incomplete Mocks
-
-**The Problem:** Partial mock responses missing downstream fields that production code expects.
-
-```typescript
-// ❌ BAD: Incomplete mock response
-const mockUserApi = jest.fn().mockResolvedValue({
-  id: 1,
-  name: 'Test User'
-  // Missing: email, createdAt, permissions, settings...
-});
-
-// Test passes, but production crashes when accessing user.email
-```
-
-```typescript
-// ✅ GOOD: Complete mock matching real API response
-const mockUserApi = jest.fn().mockResolvedValue({
-  id: 1,
-  name: 'Test User',
-  email: 'test@example.com',
-  createdAt: '2024-01-01T00:00:00Z',
-  permissions: ['read', 'write'],
-  settings: {
-    theme: 'light',
-    notifications: true
-  }
-});
-
-// Or use a factory
-const mockUserApi = jest.fn().mockResolvedValue(
-  createMockUser({ name: 'Test User' }) // Factory fills defaults
-);
-```
-
-**Solution:** Mirror complete real API response structure. Use factories to generate complete mock objects with sensible defaults.
-
----
-
-### Anti-Pattern 5: Integration Tests as Afterthought
-
-**The Problem:** Treating testing as optional follow-up work rather than integral to development.
-
-```typescript
-// ❌ BAD: "We'll add tests later"
-// Day 1: Write 500 lines of code
-// Day 2: Write 500 more lines
-// Day 3: "We need to ship, tests can wait"
-// Day 30: Catastrophic bug in production
-// Day 31: "Why didn't we have tests?"
-```
-
-```typescript
-// ✅ GOOD: Tests are part of implementation
-// Write failing test
-it('should reject duplicate usernames', async () => {
-  await createUser({ username: 'alice' });
-
-  await expect(createUser({ username: 'alice' }))
-    .rejects.toThrow('Username already exists');
-});
-
-// Make it pass
-async function createUser(data: UserInput): Promise<User> {
-  const existing = await db.users.findByUsername(data.username);
-  if (existing) {
-    throw new Error('Username already exists');
-  }
-  return db.users.create(data);
-}
-
-// Feature AND test ship together
-```
-
-**Solution:** Follow TDD - testing is implementation, not documentation. No feature is "done" without tests.
-
----
-
-## Detection Checklist
-
-Review your tests for these warning signs:
-
-| Warning Sign | Anti-Pattern |
-|-------------|--------------|
-| `expect(mock).toHaveBeenCalled()` without testing output | Testing mock behavior |
-| Methods starting with `_` or `ForTesting` in production | Test-only methods |
-| Every dependency is mocked | Mocking without understanding |
-| Mocks return `{ success: true }` only | Incomplete mocks |
-| Test files added weeks after feature ships | Tests as afterthought |
-
----
-
-## Quick Reference
-
-| Anti-Pattern | Symptom | Fix |
-|-------------|---------|-----|
-| Testing mocks | Only mock assertions, no behavior tests | Assert on actual output |
-| Test-only methods | `_reset()`, `_setForTest()` in prod | Use fresh instances |
-| Over-mocking | 10+ mocks per test | Test with real deps first |
-| Incomplete mocks | Minimal stub responses | Use factories, match reality |
-| Tests as afterthought | Features ship untested | TDD from the start |
-
----
-
-*Content adapted from [obra/superpowers](https://github.com/obra/superpowers) by Jesse Vincent (@obra), MIT License.*