vaspera 2.9.2 → 2.10.1

package/skills/vaspera-deploy/SKILL.md

@@ -0,0 +1,152 @@
+---
+description: Run deployment verification and health checks (M9)
+argument-hint: "[deployment-url]"
+allowed-tools: Bash, Read, Write, Glob, Grep
+---
+
+Run deployment verification against a deployed app.
+
+## Steps
+
+1. **Validate deployment URL**
+   - Require deployment URL as argument
+   - Validate URL format
+
+2. **Detect deployment provider**
+   - Use `deploy_detect` MCP tool
+   - Check for Vercel, AWS, GCP, Railway, Render, Fly
+
+3. **Load deployment config**
+   - Look for `.vaspera/deploy.yaml`
+   - If not found, offer to generate sample config
+
+4. **Run health checks**
+   - Check configured health endpoints
+   - Default: `/`, `/api/health`
+   - Measure response times and status codes
+
+5. **Run smoke tests**
+   - Execute tests from config
+   - Check status codes, latency, response bodies
+
+6. **Analyze results**
+   - Calculate health score (0-100)
+   - Calculate smoke test score (0-100)
+   - Calculate overall deploy score
+
+7. **Present results**
+   ```
+   Deployment Verification Results
+   ================================
+   Provider: Vercel (detected)
+   URL: https://my-app.vercel.app
+
+   Health Checks:
+   ┌────────────────┬──────────┬──────────┬────────────┐
+   │ Endpoint       │ Status   │ Code     │ Time (ms)  │
+   ├────────────────┼──────────┼──────────┼────────────┤
+   │ /              │ ✅ healthy│ 200      │ 89         │
+   │ /api/health    │ ✅ healthy│ 200      │ 45         │
+   │ /api/data      │ ⚠️ degraded│ 200     │ 612        │
+   └────────────────┴──────────┴──────────┴────────────┘
+
+   Smoke Tests:
+   ┌────────────────────────┬──────────┬────────────┐
+   │ Test                   │ Status   │ Time (ms)  │
+   ├────────────────────────┼──────────┼────────────┤
+   │ Homepage loads         │ ✅ PASS  │ 89         │
+   │ API health check       │ ✅ PASS  │ 45         │
+   │ User can login         │ ❌ FAIL  │ 1200       │
+   └────────────────────────┴──────────┴────────────┘
+
+   Scores:
+   - Health: 87/100
+   - Smoke Tests: 67/100
+   - Overall: 77/100
+
+   Certification Level: 🟡 APPROVED
+   → Ship with monitoring
+   ```
+
+8. **Vercel-specific actions** (if Vercel detected)
+   - List recent deployments
+   - Promote preview to production
+   - Rollback to previous version
+
+## Config Format
+
+Config is defined in `.vaspera/deploy.yaml`:
+
+```yaml
+provider: vercel  # Optional, auto-detected
+
+healthEndpoints:
+  - /
+  - /api/health
+  - /api/ready
+
+smokeTests:
+  - name: "Homepage loads"
+    endpoint: "/"
+    method: GET
+    expectedStatus: 200
+
+  - name: "API health check"
+    endpoint: "/api/health"
+    method: GET
+    expectedStatus: 200
+    assertions:
+      - type: latency
+        operator: lt
+        value: 500
+
+  - name: "User can login"
+    endpoint: "/api/auth/login"
+    method: POST
+    expectedStatus: 200
+    body:
+      email: "test@example.com"
+      password: "testpass"
+
+canary:
+  enabled: true
+  trafficPercent: 10
+  duration: "10m"
+  thresholds:
+    errorRate: 0.01
+    p95Latency: 500
+  rollbackOnFailure: true
+
+rollback:
+  autoRollback: true
+  retainVersions: 5
+```
+
+## MCP Tools Used
+
+- `deploy_detect` — Detect deployment provider
+- `deploy_verify` — Full verification
+- `deploy_health` — Quick health check
+- `deploy_config_generate` — Create sample config
+- `deploy_vercel_list` — List Vercel deployments
+- `deploy_vercel_promote` — Promote to production
+- `deploy_vercel_rollback` — Rollback deployment
+
+## Vercel Integration
+
+Set `VERCEL_TOKEN` for full Vercel integration:
+```bash
+export VERCEL_TOKEN=your_token_here
+```
+
+Commands available with Vercel token:
+- List recent deployments
+- Promote preview to production
+- Rollback to previous version
+
+## Important
+
+- Always verify deployment URLs before promoting to production
+- Smoke tests hit the actual deployment — use test data
+- Canary analysis requires the app to be running for the duration
+- Rollbacks are immediate — verify the target deployment first

