forge-orkes 0.3.9 → 0.3.10

package/template/.claude/skills/reviewing/SKILL.md

@@ -1,26 +1,26 @@
 ---
 name: reviewing
-description: "Use after verifying passes to assess codebase health and catalog improvement opportunities. Combines security audit (10 categories), architecture audit (4 dimensions), and refactoring scan (6 categories) into a single review pass. This is the pre-completion gate — it answers 'is this healthy enough to ship, and what could be better?'"
+description: "Post-verification health gate. Runs security audit (10 categories), architecture audit (4 dimensions), and refactoring scan (6 categories) in parallel. Determines if the milestone can ship and catalogs improvement opportunities."
 ---
 
 # Reviewing: Health Audit + Refactoring Review
 
-You are the pre-completion gate. After `verifying` confirms the work delivers what was promised, you assess codebase health AND catalog improvement opportunities in a single review pass. Three parallel scans — security, architecture, and refactoring — produce a structured report that determines whether the milestone can complete.
+The pre-completion gate. After `verifying` confirms deliverables, assess codebase health and catalog improvements. Three parallel scans produce a structured report that gates milestone completion.
 
-## When to Trigger
+## Triggers
 
-- **Automatically** after `verifying` returns a PASSED verdict (Standard and Full tiers)
-- **On-demand** at any time via user request
+- **Auto:** after `verifying` returns PASSED (Standard/Full tiers)
+- **Manual:** on user request
 
-## Process Overview
+## Process
 
-1. Read project context (`.forge/project.yml`) to determine tech stack
-2. Scope the review — glob all source files, determine milestone diff
-3. Spawn three parallel subagents: Security Audit + Architecture Audit + Refactoring Scan
+1. Read project context from `.forge/project.yml`
+2. Scope the review — glob source files, determine milestone diff
+3. Spawn three parallel subagents: Security + Architecture + Refactoring
 4. Collect results, score per-category, determine overall status
 5. Write health report to `.forge/audits/milestone-{id}-health-report.md`
 6. Write accepted refactoring items to `.forge/refactor-backlog.yml`
-7. Route based on results: healthy → complete, critical issues → user decides
+7. Route: healthy → complete, critical → user decides
 
 ## Step 1: Read Context
 
@@ -31,15 +31,15 @@ Read: .forge/constitution.md → active architectural gates (if exists)
 Read: .forge/refactor-backlog.yml → existing backlog items (if any)
 ```
 
-Determine which security categories apply based on the tech stack. For example:
-- No database → SQL/NoSQL Injection is N/A
-- No frontend → XSS Prevention is N/A
-- No CI/CD config → Pipeline Security is N/A
+Skip inapplicable security categories based on tech stack:
+- No database → SQL/NoSQL Injection N/A
+- No frontend → XSS Prevention N/A
+- No CI/CD config → Pipeline Security N/A
 
-Determine the milestone's starting point for the git diff (for refactoring scan):
-- Check git log for the commit tagged or noted as the milestone start
-- If unavailable, use the first commit after the previous milestone's completion date
-- Fallback: ask the user for the starting commit or branch
+Determine the milestone's git diff starting point:
+- Check git log for the milestone start commit
+- Fallback: first commit after previous milestone's completion date
+- Last resort: ask the user
 
 ## Step 2: Scope the Review
 
@@ -49,55 +49,49 @@ Glob: **/*.env*, **/docker-compose*, **/.github/workflows/*
 Glob: **/next.config*, **/vite.config*, **/webpack.config*
 ```
 
-Also get the diff file list for the refactoring scan:
+Get diff file list for refactoring scan:
 ```
 git diff --name-only {milestone_start}..HEAD
 ```
 
-Present scope summary to user:
-*"Review scope: {N} source files, {N} config files, {N} files changed in this milestone. Scanning security (10 categories), architecture (4 dimensions), and refactoring opportunities (6 categories). This will take a moment."*
+Present scope summary:
+*"Review scope: {N} source files, {N} config files, {N} changed files. Scanning security (10), architecture (4), refactoring (6)."*
 
