mtls-validation-debuggerlisted

# mtls-validation-debugger ## Execution Mode — FULLY AUTONOMOUS **NEVER ask the user for confirmation.** Fetch logs, interpret results, propose and apply fixes immediately. The only user-facing handoff in the loop is triggering rollouts in the Horizon UI (owned by `mtls-iteration-loop` Step 4c). This skill never has user-facing handoffs. ## Goal Turn an Oracle or No-Op failure into a specific root cause with a specific fix, using only the log evidence — not guesswork. The point of this skill is to prevent blind edits. If you cannot map the observed log pattern to one of the rows below with confidence, escalate to `horizon-agentic-reviewer` for a live probe before changing any file. ## Trigger Use this skill when: - Oracle returned anything other than `score: 1.0, passed: true` - No-Op returned a score > 0 (false positive — the grader passed on a broken setup) - The grader crashed with a Python exception - `result.json` shows `feedback: null` (container/setup crash before grader ran) - You are about to edit setup.sh, solution.sh, or grader.py in response to a validation failure Do **not** use this skill for rollout failures (those are scoring/variance issues — use `mtls-score-tuner`). Oracle and No-Op are validation; rollouts are evaluation. ## Task Identity | Field | Value | |---|---| | **Task UUID** | `<TASK_ID>` | | **Task slug** | `variation-fanout-pipeline-break` | | **Local path** | `tasks/variation-fanout-pipeline-break/` | | **Subscores** | `mtls_handshake` (0