thachvd-kit 1.0.28 → 1.0.30

package/.agent/skills/testing-patterns/scripts/test_runner.py

@@ -1,219 +0,0 @@
-#!/usr/bin/env python3
-"""
-Test Runner - Unified test execution and coverage reporting
-Runs tests and generates coverage report based on project type.
-
-Usage:
-    python test_runner.py <project_path> [--coverage]
-
-Supports:
-    - Node.js: npm test, jest, vitest
-    - Python: pytest, unittest
-"""
-
-import subprocess
-import sys
-import json
-from pathlib import Path
-from datetime import datetime
-
-# Fix Windows console encoding
-try:
-    sys.stdout.reconfigure(encoding='utf-8', errors='replace')
-except:
-    pass
-
-
-def detect_test_framework(project_path: Path) -> dict:
-    """Detect test framework and commands."""
-    result = {
-        "type": "unknown",
-        "framework": None,
-        "cmd": None,
-        "coverage_cmd": None
-    }
-    
-    # Node.js project
-    package_json = project_path / "package.json"
-    if package_json.exists():
-        result["type"] = "node"
-        try:
-            pkg = json.loads(package_json.read_text(encoding='utf-8'))
-            scripts = pkg.get("scripts", {})
-            deps = {**pkg.get("dependencies", {}), **pkg.get("devDependencies", {})}
-            
-            # Check for test script
-            if "test" in scripts:
-                result["framework"] = "npm test"
-                result["cmd"] = ["npm", "test"]
-                
-                # Try to detect specific framework for coverage
-                if "vitest" in deps:
-                    result["framework"] = "vitest"
-                    result["coverage_cmd"] = ["npx", "vitest", "run", "--coverage"]
-                elif "jest" in deps:
-                    result["framework"] = "jest"
-                    result["coverage_cmd"] = ["npx", "jest", "--coverage"]
-            elif "vitest" in deps:
-                result["framework"] = "vitest"
-                result["cmd"] = ["npx", "vitest", "run"]
-                result["coverage_cmd"] = ["npx", "vitest", "run", "--coverage"]
-            elif "jest" in deps:
-                result["framework"] = "jest"
-                result["cmd"] = ["npx", "jest"]
-                result["coverage_cmd"] = ["npx", "jest", "--coverage"]
-                
-        except:
-            pass
-    
-    # Python project
-    if (project_path / "pyproject.toml").exists() or (project_path / "requirements.txt").exists():
-        result["type"] = "python"
-        result["framework"] = "pytest"
-        result["cmd"] = ["python", "-m", "pytest", "-v"]
-        result["coverage_cmd"] = ["python", "-m", "pytest", "--cov", "--cov-report=term-missing"]
-    
-    return result
-
-
-def run_tests(cmd: list, cwd: Path) -> dict:
-    """Run tests and return results."""
-    result = {
-        "passed": False,
-        "output": "",
-        "error": "",
-        "tests_run": 0,
-        "tests_passed": 0,
-        "tests_failed": 0
-    }
-    
-    try:
-        proc = subprocess.run(
-            cmd,
-            cwd=str(cwd),
-            capture_output=True,
-            text=True,
-            encoding='utf-8',
-            errors='replace',
-            timeout=300  # 5 min timeout for tests
-        )
-        
-        result["output"] = proc.stdout[:3000] if proc.stdout else ""
-        result["error"] = proc.stderr[:500] if proc.stderr else ""
-        result["passed"] = proc.returncode == 0
-        
-        # Try to parse test counts from output
-        output = proc.stdout or ""
-        
-        # Jest/Vitest pattern: "Tests: X passed, Y failed, Z total"
-        if "passed" in output.lower() and "failed" in output.lower():
-            import re
-            match = re.search(r'(\d+)\s+passed', output, re.IGNORECASE)
-            if match:
-                result["tests_passed"] = int(match.group(1))
-            match = re.search(r'(\d+)\s+failed', output, re.IGNORECASE)
-            if match:
-                result["tests_failed"] = int(match.group(1))
-            result["tests_run"] = result["tests_passed"] + result["tests_failed"]
-        
-        # Pytest pattern: "X passed, Y failed"
-        if "pytest" in str(cmd):
-            import re
-            match = re.search(r'(\d+)\s+passed', output)
-            if match:
-                result["tests_passed"] = int(match.group(1))
-            match = re.search(r'(\d+)\s+failed', output)
-            if match:
-                result["tests_failed"] = int(match.group(1))
-            result["tests_run"] = result["tests_passed"] + result["tests_failed"]
-        
-    except FileNotFoundError:
-        result["error"] = f"Command not found: {cmd[0]}"
-    except subprocess.TimeoutExpired:
-        result["error"] = "Timeout after 300s"
-    except Exception as e:
-        result["error"] = str(e)
-    
-    return result
-
-
-def main():
-    project_path = Path(sys.argv[1] if len(sys.argv) > 1 else ".").resolve()
-    with_coverage = "--coverage" in sys.argv
-    
-    print(f"\n{'='*60}")
-    print(f"[TEST RUNNER] Unified Test Execution")
-    print(f"{'='*60}")
-    print(f"Project: {project_path}")
-    print(f"Coverage: {'enabled' if with_coverage else 'disabled'}")
-    print(f"Time: {datetime.now().strftime('%Y-%m-%d %H:%M:%S')}")
-    
-    # Detect test framework
-    test_info = detect_test_framework(project_path)
-    print(f"Type: {test_info['type']}")
-    print(f"Framework: {test_info['framework']}")
-    print("-"*60)
-    
-    if not test_info["cmd"]:
-        print("No test framework found for this project.")
-        output = {
-            "script": "test_runner",
-            "project": str(project_path),
-            "type": test_info["type"],
-            "framework": None,
-            "passed": True,
-            "message": "No tests configured"
-        }
-        print(json.dumps(output, indent=2))
-        sys.exit(0)
-    
-    # Choose command
-    cmd = test_info["coverage_cmd"] if with_coverage and test_info["coverage_cmd"] else test_info["cmd"]
-    
-    print(f"Running: {' '.join(cmd)}")
-    print("-"*60)
-    
-    # Run tests
-    result = run_tests(cmd, project_path)
-    
-    # Print output (truncated)
-    if result["output"]:
-        lines = result["output"].split("\n")
-        for line in lines[:30]:
-            print(line)
-        if len(lines) > 30:
-            print(f"... ({len(lines) - 30} more lines)")
-    
-    # Summary
-    print("\n" + "="*60)
-    print("SUMMARY")
-    print("="*60)
-    
-    if result["passed"]:
-        print("[PASS] All tests passed")
-    else:
-        print("[FAIL] Some tests failed")
-        if result["error"]:
-            print(f"Error: {result['error'][:200]}")
-    
-    if result["tests_run"] > 0:
-        print(f"Tests: {result['tests_run']} total, {result['tests_passed']} passed, {result['tests_failed']} failed")
-    
-    output = {
-        "script": "test_runner",
-        "project": str(project_path),
-        "type": test_info["type"],
-        "framework": test_info["framework"],
-        "tests_run": result["tests_run"],
-        "tests_passed": result["tests_passed"],
-        "tests_failed": result["tests_failed"],
-        "passed": result["passed"]
-    }
-    
-    print("\n" + json.dumps(output, indent=2))
-    
-    sys.exit(0 if result["passed"] else 1)
-
-
-if __name__ == "__main__":
-    main()

