01 — Dual-Path Baseline + OOM Stability

All 11 containers healthy (postgres up 7 weeks, directus up 3 weeks, incomex-nuxt up 17 hours, executor up 23 hours, plus nginx/qdrant/agent-data/kb/mcp/uptime-kuma).

OOM stability — the decisive check. Live postgres logs were read across the incident and post-incident windows. The five signal-9 crashes occurred 05:28-06:04 UTC; the LAST one was 06:04:02 UTC, failed process being the combo deploy-guard view query (SELECT verdict ... generated_v2_rowcount FROM v_rp_ui_deploy_final_readiness_guard). The 05:59:34 crash was an EXPLAIN of the same view — confirming the cost is planner-side. After 06:04:02, through roughly 08:09 UTC, the logs show ZERO signal-9 and ZERO crash recovery — only healthy checkpoints and pre-existing benign background errors (meta_catalog S129-A security guard blocking a direct count update, fn_log_issue varchar overflow from the dot-context-pack-verify job, and this session's own harmless typo errors). At 06:23 UTC the function-backed guard hit a statement-timeout on the smoke gate and TIMED OUT rather than crashing — direct proof the fix is crash-safe. The OOM pause-condition (any new OOM after 06:04) was NOT triggered.

Dual-path: query_pg read-only (5s timeout) for fast base-table and detector reads; ssh to docker exec postgres psql with statement_timeout=0 for the crash-safe-but-slow function-backed guards. The two paths agree.

Baseline no-fake metrics (all match SSOT): births 1,205,410 at start, ownership 0, guard_alerts 129, axis_registry 2 both CANDIDATE (axis_active 0), axis_assignment 25, events_active 30, PROC-OWN 5 requests / 0 votes, real_run flags all false/dry (process_dot_runtime.real_run_enabled false, execute_enabled false, dry_run_only true, plus piece_event and iu_core operator_runtime false).