test(e2e): stabilize Phase 2 runs — disable dev webServer by default, increase API timeouts, retry navigation and harden dialog interactions

docs/plans/current_spec.md

@@ -257,6 +257,8 @@ cd /projects/Charon
 npx playwright test tests/global-setup.ts tests/auth.setup.ts --project=firefox
 
 # PHASE 2: Core UI, Settings, Tasks, Monitoring
+# NOTE: PLAYWRIGHT_SKIP_SECURITY_DEPS=1 is automatically set in E2E scripts
+# Security suites will NOT execute as dependencies
 npx playwright test tests/core --project=firefox
 npx playwright test tests/settings --project=firefox
 npx playwright test tests/tasks --project=firefox

docs/plans/phase_2_failure_analysis.md

@@ -0,0 +1,42 @@
+# Phase 2 E2E Failure Analysis (2026-02-09)
+
+## Overview
+Phase 2 commands (tests/core, tests/settings, tests/tasks, tests/monitoring) executed security test suites and then hit widespread ACL/auth failures. The failures are consistent across 2A/2B/2C and point to security modules being enabled during Phase 2, despite Phase 1 reporting a successful security reset.
+
+## Evidence From E2E Remediation Checklist
+- Phase 2A/2B/2C failures show ACL blocks and auth errors during non-security runs, e.g.:
+  - "Failed to create user: {\"error\":\"Blocked by access control list\"}"
+  - "Failed to get security status: 403 {\"error\":\"Blocked by access control list\"}"
+  - "Failed to get security status: 401 {\"error\":\"Authorization header required\"}"
+- Phase 2A/2B/2C failure lists are dominated by security suite test files, for example:
+  - tests/security/waf-config.spec.ts
+  - tests/security/security-dashboard.spec.ts
+  - tests/security-enforcement/rate-limit-enforcement.spec.ts
+
+## Root Cause Hypotheses (Most Likely)
+1) Playwright dependency chain forces security tests to run for Phase 2
+   - In playwright.config.js, the browser projects (chromium/firefox/webkit) declare dependencies as:
+     - browserDependencies = ['setup', 'security-tests'] unless PLAYWRIGHT_SKIP_SECURITY_DEPS=1
+   - Running `npx playwright test tests/core --project=firefox` triggers dependencies for the firefox project, so Playwright executes the security-tests project (security/ and security-enforcement/ suites) before the targeted Phase 2 directory. This explains why security tests appear during Phase 2 commands.
+
+2) Security teardown likely did not execute after security tests failed
+   - The security-tests project declares teardown: 'security-teardown'. If security-tests fails early (as reported), teardown may not run, leaving Cerberus/ACL/WAF/rate limiting enabled. That would cause Phase 2 API calls (user creation, security status checks, admin login) to be blocked by ACL, matching the 403/401 errors seen in Phase 2.
+
+3) Auth state is valid for UI but blocked for API due to active security enforcement
+   - The 401 "Authorization header required" indicates unauthenticated API calls during security enforcement tests. Combined with ACL blocks, this suggests the system was in security-enforced mode, so normal Phase 2 setup actions (creating users, toggling settings) could not proceed. This is consistent with the security suite running unexpectedly and leaving enforcement active.
+
+## Recommendation
+Phase 2 is blocked until the Playwright dependency configuration is addressed or bypassed for Phase 2 runs.
+- Confirm whether PLAYWRIGHT_SKIP_SECURITY_DEPS=1 is required for Phase 2 commands.
+- Verify that security-teardown ran after the dependency tests or explicitly run the security reset before Phase 2.
+- Re-run Phase 2 only after validating that security modules are disabled and auth is functional.
+
+## Next Steps for Engineering Director
+1) Validate Playwright dependency behavior with the current config:
+   - Confirm that running a single project with --project=firefox triggers security-tests dependencies by design.
+2) Decide on a formal Phase 2 execution path:
+   - Option A: Require PLAYWRIGHT_SKIP_SECURITY_DEPS=1 for Phase 2 runs.
+   - Option B: Add a dedicated Phase 2 project without security-test dependencies.
+3) Add a pre-Phase 2 system state verification step:
+   - Ensure security modules are disabled and admin whitelist is clear before running Phase 2.
+4) Document the dependency requirement in Phase 2 run instructions so this does not repeat.

docs/plans/phase_2_fix_plan.md

