@paths.design/caws-cli 10.2.0 → 11.0.0

package/dist/templates/.cursor/hooks/validate-spec.sh

@@ -1,83 +0,0 @@
-#!/bin/bash
-# Cursor Hook: CAWS Spec Validation
-# 
-# Purpose: Validate working-spec.yaml when it's edited
-# Event: afterFileEdit
-# 
-# @author @darianrosebrook
-
-set -euo pipefail
-
-# Read input from Cursor
-INPUT=$(cat)
-
-# Extract file path from input
-FILE_PATH=$(echo "$INPUT" | jq -r '.file_path // ""')
-
-# Validate if any CAWS YAML file was edited (.caws/**/*.yaml or .caws/**/*.yml)
-if [[ "$FILE_PATH" == *".caws/"* ]] && ([[ "$FILE_PATH" == *.yaml ]] || [[ "$FILE_PATH" == *.yml ]]); then
-  echo "🔍 Validating CAWS spec file..." >&2
-
-  # First, validate YAML syntax
-  if command -v node >/dev/null 2>&1; then
-    # Check YAML syntax using Node.js
-    YAML_SYNTAX_VALID=$(node -e "
-      const yaml = require('js-yaml');
-      const fs = require('fs');
-      try {
-        const content = fs.readFileSync('$FILE_PATH', 'utf8');
-        yaml.load(content);
-        process.exit(0);
-      } catch (error) {
-        console.error('YAML syntax error:', error.message);
-        if (error.mark) {
-          console.error('Line:', error.mark.line + 1, 'Column:', error.mark.column + 1);
-        }
-        process.exit(1);
-      }
-    " 2>&1)
-
-    if [ $? -ne 0 ]; then
-      echo '{
-        "userMessage": "⚠️ YAML syntax error detected",
-        "agentMessage": "The spec file has invalid YAML syntax. Fix syntax errors before continuing.",
-        "suggestions": [
-          "Check indentation (YAML uses 2 spaces)",
-          "Ensure all array items use consistent format",
-          "Remove duplicate keys",
-          "Consider using '\''caws specs create <id>'\'' instead of manual creation"
-        ]
-      }' 2>/dev/null
-      exit 0
-    fi
-  fi
-
-  # Check if CAWS CLI is available for semantic validation
-  if command -v caws &> /dev/null; then
-    # Run CAWS validation with suggestions
-    if VALIDATION=$(caws validate "$FILE_PATH" --quiet 2>&1); then
-      echo '{"userMessage":"✅ CAWS spec validation passed","agentMessage":"Specification is valid and complete."}' 2>/dev/null
-    else
-      # Get suggestions for fixing the spec
-      SUGGESTIONS=$(caws validate "$FILE_PATH" --suggestions 2>/dev/null | head -5 | tr '\n' '; ' | sed 's/; $//' || echo "Run caws validate --suggestions for details")
-
-      echo '{
-        "userMessage": "⚠️ CAWS spec validation failed. Run: caws validate --suggestions",
-        "agentMessage": "The spec file has validation errors. Please review and fix before continuing.",
-        "suggestions": [
-          "Run caws validate --suggestions for detailed error messages",
-          "Check required fields: id, title, risk_tier, mode",
-          "Ensure acceptance criteria are properly defined",
-          "Verify scope boundaries are appropriate",
-          "Consider using '\''caws specs create <id>'\'' for proper structure"
-        ]
-      }' 2>/dev/null
-    fi
-  else
-    echo '{"userMessage":"⚠️ CAWS CLI not available for validation","agentMessage":"Install CAWS CLI for automatic spec validation: npm install -g @caws/cli"}' 2>/dev/null
-  fi
-fi
-
-# Allow the edit
-exit 0
-

package/dist/templates/.cursor/hooks.json

