@tekyzinc/gsd-t 2.46.11 → 2.50.11

package/templates/stacks/_security.md

@@ -0,0 +1,243 @@
+# Security Standards (Universal — All Projects)
+
+These rules are MANDATORY. Violations fail the task. No exceptions.
+
+---
+
+## 1. Input Validation & Sanitization
+
+### All User Input
+- **Validate at system boundaries** — every value from users, external APIs, URL params, form fields, file uploads
+- **Whitelist, don't blacklist** — define what IS allowed, reject everything else
+- **Validate type, length, format, and range** before processing
+- **Trim and normalize** strings before validation (Unicode normalization, whitespace)
+
+### SQL Injection Prevention
+```
+MANDATORY:
+  ├── Use parameterized queries / prepared statements — ALWAYS
+  ├── Never concatenate user input into SQL strings
+  ├── ORM query builders are preferred over raw SQL
+  └── If raw SQL is unavoidable, use the ORM's parameterized escape
+```
+
+### Command Injection Prevention
+```
+MANDATORY:
+  ├── Never pass user input to shell commands (exec, spawn, system)
+  ├── If shell execution is unavoidable, use allowlisted commands only
+  ├── Use execFile (not exec) with explicit argument arrays
+  └── Never construct commands with string interpolation from user data
+```
+
+---
+
+## 2. Cross-Site Scripting (XSS)
+
+### Output Encoding
+- **Encode all dynamic output** before rendering in HTML, JavaScript, CSS, or URLs
+- **Context-aware encoding** — HTML entities in HTML, JS escaping in script tags, URL encoding in URLs
+- **Never trust data from any source** — even your own database (it may contain previously-injected content)
+
+### DOM Manipulation
+```
+MANDATORY:
+  ├── Never use innerHTML, outerHTML, or document.write with user data
+  ├── Use textContent or innerText for text insertion
+  ├── If HTML rendering is required, sanitize with DOMPurify first
+  │     ALLOWED_TAGS: ['p', 'br', 'strong', 'em', 'ul', 'ol', 'li', 'a', 'b', 'i', 'u']
+  │     ALLOWED_ATTR: ['href'] (on <a> only, with URL validation)
+  ├── React: never use dangerouslySetInnerHTML without DOMPurify
+  └── Vue: never use v-html without DOMPurify
+```
+
+### Content Security Policy
+- Set `Content-Security-Policy` headers on all responses
+- Minimum: `default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'`
+- Never allow `'unsafe-eval'` in production
+
+---
+
+## 3. Authentication & Session Management
+
+### Token Handling
+```
+MANDATORY:
+  ├── Never store auth tokens in localStorage or sessionStorage
+  │     (accessible to any XSS attack — game over)
+  ├── Use httpOnly, Secure, SameSite cookies for session tokens
+  ├── For SPAs: store tokens in memory (React Context, closure)
+  │     Accept that page refresh = re-authenticate
+  ├── Access tokens: short-lived (15 min max)
+  ├── Refresh tokens: httpOnly cookie only, rotate on use
+  └── Never include tokens in URLs or query parameters
+```
+
+### Password Handling
+- **Never store plaintext passwords** — use bcrypt, scrypt, or Argon2
+- **Minimum 12 character requirement** — no maximum length restriction
+- **Never log passwords** — not even hashed ones
+- **Rate limit login attempts** — 5 failures → progressive delay or lockout
+
+### Session Security
+- Regenerate session ID after authentication
+- Set session timeout (idle: 30 min, absolute: 8 hours)
+- Invalidate all sessions on password change
+
+---
+
+## 4. API Security
+
+### Request Validation
+```
+MANDATORY:
+  ├── Validate Content-Type header matches expected format
+  ├── Validate request body against a schema (Zod, Joi, JSON Schema)
+  ├── Reject requests with unexpected fields (additionalProperties: false)
+  ├── Set maximum request body size (default: 1MB)
+  └── Rate limit all endpoints (default: 100 req/min per IP for APIs)
+```
+
+### Response Security
+- Never include stack traces or internal error details in production responses
+- Use generic error messages for auth failures ("Invalid credentials" — don't reveal which field failed)
+- Set security headers on all responses:
+  - `X-Content-Type-Options: nosniff`
+  - `X-Frame-Options: DENY`
+  - `Strict-Transport-Security: max-age=31536000; includeSubDomains`
+  - `X-XSS-Protection: 0` (rely on CSP instead)
+
+### CORS
+- Never use `Access-Control-Allow-Origin: *` on authenticated endpoints
+- Whitelist specific origins
+- Never reflect the Origin header as the CORS origin without validation
+
+---
+
+## 5. Secrets Management
+
+```
+MANDATORY:
+  ├── Never hardcode secrets in source code (API keys, passwords, tokens)
+  ├── Never commit .env files with real secrets
+  ├── Use environment variables for all secrets
+  ├── Never log secrets — redact in all log outputs
+  ├── Never include secrets in frontend/client-side code
+  │     (all client code is visible to users)
+  ├── Never include secrets in error messages or stack traces
+  └── Rotate secrets regularly and on any suspected compromise
+```
+
+### .gitignore Requirements
+These files must ALWAYS be in `.gitignore`:
+- `.env`, `.env.local`, `.env.*.local`
+- `*.pem`, `*.key`, `*.cert`
+- `credentials.json`, `service-account.json`
+- `*.sqlite`, `*.db` (local databases)
+
+---
+
+## 6. AI-Specific Security (LLM / Prompt Injection)
+
+### Prompt Injection Prevention
+```
+MANDATORY when user input feeds into LLM calls:
+  ├── Never concatenate user input directly into system prompts
+  ├── Use structured message format: system message (trusted) + user message (untrusted)
+  ├── Validate and sanitize user input before including in any prompt
+  ├── Strip or escape control sequences (markdown, XML tags, instruction-like text)
+  ├── Set output length limits to prevent extraction attacks
+  ├── Log and monitor prompt inputs for injection attempts
+  └── Never allow user input to modify system instructions or tool definitions
+```
+
+### LLM Output Handling
+- **Never trust LLM output** — treat it as untrusted input
+- Validate LLM-generated code before execution
+- Sanitize LLM-generated HTML/markdown before rendering
+- Never execute LLM-suggested shell commands without validation
+- If LLM output feeds into database queries, use parameterized queries
+
+### Sensitive Data in Prompts
+- Never include PII, passwords, or API keys in LLM prompts
+- Redact sensitive fields before sending to external LLM APIs
+- Be aware that LLM API providers may log prompts — treat all prompt content as potentially logged
+
+---
+
+## 7. File Upload Security
+
+```
+MANDATORY when handling file uploads:
+  ├── Validate file type by content (magic bytes), not just extension
+  ├── Set maximum file size limits
+  ├── Generate random filenames — never use the original filename in storage
+  ├── Store uploads outside the web root
+  ├── Scan for malware before processing
+  ├── Never execute or interpret uploaded files
+  └── Set Content-Disposition: attachment on file downloads
+```
+
+---
+
+## 8. Dependency Security
+
+- **Audit dependencies regularly** — `npm audit`, `pip audit`, `go mod verify`
+- **Pin dependency versions** — use lockfiles (package-lock.json, poetry.lock)
+- **Never install packages from untrusted sources**
+- **Review dependency licenses** for compatibility
+- **Monitor for CVEs** in production dependencies
+
+---
+
+## 9. Logging & Error Handling
+
+### What to Log
+- Authentication events (login, logout, failed attempts)
+- Authorization failures (access denied)
+- Input validation failures
+- Application errors and exceptions
+- Security-relevant events (rate limiting, CORS rejections)
+
+### What NEVER to Log
+- Passwords (even hashed)
+- Session tokens or API keys
+- Full credit card numbers
+- Social security numbers or government IDs
+- Personal health information
+- Any data subject to PII regulations
+
+### Error Handling
+- Never expose stack traces to users in production
+- Use structured error responses with error codes
+- Log the full error server-side, return a sanitized version to the client
+- Never catch and swallow errors silently — log them at minimum
+
+---
+
+## 10. External Links
+
+```
+MANDATORY:
+  ├── All external links: target="_blank" rel="noopener noreferrer"
+  ├── Validate URLs before redirecting (prevent open redirect attacks)
+  ├── Never redirect to user-supplied URLs without validation
+  └── Whitelist allowed redirect domains
+```
+
+---
+
+## Pre-Commit Security Checklist
+
+Before committing code that handles user input, authentication, or external data:
+
+- [ ] No hardcoded secrets in source code
+- [ ] User input validated and sanitized at system boundaries
+- [ ] SQL queries use parameterized statements
+- [ ] No `innerHTML` / `dangerouslySetInnerHTML` without sanitization
+- [ ] Auth tokens not stored in localStorage
+- [ ] Error responses don't expose internal details
+- [ ] External links use `rel="noopener noreferrer"`
+- [ ] File uploads validated by content type and size
+- [ ] Sensitive data not logged
+- [ ] If LLM-integrated: prompt injection prevention in place

package/templates/stacks/desktop.ini

@@ -0,0 +1,2 @@
+[.ShellClassInfo]
+IconResource=C:\Program Files\Google\Drive File Stream\122.0.1.0\GoogleDriveFS.exe,27

package/templates/stacks/docker.md

@@ -0,0 +1,202 @@
+# Docker Standards
+
+These rules are MANDATORY. Violations fail the task. No exceptions.
+
+---
+
+## 1. Dockerfile — Multi-Stage Builds
+
+```
+MANDATORY:
+  ├── Use multi-stage builds — separate build and runtime stages
+  ├── Final stage uses a minimal base image (alpine, distroless, slim)
+  ├── NEVER install dev dependencies in the runtime stage
+  ├── Pin base image versions — NEVER use :latest
+  └── One service per container — not multiple processes
+```
+
+**BAD**
+```dockerfile
+FROM node:20
+COPY . .
+RUN npm install
+CMD ["node", "server.js"]
+```
+
+**GOOD**
+```dockerfile
+# Build stage
+FROM node:20-alpine AS builder
+WORKDIR /app
+COPY package*.json ./
+RUN npm ci --production=false
+COPY . .
+RUN npm run build
+
+# Runtime stage
+FROM node:20-alpine
+WORKDIR /app
+COPY --from=builder /app/dist ./dist
+COPY --from=builder /app/node_modules ./node_modules
+COPY package*.json ./
+USER node
+EXPOSE 3000
+CMD ["node", "dist/server.js"]
+```
+
+---
+
+## 2. Layer Optimization
+
+```
+MANDATORY:
+  ├── Copy package.json/lock files BEFORE source code — leverage layer cache
+  ├── Use .dockerignore to exclude node_modules, .git, .env, build artifacts
+  ├── Combine RUN commands where logical — each RUN creates a layer
+  ├── Clean up caches in the same RUN that creates them
+  └── Order instructions from least-changing to most-changing
+```
+
+**GOOD** `.dockerignore`:
+```
+node_modules
+.git
+.env*
+dist
+*.md
+.gsd-t
+```
+
+---
+
+## 3. Security
+
+```
+MANDATORY:
+  ├── Run as non-root user (USER node, USER nobody, or create a dedicated user)
+  ├── NEVER copy .env files into the image — use runtime env vars or secrets
+  ├── NEVER hardcode secrets, tokens, or passwords in Dockerfile
+  ├── Use COPY not ADD (ADD can auto-extract archives and fetch URLs — too implicit)
+  ├── Scan images for vulnerabilities (docker scout, trivy, snyk)
+  └── Set HEALTHCHECK instruction for production images
+```
+
+---
+
+## 4. Docker Compose
+
+```
+MANDATORY:
+  ├── Use compose.yaml (not docker-compose.yml — modern naming)
+  ├── Always specify depends_on with condition: service_healthy where possible
+  ├── Use named volumes for persistent data — NEVER bind-mount data directories in production
+  ├── Define networks explicitly — don't rely on the default bridge
+  ├── Environment variables via env_file — not inline in compose.yaml
+  └── Pin image versions in compose — no :latest
+```
+
+**GOOD**
+```yaml
+services:
+  api:
+    build:
+      context: .
+      dockerfile: Dockerfile
+    ports:
+      - "3000:3000"
+    env_file: .env
+    depends_on:
+      db:
+        condition: service_healthy
+    networks:
+      - app-network
+
+  db:
+    image: postgres:16-alpine
+    volumes:
+      - pgdata:/var/lib/postgresql/data
+    healthcheck:
+      test: ["CMD-SHELL", "pg_isready -U postgres"]
+      interval: 10s
+      timeout: 5s
+      retries: 5
+    networks:
+      - app-network
+
+volumes:
+  pgdata:
+
+networks:
+  app-network:
+```
+
+---
+
+## 5. Image Tagging
+
+```
+MANDATORY:
+  ├── Tag with semantic version: myapp:1.2.3
+  ├── Also tag with git SHA for traceability: myapp:abc1234
+  ├── Tag :latest only on the main/production branch
+  ├── NEVER push untagged images to a registry
+  └── Use consistent naming: {registry}/{org}/{app}:{tag}
+```
+
+---
+
+## 6. Development vs Production
+
+```
+MANDATORY:
+  ├── Use compose.override.yaml for dev-specific config (hot reload, debug ports)
+  ├── Dev: bind-mount source code for hot reload
+  ├── Prod: COPY built artifacts — no bind mounts
+  ├── Dev: include dev dependencies and debug tools
+  ├── Prod: production dependencies only, no source maps
+  └── NEVER use the dev image in production
+```
+
+---
+
+## 7. Health Checks
+
+```
+MANDATORY for production:
+  ├── HEALTHCHECK in Dockerfile for standalone containers
+  ├── healthcheck in compose for orchestrated services
+  ├── Check actual readiness (HTTP endpoint, DB connection) — not just process alive
+  ├── Reasonable intervals: 10-30s interval, 3-5 retries
+  └── Lightweight check — don't hit expensive endpoints
+```
+
+---
+
+## 8. Anti-Patterns
+
+```
+NEVER:
+  ├── :latest in production — pin versions
+  ├── Root user in containers — always USER non-root
+  ├── Secrets in build args or ENV — use runtime secrets
+  ├── ADD when COPY suffices
+  ├── Multiple services in one container — one process per container
+  ├── Ignoring .dockerignore — bloated images and leaked files
+  ├── apt-get install without cleanup in the same RUN
+  └── Bind-mounting host paths in production compose
+```
+
+---
+
+## Docker Verification Checklist
+
+- [ ] Multi-stage build with minimal runtime image
+- [ ] Base images pinned to specific versions
+- [ ] .dockerignore excludes node_modules, .git, .env
+- [ ] Runs as non-root user
+- [ ] No secrets in Dockerfile or build args
+- [ ] Layer cache optimized (package files before source)
+- [ ] HEALTHCHECK defined
+- [ ] Compose uses named volumes and explicit networks
+- [ ] Images tagged with version and git SHA
+- [ ] Dev and prod configs separated

package/templates/stacks/firebase.md

@@ -0,0 +1,166 @@
+# Firebase Standards
+
+These rules are MANDATORY. Violations fail the task. No exceptions.
+
+---
+
+## 1. Firestore Security Rules
+
+```
+MANDATORY:
+  ├── Default-deny: rules start with allow read, write: if false;
+  ├── Write granular rules per collection and operation (read, create, update, delete)
+  ├── Use request.auth.uid for user-scoped access — NEVER trust client-sent IDs
+  ├── Validate data shape in rules: request.resource.data.field is string
+  ├── Test rules with the Firebase Emulator before deploying
+  └── NEVER use allow read, write: if true in production
+```
+
+**GOOD**
+```
+rules_version = '2';
+service cloud.firestore {
+  match /databases/{database}/documents {
+    match /users/{userId} {
+      allow read: if request.auth != null && request.auth.uid == userId;
+      allow update: if request.auth != null && request.auth.uid == userId
+        && request.resource.data.keys().hasOnly(['displayName', 'avatar', 'updatedAt'])
+        && request.resource.data.displayName is string
+        && request.resource.data.displayName.size() <= 100;
+      allow create, delete: if false;
+    }
+  }
+}
+```
+
+---
+
+## 2. Firestore Data Modeling
+
+```
+MANDATORY:
+  ├── Denormalize for read performance — Firestore charges per read, not per field
+  ├── Subcollections for large or unbounded lists (messages, orders)
+  ├── Embedded objects for small, bounded data that's always read together
+  ├── Store document IDs as fields when needed for queries
+  ├── Use server timestamps: serverTimestamp() — not client Date.now()
+  └── NEVER create deeply nested subcollection hierarchies (max 2-3 levels)
+```
+
+**GOOD**
+```typescript
+// User document — embedded small data
+{
+  id: "user-123",
+  displayName: "Jane Doe",
+  email: "jane@example.com",
+  settings: { theme: "dark", notifications: true },  // embedded — always read together
+  createdAt: serverTimestamp(),
+}
+
+// Orders — subcollection (unbounded, queried separately)
+// /users/user-123/orders/{orderId}
+```
+
+---
+
+## 3. Cloud Functions
+
+```
+MANDATORY:
+  ├── Use v2 functions (onRequest, onCall, onDocumentWritten) — not v1
+  ├── Validate ALL inputs in onCall functions — they're public endpoints
+  ├── Set memory and timeout limits per function
+  ├── Use secrets manager for API keys — not environment config
+  ├── Idempotent design — functions may retry on failure
+  └── Keep functions focused — one responsibility per function
+```
+
+**GOOD**
+```typescript
+import { onCall, HttpsError } from 'firebase-functions/v2/https';
+import { z } from 'zod';
+
+const schema = z.object({ orderId: z.string().uuid() });
+
+export const cancelOrder = onCall({ memory: '256MiB', timeoutSeconds: 30 }, async (request) => {
+  if (!request.auth) throw new HttpsError('unauthenticated', 'Must be logged in');
+
+  const parsed = schema.safeParse(request.data);
+  if (!parsed.success) throw new HttpsError('invalid-argument', 'Invalid input');
+
+  await db.collection('orders').doc(parsed.data.orderId).update({ status: 'cancelled' });
+  return { success: true };
+});
+```
+
+---
+
+## 4. Authentication
+
+```
+MANDATORY:
+  ├── Use Firebase Auth — don't build custom auth alongside it
+  ├── Store additional user data in Firestore — not in Auth custom claims (limited to 1KB)
+  ├── Custom claims for roles/permissions only (admin, moderator)
+  ├── Handle auth state with onAuthStateChanged listener
+  ├── Sign out clears local state — don't leave stale data
+  └── NEVER store Firebase API keys as secrets — they're meant to be public (security rules protect data)
+```
+
+---
+
+## 5. Storage Rules
+
+```
+MANDATORY:
+  ├── Restrict uploads by file type and size in rules
+  ├── User-scoped paths: /users/{userId}/avatar — match in rules
+  ├── Validate content type: request.resource.contentType.matches('image/.*')
+  ├── Set max file size in rules: request.resource.size < 5 * 1024 * 1024
+  └── NEVER allow public write access to storage
+```
+
+---
+
+## 6. Emulator and Local Development
+
+```
+MANDATORY:
+  ├── Use Firebase Emulator Suite for local development
+  ├── Test security rules against the emulator before deploying
+  ├── Seed data via emulator import — not manual dashboard entry
+  ├── CI runs tests against emulators — not production
+  └── Never connect to production from local development
+```
+
+---
+
+## 7. Anti-Patterns
+
+```
+NEVER:
+  ├── allow read, write: if true in production rules
+  ├── Trusting client-sent user IDs — use request.auth.uid
+  ├── Deep subcollection nesting (4+ levels)
+  ├── Large documents (> 1MB) — split into subcollections
+  ├── Reading entire collections without query limits
+  ├── v1 Cloud Functions for new code — use v2
+  ├── Storing secrets in Firebase config — use Secret Manager
+  └── Testing against production — use emulators
+```
+
+---
+
+## Firebase Verification Checklist
+
+- [ ] Security rules default-deny with granular per-collection policies
+- [ ] request.auth.uid used for access control — no client IDs trusted
+- [ ] Data model optimized for reads (denormalized where appropriate)
+- [ ] Subcollections for unbounded lists
+- [ ] Cloud Functions v2 with input validation
+- [ ] Functions are idempotent
+- [ ] Storage rules restrict file type and size
+- [ ] All rules tested against emulator
+- [ ] serverTimestamp() used — not client timestamps
+- [ ] No allow read, write: if true in production