devflow-kit 1.8.2 → 2.0.0

package/plugins/devflow-code-review/skills/test-patterns/references/violations.md

@@ -1,221 +0,0 @@
-# Test Pattern Violations - Extended Examples
-
-Reference examples for common test quality violations across both design and review contexts.
-
----
-
-## Complex Setup Violations
-
-### Multi-Dependency Service Setup
-
-```typescript
-// VIOLATION: Complex setup indicates design problem
-describe('UserService', () => {
-  let service: UserService;
-  let mockDb: MockDatabase;
-  let mockCache: MockCache;
-  let mockLogger: MockLogger;
-  let mockConfig: MockConfig;
-
-  beforeEach(async () => {
-    mockDb = new MockDatabase();
-    await mockDb.connect();
-    await mockDb.seed();
-    mockCache = new MockCache();
-    mockCache.clear();
-    mockLogger = new MockLogger();
-    mockConfig = new MockConfig();
-    mockConfig.set('env', 'test');
-    // ... 10+ more lines
-    service = new UserService(mockDb, mockCache, mockLogger, mockConfig);
-  });
-
-  it('should create user', async () => {
-    const result = await service.createUser({ name: 'test' });
-    expect(result.ok).toBe(true);
-  });
-});
-```
-
-**Root Cause**: UserService has too many dependencies (6+ injected services)
-
-**Solution**: Split into focused services with single responsibility
-
----
-
-## Repetitive Boilerplate Violations
-
-### Try/Catch Pattern Repetition
-
-```typescript
-// VIOLATION: Repetitive error handling indicates API problem
-describe('API endpoints', () => {
-  it('should handle user creation error', async () => {
-    try {
-      await api.createUser(invalidData);
-      fail('Should have thrown');
-    } catch (error) {
-      expect(error.status).toBe(400);
-      expect(error.message).toContain('validation');
-    }
-  });
-
-  // ... repeated pattern 10+ times
-});
-```
-
-**Root Cause**: API throws exceptions instead of returning Results
-
-**Solution**: Migrate API to Result pattern
-
----
-
-## Difficult Mocking Violations
-
-### Nested Mock Object Structures
-
-```typescript
-// VIOLATION: Complex mocking indicates tight coupling
-beforeEach(() => {
-  mockDb = {
-    transaction: jest.fn((callback) => callback(mockDb)),
-    orders: { create: jest.fn(), update: jest.fn(), findById: jest.fn() },
-    users: { findById: jest.fn(), update: jest.fn() },
-    inventory: { decrement: jest.fn(), check: jest.fn(), reserve: jest.fn() }
-  };
-  // 5+ more mock objects...
-});
-```
-
-**Root Cause**: OrderProcessor directly depends on too many external systems
-
-**Solution**: Separate pure business logic from I/O; use composition
-
----
-
-## Implementation Testing Violations
-
-### Spying on Private Methods
-
-```typescript
-// VIOLATION: Testing implementation details
-it('should call updateTotal after addItem', () => {
-  const cart = new ShoppingCart();
-  const spy = jest.spyOn(cart as any, 'updateTotal');
-  cart.addItem({ id: '1', price: 10 });
-  expect(spy).toHaveBeenCalled();  // Testing implementation!
-});
-```
-
-**Root Cause**: Tests coupled to implementation details
-
-**Solution**: Test observable behavior only
-
----
-
-## Coverage Violations
-
-### Missing Edge Cases
-
-```typescript
-// INCOMPLETE TESTS
-describe('divide', () => {
-  it('divides two numbers', () => {
-    expect(divide(10, 2)).toBe(5);  // Happy path only
-  });
-});
-
-// COMPLETE TESTS
-describe('divide', () => {
-  it('divides two positive numbers', () => { expect(divide(10, 2)).toBe(5); });
-  it('handles division by zero', () => { expect(divide(10, 0)).toBe(Infinity); });
-  it('handles negative numbers', () => { expect(divide(-10, 2)).toBe(-5); });
-  it('handles decimal results', () => { expect(divide(10, 3)).toBeCloseTo(3.333, 2); });
-});
-```
-
-### Unclear Test Names
-
-```typescript
-// UNCLEAR: What does this test?
-it('test1', () => { /* ... */ });
-it('should work', () => { /* ... */ });
-
-// CLEAR: Describes behavior
-it('validates email format on creation', () => { /* ... */ });
-it('rejects passwords shorter than 8 characters', () => { /* ... */ });
-```
-
----
-
-## Test Design Violations
-
-### Slow Tests (Real Delays)
-
-```typescript
-// SLOW: Real delays
-const result = await fetchWithRetry();  // Waits real 1000ms
-
-// FAST: Mock timers
-jest.useFakeTimers();
-const promise = fetchWithRetry();
-jest.advanceTimersByTime(1000);
-```
-
-### Flaky Tests (Timing Dependencies)
-
-```typescript
-// FLAKY: Race condition
-subscribe(callback);
-emit('update', { value: 1 });
-expect(callback).toHaveBeenCalled();  // Might not have fired yet
-
-// STABLE: Explicit waiting
-const received = new Promise(resolve => { subscribe(data => resolve(data)); });
-emit('update', { value: 1 });
-const data = await received;
-expect(data.value).toBe(1);
-```
-
-### Over-Mocking
-
-```typescript
-// OVER-MOCKED: Tests nothing real
-const mockValidator = { validate: jest.fn().mockReturnValue(true) };
-const mockHasher = { hash: jest.fn().mockReturnValue('hashed') };
-const mockRepo = { create: jest.fn().mockResolvedValue({ id: '1' }) };
-// What did we actually test? Just that mocks were called.
-
-// BETTER: Use real implementations where possible
-const repo = new InMemoryUserRepo();
-const service = new UserService(new RealValidator(), new RealHasher(), repo);
-const saved = await repo.findByEmail('test@test.com');
-expect(await bcrypt.compare('password', saved.password)).toBe(true);
-```
-
----
-
-## Environment & Database Violations
-
-### Environment Manipulation
-
-```typescript
-// VIOLATION: Tests modifying environment
-beforeEach(() => {
-  process.env = { ...process.env, DATABASE_URL: 'postgres://test', API_KEY: 'test-key' };
-});
-```
-
-**Solution**: Inject configuration as a dependency
-
-### Database State Dependencies
-
-```typescript
-// VIOLATION: Tests depend on specific seeded data
-beforeAll(async () => {
-  await db.users.insert([/* ... */]);
-  await db.orders.insert([/* ... */]);
-});
-```
-
-**Solution**: Separate data access from business logic; test calculation separately

