@su-record/vibe 3.2.64 → 4.0.0

package/skills/vibe.run/internal/arch-guard/agents/violation-checker.md

@@ -1,51 +0,0 @@
----
-name: arch-violation-checker
-role: Scans all import statements across the codebase and flags boundary violations against the rule set
-tools: [Glob, Grep, Read]
----
-
-# Arch Violation Checker
-
-## Role
-Performs the mechanical import-graph scan against the generated rule set. For every file in a `from` layer, it extracts all import paths and checks whether any resolve into a `cannotImport` layer. Reports each violation with full context.
-
-## Responsibilities
-- Enumerate all files matching each rule's `from` glob pattern
-- Extract import and require statements from each file
-- Resolve relative imports to their canonical layer classification
-- Check resolved imports against the `cannotImport` glob patterns
-- Collect violations with file path, line number, importing path, and violated rule
-
-## Input
-Normalized rule set JSON from `arch-rule-generator` and project root path.
-
-## Output
-Violation list JSON:
-```json
-{
-  "violations": [
-    {
-      "rule": "domain-no-infra",
-      "file": "src/domain/user.ts",
-      "line": 3,
-      "import": "../infra/db/userRepository",
-      "resolved": "src/infra/db/userRepository.ts",
-      "severity": "error"
-    }
-  ],
-  "scannedFiles": 142,
-  "cleanFiles": 139
-}
-```
-
-## Communication
-- Reports violation list to: `arch-reporter`
-- Receives instructions from: arch-guard orchestrator (SKILL.md)
-
-## Domain Knowledge
-Import resolution rules:
-- Relative imports (`./`, `../`) must be resolved relative to the importing file's location
-- Path aliases (`@/`, `~/`) must be resolved using the project's `tsconfig.json` `paths` config
-- External package imports (no leading `.` or `/`) are always allowed — skip them
-- Re-export barrel files (`index.ts`) count as the directory they represent
-- Type-only imports (`import type`) still count as dependencies for boundary purposes

package/skills/vibe.run/internal/arch-guard/frameworks/clean-architecture.md

@@ -1,108 +0,0 @@
----
-name: clean-architecture
-type: framework
-applies-to: [arch-guard]
----
-
-# Clean Architecture — Reference Card
-
-## Layer Model
-
-```
-┌─────────────────────────────────┐
-│  Frameworks & Drivers           │  ← UI, DB, HTTP, CLI, external APIs
-├─────────────────────────────────┤
-│  Interface Adapters             │  ← Controllers, Presenters, Gateways
-├─────────────────────────────────┤
-│  Application Use Cases          │  ← Business rules orchestration
-├─────────────────────────────────┤
-│  Entities (Domain)              │  ← Core business objects & rules
-└─────────────────────────────────┘
-```
-
-**Dependency Rule**: Dependencies point inward only. Inner layers know nothing about outer layers.
-
-## Layer Responsibilities
-
-| Layer | Contains | Must NOT contain |
-|-------|----------|-----------------|
-| Entities | Domain models, value objects, domain rules | Framework imports, DB calls |
-| Use Cases | Application workflows, business logic | HTTP, DB drivers, UI logic |
-| Adapters | Controllers, mappers, repository impls | Business rules, domain logic |
-| Frameworks | Express routes, Prisma, React, CLI | Business or application logic |
-
-## Dependency Rule in Code
-
-```ts
-// Good — Use Case depends on abstraction (repository interface)
-// src/use-cases/CreateUser.ts
-interface UserRepository { save(user: User): Promise<void> }
-
-export class CreateUserUseCase {
-  constructor(private users: UserRepository) {}
-  execute(data: CreateUserInput): Promise<User> { /* business logic only */ }
-}
-
-// Good — Adapter implements the interface
-// src/adapters/PrismaUserRepository.ts
-import { PrismaClient } from '@prisma/client'; // framework import OK here
-class PrismaUserRepository implements UserRepository {
-  save(user: User): Promise<void> { /* prisma call */ }
-}
-
-// Bad — Use Case imports Prisma directly (crosses boundary)
-// src/use-cases/CreateUser.ts
-import { PrismaClient } from '@prisma/client'; // VIOLATION
-```
-
-## Boundary Crossing Patterns
-
-### Data Transfer Objects (DTOs)
-Cross boundaries using plain data structures, not domain entities.
-
-```ts
-// Input DTO — from outer layer into use case
-type CreateUserInput = { email: string; name: string }
-
-// Output DTO — from use case out to adapter
-type CreateUserOutput = { id: string; email: string; createdAt: Date }
-```
-
-### Repository Pattern
-Isolates data access behind an interface defined in the domain layer.
-
-```ts
-// Defined in domain layer
-interface UserRepository {
-  findById(id: string): Promise<User | null>
-  save(user: User): Promise<void>
-  delete(id: string): Promise<void>
-}
-```
-
-## Common Violations
-
-| Violation | Example | Fix |
-|-----------|---------|-----|
-| Framework import in entity | `import express from 'express'` in `User.ts` | Move to adapter layer |
-| DB call in use case | `prisma.user.findMany()` in use case | Use repository interface |
-| Business logic in controller | `if (price > 100) applyDiscount()` in route handler | Move to use case |
-| Entity exposed via HTTP | Return `User` domain object as JSON directly | Map to response DTO |
-| Use case depends on use case | `CreateOrder` imports `CreateUser` | Extract shared logic to domain service |
-
-## Directory Structure Convention
-
-```
-src/
-  domain/          ← Entities, value objects, domain interfaces
-  use-cases/       ← Application business rules
-  adapters/        ← Controllers, repository implementations, mappers
-  infrastructure/  ← DB, HTTP, external services (framework layer)
-```
-
-## Arch-Guard Checks
-
-- No `import` crossing inward (outer → inner only)
-- No framework imports (`express`, `prisma`, `mongoose`) in `domain/` or `use-cases/`
-- No `fetch`/`axios` in entities or use cases
-- All use case dependencies are interfaces, not concrete classes

