chore: git cache cleanup

docs/implementation/E2E_SECURITY_ENFORCEMENT_FAILURES_SPEC.md

@@ -0,0 +1,90 @@
+## E2E Security Enforcement Failures Remediation Plan (2 Remaining)
+
+**Context**
+- Branch: `feature/beta-release`
+- Source: [docs/reports/qa_report.md](../reports/qa_report.md)
+- Failures: `/api/v1/users` setup socket hang up (Security Dashboard navigation), Emergency token baseline blocking (Test 1)
+
+## Phase 1 – Analyze (Root Cause Mapping)
+
+### Failure A: `/api/v1/users` setup socket hang up (Security Dashboard navigation)
+**Symptoms**
+- `apiRequestContext.post` socket hang up during test setup user creation in:
+  - `tests/security/security-dashboard.spec.ts` (navigation suite)
+
+**Likely Backend Cause**
+- Test setup creates an admin user via `POST /api/v1/users`, which is routed through Cerberus middleware before auth.
+- If ACL is enabled and the test runner IP is not in `security.admin_whitelist`, Cerberus will block all requests when no active ACLs exist.
+- This block can present as a socket hang up when the proxy closes the connection before Playwright reads the response.
+
+**Backend Evidence**
+- Cerberus middleware executes on all `/api/v1/*` routes: [backend/internal/api/routes/routes.go](../../backend/internal/api/routes/routes.go)
+  - `api.Use(cerb.Middleware())` and `protected.POST("/users", userHandler.CreateUser)`
+- ACL default-deny behavior and whitelist bypass: [backend/internal/cerberus/cerberus.go](../../backend/internal/cerberus/cerberus.go)
+  - `Cerberus.Middleware` and `isAdminWhitelisted`
+- User creation handler expects admin role after auth: [backend/internal/api/handlers/user_handler.go](../../backend/internal/api/handlers/user_handler.go)
+  - `UserHandler.CreateUser`
+
+**Fix Options (Backend)**
+1. Ensure ACL cannot block authenticated admin setup calls by moving Cerberus after auth for protected routes (so role can be evaluated).
+2. Add an explicit Cerberus bypass for `/api/v1/users` setup in test/dev mode when the request has a valid admin session.
+3. Require at least one allow/deny list entry before enabling ACL, and return a clear 4xx error instead of terminating the connection.
+
+### Failure B: Emergency token baseline not blocked (Test 1)
+**Symptoms**
+- Expected 403 from `/api/v1/security/status`, received 200 in:
+  - `tests/security-enforcement/emergency-token.spec.ts` (Test 1)
+
+**Likely Backend Cause**
+- ACL is enabled via `/api/v1/settings`, but Cerberus treats the request IP as whitelisted (e.g., `127.0.0.1/32`) and skips ACL enforcement.
+- The whitelist is stored in `SecurityConfig` and can persist from prior tests, causing ACL bypass for authenticated requests even without the emergency token.
+
+**Backend Evidence**
+- Admin whitelist bypass check: [backend/internal/cerberus/cerberus.go](../../backend/internal/cerberus/cerberus.go)
+  - `isAdminWhitelisted`
+- Security config persistence: [backend/internal/models/security_config.go](../../backend/internal/models/security_config.go)
+- ACL enablement via settings: [backend/internal/api/handlers/settings_handler.go](../../backend/internal/api/handlers/settings_handler.go)
+  - `SettingsHandler.UpdateSetting` auto-enables `feature.cerberus.enabled`
+
+**Fix Options (Backend)**
+1. Make ACL bypass conditional on authenticated admin context by applying Cerberus after auth on protected routes.
+2. Clear or override `security.admin_whitelist` when enabling ACL in test runs where the baseline must be blocked.
+3. Add a dedicated ACL enforcement endpoint or status check that is not exempted by admin whitelist.
+
+## Phase 2 – Focused Remediation Plan (No Code Changes Yet)
+
+### Plan A: Diagnose `/api/v1/users` socket hang up
+1. Confirm ACL and admin whitelist values immediately before test setup user creation.
+2. Check server logs for Cerberus ACL blocks or upstream connection resets during `POST /api/v1/users`.
+3. Validate that the request is authenticated and that Cerberus is not terminating the request before auth runs.
+
+**Acceptance Criteria**
+- `POST /api/v1/users` consistently returns a 2xx or a structured 4xx, not a socket hang up.
+
+### Plan B: Emergency token baseline enforcement
+1. Verify `security.admin_whitelist` contents before Test 1; ensure the test IP is not whitelisted.
+2. Confirm `security.acl.enabled` and `feature.cerberus.enabled` are both `true` after the setup PATCH.
+3. Re-run the baseline `/api/v1/security/status` request and verify 403 before applying the emergency token.
+
+**Acceptance Criteria**
+- Baseline `/api/v1/security/status` returns 403 when ACL + Cerberus are enabled.
+- Emergency token bypass returns 200 for the same endpoint.
+
+## Phase 3 – Validation Plan
+
+1. Re-run Chromium E2E suite.
+2. Verify the two failing tests pass.
+3. Capture updated results and include status evidence in QA report.
+
+## Risks & Notes
+
+- If `security.admin_whitelist` persists across suites, ACL baseline assertions will be bypassed.
+- If Cerberus runs before auth, ACL cannot distinguish authenticated admin setup calls from unauthenticated setup calls.
+
+## Next Steps
+
+- Execute the focused remediation steps above.
+- Re-run E2E tests and update [docs/reports/qa_report.md](../reports/qa_report.md).
+
+**Status**: SUSPENDED - Supersededby critical production bug (Settings Query ID Leakage)
+**Archive Date**: 2026-01-28