Files
stack/docs/deferred-errors.md
Jason Woltje 89ec509eb9 chore(orchestrator): Bootstrap Phase 4 tasks + document deferred items
Parsed remaining medium-severity findings into 12 tasks + verification.
Created docs/deferred-errors.md for MS-MED-006 (CSP) and MS-MED-008 (Valkey SSOT).
Created Gitea issue #347 for Phase 4.
Estimated total: 117K tokens.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-02-06 13:09:24 -06:00

2.2 KiB

Deferred Errors

Documented per Two-Phase Completion Protocol during Phase 3 Polish.


MS-MED-006: SEC-WEB-16 - Add Content Security Policy Headers

  • File: apps/web/next.config.ts
  • Error: No Content Security Policy (CSP) headers configured
  • Category: Architectural
  • Reason: CSP requires extensive configuration specific to the deployment environment. Inline scripts from Next.js, third-party integrations (Authentik, Ollama), WebSocket connections, and dynamic imports all need careful allowlisting. A misconfigured CSP breaks the application in production. This needs a dedicated effort with staging environment testing.
  • Suggested approach:
    1. Audit all script sources, style sources, connect sources, and frame sources
    2. Start with CSP report-only mode to capture violations without blocking
    3. Add nonce-based script loading for Next.js inline scripts
    4. Configure per-environment CSP (dev permissive, prod strict)
    5. Add violation reporting endpoint
  • Risk: Medium — Mitigated by other security controls (CSRF tokens, XSS sanitization, auth guards). CSP is defense-in-depth.

MS-MED-008: CQ-ORCH-2 - Use Valkey as Single Source of Truth for Sessions

  • File: apps/orchestrator/src/spawner/agent-spawner.service.ts:19
  • Error: In-memory Map used for sessions alongside Valkey, creating dual source of truth
  • Category: Architectural
  • Reason: Migrating from in-memory Map to Valkey-only requires: (1) redesigning the session access pattern to be async everywhere, (2) handling Valkey connection failures gracefully, (3) ensuring atomic read-modify-write for state transitions, (4) updating ~20 call sites that currently access the synchronous Map. The in-memory Map is bounded by CQ-ORCH-1 (session cleanup on terminal states), reducing the unbounded growth risk.
  • Suggested approach:
    1. Add TTL-based expiry to Valkey session keys
    2. Implement read-through cache pattern: Map as cache, Valkey as source
    3. Add Valkey connection health check before spawn operations
    4. Migrate call sites incrementally with feature flag
  • Risk: Low — Bounded by CQ-ORCH-1 cleanup. Single-instance deployment means no cross-instance consistency issue.