@valentia-ai-skills/framework 1.0.4 → 1.0.6

package/bin/cli.js

@@ -214,6 +214,71 @@ function getLocalSkills() {
   return skills;
 }
 
+// ── Email + OTP Verification ──
+
+async function requestOtpForEmail(emailInput) {
+  let email = emailInput;
+  let attempts = 0;
+
+  while (attempts < 2) {
+    if (!email || !email.includes("@")) {
+      console.log(c("red", "Invalid email."));
+      process.exit(1);
+    }
+
+    console.log(c("dim", "\nVerifying your email..."));
+
+    const response = await fetchJSON(SUPABASE_FUNCTION_URL, { email, action: "request_otp" });
+
+    if (response.error === "not_found") {
+      attempts++;
+      if (attempts >= 2) {
+        console.log(c("red", "\n✗ Email not recognized. Access denied."));
+        console.log(c("dim", "  Contact your Framework Admin to be added to the system.\n"));
+        process.exit(1);
+      }
+      console.log(c("yellow", "\n⚠ Email not found. Please check and try again.\n"));
+      email = await ask(`${c("bold", "Enter your work email:")} `);
+      continue;
+    }
+
+    if (response.error) {
+      throw new Error(response.error);
+    }
+
+    // OTP sent successfully
+    console.log(c("green", `\n✓ Found: ${response.user_name}`));
+    console.log(c("dim", `  A verification code has been sent to ${email}\n`));
+
+    return email;
+  }
+}
+
+async function verifyOtp(email) {
+  const otp = await ask(`${c("bold", "Enter the 6-digit code:")} `);
+
+  if (!otp || otp.length < 4) {
+    console.log(c("red", "Invalid code."));
+    process.exit(1);
+  }
+
+  console.log(c("dim", "\nVerifying code..."));
+
+  const response = await fetchJSON(SUPABASE_FUNCTION_URL, { email, otp, action: "verify_otp" });
+
+  if (response.error === "invalid_otp") {
+    console.log(c("red", "\n✗ Invalid verification code. Please run setup again."));
+    process.exit(1);
+  }
+
+  if (response.error) {
+    throw new Error(response.error);
+  }
+
+  console.log(c("green", "✓ Verified!\n"));
+  return response;
+}
+
 // ── Commands ──
 
 async function cmdSetup() {
@@ -229,37 +294,39 @@ async function cmdSetup() {
   }
 
   // 2. Ask for email
-  const email = await ask(`${c("bold", "Enter your work email:")} `);
-  if (!email || !email.includes("@")) {
-    console.log(c("red", "Invalid email. Please try again."));
-    process.exit(1);
-  }
-
-  // 3. Lookup team from Supabase
-  console.log(c("dim", "\nLooking up your team..."));
+  let email = await ask(`${c("bold", "Enter your work email:")} `);
 
-  let response;
   let skills;
   let teamName = null;
   let useRemote = true;
 
   try {
-    response = await fetchJSON(SUPABASE_FUNCTION_URL, { email });
+    // 3. Request OTP (with 1 retry for wrong email)
+    email = await requestOtpForEmail(email);
+
+    // 4. Verify OTP and get skills
+    const response = await verifyOtp(email);
 
     if (response.team) {
       teamName = response.team.name;
-      console.log(c("green", `\n✓ Team: ${teamName}`));
+      console.log(c("green", `✓ Team: ${teamName}`));
       if (response.user) {
         console.log(c("dim", `  Welcome, ${response.user.name} (${response.user.role})`));
       }
       if (response.team.stack_tags?.length) {
         console.log(c("dim", `  Stack: ${response.team.stack_tags.join(", ")}`));
       }
-    } else {
-      console.log(c("yellow", `\n⚠ ${response.message || "No team found for this email."}`));
+    } else if (response.message) {
+      console.log(c("yellow", `⚠ ${response.message}`));
     }
 
     skills = response.skills || [];
+
+    if (skills.length === 0) {
+      console.log(c("yellow", "\n⚠ No skills are enabled for your team. Contact your Team Lead."));
+      process.exit(1);
+    }
+
     console.log(`  ${c("bold", skills.length)} skill(s) to install\n`);
 
   } catch (err) {
@@ -275,7 +342,7 @@ async function cmdSetup() {
     process.exit(1);
   }
 
-  // 4. Install for each tool
+  // 5. Install for each tool
   for (const toolKey of tools) {
     const tool = TOOL_CONFIGS[toolKey];
     if (!tool) continue;
@@ -290,7 +357,7 @@ async function cmdSetup() {
     console.log("");
   }
 
-  // 5. Save config
+  // 6. Save config
   const config = {
     version: require(path.join(__dirname, "..", "package.json")).version,
     email,
@@ -302,7 +369,7 @@ async function cmdSetup() {
   };
   saveConfig(config);
 
-  // 6. Summary
+  // 7. Summary
   console.log(c("blue", "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"));
   console.log(c("green", "✅ Setup complete!"));
   console.log(`   ${skills.length} skills installed for ${tools.length} tool(s)`);
@@ -320,13 +387,18 @@ async function cmdUpdate() {
     process.exit(1);
   }
 
-  console.log(c("dim", `Updating for ${config.email}...`));
+  const email = config.email;
+  console.log(c("dim", `Updating for ${email}...`));
 
   let skills;
   let teamName = config.team;
 
   try {
-    const response = await fetchJSON(SUPABASE_FUNCTION_URL, { email: config.email });
+    // Request OTP for the saved email
+    await requestOtpForEmail(email);
+
+    // Verify OTP
+    const response = await verifyOtp(email);
     skills = response.skills || [];
     teamName = response.team?.name || config.team;
 

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@valentia-ai-skills/framework",
-  "version": "1.0.4",
-  "description": "AI development skills framework — centralized coding standards, security patterns, and SOPs for AI-assisted development. Works with Claude Code, Cursor, Copilot, Windsurf, and any AI coding tool.",
+  "version": "1.0.6",
+  "description": "AI development skills framework — centralized coding standards, security patterns, and SOPs for AI-assisted development. Works with Claude Code, Cursor, Copilot, Windsurf, and any AI coding tool.",
   "keywords": [
     "ai-skills",
     "claude-code",

package/skills/global/api-design/tests/test-prompts.md

@@ -1,25 +0,0 @@
-## Test 1: CRUD Endpoint Design
-**Prompt**: "Design the REST API endpoints for a blog post system with posts, comments, and tags"
-**Expected**:
-- Plural nouns: /posts, /comments, /tags
-- Proper nesting: /posts/:id/comments (max 2 levels)
-- All CRUD methods with correct status codes
-- Response envelope with data/error pattern
-- Pagination on list endpoints
-
-## Test 2: Error Handling
-**Prompt**: "Write the error handling middleware for an Express API that returns consistent error responses"
-**Expected**:
-- Error envelope: { error: { code, message, details } }
-- Correct status codes (400 for validation, 401 for auth, 404 for not found)
-- No stack traces or internal details exposed
-- Proper differentiation between 401 and 403
-
-## Test 3: Complex Query Endpoint
-**Prompt**: "Build a product search endpoint with filtering by price range, category, and rating, with sorting and pagination"
-**Expected**:
-- Query params: minPrice, maxPrice, category, minRating
-- Sort format: sort=price:asc
-- Offset pagination with page, pageSize, totalItems
-- Default and max page sizes enforced
-- Input validation on all query params

package/skills/global/code-standards/tests/test-prompts.md

@@ -1,26 +0,0 @@
-## Test 1: New Function Creation
-**Prompt**: "Write a function that fetches a user from the database by email, checks if they're active, and returns their profile with recent orders"
-**Expected**: 
-- Function named descriptively (e.g., `getUserProfileWithOrders`)
-- Parameters use camelCase
-- Boolean check uses `isActive` pattern
-- Error handling with context
-- Under 40 lines, early returns
-
-## Test 2: Refactoring Messy Code
-**Prompt**: "Refactor this: `function do_stuff(a, b, c, d, e, f) { try { if (a) { if (b) { if (c) { return process(d, e, f); } } } } catch(e) {} }`"
-**Expected**:
-- Renamed to descriptive name
-- Parameters grouped into options object (>4 params)
-- Nesting reduced via early returns
-- Error handling added (not swallowed)
-- camelCase naming
-
-## Test 3: File Organization
-**Prompt**: "Create a user registration module with validation, database save, email notification, and audit logging"
-**Expected**:
-- Split into multiple files (not one 500-line file)
-- kebab-case file names
-- Proper import ordering
-- Named exports
-- Each file has single responsibility

package/skills/global/deployment/SKILL.md

@@ -1,240 +0,0 @@
----
-name: deployment
-description: >
-  Organization-wide deployment standards for CI/CD pipelines, environment
-  management, release processes, and rollback procedures. Use this skill
-  whenever writing, reviewing, or discussing deployment configurations,
-  CI/CD pipelines, Docker files, environment promotion, feature flags,
-  release management, or rollback strategies. Triggers on: "deploy",
-  "deployment", "CI/CD", "pipeline", "GitHub Actions", "Docker", "Dockerfile",
-  "container", "Kubernetes", "k8s", "helm", "terraform", "release",
-  "rollback", "staging", "production", "environment", "feature flag",
-  "blue-green", "canary", "rolling update". Applies to all teams.
-version: "1.0.0"
-scope: global
-author: Framework Admin
-last_reviewed: 2026-03-19
----
-
-# Deployment Standards
-
-## Overview
-
-Consistent deployment practices ensure reliable, safe releases across all
-services. These standards cover CI/CD pipelines, environment management,
-containerization, and rollback procedures.
-
-## 1. Environment Promotion
-
-### Environment Ladder
-
-```
-Development → Staging → Production
-```
-
-| Environment | Purpose | Who Deploys | Auto/Manual |
-|-------------|---------|-------------|-------------|
-| Development | Feature testing, integration | Any developer | Auto on PR merge to dev |
-| Staging | Pre-production validation, QA | CI/CD pipeline | Auto on merge to main |
-| Production | Live users | CI/CD + manual approval | Manual gate after staging |
-
-### Rules
-- Code must pass through ALL environments in order — no skipping staging
-- Staging must mirror production configuration (same infra, same env vars pattern)
-- Production deployments require at least 1 manual approval
-- Exception: hotfix branches can fast-track with 2 approvals
-
-## 2. CI/CD Pipeline Structure
-
-### Required Pipeline Stages
-
-```yaml
-# Every service must implement these stages:
-
-stages:
-  # Stage 1: Quality Gates (runs on every PR)
-  - lint          # Code style, formatting
-  - typecheck     # TypeScript / mypy
-  - test:unit     # Unit tests with coverage
-  - security:scan # Dependency vulnerability scan
-  
-  # Stage 2: Build (runs on merge to main)
-  - build         # Compile, bundle, Docker build
-  - test:integration  # Integration tests against test DB
-  
-  # Stage 3: Deploy (runs after build succeeds)
-  - deploy:staging    # Auto-deploy to staging
-  - test:e2e          # E2E tests against staging
-  - deploy:production # Manual approval gate → production
-```
-
-### Rules
-- PRs cannot merge if any Stage 1 check fails
-- Build artifacts are created ONCE and promoted through environments
-- Never rebuild between staging and production — same artifact, different config
-- Pipeline must complete in under 15 minutes for Stage 1 (fast feedback)
-- Full pipeline (through staging E2E) under 30 minutes
-
-## 3. Containerization (Docker)
-
-### Dockerfile Standards
-
-```dockerfile
-# ── Stage 1: Dependencies ──
-FROM node:20-alpine AS deps
-WORKDIR /app
-COPY package.json package-lock.json ./
-RUN npm ci --production=false
-
-# ── Stage 2: Build ──
-FROM node:20-alpine AS build
-WORKDIR /app
-COPY --from=deps /app/node_modules ./node_modules
-COPY . .
-RUN npm run build
-RUN npm prune --production
-
-# ── Stage 3: Production ──
-FROM node:20-alpine AS production
-WORKDIR /app
-
-# Security: run as non-root
-RUN addgroup -g 1001 appgroup && \
-    adduser -u 1001 -G appgroup -D appuser
-USER appuser
-
-COPY --from=build /app/dist ./dist
-COPY --from=build /app/node_modules ./node_modules
-COPY --from=build /app/package.json ./
-
-EXPOSE 3000
-HEALTHCHECK --interval=30s --timeout=3s --start-period=10s \
-  CMD wget -qO- http://localhost:3000/health || exit 1
-
-CMD ["node", "dist/main.js"]
-```
-
-### Rules
-- Multi-stage builds always — keep production image minimal
-- Run as non-root user — never run as root in production
-- Include HEALTHCHECK in Dockerfile
-- Pin base image versions: `node:20.11-alpine` not `node:latest`
-- Use `.dockerignore` to exclude: node_modules, .git, .env, tests, docs
-- Production image should be under 200MB
-- No dev dependencies in production stage
-
-## 4. Environment Configuration
-
-### Config by Environment
-
-```
-# Pattern: same env var names, different values per environment
-DATABASE_URL=postgres://...    # different per environment
-LOG_LEVEL=debug                # development
-LOG_LEVEL=info                 # staging
-LOG_LEVEL=warn                 # production
-```
-
-### Rules
-- Same env var names across all environments
-- Secrets stored in secrets manager (not in CI/CD variables for production)
-- Environment-specific config via env vars, never via code branches
-- Every env var documented in README (see documentation skill)
-- Config validated at startup (see security-baseline skill)
-
-## 5. Release Strategy
-
-### Semantic Versioning
-```
-v{MAJOR}.{MINOR}.{PATCH}
-
-MAJOR: Breaking changes (API incompatibility)
-MINOR: New features (backward compatible)
-PATCH: Bug fixes (backward compatible)
-```
-
-### Release Process
-1. Merge to main → auto-deploy to staging
-2. QA validates on staging (manual or automated)
-3. Create GitHub Release with tag `v1.2.3`
-4. Release triggers production deployment (with manual approval gate)
-5. Monitor dashboards for 15 minutes post-deploy
-6. If issues: rollback immediately
-
-### Feature Flags
-For risky changes, use feature flags:
-
-```typescript
-// Feature flag pattern
-if (featureFlags.isEnabled("new-checkout-flow", { userId: user.id })) {
-  return newCheckoutFlow(order);
-} else {
-  return legacyCheckoutFlow(order);
-}
-```
-
-### Rules
-- Feature flags for any change affecting > 10% of users
-- Flags have an expiry date — clean up within 2 weeks of full rollout
-- Flag states stored in config service (not hardcoded)
-- Always have a kill switch that reverts to old behavior
-
-## 6. Rollback Procedures
-
-### Automated Rollback Triggers
-- Error rate > 5% for 2 minutes
-- p99 latency > 5s for 5 minutes
-- Health check failures on > 25% of instances
-
-### Manual Rollback Process
-```bash
-# Option 1: Revert to previous container image
-kubectl rollout undo deployment/my-service
-
-# Option 2: Deploy a specific known-good version
-kubectl set image deployment/my-service app=my-service:v1.2.2
-
-# Option 3: Disable via feature flag (fastest)
-# Toggle flag off in config service
-```
-
-### Rules
-- Every deployment must be rollback-ready before proceeding
-- Database migrations must be backward-compatible (new code works with old schema AND new schema)
-- Rollback should complete in under 5 minutes
-- Post-rollback: create incident ticket, investigate, fix forward
-- Never rollback database migrations in production — fix forward only
-
-## 7. Database Migration Safety
-
-### Safe Migration Patterns
-```
-✅ ADD a new column (nullable or with default)
-✅ ADD a new table
-✅ ADD a new index (CONCURRENTLY)
-✅ RENAME with a transition period (old name → alias → new name)
-
-❌ DROP a column (in same deploy as code change)
-❌ RENAME a column (without transition period)
-❌ CHANGE column type (without transition period)
-❌ ADD NOT NULL without default
-```
-
-### Two-Phase Migration Pattern
-For breaking schema changes:
-1. **Phase 1**: Deploy code that works with BOTH old and new schema. Run migration to add new structure.
-2. **Phase 2** (next release): Deploy code that uses only new schema. Remove old structure.
-
-## Checklist
-
-Before deploying:
-- [ ] All CI stages pass (lint, typecheck, unit tests, security scan)
-- [ ] Docker image is multi-stage, runs as non-root, under 200MB
-- [ ] Integration tests pass against staging
-- [ ] E2E tests pass against staging
-- [ ] Database migration is backward-compatible
-- [ ] Rollback plan documented and tested
-- [ ] Feature flags in place for risky changes
-- [ ] Monitoring dashboards ready for post-deploy observation
-- [ ] Manual approval obtained for production
-- [ ] Changelog updated

package/skills/global/deployment/tests/test-prompts.md

@@ -1,27 +0,0 @@
-## Test 1: Dockerfile Creation
-**Prompt**: "Write a Dockerfile for a Node.js Express API service with TypeScript compilation"
-**Expected**:
-- Multi-stage build (deps → build → production)
-- Non-root user
-- HEALTHCHECK instruction
-- Pinned base image version
-- Production-only dependencies in final stage
-- .dockerignore mentioned
-
-## Test 2: CI/CD Pipeline
-**Prompt**: "Set up a GitHub Actions workflow for a Python FastAPI service with linting, testing, Docker build, and deployment to staging"
-**Expected**:
-- Stages: lint → typecheck → test → build → deploy
-- Runs on PR and merge to main
-- Docker build with caching
-- Integration tests before deploy
-- Environment-specific secrets handling
-
-## Test 3: Database Migration Strategy
-**Prompt**: "I need to rename the 'username' column to 'display_name' in our users table. How do I do this safely?"
-**Expected**:
-- Two-phase migration approach
-- Phase 1: add display_name, backfill, deploy code that reads both
-- Phase 2: drop username column in next release
-- Never rename in a single deploy
-- Backward compatibility emphasized