audit F19: thread correlation IDs UI -> daemon -> LLM Closes the maintainability/correctness root rot identified in audit Phase 1: a single user action could not be traced from API call through state engine through LLM call back to the response without grep+wallclock alignment across four log streams. - New cortex/libs/logging/correlation.py: ContextVar-backed id, scope manager, stdlib Filter that injects record.correlation_id, helper to install the filter idempotently. - structlog processor chain now includes merge_contextvars so any get_logger()-emitted record carries correlation_id automatically. - FastAPI middleware mints (or accepts via X-Cortex-Request-ID) one id per request, binds it for the lifetime of dispatch, echoes it back on the response, and exposes the header through CORS. - WebSocketServer enters a correlation scope around every inbound message; _broadcast stamps the active id onto outbound messages with no correlation_id of their own, so daemon-initiated traffic stays traceable to the originating request. - Anthropic planner's llm.request status=ok log line now includes the active correlation id so the next finding (F20 cost telemetry) can group spend per request without retrofit. Test: cortex/tests/integration/test_correlation_ids.py — 8 cases. All fail on main (ModuleNotFoundError on the new module, missing middleware header, no broadcast stamping). All pass on this branch. Compatibility: additive. WSMessage.correlation_id already existed and was optional. No schema migration, no client coordination required. The TS extension half of the chain remains open as new Ledger entry F19b (gated on F40 TS test infra). Rollback: git revert is clean — code-only change, no persisted state. Also writes audit/findings.md (56-finding Ledger + Cheap Wins + Architectural Debt), audit/state.md (Phase 2 pointer), and seeds audit/execution-log.md with this commit's entry.

StevenWang-CY committed May 18, 2026