oraclelisted

# Cladding oracle — impl-blind conformance authoring A SPEC_CONFORMANCE oracle is a conformance test authored **without seeing the implementation**, so a passing oracle means "matches the spec," not "matches the code." The A/B that motivated this: a blind oracle caught bugs a code-peeking (sighted) oracle rubber-stamped (7/8 vs 4/8). cladding owns no LLM — the blinding is **your discipline as the host**; cladding produces the brief, records provenance, and the gate audits it. ## Which ACs need an oracle? (the policy) A project sets its requirement under `spec.yaml::project`: - **`oracle_policy: { always_ears: [unwanted], sample: 0.2 }`** (RECOMMENDED) — risk-weighted: author an oracle for every done AC whose EARS category is in `always_ears` (default `['unwanted']` — error/edge handling), PLUS a deterministic ~`sample` fraction of the rest. v8 showed exhaustive per-AC oracles add ~0 quality at ~30% cost, so spot-check the bulk and concentrate verification where failures cluster. - **`require_oracles: true`** — EXHAUSTIVE (every done AC). Highest assurance, highest cost. `oracle_policy` takes precedence when both are set. - **Neither** — no mandate (an authored oracle still runs + is recorded; a missing one is not forced). Run **`clad oracle --required`** to print the worklist — exactly which done ACs the policy demands an oracle for, which already have one, and why (`always:<ears>` / `sample` / `exhaustive`). Author oracles for the `← needs an impl-blind oracle` r