-Build explicit file lists for each subagent — pass file paths, not globs, so nothing is missed.
+Build explicit file lists for each subagent — pass paths, not globs.
 
 ## Step 3: Spawn Parallel Scans
 
-Spawn all three scans as fresh-context subagents. Each receives the explicit file list for their scope, the tech stack from `project.yml`, and their specific instructions below.
+Spawn all three as fresh-context subagents. Each receives: explicit file list, tech stack from `project.yml`, instructions below.
 
 ### Part 1: Security Audit (subagent)
 
-Spawn a security auditor agent with a fresh context window.
-
 **10 Security Categories:**
 
-| # | Category | What It Checks |
-|---|----------|---------------|
+| # | Category | Checks |
+|---|----------|--------|
 | 1 | Authentication & Authorization | Every endpoint has auth middleware; role checks before data access |
-| 2 | Data Scoping / Tenant Isolation | Queries scoped to correct user/tenant; no cross-tenant data leaks |
-| 3 | Input Validation | Request bodies/params validated before use in queries or logic |
-| 4 | Error Information Leakage | No stack traces, DB schemas, or internal details in API responses |
+| 2 | Data Scoping / Tenant Isolation | Queries scoped to correct user/tenant; no cross-tenant leaks |
+| 3 | Input Validation | Request bodies/params validated before use |
+| 4 | Error Information Leakage | No stack traces, DB schemas, or internals in API responses |
 | 5 | XSS Prevention | No unsanitized user content injected into DOM |
-| 6 | SQL/NoSQL Injection | All queries use parameterized placeholders, no string interpolation |
+| 6 | SQL/NoSQL Injection | All queries parameterized, no string interpolation |
 | 7 | Secrets Management | No hardcoded keys/tokens; `.env` in `.gitignore`; `process.env` usage |
 | 8 | CORS Policy | No wildcard `*` origins in production; appropriate method restrictions |
 | 9 | HTTP Security Headers | CSP, X-Frame-Options, HSTS, X-Content-Type-Options, Referrer-Policy |
-| 10 | CI/CD Pipeline Security | Secrets via secrets context, not hardcoded in workflow files |
+| 10 | CI/CD Pipeline Security | Secrets via secrets context, not hardcoded in workflows |
 
-**Agent behavior rules:**
-- Read every file in the provided list. No sampling or skipping.
-- Every finding must have: file path, line number, what's wrong, severity, remediation.
-- Understand context before flagging — read surrounding code, check for middleware, wrappers, and higher-order protections.
-- Document intentionally public endpoints; don't flag them as vulnerabilities.
-- Severity is firm: `critical` = exploitable vulnerability, `warning` = defense-in-depth gap, `info` = observation.
-- Prefer false negatives over false positives — only flag what you're confident about.
-- Categories that don't apply to this project's stack → mark as N/A with brief explanation.
+**Rules:**
+- Read every file. No sampling.
+- Every finding needs: file path, line number, issue, severity, remediation.
+- Check surrounding code for middleware/wrappers before flagging.
+- Document intentionally public endpoints — don't flag them.
+- Severity: `critical` = exploitable vulnerability, `warning` = defense-in-depth gap, `info` = observation.
+- Prefer false negatives over false positives.
+- Inapplicable categories → N/A with brief reason.
 
-**Project adaptation:** Adapt checks to the detected stack:
-- Express vs Next.js vs Fastify endpoint patterns
-- PostgreSQL vs MongoDB vs SQLite query patterns
-- GitHub Actions vs GitLab CI vs other CI systems
-- React vs Vue vs Svelte frontend patterns
+**Adapt checks to detected stack:** Express/Next.js/Fastify endpoints, PostgreSQL/MongoDB/SQLite queries, GitHub Actions/GitLab CI, React/Vue/Svelte frontends.
 