@@ -0,0 +1,189 @@
+# Phase 2 E2E Failure Fix Plan
+
+## 1. Introduction
+
+This plan analyzes Phase 2 E2E failures from the remediation checklist and
+prioritizes fixes that unblock the most tests. It focuses on shared root
+causes, dependency clusters, and ownership for targeted remediation.
+
+## 2. Research Findings
+
+### 2.1 Source of Truth
+
+Primary input: [E2E_REMEDIATION_CHECKLIST.md](../../E2E_REMEDIATION_CHECKLIST.md)
+(Phase 2A, 2B, 2C failures).
+
+### 2.2 Failure Clusters
+
+- Core UI Docker integration: 2 failures on missing/blocked connection source
+  control.
+- Settings notifications: 7 failures with timeouts or page context closure.
+- Settings strict-mode collisions: 5 failures from over-broad selectors.
+- Tasks log viewing: 12 timeouts waiting for log responses.
+- Caddy import sessions: 3 failures (import results and missing session banner).
+- Monitoring real-time logs: 19 failures with WebSocket status stuck at
+  Disconnected.
+- Wait-helpers: 1 failure waiting for URL string match.
+
+## 3. Root Cause Categorization
+
+### 3.1 Failure Buckets (54 total)
+
+| Bucket | Count | Examples |
+| --- | --- | --- |
+| Backend API issues | 24 | Notifications CRUD/timeouts, system settings save, Caddy import results, log viewing API timeouts |
+| Frontend UI issues | 3 | Docker integration control missing, certificate email validation state |
+| WebSocket issues | 19 | Real-time logs never connect (Disconnected state persists) |
+| Test infrastructure issues | 6 | Strict-mode collisions (selectors), wait-helpers URL timeout |
+| Admin access/permissions issues | 2 | Guest visibility of backup button, permissions uncheck disabled |
+
+### 3.2 Root Cause Patterns
+
+- Logs viewing failures (12) all timeout on `page.waitForResponse`, indicating
+  a shared logs API endpoint not returning or blocked in Docker mode.
+- Real-time logs failures (19) all show Disconnected, indicating WebSocket
+  handshake or server-side streaming not established for `/api/v1/logs`.
+- Caddy import failures cluster on missing import session artifacts (no banner
+  and zero parsed imports), suggesting a shared import-session persistence or
+  retrieval issue.
+- Settings notifications failures cluster on timeouts and context closure,
+  suggesting API routes or navigation errors when provider lists/templates
+  are queried or mutated.
+- Strict-mode collisions in settings and monitoring point to test selectors
+  resolving multiple nodes, indicating test infra refinement needed.
+- Admin access failures show inconsistent RBAC enforcement between UI
+  visibility and server-side enforcement.
+
+## 4. Technical Specifications
+
+### 4.1 Priority Ranking (Max Impact First)
+
+1. WebSocket connection failures for real-time logs (19 tests blocked)
+2. Logs API timeouts for static log viewing (12 tests blocked)
+3. Notifications settings API timeouts/context closure (7 tests blocked)
+4. Caddy import session persistence/results (3 tests blocked)
+5. Docker integration UI controls missing (2 tests blocked)
+6. Strict-mode collisions and wait-helpers (6 tests blocked)
+7. Admin access/permissions mismatches (2 tests blocked)
+
+### 4.2 Fix Batches
+
+#### Critical Fixes (Block multiple suites)
+
+- WebSocket connection / event delivery
+  - Affected tests: 19 (monitoring/real-time-logs)
+  - Root cause: WebSocket never reaches Connected; likely backend
+    upgrade/streaming path or proxy config issue.
+  - Recommendation: Backend Dev
+
+- Logs API timeouts
+  - Affected tests: 12 (tasks/logs-viewing)
+  - Root cause: log listing endpoints timing out or blocked in container mode.
+  - Recommendation: Backend Dev
+
+- Notifications settings API timeouts
+  - Affected tests: 7 (settings/notifications)
+  - Root cause: provider/template APIs not responding or UI navigation error
+    closing the page context.
+  - Recommendation: Backend Dev with Frontend Dev support
+
+- Caddy import session persistence
+  - Affected tests: 3 (tasks/caddy-import-*)
+  - Root cause: import sessions not persisted or banner data not returned.
+  - Recommendation: Backend Dev
+
+#### Secondary Fixes (Quick wins or infra)
+
+- Docker integration UI controls
+  - Affected tests: 2 (core/proxy-hosts Docker integration)
+  - Root cause: missing/hidden form control for connection source.
+  - Recommendation: Frontend Dev
+
+- Strict-mode collisions and wait helpers
+  - Affected tests: 6 (settings + monitoring + wait-helpers)
+  - Root cause: selectors match multiple elements or URL helper too strict.
+  - Recommendation: Playwright Dev
+
+- Admin access/permissions mismatches
+  - Affected tests: 2 (tasks/backups guest UI, settings permission uncheck)
+  - Root cause: UI visibility vs RBAC mismatch or disabled inputs.
+  - Recommendation: Backend Dev with Frontend Dev support
+
+## 5. Effort and Impact Estimates
+
+| Category | Effort | Impact | Notes |
+| --- | --- | --- | --- |
+| WebSocket connection | L | Very High | Unblocks 19 monitoring tests |
+| Logs API timeouts | M | High | Unblocks 12 task tests |
+| Notifications API timeouts | M | High | Unblocks 7 settings tests |
+| Caddy import sessions | M | Medium | Unblocks 3 task tests |
+| Docker integration UI | S | Medium | Unblocks 2 core tests |
+| Strict-mode + wait helpers | S | Medium | Unblocks 6 tests |
+| Admin access mismatches | S | Low | Unblocks 2 tests |
+
+## 6. Implementation Plan
+
+### Phase 1: WebSocket and Logs APIs
+
+1. Verify `/api/v1/logs` WebSocket handshake and server-side stream starts.
+2. Validate static logs API endpoints and response time in Docker mode.
+3. Confirm UI connects to correct WebSocket endpoint for app/security modes.
+
+### Phase 2: Notifications and Caddy Import Sessions
+
+1. Validate notification providers CRUD endpoints and template endpoints.
+2. Ensure notification routes do not crash the page context.
+3. Validate import-session persistence and banner retrieval endpoints.
+
+### Phase 3: UI and Test Infrastructure Quick Wins
+
+1. Restore Docker integration connection source control visibility.
+2. Tighten selectors in strict-mode failures (system status, user management,
+   uptime monitor).
+3. Adjust wait-helpers URL matching to handle expected navigation timing.
+
+### Phase 4: RBAC Consistency
+
+1. Ensure guest users cannot see Create Backup UI controls.
+2. Ensure permission management inputs reflect actual capability and are
+   enabled for admin flows.
+
+## 7. Acceptance Criteria (EARS)
+
+- WHEN the real-time logs page loads, THE SYSTEM SHALL establish a WebSocket
+  connection and report Connected status within the test timeout.
+- WHEN static logs are requested, THE SYSTEM SHALL return log data within
+  the test timeout for pagination, filtering, and download flows.
+- WHEN notification providers/templates are managed, THE SYSTEM SHALL respond
+  to CRUD requests without page context closure or timeouts.
+- WHEN a Caddy import session exists, THE SYSTEM SHALL return the session
+  banner and import results for review flows.
+- WHEN a guest user accesses backups, THE SYSTEM SHALL hide Create Backup
+  controls and enforce server-side RBAC.
+- WHEN strict-mode selectors are used, THE SYSTEM SHALL present a unique
+  element for each targeted control in settings and monitoring pages.
+
+## 8. Delegation Recommendations
+
+- Backend Dev
+  - WebSocket connection and streaming
+  - Logs API timeouts
+  - Notifications APIs
+  - Caddy import session persistence
+  - RBAC enforcement for backups and permissions
+
+- Frontend Dev
+  - Docker integration UI control visibility
+  - UI state handling for notifications if backend responses are valid
+
+- Playwright Dev
+  - Strict-mode selector refinements
+  - wait-helpers URL matching reliability
+
+## 9. Confidence Score
+
+Confidence: 78 percent
+
+Rationale: Failure clusters are clear and repeated across suites, but root
+causes still require endpoint-level confirmation in backend logs and
+WebSocket diagnostics.