package/skills/vaspera-fix-critical/SKILL.md

@@ -0,0 +1,52 @@
+---
+description: Fix all CRITICAL severity security findings
+argument-hint: "[project-path: defaults to .]"
+allowed-tools: Read, Edit, Write, Bash, Grep, Glob
+---
+
+Remediate all CRITICAL severity findings with verification loop.
+
+## Steps
+
+1. **Load audit findings**
+   - Read latest from `.vaspera/audit/*.json` (most recent by timestamp)
+   - If no audit exists, run `/vaspera-audit` first
+   - Filter findings where `severity === "critical"`
+
+2. **Categorize critical findings**
+   Critical categories:
+   - Unhandled async/await (crashes)
+   - Missing auth checks (unauthorized access)
+   - Missing RLS policies (data leakage)
+   - Hardcoded secrets (credential exposure)
+   - Raw SQL injection (CWE-89)
+   - dangerouslySetInnerHTML (XSS, CWE-79)
+   - Publicly exposed endpoints
+   - Missing CORS configuration
+
+3. **For each finding**
+   - Show file location with context (3 lines before/after)
+   - Preview the fix (before/after diff)
+   - Apply fix:
+     - Auto-apply if pattern has `safeToAutoApply: true`
+     - Otherwise, confirm with user
+   - Run `npm run build` to verify no compile errors
+
+4. **Verification loop**
+   - After fixing a group of related findings, re-run the targeted scanner
+   - Example: after fixing gitleaks findings, run gitleaks again
+   - Confirm finding count decreased
+   - If new findings appear (regressions), flag immediately
+
+5. **Final report**
+   - N critical findings fixed
+   - M critical findings remaining (with reasons)
+   - Any regressions introduced
+   - Suggest `/vaspera-fix-high` as next step
+
+## Important
+
+- ALWAYS run `npm run build` after each fix to catch compile errors early
+- NEVER skip the verification loop — re-scan to confirm fixes worked
+- Stage changes but do NOT commit unless user requests
+- If a fix requires manual intervention, explain why and provide guidance

package/skills/vaspera-fix-high/SKILL.md