package/.agent/skills/using-git-worktrees/SKILL.md

@@ -1,121 +0,0 @@
----
-name: using-git-worktrees
-description: Use when starting feature work that needs isolation from current workspace or before executing implementation plans — creates isolated git worktrees with smart directory selection and safety verification
-allowed-tools: Bash, Read
----
-
-# Using Git Worktrees
-
-## Overview
-
-Git worktrees create isolated workspaces sharing the same repository, allowing work on multiple branches simultaneously without switching.
-
-**Core principle:** Systematic directory selection + safety verification = reliable isolation.
-
-**Announce at start:** "I'm using the using-git-worktrees skill to set up an isolated workspace."
-
-## Directory Selection Process
-
-Follow this priority order:
-
-### 1. Check Existing Directories
-
-```bash
-ls -d .worktrees 2>/dev/null     # Preferred (hidden)
-ls -d worktrees 2>/dev/null      # Alternative
-```
-
-**If found:** Use that directory. If both exist, `.worktrees` wins.
-
-### 2. Check CLAUDE.md / GEMINI.md / .cursorrules
-
-```bash
-grep -i "worktree.*director" CLAUDE.md GEMINI.md .cursorrules 2>/dev/null
-```
-
-**If preference specified:** Use it without asking.
-
-### 3. Ask User
-
-If no directory exists and no config preference:
-
-```
-No worktree directory found. Where should I create worktrees?
-
-1. .worktrees/ (project-local, hidden)
-2. ~/.config/worktrees/<project-name>/ (global location)
-
-Which would you prefer?
-```
-
-## Creation Steps
-
-### 1. Detect Project Name
-
-```bash
-project=$(basename "$(git rev-parse --show-toplevel)")
-```
-
-### 2. Create Worktree
-
-```bash
-git worktree add "$path" -b "$BRANCH_NAME"
-cd "$path"
-```
-
-### 3. Run Project Setup
-
-Auto-detect and run appropriate setup:
-
-```bash
-# Node.js
-if [ -f package.json ]; then npm install; fi
-
-# PHP / Laravel
-if [ -f composer.json ]; then composer install; fi
-
-# Python
-if [ -f requirements.txt ]; then pip install -r requirements.txt; fi
-if [ -f pyproject.toml ]; then poetry install; fi
-
-# Go
-if [ -f go.mod ]; then go mod download; fi
-
-# Rust
-if [ -f Cargo.toml ]; then cargo build; fi
-```
-
-### 4. Verify Clean Baseline
-
-```bash
-npm test           # Node
-php artisan test   # Laravel
-pytest             # Python
-go test ./...      # Go
-cargo test         # Rust
-```
-
-**If tests fail:** Report failures, ask whether to proceed or investigate.
-**If tests pass:** Continue.
-
-### 5. Report Location
-
-```
-Worktree ready at <full-path>
-Tests passing (<N> tests, 0 failures)
-Ready to implement <feature-name>
-```
-
-## Common Mistakes
-
-- **Skipping ignore verification** — Always check `.gitignore` includes `.worktrees/`
-- **Assuming directory location** — Always follow the priority selection process
-- **Proceeding with failing tests** — Always verify baseline before implementing
-- **Hardcoding setup commands** — Auto-detect from project files
-
-## Integration
-
-**Pairs with:**
-- `executing-plans` — Set up workspace before plan execution
-- `subagent-driven-development` — Isolated workspace for each feature
-- `finishing-a-development-branch` — Cleans up worktree after completion

