devflow-kit 1.8.3 → 2.0.0

package/plugins/devflow-self-review/agents/validator.md

@@ -1,86 +0,0 @@
----
-name: Validator
-description: Dedicated agent for running validation commands (build, typecheck, lint, test). Reports pass/fail with structured failure details - never fixes.
-model: haiku
-skills: test-patterns
----
-
-# Validator Agent
-
-You are a validation specialist that runs build and test commands to verify code correctness. You discover validation commands from project configuration, execute them in order, and report structured results. You never fix issues - you only report them for other agents to fix.
-
-## Input Context
-
-You receive from orchestrator:
-- **FILES_CHANGED**: List of modified files
-- **VALIDATION_SCOPE**: `full` | `changed-only` (hints for test filtering if supported)
-
-## Responsibilities
-
-1. **Discover validation commands**: Check package.json scripts, Makefile, Cargo.toml, or similar for available commands
-2. **Execute in order**: build → typecheck → lint → test (skip if command doesn't exist)
-3. **Capture all output**: Record stdout/stderr for each command
-4. **Parse failures**: Extract file:line references from error output where possible
-5. **Report results**: Return structured pass/fail status with failure details
-
-## Validation Order
-
-Execute in this order, stopping on first failure:
-
-| Priority | Command Type | Common Examples |
-|----------|-------------|-----------------|
-| 1 | Build | `npm run build`, `cargo build`, `make build` |
-| 2 | Typecheck | `npm run typecheck`, `tsc --noEmit` |
-| 3 | Lint | `npm run lint`, `cargo clippy`, `make lint` |
-| 4 | Test | `npm test`, `cargo test`, `make test` |
-
-## Principles
-
-1. **Report only** - Never fix code, never commit, never modify files
-2. **Stop on failure** - First failure halts remaining commands
-3. **Parse intelligently** - Extract file:line from error messages when possible
-4. **Respect scope** - Use VALIDATION_SCOPE hint for test filtering if framework supports it
-5. **Fast feedback** - Use haiku model for speed on this simple task
-
-## Output
-
-Return structured validation results:
-
-```markdown
-## Validation Report
-
-### Status: PASS | FAIL | BLOCKED
-
-### Commands Executed
-| Command | Status | Duration |
-|---------|--------|----------|
-| npm run build | PASS | 3.2s |
-| npm run typecheck | FAIL | 1.8s |
-
-### Failures (if FAIL)
-
-#### typecheck
-```
-src/auth/login.ts:42:15 - error TS2339: Property 'email' does not exist on type 'User'.
-src/auth/login.ts:58:3 - error TS2345: Argument of type 'string' is not assignable to parameter of type 'number'.
-```
-
-**Parsed References:**
-- `src/auth/login.ts:42` - Property 'email' does not exist on type 'User'
-- `src/auth/login.ts:58` - Argument type mismatch (string vs number)
-
-### Blockers (if BLOCKED)
-{Description of why validation couldn't run - e.g., missing dependencies, broken config}
-```
-
-## Boundaries
-
-**Escalate to orchestrator (BLOCKED):**
-- No validation commands found in project
-- Validation command crashes (not test failure, but command itself fails to run)
-- Missing dependencies that prevent any validation
-
-**Handle autonomously:**
-- All command execution and output parsing
-- Determining which commands exist and should run
-- Formatting error output into structured references

package/plugins/devflow-self-review/commands/self-review.md

@@ -1,132 +0,0 @@
----
-description: Self-review workflow - Simplifier (code clarity) then Scrutinizer (9-pillar quality gate)
----
-
-# Self-Review Command
-
-Run Simplifier and Scrutinizer sequentially on changed files for post-implementation quality refinement.
-
-## Usage
-
-/self-review              (auto-detect changed files from git)
-/self-review <file>...    (review specific files)
-
-## Phases
-
-### Phase 0: Context Gathering
-
-Detect changed files and build context:
-
-1. If arguments provided, use those as FILES_CHANGED
-2. Else run `git diff --name-only HEAD` + `git diff --name-only --cached` to get staged + unstaged
-3. If no changes found, report "No changes to review" and exit
-4. Build TASK_DESCRIPTION from recent commit messages or branch name
-5. Read `.memory/knowledge/pitfalls.md` and `.memory/knowledge/decisions.md`. Pass as KNOWLEDGE_CONTEXT to Simplifier and Scrutinizer — known pitfalls help identify reintroduced issues, prior decisions help validate architectural consistency.
-
-**Extract:** FILES_CHANGED (list), TASK_DESCRIPTION (string), KNOWLEDGE_CONTEXT (string, optional)
-
-### Phase 1: Simplifier (Code Refinement)
-
-Spawn Simplifier agent to refine code for clarity and consistency:
-
-Task(subagent_type="Simplifier", run_in_background=false):
-"TASK_DESCRIPTION: {task_description}
-FILES_CHANGED: {files_changed}
-KNOWLEDGE_CONTEXT: {knowledge_context or 'None'}
-Simplify and refine the code for clarity and consistency while preserving functionality.
-If knowledge context is provided, verify no known pitfall patterns are being reintroduced."
-
-**Wait for completion.** Simplifier commits changes directly.
-
-### Phase 2: Scrutinizer (9-Pillar Quality Gate)
-
-Spawn Scrutinizer agent for quality evaluation and fixing:
-
-Task(subagent_type="Scrutinizer", run_in_background=false):
-"TASK_DESCRIPTION: {task_description}
-FILES_CHANGED: {files_changed}
-KNOWLEDGE_CONTEXT: {knowledge_context or 'None'}
-Evaluate against 9-pillar framework. Fix P0/P1 issues. Return structured report.
-If knowledge context is provided, check whether any known pitfall patterns are being reintroduced and verify architectural consistency with prior decisions."
-
-**Wait for completion.** Extract: STATUS (PASS|FIXED|BLOCKED), changes_made (bool)
-
-### Phase 3: Conditional Validation
-
-If Scrutinizer made changes (STATUS == FIXED):
-
-Task(subagent_type="Validator", run_in_background=false):
-"FILES_CHANGED: {scrutinizer_modified_files}
-VALIDATION_SCOPE: changed-only
-Run build, typecheck, lint, test on modified files"
-
-**If FAIL:** Report validation failures to user and halt
-**If PASS:** Continue to report
-
-### Phase 4: Report
-
-Display summary:
-
-## Self-Review Complete
-
-**Files Reviewed**: {n}
-**Status**: {PASS|FIXED|BLOCKED}
-
-### Simplifier
-- {n} files refined for clarity
-
-### Scrutinizer (9-Pillar Evaluation)
-| Pillar | Status |
-|--------|--------|
-| Design | {status} |
-| Functionality | {status} |
-| Security | {status} |
-| Complexity | {status} |
-| Error Handling | {status} |
-| Tests | {status} |
-| Naming | {status} |
-| Consistency | {status} |
-| Documentation | {status} |
-
-### Commits Created
-- {sha} {message}
-
-{If BLOCKED: ### Blocking Issue\n{description}}
-
-## Architecture
-
-/self-review (orchestrator)
-│
-├─ Phase 0: Context gathering
-│  ├─ Git diff for changed files
-│  └─ Read project knowledge (decisions.md + pitfalls.md)
-│
-├─ Phase 1: Simplifier
-│  └─ Code refinement (commits directly)
-│
-├─ Phase 2: Scrutinizer
-│  └─ 9-pillar quality gate (may fix and commit)
-│
-├─ Phase 3: Validator (conditional)
-│  └─ If Scrutinizer made changes, verify tests pass
-│
-└─ Phase 4: Report
-   └─ Display summary with pillar status
-
-## Edge Cases
-
-| Case | Handling |
-|------|----------|
-| No changes | Report "No changes to review" and exit |
-| Simplifier finds nothing | Normal, continue to Scrutinizer |
-| Scrutinizer BLOCKED | Report blocking issue, halt workflow |
-| Validation fails | Report failures, halt (don't create broken state) |
-| Not in git repo | Report error, suggest running in git repo |
-
-## Principles
-
-1. **Orchestration only** - Command spawns agents, doesn't do the work
-2. **Sequential execution** - Simplifier must complete before Scrutinizer
-3. **Validation gate** - If Scrutinizer changes code, must pass validation
-4. **Honest reporting** - Display actual agent outputs
-5. **Fail fast** - Stop on BLOCKED or validation failure

package/plugins/devflow-self-review/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

package/plugins/devflow-self-review/skills/core-patterns/references/checklist.md

@@ -1,276 +0,0 @@
-# Validation Checklist
-
-Comprehensive checklist for code review and validation against core engineering patterns.
-
----
-
-## Pre-Implementation Checklist
-
-Before writing code, verify:
-
-- [ ] Understood the existing patterns in the codebase
-- [ ] Identified similar implementations to follow
-- [ ] Determined if Result types are used (and will follow same pattern)
-- [ ] Identified dependencies that need injection
-- [ ] Planned separation of pure logic from side effects
-
----
-
-## Result Types Checklist
-
-### Functions That Can Fail
-
-- [ ] All business functions return `Result<T, E>` types
-- [ ] No `throw` statements in business logic
-- [ ] Error types are discriminated unions (not generic Error)
-- [ ] Each error type has all context needed to handle it
-- [ ] Async functions return `Promise<Result<T, E>>`
-
-### Exception Boundaries
-
-- [ ] Try/catch ONLY at system boundaries (API handlers, DB adapters)
-- [ ] Boundaries convert exceptions to Result types
-- [ ] HTTP responses derived from Result errors
-- [ ] No silent error swallowing (empty catch blocks)
-
-### Error Handling
-
-- [ ] All Result errors are handled explicitly
-- [ ] No `if (!result.ok) return;` without proper handling
-- [ ] Error propagation preserves context
-- [ ] Logging happens before converting errors
-
----
-
-## Dependency Injection Checklist
-
-### Constructor Injection
-
-- [ ] All dependencies passed through constructor
-- [ ] No `new` keyword for dependencies inside classes
-- [ ] No imported singletons used directly
-- [ ] No static method calls on external services
-
-### Interfaces
-
-- [ ] Dependencies typed as interfaces, not implementations
-- [ ] Interfaces are small and focused (ISP)
-- [ ] Mock implementations easy to create
-- [ ] No concrete class imports in business logic
-
-### Testing
-
-- [ ] Can instantiate class with mock dependencies
-- [ ] No test requires real database/network
-- [ ] No environment manipulation in tests
-- [ ] Test setup is < 10 lines
-
----
-
-## Immutability Checklist
-
-### Objects
-
-- [ ] All updates return new objects (spread operator)
-- [ ] No direct property assignment on inputs
-- [ ] No `delete` operator on inputs
-- [ ] Nested updates also create new objects
-
-### Arrays
-
-- [ ] No `.push()`, `.pop()`, `.shift()`, `.unshift()`
-- [ ] No `.splice()`, `.reverse()`, `.sort()` on originals
-- [ ] Use `.map()`, `.filter()`, `.reduce()` for transformations
-- [ ] Copy before sorting: `[...arr].sort()`
-
-### State
-
-- [ ] No module-level `let` or `var`
-- [ ] No global mutable state
-- [ ] Configuration is frozen after initialization
-- [ ] Caches use immutable entries
-
----
-
-## Pure Functions Checklist
-
-### Business Logic
-
-- [ ] Pure functions have no side effects
-- [ ] Same input always produces same output
-- [ ] No date/time access (inject clock)
-- [ ] No random values (inject generator)
-- [ ] No environment variable access
-
-### Side Effect Isolation
-
-- [ ] I/O operations in wrapper functions
-- [ ] Pure calculations extracted and tested separately
-- [ ] Side effects clearly documented
-- [ ] Logging/metrics in wrappers, not core logic
-
-### Dependencies
-
-- [ ] Time/random injected as dependencies
-- [ ] Environment config loaded once at startup
-- [ ] File system access at boundaries only
-- [ ] Network calls at boundaries only
-
----
-
-## Type Safety Checklist
-
-### Strict Types
-
-- [ ] No `any` types (use `unknown` for dynamic data)
-- [ ] All function parameters typed
-- [ ] All return types explicit
-- [ ] Strict null checks enabled
-
-### Pattern Matching
-
-- [ ] Switch statements are exhaustive
-- [ ] Discriminated unions for state/variants
-- [ ] No default case that hides missing patterns
-- [ ] Type guards for runtime narrowing
-
-### Type Design
-
-- [ ] Domain types prevent primitive obsession
-- [ ] Branded types for IDs that shouldn't mix
-- [ ] Optional fields explicit (`field?: Type`)
-- [ ] Readonly where appropriate
-
----
-
-## Error Type Design Checklist
-
-### Discriminated Unions
-
-- [ ] Each error type has a `type` discriminator
-- [ ] Error types include all context needed
-- [ ] Related errors grouped in union types
-- [ ] Error unions are exhaustive
-
-### Error Information
-
-- [ ] Error messages are actionable
-- [ ] Technical details preserved for logging
-- [ ] User-facing messages are sanitized
-- [ ] Error codes are unique and documented
-
----
-
-## Resource Cleanup Checklist
-
-### File/Connection Handling
-
-- [ ] All file handles closed in `finally`
-- [ ] All connections released in `finally`
-- [ ] Using context managers (Python) or `using` (TS)
-- [ ] Pool resources released after use
-
-### Subscriptions/Timers
-
-- [ ] Event listeners removed on cleanup
-- [ ] Intervals cleared when done
-- [ ] Timeouts cleared if operation completes early
-- [ ] Subscription manager for complex lifecycles
-
-### Memory
-
-- [ ] Large data structures released when done
-- [ ] Caches have size limits or TTL
-- [ ] Circular references avoided
-- [ ] WeakMap/WeakSet for object keys
-
----
-
-## API Consistency Checklist
-
-### Error Handling Pattern
-
-- [ ] Same error handling pattern across module
-- [ ] All methods return Result OR all throw (not mixed)
-- [ ] Error types consistent across related methods
-- [ ] HTTP error mapping centralized
-
-### Async Pattern
-
-- [ ] Single async pattern (async/await preferred)
-- [ ] No mixing callbacks and promises
-- [ ] All async calls awaited (no fire-and-forget)
-- [ ] Promise.all for parallel operations
-
-### Naming
-
-- [ ] Consistent naming across codebase
-- [ ] PascalCase for types/classes
-- [ ] camelCase for functions/variables
-- [ ] SCREAMING_SNAKE_CASE for constants
-
----
-
-## Architecture Documentation Checklist
-
-### Code Comments
-
-- [ ] Public APIs have JSDoc/docstrings
-- [ ] Complex algorithms explained
-- [ ] Non-obvious decisions documented
-- [ ] Architecture boundaries marked
-
-### Exceptions/Workarounds
-
-- [ ] All workarounds labeled (HACK:, TODO:, TEMPORARY:)
-- [ ] Architecture exceptions have justification
-- [ ] Technical debt has tracking ticket
-- [ ] Deadlines on temporary solutions
-
----
-
-## Performance Checklist
-
-### Measurement
-
-- [ ] Performance claims have benchmarks
-- [ ] Hot paths identified and measured
-- [ ] No premature optimization
-- [ ] Trade-offs documented
-
-### Common Issues
-
-- [ ] No N+1 queries
-- [ ] Appropriate data structures (Map vs Array)
-- [ ] Lazy evaluation for expensive operations
-- [ ] Batch operations where possible
-
----
-
-## Anti-Pattern Checklist
-
-Verify NONE of these exist:
-
-- [ ] No hardcoded responses simulating functionality
-- [ ] No silent error swallowing
-- [ ] No unlabeled magic values
-- [ ] No global mutable state
-- [ ] No tight coupling to concrete implementations
-- [ ] No mixing error handling patterns
-- [ ] No fire-and-forget async calls
-- [ ] No resource leaks
-
----
-
-## Final Review Checklist
-
-Before considering code complete:
-
-- [ ] All tests pass
-- [ ] No TypeScript errors
-- [ ] No ESLint warnings
-- [ ] Code matches existing patterns
-- [ ] Documentation updated
-- [ ] No TODO without ticket
-- [ ] No console.log in production code
-- [ ] No commented-out code