@@ -0,0 +1,81 @@
+---
+description: Fix HIGH severity findings in 4 rounds
+argument-hint: "[project-path: defaults to .]"
+allowed-tools: Read, Edit, Write, Bash, Grep, Glob
+---
+
+Remediate HIGH severity findings systematically in 4 rounds.
+
+## Steps
+
+1. **Load audit findings**
+   - Read latest from `.vaspera/audit/*.json`
+   - Filter findings where `severity === "high"`
+   - Group by category for round assignment
+
+2. **Round A: Input Validation**
+   Target findings related to:
+   - Missing Zod schemas
+   - Missing safeParse calls
+   - Missing 400 responses for invalid input
+   - Unvalidated user input
+   
+   For each:
+   - Add Zod schema if missing
+   - Replace direct access with safeParse
+   - Add proper error responses
+   - Run `npm run build` to verify
+
+3. **Round B: TypeScript Strictness**
+   Target findings related to:
+   - `any` type annotations
+   - Missing explicit return types
+   - Unsafe type assertions (`as unknown as T`)
+   
+   For each:
+   - Replace `any` with proper types or `unknown`
+   - Add explicit return types to functions
+   - Replace unsafe casts with type guards
+   - Run `npm run build` to verify
+
+4. **Round C: UI Resilience**
+   Target findings related to:
+   - Missing loading states
+   - Missing error states
+   - Missing empty states
+   - Missing cleanup for subscriptions/listeners
+   - Missing Error Boundaries
+   
+   For each:
+   - Add loading/error/empty state handling
+   - Add cleanup in useEffect return
+   - Wrap risky components in Error Boundaries
+   - Run `npm run build` to verify
+
+5. **Round D: API Hardening**
+   Target findings related to:
+   - Error response leaking internal details
+   - Missing revalidatePath calls
+   - Inconsistent response shapes
+   
+   For each:
+   - Sanitize error responses
+   - Add cache invalidation
+   - Standardize response format
+   - Run `npm run build` to verify
+
+6. **After each round**
+   - Commit with: `fix: resolve high-severity issues (round X)`
+   - Re-scan to verify finding count decreased
+   - Report progress: N fixed in round X
+
+7. **Final report**
+   - Total high findings fixed across all rounds
+   - Remaining high findings (if any)
+   - Suggest `/vaspera-fix-medium` as next step
+
+## Important
+
+- Complete each round fully before moving to next
+- Commit after each round for clean rollback if needed
+- If a fix is unclear, ask for guidance rather than guessing

package/skills/vaspera-fix-medium/SKILL.md

@@ -0,0 +1,56 @@
+---
+description: Fix MEDIUM severity findings
+argument-hint: "[project-path: defaults to .]"
+allowed-tools: Read, Edit, Write, Bash, Grep, Glob
+---
+
+Remediate MEDIUM severity findings in a single pass.
+
+## Steps
+
+1. **Load audit findings**
+   - Read latest from `.vaspera/audit/*.json`
+   - Filter findings where `severity === "medium"`
+
+2. **Categorize and fix**
+   Medium categories:
+   
+   **Code Quality**
+   - Missing test files → Add basic test coverage
+   - Code duplication → Extract shared utilities
+   - Components >300 lines → Split into smaller components
+   - Hardcoded strings → Extract to constants/i18n
+   
+   **Type Safety**
+   - Missing return types → Add explicit return types
+   - Implicit any (not explicit) → Add proper typing
+   
+   **Error Handling**
+   - No structured logging → Add logger calls
+   - Inconsistent error responses → Standardize format
+   - No error boundaries → Add React Error Boundaries
+   
+   **Architecture**
+   - Manual schema management → Add migration files
+   - Scattered Supabase clients → Centralize client creation
+
+3. **For each finding**
+   - Show context and proposed fix
+   - Apply fix with user confirmation
+   - Run `npm run build` to verify
+
+4. **Verification**
+   - After all fixes, re-run audit
+   - Confirm medium count decreased
+   - Flag any regressions
+
+5. **Final report**
+   - N medium findings fixed
+   - Remaining medium findings
+   - Suggest `/vaspera-add-tests` as next step
+
+## Important
+
+- Medium fixes are lower priority but improve maintainability
+- Some fixes may require architectural decisions — ask if unclear
+- Stage changes but do NOT commit unless user requests

package/skills/vaspera-fix-rls/SKILL.md