package/skills/vibe.run/internal/arch-guard/frameworks/solid.md

@@ -1,102 +0,0 @@
----
-name: solid-principles
-type: framework
-applies-to: [arch-guard]
----
-
-# SOLID Principles — Reference Card
-
-## S — Single Responsibility Principle
-> A class/module should have only one reason to change.
-
-**Violation signal**: A function does fetching + parsing + formatting + writing.
-
-```ts
-// Bad — UserService handles auth AND email AND db writes
-class UserService {
-  login(email: string, password: string): void { /* auth logic */ }
-  sendWelcomeEmail(user: User): void { /* email logic */ }
-  saveToDb(user: User): void { /* db logic */ }
-}
-
-// Good — each class owns one concern
-class AuthService { login(email: string, password: string): void {} }
-class EmailService { sendWelcome(user: User): void {} }
-class UserRepository { save(user: User): void {} }
-```
-
-## O — Open/Closed Principle
-> Open for extension, closed for modification.
-
-**Violation signal**: Adding a new type requires editing existing switch/if chains.
-
-```ts
-// Bad — adding payment type requires editing processPayment
-function processPayment(type: string, amount: number): void {
-  if (type === 'card') { /* ... */ }
-  if (type === 'paypal') { /* ... */ }
-}
-
-// Good — extend via new class, no existing code changes
-interface PaymentProcessor { process(amount: number): void }
-class CardProcessor implements PaymentProcessor { process(amount: number): void {} }
-class PayPalProcessor implements PaymentProcessor { process(amount: number): void {} }
-```
-
-## L — Liskov Substitution Principle
-> Subtypes must be substitutable for their base types.
-
-**Violation signal**: Overriding a method to throw `NotImplementedError` or changing preconditions.
-
-```ts
-// Bad — Square breaks Rectangle's invariant (width/height independence)
-class Rectangle { setWidth(w: number): void {} setHeight(h: number): void {} }
-class Square extends Rectangle {
-  setWidth(w: number): void { this.width = w; this.height = w; } // breaks contract
-}
-
-// Good — separate types, shared interface
-interface Shape { area(): number }
-class Rectangle implements Shape { area(): number { return this.w * this.h; } }
-class Square implements Shape { area(): number { return this.side ** 2; } }
-```
-
-## I — Interface Segregation Principle
-> Clients should not depend on interfaces they do not use.
-
-**Violation signal**: Implementing an interface and leaving methods as `() => { throw new Error() }`.
-
-```ts
-// Bad — Printer forced to implement fax() it doesn't support
-interface Machine { print(): void; scan(): void; fax(): void; }
-
-// Good — split into focused interfaces
-interface Printer { print(): void }
-interface Scanner { scan(): void }
-interface FaxMachine { fax(): void }
-```
-
-## D — Dependency Inversion Principle
-> Depend on abstractions, not concretions.
-
-**Violation signal**: High-level module imports a specific low-level class directly.
-
-```ts
-// Bad — OrderService tightly coupled to MySQLDatabase
-import { MySQLDatabase } from './MySQLDatabase';
-class OrderService { db = new MySQLDatabase(); }
-
-// Good — depend on interface, inject implementation
-interface Database { query(sql: string): unknown[] }
-class OrderService { constructor(private db: Database) {} }
-```
-
-## Quick Checklist
-
-| Principle | Red Flag |
-|-----------|----------|
-| SRP | Function/class name contains "And" or "Manager" |
-| OCP | Adding feature requires editing existing if/switch |
-| LSP | Subclass throws `NotImplemented` or removes behavior |
-| ISP | Interface has methods unused by most implementors |
-| DIP | `new ConcreteClass()` inside a high-level module |

