diff --git a/.changeset/bump-core-permissions-as-associations.md b/.changeset/bump-core-permissions-as-associations.md
deleted file mode 100644
index e09debb..0000000
--- a/.changeset/bump-core-permissions-as-associations.md
+++ /dev/null
@@ -1,37 +0,0 @@
----
-'@haverstack/eleventy': minor
----
-
-Bump `@haverstack/core` to `^0.37.0` and `@haverstack/commons` to `^0.31.0`.
-
-**Existing stacks must be recreated.** Core 0.35.0 stores record permissions as
-associations and takes `parentId` off the version tier. The SQLite schema is
-`CREATE TABLE IF NOT EXISTS` only and ships no migration, so a database written
-by an older core opens and then fails on the first permission write: its
-`associations` table keeps a `kind` constraint that refuses `permission` and
-`anyone`, and has no `related_role` or `attachment_record_id` column.
-
-`Permission` is gone. A record's ACL is now `AuthorityAssociation[]` — a
-`permission` association whose bit is its label and whose `grantee` carries a
-required `role`, or an `anyone` association spelling world-read affirmatively.
-`[{ access: 'public' }]` becomes `[{ kind: 'anyone', label: 'read' }]`. The
-`associations` key narrows to `DataAssociation[]`, since authority kinds now
-live in the same table behind a separate key.
-
-The plugin reads rather than writes both sets, so this is a dependency and
-documentation change: no module needed a code change, and `StackRecord`'s two
-projections keep an association loop from ever seeing an ACL entry. Attachment
-candidates are now ordered by core's own total order (`createdAt`, then `id`)
-so two uploads landing in the same millisecond stage the same way every build.
-
-`docs/design.md § Rebuilding on change` is corrected, and the correction is the
-part worth reading before building rebuild avoidance. Since 0.33–0.35 the
-journal-tier ops — `associate`, `dissociate`, `permissions`, `reparent`,
-`unlist`, `list` — leave `version` **and** `updatedAt` exactly where they stand.
-The previously sketched `updatedAt: { after }` gate would therefore skip a
-rebuild for precisely the edits this plugin cares most about: adding a record to
-a site, scoping one with `for-site`, embedding an attachment, moving a page, or
-publishing a draft. The gate now runs after load and fingerprints the index
-(associations and permissions included) rather than asking the query layer a
-question `updatedAt` can no longer answer. A watching `--serve` correspondingly
-reads `RecordChange.ops`, never `version`.
diff --git a/CHANGELOG.md b/CHANGELOG.md
index f6fc15d..957b2d0 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -1,5 +1,43 @@
 # @haverstack/eleventy
 
+## 0.3.0
+
+### Minor Changes
+
+- [#4](https://github.com/haverstack/eleventy/pull/4) [`8b9d519`](https://github.com/haverstack/eleventy/commit/8b9d5199f6a163eee2b6fba2ceb9bb00d13378c3) Thanks [@cuibonobo](https://github.com/cuibonobo)! - Bump `@haverstack/core` to `^0.37.0` and `@haverstack/commons` to `^0.31.0`.
+
+  **Existing stacks must be recreated.** Core 0.35.0 stores record permissions as
+  associations and takes `parentId` off the version tier. The SQLite schema is
+  `CREATE TABLE IF NOT EXISTS` only and ships no migration, so a database written
+  by an older core opens and then fails on the first permission write: its
+  `associations` table keeps a `kind` constraint that refuses `permission` and
+  `anyone`, and has no `related_role` or `attachment_record_id` column.
+
+  `Permission` is gone. A record's ACL is now `AuthorityAssociation[]` — a
+  `permission` association whose bit is its label and whose `grantee` carries a
+  required `role`, or an `anyone` association spelling world-read affirmatively.
+  `[{ access: 'public' }]` becomes `[{ kind: 'anyone', label: 'read' }]`. The
+  `associations` key narrows to `DataAssociation[]`, since authority kinds now
+  live in the same table behind a separate key.
+
+  The plugin reads rather than writes both sets, so this is a dependency and
+  documentation change: no module needed a code change, and `StackRecord`'s two
+  projections keep an association loop from ever seeing an ACL entry. Attachment
+  candidates are now ordered by core's own total order (`createdAt`, then `id`)
+  so two uploads landing in the same millisecond stage the same way every build.
+
+  `docs/design.md § Rebuilding on change` is corrected, and the correction is the
+  part worth reading before building rebuild avoidance. Since 0.33–0.35 the
+  journal-tier ops — `associate`, `dissociate`, `permissions`, `reparent`,
+  `unlist`, `list` — leave `version` **and** `updatedAt` exactly where they stand.
+  The previously sketched `updatedAt: { after }` gate would therefore skip a
+  rebuild for precisely the edits this plugin cares most about: adding a record to
+  a site, scoping one with `for-site`, embedding an attachment, moving a page, or
+  publishing a draft. The gate now runs after load and fingerprints the index
+  (associations and permissions included) rather than asking the query layer a
+  question `updatedAt` can no longer answer. A watching `--serve` correspondingly
+  reads `RecordChange.ops`, never `version`.
+
 ## 0.2.1
 
 ### Patch Changes
diff --git a/package.json b/package.json
index a84a414..7f4c87a 100644
--- a/package.json
+++ b/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@haverstack/eleventy",
-  "version": "0.2.1",
+  "version": "0.3.0",
   "description": "Eleventy plugin that builds a static site from a Haverstack stack — records are the content source, no content files on disk",
   "type": "module",
   "exports": {