docs/plans/phase_2_interruption_analysis.md

@@ -0,0 +1,119 @@
+---
+post_title: "Phase 2 Test Interruption Analysis"
+author1: "Charon Team"
+post_slug: "phase-2-test-interruption-analysis"
+microsoft_alias: "charon-team"
+featured_image: "https://wikid82.github.io/charon/assets/images/featured/charon.png"
+categories: ["testing"]
+tags: ["playwright", "e2e", "phase-2", "diagnostics"]
+ai_note: "true"
+summary: "Analysis of Phase 2 Playwright interruptions, with root cause
+  hypotheses and recommended diagnostics to stabilize execution."
+post_date: "2026-02-09"
+---
+
+## 1. Introduction
+
+This analysis investigates Phase 2 Playwright test interruptions that surface
+as exit code 130 and errors such as "Target page, context or browser has been
+closed" or "Test ended." The focus is on the setup/teardown flow, storage
+state usage, and security-related dependencies that can affect browser
+lifecycles.
+
+## 2. Research Findings
+
+### 2.1 Setup and Auth Storage State Flow
+
+- Phase 1 authentication is performed in [tests/auth.setup.ts](tests/auth.setup.ts)
+  using the Playwright request context, with storage state persisted to the
+  path defined by [tests/constants.ts](tests/constants.ts).
+- The auth setup validates cookie domain alignment with `baseURL` and writes
+  the storage state to `playwright/.auth/user.json`, which Phase 2 uses.
+- Global setup in [tests/global-setup.ts](tests/global-setup.ts) performs
+  preflight health checks, optional emergency security reset, and cleanup.
+  It does not explicitly close browsers, but it can terminate the process if
+  the emergency token is invalid.
+
+### 2.2 Playwright Project Dependencies and Scheduling
+
+- [playwright.config.js](playwright.config.js) declares projects for `setup`,
+  `security-tests`, `security-teardown`, and the browser projects.
+- When `PLAYWRIGHT_SKIP_SECURITY_DEPS` is set (default), browser projects depend
+  only on `setup`, but `security-teardown` remains a standalone project and can
+  still run during the same invocation.
+- Fully parallel execution is enabled, so independent projects may run in
+  parallel unless constrained.
+
+### 2.3 Security Teardown Behavior
+
+- [tests/security-teardown.setup.ts](tests/security-teardown.setup.ts) uses an
+  authenticated API request context and enforces a specific security state:
+  Cerberus enabled, modules enabled, and admin whitelist configured.
+- This teardown is documented as a post-security-test action, but it is not
+  guarded from running alongside non-security browser tests.
+
+### 2.4 Test-Level Browser/Context Closure
+
+- No Phase 2 core/settings/tasks tests explicitly close the shared browser.
+- A direct `context.close()` exists in
+  [tests/monitoring/real-time-logs.spec.ts](tests/monitoring/real-time-logs.spec.ts),
+  but it is scoped to a context created in `beforeAll` and should not affect
+  other tests.
+
+## 3. Root Cause Hypotheses (Ranked)
+
+### H1: Security Teardown Runs Concurrently and Alters State Mid-Run
+
+Because `security-teardown` is configured as a standalone project, it can run
+in parallel when security dependencies are skipped. Its API calls modify
+security settings and admin whitelist configuration. If this overlaps with
+Phase 2 navigation or API-driven setup, it can lead to transient 401/403
+responses, blocked routes, or reload events. The resulting timeouts can cause
+Playwright to end tests early, which produces "Test ended" and "Target page,
+context or browser has been closed" errors.
+
+### H2: Storage State Domain Mismatch or Invalid State
+
+`auth.setup.ts` writes storage state for the `baseURL` domain. If Phase 2 runs
+with a different `PLAYWRIGHT_BASE_URL` host (for example, `localhost` vs
+`127.0.0.1`), cookies may not be sent, leading to authentication failures.
+Tests that assume an authenticated session can then hang in navigation or UI
+assertions, eventually triggering test end and context closure errors.
+
+### H3: Global Setup Emergency Reset Leaves Partial State
+
+Global setup performs an emergency reset and a post-auth reset if storage state
+exists. If the emergency server or token validation is inconsistent, the reset
+may partially apply, leaving security modules enabled without the expected
+whitelist. This can block subsequent API calls and surface as navigation
+timeouts, especially early in Phase 2.
+
+### H4: Environment Instability or Resource Pressure
+
+If the Docker container becomes unresponsive, navigation requests can fail or
+hang, which can cascade into test termination. No direct evidence is present in
+this review, but the symptoms are consistent with sudden page closures after a
+few tests.
+
+## 4. Recommendations for Next Steps
+
+- Confirm whether `security-teardown` is executing during Phase 2 runs and
+  whether it overlaps with browser projects. If it does, isolate it to only run
+  when `security-tests` are executed or after them.
+- Validate storage state consistency by confirming Phase 2 uses the same
+  `PLAYWRIGHT_BASE_URL` host as Phase 1 authentication. Align to a single host
+  (`127.0.0.1` or `localhost`) and keep it consistent across setup and tests.
+- Capture Playwright project scheduling output and test order to confirm whether
+  any teardown is running concurrently with Phase 2 suites.
+- Add a lightweight health check in Phase 2 suites (or in the base fixture) to
+  detect server unresponsiveness early and surface actionable failures instead
+  of page-closed errors.
+
+## 5. Acceptance Criteria
+
+- Phase 2 suites (core, settings, tasks) run to completion without premature
+  browser/context closure errors.
+- No occurrences of "page.goto: Target page, context or browser has been closed"
+  or "page.goto: Test ended" in Phase 2 runs.
+- Project scheduling confirms `security-teardown` does not run concurrently with
+  non-security browser projects when security dependencies are skipped.

