packages feed

shikumi-cache-0.2.0.0: CHANGELOG.md

# Changelog

## Unreleased

## 0.2.0.0 — 2026-09-08

- Raise the internal `shikumi` bound to `^>=0.4.0.0` for the breaking core release.

- Clear provider-call evidence on every cache hit, including the memory backend, so logical traces do not reuse a previous crossing as new evidence.

- Bypass memoizer reads and writes for any evidence request, including defaults and warm entries. Apply request defaults before caching so keys reflect effective options. No cache format or public signature change.

- Validate continuation before cache lookup. Both memoizers now require `Error ShikumiError`; this public constraint change requires a PVP major review at release.

- Upgrade the dependency on `mori://shinzui/baikai/packages/baikai` to `>=0.7.0.0 && <0.8`. Preserve cost basis and usage availability in cached responses while accepting legacy JSON without those fields. Include explicit inference speed in cache keys while preserving keys for requests without a speed preference.

## 0.1.2.3 — 2026-08-29

### Changed

- Every library dependency now carries a PVP upper bound: `aeson`, `blake3`,
  `bytestring`, `containers`, `direct-sqlite`, `effectful`, `generic-lens`,
  `scientific`, `stm`, `time`, `vector`. `cabal check` reported these under
  `missing-upper-bounds`. Without one, a future breaking release of a dependency
  enters a consumer's build plan unchecked — which is the failure the bound
  exists to prevent.

  Each bound admits the version this package is built and tested against and
  stops below the next major.

  `aeson` stops at `<2.3` rather than `<2.4`: baikai-openai 0.5 constrains it to
  `^>=2.2`, so aeson 2.3 is not reachable for this cohort and a wider bound
  would assert compatibility that cannot be exercised here.

## 0.1.2.2 — 2026-08-07

### Changed

- Upgraded the `baikai` dependency to the `0.5` series (`>=0.5 && <0.6`).

- `Shikumi.Cache.ResponseJSON`'s orphan `ToJSON`/`FromJSON` for
  `Baikai.Response.Response` are written out by hand instead of derived, and
  they neither write nor read baikai 0.5's new `evidence` field. A cache hit
  replays a stored response without any provider call, so carrying the
  original call's `ModelCallEvidence` would attribute a record of a real
  boundary crossing to a call that never made one. Decoding always yields
  `evidence = Nothing`.

  The encoded keys are otherwise unchanged, so entries written by a pre-0.5
  shikumi still read back and `currentKeyVersion` is untouched. (baikai
  deliberately ships no `FromJSON ModelCallEvidence`, so the derived instance
  could not have been kept regardless.)

## 0.1.2.1 - 2026-07-20

### Changed

- Upgraded the `baikai` dependency to the `0.4` series (`>=0.4 && <0.5`).
  Dependency bounds only — no changes to the exported API.

## 0.1.2.0 - 2026-07-05

### Added

- `CacheConfig`, `defaultCacheConfig`, and `cachedLLMWith` for a shared policy
  layer across cache backends, including optional TTL-based entry expiry.
- `Shikumi.Cache.Backend.Effort` for best-effort backend error handling and
  `stripMessageTimestamps` for canonical cache-key inspection.

### Changed

- Cache keys now include endpoint identity, default/per-call headers, provider
  compatibility settings, and omit message construction timestamps. This bumps
  `currentKeyVersion` to `shikumi-cache/v2`, invalidating old cache entries and
  old trace replay keys.
- `cachedLLM` no longer stores in-band provider error responses, and persistent
  backend lookup/store failures degrade to cache misses or no-ops.
- Refreshed the internal `shikumi` bound for the `0.3` series.

## 0.1.1.0 - 2026-06-28

### Changed

- Refreshed the internal `shikumi` bound for the `0.2` series.
- Updated SQLite backend internals to match the record-patterns conventions used
  across the package set.

## 0.1.0.1 - 2026-06-21

### Changed

- Constrained the baikai dependency to the 0.2 series and refreshed internal shikumi bounds.

## 0.1.0.0 - 2026-06-13

### Added

- Initial Hackage release of provider-neutral response caching for shikumi.
- Content-addressed cache keys, in-memory and SQLite cache backends, cached LLM interpretation, and response JSON support shared by backend packages.