@tekyzinc/gsd-t 2.45.11 → 2.50.10

package/templates/CLAUDE-global.md

@@ -49,6 +49,7 @@ PROJECT or FEATURE or SCAN
 | `/user:gsd-t-execute` | Run tasks — task-level fresh dispatch, worktree isolation, adaptive replanning, active rule injection |
 | `/user:gsd-t-test-sync` | Keep tests aligned with code changes |
 | `/user:gsd-t-qa` | QA agent — test generation, execution, gap reporting |
+| `/user:gsd-t-doc-ripple` | Automated document ripple — update downstream docs after code changes |
 | `/user:gsd-t-integrate` | Wire domains together |
 | `/user:gsd-t-verify` | Run quality gates + goal-backward behavior verification |
 | `/user:gsd-t-complete-milestone` | Archive milestone + git tag (goal-backward gate, rule engine distillation) |
@@ -250,6 +251,32 @@ BEFORE reporting "tests pass" for ANY task:
 
 The conditional "if UI/routes/flows changed" in command files applies to **writing new E2E specs**, not to **running existing ones**. You always run existing E2E specs. Always.
 
+### E2E Test Quality Standard (MANDATORY)
+
+**E2E tests must be FUNCTIONAL tests, not LAYOUT tests.** This is non-negotiable.
+
+A layout test checks that elements exist (`isVisible`, `toBeAttached`, `toBeEnabled`, `toHaveCount`). A functional test checks that features work — actions produce correct outcomes.
+
+```
+LAYOUT TEST (WRONG — passes even if every feature is broken):
+  await expect(page.locator('#tab-sessions')).toBeVisible();
+  await page.click('#tab-sessions');
+  // ← No assertion that the tab's content actually loaded
+
+FUNCTIONAL TEST (RIGHT — fails if the feature is broken):
+  await page.click('#tab-sessions');
+  await expect(page.locator('.session-list')).toContainText('Session 1');
+  // ← Proves clicking the tab loaded the session data
+```
+
+Every Playwright assertion must verify one of:
+- **State changed**: After click/type/submit, the app state is different (new content, updated data, changed status)
+- **Data flowed**: User input → API call → response rendered (use `page.waitForResponse` or assert on rendered data)
+- **Content loaded**: Navigation/tab switch → destination content appeared (assert on text/data unique to destination)
+- **Widget responded**: Terminal accepted keystrokes and produced output, editor saved changes, form submitted and data persisted
+
+**If a test would pass on an empty HTML page with the correct element IDs and no JavaScript, it is not a functional test.** Rewrite it.
+
 ## QA Agent (Mandatory)
 
 Any GSD-T phase that produces or validates code **MUST run QA**. The QA agent's sole job is test generation, execution, and gap reporting. It never writes feature code.
@@ -269,10 +296,15 @@ a. Unit tests (vitest/jest/mocha): run the full suite
 b. E2E tests: check for playwright.config.* or cypress.config.* — if found, run the FULL E2E suite
 c. NEVER skip E2E when a config file exists. Running only unit tests is a QA FAILURE.
 d. Read .gsd-t/contracts/ for contract definitions. Check contract compliance.
-Report format: 'Unit: X/Y pass | E2E: X/Y pass (or N/A if no config) | Contract: compliant/violations'"
+e. AUDIT E2E test quality: Review each Playwright spec — if any test only checks element
+   existence (isVisible, toBeAttached, toBeEnabled) without verifying functional behavior
+   (state changes, data loaded, content updated after user actions), flag it as
+   'SHALLOW TEST — needs functional assertions'. A passing test suite that doesn't catch
+   broken features is a QA FAILURE.
+Report format: 'Unit: X/Y pass | E2E: X/Y pass (or N/A if no config) | Contract: compliant/violations | Shallow tests: N'"
 ```
 
-**QA failure blocks phase completion.** Lead cannot proceed until QA reports PASS or user explicitly overrides.
+**QA failure OR shallow tests found blocks phase completion.** Lead cannot proceed until QA reports PASS with zero shallow tests, or user explicitly overrides.
 
 ## Model Display (MANDATORY)
 
@@ -307,7 +339,7 @@ This applies during: `gsd-t-execute`, `gsd-t-quick`, `gsd-t-integrate`, `gsd-t-w
 
 ## Prime Rule
 KEEP GOING. Only stop for:
-1. Unrecoverable errors after 2 fix attempts
+1. Unrecoverable errors after 2 fix attempts (delegate to `gsd-t headless --debug-loop` first — only stop if exit code 4)
 2. Ambiguity that fundamentally changes project direction
 3. Milestone completion (checkpoint for user review)
 4. Destructive actions (see Destructive Action Guard above — ALWAYS stop)
@@ -361,6 +393,35 @@ BEFORE EVERY COMMIT:
 
 If ANY answer is YES and the doc is NOT updated, update it BEFORE committing. No exceptions.
 
+## Document Ripple Completion Gate (MANDATORY)
+
+**NEVER report a task as "done" or present a summary until ALL downstream documents are updated.** This is not optional.
+
+When a change affects multiple files (e.g., a new standard that applies across command files, a renamed API, a new convention), you MUST:
+
+1. **Identify the full blast radius BEFORE starting**: List every file that needs the change
+2. **Complete ALL updates in one pass**: Do not update 3 of 8 files and then present a summary
+3. **Run the Pre-Commit Gate on the COMPLETE changeset**: Not on a partial subset
+4. **Only THEN report completion**
+
+```
+BEFORE reporting "done" or presenting a summary:
+  ├── Did this change establish a new standard, rule, or convention?
+  │     YES → Grep for every file that should enforce it. Update ALL of them.
+  ├── Did this change modify a pattern used in multiple command files?
+  │     YES → Find and update EVERY command file that uses that pattern.
+  ├── Did this change affect a template (CLAUDE-global, CLAUDE-project, etc.)?
+  │     YES → The template AND the live equivalent (~/.claude/CLAUDE.md) must match.
+  ├── Did this change add a new requirement?
+  │     YES → Add to docs/requirements.md in the same pass.
+  ├── Have I checked EVERY file in the blast radius?
+  │     NO → Keep going. Do not present partial work.
+  └── Am I about to say "want me to also update X?" or "should I check Y?"
+        YES → STOP. Just update X and check Y. Then report done.
+```
+
+**The test for this gate**: If the user asks "did you update all the documents?" and the answer would be "no, I missed some" — you failed this gate. The user should never need to ask.
+
 ## Execution Behavior
 - ALWAYS check docs/architecture.md before adding or modifying components.
 - ALWAYS check docs/workflows.md before changing any multi-step process.
@@ -370,7 +431,7 @@ If ANY answer is YES and the doc is NOT updated, update it BEFORE committing. No
 - NEVER pause to show verification steps — execute them.
 - NEVER ask "should I continue?" — just continue.
 - NEVER summarize what you're "about to do" — just do it.
-- IF a test fails, fix it immediately (up to 2 attempts) before reporting.
+- IF a test fails, fix it immediately (up to 2 attempts) before reporting. If both attempts fail, delegate to `gsd-t headless --debug-loop` before stopping.
 
 ## Autonomy Levels
 
@@ -522,6 +583,23 @@ Also pad all cell values in a column to the width of the widest value:
 ```
 
 
+## Stack Rules Engine
+
+GSD-T auto-detects project tech stack at subagent spawn time and injects mandatory best-practice rules into the subagent prompt.
+
+**Detection sources**: `package.json` (React, TypeScript, Node API), `requirements.txt`/`pyproject.toml` (Python), `go.mod` (Go), `Cargo.toml` (Rust).
+
+**Universal rules**: Templates prefixed with `_` (e.g., `_security.md`) are **always** injected, regardless of stack.
+
+**Stack-specific rules**: Injected only when the matching stack is detected (e.g., `react.md` when `"react"` is in `package.json`).
+
+**Enforcement**: Stack rule violations have the same weight as contract violations — they are task failures, not warnings.
+
+**Extensible**: Drop a `.md` file into `templates/stacks/` in the GSD-T package to add rules for a new stack. If the directory is missing, detection skips silently.
+
+**Commands that inject stack rules**: `gsd-t-execute`, `gsd-t-quick`, `gsd-t-integrate`, `gsd-t-wave`, `gsd-t-debug`.
+
+
 # Recovery After Interruption
 
 When resuming work (new session or after /clear):

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