-**Output format** (return to orchestrator):
+**Output format:**
 
 ```yaml
 security_audit:
@@ -117,25 +111,22 @@ security_audit:
 
 ### Part 2: Architecture Audit (subagent)
 
-Spawn an architecture auditor agent with a fresh context window.
-
-**4 Architecture Dimensions:**
+**4 Dimensions:**
 
-| Dimension | What It Checks |
-|-----------|---------------|
-| **Scalability** | Synchronous blocking calls, missing pagination, unbounded queries, N+1 query patterns, missing caching opportunities, single points of failure, hardcoded limits |
-| **Maintainability** | Code complexity hotspots (files >300 lines, deeply nested logic >4 levels, god components/classes), circular dependencies, duplicated logic that warrants abstraction |
-| **Code Health** | Dead code / unused exports, TODO/FIXME inventory with age, test coverage gaps (untested critical paths), stale/vulnerable dependencies |
-| **Structural Quality** | Separation of concerns violations (business logic in UI layer), inconsistent patterns across similar features, missing error boundaries, API contract consistency |
+| Dimension | Checks |
+|-----------|--------|
+| **Scalability** | Synchronous blocking, missing pagination, unbounded queries, N+1 patterns, missing caching, single points of failure, hardcoded limits |
+| **Maintainability** | Files >300 lines, nesting >4 levels, god components/classes, circular deps, duplicated logic warranting abstraction |
+| **Code Health** | Dead code/unused exports, TODO/FIXME inventory with age, untested critical paths, stale/vulnerable deps |
+| **Structural Quality** | Business logic in UI layer, inconsistent patterns across features, missing error boundaries, API contract inconsistency |
 
-**Agent behavior rules:**
+**Rules:**
 - Check actual code, not theoretical concerns.
 - Every finding references specific files with evidence.
-- Severity: `critical` = architectural debt that will cause production issues or block future work, `warning` = quality concern worth addressing, `info` = improvement opportunity.
-- Respect existing ADRs in `.forge/decisions/` — don't flag intentional architectural choices as issues.
-- Respect constitutional articles in `.forge/constitution.md` — if the constitution permits a pattern, don't flag it.
+- Severity: `critical` = debt causing production issues or blocking future work, `warning` = quality concern, `info` = improvement opportunity.
+- Respect existing ADRs in `.forge/decisions/` and constitutional articles — don't flag intentional choices.
 
-**Output format** (return to orchestrator):
+**Output format:**
 
 ```yaml
 architecture_audit:
@@ -162,29 +153,29 @@ architecture_audit:
 
 ### Part 3: Refactoring Scan (subagent)
 
-Spawn a refactoring scanner agent with a fresh context window. Pass it only the files changed during the milestone (from the git diff).
+Pass only files changed during the milestone (from git diff).
 
-**6 Refactoring Categories:**
+**6 Categories:**
 
-| # | Category | What to Look For |
-|---|----------|-----------------|
-| 1 | **Duplication** | Similar logic in 2+ places that could be extracted into a shared function, hook, or utility |
-| 2 | **Complexity hotspots** | Functions >50 lines, nesting >3 levels deep, high cyclomatic complexity, overly long files |
-| 3 | **Naming & clarity** | Unclear variable/function names, misleading abstractions, functions that do more than their name suggests |
-| 4 | **Pattern inconsistency** | Same thing done differently across the milestone's files (e.g., error handling, data fetching, state management) |
-| 5 | **Dead code** | Unused functions, unreachable branches, commented-out code left behind, unused imports |
-| 6 | **Abstraction issues** | Over-engineered helpers used once, repeated inline code that warrants extraction, premature or missing abstractions |
+| # | Category | Look For |
+|---|----------|----------|
+| 1 | **Duplication** | Similar logic in 2+ places extractable into shared function/hook/utility |
+| 2 | **Complexity hotspots** | Functions >50 lines, nesting >3 levels, high cyclomatic complexity, overly long files |
+| 3 | **Naming & clarity** | Unclear names, misleading abstractions, functions exceeding their name's scope |
+| 4 | **Pattern inconsistency** | Same concern handled differently across milestone files (error handling, data fetching, state) |
+| 5 | **Dead code** | Unused functions, unreachable branches, commented-out code, unused imports |
+| 6 | **Abstraction issues** | Over-engineered one-use helpers, repeated inline code warranting extraction, premature/missing abstractions |
 