@@ -0,0 +1,85 @@
+---
+description: Generate and apply Supabase Row Level Security policies
+argument-hint: "[project-path: defaults to .]"
+allowed-tools: Read, Write, Bash, Grep, Glob
+---
+
+Generate RLS policies for Supabase tables to prevent unauthorized data access.
+
+## Steps
+
+1. **Discover tables**
+   - Scan `supabase/migrations/` for CREATE TABLE statements
+   - Scan seed files for table references
+   - Scan codebase for `supabase.from('table_name')` calls
+   - Build complete table inventory
+
+2. **Detect existing policies**
+   - Look for `CREATE POLICY` statements in migrations
+   - Look for `ALTER TABLE ... ENABLE ROW LEVEL SECURITY`
+   - Identify tables with RLS enabled vs disabled
+
+3. **Analyze access patterns**
+   For each `supabase.from()` call:
+   - What columns are selected?
+   - Is there a `.eq('user_id', ...)` filter?
+   - Is it in an authenticated context?
+   - Infer ownership column (usually `user_id` or `owner_id`)
+
+4. **Generate migration**
+   For tables missing RLS:
+   ```sql
+   -- Enable RLS
+   ALTER TABLE table_name ENABLE ROW LEVEL SECURITY;
+   
+   -- SELECT: users can only read their own rows
+   CREATE POLICY "Users can view own rows"
+     ON table_name FOR SELECT
+     USING (auth.uid() = user_id);
+   
+   -- INSERT: users can only insert with their user_id
+   CREATE POLICY "Users can insert own rows"
+     ON table_name FOR INSERT
+     WITH CHECK (auth.uid() = user_id);
+   
+   -- UPDATE: users can only update their own rows
+   CREATE POLICY "Users can update own rows"
+     ON table_name FOR UPDATE
+     USING (auth.uid() = user_id);
+   
+   -- DELETE: users can only delete their own rows
+   CREATE POLICY "Users can delete own rows"
+     ON table_name FOR DELETE
+     USING (auth.uid() = user_id);
+   ```
+
+5. **Write migration file**
+   - Create `supabase/migrations/{timestamp}_add_rls_policies.sql`
+   - Include all generated policies
+
+6. **Generate RLS-REPORT.md**
+   ```markdown
+   # RLS Policy Report
+   
+   ## Tables with RLS
+   | Table | SELECT | INSERT | UPDATE | DELETE |
+   |-------|--------|--------|--------|--------|
+   | users | ✅ | ✅ | ✅ | ✅ |
+   
+   ## Tables MISSING RLS (CRITICAL)
+   - orders (no policies, added in migration)
+   
+   ## Service Role Usage (review required)
+   - src/api/admin.ts:42 — uses service role key
+   ```
+
+7. **Optionally apply**
+   - If user confirms: `supabase db push`
+   - Otherwise: leave migration file for manual review
+
+## Important
+
+- RLS is the MOST IMPORTANT security control for multi-tenant Supabase apps
+- Missing RLS = any authenticated user can read ALL data
+- Service role key bypasses RLS — flag all usages for review
+- Always test policies locally before pushing to production

package/skills/vaspera-harden/SKILL.md

@@ -0,0 +1,102 @@
+---
+description: Run complete 6-phase hardening pipeline
+argument-hint: "[project-path: defaults to .]"
+allowed-tools: Read, Edit, Write, Bash, Grep, Glob
+---
+
+Execute the full hardening pipeline with verification at each phase.
+
+## Pipeline Overview
+
+```
+Phase 1: Audit      → Baseline assessment
+Phase 2: Fix Critical → Resolve all CRITICAL findings
+Phase 3: Fix High   → Resolve HIGH findings (4 rounds)
+Phase 4: Fix Medium → Resolve MEDIUM findings
+Phase 5: Add Tests  → Generate security tests
+Phase 6: Verify     → Before/after comparison
+```
+
+## Execution
+
+### Phase 1: Audit
+Run `/vaspera-audit` to establish baseline.
+- Record initial Production Readiness Score
+- Save finding counts by severity
+
+### Phase 2: Fix Critical
+Run `/vaspera-fix-critical`
+- Must resolve ALL critical findings before proceeding
+- Commit: `fix: resolve critical security issues`
+- **Gate**: If any critical remains, STOP and report
+
+### Phase 3: Fix High
+Run `/vaspera-fix-high`
+- 4 rounds: validation → types → UI → API
+- Commit after each round: `fix: resolve high-severity issues (round X)`
+- **Verification**: Re-scan after each round
+
+### Phase 4: Fix Medium
+Run `/vaspera-fix-medium`
+- Single pass through medium findings
+- Commit: `fix: resolve medium-severity issues`
+
+### Phase 5: Add Tests
+Run `/vaspera-add-tests`
+- Priority: API routes → data layer → UI → utilities
+- Commit: `test: add security tests for critical paths`
+- **Gate**: `npm test` must pass
+
+### Phase 6: Verify
+Run `/vaspera-verify`
+- Generate HARDENING-REPORT.md
+- Compare before/after scores
+- Flag any regressions
+
+## Pre-commit Gate
+
+Before each commit, verify:
+- [ ] `npm run build` passes (TypeScript)
+- [ ] `npm test` passes (all tests)
+- [ ] No new console.logs introduced
+- [ ] No commented code added
+- [ ] No circular imports
+
+## Failure Handling
+
+**Build fails**: Pause, report error, suggest fix
+**Tests fail**: Roll back phase changes, report
+**Regressions detected**: Flag prominently, pause for review
+
+## Final Report
+
+```markdown
+# Hardening Complete
+
+## Score Improvement
+Before: XX/100 (LEVEL)
+After: YY/100 (LEVEL)
+Delta: +ZZ points
+
+## Findings Resolved
+- Critical: X → 0
+- High: Y → N
+- Medium: Z → M
+
+## Commits Made
+1. fix: resolve critical security issues
+2. fix: resolve high-severity issues (round A)
+...
+
+## Next Steps
+- Review and merge PR
+- Deploy to staging
+- Run production certification
+```
+
+## Important
+
+- This is a LONG-RUNNING operation — may take 30+ minutes
+- Each phase commits independently for clean rollback
+- The pipeline can be resumed from any phase if interrupted
+- Do NOT push to remote unless user explicitly requests