@@ -1,76 +0,0 @@
-{
-  "version": 1,
-  "hooks": {
-    "beforeShellExecution": [
-      {
-        "command": "./.cursor/hooks/block-dangerous.sh"
-      },
-      {
-        "command": "./.cursor/hooks/session-log.sh"
-      },
-      {
-        "command": "./.cursor/hooks/audit.sh"
-      }
-    ],
-    "beforeReadFile": [
-      {
-        "command": "./.cursor/hooks/scan-secrets.sh"
-      },
-      {
-        "command": "./.cursor/hooks/caws-scope-guard.sh"
-      },
-      {
-        "command": "./.cursor/hooks/session-log.sh"
-      }
-    ],
-    "afterFileEdit": [
-      {
-        "command": "./.cursor/hooks/format.sh"
-      },
-      {
-        "command": "./.cursor/hooks/naming-check.sh"
-      },
-      {
-        "command": "./.cursor/hooks/validate-spec.sh"
-      },
-      {
-        "command": "./.cursor/hooks/caws-quality-check.sh"
-      },
-      {
-        "command": "./.cursor/hooks/session-log.sh"
-      },
-      {
-        "command": "./.cursor/hooks/audit.sh"
-      }
-    ],
-    "beforeSubmitPrompt": [
-      {
-        "command": "./.cursor/hooks/caws-scope-guard.sh"
-      },
-      {
-        "command": "./.cursor/hooks/session-log.sh"
-      },
-      {
-        "command": "./.cursor/hooks/audit.sh"
-      }
-    ],
-    "afterAgentResponse": [
-      {
-        "command": "./.cursor/hooks/session-log.sh"
-      }
-    ],
-    "afterAgentThought": [
-      {
-        "command": "./.cursor/hooks/session-log.sh"
-      }
-    ],
-    "stop": [
-      {
-        "command": "./.cursor/hooks/session-log.sh"
-      },
-      {
-        "command": "./.cursor/hooks/audit.sh"
-      }
-    ]
-  }
-}

package/dist/templates/.cursor/rules/00-claims-verification.mdc