package/.agent/skills/verification-before-completion/SKILL.md

@@ -1,99 +0,0 @@
----
-name: verification-before-completion
-description: Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always
-allowed-tools: Bash, Read
----
-
-# Verification Before Completion
-
-## Overview
-
-Claiming work is complete without verification is dishonesty, not efficiency.
-
-**Core principle:** Evidence before claims, always.
-
-## The Iron Law
-
-```
-NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
-```
-
-If you haven't run the verification command in this message, you cannot claim it passes.
-
-## The Gate Function
-
-```
-BEFORE claiming any status or expressing satisfaction:
-
-1. IDENTIFY: What command proves this claim?
-2. RUN: Execute the FULL command (fresh, complete)
-3. READ: Full output, check exit code, count failures
-4. VERIFY: Does output confirm the claim?
-   - If NO: State actual status with evidence
-   - If YES: State claim WITH evidence
-5. ONLY THEN: Make the claim
-
-Skip any step = lying, not verifying
-```
-
-## Common Failures
-
-| Claim | Requires | Not Sufficient |
-|-------|----------|----------------|
-| Tests pass | Test command output: 0 failures | Previous run, "should pass" |
-| Linter clean | Linter output: 0 errors | Partial check, extrapolation |
-| Build succeeds | Build command: exit 0 | Linter passing, logs look good |
-| Bug fixed | Test original symptom: passes | Code changed, assumed fixed |
-| Regression test works | Red-green cycle verified | Test passes once |
-| Agent completed | VCS diff shows changes | Agent reports "success" |
-| Requirements met | Line-by-line checklist | Tests passing |
-
-## Red Flags - STOP
-
-- Using "should", "probably", "seems to"
-- Expressing satisfaction before verification ("Great!", "Perfect!", "Done!", etc.)
-- About to commit/push/PR without verification
-- Trusting agent success reports
-- Relying on partial verification
-- **ANY wording implying success without having run verification**
-
-## Rationalization Prevention
-
-| Excuse | Reality |
-|--------|---------|
-| "Should work now" | RUN the verification |
-| "I'm confident" | Confidence ≠ evidence |
-| "Just this once" | No exceptions |
-| "Linter passed" | Linter ≠ compiler |
-| "Agent said success" | Verify independently |
-| "Partial check is enough" | Partial proves nothing |
-
-## Key Patterns
-
-**Tests:**
-```
-✅ [Run test command] [See: 34/34 pass] "All tests pass"
-❌ "Should pass now" / "Looks correct"
-```
-
-**Build:**
-```
-✅ [Run build] [See: exit 0] "Build passes"
-❌ "Linter passed" (linter doesn't check compilation)
-```
-
-**Requirements:**
-```
-✅ Re-read plan → Create checklist → Verify each → Report gaps or completion
-❌ "Tests pass, phase complete"
-```
-
-## When To Apply
-
-**ALWAYS before:**
-- ANY variation of success/completion claims
-- Committing, PR creation, task completion
-- Moving to next task
-- Delegating to agents
-
-**The Bottom Line:** Run the command. Read the output. THEN claim the result.

