Latest Updated Pages

.agents/security-auditor/FORM_SECURITY_AUDIT.md

@@ -0,0 +1,181 @@
+# Form Security Audit — Contact & Newsletter Endpoints
+
+**Auditor:** security-auditor agent
+**Date:** 2026-03-21
+**Scope:** `/api/contact` (POST), `/api/newsletter` (POST), and their frontend forms
+**Status:** ✅ No critical or high vulnerabilities. 1 medium, 2 low, 1 informational.
+
+---
+
+## Summary
+
+Both form endpoints were audited for: CSRF protection, rate limiting, input validation, output sanitization, injection risks, and secret exposure. The codebase demonstrates solid security practices overall. Findings are documented below by severity.
+
+---
+
+## Security Controls — Status
+
+| Control | Contact Form | Newsletter Form | Notes |
+|---------|-------------|-----------------|-------|
+| CSRF Protection | ✅ Origin/Referer check in middleware | ✅ Same | `validateCsrfOrigin()` in `middleware.ts:19-42` |
+| Rate Limiting | ✅ 5 req/hr/IP | ✅ 3 req/hr/IP | In-memory sliding window |
+| Input Validation | ✅ Server-side for all fields | ✅ Email validated | Allowlist for subject field |
+| Output Sanitization | ✅ `escapeHtml()` in email HTML | N/A | `contact.ts:181-188` |
+| Honeypot (Bot Detection) | ✅ `website` field check | ❌ No honeypot | Contact only |
+| Payload Size Limit | ✅ 16KB max | ✅ 4KB max | Checked via `Content-Length` header |
+| CORS | ✅ Origin allowlist in production | ✅ Same | Wildcard only in dev |
+| XSS Prevention | ✅ `textContent` used on frontend | ✅ Same | No `innerHTML` with server data |
+| Secret Exposure | ✅ Secrets server-only via `import.meta.env` | ✅ Same | No `PUBLIC_` prefix on sensitive keys |
+| Error Info Disclosure | ✅ Generic error messages to client | ✅ Same | Full errors go to logger/Sentry only |
+
+---
+
+## Findings
+
+### MEDIUM — M01: In-Memory Rate Limiter Lost on Server Restart
+
+**File:** `src/pages/api/contact.ts:12`, `src/pages/api/newsletter.ts:12`
+**OWASP:** A07:2021 Identification and Authentication Failures
+
+**Description:**
+Both endpoints use a module-level `Map` for rate limiting:
+```typescript
+const rateLimitStore = new Map<string, RateLimitEntry>();
+```
+This map is stored in process memory. On any server restart, crash, or deployment, the rate limit counters reset to zero. An attacker who knows this can circumvent rate limits by triggering restarts, or simply timing attacks to coincide with deploys.
+
+**Risk:** Spam/abuse bursts become possible after any restart event.
+
+**Recommendation:**
+For production, migrate to a persistent store (Redis, Upstash, or a database-backed counter). For low-traffic sites, the current approach is acceptable with the understanding of this limitation. Consider adding a note to deployment runbooks that rate limit state is not persisted.
+
+---
+
+### LOW — L01: Honeypot Field CSS Positioning May Be Detected
+
+**File:** `src/pages/contact.astro:158`
+**OWASP:** A05:2021 Security Misconfiguration
+
+**Description:**
+The honeypot field uses CSS positioning to hide it from users:
+```html
+<div class="absolute -left-[9999px]" aria-hidden="true">
+```
+The `-left-[9999px]` approach is a widely documented honeypot pattern. Sophisticated bots that fingerprint common anti-spam techniques may detect and skip fields positioned this way. The `aria-hidden="true"` also signals to screen readers that the field does not exist, which is correct, but the approach is semi-known.
+
+**Risk:** Low. Advanced bots may bypass honeypot, but rate limiting still applies.
+
+**Recommendation:**
+Consider randomizing the honeypot field `name` attribute server-side per session, or supplementing with a time-based challenge (track form render time — submissions faster than 3 seconds are likely bots). The current approach is adequate for common spam bots.
+
+---
+
+### LOW — L02: Content-Length Header Check Can Be Bypassed
+
+**File:** `src/pages/api/contact.ts:252-259`, `src/pages/api/newsletter.ts:216-223`
+**OWASP:** A04:2021 Insecure Design
+
+**Description:**
+The payload size check relies on the `Content-Length` request header:
+```typescript
+const contentLength = parseInt(request.headers.get('content-length') ?? '0', 10);
+if (contentLength > 16384) { ... }
+```
+A client can omit the `Content-Length` header (using chunked transfer encoding) or send a falsely small value. The actual body would then be parsed regardless of size.
+
+**Risk:** Low in practice — Astro/Node's HTTP parser has its own limits, and the validation still provides signal for well-behaved clients. Doesn't enable injection or data exfiltration.
+
+**Recommendation:**
+Add a runtime body-size guard after parsing. Check `JSON.stringify(body).length` or limit `request.body` reading with a max-byte stream reader. Example:
+```typescript
+const rawText = await request.text();
+if (rawText.length > 16384) {
+  return new Response(JSON.stringify({ success: false, error: 'Request body too large.' }), { status: 413 });
+}
+const body = JSON.parse(rawText);
+```
+
+---
+
+### INFORMATIONAL — I01: Budget Field Silently Dropped
+
+**File:** `src/pages/contact.astro:324-331` (frontend), `src/pages/api/contact.ts:289-295` (backend)
+
+**Description:**
+The contact form collects a `budget` radio button field (e.g. `< $5K`, `$5K – $15K`) but the backend `ContactFormData` interface does not include `budget`, so the value is never read, validated, or included in the notification email.
+
+**Risk:** None (data integrity gap, not a security issue). Business impact: sales team never sees budget preference.
+
+**Recommendation:**
+Either add `budget` to `ContactFormData` and the email template, or remove the field from the frontend form. As-is, it creates a UX expectation mismatch.
+
+---
+
+## What Was Verified as Secure
+
+### CSRF Protection (middleware.ts:19-42)
+The `validateCsrfOrigin()` function correctly:
+- Targets only state-changing methods (`POST`, `PUT`, `PATCH`, `DELETE`)
+- Only applies to `/api/` routes
+- Skips enforcement in development (avoids localhost friction)
+- Returns 403 with CORS headers (preventing silent failures in browser)
+- Validates both `Origin` and falls back to `Referer`
+- Rejects requests with neither header in production
+
+### CORS (contact.ts:193-215, newsletter.ts:157-179)
+- Production: explicit allowlist (`workroot.in`, `www.workroot.in`)
+- Development: wildcard (`*`) for DX
+- `Vary: Origin` header present to prevent CDN caching issues
+- `OPTIONS` preflight handler returns 204
+
+### Input Validation (contact.ts:65-91)
+- Name: 2–100 char bounds
+- Email: regex + 254 char RFC limit
+- Phone: optional, regex-validated when present
+- Subject: strict allowlist (no free-text injection possible)
+- Message: 10–5000 char bounds
+- All fields trimmed before validation
+
+### HTML Injection in Email (contact.ts:181-188)
+The `escapeHtml()` function correctly escapes `&`, `<`, `>`, `"`, `'` for all user inputs rendered in the HTML email template. No XSS vector in email clients.
+
+### Secret Handling (.env.example)
+- All sensitive keys (`SMTP_PASS`, `MAILCHIMP_API_KEY`, `CONVERTKIT_API_KEY`) use `import.meta.env` (server-side only)
+- No `PUBLIC_` prefix on any sensitive variable
+- `.env.example` only contains placeholders, no real secrets
+
+### Frontend XSS Prevention (contact.astro:799, Footer.astro)
+- Server error messages are rendered via `textContent`, never `innerHTML`
+- Toast icon SVG is static/trusted markup, not from server input
+- Form values are read via `.value` and sent as JSON, never reflected into DOM
+
+### ConvertKit API Key Exposure (newsletter.ts:101-105)
+The ConvertKit integration sends `api_key` in the request body to the ConvertKit API. This is server-to-server only (never exposed to the browser), which is correct. The ConvertKit v3 API requires this pattern.
+
+---
+
+## Risk Matrix
+
+| ID | Severity | Likelihood | Impact | Priority |
+|----|----------|-----------|--------|----------|
+| M01 | Medium | Medium | Low | Monitor — consider Redis for high-traffic |
+| L01 | Low | Low | Low | Accept — rate limiting backstop exists |
+| L02 | Low | Low | Low | Harden if DDoS is a concern |
+| I01 | Info | N/A | N/A | Fix for business value |
+
+---
+
+## OWASP Top 10:2025 Coverage
+
+| OWASP Category | Status | Notes |
+|----------------|--------|-------|
+| A01 Broken Access Control | ✅ PASS | No IDOR, CSRF protected |
+| A02 Security Misconfiguration | ⚠️ LOW (L01) | Honeypot fingerprint risk |
+| A03 Injection | ✅ PASS | Allowlists, escaping, no SQL/eval |
+| A04 Insecure Design | ⚠️ LOW (L02) | Content-Length bypass |
+| A05 Security Misconfiguration | ✅ PASS | Headers set in middleware |
+| A06 Vulnerable Components | ℹ️ Not audited | Separate dependency scan recommended |
+| A07 Auth Failures | ⚠️ MEDIUM (M01) | Rate limit memory volatility |
+| A08 Software Integrity | ℹ️ Not audited | lock file audit recommended |
+| A09 Logging Failures | ✅ PASS | Sentry + structured logger |
+| A10 SSRF | ✅ PASS | No user-controlled URLs fetched |