@@ -1,144 +0,0 @@
----
-description: Production readiness claims require rigorous verification - agents must prove, not assert
-globs:
-alwaysApply: true
----
-
-# Production Readiness Verification & Accountability
-
-## Core Principle
-
-**Never claim "production-ready", "production-grade", or similar unless ALL criteria below are met.** If any criterion is not satisfied, use these statuses instead:
-
-- ❌ **"In development"** - Active development with known issues
-- ❌ **"Partially implemented"** - Some features working, major gaps remain
-- ❌ **"Proof of concept"** - Core concept demonstrated, not production-viable
-
-## Mandatory Production Readiness Criteria
-
-Before claiming production readiness, **agents must verify ALL of these**:
-
-### ✅ Code Quality Gates
-
-- **Zero linting errors or warnings** (ESLint, TypeScript, etc.)
-- **Zero TypeScript compilation errors**
-- **All TODOs, PLACEHOLDERs, and MOCK DATA cleared from production code**
-- **No dead code or unused imports**
-- **Consistent code formatting** (Prettier/ESLint rules)
-
-### ✅ Testing & Quality Assurance
-
-- **Complete unit test coverage** (80%+ line coverage, 90%+ branch coverage)
-- **All unit tests passing** (no skipped tests in production code)
-- **Integration tests passing** (database, external APIs, end-to-end flows)
-- **Mutation testing** (70%+ score for critical components)
-- **Performance tests** meeting documented SLAs
-
-### ✅ Infrastructure & Persistence
-
-- **Actual database persistence implemented** (not just in-memory mocks)
-- **Database integration tests passing** with real database
-- **Migration scripts tested and working**
-- **Data consistency and rollback capabilities**
-- **Connection pooling and error handling**
-
-### ✅ Security & Reliability
-
-- **Security controls tested and validated** (authentication, authorization, input validation)
-- **No security scan violations** (SAST, dependency scanning)
-- **Circuit breakers and retry logic** for external dependencies
-- **Graceful degradation** under failure conditions
-- **Logging and monitoring** implemented
-
-### ✅ Documentation & Reality Alignment
-
-- **Documentation matches implementation reality** (no claims of features that don't exist)
-- **API documentation** current and accurate
-- **Deployment and operational docs** exist
-- **Architecture diagrams** reflect actual implementation
-- **README and changelogs** accurate
-
-## Accountability Measures for Coding Agents
-
-### Pre-Claim Verification Process
-
-1. **Run full test suite** - All tests pass locally
-2. **Run linters** - Zero errors/warnings
-3. **Run security scans** - No vulnerabilities
-4. **Check coverage reports** - Meet or exceed thresholds
-5. **Verify database operations** - Real persistence working
-6. **Test deployment pipeline** - CI/CD passes
-7. **Document verification evidence** - Include in PR/commit
-
-### Prohibited Claims
-
-**NEVER claim these without verification:**
-
-- "Production-ready" without all criteria met
-- "Enterprise-grade" without enterprise testing
-- "Battle-tested" without comprehensive testing
-- "Stable" with failing tests or linting errors
-- "Complete" with TODOs, placeholders, or mock data
-- "Secure" without security testing and scans
-
-### Evidence Requirements
-
-For any production readiness claim, provide:
-
-- Test execution results (screenshots/logs)
-- Coverage reports
-- Lint results
-- Security scan reports
-- Performance benchmarks
-- Database connectivity proofs
-- Deployment verification
-
-## Common Failure Patterns to Avoid
-
-### Implementation Gaps
-
-- Empty directories claiming "full implementation"
-- Mock functions in production code
-- TODO comments in core business logic
-- Placeholder implementations
-- Missing error handling
-
-### Testing Shortcuts
-
-- Skipping integration tests
-- Mocking database operations
-- Ignoring linting errors
-- Not testing error conditions
-- Fake test data instead of real fixtures
-
-### Documentation Lies
-
-- Claiming 100% coverage with 75% actual
-- Features documented but not implemented
-- APIs documented with wrong signatures
-- Missing breaking changes in changelogs
-
-### Infrastructure Pretending
-
-- In-memory storage claiming "persistence"
-- No-op security claiming "secure"
-- Console.log claiming "monitoring"
-- No circuit breakers claiming "resilient"
-
-## Verification Checklist
-
-Use this before any production claim:
-
-- [ ] `npm test` passes all tests
-- [ ] `npm run lint` shows zero errors
-- [ ] `npm run typecheck` passes
-- [ ] Database tests use real PostgreSQL/MySQL/etc.
-- [ ] Security tests validate actual controls
-- [ ] Performance tests meet SLAs
-- [ ] No TODO/PLACEHOLDER/MOCK_DATA in src/
-- [ ] Coverage reports show adequate thresholds
-- [ ] CI/CD pipeline passes
-- [ ] Deployment docs exist and are tested
-- [ ] Documentation matches code reality
-
-**If ANY box is unchecked, do not claim production readiness.**

package/dist/templates/.cursor/rules/01-working-style.mdc

@@ -1,50 +0,0 @@
----
-description: Default agent behavior, edit style, and risk limits
-globs:
-alwaysApply: true
----
-
-# Working Style & Risk Limits
-
-## Intent
-
-Prefer directly applying fixes over explaining. Explanations are secondary unless asked, or when a change is **risky** (see Risk Gate).
-
-## Edit Principles
-
-- **Small, bounded diffs.** Keep edits minimal, cohesive, and reviewable.
-- **Edit existing modules over forking.** Prefer refactor + rename to duplication.
-- **Preserve public behavior** unless the task explicitly requests behavioral change.
-
-## Ask-First Triggers (Risk Gate)
-
-Before editing, _ask with a Targeted Edit Plan_ if any are true:
-
-- Changes cross package boundaries or public APIs.
-- Requires deleting files or renaming public symbols.
-- Introduces a new dependency or build tool.
-- Affects security, persistence, auth, or infra.
-- Touches > 10 files or > 300 LOC.
-
-**Targeted Edit Plan (TEP)** must include:
-
-- Scope (files, symbols), risks, rollback notes.
-- Tests to run/update.
-- Acceptance checks (what passing looks like).
-
-## Diff Hygiene
-
-- Keep each commit focused on one intent.
-- Include brief rationale in the commit subject (≤72 chars).
-- Never bypass pre-commit hooks; `--no-verify` is **forbidden**.
-
-## When to Explain
-
-- On TEP prompts, on rejected edits, or when trade-offs are non-obvious.
-- Keep explanations concise and adjacent to the diff.
-
-## Acceptance (per PR)
-
-- Tests + lints pass locally.
-- No widened public API surface without TEP.
-- No dead code or duplicate modules introduced.