package/plugins/devflow-core-skills/.claude-plugin/plugin.json

@@ -1,31 +0,0 @@
-{
-  "name": "devflow-core-skills",
-  "description": "Auto-activating quality enforcement skills - foundation layer for all DevFlow plugins",
-  "author": {
-    "name": "Dean0x"
-  },
-  "version": "1.8.2",
-  "homepage": "https://github.com/dean0x/devflow",
-  "repository": "https://github.com/dean0x/devflow",
-  "license": "MIT",
-  "keywords": [
-    "skills",
-    "quality",
-    "patterns",
-    "auto-activate",
-    "enforcement",
-    "foundation"
-  ],
-  "agents": [],
-  "skills": [
-    "core-patterns",
-    "docs-framework",
-    "git-safety",
-    "git-workflow",
-    "github-patterns",
-    "input-validation",
-    "search-first",
-    "test-driven-development",
-    "test-patterns"
-  ]
-}

package/plugins/devflow-core-skills/README.md

@@ -1,50 +0,0 @@
-# devflow-core-skills
-
-Auto-activating quality enforcement skills for Claude Code. These skills activate automatically based on context to enforce best practices.
-
-## Installation
-
-```bash
-# Via DevFlow CLI
-npx devflow-kit init --plugin=core-skills
-
-# Via Claude Code (when available)
-/plugin install dean0x/devflow-core-skills
-```
-
-## Skills Included
-
-| Skill | Auto-Triggers When | What It Enforces |
-|-------|-------------------|------------------|
-| `core-patterns` | Business logic, error handling | Result types, DI, immutability, workaround labeling |
-| `git-workflow` | Staging files, creating commits, PRs | Atomic commits, message format, PR descriptions |
-| `test-patterns` | Tests written or modified | Test quality, setup complexity, behavior testing, coverage |
-| `input-validation` | API endpoints, external data handling | Boundary validation, parse-don't-validate |
-| `typescript` | TypeScript codebases | Type safety, generics, utility types |
-| `react` | React codebases | Components, hooks, state management |
-
-## How Auto-Activation Works
-
-Skills monitor context and activate when their trigger conditions are met. You don't need to invoke them manually - they provide guidance and enforcement automatically.
-
-## Iron Laws
-
-Each skill enforces a non-negotiable principle:
-
-| Skill | Iron Law |
-|-------|----------|
-| `core-patterns` | NEVER THROW IN BUSINESS LOGIC |
-| `git-workflow` | ATOMIC COMMITS WITH HONEST DESCRIPTIONS |
-| `test-patterns` | TESTS VALIDATE BEHAVIOR, NOT IMPLEMENTATION |
-| `input-validation` | ALL EXTERNAL DATA IS HOSTILE |
-| `typescript` | UNKNOWN OVER ANY |
-| `react` | COMPOSITION OVER PROPS |
-
-## Usage
-
-No manual invocation needed. Skills activate automatically. To see what a skill enforces, check its SKILL.md file in the skills directory.
-
-## Related Plugins
-
-- [devflow-implement](../devflow-implement) - Implementation workflow with additional skills
-- [devflow-code-review](../devflow-code-review) - Review with pattern skills

package/plugins/devflow-core-skills/skills/core-patterns/SKILL.md

