This document captures operational security expectations that complement the reference specs in docs/specs/system_spec.md and docs/specs/test_spec.md.

• API authentication is JWT-based with access/refresh token flows (/api/auth/*).
• Passkey enrollment/login/reset routes are first-class and must remain covered by controller and E2E checks.
• Demo login must stay explicitly gated by configuration (Auth:DemoLogin:Enabled) and disabled in production-safe defaults.

• Sensitive secrets (JWT, SMTP credentials, tunnel tokens) are environment-driven and must never be hardcoded.
• Frontend error telemetry and consent-based analytics must respect runtime consent flags.
• Demo account seeding must stay disabled by default and restricted to non-production workflows.

• Seeding:EnableDemoAccount / SEED_DEMO_ACCOUNT controls demo-user creation and defaults to false.
• Auth:DemoLogin:Enabled / DEMO_LOGIN_ENABLED controls /api/auth/demo-login and defaults to false.
• VITE_DEMO_LOGIN_ENABLED controls frontend demo-login affordances and defaults to false.
• VITE_PUBLIC_TESTIMONIALS_FALLBACK_ENABLED and VITE_PUBLIC_CUSTOMER_STATS_FALLBACK_ENABLED control synthetic marketing fallback content and default to false.
• DemoAccountReadOnlyMiddleware enforces write restrictions for demo users outside development.
• Production deployments must keep demo credentials environment-specific (Auth:DemoLogin:ProductionEmail), keep fallback flags disabled unless explicitly approved, and never use shared personal accounts.

• Release-blocking quality gates are defined in docs/specs/test_spec.md (lint, build, unit, integration, e2e, manual-regression, docs-updated, ci).
• Manual regression evidence is tracked with labels curl and playwright-mcp.