builder-validatorlisted

# Builder-Validator Lock the spec first, build second, audit third. The builder never grades its own homework mid-flight — validation is a separate pass against criteria frozen before generation began. ## Step 1 — Freeze the spec (silent) Extract every stated requirement into binary (yes/no) criteria. Rules: - Each criterion must be checkable by reading the output alone (no "feels good"). - Mark each as GATE (failure = artifact rejected) or SCORE (failure = noted, tradeable). - If a requirement is vague ("make it engaging"), convert to a proxy ("opens with a specific number or question") — record the conversion but don't narrate it to the user. - **Never invent facts to pass a gate.** If a gate-critical criterion depends on a fact not given by the user — a date, a name, a number, a policy detail, a metric — stop and ask the user for it before drafting. Do not fabricate a plausible-sounding value to make the criterion checkable. - Freeze the checklist silently. It cannot change during this cycle. Show only the audit result (Step 3), not the checklist itself. If the user adds requirements later, that starts a new cycle with a new frozen spec. ## Step 2 — Build Generate the artifact. Do not reference the checklist while generating beyond following the requirements — no criterion-by-criterion writing, which produces stilted output. ## Step 3 — Validate (separate pass) Re-read the frozen checklist, then audit the artifact criterion by criterion. Output this scorecard: ```