KARL Integration -- Evolution3 / Stage 3: EXPAND + MASTER PLAN

# KARL Integration -- Evolution3 / Stage 3: EXPAND + MASTER PLAN **Run:** karl-trajectory-intelligence **Generated:** 2026-03-10 **Method:** Evolution3 -- stress-test and master checklist **Run Directory:** Desktop/evo-cube-output/karl-trajectory-intelligence/ Before auditing the compound, I verified every data assumption against the live system: | Assumption (from Stage 2) | Reality | Impact | |---|---|---| | unified.jsonl has 3,909 entries with tool_calls arrays | **3,940 entries, but only 3 have populated tool_calls** (all empty arrays) | **CRITICAL**: The unified store does NOT contain usable trajectory data | | verbose-all.jsonl has 3,249 entries, 157 with multi-step tool sequences | **3,258 entries, 157 with tool_calls in assistant_turns** (confirmed) | Correct, but these are 96% Codex entries (`exec_command`, `shell_command`), not Claude Code entries | | 88 skills, 13 active in registry | **Confirmed: 88 skills, 13 active** | Accurate | | ops_trigger.py is 233 lines | **232 lines** | Accurate | | RAG++ at :8000 reachable | **Confirmed: healthy, returns related_turns + graph_context** | Accurate | | Mac5 MLX :8100 reachable | **Unreachable via direct curl AND via SSH** | **BLOCKER**: Mac5 is offline or unreachable right now | | Mac5 finetune-daemon :9200 | **Unreachable** | Same blocker as above | | numu-weave at [home-path] | **Confirmed: 270 lines** | Accurate | | l4_controller.py exists | **Does not exist** (greenfield) | Expected -- this is what we build | | pulse_bridge.py exists | **981 lines** (much larger than Stage 0's estimate of "lines 109-123") | Need to account for actual complexity | | Supabase has 141 tables | **Could not verify** (API key not in env) | Assume accurate per MEMORY.md | **What holds:** - The two-channel architecture (live tap + historical backfill) is correct. - The JSONL append-only store design is sound for hook latency constraints. - The schema is comprehensive and covers all downstream consumers. - The tap points in ops_trigger.py, post_tool_hook.py, response_hook.py, and session_end_hook.py are identified correctly. 1. **The backfill data is mostly Codex, not Claude Code.** Of 157 entries with tool_calls, the tool names are `exec_command` (1,632), `shell_command` (1,108), `apply_patch` (266). These are Codex tool names. Only 7 entries have `read_file` (Claude Code's equivalent). The backfill extractor assumed these entries represent Claude Code workflows, but they represent Codex workflows. The tool name normalization (`shell_command` -> `Bash`) is technically possible but produces Codex-biased trajectories that may not transfer to Claude Code routing.