package/skills/vibe.run/internal/arch-guard/scripts/check-boundaries.js

@@ -1,90 +0,0 @@
-#!/usr/bin/env node
-/**
- * arch-guard/scripts/check-boundaries.js
- * Read arch-rules.json and scan imports for violations.
- * Usage: node check-boundaries.js [arch-rules.json] [src-dir]
- * Output: JSON array of violations to stdout.
- */
-
-import fs from 'fs';
-import path from 'path';
-
-const IMPORT_RE = /(?:import|from|require)\s*\(?['"]([^'"]+)['"]\)?/g;
-const CODE_EXTS = new Set(['.ts', '.tsx', '.js', '.jsx']);
-
-/** @returns {string[]} */
-function collectFiles(dir) {
-  if (!fs.existsSync(dir)) return [];
-  const results = [];
-  for (const entry of fs.readdirSync(dir, { withFileTypes: true })) {
-    if (entry.name.startsWith('.') || entry.name === 'node_modules' || entry.name === 'dist') continue;
-    const full = path.join(dir, entry.name);
-    if (entry.isDirectory()) results.push(...collectFiles(full));
-    else if (CODE_EXTS.has(path.extname(entry.name))) results.push(full);
-  }
-  return results;
-}
-
-/** @param {string} pattern @param {string} filePath @returns {boolean} */
-function matchesGlob(pattern, filePath) {
-  const normalized = filePath.replace(/\\/g, '/');
-  const regexStr = pattern
-    .replace(/\\/g, '/')
-    .replace(/\./g, '\\.')
-    .replace(/\*\*/g, '__DOUBLE__')
-    .replace(/\*/g, '[^/]+')
-    .replace(/__DOUBLE__/g, '.+');
-  return new RegExp(`^${regexStr}$`).test(normalized);
-}
-
-/** @param {string} file @returns {string[]} */
-function extractImports(file) {
-  const content = fs.readFileSync(file, 'utf-8');
-  const imports = [];
-  let m;
-  IMPORT_RE.lastIndex = 0;
-  while ((m = IMPORT_RE.exec(content)) !== null) imports.push(m[1]);
-  return imports;
-}
-
-/** @param {string} fromFile @param {string} imp @param {string} baseDir @returns {string} */
-function resolveImport(fromFile, imp, baseDir) {
-  if (!imp.startsWith('.')) return imp;
-  return path.resolve(path.dirname(fromFile), imp).replace(baseDir + path.sep, '').replace(/\\/g, '/');
-}
-
-const rulesPath = process.argv[2] || '.vibe/arch-rules.json';
-const srcDir = path.resolve(process.argv[3] || 'src');
-const baseDir = path.resolve('.');
-
-if (!fs.existsSync(rulesPath)) {
-  process.stderr.write(`arch-rules.json not found: ${rulesPath}\n`);
-  process.exit(1);
-}
-
-const { rules } = JSON.parse(fs.readFileSync(rulesPath, 'utf-8'));
-const files = collectFiles(srcDir);
-const violations = [];
-
-for (const rule of rules) {
-  const fromFiles = files.filter(f => matchesGlob(rule.from, f.replace(baseDir + path.sep, '').replace(/\\/g, '/')));
-  for (const file of fromFiles) {
-    const imports = extractImports(file);
-    for (const imp of imports) {
-      const resolved = resolveImport(file, imp, baseDir);
-      const forbidden = (rule.cannotImport || []).some(pat => matchesGlob(pat, resolved) || resolved.includes(pat.replace('/**', '').replace('**/', '')));
-      if (forbidden) {
-        violations.push({
-          rule: rule.name,
-          file: file.replace(baseDir + path.sep, '').replace(/\\/g, '/'),
-          import: imp,
-          resolved,
-          reason: rule.reason || `Violates rule: ${rule.name}`,
-        });
-      }
-    }
-  }
-}
-
-process.stdout.write(JSON.stringify(violations, null, 2) + '\n');
-if (violations.length > 0) process.exit(1);