docs/plans/phase_2_test_organization_audit.md

@@ -0,0 +1,77 @@
+# Phase 2 Test Organization Audit
+
+**Date**: 2026-02-09
+
+## Scope
+
+Phase 2 runs with `PLAYWRIGHT_SKIP_SECURITY_DEPS=1`, so security modules are disabled. This audit flags tests in Phase 2 folders that exercise security UI or security-dependent workflows and should be relocated.
+
+## Findings From Phase 2 Failures
+
+No Phase 2 failure messages reference ACL blocks, WAF, rate limiting, or CrowdSec enforcement. The recorded failures are interruption/teardown errors, not security enforcement failures. Security-dependent tests are still present in Phase 2 suites and should be relocated to avoid running with security disabled.
+
+## Misorganized Tests (Relocate)
+
+### Move to tests/security/ (security UI/config)
+
+- [tests/core/access-lists-crud.spec.ts](tests/core/access-lists-crud.spec.ts)
+  - **Tests**: `Access Lists - CRUD Operations` (entire file)
+  - **Reason**: Access lists are a Cerberus security feature; these tests validate security configuration UI and should not run with security disabled.
+
+- [tests/settings/system-settings.spec.ts](tests/settings/system-settings.spec.ts)
+  - **Tests**: `should toggle Cerberus security feature`, `should toggle CrowdSec console enrollment`, `should persist feature toggle changes`, `should handle concurrent toggle operations`, `should retry on 500 Internal Server Error`, `should fail gracefully after max retries exceeded`
+  - **Reason**: These tests explicitly change security feature flags and expect propagation that only makes sense when security is enabled and being exercised.
+  - **Note**: Remaining non-security system settings tests can stay in Phase 2; recommend splitting into a security toggles spec.
+
+- [tests/settings/encryption-management.spec.ts](tests/settings/encryption-management.spec.ts)
+  - **Tests**: `Encryption Management` (entire file)
+  - **Reason**: Encryption management is a security area under `/security/encryption` and depends on security configuration state.
+
+- [tests/tasks/import-crowdsec.spec.ts](tests/tasks/import-crowdsec.spec.ts)
+  - **Tests**: `Import CrowdSec Configuration` (entire file)
+  - **Reason**: CrowdSec import is a security configuration workflow; it should run with security enabled.
+
+- [tests/monitoring/real-time-logs.spec.ts](tests/monitoring/real-time-logs.spec.ts)
+  - **Tests**: `Real-Time Logs Viewer` (entire file)
+  - **Reason**: The suite explicitly requires Cerberus to render the LiveLogViewer and exercises security-mode log streams and filters.
+  - **Note**: If a future split is desired, only the App Logs mode tests should remain in Phase 2.
+
+### Move to tests/security-enforcement/ (blocking/enforcement)
+
+- **None identified in Phase 2 suites.**
+  - The Phase 2 failures list does not include enforcement messages like ACL blocks, WAF violations, or rate-limit errors.
+
+## Phase 2 Tests Likely Failing for Environmental Reasons (Keep)
+
+- [tests/settings/account-settings.spec.ts](tests/settings/account-settings.spec.ts)
+  - **Failure type**: `page.goto` interrupted / test ended
+  - **Reason**: Interruption/teardown, not security-related.
+
+- [tests/tasks/backups-create.spec.ts](tests/tasks/backups-create.spec.ts)
+  - **Failure type**: `Browser.removeBrowserContext` / `Test ended`
+  - **Reason**: Browser context teardown, not security-related.
+
+- [tests/utils/wait-helpers.spec.ts](tests/utils/wait-helpers.spec.ts)
+  - **Failure type**: Suite interrupted before execution
+  - **Reason**: Test run interruption, not security-related.
+
+## Relocation Summary
+
+- **Move to tests/security/**: 5 files
+  - Access Lists CRUD
+  - System Settings security toggles (subset of tests)
+  - Encryption Management
+  - Import CrowdSec
+  - Real-Time Logs Viewer
+
+- **Move to tests/security-enforcement/**: 0 files
+
+- **Keep in Phase 2** (but investigate interruptions): 3 files
+
+## Recommended Moves
+
+1. Move Access Lists CRUD to tests/security/.
+2. Split System Settings tests so security toggles move to tests/security/.
+3. Move Encryption Management to tests/security/.
+4. Move Import CrowdSec to tests/security/.
+5. Move Real-Time Logs Viewer to tests/security/ (or split to keep App Logs only in Phase 2).