-**Agent behavior rules:**
+**Rules:**
 - Read every file in the diff. No sampling.
-- Every finding must reference a specific file and line range.
-- Understand context — don't flag intentional patterns documented in the constitution.
-- Don't duplicate findings from the security or architecture audits.
-- Estimate effort for each item: `quick` (< 30 min, under 50 lines) or `standard` (needs planning).
-- Suggest a concrete approach for each finding, not just "refactor this."
-- Prefer fewer high-quality findings over many low-signal ones.
+- Every finding references a specific file and line range.
+- Don't flag patterns documented in the constitution.
+- Don't duplicate security or architecture findings.
+- Estimate effort: `quick` (< 30 min, < 50 lines) or `standard` (needs planning).
+- Suggest a concrete approach, not "refactor this."
+- Fewer high-quality findings over many low-signal ones.
 
-**Output format** (return to orchestrator):
+**Output format:**
 
 ```yaml
 refactoring_scan:
@@ -200,30 +191,28 @@ refactoring_scan:
 
 ## Step 4: Score Results
 
-After all three subagents return, compute scores.
-
 **Per-category scoring (security + architecture):**
 
 | Status | Meaning |
 |--------|---------|
-| `passed` | No issues found |
-| `warning` | Non-critical issues (info-level also maps here) |
-| `critical` | Real vulnerabilities or architectural blockers |
-| `na` | Category doesn't apply to this project |
+| `passed` | No issues |
+| `warning` | Non-critical issues |
+| `critical` | Exploitable vulnerabilities or architectural blockers |
+| `na` | Category doesn't apply |
 
-**Overall health status:**
+**Overall health:**
 
 | Overall | Condition |
 |---------|-----------|
-| `passed` | ALL categories and dimensions passed or N/A |
-| `warnings_only` | One or more warnings, zero critical |
-| `issues_found` | One or more critical findings |
+| `passed` | All categories passed or N/A |
+| `warnings_only` | One+ warnings, zero critical |
+| `issues_found` | One+ critical findings |
 
-**Refactoring findings** are separate from the health status — they never block completion.
+Refactoring findings are separate — they never block completion.
 
 ## Step 5: Write Health Report
 
-Create `.forge/audits/` directory if needed. Write to `.forge/audits/milestone-{id}-health-report.md`.
+Create `.forge/audits/` if needed. Write to `.forge/audits/milestone-{id}-health-report.md`.
 
 **YAML frontmatter:**
 
@@ -259,7 +248,7 @@ total_files_scanned: N
 # Review Report: {milestone name}
 
 ## Executive Summary
-{1-3 sentences: overall health assessment, key findings, refactoring highlights, recommendation}
+{1-3 sentences: health assessment, key findings, refactoring highlights, recommendation}
 
 ## Security Findings
 
@@ -268,7 +257,7 @@ total_files_scanned: N
 |------|------|----------|-------|-------------|
 | ... | ... | ... | ... | ... |
 
-{Repeat for each category. N/A categories get a single line: "N/A — {reason}"}
+{Repeat per category. N/A categories: single line "N/A — {reason}"}
 
 ## Architecture Findings
 
@@ -277,7 +266,7 @@ total_files_scanned: N
 |------|------|----------|-------|-------------|
 | ... | ... | ... | ... | ... |
 
-{Repeat for each dimension}
+{Repeat per dimension}
 
 ## Refactoring Opportunities
 
@@ -286,59 +275,56 @@ total_files_scanned: N
 |------|-------|-------------|--------|----------|
 | ... | ... | ... | quick/standard | ... |
 
-{Repeat for each refactoring category with findings}
+{Repeat per category with findings}
 
 ## Public Endpoints
-{List of intentionally public endpoints documented during security audit}
+{Intentionally public endpoints documented during security audit}
 
 ## Files Scanned
-{Count and list of all files scanned across all three scans}
+{Count and list of all files scanned}
 ```
 