package/skills/vibe.run/internal/arch-guard/templates/arch-rules.json

@@ -1,47 +0,0 @@
-{
-  "_comment": "Architecture boundary rules for arch-guard. Copy to .vibe/arch-rules.json and customize.",
-  "rules": [
-    {
-      "name": "services-no-ui",
-      "from": "src/services/**",
-      "cannotImport": ["src/components/**", "src/pages/**", "src/app/**"],
-      "canImport": ["src/models/**", "src/utils/**", "src/types/**"],
-      "reason": "Services must be UI-agnostic for testability and reuse"
-    },
-    {
-      "name": "domain-no-infra",
-      "from": "src/domain/**",
-      "cannotImport": ["src/infra/**", "src/db/**", "src/adapters/**"],
-      "canImport": ["src/domain/**", "src/types/**"],
-      "reason": "Domain layer must not depend on infrastructure (Clean Architecture)"
-    },
-    {
-      "name": "components-no-pages",
-      "from": "src/components/**",
-      "cannotImport": ["src/pages/**", "src/app/**"],
-      "canImport": ["src/components/**", "src/hooks/**", "src/utils/**", "src/types/**"],
-      "reason": "Shared components must not import from page-level modules"
-    },
-    {
-      "name": "lib-no-components",
-      "from": "src/lib/**",
-      "cannotImport": ["src/components/**", "src/pages/**"],
-      "canImport": ["src/lib/**", "src/types/**"],
-      "reason": "Library utilities must be framework-agnostic"
-    },
-    {
-      "name": "models-no-controllers",
-      "from": "src/models/**",
-      "cannotImport": ["src/controllers/**", "src/handlers/**", "src/routes/**"],
-      "canImport": ["src/models/**", "src/types/**"],
-      "reason": "Models must not depend on request/response layer (MVC)"
-    },
-    {
-      "name": "no-direct-db-in-handlers",
-      "from": "src/handlers/**",
-      "cannotImport": ["src/db/**", "src/repositories/**"],
-      "canImport": ["src/services/**", "src/types/**"],
-      "reason": "Handlers must use services, not access the database directly"
-    }
-  ]
-}

package/skills/vibe.run/internal/arch-guard/templates/violation-report.md

@@ -1,53 +0,0 @@
-# Architecture Violation Report
-
-**Project**: {{PROJECT_NAME}}
-**Date**: {{DATE}}
-**Rules File**: {{RULES_FILE}}
-**Total Violations**: {{VIOLATION_COUNT}}
-
----
-
-## Summary
-
-| Rule | Violations |
-|------|-----------|
-{{RULE_SUMMARY_TABLE}}
-
----
-
-## Violations by Rule
-
-{{VIOLATIONS_BY_RULE}}
-
-<!-- Example entry:
-### services-no-ui (3 violations)
-
-**Rule**: Services must be UI-agnostic for testability and reuse
-
-| File | Forbidden Import |
-|------|-----------------|
-| src/services/auth.ts | src/components/Button.tsx |
-| src/services/user.ts | src/pages/dashboard/index.ts |
--->
-
----
-
-## How to Fix
-
-For each violation, choose one:
-
-1. **Move the dependency** — relocate shared logic to a layer both sides can import
-2. **Invert the dependency** — use an interface/callback instead of a direct import
-3. **Promote the import** — move the imported file to a shared/common layer
-4. **Update the rule** — if the violation is intentional, document why and update arch-rules.json
-
-> Do NOT suppress violations without documenting the reason in arch-rules.json.
-
----
-
-## Next Steps
-
-1. Fix all violations in the table above
-2. Re-run: `node skills/vibe.arch-guard/scripts/check-boundaries.js {{RULES_FILE}} {{SRC_DIR}}`
-3. Commit clean state: `git commit -m "fix: resolve arch-guard boundary violations"`
-4. Add to CI: run check-boundaries.js in pre-commit or CI pipeline

package/skills/vibe.run/internal/exec-plan/agents/decomposer.md