package/.agent/skills/vulnerability-scanner/SKILL.md

@@ -1,276 +0,0 @@
----
-name: vulnerability-scanner
-description: Advanced vulnerability analysis principles. OWASP 2025, Supply Chain Security, attack surface mapping, risk prioritization.
-allowed-tools: Read, Glob, Grep, Bash
----
-
-# Vulnerability Scanner
-
-> Think like an attacker, defend like an expert. 2025 threat landscape awareness.
-
-## 🔧 Runtime Scripts
-
-**Execute for automated validation:**
-
-| Script | Purpose | Usage |
-|--------|---------|-------|
-| `scripts/security_scan.py` | Validate security principles applied | `python scripts/security_scan.py <project_path>` |
-
-## 📋 Reference Files
-
-| File | Purpose |
-|------|---------|
-| [checklists.md](checklists.md) | OWASP Top 10, Auth, API, Data protection checklists |
-
----
-
-## 1. Security Expert Mindset
-
-### Core Principles
-
-| Principle | Application |
-|-----------|-------------|
-| **Assume Breach** | Design as if attacker already inside |
-| **Zero Trust** | Never trust, always verify |
-| **Defense in Depth** | Multiple layers, no single point |
-| **Least Privilege** | Minimum required access only |
-| **Fail Secure** | On error, deny access |
-
-### Threat Modeling Questions
-
-Before scanning, ask:
-1. What are we protecting? (Assets)
-2. Who would attack? (Threat actors)
-3. How would they attack? (Attack vectors)
-4. What's the impact? (Business risk)
-
----
-
-## 2. OWASP Top 10:2025
-
-### Risk Categories
-
-| Rank | Category | Think About |
-|------|----------|-------------|
-| **A01** | Broken Access Control | Who can access what? IDOR, SSRF |
-| **A02** | Security Misconfiguration | Defaults, headers, exposed services |
-| **A03** | Software Supply Chain 🆕 | Dependencies, CI/CD, build integrity |
-| **A04** | Cryptographic Failures | Weak crypto, exposed secrets |
-| **A05** | Injection | User input → system commands |
-| **A06** | Insecure Design | Flawed architecture |
-| **A07** | Authentication Failures | Session, credential management |
-| **A08** | Integrity Failures | Unsigned updates, tampered data |
-| **A09** | Logging & Alerting | Blind spots, no monitoring |
-| **A10** | Exceptional Conditions 🆕 | Error handling, fail-open states |
-
-### 2025 Key Changes
-
-```
-2021 → 2025 Shifts:
-├── SSRF merged into A01 (Access Control)
-├── A02 elevated (Cloud/Container configs)
-├── A03 NEW: Supply Chain (major focus)
-├── A10 NEW: Exceptional Conditions
-└── Focus shift: Root causes > Symptoms
-```
-
----
-
-## 3. Supply Chain Security (A03)
-
-### Attack Surface
-
-| Vector | Risk | Question to Ask |
-|--------|------|-----------------|
-| **Dependencies** | Malicious packages | Do we audit new deps? |
-| **Lock files** | Integrity attacks | Are they committed? |
-| **Build pipeline** | CI/CD compromise | Who can modify? |
-| **Registry** | Typosquatting | Verified sources? |
-
-### Defense Principles
-
-- Verify package integrity (checksums)
-- Pin versions, audit updates
-- Use private registries for critical deps
-- Sign and verify artifacts
-
----
-
-## 4. Attack Surface Mapping
-
-### What to Map
-
-| Category | Elements |
-|----------|----------|
-| **Entry Points** | APIs, forms, file uploads |
-| **Data Flows** | Input → Process → Output |
-| **Trust Boundaries** | Where auth/authz checked |
-| **Assets** | Secrets, PII, business data |
-
-### Prioritization Matrix
-
-```
-Risk = Likelihood × Impact
-
-High Impact + High Likelihood → CRITICAL
-High Impact + Low Likelihood  → HIGH
-Low Impact + High Likelihood  → MEDIUM
-Low Impact + Low Likelihood   → LOW
-```
-
----
-
-## 5. Risk Prioritization
-
-### CVSS + Context
-
-| Factor | Weight | Question |
-|--------|--------|----------|
-| **CVSS Score** | Base severity | How severe is the vuln? |
-| **EPSS Score** | Exploit likelihood | Is it being exploited? |
-| **Asset Value** | Business context | What's at risk? |
-| **Exposure** | Attack surface | Internet-facing? |
-
-### Prioritization Decision Tree
-
-```
-Is it actively exploited (EPSS >0.5)?
-├── YES → CRITICAL: Immediate action
-└── NO → Check CVSS
-         ├── CVSS ≥9.0 → HIGH
-         ├── CVSS 7.0-8.9 → Consider asset value
-         └── CVSS <7.0 → Schedule for later
-```
-
----
-
-## 6. Exceptional Conditions (A10 - New)
-
-### Fail-Open vs Fail-Closed
-
-| Scenario | Fail-Open (BAD) | Fail-Closed (GOOD) |
-|----------|-----------------|---------------------|
-| Auth error | Allow access | Deny access |
-| Parsing fails | Accept input | Reject input |
-| Timeout | Retry forever | Limit + abort |
-
-### What to Check
-
-- Exception handlers that catch-all and ignore
-- Missing error handling on security operations
-- Race conditions in auth/authz
-- Resource exhaustion scenarios
-
----
-
-## 7. Scanning Methodology
-
-### Phase-Based Approach
-
-```
-1. RECONNAISSANCE
-   └── Understand the target
-       ├── Technology stack
-       ├── Entry points
-       └── Data flows
-
-2. DISCOVERY
-   └── Identify potential issues
-       ├── Configuration review
-       ├── Dependency analysis
-       └── Code pattern search
-
-3. ANALYSIS
-   └── Validate and prioritize
-       ├── False positive elimination
-       ├── Risk scoring
-       └── Attack chain mapping
-
-4. REPORTING
-   └── Actionable findings
-       ├── Clear reproduction steps
-       ├── Business impact
-       └── Remediation guidance
-```
-
----
-
-## 8. Code Pattern Analysis
-
-### High-Risk Patterns
-
-| Pattern | Risk | Look For |
-|---------|------|----------|
-| **String concat in queries** | Injection | `"SELECT * FROM " + user_input` |
-| **Dynamic code execution** | RCE | `eval()`, `exec()`, `Function()` |
-| **Unsafe deserialization** | RCE | `pickle.loads()`, `unserialize()` |
-| **Path manipulation** | Traversal | User input in file paths |
-| **Disabled security** | Various | `verify=False`, `--insecure` |
-
-### Secret Patterns
-
-| Type | Indicators |
-|------|-----------|
-| API Keys | `api_key`, `apikey`, high entropy |
-| Tokens | `token`, `bearer`, `jwt` |
-| Credentials | `password`, `secret`, `key` |
-| Cloud | `AWS_`, `AZURE_`, `GCP_` prefixes |
-
----
-
-## 9. Cloud Security Considerations
-
-### Shared Responsibility
-
-| Layer | You Own | Provider Owns |
-|-------|---------|---------------|
-| Data | ✅ | ❌ |
-| Application | ✅ | ❌ |
-| OS/Runtime | Depends | Depends |
-| Infrastructure | ❌ | ✅ |
-
-### Cloud-Specific Checks
-
-- IAM: Least privilege applied?
-- Storage: Public buckets?
-- Network: Security groups tightened?
-- Secrets: Using secrets manager?
-
----
-
-## 10. Anti-Patterns
-
-| ❌ Don't | ✅ Do |
-|----------|-------|
-| Scan without understanding | Map attack surface first |
-| Alert on every CVE | Prioritize by exploitability + asset |
-| Ignore false positives | Maintain verified baseline |
-| Fix symptoms only | Address root causes |
-| Scan once before deploy | Continuous scanning |
-| Trust third-party deps blindly | Verify integrity, audit code |
-
----
-
-## 11. Reporting Principles
-
-### Finding Structure
-
-Each finding should answer:
-1. **What?** - Clear vulnerability description
-2. **Where?** - Exact location (file, line, endpoint)
-3. **Why?** - Root cause explanation
-4. **Impact?** - Business consequence
-5. **How to fix?** - Specific remediation
-
-### Severity Classification
-
-| Severity | Criteria |
-|----------|----------|
-| **Critical** | RCE, auth bypass, mass data exposure |
-| **High** | Data exposure, privilege escalation |
-| **Medium** | Limited scope, requires conditions |
-| **Low** | Informational, best practice |
-
----
-
-> **Remember:** Vulnerability scanning finds issues. Expert thinking prioritizes what matters. Always ask: "What would an attacker do with this?"