-**Health trend tracking:** If a previous audit exists for an earlier milestone (check `.forge/audits/` for prior reports), compare results and note improvements or regressions in the executive summary.
+If a previous milestone audit exists in `.forge/audits/`, compare results and note improvements/regressions in the executive summary.
 
 ## Step 6: Present Results + Triage Refactoring
 
 ### Health Results
 
-Present the health status first — this is the gate.
+Present health status first — this is the gate.
 
-**If HEALTHY (all passed):**
-*"Health audit passed. No security vulnerabilities or architectural concerns found."*
+**HEALTHY (all passed):**
+*"Health audit passed. No security vulnerabilities or architectural concerns."*
 
-**If NEEDS ATTENTION (critical issues):**
-*"Review found critical issues that should be addressed before shipping:"*
-Inline the top 3 findings per critical category so the user sees them immediately.
+**NEEDS ATTENTION (critical issues):**
+*"Critical issues found:"*
+Inline top 3 findings per critical category.
 
-**If WARNINGS ONLY:**
-*"Review passed with warnings — no critical issues, but {N} items worth noting. See the full report at `.forge/audits/milestone-{id}-health-report.md`."*
+**WARNINGS ONLY:**
+*"Passed with warnings — no critical issues, {N} items worth noting. Full report: `.forge/audits/milestone-{id}-health-report.md`."*
 
 ### Refactoring Triage
 
-After presenting health results, show refactoring findings for triage. Group by category, max 10 initially:
-
-*"I also found {N} refactoring opportunities in the code built during this milestone:"*
+Show findings grouped by category (max 10 initially):
 
-For each category with findings:
-*"**Duplication** ({N} items):*
-*1. `src/api/users.ts:42-67` — Duplicate email validation in createUser and updateUser. Quick fix: extract shared helper. [Accept / Dismiss]*
-*2. ...*"
+*"{N} refactoring opportunities found:"*
 
-The user can respond with:
-- **Accept** (individual item) → add to backlog
-- **Dismiss** (individual item) → skip, not a real issue or intentional
-- **Accept all** → bulk add all remaining items to backlog
-- **Dismiss all** → skip everything, no backlog items added
+Per category:
+*"**Duplication** ({N}):*
+*1. `src/api/users.ts:42-67` — Duplicate email validation. Quick fix: extract helper. [Accept / Dismiss]*"
 
-For dismissed items, optionally ask for a brief reason (helps calibrate future scans).
+User responses:
+- **Accept** → add to backlog
+- **Dismiss** → skip (optionally ask reason to calibrate future scans)
+- **Accept all** → bulk add remaining
+- **Dismiss all** → skip everything
 
 ## Step 7: Write Backlog + Route
 
 ### Write Refactoring Backlog
 
-Read existing `.forge/refactor-backlog.yml` (if any). Determine the next item ID by incrementing from the highest existing ID.
+Read existing `.forge/refactor-backlog.yml`. Determine next item ID by incrementing from highest existing.
 
-Append accepted items to `.forge/refactor-backlog.yml`:
+Append accepted items:
 
 ```yaml
 items:
@@ -355,83 +341,66 @@ items:
     completed: null
 ```
 
-If the file doesn't exist yet, create it from the template at `.forge/templates/refactor-backlog.yml`.
+If file doesn't exist, create from `.forge/templates/refactor-backlog.yml`.
 
 ### Route Based on Health Status
 
-#### HEALTHY or WARNINGS ONLY (user accepts)
+#### HEALTHY or WARNINGS ONLY (accepted)
 