@@ -1,162 +0,0 @@
----
-name: core-patterns
-description: This skill should be used when the user asks to "handle errors", "inject dependencies", "return Result", "make it immutable", "compose with pipes", or implements business logic, error handling, or service composition. Provides Result type patterns, dependency injection, immutability by default, pipe composition, and structured logging for robust application architecture.
-user-invocable: false
-allowed-tools: Read, Grep, Glob, AskUserQuestion
----
-
-# Core Engineering Patterns
-
-The canonical source of architectural patterns and principles for consistent, high-quality code.
-
-## Iron Law
-
-> **NEVER THROW IN BUSINESS LOGIC**
->
-> All operations that can fail MUST return Result types. Exceptions are allowed
-> ONLY at system boundaries (API handlers, database adapters). Any `throw` statement
-> in business logic is a violation. No exceptions.
-
-## Philosophy
-
-1. **Type Safety First** - Strict type checking, avoid dynamic types
-2. **Functional Core, Imperative Shell** - Business logic pure, side effects isolated
-3. **Explicit Error Handling** - Result types instead of exceptions
-4. **Immutability by Default** - Return new objects, don't mutate
-5. **Dependency Injection** - Inject dependencies for testability
-6. **Test Behaviors** - Simple tests that validate behavior, not implementation
-7. **No Fake Solutions** - Be honest about limitations and workarounds
-8. **Fix Root Causes** - Never work around bad architecture
-
----
-
-## Pattern 1: Result Types
-
-```typescript
-type Result<T, E = Error> = { ok: true; value: T } | { ok: false; error: E };
-
-function createUser(data: unknown): Result<User, ValidationError> {
-  if (!valid(data)) return Err({ type: 'ValidationFailed', details: validate(data).errors });
-  return Ok(buildUser(data));
-}
-```
-
-## Pattern 2: Dependency Injection
-
-```typescript
-class UserService {
-  constructor(private db: Database, private emailer: EmailService) {}
-}
-// Easy to test: new UserService(mockDb, mockEmailer)
-```
-
-Never: `private db = new Database()` - can't mock.
-
-## Pattern 3: Immutability
-
-```typescript
-function updateUser(user: User, changes: Partial<User>): User {
-  return { ...user, ...changes };  // New object, no mutation
-}
-```
-
-Never mutate inputs. Copy before `.sort()`.
-
-## Pattern 4: Pure Functions
-
-```typescript
-function calculateTotal(items: Item[], taxRate: number): number {
-  return items.reduce((sum, i) => sum + i.price, 0) * (1 + taxRate);
-}
-```
-
-No side effects in pure functions.
-
-## Pattern 5: Type Safety
-
-```typescript
-type Status = 'pending' | 'completed' | 'failed';
-function handleStatus(status: Status): string {
-  switch (status) {
-    case 'pending': return 'Waiting';
-    case 'completed': return 'Done';
-    case 'failed': return 'Error';
-  }  // Exhaustive - no default needed
-}
-```
-
-## Pattern 6: Error Type Design
-
-```typescript
-type UserError =
-  | { type: 'NotFound'; userId: string }
-  | { type: 'ValidationFailed'; field: string; message: string };
-```
-
-## Pattern 7: Resource Cleanup
-
-```typescript
-const handle = await fs.open(path);
-try {
-  return Ok(parse(await handle.readFile()));
-} finally {
-  await handle.close();
-}
-```
-
-## Pattern 8: Architecture Documentation
-
-```typescript
-// ARCHITECTURE: Repository returns domain objects only
-// ARCHITECTURE EXCEPTION: Direct DB for health check - must work if service layer down
-```
-
-## Pattern 9: Naming Conventions
-
-- **Types/Classes**: PascalCase (`UserProfile`)
-- **Functions/Variables**: camelCase (`calculateTotal`)
-- **Constants**: SCREAMING_SNAKE_CASE (`MAX_RETRY`)
-
-## Pattern 10: Performance Awareness
-
-```typescript
-const customerMap = new Map(customers.map(c => [c.id, c]));  // O(1) vs O(n)
-```
-
----
-
-## Consistency Rules
-
-- Result types: if one method returns Result, ALL must
-- DI: apply consistently throughout
-- Async: single pattern (don't mix callbacks/promises)
-
-## Anti-Patterns
-
-| Pattern | Description |
-|---------|-------------|
-| Fake Solutions | Hardcoded responses simulating functionality |
-| Silent Failures | Catch blocks that swallow errors |
-| Magic Values | Unlabeled constants with special meaning |
-| Deceptive Code | Functions that pretend to work (e.g., `return true` with no logic) |
-
-### Workaround Labeling (Required)
-
-All workarounds, hacks, and temporary solutions MUST be labeled:
-
-| Label | Use When |
-|-------|----------|
-| `HACK:` | Workaround for specific problem |
-| `MOCK:` | Fake data for testing/development |
-| `TODO:` | Work that needs to be done |
-| `TEMPORARY:` | Short-term solution with deadline |
-| `NOT-PRODUCTION:` | Code that should never ship |
-| `ARCHITECTURE EXCEPTION:` | Violates pattern with justification |
-
-Unlabeled workarounds, empty catch blocks, and early returns without rationale are violations. See `references/code-smell-violations.md` for extended examples.
-
----
-
-## Extended References
-
-See `references/` for: violations.md, patterns.md, detection.md, checklist.md