package/skills/vaspera-help/SKILL.md

@@ -0,0 +1,61 @@
+---
+description: List all available Vaspera Hardening skills
+argument-hint: ""
+allowed-tools: Bash
+---
+
+Display the Vaspera Hardening skill menu.
+
+## Output
+
+```
+Vaspera Hardening Skills
+========================
+
+AUDIT & VERIFY
+  /vaspera-audit         Run security audit, write findings to .vaspera/audit/
+  /vaspera-verify        Compare before/after audit state, generate report
+  /vaspera-verify-e2e    Runtime verification (M7) - test app actually works
+
+FIX BY SEVERITY
+  /vaspera-fix-critical  Fix all CRITICAL severity findings
+  /vaspera-fix-high      Fix HIGH severity findings (4 rounds)
+  /vaspera-fix-medium    Fix MEDIUM severity findings
+
+SPECIALIZED
+  /vaspera-fix-rls       Generate Supabase RLS policies
+  /vaspera-add-tests     Generate security tests (priority order)
+
+ORCHESTRATION
+  /vaspera-harden        Full 6-phase hardening pipeline
+                         (audit → fix-critical → fix-high → fix-medium → add-tests → verify)
+
+RUNTIME & SCALE (M7-M8)
+  /vaspera-verify-e2e    Launch app, run golden paths, calculate runtime score
+  /vaspera-load-test     Run k6 load tests, detect bottlenecks, estimate capacity
+  /vaspera-certify       Full production readiness certification (all dimensions)
+
+DEPLOYMENT (M9)
+  /vaspera-deploy        Health checks, smoke tests, Vercel integration
+
+AI CODE VERIFICATION (M10)
+  /vaspera-ai-verify     Detect AI patterns, hallucinations, confidence scoring
+
+DISCOVERY
+  /vaspera-help          This menu
+
+MCP TOOLS (stateful operations)
+  hardening_dashboard    Portfolio view across all projects
+  certification_*        Stateful certification workflow
+  consensus_*            Multi-agent consensus calculation
+  runtime_*              Runtime verification (7 tools)
+  scale_*                Scale assessment (5 tools)
+  deploy_*               Deployment verification (7 tools)
+```
+
+## Usage Tips
+
+- Start with `/vaspera-audit` to get a baseline
+- Fix by severity: critical → high → medium
+- Run `/vaspera-verify` after fixes to confirm improvement
+- Use `/vaspera-harden` for the full automated pipeline