# Changelog
## 0.5.0.0 — 2026-08-22
### Breaking Changes
- The composed plan includes the corrected Kioku `0011` payload. A database that already applied
`0011` with Kioku 0.4.0.0 or 0.4.1.0 must run
`kioku-migrations/ledger-fixups/2026-08-19-rebaseline-0011-checksum.sql` before this executable's
first `up` or `verify`; a database where `0011` is pending needs no preflight action. The next
release must use the 0.5.0.0 series.
### Changed
- The composed Keiro migration dependency is now 0.14.0.0 and includes `keiro/0031`. `up`,
`status`, and `verify` now report 55 migrations: Kiroku 11, Keiro 31, and Kioku 13.
### Fixed
- A single composed `up` no longer leaves the migration connection's `search_path` pinned to the
Kiroku schema before control reaches an application-owned component.
## 0.4.1.0 — 2026-08-18
### Changed
- Version bump only, to stay on the shared Kioku version. The release moves `kioku-core` onto the
Baikai 0.5 cohort; this package is unchanged apart from its internal dependency bounds.
## 0.4.0.0 — 2026-08-17
### Breaking Changes
- The composed plan gains `kioku/0012-relocate-projections-to-kioku-schema`, which moves Kioku's
seven projections out of the `kiroku` schema into a dedicated `kioku` one. `up` and `status`
now report 53 migrations (kiroku 11, keiro 30, kioku 12). Run it with writers stopped and before
the new application binary starts; `up` reconciles the Keiro read-model registry to the new
memory v3 / session v5 / turn v3 identities afterwards, as it always has. See
`docs/user/upgrading-to-the-kioku-schema.md`.
## 0.3.0.0 — 2026-08-05
### Breaking Changes
- Moved onto the Keiki 0.9 / Keiro 0.11 cohort through `kioku-core` and `kioku-migrations`. The
bound is breaking; the schema effect is nothing. A database migrated by kioku 0.2.0.0 has no
pending migration on the next `kioku-migrate up` — every one of the 38 reports as already
applied, and `kioku-migrate verify` still reports `applied=38 pending=0 unknown=0`.
### Changed
- No change to planning, applying, verifying, repairing, Codd-history import, or read-model
registry reconciliation.
## 0.2.0.0 — 2026-07-30
### Breaking Changes
- Moved onto the Keiro 0.4 cohort through `kioku-core` and `kioku-migrations`. A database that was
migrated by kioku 0.1.0.0 picks up exactly two migrations on the next `kioku-migrate up` —
`keiro/0019-keiro-snapshots-state-shape-hash` and
`keiro/0020-keiro-workflow-children-failure-reason` — and reports every other migration as
already applied. Both add a column to a Keiro-owned table; no existing row is read or rewritten.
After the upgrade `kioku-migrate verify` reports `applied=38 pending=0 unknown=0`.
### Deprecated
- The `kioku-migrate import` subcommand, which imports a codd ledger into pg-migrate, is
deprecated. It remains fully supported for now. Removal is gated on the last codd-era downstream
database crossing over; see `kioku-migrations/codd-upgrade/README.md` for the gate and the full
list of what is removed together.
## 0.1.0.0 — 2026-07-14
### Added
- Added a pg-migrate administration executable for planning, listing, checking, inspecting,
verifying, applying, repairing, and creating migrations.
- Added checked Codd-history import for the pinned Kiroku, Keiro, and Kioku migration cohort with
text or JSON reports.
- Added automatic read-model registry reconciliation after successful migration application.
### Changed
- Updated the executable to pg-migrate 1.1 and the Keiro 0.3/Kiroku Store 0.3 application resource
model.