eval-enginelisted

# Eval Engine Turn a feature spec into a complete verification layer: binary gates, a calibrated LLM-judge rubric, and a runnable harness. Spec in, eval out. ## The one distinction that matters **Gates are binary, disqualifying, and invisible when passing.** A gate failure makes the output unshippable regardless of how good everything else is — fabricated claims, missing required fields, safety violations. Nobody celebrates a passed gate; a passed gate produces zero lines of output. **Rubric criteria are gradual and tradeable.** A 3 on conciseness can be worth accepting for a 5 on accuracy. Rubric scores rank quality among outputs that already cleared every gate. If a check can be "mostly passed," it is a rubric criterion. If partial credit is meaningless, it is a gate. Never average gates into a score — see `references/gate-design.md` for the full test. **Human-vs-judge disagreement is calibration signal, not failure.** When the LLM judge scores a case 4 and the PM says 2, that gap is data about a vague anchor — tighten the anchor, re-run. See `references/rubric-calibration.md`. ## Step 1 — Extract the testable surface Read the spec. List what the feature must never do (gate candidates) and what makes its output better or worse (rubric candidates). If the user gave no concrete spec, PRD, or task description, stop and ask for one — never generate an eval for a hypothetical feature. If the spec is silent on a domain fact a gate needs (a policy value, a required field l