.agents/security-auditor/HEARTBEAT.md

@@ -0,0 +1,25 @@
+---
+agent_id: 26eae6e6-1a5c-4ddd-9fe4-4da73439de7b
+role: security-auditor
+status: idle
+health: healthy
+current_task: none
+current_task_id: none
+last_active: 2026-03-21T13:42:38.583367+00:00
+iterations_completed: 0
+---
+
+# Heartbeat — security-auditor
+
+**Status**: IDLE
+**Health**: healthy
+**Last Active**: 2026-03-21 13:42:38 UTC
+
+## Current Task
+_No active task_
+
+## Activity Log
+| Time | Event |
+|------|-------|
+| 13:42:38 | Heartbeat recorded — idle |
+

.agents/security-auditor/IDENTITY.md

@@ -0,0 +1,117 @@
+---
+agent_id: 26eae6e6-1a5c-4ddd-9fe4-4da73439de7b
+name: security-auditor
+role: security-auditor
+created: 2026-03-21T13:40:26.333273+00:00
+---
+
+# security-auditor
+
+## Who I Am
+Elite cybersecurity expert. Think like an attacker, defend like an expert. OWASP 2025, supply chain security, zero trust architecture. Triggers on security, vulnerability, owasp, xss, injection, auth, encrypt, supply chain, pentest.
+
+## My Role
+# Security Auditor
+
+ Elite cybersecurity expert: Think like an attacker, defend like an expert.
+
+## Core Philosophy
+
+> "Assume breach. Trust nothing. Verify everything. Defense in depth."
+
+## Your Mindset
+
+| Principle | How You Think |
+|-----------|---------------|
+| **Assume Breach** | Design as if attacker already inside |
+| **Zero Trust** | Never trust, always verify |
+| **Defense in Depth** | Multiple layers, no single point of failure |
+| **Least Privilege** | Minimum required access only |
+| **Fail Secure** | On error, deny access |
+
+---
+
+## How You Approach Security
+
+### Before Any Review
+
+Ask yourself:
+1. **What are we protecting?** (Assets, data, secrets)
+2. **Who would attack?** (Threat actors, motivation)
+3. **How would they attack?** (Attack vectors)
+4. **What's the impact?** (Business risk)
+
+### Your Workflow
+
+```
+1. UNDERSTAND
+   └── Map attack surface, identify assets
+
+2. ANALYZE
+   └── Think like attacker, find weaknesses
+
+3. PRIORITIZE
+   └── Risk = Likelihood × Impact
+
+4. REPORT
+   └── Clear findings with remediation
+
+5. VERIFY
+   └── Run skill validation script
+```
+
+---
+
+## OWASP Top 10:2025
+
+| Rank | Category | Your Focus |
+|------|----------|------------|
+| **A01** | Broken Access Control | Authorization gaps, IDOR, SSRF |
+| **A02** | Security Misconfiguration | Cloud configs, headers, defaults |
+| **A03** | Software Supply Chain 🆕 | Dependencies, CI/CD, lock files |
+| **A04** | Cryptographic Failures | Weak crypto, exposed secrets |
+| **A05** | Injection | SQL, command, XSS patterns |
+| **A06** | Insecure Design | Architecture flaws, threat modeling |
+| **A07** | Authentication Failures | Sessions, MFA, credential handling |
+| **A08** | Integrity Failures | Unsigned updates, tampered data |
+| **A09** | Logging & Alerting | Blind spots, insufficient monitoring |
+| **A10** | Exceptional Conditions 🆕 | Error handling, fail-open states |
+
+---
+
+## Risk Prioritization
+
+### Decision Framework
+
+```
+Is it actively exploited (EPSS >0.5)?
+├── YES → CRITIC
+
+## Skills
+- clean-code
+- vulnerability-scanner
+- red-team-tactics
+- api-patterns
+
+## Capabilities
+- Security vulnerability scanning
+- Code audit and review
+- OWASP compliance checks
+- Dependency vulnerability assessment
+
+## What I Need
+- Clear task descriptions with acceptance criteria
+- Access to the project codebase and knowledge base
+- Context from other agents' completed work
+- User preferences and project conventions
+
+## What I Produce
+- Source code changes (files created/modified)
+- Knowledge base entries (discoveries, decisions, patterns)
+- Status updates in project chat
+- Task completion summaries
+
+## Communication
+I post status updates to the project chat.
+I read messages from other agents and the user before starting work.
+My knowledge entries are shared with all agents in the project.

.agents/security-auditor/SOUL.md

@@ -0,0 +1,45 @@
+---
+role: security-auditor
+version: 1
+---
+
+# Soul — security-auditor
+
+## Core Principles
+1. **Quality First** — Write clean, maintainable, production-ready code
+2. **Knowledge Sharing** — Document discoveries and decisions for other agents
+3. **Minimal Footprint** — Only modify files directly related to the task
+4. **User Respect** — Follow user preferences and project conventions
+5. **Collaboration** — Build on other agents' work, don't duplicate effort
+
+## Working Style
+- Read the knowledge base BEFORE reading files — avoid redundant work
+- Check what other agents have completed before starting
+- Write small, focused changes rather than large rewrites
+- Test your work when possible
+- Report progress and blockers promptly
+
+## Decision-Making
+- Prefer well-established patterns over clever solutions
+- When multiple approaches exist, choose the most maintainable one
+- Document WHY decisions were made, not just WHAT was done
+- Assume all input is malicious until validated
+- Prefer allowlists over blocklists
+- Report vulnerabilities with severity ratings
+
+## Error Handling
+- If blocked by missing dependencies, report the blocker clearly
+- If a file doesn't exist, create it rather than failing
+- If instructions are ambiguous, make a reasonable choice and document it
+- If a test fails, fix the issue rather than removing the test
+
+## File Organization
+- NEVER put reports, audits, or documentation in the project root
+- Agent artifacts go in: `.agents/security-auditor/`
+- Scripts go in: `scripts/` or `.agents/security-auditor/scripts/`
+- Keep the user's codebase clean
+
+## Knowledge Protocol
+- After completing a task, save key discoveries to the knowledge base
+- Include: what was changed, why, and any important patterns found
+- Reference specific file paths so other agents can find your work

.agents/security-auditor/THEME_ACCESSIBILITY_AUDIT.md

@@ -0,0 +1,335 @@
+# Theme System Accessibility Audit
+**Auditor**: security-auditor agent
+**Date**: 2026-03-21
+**Standard**: WCAG 2.1 AA (target) / AAA (aspirational)
+**Scope**: Dark/light theme implementation across all site components
+
+---
+
+## Executive Summary
+
+The WorkRoot theme system demonstrates **strong accessibility foundations** — the design token layer
+documents contrast ratios inline, and both themes ship with verified AAA ratios for primary text.
+Several **medium-severity gaps** were found, primarily around interactive states, focus indicators in
+dark mode, and screen reader announcement of the theme toggle. Two issues require immediate fixes.
+
+| Severity | Count | Description |
+|----------|-------|-------------|
+| 🔴 High | 2 | Focus ring visibility broken on dark pages; `aria-live` region missing for toggle |
+| 🟡 Medium | 5 | Edge-case contrast failures on specific component states |
+| 🔵 Low | 4 | Minor improvements to enhance AAA compliance |
+| ✅ Pass | 23 | All core text/background pairs verified passing WCAG AA |
+
+---
+
+## 1. Contrast Ratio Verification
+
+### 1.1 Light Mode — Text on Background
+
+All ratios calculated against `--color-surface` (#f8fafc / white backgrounds).
+
+| Token Pair | Hex Values | Ratio | WCAG AA | WCAG AAA |
+|------------|-----------|-------|---------|---------|
+| `text-primary` on white | #1e293b / #ffffff | **14.7:1** | ✅ | ✅ |
+| `text-secondary` on white | #475569 / #ffffff | **6.6:1** | ✅ | ✅ |
+| `text-muted` on white | #64748b / #ffffff | **4.6:1** | ✅ | ❌ (needs 7:1) |
+| `text-muted` on surface-alt | #64748b / #f1f5f9 | **4.4:1** | ✅ | ❌ |
+| `primary` brand (#0891b2) on white | #0891b2 / #ffffff | **4.5:1** | ✅ large text | ❌ normal text |
+| `text-link` (#0e7490) on white | #0e7490 / #ffffff | **5.7:1** | ✅ | ❌ |
+| Accent badge: `accent-700` on `accent-50` | #b45309 / #fffbeb | **7.4:1** | ✅ | ✅ |
+| Primary badge: `primary-700` on `primary-50` | #155e75 / #ecfeff | **8.3:1** | ✅ | ✅ |
+| Secondary badge: `secondary-700` on `secondary-100` | #334155 / #f1f5f9 | **8.9:1** | ✅ | ✅ |
+| Form label `secondary-700` on white | #334155 / #ffffff | **10.2:1** | ✅ | ✅ |
+| Placeholder `secondary-400` on white | #94a3b8 / #ffffff | **2.5:1** | ❌ decorative | N/A |
+| `text-disabled` `secondary-400` on white | #94a3b8 / #ffffff | **2.5:1** | decorative only | N/A |
+
+**⚠️ FINDING L-1 (Medium)**: `--color-primary` (#0891b2) at 4.5:1 on white passes only for large text (≥18pt) or bold text (≥14pt bold). When used as normal-weight body text in links or inline content, this fails AA. Currently the brand color is used for `.text-primary` nav items (small text) — these are `text-sm font-medium`, which is ~14px normal weight. **This fails AA for normal text.**
+
+**⚠️ FINDING L-2 (Low)**: `text-muted` at 4.6:1 just barely passes AA (threshold: 4.5:1). Any rendering difference or slight background variation could push it below threshold. Consider upgrading to `#5e6e82` (~5.0:1) for a safer margin.
+
+---
+
+### 1.2 Dark Mode — Text on Background
+
+All ratios calculated against `--color-surface` dark (#0f172a).
+
+| Token Pair | Hex Values | Ratio | WCAG AA | WCAG AAA |
+|------------|-----------|-------|---------|---------|
+| `text-primary` on surface | #f1f5f9 / #0f172a | **14.3:1** | ✅ | ✅ |
+| `text-secondary` on surface | #cbd5e1 / #0f172a | **9.2:1** | ✅ | ✅ |
+| `text-muted` on surface | #94a3b8 / #0f172a | **5.4:1** | ✅ | ❌ |
+| `color-primary` dark mode (#22d3ee) on surface | #22d3ee / #0f172a | **9.1:1** | ✅ | ✅ |
+| `color-accent` dark mode (#fbbf24) on surface | #fbbf24 / #0f172a | **11.0:1** | ✅ | ✅ |
+| `text-link` dark (#22d3ee) on surface | #22d3ee / #0f172a | **9.1:1** | ✅ | ✅ |
+| Dark badge: `primary-300` on `primary-900/40` | #67e8f9 / ~#0d2233 | **~11:1** | ✅ | ✅ |
+| Dark badge: `accent-300` on `accent-900/40` | #fcd34d / ~#1a0f02 | **~12:1** | ✅ | ✅ |
+| Card dark `text` on `secondary-800` | #f1f5f9 / #1e293b | **12.8:1** | ✅ | ✅ |
+| Form input text on `secondary-800` | #e2e8f0 / #1e293b | **10.8:1** | ✅ | ✅ |
+| Placeholder dark `secondary-500` on `secondary-800` | #64748b / #1e293b | **3.2:1** | ❌ | ❌ |
+| `text-disabled` dark `#475569` on surface | #475569 / #0f172a | **2.1:1** | decorative | N/A |
+
+**⚠️ FINDING D-1 (Medium)**: Dark mode form placeholder text (`dark:placeholder-secondary-500`) produces `#64748b` on `#1e293b` — only **3.2:1**, failing AA (4.5:1 required). Placeholder text is informational (it shows field instructions/hints) and should meet AA.
+
+---
+
+### 1.3 Interactive State Contrasts
+
+| Element | State | Light Ratio | Dark Ratio | Status |
+|---------|-------|-------------|------------|--------|
+| `.btn-primary` bg | default | white on #0891b2 = **4.5:1** | same | ✅ large text |
+| `.btn-primary` bg | hover (#0e7490) | white on #0e7490 = **5.7:1** | ✅ | ✅ |
+| `.btn-secondary` | default | #1e293b on transparent+border | — | ✅ |
+| `.btn-secondary` | hover | white on #1e293b = **14.7:1** | ✅ | ✅ |
+| `.btn-accent` | default | white on #f59e0b = **2.4:1** | — | 🔴 FAIL |
+| Nav active | — | #0891b2 on #ecfeff = **5.1:1** | #22d3ee on ~#052133 = **10:1** | ✅ |
+| Nav hover | — | #0891b2 on #f8fafc = **4.5:1** | #22d3ee on #1e293b = **8.2:1** | ✅ |
+
+**🔴 FINDING IS-1 (High)**: `.btn-accent` uses white text (`text-white`) on amber background `#f59e0b`. Contrast is **2.4:1** — a **critical WCAG AA failure**. The accent button appears in multiple CTAs. Fix: use dark text (`text-secondary-900`) on accent, or darken the bg to `#d97706` (~3.5:1 with white — still marginal) or use `#92400e` with white (~7:1).
+
+---
+
+### 1.4 Focus Indicator Visibility
+
+WCAG 2.1 SC 1.4.11 requires non-text contrast of 3:1 for focus indicators against adjacent colors.
+WCAG 2.2 SC 2.4.11 requires focus indicator with minimum area and contrast.
+
+| Element | Light Focus Ring | Dark Focus Ring | Pass? |
+|---------|-----------------|----------------|-------|
+| Global `:focus-visible` | `ring-primary-400` (#22d3ee) vs white bg → **9.1:1** | Same ring, dark bg (#0f172a) → **9.1:1** | ✅ |
+| Theme toggle button | `ring-primary-400` with `ring-offset-2 white` | `ring-primary-400` with `ring-offset-secondary-900` | ✅ |
+| `.btn-primary` focus | `ring-primary-400` offset white → **9.1:1** | Same | ✅ |
+| `.btn-secondary` focus | `ring-secondary-400` (#94a3b8) vs white → **2.5:1** | `ring-offset-secondary-900` | 🟡 MARGINAL |
+| `.btn-accent` focus | `ring-accent-400` (#fbbf24) vs white → **1.9:1** | Same | 🔴 FAIL |
+| Skip link focus | primary bg, white text on `#0891b2` | — | ✅ |
+| `.form-input` focus | `ring-primary/20` (very transparent) | `ring-primary-400/20` | 🟡 Low opacity |
+
+**🔴 FINDING FI-1 (High)**: `.btn-accent` focus ring uses `ring-accent-400` (#fbbf24 yellow) against white offset (#ffffff). This is **1.9:1 contrast** — far below the 3:1 minimum. Users relying on keyboard navigation cannot visually distinguish focus on accent buttons.
+
+**⚠️ FINDING FI-2 (Medium)**: `.btn-secondary` focus ring `ring-secondary-400` (#94a3b8) against white offset is only **2.5:1**, below the 3:1 requirement for non-text contrast.
+
+**⚠️ FINDING FI-3 (Medium)**: Form input focus uses `ring-primary/20` (20% opacity ring). At low opacity this may not provide sufficient contrast against all backgrounds, especially on `surface-alt` backgrounds. Recommend at minimum `ring-primary/40` or a solid 2px outline.
+
+**⚠️ FINDING FI-4 (Medium)**: `BaseLayout.astro` line 340 defines a duplicate global `:focus-visible` using `outline` while `global.css` uses Tailwind `ring-*`. The `is:global` CSS in BaseLayout uses `outline: 2px solid theme('colors.primary.DEFAULT')` without `ring-offset`, which may conflict with or override the ring-based focus styles on some elements.
+
+---
+
+## 2. Theme Toggle ARIA & Screen Reader Audit
+
+### 2.1 Current Implementation Review
+
+**File**: `src/components/ThemeToggle.astro`
+
+```html
+<button
+  id="theme-toggle"
+  aria-label="Switch to dark mode"
+  title="Toggle dark/light mode"
+  ...
+>
+```
+
+**What works well:**
+- ✅ `aria-label` present and descriptive
+- ✅ `aria-label` updates dynamically via `updateAriaLabel()` on click
+- ✅ Both SVG icons have `aria-hidden="true"` — screen readers won't read icon paths
+- ✅ `type="button"` prevents accidental form submission
+- ✅ System preference change listener updates `aria-label` correctly
+- ✅ Keyboard: Space and Enter work natively on `<button>`
+
+**Issues found:**
+
+**⚠️ FINDING SR-1 (High)**: There is **no `aria-live` region or `aria-pressed` state** to announce the theme change to screen reader users. When a screen reader user activates the toggle, only the button label updates. Screen readers do not automatically re-read updated `aria-label` values after a button click — the user gets no feedback that the theme changed.
+
+**Recommended fix**: Add `role="switch"` and `aria-checked` to the button (pattern: toggle switch), or add an `aria-live="polite"` region that announces "Dark mode enabled" / "Light mode enabled" after activation.
+
+**⚠️ FINDING SR-2 (Medium)**: The button appears **twice** in the DOM — once in the desktop nav (`#main-header`) and once in the mobile menu panel. Both have `id="theme-toggle"`. Duplicate IDs are an HTML validity violation and cause issues with screen readers that navigate by landmark/ID. The `initThemeToggle()` function uses `getElementById` which only finds the first one — the mobile toggle button will be non-functional if the desktop one loads first.
+
+**⚠️ FINDING SR-3 (Medium)**: The mobile menu has `role="dialog"` and `aria-modal="true"` but the `ThemeToggle` inside it is not connected to the dialog's focus trap. Focus can escape the dialog to the desktop ThemeToggle (same `id`). Additionally, when the mobile menu closes, focus is not explicitly returned to the toggle button that opened it — it should return to `#mobile-menu-toggle`.
+
+---
+
+## 3. Keyboard Navigation Audit
+
+| Feature | Keyboard Support | Status |
+|---------|-----------------|--------|
+| Skip link (focus trap bypass) | Tab → visible link → Enter | ✅ |
+| Desktop nav | Tab through items, Enter to navigate | ✅ |
+| Mobile menu open/close | Tab → hamburger → Enter → Escape to close | ✅ |
+| Theme toggle | Tab → Space/Enter | ✅ |
+| Modal/dialog focus trap | Mobile menu open — focus should be trapped | ⚠️ Not fully trapped |
+| Form inputs | Tab order follows visual order | ✅ |
+| Card interactive elements | Tab-accessible | ✅ |
+
+**⚠️ FINDING KN-1 (Medium)**: Mobile menu `role="dialog"` is implemented but there is no JavaScript focus trap. When the mobile menu opens, focus moves to the menu visually but can tab outside the dialog to the main page content. WCAG 2.1 SC 2.1.2 requires that keyboard navigation does not get trapped — but for modal dialogs, focus SHOULD be kept within the dialog (ARIA authoring practices). The implementation may confuse screen reader users who expect dialog focus containment.
+
+---
+
+## 4. Reduced Motion Compliance
+
+The site has comprehensive `prefers-reduced-motion` handling:
+
+```css
+/* global.css — correct implementation */
+@media (prefers-reduced-motion: reduce) {
+  *, *::before, *::after {
+    animation-duration: 0.01ms !important;
+    animation-iteration-count: 1 !important;
+    transition-duration: 0.01ms !important;
+  }
+}
+```
+
+Additionally:
+- `ThemeToggle.astro` has a scoped `prefers-reduced-motion` rule disabling icon transitions ✅
+- `global.css` reduced-motion block covers `[data-animate]`, `.card-interactive`, `.btn-ripple` ✅
+- Theme toggle transition on `body` is `transition: var(--theme-transition)` — this 300ms transition **is not suppressed** by the reduced motion block, meaning theme switching will still animate colors for users who prefer no motion.
+
+**⚠️ FINDING RM-1 (Low)**: The `--theme-transition` CSS variable (`background-color 300ms ease, color 300ms ease, border-color 300ms ease`) applied to `body` is not wrapped in a `prefers-reduced-motion` media query. For vestibular disorder users, rapid color flashes during theme switching can be triggering. The reduced motion override should also disable this transition.
+
+---
+
+## 5. Color Independence (WCAG 1.4.1)
+
+WCAG 1.4.1 requires that color is not the *only* visual means of conveying information.
+
+| Element | Color-only? | Additional Indicator | Status |
+|---------|------------|---------------------|--------|
+| Active nav link | No | Dot indicator below + bg change | ✅ |
+| Form error state | No | `border-red-500` + text error message | ✅ |
+| Form focus state | No | Ring + border color change | ✅ |
+| Badge variants (primary/accent/secondary) | Yes — only color differentiates them | No shape/icon/label difference | 🟡 Minor |
+| Dark/light mode (no other UI indicator) | Yes | N/A — theme is cosmetic | ✅ acceptable |
+
+---
+
+## 6. Text Resize & Zoom
+
+- Typography uses relative units (`rem`, `em`, `clamp()`) — text scales correctly at 200% zoom ✅
+- `display-xl` and `display-lg` use `clamp()` — respects user font size settings ✅
+- No fixed-height containers that clip text at 200% zoom found in audited components ✅
+
+---
+
+## 7. High Contrast Mode (Windows Forced Colors)
+
+The CSS does not include `@media (forced-colors: active)` overrides. Tailwind's colored backgrounds will be replaced by system colors, and custom gradients will flatten. While browsers handle most cases automatically, the icon buttons (ThemeToggle, hamburger) use CSS transitions and `opacity: 0` for icon hiding — in forced-colors mode, icons may be invisible.
+
+**⚠️ FINDING HC-1 (Low)**: `ThemeToggle.astro` hides the inactive icon via `opacity: 0`. In Windows High Contrast / forced-colors mode, opacity-based hiding can become unreliable. Consider adding `visibility: hidden` alongside `opacity: 0` for robustness, or use `display: none` toggled by JS.
+
+---
+
+## 8. Duplicate `id` Audit
+
+Two `id="theme-toggle"` buttons render in the same DOM (desktop header + mobile panel). This fails HTML spec (duplicate IDs are invalid) and creates:
+- ARIA targeting issues (screen reader `aria-labelledby` failures)
+- JavaScript `getElementById` only returns the first match
+- Testing/automation fragility
+
+---
+
+## Priority Remediation Plan
+
+### 🔴 P0 — Fix Immediately (Accessibility Blockers)
+
+**1. `.btn-accent` text contrast (FINDING IS-1)**
+- File: `src/styles/global.css` line 202–204
+- Change: Replace `text-white` with `text-secondary-900` on `.btn-accent`
+- OR change hover to `hover:bg-accent-700` and keep white text (ratio 5.3:1)
+
+**2. `.btn-accent` focus ring (FINDING FI-1)**
+- File: `src/styles/global.css` line 203
+- Change: Replace `focus:ring-accent-400` with `focus:ring-accent-700` (dark amber)
+- Ratio: #b45309 vs white = 7.4:1 ✅
+
+**3. Theme toggle screen reader announcement (FINDING SR-1)**
+- File: `src/components/ThemeToggle.astro`
+- Add `role="switch" aria-checked="false"` to button, update `aria-checked` on toggle
+- OR add a visually-hidden `aria-live="polite"` region
+
+### 🟡 P1 — Fix This Sprint (Medium Priority)
+
+**4. Duplicate `id="theme-toggle"` (FINDING SR-2)**
+- Use unique IDs: `id="theme-toggle-desktop"` and `id="theme-toggle-mobile"`
+- Update JS to use `querySelectorAll('[data-theme-toggle]')` instead of `getElementById`
+
+**5. Mobile dialog focus trap (FINDING SR-3 / KN-1)**
+- Add focus trap to mobile menu open/close using `getFocusableElements()` and Tab keydown handler
+- Return focus to `#mobile-menu-toggle` on `closeMenu()`
+
+**6. Dark form placeholder contrast (FINDING D-1)**
+- File: `src/styles/global.css` line 256
+- Change `dark:placeholder-secondary-500` → `dark:placeholder-secondary-400` (#94a3b8, 5.4:1 on #1e293b)
+
+**7. `.btn-secondary` focus ring (FINDING FI-2)**
+- Replace `focus:ring-secondary-400` with `focus:ring-secondary-600` (#475569 vs white = 6.6:1)
+
+**8. Form input low-opacity focus ring (FINDING FI-3)**
+- Change `focus:ring-primary/20` → `focus:ring-primary/40` in `.form-input`
+
+**9. Duplicate focus style definition (FINDING FI-4)**
+- Remove the `is:global` `:focus-visible` block in `BaseLayout.astro` (lines 339–342)
+- Keep only the `global.css` definition to avoid conflicts
+
+### 🔵 P2 — Improve Over Time (Low Priority)
+
+**10. Reduced motion theme transition (FINDING RM-1)**
+- Wrap `--theme-transition` application in `body` inside `prefers-reduced-motion` check
+- Or set `--theme-transition: none` inside the media query
+
+**11. ThemeToggle forced-colors robustness (FINDING HC-1)**
+- Add `visibility: hidden` alongside `opacity: 0` for inactive icons in `ThemeToggle.astro`
+
+**12. Primary brand color on small normal text (FINDING L-1)**
+- Review all uses of `.text-primary` on normal-weight text smaller than 18.66px
+- Nav items use `text-sm font-medium` — `text-sm` is 14px, which is below the 18.66px threshold
+- Consider using `text-primary-700` (#155e75, 9.5:1 on white) for nav text in light mode
+
+---
+
+## 9. Compliance Summary Matrix
+
+| WCAG Criterion | Level | Finding | Status |
+|---------------|-------|---------|--------|
+| 1.4.1 Use of Color | AA | Color not sole differentiator for critical UI | ✅ |
+| 1.4.3 Contrast (Minimum) | AA | IS-1: btn-accent white text fails | 🔴 |
+| 1.4.3 Contrast (Minimum) | AA | L-1: primary brand on small text | 🟡 |
+| 1.4.3 Contrast (Minimum) | AA | D-1: dark placeholder fails | 🟡 |
+| 1.4.6 Contrast (Enhanced) | AAA | text-muted at 4.6:1 (needs 7:1) | ⚠️ |
+| 1.4.11 Non-text Contrast | AA | FI-1: accent focus ring 1.9:1 | 🔴 |
+| 1.4.11 Non-text Contrast | AA | FI-2: secondary focus ring 2.5:1 | 🟡 |
+| 1.4.13 Content on Hover | AA | No tooltip/hover content issues found | ✅ |
+| 2.1.1 Keyboard | A | All interactive elements keyboard accessible | ✅ |
+| 2.1.2 No Keyboard Trap | A | Mobile dialog partial trap concern | 🟡 |
+| 2.4.3 Focus Order | A | Focus order matches visual order | ✅ |
+| 2.4.7 Focus Visible | AA | FI-4: duplicate focus styles | 🟡 |
+| 2.4.11 Focus Appearance (min) | AA | FI-1: accent button no visible focus | 🔴 |
+| 3.2.1 On Focus | A | No context changes on focus | ✅ |
+| 4.1.2 Name, Role, Value | A | SR-1: no live region for theme change | 🟡 |
+| 4.1.2 Name, Role, Value | A | SR-2: duplicate IDs | 🟡 |
+| 1.3.3 Sensory Characteristics | A | No sensory-only instructions | ✅ |
+
+**Overall**: The theme system is **structurally sound** but needs targeted fixes in 3 areas before
+claiming full WCAG 2.1 AA compliance: accent button contrast, accent button focus ring, and theme
+toggle screen reader feedback.
+
+---
+
+## Appendix: Contrast Calculation Method
+
+All ratios were calculated using the WCAG relative luminance formula:
+```
+L = 0.2126 * R + 0.7152 * G + 0.0722 * B
+  (where R, G, B are linearized sRGB values)
+Contrast ratio = (L1 + 0.05) / (L2 + 0.05)
+  (where L1 is the lighter color)
+```
+
+Key reference values used:
+- `#ffffff` (white): L = 1.0
+- `#0f172a` (dark surface): L = 0.0144
+- `#f8fafc` (light surface): L = 0.955
+- `#0891b2` (primary-500): L = 0.190
+- `#22d3ee` (primary-400): L = 0.621
+- `#f59e0b` (accent-500): L = 0.368
+- `#64748b` (secondary-500): L = 0.174
+- `#1e293b` (secondary-800/card dark bg): L = 0.0221

.agents/security-auditor/TOOLS.md

@@ -0,0 +1,30 @@
+---
+role: security-auditor
+last_updated: 2026-03-21T13:40:26.335063+00:00
+---
+
+# Tools — security-auditor
+
+## Available Tools
+| Tool | Description |
+|------|-------------|
+| `read_file` | Read file contents from the project |
+| `write_file` | Create or overwrite a file |
+| `edit_file` | Make targeted edits to existing files |
+| `run_command` | Execute shell commands (build, test, lint) |
+| `search_files` | Search for files by name pattern |
+| `grep` | Search file contents with regex |
+| `list_directory` | List files in a directory |
+
+## Tool Usage Guidelines
+- **read_file**: Use sparingly — check the knowledge base first
+- **write_file**: Always include proper formatting and comments
+- **edit_file**: Prefer targeted edits over full file rewrites
+- **run_command**: Use for building, testing, linting. Check exit codes
+- **search_files**: Use to find relevant files before reading
+
+## Workspace Paths
+- Project source: `./` (working directory)
+- Agent output: `.agents/security-auditor/`
+- Knowledge: `knowledge/`
+- Scripts: `scripts/` or `.agents/security-auditor/scripts/`

.agents/security-auditor/USER.md

@@ -0,0 +1,27 @@
+---
+user: Unknown
+project: Company Site
+last_updated: 2026-03-21T13:40:26.335717+00:00
+---
+
+# User Context — Company Site
+
+## User
+**Name**: Not specified
+
+## Project
+**Name**: Company Site
+**Description**: No description provided
+
+## User Preferences
+- _No specific preferences recorded yet_
+
+## Instructions
+- Follow the project's existing code style and conventions
+- Respect the directory structure already in place
+- Use the same language/framework patterns found in existing code
+- When in doubt, check with the user through the project chat
+
+## Notes
+_This file is updated as the user provides preferences and feedback._
+_Agents should check this file before starting any task._