code-ai-installer 1.3.1 → 1.5.0

package/locales/en/.agents/skills/adr_log/SKILL.md

@@ -0,0 +1,369 @@
+---
+name: adr_log
+description: Record key Architectural Decision Records (ADR) with trade-offs — Pros/Cons/Alternatives/Decision, status and date.
+---
+
+# Skill: ADR Log
+
+Format and examples for Architectural Decision Records.
+
+**Sections:**
+1. [When to create an ADR](#1-when-to-create)
+2. [Format (mandatory)](#2-format)
+3. [Naming Convention](#3-naming)
+4. [ADR Examples](#4-examples)
+5. [Decision Matrix](#5-decision-matrix)
+6. [Lifecycle](#6-lifecycle)
+7. [Anti-patterns](#7-anti-patterns)
+
+---
+
+## 1. When to create an ADR
+
+Create an ADR for **every non-trivial choice** — if in 6 months someone asks "why is it like this?":
+
+| Category | Examples |
+|-----------|---------|
+| **Database** | DBMS choice, embed vs reference, sharding strategy |
+| **Auth** | JWT vs sessions, cookie vs header, OAuth flow |
+| **API Design** | REST vs GraphQL, versioning, error format |
+| **Architecture** | Monolith vs microservices, layering, module boundaries |
+| **Infrastructure** | Docker vs K8s, CDN, reverse proxy, HTTPS strategy |
+| **Integration** | Wix SDK choice, payment provider, email service |
+| **State** | Zustand vs Redux vs Context, server state (React Query) |
+| **Styling** | CSS Modules vs Tailwind vs styled-components |
+| **Testing** | Test runner, coverage thresholds, mock strategy |
+| **Error handling** | Error format, retry policy, circuit breaker |
+
+---
+
+## 2. Format (mandatory)
+
+```markdown
+# ADR-XXX: <Short name of the decision>
+
+## Status
+Proposed | Accepted | Deprecated | Superseded by ADR-YYY
+
+## Date
+YYYY-MM-DD
+
+## Context
+<Why is this needed? What are the constraints? What hurts?>
+- Current situation
+- Requirements / constraints
+- What happens if not resolved
+
+## Decision
+<What was chosen and exactly how we will do it>
+
+## Consequences
+
+### Positive
+- ...
+- ...
+
+### Negative
+- ...
+- ...
+
+### Risks
+- ... (and how we mitigate them)
+
+## Alternatives Considered
+
+### Option A: <name>
+- ✅ Pros: ...
+- ❌ Cons: ...
+- 💡 Why rejected: ...
+
+### Option B: <name>
+- ✅ Pros: ...
+- ❌ Cons: ...
+- 💡 Why rejected: ...
+
+## References
+- PRD section / UX Spec / ticket
+- External docs / articles
+- Related ADRs: ADR-XXX
+```
+
+---
+
+## 3. Naming Convention
+
+| Rule | Example |
+|---------|--------|
+| Number: 3-digit, with leading zeros | ADR-001, ADR-042 |
+| Name: action + object | "Use MongoDB as primary database" |
+| File: `ADR-XXX-kebab-case.md` | `ADR-001-use-mongodb.md` |
+| Directory: `docs/architecture/adr/` | — |
+| Chronological order | New ADRs = next number |
+
+---
+
+## 4. ADR Examples
+
+### ADR-001: Use MongoDB as primary database
+
+```markdown
+# ADR-001: Use MongoDB as primary database
+
+## Status
+Accepted
+
+## Date
+2025-06-15
+
+## Context
+The application needs persistent storage for tenants, settings,
+and products. Requirements:
+- Flexible schema (settings structure varies per configuration)
+- Low operational overhead (small team)
+- Good Node.js ecosystem support
+- No complex joins needed (data is per-tenant)
+
+## Decision
+Use MongoDB 7 with Mongoose ODM.
+- Single database, collections: tenants, settings, products
+- Hosted via Docker (dev) / MongoDB Atlas (production)
+
+## Consequences
+
+### Positive
+- Flexible schema fits varying template settings
+- Excellent Mongoose ecosystem (validators, middleware, lean queries)
+- Easy Docker setup for local development
+- Native JSON — minimal serialization overhead
+
+### Negative
+- No ACID transactions across collections (need replica set)
+- No joins — must denormalize or do application-level joins
+- Schema discipline required (strict mode + Zod validation)
+
+### Risks
+- Schema drift without validation → mitigated by strict: 'throw'
+- 16MB document limit → mitigated by reference strategy for unbounded arrays
+
+## Alternatives Considered
+
+### Option A: PostgreSQL
+- ✅ ACID, complex queries, strong typing
+- ❌ Schema migrations more complex for flexible settings
+- ❌ JSON column less ergonomic than native MongoDB documents
+- 💡 Overkill for current use case (no joins, no complex queries)
+
+### Option B: SQLite
+- ✅ Zero infrastructure, file-based
+- ❌ No concurrent writes in Docker
+- ❌ No production scaling path
+- 💡 Too limiting for multi-service architecture
+
+## References
+- PRD: Data requirements section
+- Related: ADR-002 (Mongoose strict mode)
+```
+
+---
+
+### ADR-018: Use Wix ImageViewer for dashboard images
+
+```markdown
+# ADR-018: Use Wix ImageViewer for dashboard images
+
+## Status
+Accepted
+
+## Date
+2025-12-20
+
+## Context
+Dashboard needs to display template preview images.
+The app runs inside Wix iframe where standard <img> tags may have
+CORS issues with Wix media URLs (wixstatic.com).
+
+## Decision
+Use WDS (Wix Design System) ImageViewer component for all
+dashboard images instead of native <img> tags.
+
+## Consequences
+
+### Positive
+- Handles Wix media URLs natively (no CORS issues)
+- Consistent with Wix design system (visual parity)
+- Built-in loading states and error handling
+
+### Negative
+- Dependency on WDS component library
+- Different API than standard <img> (onLoad, src format)
+
+## Alternatives Considered
+
+### Option A: Native <img> with proxy
+- ✅ Simple, no dependency
+- ❌ CORS errors with wixstatic.com
+- ❌ Need custom proxy endpoint
+- 💡 Unnecessary complexity
+
+## References
+- Bug: Dashboard images not loading (blank src)
+- Wix Design System docs: ImageViewer component
+```
+
+---
+
+### ADR-019: CSS overflow containment for popup templates
+
+```markdown
+# ADR-019: CSS overflow containment for popup
+
+## Status
+Accepted
+
+## Date
+2025-12-20
+
+## Context
+Popup templates render inside Wix embedded script.
+CSS overflow from popup elements leaks outside the container,
+causing scrollbars on the Wix page.
+
+## Decision
+Apply containment strategy:
+1. `overflow: hidden` on popup container
+2. `contain: layout style` on root widget element
+3. `box-sizing: border-box` on all popup children
+
+## Consequences
+
+### Positive
+- No visual leaking outside container
+- No unexpected scrollbars on host page
+- Each template isolated
+
+### Negative
+- Must test each template for clipping issues
+- Shadow effects near edges may be cut off
+
+## Alternatives Considered
+
+### Option A: Shadow DOM
+- ✅ Complete style isolation
+- ❌ Complex to implement for dynamic templates
+- ❌ Limited shadow DOM support for legacy browsers
+- 💡 Overkill for current 3-template scope
+
+## References
+- Bug: Scrollbar appearing on Wix site when popup opens
+- Related: ADR-018 (ImageViewer)
+```
+
+---
+
+## 5. Decision Matrix
+
+For complex decisions with 3+ alternatives, use a weighted matrix:
+
+```markdown
+## Decision Matrix: State Management
+
+### Criteria (weighted)
+| Criteria | Weight | Description |
+|----------|--------|-------------|
+| Simplicity | 3 | Learning curve, boilerplate |
+| Performance | 2 | Re-render efficiency |
+| DevTools | 1 | Debugging experience |
+| Ecosystem | 1 | Community, plugins |
+| Bundle size | 2 | KB added |
+
+### Scoring (1-5, higher = better)
+
+| Option | Simplicity (×3) | Performance (×2) | DevTools (×1) | Ecosystem (×1) | Bundle (×2) | **Total** |
+|--------|:---:|:---:|:---:|:---:|:---:|:---:|
+| **Zustand** | 5 (15) | 4 (8) | 4 (4) | 3 (3) | 5 (10) | **40** |
+| Redux Toolkit | 3 (9) | 4 (8) | 5 (5) | 5 (5) | 3 (6) | **33** |
+| Context + useReducer | 4 (12) | 2 (4) | 3 (3) | 5 (5) | 5 (10) | **34** |
+| Jotai | 4 (12) | 5 (10) | 3 (3) | 2 (2) | 5 (10) | **37** |
+
+### Decision
+Zustand wins (40 points). Best simplicity + performance + bundle size.
+```
+
+---
+
+## 6. Lifecycle
+
+```
+Proposed → Accepted → [Active use]
+                         ↓
+                    Deprecated (if better solution found)
+                         ↓
+                    Superseded by ADR-YYY
+```
+
+| Status | Meaning |
+|--------|---------|
+| **Proposed** | Decision proposed, waiting for review |
+| **Accepted** | Decision approved, is applied |
+| **Deprecated** | Decision is obsolete, but code still uses it |
+| **Superseded** | Replaced by another ADR (provide link) |
+
+### Supersedes/Superseded-by
+
+```markdown
+# ADR-025: Migrate from CSS Modules to Tailwind
+
+## Status
+Accepted (Supersedes ADR-008)
+
+---
+
+# ADR-008: Use CSS Modules for component styling
+
+## Status
+Superseded by ADR-025
+```
+
+---
+
+## 7. Anti-patterns
+
+| ❌ Anti-pattern | ✅ Solution |
+|----------------|-----------|
+| ADR without Alternatives | Always minimum 2 alternatives |
+| "We chose X because it's popular" | Specific Pros/Cons according to project criteria |
+| 500-line ADR | Short and specific: max 50-80 lines |
+| ADR retroactively (a month later) | Create ADR at the moment of making the decision |
+| No cross-references | Links to PRD, related ADRs, tickets |
+| No Negative consequences | Every decision has trade-offs |
+| "Alternatives: none" | If there are no alternatives — reconsider the scope of the question |
+
+---
+
+## Deliverables
+
+| Artifact | Format | Where |
+|---------|--------|-----|
+| ADR record | Markdown (format above) | `docs/architecture/adr/ADR-XXX-name.md` |
+| ADR index | Table of contents | `docs/architecture/adr/README.md` |
+
+### ADR Index format
+
+```markdown
+# Architecture Decision Records
+
+| # | Title | Status | Date |
+|---|-------|--------|------|
+| ADR-001 | Use MongoDB as primary database | Accepted | 2025-06-15 |
+| ADR-008 | Use CSS Modules for styling | Superseded by ADR-025 | 2025-07-01 |
+| ADR-018 | Use WDS ImageViewer | Accepted | 2025-12-20 |
+| ADR-019 | CSS overflow containment | Accepted | 2025-12-20 |
+| ADR-025 | Migrate to Tailwind | Accepted | 2026-01-15 |
+```
+
+---
+
+## See also
+- `$architecture_doc` — Architecture Document (ADR decisions referenced inline)
+- `$current_state_analysis` — audit before new ADRs
+- `$system_design_checklist` — design completeness checklist

package/locales/en/.agents/skills/adr_log/agents/claude.json

@@ -0,0 +1,17 @@
+{
+  "name": "adr_log",
+  "display_name": "ADR Log",
+  "description": "Capture key architectural decisions (ADR) with trade-offs - pros, cons, alternatives, decision, status, and date.",
+  "default_prompt": "Use $adr_log when the task matches the \"ADR Log\" skill.",
+  "triggers": [
+    "adr_log",
+    "adr log",
+    "Capture key architectural decisions (ADR) with trade-offs - pros, cons, alternatives, decision, status, and date"
+  ],
+  "capabilities": [
+    "adr",
+    "log"
+  ],
+  "tools": [],
+  "implicit_invocation": true
+}

package/locales/en/.agents/skills/adr_log/agents/copilot.json

@@ -0,0 +1,17 @@
+{
+  "name": "adr_log",
+  "display_name": "ADR Log",
+  "description": "Capture key architectural decisions (ADR) with trade-offs - pros, cons, alternatives, decision, status, and date.",
+  "default_prompt": "Use $adr_log when the task matches the \"ADR Log\" skill.",
+  "triggers": [
+    "adr_log",
+    "adr log",
+    "Capture key architectural decisions (ADR) with trade-offs - pros, cons, alternatives, decision, status, and date"
+  ],
+  "capabilities": [
+    "adr",
+    "log"
+  ],
+  "tools": [],
+  "implicit_invocation": true
+}

package/locales/en/.agents/skills/adr_log/agents/gemini.json

@@ -0,0 +1,17 @@
+{
+  "name": "adr_log",
+  "display_name": "ADR Log",
+  "description": "Capture key architectural decisions (ADR) with trade-offs - pros, cons, alternatives, decision, status, and date.",
+  "default_prompt": "Use $adr_log when the task matches the \"ADR Log\" skill.",
+  "triggers": [
+    "adr_log",
+    "adr log",
+    "Capture key architectural decisions (ADR) with trade-offs - pros, cons, alternatives, decision, status, and date"
+  ],
+  "capabilities": [
+    "adr",
+    "log"
+  ],
+  "tools": [],
+  "implicit_invocation": true
+}

package/locales/en/.agents/skills/adr_log/agents/openai.yaml

@@ -0,0 +1,8 @@
+interface:
+  display_name: "ADR Log"
+  short_description: "Capture key architectural decisions (ADR) with trade-offs - pros, cons, alternatives, decision,…"
+  default_prompt: "Use $adr_log when the task matches the \"ADR Log\" skill."
+dependencies:
+  tools: []
+policy:
+  allow_implicit_invocation: true

package/locales/en/.agents/skills/adr_log/agents/qwen.json

@@ -0,0 +1,17 @@
+{
+  "name": "adr_log",
+  "display_name": "ADR Log",
+  "description": "Capture key architectural decisions (ADR) with trade-offs - pros, cons, alternatives, decision, status, and date.",
+  "default_prompt": "Use $adr_log when the task matches the \"ADR Log\" skill.",
+  "triggers": [
+    "adr_log",
+    "adr log",
+    "Capture key architectural decisions (ADR) with trade-offs - pros, cons, alternatives, decision, status, and date"
+  ],
+  "capabilities": [
+    "adr",
+    "log"
+  ],
+  "tools": [],
+  "implicit_invocation": true
+}

package/locales/en/.agents/skills/adr_log/agents/skill.yaml

@@ -0,0 +1,21 @@
+version: 1
+name: "adr_log"
+display_name: "ADR Log"
+description: "Capture key architectural decisions (ADR) with trade-offs - pros, cons, alternatives, decision, status, and date."
+default_prompt: "Use $adr_log when the task matches the \"ADR Log\" skill."
+triggers:
+  - "adr_log"
+  - "adr log"
+  - "Capture key architectural decisions (ADR) with trade-offs - pros, cons, alternatives, decision, status, and date"
+capabilities:
+  - "adr"
+  - "log"
+tools: []
+invocation:
+  explicit: true
+  implicit: true
+localization:
+  default_locale: "en"
+  available_locales:
+    - "ru"
+    - "en"

package/locales/en/.agents/skills/api_contract_compliance_review/SKILL.md

@@ -0,0 +1,224 @@
+---
+name: api_contract_compliance_review
+description: API implementation contract compliance review — schemas, error codes, validation, authorization, idempotency, pagination.
+---
+
+# Skill: API Contract Compliance Review
+
+Review: API implementation conforms to the declared contracts.
+
+**Sections:**
+1. [Workflow](#1-workflow)
+2. [Checklist](#2-checklist)
+3. [Verification Methods](#3-methods)
+4. [Common Mismatches](#4-mismatches)
+5. [Output Template](#5-output)
+
+---
+
+## 1. Workflow
+
+```
+1. Load API Contracts (from $api_contracts)
+   └── List of endpoints, schemas, error codes
+
+2. For each endpoint:
+   a. Find the implementation file (route → controller → service)
+   b. Compare: method, path, request schema, response schema
+   c. Check: error format, status codes, auth, validation
+
+3. Check cross-cutting concerns:
+   └── Error format, pagination, auth, rate limiting
+
+4. Formulate compliance report
+```
+
+---
+
+## 2. Checklist
+
+### 2.1 Endpoint Compliance
+
+| # | Check | Severity | Status |
+|---|-------|----------|--------|
+| API-01 | Every documented endpoint exists in code | 🔴 P0 | ☐ |
+| API-02 | HTTP method matches contract (POST, not PUT for create) | 🔴 P0 | ☐ |
+| API-03 | URL path matches contract (naming, params) | 🔴 P0 | ☐ |
+| API-04 | Request body schema validates with Zod (matches contract fields) | 🔴 P0 | ☐ |
+| API-05 | Response body matches contract shape | 🔴 P0 | ☐ |
+| API-06 | No undocumented endpoints exist | 🟠 P1 | ☐ |
+
+### 2.2 Error Format
+
+| # | Check | Severity | Status |
+|---|-------|----------|--------|
+| API-07 | Error responses use unified format `{ error: { code, message } }` | 🔴 P0 | ☐ |
+| API-08 | Error codes match registry (VALIDATION_ERROR, NOT_FOUND, etc.) | 🟠 P1 | ☐ |
+| API-09 | No stack traces in error responses | 🔴 P0 | ☐ |
+| API-10 | Validation errors include `details` with field names | 🟠 P1 | ☐ |
+
+### 2.3 Status Codes
+
+| # | Check | Severity | Status |
+|---|-------|----------|--------|
+| API-11 | 200 for successful GET/PUT | 🟠 P1 | ☐ |
+| API-12 | 201 for successful POST (create) | 🟠 P1 | ☐ |
+| API-13 | 204 for successful DELETE | 🟠 P1 | ☐ |
+| API-14 | 400 for validation errors | 🟠 P1 | ☐ |
+| API-15 | 401 for missing auth, 403 for insufficient permissions | 🔴 P0 | ☐ |
+| API-16 | 404 for not found | 🟠 P1 | ☐ |
+| API-17 | 409 for conflict/duplicate | 🟠 P1 | ☐ |
+| API-18 | 500 only for unexpected errors (not for validation/auth!) | 🟠 P1 | ☐ |
+
+### 2.4 Auth & AuthZ
+
+| # | Check | Severity | Status |
+|---|-------|----------|--------|
+| API-19 | Protected endpoints have auth middleware | 🔴 P0 | ☐ |
+| API-20 | Public endpoints are intentionally public (documented) | 🟠 P1 | ☐ |
+| API-21 | IDOR protection: ownership check on data access | 🔴 P0 | ☐ |
+
+### 2.5 Pagination & Filtering
+
+| # | Check | Severity | Status |
+|---|-------|----------|--------|
+| API-22 | List endpoints have pagination (cursor or offset) | 🔴 P0 | ☐ |
+| API-23 | Pagination params match contract (limit, cursor/page) | 🟠 P1 | ☐ |
+| API-24 | Response includes pagination metadata (totalCount, hasMore) | 🟠 P1 | ☐ |
+| API-25 | Filter params documented and validated | 🟡 P2 | ☐ |
+
+### 2.6 Idempotency
+
+| # | Check | Severity | Status |
+|---|-------|----------|--------|
+| API-26 | Safe methods (GET) are idempotent | 🟠 P1 | ☐ |
+| API-27 | Risky create/charge operations support Idempotency-Key (if contract requires) | 🟡 P2 | ☐ |
+
+---
+
+## 3. Verification Methods
+
+### Endpoint comparison table
+
+For each documented endpoint, fill in:
+
+```markdown
+| Contract | Implementation | Match? |
+|----------|---------------|:------:|
+| POST /api/v1/coupons | routes/coupons.js:12 → couponController.create | ✅ |
+| GET /api/v1/coupons | routes/coupons.js:8 → couponController.list | ✅ |
+| PUT /api/v1/settings/:id | routes/settings.js:15 → settingsController.update | ⚠️ PATCH vs PUT |
+| DELETE /api/v1/coupons/:id | — | ❌ NOT IMPLEMENTED |
+```
+
+### Schema comparison
+
+```javascript
+// Contract says:
+// POST /coupons → { code: string, discount: number, expiresAt: string(ISO) }
+
+// Check Zod schema in middleware:
+const createCouponSchema = z.object({
+  code: z.string().min(1).max(50),      // ✅ matches
+  discount: z.number().min(0).max(100),  // ✅ matches
+  expiresAt: z.string().datetime(),      // ✅ matches
+  // ❌ Missing: 'description' field from contract
+});
+```
+
+### Error format validation
+
+```javascript
+// Contract says: { error: { code: string, message: string, details?: object } }
+
+// Check actual error handler:
+grep_search: Query="res.status(4" Includes=["*/controllers/*"]
+grep_search: Query="res.status(5" Includes=["*/controllers/*"]
+// For each: does response match { error: { code, message } } format?
+```
+
+### Grep patterns
+
+```bash
+# Find all route definitions
+grep_search: Query="router\.(get|post|put|patch|delete)" Includes=["*/routes/*"] IsRegex=true
+
+# Find status codes used
+grep_search: Query="res.status(" Includes=["*.js"]
+
+# Find error responses
+grep_search: Query="error.*code" Includes=["*/controllers/*","*/middleware/*"]
+
+# Find auth middleware usage
+grep_search: Query="auth" Includes=["*/routes/*"]
+```
+
+---
+
+## 4. Common Mismatches
+
+| Mismatch | Example | Severity | Fix |
+|----------|---------|----------|-----|
+| **Wrong status code** | POST returns 200 instead of 201 | 🟠 P1 | `res.status(201)` |
+| **Wrong method** | PUT for partial update (should be PATCH) | 🟠 P1 | Change to PATCH or justify in ADR |
+| **Error format inconsistent** | Some endpoints return `{ message }`, others `{ error: { code } }` | 🔴 P0 | Unify via error handler middleware |
+| **Missing validation** | Endpoint accepts any body shape | 🔴 P0 | Add Zod middleware |
+| **Missing fields in response** | Contract says `{ data, meta }` but returns only `{ data }` | 🟠 P1 | Add `meta` to response |
+| **Undocumented endpoint** | New endpoint exists without contract update | 🟠 P1 | Update API contracts doc |
+| **Auth on public endpoint** | Widget endpoint requires auth (should be public) | 🔴 P0 | Remove auth, verify contract |
+| **No pagination** | List returns all records | 🔴 P0 | Add pagination params |
+| **Mixed error details** | Some 400 include field errors, some don't | 🟠 P1 | Standardize `details` shape |
+
+---
+
+## 5. Output Template
+
+```markdown
+# API Contract Compliance Review
+
+**Scope:** <module/PR>
+**Reviewer:** Reviewer Agent
+**Date:** YYYY-MM-DD
+**Contract reference:** docs/api-contracts.md
+
+## Endpoint Compliance
+
+| # | Contract Endpoint | Implementation | Method | Path | Schema | Auth | Status |
+|---|------------------|---------------|:------:|:----:|:------:|:----:|:------:|
+| 1 | POST /api/v1/coupons | couponController.create | ✅ | ✅ | ✅ | ✅ | ✅ |
+| 2 | GET /api/v1/coupons | couponController.list | ✅ | ✅ | ⚠️ | ✅ | ⚠️ |
+| 3 | PUT /api/v1/settings/:id | settingsController.update | ⚠️ | ✅ | ✅ | ✅ | ⚠️ |
+| 4 | DELETE /api/v1/coupons/:id | — | — | — | — | — | ❌ |
+
+## Findings
+
+| # | Severity | Check | File:Line | Mismatch | Fix |
+|---|----------|-------|-----------|----------|-----|
+| 1 | 🔴 P0 | API-01 | — | DELETE /coupons/:id not implemented | Implement or remove from contract |
+| 2 | 🟠 P1 | API-12 | `controllers/coupon.js:35` | POST returns 200 instead of 201 | Change to `res.status(201)` |
+| 3 | 🟠 P1 | API-02 | `routes/settings.js:15` | PUT used for partial update | Change to PATCH or update contract |
+
+## Error Format Compliance
+| Endpoint | Expected Format | Actual Format | Status |
+|----------|----------------|--------------|:------:|
+| POST /coupons (400) | `{ error: { code, message, details } }` | ✅ | Pass |
+| GET /coupons (500) | `{ error: { code, message } }` | `{ message: err.message }` | ❌ Fail |
+
+## Summary
+- Endpoints: X/Y compliant (Z% coverage)
+- P0 mismatches: N
+- P1 mismatches: M
+
+## Verdict
+- ✅ COMPLIANT — all endpoints match contract
+- ⚠️ DEVIATIONS — minor mismatches to fix
+- ❌ NON-COMPLIANT — critical contract violations
+```
+
+---
+
+## See also
+- `$api_contracts` — API contract definitions (source of truth)
+- `$code_review_checklist` — general review (API section)
+- `$security_review` — auth/validation depth (SEC-06..SEC-17)
+- `$review_reference_snippets` — DO/DON'T snippets (section M)