v1.83.0

## [1.83.0] - 2026-05-16

### Added — Publish → recall round-trip verification (#53, #56)

After every successful Hub publish (Capsule, AntiPattern, or SkillBundle),
the daemon now confirms that the asset can actually be **recalled** from
Hub. A new `src/gep/recallVerifier.js` worker runs Phase 2 deterministic
`asset_id` lookups on a sampling of published assets, with exponential
backoff to absorb indexing latency. Outcomes (`roundtrip_ok` /
`roundtrip_missing` / `roundtrip_mismatch` / `verification_skipped`) land
in `memory_graph.jsonl` as `kind=recall_verify` events.

A new `scripts/recall-verify-report.js` aggregates those events into a
Markdown table grouped by asset type with success rate + p50/p95/p99
latency. Exit code is a ship-gate: 0 when every asset type meets ≥ 0.95
success and zero mismatches, exit 2 otherwise. Designed to plug into
deploy.sh as a pre-publish guard.

This closes the "daemon knows results" theme set up by v1.82.0's open-PR
overlap detection: v1.82.0 made the daemon aware of in-flight work so it
stops re-inventing it; v1.83.0 makes the daemon aware of whether its own
uploaded experience is actually retrievable later. Together they bound
the daemon's two main blind spots — "what other people are doing" and
"whether what I just uploaded actually stuck."

### Architecture

| Layer | Behavior |
|---|---|
| `src/gep/recallVerifier.js` (new) | Bounded ring queue (default 256), single-flight by asset_id, sample-rate gate, async setInterval worker (unref'd so process exit is unblocked). Retries on missing with [5s, 15s, 60s] backoff up to 3 attempts. |
| `src/gep/hubSearch.js` | Phase 2 fetch logic extracted into a reusable `fetchAssetById(assetId, opts)` helper. Cache-first ordering preserved so hot payloads return instantly even when the search-phase budget is exhausted. |
| Three publish hooks | `solidify.js` capsule + anti-pattern, `skill2gep.js` `publishBundleChannel`. Each enqueues only after `res.ok && !res.dry_run`, and uses the **sanitized** capsule's `asset_id` so the verifier looks up the same hash the Hub indexed. |
| `scripts/recall-verify-report.js` (new) | Markdown report with monotonic gate severity (RED never downgrades to YELLOW). |
| `index.js` | `[RecallVerify] ENABLED/DISABLED` startup banner, starts the worker once, with sample-rate range clamping. |

### Mismatch detection

`verifyOnce` recomputes `computeAssetId` on the recalled body and
compares to `results[0].asset_id`. A mismatch means the Hub re-encoded or
corrupted the asset between publish and fetch — surfaced as
`roundtrip_mismatch` and flips the gate to RED.

### Configuration (all default-on)

| Env var | Default | Purpose |
|---|---|---|
| `EVOLVE_RECALL_VERIFY` | `1` | Master switch |
| `EVOLVE_RECALL_VERIFY_SAMPLE_RATE` | `1.0` | Fraction of publishes to verify (clamped to [0, 1]) |
| `EVOLVE_RECALL_VERIFY_QUEUE_MAX` | `256` | Ring queue size |
| `EVOLVE_RECALL_VERIFY_INITIAL_WAIT_MS` | `5000` | First-attempt delay |
| `EVOLVE_RECALL_VERIFY_POLL_MS` | `5000` | Worker tick rate |
| `EVOLVE_RECALL_VERIFY_ATTEMPTS` | `3` | Retries on `roundtrip_missing` |
| `EVOLVE_RECALL_VERIFY_FETCH_TIMEOUT_MS` | `8000` | Phase 2 timeout |

### Hub mirror staging

`recall_verify` is intentionally **not** in `HUB_SYNC_KIND_ALLOWLIST` on
first ship — local-only until Hub side confirms it accepts the schema.
One-line follow-up patch enables mirroring later.

### Hardened — five Bugbot review iterations on the publish/verify
data flow

PR #53 + #56 went through five Cursor Bugbot rounds. Each surfaced a
real defect that would have shipped silently:

- **schemas/protocol obfuscation gap.** `recallVerifier.js` was missing
  from `public.manifest.json:obfuscate`; would have shipped in plaintext
  to npm.
- **Phase 2 cache bypass regression.** Refactored time-budget check
  ordered before cache lookup, so hot payloads were silently re-fetched
  (or worse, dropped) under deadline pressure.
- **Gate severity could downgrade.** `recall-verify-report.js`'s gate
  loop overwrote later rows, so AntiPattern@RED followed by Capsule@YELLOW
  reported YELLOW — misleading dashboards even though exit code was
  correct. Replaced with monotonic escalation (RANK ordinal).
- **Wrong asset_id used for recall lookup.** `solidify.js`'s capsule and
  anti-pattern paths enqueued the **pre-sanitize** `asset_id` for
  verification, but Hub indexes by the **sanitized** hash. Any PII
  redaction would have produced persistent false `roundtrip_missing`
  results, dragging the ship gate toward RED forever. Both paths now
  recompute on the sanitized capsule and pass that hash to the verifier.
- **Sample-rate banner-vs-implementation drift.** `index.js` clamped
  sample rate to [0, 1] but `_getSampleRate()` did not, so a negative
  env value silently disabled all verification while the banner still
  reported 1.0.
- **Dry-run guard masked Hub rejections.** `else if (res && res.dry_run)`
  classified `{ok:false, dry_run:true}` (a real Hub reject during
  dry-run) as a clean dry-run skip. Now requires `res.ok && res.dry_run`.

### Notes for operators

- This release is enabled-by-default; no opt-in required to start
  collecting recall_verify events. To disable, set
  `EVOLVE_RECALL_VERIFY=0` before the daemon starts.
- A 30-minute real-Hub daemon smoke + `recall-verify-report` ship-gate
  read is the recommended pre-deploy ritual once a non-trivial volume of
  publishes has accumulated.
- Memory graph events with `kind=recall_verify` are local-only this
  release; the next release will add them to the Hub mirror allowlist
  once Hub-side schema acceptance is confirmed.