@@ -1,47 +0,0 @@
----
-name: plan-decomposer
-role: Breaks a SPEC document into concrete phases and atomic tasks
-tools: [Read]
----
-
-# Plan Decomposer
-
-## Role
-Reads a SPEC document and breaks it into a structured hierarchy of phases and tasks. Each task is scoped to a single file or function change, making it independently assignable and reviewable. Produces the raw task list that all other planning agents operate on.
-
-## Responsibilities
-- Parse SPEC phases and acceptance criteria into discrete implementation tasks
-- Scope each task to a single concern: one file, one function, one schema change
-- Classify each task by type: create, modify, delete, test, config, migration
-- Identify tasks that are purely setup/scaffolding vs. feature logic vs. verification
-- Flag ambiguous requirements that need clarification before implementation can begin
-- Produce a flat numbered task list with parent-phase references
-
-## Input
-- SPEC document path (e.g., `.vibe/specs/my-feature.spec.md`)
-- Optional: existing codebase context to detect which files already exist
-
-## Output
-Task list JSON:
-```json
-{
-  "phases": [
-    {
-      "id": "P1",
-      "name": "Data Layer",
-      "tasks": [
-        { "id": "T1", "phase": "P1", "type": "create", "description": "Create User schema in src/db/schema.ts", "file": "src/db/schema.ts" },
-        { "id": "T2", "phase": "P1", "type": "create", "description": "Create userRepository with findById, save, delete", "file": "src/infra/userRepository.ts" }
-      ]
-    }
-  ],
-  "ambiguities": ["SPEC phase 3 does not specify error handling strategy for 404 case"]
-}
-```
-
-## Communication
-- Reports task list to: `plan-dependency-mapper`
-- Receives instructions from: exec-plan orchestrator (SKILL.md)
-
-## Domain Knowledge
-Decomposition heuristics: tasks should be completable in 15-60 min. If a task description contains "and", split it. Test tasks must correspond 1:1 with feature tasks. Migration tasks always precede the feature tasks that depend on the new schema. Prefer vertical slices (full feature thin slice) over horizontal layers when parallelizing.

package/skills/vibe.run/internal/exec-plan/agents/dependency-mapper.md