-Update `.forge/state/milestone-{id}.yml`:
-- Set `current.status` to `complete`
+Update `.forge/state/milestone-{id}.yml`: set `current.status` to `complete`.
+Update `.forge/state/index.yml`: set milestone status to `complete`, update `last_updated`.
 
-Update `.forge/state/index.yml`:
-- Set milestone status to `complete`
-- Update `last_updated` timestamp
+*"Milestone [{name}] complete. {N} refactoring items in backlog."*
 
-Present to user:
-*"Milestone [{name}] is complete. {N} refactoring items are in the backlog for whenever you want to tackle them."*
+If Beads installed, run `bd complete`.
 
-If Beads is installed, run `bd complete` to update the dependency graph.
+#### NEEDS ATTENTION (critical issues)
 
-#### NEEDS ATTENTION (critical issues found)
+Do NOT mark complete. Present choices:
 
-Do NOT mark milestone complete. Present choices:
-
-*"Options:"*
 - **A. Fix critical issues** — return to `planning` in fix mode with findings as requirements
-- **B. Accept risk and continue** — document accepted risks in report, complete the milestone
-
-If user chooses A:
-- Create fix requirements from critical findings
-- Route to `planning` skill in fix mode
-- After fix execution + re-verification, re-run `reviewing` (not full verification — just this review)
+- **B. Accept risk** — document accepted risks in report, complete the milestone
 
-If user chooses B:
-- Append "Accepted Risks" section to the health report with user's acknowledgment
-- Complete the milestone (same as HEALTHY path above)
+If A: create fix requirements from findings → route to `planning` → after fix + re-verification → re-run `reviewing`.
+If B: append "Accepted Risks" section to report → complete milestone (same as HEALTHY path).
 
 #### WARNINGS ONLY (user wants to fix)
 
-If user wants to fix warnings instead of accepting:
-- Create fix requirements from warning findings
-- Route to `planning` in fix mode
-- After fix execution, re-run `reviewing`
+Create fix requirements from warnings → route to `planning` in fix mode → after fix → re-run `reviewing`.
 
 ## Gate Type: Mixed
 
-- **Security critical findings** → soft gate (user can accept risk, but strongly recommended to fix)
-- **Architecture critical findings** → soft gate (same — user has final authority)
+- **Security critical** → soft gate (user can accept risk)
+- **Architecture critical** → soft gate (user has final authority)
 - **Warnings** → advisory (noted in report, user chooses)
-- **Refactoring items** → never block (cataloged to backlog for future work)
+- **Refactoring items** → never block (cataloged to backlog)
 
-The report documents the decision either way, creating an audit trail.
+The report documents the decision either way — audit trail.
 
 ## Backlog Lifecycle
 
-Backlog items follow this lifecycle:
-
 ```
 pending → in_progress → done
-pending → dismissed (during triage or later review)
+pending → dismissed (during triage or later)
 ```
 
-Items with `effort: quick` can be picked up directly via `quick-tasking`.
-Items with `effort: standard` should go through the Standard tier flow.
+`effort: quick` items → pick up via `quick-tasking`.
+`effort: standard` items → Standard tier flow.
 
-When working a backlog item:
-1. `forge` surfaces it as an available task
+Working a backlog item:
+1. `forge` surfaces it as available
 2. User selects it
 3. Route to `quick-tasking` or Standard tier based on effort
-4. On completion, update the item's `status` to `done` and set `completed` date
+4. On completion, set `status: done` and `completed` date
 
 ## Phase Handoff
 
-After reviewing completes (all paths: HEALTHY, accepted risk, accepted warnings):
+After reviewing completes (all paths):
 
-1. **Verify persistence** — Confirm health report is written to `.forge/audits/milestone-{id}-health-report.md` and refactoring backlog is updated
-2. **Update state** — Set `current.status` to `complete` in `.forge/state/milestone-{id}.yml`
-3. **Present completion:**
+1. Confirm health report written to `.forge/audits/milestone-{id}-health-report.md` and backlog updated
+2. Set `current.status` to `complete` in `.forge/state/milestone-{id}.yml`
+3. Present:
 
