Meta-Recursive Failure Pattern Audit

**Date:** 2026-03-14 **Auditor:** Meta-Recursive Explorer (Opus 4.6) **Data Sources:** Supabase mesh_events (23,124 total), failure_journal.jsonl (5,678 entries), cortex/entries.jsonl (679 entries), session-crons/results (11 ring buffers), failure-museum.md (10 exhibits, 26 gems), skills/registry.json (88 skills) The mesh failure detection system has a critical blind spot: **100% of all 5,678 failure journal entries are classified as "unknown"** because the `failure-intel/handler.py` hook receives empty `error_snippet` fields for nearly every failure. This means the classifier never matches any of its 10 regex patterns, the recovery registry never fires, and the event bus gets flooded with uninformative `failure_pattern` events. The result is a system that detects failures prolifically but classifies none of them, making the escalation hints generic ("Review approach and try a different strategy") rather than actionable. **Evidence:** - `[home]/.claude/state/failure_journal.jsonl`: 5,678 entries, all class="unknown" - 99.9% of entries have empty `error_snippet` (only 8 of 5,678 have non-empty content) - The non-empty ones contain "Shell cwd was reset" messages, not actual errors **Root Cause:** The handler extracts error text from `tool_response.stderr` + `tool_response.error` (line 178 of `[home]/.claude/hooks/failure-intel/handler.py`). But Claude Code's `PostToolUseFailure` hook input does not always populate these fields. The actual error content is likely in `tool_response.stdout`, `tool_response.content`, or the raw `tool_response` string itself. The handler concatenates two empty/missing fields and classifies the empty string, which matches nothing. **Impact:** - 4 recovery registry entries (ssh_timeout, xcode_build_failure, disk_full, import_error) have **never fired** - All escalation hints default to the generic message - `failure_pattern` events flood mesh_events (1,000+ events since Mar 7), all with `failure_class: unknown`