@@ -1,44 +0,0 @@
----
-name: plan-dependency-mapper
-role: Creates a directed acyclic graph of task dependencies to reveal what can run in parallel
-tools: [Read]
----
-
-# Dependency Mapper
-
-## Role
-Analyzes the decomposed task list and maps the true dependency relationships between tasks, producing a DAG (directed acyclic graph). Identifies which tasks have no dependencies and can start immediately, which must wait, and which form the critical path — the longest chain that determines the minimum total execution time.
-
-## Responsibilities
-- Analyze each task pair for dependency relationships (does T2 require T1's output?)
-- Classify dependency types: file-level (imports the file), schema-level (uses the type), logical (tests the feature)
-- Build a DAG with tasks as nodes and dependencies as directed edges
-- Detect and flag cycles — which indicate a SPEC conflict requiring clarification
-- Identify the critical path: the longest chain of sequential dependencies
-- List all tasks with zero dependencies (immediately parallelizable)
-
-## Input
-Task list JSON from `plan-decomposer`.
-
-## Output
-Dependency graph:
-```json
-{
-  "dag": {
-    "T1": { "deps": [], "dependents": ["T2", "T3"] },
-    "T2": { "deps": ["T1"], "dependents": ["T4"] },
-    "T3": { "deps": ["T1"], "dependents": ["T4"] },
-    "T4": { "deps": ["T2", "T3"], "dependents": [] }
-  },
-  "criticalPath": ["T1", "T2", "T4"],
-  "parallelizable": [["T2", "T3"]],
-  "cycles": []
-}
-```
-
-## Communication
-- Reports dependency graph to: `plan-estimator`
-- Receives instructions from: exec-plan orchestrator (SKILL.md)
-
-## Domain Knowledge
-Dependency detection rules: if task A creates a file that task B imports, A must precede B. If task A defines a type that task B uses, A must precede B. Test tasks depend on the feature task they test. Config/setup tasks depend on nothing and should be in the first wave. DAG critical path calculation: longest path from source to sink node by task count (not time, until estimator adds duration).

package/skills/vibe.run/internal/exec-plan/agents/estimator.md

@@ -1,43 +0,0 @@
----
-name: plan-estimator
-role: Estimates complexity and duration for each task and suggests parallelization strategy
-tools: [Read, Glob]
----
-
-# Plan Estimator
-
-## Role
-Assigns complexity and effort estimates to each task based on task type, scope, and codebase context. Uses the dependency graph to compute the estimated critical path duration and suggest an optimal parallel execution wave plan that minimizes total clock time.
-
-## Responsibilities
-- Assign effort estimates per task: trivial (< 15 min), minor (15-30 min), moderate (30-60 min), major (> 60 min)
-- Check existing codebase for similar implementations to calibrate estimates
-- Compute total sequential estimate and parallel estimate using the DAG waves
-- Group tasks into execution waves: Wave 1 (no deps), Wave 2 (deps only on Wave 1), etc.
-- Identify tasks suitable for sub-agent delegation vs. tasks requiring orchestrator attention
-- Flag tasks with high uncertainty that need a spike/research step first
-
-## Input
-Task list JSON from `plan-decomposer` and dependency graph from `plan-dependency-mapper`.
-
-## Output
-Estimated plan with waves:
-```json
-{
-  "totalSequentialEstimate": "4h 30m",
-  "totalParallelEstimate": "2h 15m",
-  "waves": [
-    { "wave": 1, "tasks": ["T1"], "estimate": "30m", "note": "Foundation — must complete before anything else" },
-    { "wave": 2, "tasks": ["T2", "T3"], "estimate": "45m", "note": "Parallel — independent of each other" },
-    { "wave": 3, "tasks": ["T4", "T5"], "estimate": "60m", "note": "Integration — requires wave 2 output" }
-  ],
-  "highUncertaintyTasks": ["T6 — no existing auth pattern to reference, consider spike first"]
-}
-```
-
-## Communication
-- Reports estimated plan to: `plan-validator`
-- Receives instructions from: exec-plan orchestrator (SKILL.md)
-
-## Domain Knowledge
-Complexity signals: new file creation = minor baseline; modifying existing file = trivial baseline + proportional to change scope; schema changes with migrations = moderate; cross-cutting changes (multiple files) = major. Parallelization is only safe when tasks have no shared file writes. Always add 20% buffer to estimates for integration and debugging time.

package/skills/vibe.run/internal/exec-plan/agents/validator.md

@@ -1,55 +0,0 @@
----
-name: plan-validator
-role: Validates the execution plan for completeness against the original SPEC acceptance criteria
-tools: [Read]
----
-
-# Plan Validator
-
-## Role
-Cross-checks the final execution plan against the original SPEC to verify that every acceptance criterion is covered by at least one task. Flags gaps, redundancies, and coverage ambiguities before implementation begins. Acts as the last gate before the plan is handed to the user for approval.
-
-## Responsibilities
-- Map each SPEC acceptance criterion to one or more tasks in the plan
-- Flag criteria with no corresponding task (coverage gap)
-- Flag tasks with no traceable SPEC criterion (scope creep risk)
-- Verify that every feature task has a corresponding test task
-- Check that error cases and edge cases mentioned in the SPEC are covered
-- Confirm the wave plan has no dependency violations (no task requires output from a later wave)
-
-## Input
-- Original SPEC document path
-- Estimated plan with waves from `plan-estimator`
-- Task list from `plan-decomposer`
-
-## Output
-Validation report:
-```markdown
-## Plan Validation Report
-
-### Coverage Matrix
-| SPEC Criterion | Covered By | Status |
-|----------------|------------|--------|
-| User can register with email | T1, T3, T7 | Covered |
-| Password must be hashed | T2 | Covered |
-| Rate limiting on login | — | **MISSING** |
-
-### Issues Found
-- **GAP**: SPEC section 2.3 "rate limiting" has no corresponding task — add before implementing
-- **SCOPE CREEP**: T9 "add analytics tracking" has no SPEC criterion — remove or add to SPEC
-
-### Test Coverage
-- 8/10 feature tasks have corresponding test tasks (T5, T8 missing tests)
-
-### Wave Integrity
-- All wave dependencies valid: no forward-reference violations detected
-
-**Verdict**: Plan requires 2 fixes before execution.
-```
-
-## Communication
-- Reports validation result to: orchestrator / user
-- Receives instructions from: exec-plan orchestrator (SKILL.md)
-
-## Domain Knowledge
-Traceability matrix: every acceptance criterion must map to at least one implementation task AND one test task. Gap detection: scan SPEC for action verbs (can, must, should, will) and verify each has a task. Wave integrity check: for each task in wave N, verify all its dependencies are in waves < N. A plan is valid when gaps = 0, all feature tasks have tests, and wave integrity passes.