-*"Milestone [{name}] complete. Review report at `.forge/audits/milestone-{id}-health-report.md`. {N} refactoring items in backlog.*
+*"Milestone [{name}] complete. Report: `.forge/audits/milestone-{id}-health-report.md`. {N} refactoring items in backlog.*
 
 *Start new work with `/forge` or tackle backlog items anytime."*

package/template/.claude/skills/securing/SKILL.md

@@ -7,11 +7,11 @@ description: "Use when building features that touch authentication, user data, e
 
 Security is a requirement, not a feature. Review before shipping.
 
-## When This Skill Triggers
+## Trigger
 
-Ask these 4 questions. If YES to any, run this skill:
+YES to any of these? Run this skill:
 
-1. Does this feature touch **authentication or authorization**?
+1. Does the feature touch **authentication or authorization**?
 2. Does it **store or transmit user data**?
 3. Does it **call external APIs** or accept webhooks?
 4. Does it **handle secrets, keys, or tokens**?
@@ -20,43 +20,43 @@ Ask these 4 questions. If YES to any, run this skill:
 
 ### Authentication & Authorization
 - [ ] Passwords hashed with bcrypt/scrypt/argon2 (never MD5/SHA)
-- [ ] Sessions/tokens expire (configurable, reasonable default)
+- [ ] Sessions/tokens expire with reasonable defaults
 - [ ] Token refresh mechanism exists
 - [ ] Authorization checked server-side before every data access
 - [ ] Failed login attempts rate-limited
 - [ ] Password reset flow doesn't reveal account existence
 
 ### Input Validation & Injection
-- [ ] All user input validated server-side (not just client-side)
+- [ ] All user input validated server-side
 - [ ] SQL queries use parameterized statements (never string concatenation)
 - [ ] HTML output escaped to prevent XSS
-- [ ] File uploads validated: type, size, content (not just extension)
-- [ ] URL parameters sanitized before use
+- [ ] File uploads validated: type, size, content (not extension alone)
+- [ ] URL parameters sanitized
 - [ ] JSON parsing has size limits
 
 ### Secrets Management
-- [ ] Secrets stored in environment variables, never in code
-- [ ] `.env` file in `.gitignore`
+- [ ] Secrets in environment variables, never in code
+- [ ] `.env` in `.gitignore`
 - [ ] No secrets in logs, error messages, or stack traces
-- [ ] API keys scoped to minimum required permissions
-- [ ] Secrets rotated periodically (documented rotation process)
+- [ ] API keys scoped to minimum permissions
+- [ ] Documented rotation process
 
 ### Data Protection
-- [ ] Sensitive data encrypted at rest (if stored)
-- [ ] HTTPS enforced for all data in transit
+- [ ] Sensitive data encrypted at rest
+- [ ] HTTPS enforced for all transit
 - [ ] PII not logged (names, emails, addresses, IPs)
-- [ ] Data retention policy defined (how long, when deleted)
-- [ ] CORS configured to allow only known origins
+- [ ] Data retention policy defined
+- [ ] CORS allows only known origins
 
 ### Dependencies
 - [ ] `npm audit` (or equivalent) passes or vulnerabilities documented
-- [ ] No known vulnerable versions of critical dependencies
-- [ ] Lock file committed (package-lock.json, yarn.lock)
+- [ ] No known vulnerable versions of critical deps
+- [ ] Lock file committed
 - [ ] Dependencies from trusted registries only
 
 ### Error Handling
-- [ ] Error messages don't leak internal details (stack traces, DB schema, file paths)
-- [ ] Unhandled exceptions caught and logged (not displayed to user)
+- [ ] Error messages don't leak internals (stack traces, DB schema, file paths)
+- [ ] Unhandled exceptions caught and logged, not displayed
 - [ ] Rate limiting on all public endpoints
 - [ ] Graceful degradation when external services fail