v1.80.9

## [1.80.9] - 2026-05-16

### Fixed

- **GEP prompt schema enums now flow from a single source of truth (#45,
  follows up #42).** v1.80.8 patched three hardcoded `repair|optimize|innovate`
  literals in `src/gep/prompt.js` after the `explore` category had been
  silently dropped from the LLM contract for months. This release makes the
  whole class of bug structurally impossible: a new `src/gep/schemas/protocol.js`
  is the single source of truth for every enum that appears both in JS
  validation code (`mutation.js`) and in the LLM-facing prompt schema
  (`prompt.js`). It re-exports `VALID_CATEGORIES` from `schemas/gene.js`,
  `VALID_OUTCOME_STATUSES` from `schemas/capsule.js`, plus declares
  `VALID_RISK_LEVELS` and `VALID_TRACE_STAGES`. `prompt.js`'s
  `SCHEMA_DEFINITIONS` is now generated by `buildSchemaDefinitions()` which
  interpolates `renderEnum()` / `renderEnumList()` calls instead of
  hardcoding each value. `mutation.js`'s `isValidMutation` and
  `normalizeMutation` import the enums instead of inlining them. The
  stale "keep this in sync with schemas/gene.js" warning comment in
  `solidify.js` is removed because the rule is now enforced by the type
  system, not by reader vigilance. A new test
  `test/schemaPromptConsistency.test.js` adds 4 cases that fail loudly if
  any future contributor reintroduces a hardcoded enum literal in
  `prompt.js`, drifts `protocol.js` from the underlying schema files, or
  removes a category from the canonical whitelist without auditing
  `strategy.js` presets.

### Hardened

- **`scripts/deploy.sh` now fails fast before the irreversible
  `npm publish` step (#45).** The previous pipeline used
  `|| echo "WARN: ..."` after step 5 (`publish_public.js`) and step 6
  (binary upload), which let a failed GitHub Release step be followed by
  a successful `npm publish` — leaving the registry pointing at a version
  with no GitHub release. `npm publish` cannot be undone, so this was a
  real one-way state. v1.80.8 actually hit it when `publish_public.js`
  failed with a missing-git-identity error in the temp publish repo, but
  deploy continued and shipped npm@1.80.8 anyway. Two layered defenses
  now apply: (1) step 5 exits 1 with an actionable error if
  `publish_public.js` returns non-zero, instead of `WARN`-and-continue;
  (2) step 7 runs `gh release view v$VERSION` as a precondition before
  invoking `npm publish` and refuses to ship if the GitHub Release is
  missing or in draft state. Step 7 itself also fails fast if `npm
  publish` errors. Step 6 (binary upload) intentionally keeps
  `WARN`-and-continue because binary upload is recoverable via
  `gh release upload --clobber` and missing binaries do not put the
  registry in an inconsistent state.