hazo_blog 2.0.0 → 2.16.0

package/CHANGE_LOG.md

@@ -3,6 +3,873 @@
 All notable changes are documented here. This project follows
 [Semantic Versioning](https://semver.org/).
 
+## 2.16.0 — 2026-11-08
+
+**⚠️ DDL required — site settings + custom CSS data layer (Phase 1b ticket 09): `hazo_blog_site_files`, a typed `SiteIdentity` settings shape, and `RenderSite.ogImage`.** This is the BACKEND/DATA layer — the admin UI, the two API routes, the `RenderContext.site` population, and the `<head>`-injection decision for custom CSS all ship in the BlogSketch platform repo's own commit for this ticket, per this package's usual split (see 2.13.0's menus entry for the same precedent).
+
+- **New table** `hazo_blog_site_files` (both dialect files, mirrored into the platform's `migrations/0001_hazo_blog.sql`/`migrations/postgres/0001_hazo_blog.sql`): `id`, `scope_id` NOT NULL (platform-multi-tenant-first, same reasoning as `hazo_blog_menus`/`hazo_blog_site_theme` — no useful "global" custom CSS), `kind` (free-text, only `'custom_css'` used today — see `SiteFileKind`), `content`, `version`, `is_current`, `created_at`. **Versioning**: every save INSERTS a new row (never updates `content` in place) with `version` one higher than the previous current row for that `(scope_id, kind)`, flipping the old row's `is_current` off in the same call (`SiteFileRepository.setCurrentFile`) — full edit history for free, "at most one current row per (scope_id, kind)" enforced in application code, not a DB constraint (same convention as `hazo_blog_app_site_domains.is_primary`). Postgres also gets the strict (`scope_id` NOT NULL) RLS policy, same shape as `hazo_blog_menus`/`hazo_blog_site_theme`.
+- **`createSiteFileRepository`/`createSiteFileService`** (`src/repository/site-files.ts`/`src/service/site-files.ts`, exported via the main entry) — `getCustomCss`/`getCustomCssFile`/`updateCustomCss`/`listCustomCssVersions`. `updateCustomCss` enforces a 256 KiB cap (`MAX_CUSTOM_CSS_BYTES`, `CustomCssTooLargeError`) — the only validation this layer does; this package does NOT sanitize/escape the CSS content itself (see `site-files.ts`'s own header comment: that boundary belongs to the host's render edge, same "service stores, render boundary escapes" split as MDX `content`/`rehype-sanitize`).
+- **`SiteIdentity`** (`src/lib/site-identity.ts`, exported via `./lib` and the main entry) — a SECOND, separate typed settings shape (title/tagline/logo/favicon/ogImage/social/locale/timezone/analytics/ads), stored under its own `SITE_IDENTITY_KEY` (`"site_identity"`) plain key via the EXISTING `repository.getSetting`/`setSetting` mechanism `BlogSettings`/`BLOG_SETTINGS_KEY` ("display") already uses — not folded into that shape, per this ticket's own instruction (different concern). `resolveSiteIdentity(payload, fallback)` follows `resolveBlogSettings`'s exact "coerce untrusted payload, never throw, default per-field" contract. `contact_email` is deliberately NOT part of this shape — ticket 14's `contact_email` plain-key bridge already owns that, reused as-is by the platform's own admin UI rather than duplicated.
+- **`RenderSite` gains `ogImage`** (`src/render/types.ts`) — the one `site.*` field ticket 09's Liquid-context bullet asks for that didn't already exist (`title`/`tagline`/`logo`/`favicon`/`locale`/`social`/`analytics` were all already there, from tickets 03/07). `{% seo_head %}`'s `og:image` fallback chain is now `post.seo.ogImage -> site.ogImage -> site.logo` (previously `post.seo.ogImage -> site.logo`) — additive, same `og:image` behaviour as before for any caller that never sets `site.ogImage`.
+- Tests: `src/__tests__/site-identity.test.ts` (16 cases — pure `resolveSiteIdentity` coercion, including the untrusted-payload cap on `social`'s size), `src/__tests__/site-files.repository.integration.test.ts` (6 cases, real SQLite — versioning, history, scope isolation, cross-kind isolation), `src/__tests__/site-files.service.integration.test.ts` (7 cases, real SQLite — save/load round-trip, size cap, tenant isolation), plus 2 new cases in `src/__tests__/render.tags.test.ts` for the widened `og:image` fallback chain. 25 new tests, all passing; full suite unaffected (same pre-existing, unrelated v1.6/v2.0.0 schema-split failures every release since 2.10.0 has carried — zero regressions, +25 passing from this release).
+- **Not done in this release (flagged, not silently deferred)**: no admin UI, no API routes, no `RenderContext.site` wiring, no custom-CSS `<head>` injection, no cache-purge-on-save (all of those ship in the platform repo's own commit); no rollback UI/API for custom CSS (`hazo_blog_site_files` keeps full history, but nothing reactivates an older version yet — same gap shape as 2.15.0's theme-version-rollback note); ad network ids (`SiteIdentity.ads`) are captured but not wired into any render/head-script-injection path yet (out of this ticket's own `site.*` Liquid-context scope, which lists only title/tagline/logo/favicon/social/locale/OG image).
+
+Bumps 2.15.0 -> 2.16.0 (minor, new required DDL — see ⚠️ heading above).
+
+## 2.15.0 — 2026-11-08
+
+**⚠️ DDL required — theme management data/service layer (Phase 1b ticket 06): `hazo_blog_themes`, `hazo_blog_theme_versions`, `hazo_blog_site_theme`, `theme.json` parsing/validation, and the render-integration answer to "which `themeDir` does `renderPage` use for site X?".** This is the BACKEND/DATA layer — the admin gallery UI is ticket 08's job, per this ticket's own scope note.
+
+- **New tables**, both dialect files, mirrored into the platform's `migrations/0001_hazo_blog.sql`/`migrations/postgres/0001_hazo_blog.sql`: `hazo_blog_themes` (`id`, nullable `scope_id` — `NULL` = built-in/global, non-null = one site's own upload, visible only to it — `name`, `handle`, `version`, `author`, `licence`, `description`, `screenshots` JSON array, `source` `'built-in'|'upload'`, `storage_path`, `created_at`), `hazo_blog_theme_versions` (`id`, `theme_id` FK cascade, `version`, `storage_path`, `created_at` — full version history, not just the current one), `hazo_blog_site_theme` (`id`, `scope_id`, `theme_id` FK cascade, `settings` JSONB, `activated_at`). **One active theme per site** is enforced by a `UNIQUE(scope_id)` index on `hazo_blog_site_theme` PLUS upsert semantics in `ThemeRepository.setSiteTheme` (selects-then-updates the existing row for that scope rather than ever inserting a second one) — no separate `is_active` flag to go out of sync. No DB-level `UNIQUE(scope_id, handle)` on `hazo_blog_themes` — Postgres/SQLite both treat every `NULL` as distinct, so a composite unique index including the nullable `scope_id` would not actually stop two built-in themes sharing a handle; that invariant is enforced in application code (`findBuiltInByHandle`'s upsert-by-handle check) instead, same "invariant enforced in code, not SQL" convention this file already documents for `hazo_blog_menu_items.item_type`. Postgres also gets RLS: the dual-mode nullable-scope_id policy (same shape as `hazo_blog_categories`/`hazo_blog_themes` itself) on `hazo_blog_themes`, a join-based policy on `hazo_blog_theme_versions` (no `scope_id` column of its own — inherits visibility via `theme_id`), and the strict policy on `hazo_blog_site_theme`.
+- **`BlogFileStorageProvider` gains two OPTIONAL methods, `get`/`list`** (additive, non-breaking) — needed because `hazo_blog/render`'s `renderPage` only ever reads `.liquid` files off a LOCAL filesystem directory (LiquidJS's `root` option is fs-only), so an uploaded theme stored in R2 has to be read back and materialized to local disk before it can render at all. `hazo_files`' `S3Provider` already implements both.
+- **`theme.json` schema** (`src/lib/theme-schema.ts`, Zod, exported via `./lib` and the main entry) — `name`/`version` (loose semver)/`author`/`licence`/`description`/`screenshots`, a `settings[]` array (ticket's own exact field types: `colour`/`font`/`image`/`select`/`toggle`/`text`/`range`, with `options` required for `select`), and an optional `allowedSections` map (template name -> allowed section-type list). `parseThemeJson()` collects every validation issue, not just the first. `getAllowedSectionsForTemplate()` resolves one template's list (`null` = unrestricted) but **nothing calls it yet** — see the bridge note below. `buildThemeSettingsSchema()` builds a per-theme Zod schema (type-checked, partial, unknown keys dropped) for validating a settings PATCH.
+- **Upload validation pipeline** (`src/lib/theme-validate.ts`'s `validateThemeFiles`) — the ticket's own exact checklist, in order: zip-slip path-safety re-check (absolute paths, `..`/empty segments, backslashes all rejected — defence in depth regardless of whether the caller, i.e. the platform's zip-extraction step, already checked), `theme.json` present + parses, all four required templates present (`home`/`post`/`page`/`404`), every `.liquid` file parses via `hazo_blog/render`'s OWN parser (new `parseLiquidSource()` in `src/render/engine.ts` — a pure in-memory syntax check, no file I/O, reusing the exact same `Liquid` construction + tag registrations real rendering uses, per the ticket's "don't hand-roll a second parser" instruction), total size under a configurable cap (default 20 MiB), and asset files restricted to CSS/JS/images/fonts by extension. Collects every issue into one `ThemeValidationError`, same "whole input is one unit" contract as `SectionValidationError`/`CustomFieldValidationError`. **Operates on an already-extracted `ThemeFile[]` — this package never unzips anything itself**; zip extraction is the platform repo's job (`uzip`, already available there, per the ticket's own instruction not to add a zip dependency here).
+- **ISOLATION**: `theme-validate.ts` reaches `parseLiquidSource` via a LAZY `await import("../render/engine.js")` (a relative import of this package's own internal module, not the public `hazo_blog/render` subpath) — `liquidjs` is only ever loaded into memory when a theme upload is actually being validated, so a host that never installs/activates an uploaded theme still never pays for it, preserving `./render`'s own "nothing outside it pulls in `liquidjs`" boundary (2.12.0) even though theme management itself lives in the main, db-aware entry point.
+- **`createThemeService(config, deps?)`** (`src/service/themes.ts`) — the orchestration layer: `listThemes`/`getTheme` (visibility-checked: built-in or the caller's own scope, `null` across a tenant boundary), `installBuiltInThemes` (the boot-scan bridge, below), `installThemeFromFiles` (validate -> store every file via `BlogConfig.themeStorage`'s provider -> register/bump a `BlogTheme` + `BlogThemeVersion` row — a second upload of the same theme name in the same scope is a new VERSION, not a duplicate), `getActiveTheme`/`activateTheme`/`deactivateTheme` (activating seeds `settings` from `theme.json`'s field defaults UNLESS re-activating the theme already active for that scope, which keeps its existing settings untouched), `updateThemeSettings` (schema-validated partial merge, `ThemeSettingsValidationError`/`ThemeNotActiveError`), and **`resolveRenderThemeDir({ previewThemeId }, req)`** — the ticket's own central render-integration question. A built-in theme's `storage_path` IS already a local directory (render directly, no materialization); an uploaded theme is downloaded (`provider.list`/`get`) into `BlogConfig.themes.renderCacheDir` (default `os.tmpdir()/hazo_blog_themes_cache/<themeId>/<version>`, cached behind a `.ok` marker written only after every file succeeds, so a crash mid-download retries rather than serving a half-written cache) before being handed back as a real `themeDir`. `previewThemeId` — when visible to the caller's scope — wins over the persisted active theme and is NEVER written to `hazo_blog_site_theme`; session-scoping the preview (cookie/query param) is the host's job, this function just honours whichever id it's handed.
+- **BUILT-IN THEME SCAN BRIDGE**: `installBuiltInThemes` looks for an installed npm package named `BlogConfig.themes.builtInPackageName` (default `"hazo_blog_themes"`) and walks its `themes/<handle>/{theme.json,templates/*.liquid,...}` subdirectories, validating and `upsertBuiltInTheme`-ing each one. **That package does not exist yet — ticket 07 builds it with real themes inside.** Until then (or for any host that never installs it), the scan degrades gracefully: logs once via `hazo_logs`, returns `{ available: false, installed: [] }`, never throws — same bridge shape `../render/fallback-theme.ts` (ticket 03) and `../lib/sections.ts` (ticket 05) already use for "the real thing doesn't exist yet." `deps.resolveThemesPackageRoot` is the injectable seam (same convention as `../service/media.ts`'s `deps.processMediaVariants`) that lets this package's OWN test suite point the scan at a local fixture directory (`src/__tests__/fixtures/hazo_blog_themes_fixture/`) with the same shape, rather than needing a real installed package.
+- **`allowedSections`-per-template, EXPLICITLY NOT wired into enforcement**: `theme.json` now parses and stores the field (`getAllowedSectionsForTemplate`), but `../lib/sections.ts`'s `validateSections` (ticket 05) still allows every `SECTION_TYPE_REGISTRY` type on every page, unchanged. Wiring real enforcement would mean threading the ACTIVE theme's parsed `theme.json` into every `createPost`/`updatePost` call — today those only ever see `BlogConfig`, never a resolved theme — a genuine cross-cutting change to the post-save path, bigger than "parse one more field," so it's handed off to ticket 07/08 per this ticket's own explicit instruction, not half-wired here.
+- Tests: `src/__tests__/theme-schema.test.ts` (13 cases), `src/__tests__/theme-validate.test.ts` (15 cases — including the zip-slip rejections and multi-issue collection), `src/__tests__/themes.repository.integration.test.ts` (11 cases, real SQLite), `src/__tests__/themes.service.integration.test.ts` (14 cases, real SQLite + a fake in-memory `BlogFileStorageProvider` — built-in scan against the fixture package, install-from-files standing in for "from zip," activate/deactivate, settings save/load + validation, cross-scope activation/preview rejection, and the actual local-disk materialization of an uploaded theme). 53 new tests, all passing; full suite unaffected (same pre-existing, unrelated i18n/translation-feature test failures every release since 2.10.0 has carried — verified unchanged with this release's changes reverted via `git stash` on just the files this release touched — zero regressions, +53 passing).
+- **Not done in this release (flagged, not silently deferred)**: no admin gallery/install/activate UI (ticket 08's own surface, per this ticket's scope note) — the platform repo's own commit for this ticket ships the manage API routes, a minimal settings-form auto-generation component, and the `?theme_preview=` wiring into its public render pipeline, but not a themes BROWSE screen; no theme rollback API (`hazo_blog_theme_versions` keeps full history, but nothing lets an operator reactivate an older version yet — straightforward to add on top of the existing version rows, just not asked for here); `allowedSections` enforcement (see above).
+
+Bumps 2.14.0 -> 2.15.0 (minor, new required DDL — see ⚠️ heading above).
+
+## 2.14.0 — 2026-11-08
+
+**⚠️ DDL required — section types + section builder (Phase 1b ticket 05): `sections_json` on `hazo_blog_posts`, a 12-type section registry, and the `{% section_list %}` Liquid tag.** Operators compose page layouts (hero/text/image+text/posts grid/CTA/FAQ/quote form/testimonials/logos/contact/stats/features) as an ordered, hide-able list stored alongside the post, rendered through themed partials with a safe generic fallback.
+
+- **New column** `sections_json` on `hazo_blog_posts` — `JSONB NOT NULL DEFAULT '[]'::jsonb` (Postgres, also an idempotent `ALTER TABLE ... ADD COLUMN IF NOT EXISTS` for a pre-2.14.0 table) / `TEXT NOT NULL DEFAULT '[]'` (SQLite, in the `CREATE TABLE` directly — SQLite/add-on-mode installs are expected fresh, same convention `status`/`category_id` already established for this table). Stores `[{type, version, key, settings, hidden}]`, in display order. Lives on the POST row (not `hazo_blog_revisions`) — layout composition is a page property, not versioned MDX content, same reasoning `template` already carries.
+- **`SECTION_TYPE_REGISTRY`** (`src/lib/sections.ts`, exported via `./lib` and the main `.` entry) — the 12 ticket-specified types, each with a Zod settings schema, a `defaultSettings()` factory (valid placeholder content, not empty objects — a freshly-added section is immediately previewable/savable), a display `label`, a `lucide-react` icon NAME (string, framework-free), and a `summarize()` one-liner for the admin card list. `validateSections(value)` validates+normalizes an untrusted `sections_json` array against the registry (unknown `type`, missing `key`, or a per-type schema failure all collect into one `SectionValidationError.issues[]` — same "all failures reported, not just the first" contract as `CustomFieldValidationError`); `isSafeUrl()` (`src/lib/safe-url.ts`, same allowlist as `../repository/menus.ts`'s `isSafeMenuUrl`) rejects `javascript:`/other unsafe schemes on URL-shaped settings (`hero.ctaUrl`, `cta.buttonUrl`, `logos[].url`) at WRITE time.
+- **`PostService.createPost`/`updatePost`** now validate `sections_json` unconditionally (engine-defined, not host-configured like `customFieldSchemas`) via `validateSections()` before any repository write, persisting the normalized (Zod-defaulted) shape. `UpdatePostInput.sections_json` omitted = unchanged, same convention as every other optional field — an editor save that never touches sections cannot accidentally clear them.
+- **`{% section_list %}` Liquid tag** (`src/render/tags/section-list.ts`, registered alongside tickets 03/04's tags) — iterates `page.sections` in order, skips `hidden` entries, and renders each visible one through the active theme's `sections/{type}.liquid` partial (via `this.liquid.renderFile()`, the SAME engine instance, so the partial sees the full render context plus a `section` key) — falling back to a generic card (type name + an HTML-escaped settings dump) when the theme has no matching partial. **Bridge, same shape as ticket 03's fallback-theme bridge**: the built-in `FALLBACK_THEME_DIR` ships no `sections/*.liquid` partials at all, so every section renders as the fallback card there today — expected, not a bug, until a real theme (ticket 07) ships matching partials.
+- **Built-in fallback theme** (`src/render/fallback-theme/templates/default.liquid`) now calls `{% section_list %}` right after `{{ content }}`, on the SAME line (`{{ content }}{% section_list %}`, no separating newline) specifically so the existing byte-for-byte-identical invariant (ticket 03) still holds for every row with an empty `sections_json` (the default, i.e. every pre-2.14.0 post/page and anything a host never explicitly adds sections to) — verified by keeping that exact test passing, plus a new one proving sections DO render once a page actually has them.
+- **`allowedSections`-per-template bridge, explicitly NOT built here**: there is no theme management system yet (ticket 06/07 build per-site `theme.json` storage). Per the ticket's own stated default, every registered type is allowed on every page today — `SECTION_TYPES` is the full, unnarrowed list. When ticket 06/07 lands real `theme.json` reading, `allowedSections` narrows this per template; nothing in `SECTION_TYPE_REGISTRY`/`validateSections` needs to change for that.
+- Tests: `src/__tests__/sections.test.ts` (18 cases — registry shape, every type's `defaultSettings()` validates against its own schema, valid-passes/invalid-rejected per type, unsafe-URL-scheme rejection, multi-entry issue collection), `src/__tests__/render.section-list.test.ts` (7 cases — order preserved, hidden skipped, fallback card for a theme with no partial, a real theme partial rendered instead when one exists, the partial seeing the rest of the render context, fallback+real-partial mixed on one page), `src/__tests__/posts.sections.test.ts` (7 cases — real-sqlite-adapter CRUD via `PostService`: create/round-trip, default-to-`[]`, reject-with-no-row-written, unsafe-URL rejection, update-replaces-and-revalidates, omitted-field-leaves-unchanged, reorder/duplicate/hide round-tripping exactly as the admin builder would send them). 34 new tests (2.14.0's own, plus 2 pre-existing `toPost` duplicates in `src/repository/bylines.ts`/`src/repository/tags.ts` updated to parse the new column), all passing; full suite unaffected (same pre-existing v1.6/v2.0.0 schema-split failures as every release since 2.10.0 — zero regressions, +34 passing from this release).
+- **Not done in this release (flagged, not silently deferred):** no real theme ships `sections/*.liquid` partials (every section renders as the fallback card on every live site today, per the bridge above); no `quote_form` section actually embeds a QuoteDash form (`quotedashCategory` is just captured data for a future embed renderer — the embed itself is `08.quotedash`'s own surface); the platform's own admin section-builder UI, Post PATCH wiring, and preview button ship in the platform repo's own ticket 05 commit, not here.
+
+Bumps 2.13.0 -> 2.14.0 (minor, new required DDL — see ⚠️ heading above).
+
+## 2.13.0 — 2026-11-08
+
+**⚠️ DDL required — menu system (Phase 1b ticket 04): `hazo_blog_menus` + `hazo_blog_menu_items`, a manage service, and the `{% menu "handle" %}` Liquid tag.** Named navigation menus (e.g. "main", "footer") with reference items (auto-resolved title+URL from a live post/page/category, dropped when unpublished) or custom items (own label+URL), nested to unlimited depth, reordered via drag or indent/outdent.
+
+- **New tables** `hazo_blog_menus` (`id`, `scope_id`, `name`, `handle`, unique per `(scope_id, handle)`) and `hazo_blog_menu_items` (`id`, `menu_id`, `scope_id`, `parent_id` self-referencing for nesting, `position`, `item_type` `reference`/`custom`, `ref_type`/`ref_id` for reference items, `label`/`url`/`css_class`/`target`) — both dialect files, mirrored into the platform's `migrations/0001_hazo_blog.sql`/`migrations/postgres/0001_hazo_blog.sql` in the same pass. **`scope_id` is NOT NULL on both** — a deliberate deviation from this file's own "every other table carries a nullable `scope_id`" convention, matching `hazo_blog_posts`/`hazo_blog_bylines`/`hazo_blog_app_site_domains` instead: menus are multi-tenant-platform-first (there's no useful "global menu" the way a shared legacy category/tag can be), and v1.6 add-on consumers (GoTimer/kinstripe, pinned `~1.6`) never pull this DDL at all, so there's no back-compat reason to allow `NULL` here either. `ON DELETE CASCADE` on both `menu_id` and `parent_id` means deleting a menu or any item removes its whole subtree in one statement. Postgres also gets `ENABLE`/`FORCE ROW LEVEL SECURITY` + a strict `tenant_isolation` policy on both new tables, same convention as every other NOT-NULL-`scope_id` table since 2.11.0.
+- **`createMenuRepository(adapter, scope)`** (`src/repository/menus.ts`) — CRUD for menus + items, `reorderMenuItems(menuId, items)` (batched `{id, parentId, position}` — drives both plain drag-reorder and indent/outdent from the same primitive), shape validation (`MenuItemValidationError`: custom items need `label`+`url`, reference items need `ref_type`+`ref_id`), handle-uniqueness (`MenuHandleConflictError`), and self-parent/cross-menu-parent rejection. `MenuNotFoundError`/`MenuItemNotFoundError` for unknown ids, same "throw on write, scope-filtered lookups" convention as `BylineRepository`/`DomainRepository`.
+- **`createMenuService(config)`** (`src/service/menus.ts`) — thin per-request wrapper (same `resolvePostScope` scope resolution as bylines/domains) plus the one piece of real logic this ticket needed: **`resolveMenuForRender(handle, req)`**, which walks a menu's items and, for each reference item, looks up the live post/page/category it points at — dropping the item (and its entire subtree, since nothing re-parents onto a dropped id) when the target is missing or unpublished (`isPostLive`). Returns `ResolvedMenuItem[]` (nested, render-ready). `BlogConfig.menus.resolveReferenceUrl` optionally overrides the built-in URL shape (`/${slug}` for post/page, `/category/${slug}` for category — already the platform's own public routing convention, so most hosts never need to set this). `buildResolvedMenuTree` (the tree-builder) is exported standalone and unit-tested without a DB.
+- **`{% menu "handle" %}` Liquid tag** (`src/render/tags/menu.ts`, registered alongside ticket 03's five tags) — renders a nested `<nav><ul><li>` from `RenderContext.menus[handle]`, an ALREADY-resolved tree the host builds via `resolveMenuForRender`/`resolveAllMenusForRender` before calling `renderTemplate()`/`renderPage()` (same "no db/fs/network inside a template" boundary as `related_posts`/`faq`). Active item gets `aria-current="page"` (compared against `request.path`, already in context); a `target="_blank"` item automatically gets `rel="noopener noreferrer"`. `RenderMenuItem` is a deliberately separate, structurally-identical type from `ResolvedMenuItem` (not a shared import) — same "`src/render/*` stays self-contained" reasoning as every other `Render*` type.
+- Tests: `src/__tests__/menus.repository.integration.test.ts` (29 cases — CRUD, nesting, reorder/indent/outdent, validation, tenant isolation, real SQLite via the `better-sqlite3` driver so `ON DELETE CASCADE` is actually exercised — the default `sql.js` driver these integration tests normally run under does not enforce foreign keys at all), `src/__tests__/menus.service.integration.test.ts` (14 cases — reference resolution for published/draft/missing posts and categories, label overrides, dropped-subtree behaviour, nesting/ordering, `resolveAllMenusForRender`), plus 7 new cases in `src/__tests__/render.tags.test.ts` (`buildMenu`'s nesting/active-state/escaping, and the tag wired through a real Liquid template). 50 new tests, all passing; full suite unaffected (same pre-existing unrelated failures as 2.12.0 — see that entry).
+- **Not done in this release (flagged, not silently deferred):** no `next/menu-routes.ts` API-key route factory (the `createBylineManageRoutes`-shape documented in this package's own CLAUDE.md) — every admin resource shipped since ticket 14 (`domains`, `bylines`, `categories`/`tags`) is actually consumed by the BlogSketch platform via its OWN `/api/*` Next.js routes calling `createXService`/`createXRepository` directly (with the platform's own membership check), never through this package's API-key route factories, so menus follows that same real precedent rather than building an unused route factory. (The platform's own public-page render pipeline wiring + admin UI ship in the platform repo's own ticket 04 commit.)
+
+Bumps 2.12.0 -> 2.13.0 (minor, new required DDL — see ⚠️ heading above).
+
+## 2.12.0 — 2026-11-07
+
+**Additive — LiquidJS render engine behind a new isolated `./render` export boundary (Phase 1b ticket 03, critical path for themed public sites).** `liquidjs` is a real `dependencies` entry now, but it is NEVER pulled into a consumer's bundle unless that consumer explicitly does `import ... from "hazo_blog/render"` — nothing under `src/index.ts`, `src/next/index.ts`, or `src/ui/index.ts` imports from `src/render/*`, mirroring the isolation principle the package's own `./ui` boundary already established (see `src/render/index.ts`'s header comment). Add-on consumers (GoTimer, kinstripe) pinned to `~1.6` are completely unaffected; even a `2.x`+ consumer that only imports `.`/`./next`/`./ui` never loads `liquidjs`.
+
+- **`renderTemplate(themeDir, templateName, context)`** (`src/render/engine.ts`) — the core primitive: renders `templates/{templateName}.liquid` under a theme directory with a `RenderContext`. One `Liquid` engine instance (with its own parsed-template cache) is kept in-memory per `themeDir`; `invalidateThemeCache(themeDir)` drops it so the next render re-reads from disk — call this whenever a theme's files change (no theme-change event source exists yet; ticket 06/07 build real theme storage on top of this).
+- **`resolveTemplateName(themeDir, { type, template })`** (`src/render/resolve.ts`) + **`renderPage(themeDir, { type, template }, context)`** (`src/render/engine.ts`) — the template resolution chain: `templates/{page.template}.liquid` -> `templates/{type}.liquid` -> `templates/default.liquid` -> `templates/404.liquid`. `renderPage` reports which template actually won and whether it fell through to `404`.
+- **`RenderContext`** (`src/render/types.ts`): `content` (pre-rendered HTML — this is the two-pass pipeline: MDX compiled to HTML first, then Liquid renders the page template around it), `post` (title/slug/dates/categories/tags/customFields/seo overrides, plus `faq`/`related` — see below), `site` (title/tagline/logo/favicon/locale/social/analytics), `page` (for page-type content), `request` (url/path/segments). Liquid templates get ONLY this object — no db, filesystem, or network handle is ever placed in scope; the engine itself reading `.liquid` files off `themeDir` is loading the template source, not something a template/tag can reach at render time.
+  - **Judgment call, flagged rather than silently decided:** the ticket's context-contract bullet doesn't literally list data for `{% related_posts %}` or `{% faq %}`. Rather than have those tags reach outside `context` (which would violate the "no db/fs/network from inside a template" invariant), both are modelled as pre-computed fields nested under `post` — `post.related: RenderRelatedPost[]` and `post.faq: RenderFaqItem[]` (same `question`/`answer` shape as this package's existing `FaqItem`) — populated by the host the same way `content` itself already is.
+- **Platform Liquid tags** (`src/render/tags/*.ts`, registered via `registerPlatformTags()`): `{% seo_head %}` (canonical link, OG/Twitter meta, BlogPosting/WebSite JSON-LD, per-entry `noindex`/title/description/image overrides), `{% image media size: "..." %}` (responsive `<picture>` with AVIF/WebP `<source>`s filtered to the requested size + a plain `<img>` fallback), `{% related_posts limit: N %}`, `{% toc %}` (table of contents extracted from the `<h2>`/`<h3>` headings already in `content` — decodes the small set of HTML entities `escapeHtml()` itself produces before slugifying/re-escaping, to avoid double-escaping and junk ids like `conclusion-amp-next-steps`), `{% faq %}` (accordion + FAQPage JSON-LD). Every tag's HTML-escaping is manual (`src/render/html.ts`) since `emitter.write()` bypasses Liquid's own output escaping. Every tag also exports its pure builder function (`buildSeoHead`, `buildImageTag`, `buildRelatedPosts`, `buildToc`/`extractHeadings`, `buildFaq`) so it's unit-testable without parsing any Liquid markup.
+- **Built-in fallback/bridge theme** (`src/render/fallback-theme.ts` + `src/render/fallback-theme/templates/{default,404}.liquid`, `FALLBACK_THEME_DIR`): there is no theme management system yet (ticket 06/07 build per-site theme storage + the real "trades" theme on top of this engine). This ships JUST `default.liquid` (literally `{{ content }}`, no chrome at all) + `404.liquid` so a host with no real theme can still route its public pages through `renderTemplate()`/`renderPage()` instead of a hand-rolled MDX-to-React pipeline, producing byte-for-byte the same HTML fragment as plain MDX rendering did before. `.liquid` files aren't TypeScript sources, so `npm run build` now also runs `scripts/copy-render-assets.mjs` to copy them into `dist/render/fallback-theme/` alongside the compiled JS.
+- Tests: `src/__tests__/render.resolve.test.ts` (6 cases — the full resolution chain + edge cases), `src/__tests__/render.engine.test.ts` (7 cases — correct HTML structure from a minimal test theme, `renderPage`'s resolution+404 fallthrough, the in-memory per-theme cache AND its invalidation, including that two themes' caches are independent), `src/__tests__/render.tags.test.ts` (18 cases — every tag's pure builder tested in isolation with known input -> expected output, PLUS one render-through-real-Liquid test per tag proving `registerPlatformTags()` wiring), `src/__tests__/render.fallback-theme.test.ts` (2 cases — the bridge theme reproduces plain content with no chrome, and has a working `404.liquid`). 35 new tests, all passing; full suite 530 passing / 52 failing (same pre-existing v1.6/v2.0.0 schema-split failures as 2.10.0/2.11.0 — zero regressions, +35 passing from this release).
+- `test-app/app/render-demo/page.tsx` + `test-app/themes/demo/templates/*.liquid` — a server-rendered manual sanity-check page exercising every platform tag and both the demo theme and the fallback bridge theme side by side.
+- **Not done in this release (flagged, not silently deferred):** no host actually calls this engine yet from a Next.js route in THIS package — `createBlogPostPage`/`createBlogIndexPage` (`src/next/pages.tsx`) are untouched, still rendering via `BlogContent`'s React/MDX pipeline. Wiring a real host's public routes to this engine (with the fallback theme as a bridge) is the BlogSketch platform app's own ticket 03 work, done in that repo, not here.
+
+Bumps 2.11.0 -> 2.12.0 (minor, additive — no DDL, no removed/renamed exports).
+
+## 2.11.0 — 2026-11-06
+
+**⚠️ DDL required — Postgres Row-Level Security policies (Phase 1a issue 17, platform's tenant-isolation release gate).** Defence-in-depth backstop on top of the repository layer's existing scope_id filtering — not a behaviour change for any consumer that doesn't set `app.current_scope_id`, until that consumer's Postgres has this migration applied.
+
+- **New Postgres-only DDL section** at the end of `db_setup_postgres.sql` (mirrored byte-for-byte into `migrations/db_setup_postgres.sql`, same convention this file already follows) — no SQLite equivalent exists or is attempted; this establishes the precedent for any future Postgres-only feature in this file (its own section, clearly headed, dialect files allowed to diverge only there).
+- `ENABLE ROW LEVEL SECURITY` + `FORCE ROW LEVEL SECURITY` + one `tenant_isolation` policy on every `hazo_blog_*` table: `hazo_blog_categories`, `hazo_blog_tags`, `hazo_blog_posts`, `hazo_blog_revisions`, `hazo_blog_post_tags`, `hazo_blog_bylines`, `hazo_blog_post_bylines`, `hazo_blog_media`, `hazo_blog_media_usage`, `hazo_blog_settings`, `hazo_blog_app_site_domains`. `FORCE` matters: the app's Postgres role OWNS these tables in production (`infra/provision.sh`'s `createdb -O`), and table owners bypass RLS by default — verified by hand against a real Postgres that without `FORCE` the owning role saw every tenant's rows regardless of the GUC.
+- New `hazo_blog_current_scope_id()` SQL function wraps `current_setting('app.current_scope_id', true)` and collapses it through `NULLIF(..., '')`. Found by testing against a real Postgres, not assumed: once any transaction on a pooled connection has done `SET LOCAL app.current_scope_id = '...'` and committed, the GUC resets to `''` (empty string) for the rest of that session, NOT back to SQL NULL — a naive `IS NOT NULL` fail-safe check would treat a later request that forgot to set the GUC as "scoped" and leak every NULL-scope_id (global) row. The function makes "unset" mean the same thing on a fresh connection and a recycled one.
+- Fail-safe default is **deny all** when the GUC is unset/empty (not "allow all") — the safer of the two options, on the reasoning that a forgotten `SET LOCAL` should produce a loud empty result, not a cross-tenant leak.
+- Nullable-`scope_id` tables (`categories`/`tags`/`settings`) keep this package's own documented "NULL = legacy/global, visible to every tenant" rule (same rule `assertCategoryVisible`/the tags repository already enforce in application code) — RLS mirrors that, it doesn't invent a stricter rule. NOT-NULL-`scope_id` tables get strict equality. The two join tables with no `scope_id` column of their own (`hazo_blog_post_tags`/`hazo_blog_post_bylines`) reach through `post_id` to `hazo_blog_posts.scope_id`.
+- **Compatibility note:** this assumes a consumer that always sets `app.current_scope_id` per request (a genuinely multi-tenant deployment). A single-tenant/add-on-mode consumer that never sets the GUC would see zero rows under these policies, not its own data. GoTimer/kinstripe (add-on mode) are pinned to `~1.6` and never pull this DDL, so they're unaffected; flag this again before ever applying this migration to a single-tenant deployment on `2.x`+.
+- **App-side wiring is NOT included in this release.** These policies are only a real backstop once the app issues `SET LOCAL app.current_scope_id = '<scope>'` inside the transaction wrapping each request. The BlogSketch platform app does not yet do this (see Phase 1a issue 17's write-up / `docs/TENANT_ISOLATION_TESTING.md` in the platform repo) — query-level scope filtering, already in place, is what's actually protecting production right now. The policies themselves are proven correct independently via direct SQL (see below), which is what "RLS tested: direct SQL query ... returns no rows" asked for.
+- New `src/__tests__/rls.postgres.integration.test.ts` — real Postgres integration test (8 cases), env-gated on `TEST_POSTGRES_URL` (skipped, not failed, when unset — this is the first env-gated/Postgres-only integration test in this package, establishing that precedent; every other integration test here runs against SQLite). Creates its own throwaway role + database owned by that role (mirrors production's ownership shape, so the FORCE-RLS behaviour is actually exercised, not bypassed by a superuser/owner shortcut), applies the real `db_setup_postgres.sql`, then proves: own-scope + global visibility, cross-tenant SELECT/UPDATE/INSERT all blocked, join-table policies scoped correctly, the fail-safe-deny-when-unset behaviour (including the empty-string gotcha above), and that `FORCE ROW LEVEL SECURITY` is actually set on disk (`pg_class.relforcerowsecurity`). Run locally with `TEST_POSTGRES_URL=postgres://user@host:port/db npm test -- rls.postgres`.
+- **Not in scope for this release** (flagged, not silently skipped): `hazo_seo_*` tables are also multi-tenant with a nullable `scope_id` and have no RLS — out of scope for this ticket (a different repo/package), proposed as a follow-up.
+
+**Bug fix, found by this same ticket's real-DB (not mocked) end-to-end testing — `PostRepository.createPost` violated its own foreign key under real FK enforcement.** `createPost` (`src/repository/posts.ts`) inserted the new post's first `hazo_blog_revisions` row (`post_id` is `NOT NULL REFERENCES hazo_blog_posts(id)`) BEFORE inserting the `hazo_blog_posts` row that `post_id` points at — an immediate FK violation under a connection with `PRAGMA foreign_keys = ON`, which is `hazo_connect`'s `BetterSqlite3Adapter` default AND this platform's own `.env.local` (`HAZO_CONNECT_SQLITE_DRIVER=better-sqlite3`). Every existing test in this package (and in the platform) that exercises `createPost` either mocks the service entirely or runs against whichever driver `createHazoConnect`'s raw factory defaults to when none is specified (sql.js/WASM, which doesn't enforce the pragma the same way) — so this never surfaced until Phase 1a issue 17's comprehensive suite created a REAL post through a REAL `better-sqlite3` connection for the first time anywhere in this package's or the platform's test history. Fixed by reordering: insert the post row first (`draft_revision_id: null`), then the revision, then `updateById` the post's `draft_revision_id` to point at it. No interface/behaviour change for any caller — same inputs produce the same `Post` shape back; this is a patch-level fix, not a DDL/API change. New coverage is the tenant-isolation suite itself (platform repo), not a new test in this package — flagged here rather than silently fixed with no trace.
+
+Bumps 2.10.0 -> 2.11.0 (minor, new required DDL — see ⚠️ heading above; the `createPost` fix above is a patch-level fix riding along in this same release rather than a separate point release).
+
+## 2.10.0 — 2026-11-06
+
+**Additive — v2 tags + minimal custom-fields schema validation (Phase 1a issue 15, post editor).** Two gaps the platform's post editor needed closed:
+
+- **Tags on v2 posts.** `hazo_blog_post_tags`/`hazo_blog_tags` already existed (legacy v1.6 tables, `post_id` already pointing at the current `hazo_blog_posts`, surrogate `id` PK) — reused AS-IS, no new DDL. New `src/repository/tags.ts`/`src/service/tags.ts` (`createTagRepository`/`createTagService`), mirroring `./bylines.ts`'s shape exactly: `listTags` (scope-visible — this tenant's own tags PLUS global `scope_id: null` ones, since `hazo_blog_tags.scope_id` is nullable and its unique index doesn't dedupe NULLs), `getOrCreateTag` (select/create UX, own-scope-first lookup), `createTag`, `assignTagToPost`/`removeTagFromPost` (idempotent), `listTagsForPost`, `listPostsByTag`. Because `hazo_blog_post_tags` has NO `scope_id` column of its own (unlike `hazo_blog_post_bylines`), every cross-table reference here is visibility-checked in code — a tag with a real, DIFFERENT non-null `scope_id` is treated as not found, same cross-tenant-reject rule `assertCategoryVisible` (issue 12's security fix) set for `category_id`. New errors: `TagNotFoundError`, `PostNotFoundForTagError`.
+- **Minimal custom-fields schema validation.** `Post.custom_fields` stays an untyped JSONB blob — this adds an OPTIONAL per-`type` Zod hook, not a schema-authoring product: `BlogConfig.customFieldSchemas?: Record<string, ZodTypeAny>`. `createPostService.createPost`/`updatePost` validate `input.custom_fields` against the schema for the post's `type` (the input's `type` on create, the EXISTING post's `type` on update — never the input's, since `UpdatePostInput` has no `type` field) when both a schema is configured AND `custom_fields` is actually supplied; a mismatch throws the new `CustomFieldValidationError` (carries every failing field via Zod's issues, not just the first) and blocks the ENTIRE save, same all-or-nothing contract as a stale `expectedRev`. No schema configured for a `type` = exactly today's untyped behaviour (no-op). `zod` is now a real dependency of this package (`^4.6.7`) — only ever imported type-only (`ZodTypeAny`) in `types/index.ts`; `service/posts.ts` never imports zod itself, just calls `.safeParse()` structurally on whatever the host hands it, so this package never pins the host's zod version at runtime.
+
+- **`src/repository/tags.ts`** (new), **`src/service/tags.ts`** (new): see above.
+- **`src/service/posts.ts`**: `validateCustomFields` + `CustomFieldValidationError`, wired into `createPost`/`updatePost`.
+- **`src/types/index.ts`**: `Tag`, `CreateTagInput`; `BlogConfig.customFieldSchemas`.
+- **`src/index.ts`**: new exports — `createTagRepository`, `createTagService`, `TagNotFoundError`, `PostNotFoundForTagError`, `CustomFieldValidationError`.
+- Tests: `src/__tests__/tags.repository.integration.test.ts` (24 cases — CRUD, assignment, `listPostsByTag`, global/null-scope tag visibility, tenant isolation, mirroring `bylines.repository.integration.test.ts`'s style) and `src/__tests__/posts.custom-fields.test.ts` (8 cases — valid passes, invalid rejected with every failing field, no-schema-configured and omitted-field no-ops, update validates against the post's OWN type). Full suite: 495 passing / 52 failing (same pre-existing v1.6/v2.0.0 schema-split failures as 2.9.1 — zero regressions, +32 passing from this release).
+
+Bumps 2.9.1 -> 2.10.0 (minor, additive — no DDL).
+
+## 2.9.1 — 2026-11-06
+
+**Security fix — domain-claim squatting (⚠️ DDL required — index change only, no column/table change).**
+`addDomain` blocked registration on ANY existing row for a domain string,
+verified or not — a tenant could squat an unverified claim on a domain it
+doesn't own and permanently block the real owner from ever registering it
+(denial of service). `hazo_blog_app_site_domains`'s global unique index on
+`domain` is now a PARTIAL unique index (`WHERE verified`/`WHERE verified =
+1`) so only a verified row blocks registration; multiple unverified claims
+on the same domain string can coexist. `findDomainByHost`/
+`resolveScopeByDomain` now only ever return a VERIFIED row (previously
+returned any match, relying on the caller to check `.verified` — simplified
+to the stricter contract). `verifyDomain` now deletes losing unverified
+sibling claims on the same domain string once one of them actually proves
+ownership (new `deleteCompetingUnverifiedClaims`). Postgres/SQLite hosts
+upgrading need to drop the old plain unique index and create the new
+partial one (see `db_setup_*.sql`'s updated `CREATE UNIQUE INDEX`
+statements) — no data loss, no column change.
+
+## 2.9.0 — 2026-11-06
+
+**Additive — `getPostBySlug` for the v2 `Post` model (Phase 1a issue 14).**
+`PostRepository`/`PostService` gain `getPostBySlug(slug, opts?: { locale?
+})` — the v2 content model (`hazo_blog_posts`) had no slug-based lookup at
+all before this (only `getPostById`, plus pagination-oriented `listPosts`),
+which the platform's public `/{slug}` route resolver needs to turn a URL
+slug into a post/page. Status-agnostic, same convention as `getPostById` —
+callers check `isPostLive` themselves. Mirrors the legacy
+`BlogRepository.getPostBySlug`'s exact `locale IS NULL` vs. `locale = ?`
+query-building convention (`eq` with a literal `null` doesn't match on
+Postgres). No DDL change — reuses the existing
+`(scope_id, slug, COALESCE(locale, ''))` unique index.
+
+- **`src/repository/posts.ts`**: new `getPostBySlug` on `PostRepository` +
+  implementation.
+- **`src/service/posts.ts`**: new `getPostBySlug` on `PostService`, thin
+  passthrough to the repository.
+- Tests: 2 new cases in `posts.repository.integration.test.ts` (default-
+  locale resolution + tenant isolation; locale-variant resolution). Full
+  suite: 463 passing / 52 failing (same pre-existing failures as 2.8.0).
+
+## 2.8.0 — 2026-11-06
+
+**⚠️ DDL required — app site domains (Phase 1a issue 14).** Adds
+`hazo_blog_app_site_domains` (both dialects + `migrations/`): `id`,
+`scope_id` (NOT NULL — see table comment), `domain`, `verified`,
+`is_primary`, `created_at`. `domain` is unique GLOBALLY, not per-scope (a
+domain can only ever belong to one tenant — see the table comment for why
+this deviates from this package's usual `(scope_id, slug)` compound
+uniqueness). Postgres hosts need the new `CREATE TABLE`/index statements
+applied; SQLite hosts just re-run `db_setup_sqlite.sql`.
+
+This is the first unauthenticated-public-facing table this package ships:
+it's what the platform's Host-based routing (Host header -> domain ->
+`scope_id`, no membership check) resolves against, and what Caddy's
+on-demand TLS `ask` endpoint checks before issuing a certificate. Tenant
+isolation matters even more here than usual — an unknown or unverified
+domain must never resolve to any scope, let alone a default one.
+
+- **`src/types/index.ts`**: new `AppSiteDomain`/`AddAppSiteDomainInput`.
+  `BlogConfig` gains two new optional nested configs: `cdn?: { purgeUrl }`
+  (CDN cache-purge-by-URL, called from the new `after:publish` hook below)
+  and `domains?: { verificationSecret? }` (seeds the deterministic
+  verification token — see below). Both follow the exact "optional feature,
+  omit to skip" shape `BlogConfig.seo` already established in 2.6.0.
+- **`src/repository/domains.ts`** (new): `createDomainRepository(adapter, scope)`
+  — scoped CRUD (`addDomain`/`listDomains`/`removeDomain`/`markVerified`/
+  `setPrimary`/`getPrimaryDomain`); first domain added to a scope becomes
+  primary automatically. Plus a deliberately UNSCOPED `findDomainByHost`
+  (by normalized/lower-cased domain, across every scope) — the primitive
+  both `resolveScopeByDomain` and the `ask` route resolve a bare Host header
+  against, since by definition neither yet knows which scope it belongs to.
+  `DomainNotFoundError`/`DomainAlreadyRegisteredError`.
+- **`src/lib/domain-token.ts`** (new): `domainVerificationToken(scopeId, domain, secret?)`
+  — a DETERMINISTIC `sha256(scopeId:domain:secret)` token, not a column
+  stored on the row (keeps `AppSiteDomain`'s shape to exactly the ticket's
+  literal column list). `domainVerificationRecordName(domain)` names the
+  TXT record operators are asked to create: `_blogsketch-verify.{domain}`.
+  Falls back to a documented, exported, dev-only insecure secret
+  (`INSECURE_DEV_FALLBACK_SECRET`) when `BlogConfig.domains?.verificationSecret`
+  is omitted — real hosts should set a real secret.
+- **`src/lib/domain-dns.ts`** (new): `verifyDomainTxtRecord(domain, expectedToken, resolveTxt?)`
+  — the real `dns.promises.resolveTxt` lookup at the TXT record name above,
+  with an injectable resolver (tests never hit real DNS). Never throws —
+  any DNS failure (NXDOMAIN, timeout, no records) resolves to `false`.
+- **`src/service/domains.ts`** (new): `createDomainService(config)` — thin
+  per-request wrapper over `DomainRepository` (same `resolvePostScope`
+  scope-resolution convention as `createBylineService`), plus
+  `verifyDomain` (runs the real DNS check, marks verified on a match, never
+  throws on a failed *verification*, only on an unknown id) and
+  `verificationInstructions` (TXT/CNAME/A record values for the admin
+  screen). Also exports the standalone, UNSCOPED `resolveScopeByDomain(config, host)`
+  → `{ scopeId, verified } | null` — the platform's host-resolution cache's
+  DB-fallback primitive, and the `ask` route's own lookup. Returns `null`
+  for any unregistered host; never a default/fallback scope.
+- **`src/service/cdn-hooks.ts`** (new): `registerCdnHooks(hooks, config, cdn)`
+  — a default `after:publish` handler, following `./seo-hooks.ts`'s EXACT
+  "optional feature wired through `BlogConfig` + the hook bus" pattern
+  (same double-registration `WeakSet` guard). Purges the newly-published
+  post's absolute URL via `cdn.purgeUrl`, skipped when the post isn't live
+  right now (same `isPostLive` gate `seo-hooks.ts` uses). Wired into
+  `createPostService` (`src/service/posts.ts`) alongside `registerSeoHooks`,
+  gated on `config.cdn`.
+- **`src/next/domain-routes.ts`** (new): `createDomainAskRoute(config)` —
+  Caddy's on-demand TLS `ask` endpoint: a plain public GET (no auth, same
+  convention as `createBlogSearchRoute`/`createBlogFeedRoute`) that takes
+  `?domain=`, returns 200 only when that domain resolves to a VERIFIED
+  scope, 403 otherwise (including "never registered at all"). Exported from
+  the main `hazo_blog` entry, not `hazo_blog/next` (React-free, same
+  convention as every other route-handler factory).
+- Everything above is re-exported from `src/index.ts`.
+- Tests: `domains.repository.integration.test.ts` (CRUD + tenant isolation +
+  global uniqueness), `domains.service.test.ts` (DNS-mocked verify flow +
+  `resolveScopeByDomain`'s "unknown/unverified never resolves to a scope"
+  guarantee), `domain-token.test.ts`, `domain-dns.test.ts` (mocked
+  `resolveTxt`, never real DNS), `cdn-hooks.test.ts`, and
+  `routes.domain-ask.test.ts`. 32 new tests, all passing; full suite:
+  461 passing / 52 failing (same 52 pre-existing failures as 2.7.1 — no
+  regressions).
+
+## 2.7.1 — 2026-11-06
+
+**Security fix — cross-tenant category IDOR.** `createPost`/`updatePost`
+stored a caller-supplied `category_id` with no scope check — a post in one
+tenant could reference (and, via `listPostsForAdmin`, display) a category
+belonging to a different tenant. `category_id` is now validated with a new
+`assertCategoryVisible()`: a real category owned by another scope is
+rejected (new `CategoryNotFoundError`); a dangling/never-existed id is still
+accepted and resolves to "uncategorized", unchanged from 2.7.0's intended
+soft-ref behaviour. `listPostsForAdmin`'s batch category/byline resolution
+also gained a defense-in-depth scope filter. No DDL change.
+
+## 2.7.0 — 2026-11-06
+
+**⚠️ DDL required — post list / primary category (Phase 1a issue 12).** Adds
+a nullable `category_id TEXT` column to `hazo_blog_posts` (both dialects +
+`migrations/`). No backfill needed (`NULL` = uncategorized, correct for
+every pre-existing row). Postgres hosts need the idempotent
+`ALTER TABLE ... ADD COLUMN IF NOT EXISTS` statement (db_setup_postgres.sql)
+applied to existing databases; SQLite hosts just re-run `db_setup_sqlite.sql`
+(fresh `CREATE TABLE IF NOT EXISTS`), same upgrade story as the `status`
+column added in 2.2.0.
+
+Supports the platform's admin content-list screen (editors browsing/filtering
+posts and pages) — new filters, a "primary category" field on `Post`, and a
+dedicated admin-list query that resolves category + byline display data
+without an N+1 query explosion.
+
+- **`src/types/index.ts`**:
+  - `Post.category_id: string | null` (new) — a loose reference to
+    `hazo_blog_categories`, reusing the SAME legacy table the v1.6
+    `BlogPost.category_id` pointed at. Deliberate: the ticket only asked for
+    a single "primary category" and there's no Phase 1a ticket for a v2
+    category system, so this is a minimal addition rather than a new one.
+    Not a DB FK, matching every other optional/legacy cross-table reference
+    in this package. `CreatePostInput`/`UpdatePostInput` both gain an
+    optional `category_id`.
+  - `ListPostsQuery` gains `categoryId?: string`, `bylineId?: string`, and
+    `hasPendingChanges?: boolean` (SQL-level — `live_revision_id IS NOT
+    NULL AND draft_revision_id IS NOT NULL`, so pagination/totals stay
+    correct, unlike a post-hoc JS filter using the existing
+    `hasPendingChanges()` helper from `src/lib/revisions.ts`). `sortBy` gains
+    `"title"`.
+  - New `PostListItem` (extends `Post` with `category: { id, name, slug } |
+    null` and `bylines: Byline[]`) and `PaginatedPostListResult` —
+    denormalized display types for the admin list screen, kept separate
+    from `Post`/`PaginatedPostsResult` so ordinary callers (e.g. the issue
+    11 sitemap source) don't carry a join they don't need.
+- **`src/repository/posts.ts`**:
+  - `listPosts` applies `categoryId` (`category_id = ?`), `hasPendingChanges`
+    (two `IS NOT NULL` clauses), and `bylineId` (one extra query against
+    `hazo_blog_post_bylines` for matching `post_id`s, then an `id IN (...)`
+    clause — same pattern `listPostsByByline` in `../repository/bylines.ts`
+    already uses the other direction; NOT a SQL join).
+  - New `listPostsForAdmin(query?)`: calls `listPosts` for the filtered/
+    paginated page, then batch-resolves `category_id` → `{id, name, slug}`
+    and this page's bylines (ordered by position) with one extra query
+    each — never a per-row query, never a SQL join. A join was considered
+    and rejected: this package has no existing join-query precedent,
+    bylines alone would need a 3-table join to preserve ordering, and
+    `category_id` is a loose/legacy reference that may not resolve at all.
+    Own `createCrudService` instances for `hazo_blog_categories`/
+    `hazo_blog_bylines`/`hazo_blog_post_bylines` (duplicated rather than
+    importing `../repository/bylines.ts`, same "stay independently
+    testable" convention that module's `PostNotFoundForBylineError`
+    doc-comment already documents).
+- **`src/service/posts.ts`** — `PostService.listPostsForAdmin(query?, req?)`,
+  a thin delegate to the repository method, same shape as every other
+  `PostService` method.
+- **DDL** — see the `⚠️ DDL required` note above.
+- **Tests** — `src/__tests__/posts.repository.integration.test.ts`: new
+  `category_id` round-trip coverage, `categoryId`/`bylineId`/
+  `hasPendingChanges` filter coverage (including that `bylineId` with no
+  matches returns a well-formed empty page, and that `hasPendingChanges`
+  affects pagination totals, not just the returned rows), and
+  `listPostsForAdmin` coverage (category/byline resolution, a dangling
+  `category_id` resolving to `null`, filter pass-through, tenant
+  isolation).
+
+**No route-factory changes.** Following the pattern the platform app
+already established for hazo_seo in Phase 1a issue 11 (calling service
+functions directly from its own `/app/api/*` routes rather than mounting a
+package route factory), the platform's admin content-list screen calls
+`createPostService(buildBlogConfig(scopeId)).listPostsForAdmin(...)`
+directly — `src/next/post-routes.ts`'s `createPostManageRoutes` (API-key
+auth) is for a different consumer (programmatic/management API) and is
+unchanged by this ticket.
+
+## 2.6.0 — 2026-11-06
+
+SEO admin screens, hazo_blog portion (Phase 1a issue 11). Adds a
+`previousSlug` hook field, a hazo_seo-shaped sitemap source for the v2 `Post`
+model, and optional default SEO automation hooks (auto-301 redirects +
+IndexNow submission) wired through a new `BlogConfig.seo` field. hazo_seo is
+a NEW optional peer dependency (`^0.19.0`) — nothing in this release requires
+it to be installed.
+
+- **`src/lib/hook-bus.ts`** — `AfterSaveHookPayload` gains `previousSlug:
+  string | null`: the post's slug immediately before this save, `null` on
+  `action: 'create'`. Lets an `after:save` handler detect a slug change
+  without re-fetching the pre-save row. `src/service/posts.ts`'s
+  `saveWithHooks` now passes `current?.slug ?? null` through on every
+  `emitAfter("after:save", ...)` call. Purely additive to an existing
+  payload interface — safe for any existing handler that destructures only
+  the fields it already used.
+- **`src/lib/status.ts`** — new `isPostLive(post: Post): boolean`
+  (`status === 'published' && deleted_at === null`), the v2 model's
+  equivalent of the legacy `BlogPost` model's "live-post gate" invariant.
+  For the v2 `ContentStatus` lifecycle this is a single check with no date
+  math: the `'scheduled' -> 'published'` transition itself is only performed
+  once `publish_at` has passed (the auto-publish maintenance job), so
+  `status === 'published'` already means "live right now". Shared by both
+  new features below so they agree on what "live" means. Re-exported from
+  `./lib/index.js`.
+- **`src/seo/hazo-seo-sitemap-source.ts`** (new) — `createBlogSitemapSource
+  (service: PostService, config: ResolvedBlogConfig, opts?: { name?: string;
+  postType?: string; req?: Request }): SitemapSource` (hazo_seo's
+  `SitemapSource`/`SitemapEntry`, type-only imported — zero runtime
+  dependency just to use the types). A SEPARATE, NEW function from the
+  existing `getBlogSitemapEntries` (legacy `BlogPostWithRelations` model,
+  untouched) — does not import from or modify it. Lists live posts via
+  `PostService.listPosts({ status: 'published', ... })`, optionally filtered
+  by `opts.postType` (one sitemap SOURCE per content type, e.g.
+  `'blog-posts'`/`'blog-pages'`, is a host choice this function supports but
+  doesn't require). `lastModified` is the LIVE revision's `created_at` when
+  `post.live_revision_id` resolves, falling back to `post.updated_at` only
+  when it can't — a draft edit bumps `updated_at` without moving what's
+  actually public, so the live revision's own timestamp is the only
+  truthful value (matches hazo_seo's truthful-lastmod-guard philosophy).
+  `images: [post.og_image]` when set. Never sets `alternates` — the v2
+  `Post` model has no translation-cluster/grouping field to derive hreflang
+  from (documented gap, not a bug). `opts.req` is new/notable: hazo_seo's
+  `SitemapSource.fetch(since?)` signature has no request parameter, but
+  `PostService` needs one whenever `BlogConfig.resolveScope` is configured
+  (`resolvePostScope` throws `ScopeUnresolvedError` otherwise) — a
+  multi-site host threads a fixed `Request` here (pinning the bound service
+  to one site) via closure; add-on/single-site hosts (no `resolveScope`
+  configured) can omit it. No "list every scope" primitive exists anywhere
+  in this package — a sitemap-per-site host builds one `PostService`/one
+  `createBlogSitemapSource` call per site. Re-exported from
+  `src/seo/index.ts` (so it's reachable via both the `hazo_blog/seo` subpath
+  and the main `hazo_blog` barrel) and from `src/index.ts`.
+- **`BlogConfig.seo`** (new, optional; `src/types/index.ts`) —
+  `{ redirectsService?: { createRedirect(input: { fromPath; toPath;
+  statusCode?; scopeId? }): Promise<unknown> }; indexNow?: { key; host;
+  endpoint?; dryRun?; fetchImpl? } }`. `redirectsService` is a narrow
+  duck-typed shape (not hazo_seo's concrete type) so the field type-checks
+  with hazo_seo absent; hazo_seo's real `createRedirectService(adapter)`
+  return value satisfies it as-is.
+- **`src/service/seo-hooks.ts`** (new) — `registerSeoHooks(hooks: HookBus,
+  config: ResolvedBlogConfig, seo: NonNullable<BlogConfig['seo']>): void`,
+  wired once from `createPostService(config)` (right after its `hooks`
+  variable is built, via `resolveConfig(config)`) when `config.seo` is
+  present:
+  - `after:save` — on `action: 'update'` where `previousSlug` differs from
+    the new slug AND the post is live (`isPostLive`) AND
+    `seo.redirectsService` is configured, creates a 301 redirect from the
+    old root-relative path to the new one (derived by stripping
+    `config.baseUrl` off `postUrl(...)` — there's no path-only variant
+    exported). A slug change on a draft/unpublished post deliberately
+    creates no redirect (nothing was ever public at the old slug). The
+    `createRedirect` call is NOT wrapped in try/catch — hazo_seo's
+    `from_path` is a GLOBAL primary key across every scope/site (inherited
+    limitation, explicitly not fixed here), so two tenants renaming into the
+    same old slug can collide, and that collision's synchronous `Error`
+    degrades to "no redirect created, logged" via `HookBus.emitAfter`'s
+    existing catch — never a broken save.
+  - `after:publish` — when `seo.indexNow` is configured, resolves
+    `hazo_seo/files` lazily via `optional_import` (same convention as
+    `resolvePostScope`'s `hazo_auth/server-lib` lookup) and calls
+    `submitToIndexNow([postUrl(...)], seo.indexNow)`; no-ops silently when
+    hazo_seo isn't installed.
+  - Double-registration guard: a module-level `WeakSet<HookBus>` makes a
+    second `registerSeoHooks` call against the SAME `hooks` instance a
+    no-op, so `createPostService` being constructed more than once against
+    one shared `config.hooks` bus can't double-fire either handler.
+    Re-exported from `src/index.ts`.
+- **`package.json`** — `hazo_seo: "^0.19.0"` added to `peerDependencies` +
+  `peerDependenciesMeta` (`optional: true`), mirroring `hazo_auth`'s exact
+  treatment. NOT added to `devDependencies` — `hazo_auth`/`hazo_images`/
+  `hazo_jobs`/`hazo_theme`/`hazo_i18n`/`hazo_llm_api` (the package's other
+  optional peers) aren't there either, so hazo_seo follows the same
+  established pattern.
+- **Tests** (4 new files) — `seo-hooks.test.ts` (real SQLite: auto-301 fires
+  exactly when published + slug changed + `redirectsService` configured;
+  does not fire for a draft slug change, an unchanged slug, create, or a
+  missing `redirectsService`; a `createRedirect` rejection simulating
+  hazo_seo's `from_path` collision doesn't throw out of `updatePost`;
+  IndexNow submission on publish with the right single URL; double-
+  registration guard); `seo-hooks.indexnow-unresolvable.test.ts` (hazo_seo
+  unresolvable — mocks `hazo_seo/files`'s import to reject outright — the
+  `after:publish` handler no-ops instead of throwing out of `setStatus(...,
+  'published')`); `hazo-seo-sitemap-source.test.ts` (entry shape, truthful
+  lastmod vs. fallback, image inclusion, draft/unpublished exclusion,
+  `postType` filtering, the `opts.req`/`ScopeUnresolvedError` interaction for
+  both multi-site and add-on-mode hosts); plus 3 new cases in
+  `posts.service.hooks.test.ts` for `previousSlug` (null on create, carries
+  the old slug on update, equals the current slug when unchanged).
+
+## 2.5.0 — 2026-11-06
+
+⚠️ DDL required — new `hazo_blog_media`/`hazo_blog_media_usage` tables.
+
+End-to-end media pipeline data layer (Phase 1a issue 10): upload → process
+(variants/blurhash/hash via hazo_images) → store (host-supplied
+`hazo_files`-shaped storage provider) → dedup by content hash → persist →
+track where each media item is used. This is NEW v2 infrastructure for the
+`Post`/content model (tickets 04/06–09) — completely separate from, and
+does NOT touch, the legacy v1.6 `BlogMediaConfig`/`createBlogImageUploadRoute`
+single-image-upload path (`src/next/image-upload.ts`), which stays wired to
+`BlogConfig.media`.
+
+- **DDL** — `hazo_blog_media` (one row per distinct uploaded file per
+  tenant: filename/mime_type/size_bytes/width/height/hash/blurhash/
+  dominant_colour/focal_point/alt/caption/tags/ai_data/variants/storage_key)
+  and `hazo_blog_media_usage` (surrogate `id` PK — same "CrudService only
+  deletes by a single PK" reasoning as `hazo_blog_post_tags`/
+  `hazo_blog_post_bylines` — tracking `(media_id, entity_type, entity_id,
+  field, scope_id)`). `idx_hazo_blog_media_scope_hash` is a UNIQUE index on
+  `(scope_id, hash)` — dedup is per-tenant, never global: the same bytes
+  uploaded to two different sites get two separate rows. Both dialects +
+  `migrations/` mirror updated.
+- **`src/repository/media.ts`** (new) — `createMediaRepository(adapter, scope)`:
+  plain CRUD (`listMedia` with in-app filtering for search/source/date/
+  orientation/used-unused — this package's QueryBuilder has no portable
+  JSON/substring-OR/date-range operators rich enough, same convention as
+  `listPosts`/`searchPosts`), `getMediaByHash` (the dedup lookup),
+  `insertMedia`, `updateMedia`, `removeMedia` (explicit usage-row cleanup
+  rather than relying on the DDL's `ON DELETE CASCADE` — confirmed
+  empirically that `hazo_connect`'s `CrudService.deleteById` does not
+  reliably trigger it, same reasoning as `../repository/index.ts`'s
+  `deletePost` cleaning up `hazo_blog_post_tags` itself), `listUsageForMedia`,
+  `setUsage` (idempotent per `(entity_type, entity_id, field)`).
+- **`src/service/media.ts`** (new) — `createMediaService(config, deps?)`'s
+  `uploadMedia(buffer, filename, mimeType, req?)` orchestrates: block SVG
+  (mime `image/svg+xml` or a `.svg` filename extension) → fire
+  `media:before:upload` (vetoable — the hook bus's Phase 1a issue 09 stub,
+  now actually fired for the first time) → `processMediaVariants` (dynamic
+  `import("hazo_images/server")`, injectable via `deps.processMediaVariants`
+  for tests — a SEPARATE seam from `../next/image-upload.ts`'s
+  `deps.loadImages`, same convention, don't merge them) → dedup by
+  `(scope_id, hash)` (a hit returns the existing row UNCHANGED, skipping
+  storage entirely) → store every variant via the host-supplied
+  `BlogFileStorageProvider` → insert the `hazo_blog_media` row → fire
+  `media:after:upload` (fire-and-forget). Also: `removeMedia` (best-effort
+  storage cleanup, logged not thrown, then the DB delete),
+  `syncMediaUsageForEntity` (tolerant — catches and logs via `hazo_logs`,
+  never throws, so a usage-tracking issue can never break a content save),
+  and `toAdapter(req?)` returning a plain object literally shaped like
+  `MediaSource` (the adapter hazo_images/ui's `MediaGallery`/`MediaPicker`
+  expect, structurally — see below).
+- **New `BlogConfig.mediaStorage` field** (`src/types/index.ts`) —
+  `{ getStorageProvider: (scope) => BlogFileStorageProvider | Promise<...> }`.
+  Named `mediaStorage` rather than `media2`/`mediaV2` to read naturally at
+  call sites while staying unambiguous next to the EXISTING, UNTOUCHED
+  `media` field (`BlogMediaConfig`, the legacy v1.6 config). The host is
+  expected to hand back an `hazo_files` `S3Provider` instance (or any
+  duck-typed equivalent) already constructed with `key_prefix` set to that
+  tenant's scope id — THAT is what satisfies the acceptance criteria's
+  "storage keys prefixed by scope_id": `uploadMedia` itself never prepends
+  `scope_id` to a path, it trusts the provider instance it's handed.
+  `BlogFileStorageProvider` is a new duck-typed interface (`put`/
+  `getSignedUrl`/`delete` — the subset of `hazo_files`' `FileStorageProvider`
+  this package actually calls), same "no compile-time `hazo_files` import"
+  convention as the existing `BlogFileManager`.
+- **New `Media`/`MediaUsage`/`MediaSource` types** (`src/types/index.ts`) —
+  `MediaSource` is the adapter interface (`list`/`get`/`upload`/`update`/
+  `remove`, plus `listUsage` for the gallery's "where used" list, plus
+  `generate`/`regenerate` as genuinely-unimplemented optional Phase 3
+  stubs). `Media.variants` maps a `"{width}-{format}"` key to that variant's
+  `storage_key`; `Media.storage_key` (top-level) is the SAME value as the
+  widest-width AVIF entry — the "primary" variant representing this item at
+  a glance.
+- **`src/lib/hook-bus.ts`'s `media:before:upload`/`media:after:upload`** —
+  defined (unfired) since Phase 1a issue 09; THIS release is the one that
+  actually fires them, from `uploadMedia`. Payload shapes are unchanged.
+- **`src/service/posts.ts`** — `createPost`/`updatePost` (via the shared
+  `saveWithHooks` helper) now call a new internal `syncPostMediaUsage` after
+  every successful save, pointing `('post', post.id, 'og_image')` at
+  `post.og_image` (the only media-referencing field the v2 `Post` model has
+  today). Builds its own `MediaRepository` straight from
+  `../repository/media.js` — deliberately NOT `../service/media.js`'s
+  `createMediaService`, to avoid a circular import between the two service
+  modules — and uses `post.scope_id` directly rather than re-resolving
+  scope. Tolerant by design: every error is caught and logged via
+  `hazo_logs`, never thrown, so a usage-tracking issue can never break an
+  otherwise-successful post save. Awaited (not fire-and-forget) specifically
+  so the write isn't lost under a serverless host that returns immediately
+  after the save.
+- **`src/next-shims.d.ts`** — added a loose `processMediaVariants` ambient
+  declaration to the existing `hazo_images/server` shim (same "optional
+  peer, type-checks standalone without it installed" reasoning as the
+  shim's pre-existing `createImageProcessHandler` entry).
+- **Tests** (3 new files) — `media.repository.integration.test.ts` (real
+  SQLite: CRUD, dedup is per-scope not global, usage set/update/clear,
+  cascade-on-remove, every `listMedia` filter, cross-scope isolation);
+  `media.service.test.ts` (fake `processMediaVariants` + fake
+  `BlogFileStorageProvider`: full upload orchestration, dedup skips storage
+  entirely, SVG rejection by MIME and by extension, hook veto blocks
+  upload, `media:after:upload` fires with the right path/url, missing
+  `mediaStorage` config throws, same-hash-different-scope uploads don't
+  collide, `removeMedia`, `toAdapter`); `posts.service.media-usage.test.ts`
+  (real SQLite: usage row created/updated/cleared across
+  create/update, and a post save still succeeds even when usage-sync itself
+  errors — `hazo_logs` mocked via `jest.unstable_mockModule`, same pattern
+  as `hook-bus.test.ts`, because this last case deliberately exercises the
+  real error-logging branch).
+
+## 2.4.0 — 2026-11-06
+
+Typed hook bus for content-lifecycle events (Phase 1a issue 09). Purely
+additive — a new standalone module plus a new optional `BlogConfig` field,
+wired into the v2 `Post`/`hazo_blog_posts` CRUD flow
+(`src/repository/posts.ts`/`src/service/posts.ts`). Not DDL, no DB change.
+Unrelated to the legacy v1.6 `BlogConfig.onPostSaved?: (post, action) => void`
+callback (still used, untouched, by `src/service/index.ts`'s
+`createTranslation`/`translatePost`/upsert flow for the old `BlogPost` shape)
+— don't confuse the two.
+
+- **`src/lib/hook-bus.ts`** (new) — `createHookBus()` factory (matching this
+  package's `createPostRepository`/`createPostService` factory-function
+  convention) returning a `HookBus`: `on<K>(event, handler)` (TypeScript
+  generic infers the handler's payload type from the event name `K`, via the
+  new `BlogHookEventMap` covering all 10 events from the acceptance
+  criteria — `before:save`/`after:save`, `before:publish`/`after:publish`,
+  `before:delete`/`after:delete`, plus four forward-looking stubs, see
+  below), returning an unsubscribe function; `emitBefore<K>` (runs EVERY
+  registered `before:`-ish handler sequentially to completion — never
+  short-circuits on the first veto, per the literal acceptance-criteria text
+  — and reports `{ vetoed: true, reason }` using the first vetoing handler's
+  reason if any vetoed); `emitAfter<K>` (runs every handler, each one
+  individually try/caught so one throwing/rejecting handler never stops the
+  next, and never itself rejects — any caught error is logged via
+  `hazo_logs` instead of thrown). A `before:`/`after:` handler's `HookResult`
+  is `void | { veto: true; reason: string }`.
+  - **`media:before:upload`/`media:after:upload`** (ticket 10 — no upload
+    implementation exists yet), **`cron`** (likely ticket 16), and
+    **`page:metadata`** (likely ticket 11's SEO work) are defined as
+    emittable payload types in `BlogHookEventMap` now, per the acceptance
+    criteria, but nothing fires them yet — stubs for those future tickets to
+    wire up.
+  - `hazo_logs`' real `createLogger()` is constructed LAZILY, on the first
+    actual after-handler error, not at module-load time — its background
+    "upgrade to the real winston logger" dynamic import is otherwise a
+    dangling async operation that can crash an unrelated Jest test file
+    under `--experimental-vm-modules` (a real issue hit while writing this
+    ticket's tests, not a hypothetical).
+- **`src/types/index.ts`** — new optional `BlogConfig.hooks?: HookBus`
+  field. Deliberately NOT a package-level singleton: omitted, `createPostService`
+  builds a fresh PRIVATE `createHookBus()` internally (nothing outside that
+  closure can reach it, so there's nothing to share). A host that actually
+  wants to register handlers must build its own bus with this package's
+  exported `createHookBus()` and pass the SAME instance into every
+  `createPostService(config)` call it should be shared across — see the
+  field's own doc-comment for the full reasoning (mirrors `getHazoConnect`'s
+  "host builds it, package consumes it" shape, not `resolveScope`'s
+  "package calls a host function per request" shape, since registered
+  handlers need to persist across requests).
+- **`src/service/posts.ts`** — `createPost`/`updatePost` now fire
+  `before:save`/`after:save`; `publishDraft` and `setStatus(..., 'published')`
+  fire `before:publish`/`after:publish`; `trashPost`, the void-returning
+  `deletePost` back-compat alias, and `setStatus(..., 'trashed')` all fire
+  `before:delete`/`after:delete` (routed through one shared internal helper
+  so the hooks can't drift between the three call sites). A veto from any
+  `before:` handler throws the new `HookVetoError` (`{ event, reason }`),
+  aborting the operation before the repository call runs — surfaced
+  verbatim to the caller. `after:` hooks are fired but NOT awaited by these
+  methods (fire-and-forget, per `HookBus.emitAfter`'s contract) — the
+  methods still return as soon as the underlying write commits.
+  Deliberately NOT wired into the cross-tenant `purgeTrashedPosts()`
+  maintenance job (`src/repository/posts.ts`) — see that function's own
+  doc-comment for why a batch hard-delete across every tenant, with no
+  `BlogConfig`/hook-bus instance to fire against, doesn't get per-post
+  `before:delete`/`after:delete` hooks.
+- **Tests** — `src/__tests__/hook-bus.test.ts` (new, 12 cases): the bus in
+  isolation — registration/unsubscribe, veto reporting, "every before:
+  handler runs even after one vetoes", async/sequential handler ordering,
+  after-handler error isolation + `hazo_logs` logging (`hazo_logs` mocked
+  via `jest.unstable_mockModule`, same ESM-mocking convention as
+  `service.translate-post.test.ts`'s `hazo_llm_api/server` mock), and a
+  compile-time proof of the event→payload generic inference (`@ts-expect-error`
+  cases — this package has no `tsd`/type-testing setup, so this stays a
+  plain `.test.ts` file per Phase 1a issue 09's own guidance).
+  `src/__tests__/posts.service.hooks.test.ts` (new, 14 cases, real-SQLite
+  integration — same harness as `posts.service.test.ts`): veto actually
+  blocking `createPost`/`updatePost`/`publishDraft`/`setStatus`/`trashPost`/
+  `deletePost` (not just the bus in isolation), multiple handlers all
+  running, `after:` firing post-commit, and the `config.hooks` host-supplied-bus
+  wiring path. 359 passing vs. 333 on the prior HEAD (net +26), the same 52
+  pre-existing failures (v1.6/v2.0.0 schema split, unrelated) unchanged, 0
+  new failures.
+- **`package.json`** — adds `hazo_logs` (`^2.3.1`) as a regular `dependency`
+  (not a peer — matches `hazo_logs`' own README: logging-only consumption
+  needs no peer deps, only its optional log-viewer UI does, and this
+  package's own peers already cover `react`/`next` for anyone who'd also
+  want that UI).
+
+## 2.3.0 — 2026-11-06
+
+**⚠️ DDL required — bylines (Phase 1a issue 08).** Adds two new tables (both
+dialects + `migrations/`): `hazo_blog_bylines` and `hazo_blog_post_bylines`.
+Purely additive — no existing table is touched, so there's nothing to
+backfill; hosts just re-apply `db_setup_sqlite.sql`/`db_setup_postgres.sql`.
+
+Author attribution independent of `hazo_auth` login accounts: a byline is a
+named author (real user, guest, or imported WordPress author) that can be
+assigned to one or more posts, ordered for display. Entirely new — doesn't
+touch `src/repository/posts.ts`/`src/service/posts.ts` or any status/revision
+machinery from tickets 04/06/07, and is unrelated to the legacy v1.6
+`author_id`/`AuthorInfo` fields on the untouched `BlogPost` shape.
+
+- **`db_setup_sqlite.sql` / `db_setup_postgres.sql`** — `hazo_blog_bylines`
+  (`id`, `scope_id` NOT NULL, `name`, `slug`, `bio`, `avatar_url`, `user_id`,
+  `created_at`, `updated_at`), unique index on `(scope_id, slug)` mirroring
+  `hazo_blog_posts`' own `(scope_id, slug, locale)` pattern. `user_id` is a
+  loose, nullable `TEXT` column — deliberately NOT a DB `REFERENCES` into a
+  `hazo_auth` users table, since `hazo_auth` is an OPTIONAL peer this
+  package's own migrations don't own; validated at the application layer
+  only if/when `hazo_auth` is present.
+  `hazo_blog_post_bylines` (post↔byline join: `id`, `post_id`, `byline_id`,
+  `position`) has a **surrogate `id` PK**, not a composite
+  `(post_id, byline_id)` key — same reasoning as `hazo_blog_post_tags`:
+  `hazo_connect`'s `CrudService` only deletes by a single PK. Unique index
+  on `(post_id, byline_id)` prevents duplicate assignment; an index on
+  `byline_id` and on `(post_id, position)` back the two list queries below.
+- **`src/types/index.ts`** — `Byline`, `PostByline` (a `Byline` resolved with
+  the junction row's own id + `position`), `CreateBylineInput`,
+  `UpdateBylineInput`.
+- **`src/repository/bylines.ts`** (new) — `createBylineRepository(adapter, scope)`,
+  a sibling of `createPostRepository`: scoped CRUD for bylines
+  (`createByline`/`updateByline`/`getBylineById`/`listBylines`/`deleteByline`),
+  plus `assignBylineToPost`/`removeBylineFromPost`/`reorderPostBylines`/
+  `listBylinesForPost`/`listPostsByByline` (paginated, same shape as
+  `PostRepository.listPosts`). `assignBylineToPost`/`removeBylineFromPost`/
+  `reorderPostBylines` all resolve the post within this repository's own
+  scope first — the junction table itself carries no `scope_id`, so tenant
+  isolation on assignment is enforced here, not by a DB constraint. New
+  error classes `BylineNotFoundError` / `PostNotFoundForBylineError` (the
+  latter deliberately distinct from `../repository/posts.ts`'s own
+  `PostNotFoundError`, duplicated rather than imported so this module stays
+  independently testable — see its doc-comment).
+- **`src/service/bylines.ts`** (new) — `createBylineService(config)`, a thin
+  `req`-scoped wrapper matching `PostService`'s shape exactly. Deliberately
+  **reuses** `resolvePostScope` from `../service/posts.ts` rather than
+  duplicating it — bylines share posts' exact scope-resolution rules
+  (add-on-mode default to `hazo_auth`'s system scope, `ScopeUnresolvedError`
+  on an unresolved multi-site request).
+- **`src/next/byline-routes.ts`** (new) — six route factories following
+  `../next/post-routes.ts`'s shape (`blog:read`/`blog:write` `hazo_api`
+  scopes, `ok()`/`fail()` envelopes): `createBylineManageRoutes` (list/create),
+  `createBylineItemRoutes` (get/update/delete), `createBylinePostsRoutes`
+  (list posts by byline), `createPostBylinesRoutes` (list a post's bylines /
+  assign), `createPostBylineItemRoutes` (remove one assignment),
+  `createPostBylinesReorderRoutes` (set display order) — the last two
+  mounted on their own sub-resources, same reasoning as
+  `createPostCompareRoutes`/`createPostStatusRoutes` in `post-routes.ts`.
+- **Tests**: `src/__tests__/bylines.repository.integration.test.ts` (28
+  cases — CRUD, assignment + ordering including re-assign-updates-position
+  and ignore-unassigned-ids-on-reorder, `listPostsByByline`, and tenant
+  isolation across every mutating method including the "byline from scope A
+  can't be assigned to a post in scope B" case) and
+  `src/__tests__/routes.bylines.test.ts` (6 cases covering the full route
+  surface end to end). 52 pre-existing failures (v1.6/v2.0.0 schema split,
+  unrelated to this change) are unchanged; 333 passing vs. 299 on the prior
+  HEAD (net +34), 0 new failures.
+
+Bumps 2.2.0 -> 2.3.0 (minor, new required DDL).
+
+## 2.2.0 — 2026-11-06
+
+**⚠️ DDL required — status lifecycle + trash (Phase 1a issue 07).** Adds a
+`status` column to `hazo_blog_posts` (both dialects + `migrations/`):
+`TEXT NOT NULL DEFAULT 'draft'`, backfilling every pre-2.2.0 row to
+`'draft'` so nothing breaks on upgrade. Postgres hosts also need the
+idempotent `ALTER TABLE ... ADD COLUMN IF NOT EXISTS` statement
+(db_setup_postgres.sql) applied to existing databases; SQLite hosts just
+re-run `db_setup_sqlite.sql` (fresh `CREATE TABLE IF NOT EXISTS`, same as
+every other column added to this table so far).
+
+The full v2 content lifecycle: six statuses (`draft`/`in_review`/`queued`/
+`scheduled`/`published`/`trashed`) forming a pipeline with optional steps,
+validated transitions, soft-delete trash with restore and a 30-day
+auto-purge, and a `publish_at`-driven auto-publish worker — all wired
+through `hazo_jobs`' `MaintenanceJob` primitive (its first usage in this
+package).
+
+- **`src/types/index.ts`** — new `ContentStatus` type (6-value union),
+  deliberately NOT the legacy `PostStatus` (3 values, backs the untouched
+  v1.6 `BlogPost`/`status`) — a new type name avoids any confusion between
+  the two coexisting shapes. `Post.status: ContentStatus`, defaulting to
+  `'draft'`. `ListPostsQuery.status` filter added alongside the existing
+  `type` filter.
+- **`src/lib/status.ts`** (new) — `isValidStatusTransition(from, to)`: a
+  pure, DB-free state machine enforcing the pipeline (draft → in_review →
+  queued → scheduled → published, review and queue both skippable, draft →
+  published valid), any-status → trashed, and trashed → draft (restore,
+  the ONLY legal exit from trashed — never a direct restore to published).
+  `CONTENT_STATUSES` is the ordered list of all six values. Re-exported
+  from `./lib`; also the one new import `./ui/content-status-badge.tsx`
+  needed (see below), since `../lib/*` is within the `./ui` export
+  boundary's allowed-import list.
+- **`src/repository/posts.ts`**:
+  - `setStatus(id, to)` — validates the transition, throws the new
+    `PostInvalidStatusTransitionError` on an invalid edge. Transitioning TO
+    `'published'` also promotes a staged draft to live in the same update
+    (same `draft_revision_id → live_revision_id` + `_rev` bump +
+    first-publish-only `published_at` stamp `publishDraft` does — issue 06's
+    `publishDraft` and this issue's status machine are related but
+    distinct: `publishDraft` promotes a staged revision and never touches
+    `status`; `setStatus(..., 'published')` governs the lifecycle stage
+    and, as a documented side effect, performs the same promotion IF
+    something's staged — but, unlike calling `publishDraft` directly, never
+    throws `PostNoDraftRevisionError` when nothing is). Transitioning TO
+    `'trashed'` stamps `deleted_at`; `'trashed' -> 'draft'` clears it.
+  - `trashPost(id)` / `restorePost(id)` — thin `setStatus` wrappers.
+    `trashPost` **supersedes** `softDeletePost`: `softDeletePost` is kept
+    only as a void-returning back-compat alias that now delegates to
+    `trashPost`, so every existing caller also gets a correct `status`
+    (previously it stamped `deleted_at` only, with no `status` column to
+    set).
+  - `findDueScheduledPosts(adapter)` / `purgeTrashedPosts(adapter, days?)`
+    (new, module-level exports, NOT part of `PostRepository`) — cross-tenant
+    maintenance queries: a scheduled-publish or trash-purge sweep runs
+    across every `scope_id` in one pass, unlike every other method on this
+    file's single-scope `PostRepository`. `purgeTrashedPosts` hard-deletes;
+    `hazo_blog_revisions` rows cascade via the existing `ON DELETE CASCADE`
+    FK, no separate cleanup needed.
+- **`src/jobs/maintenance-jobs.ts`** (new) — `hazo_jobs`' `MaintenanceJob`
+  primitive (its README's "Maintenance jobs", v0.10+) wired up for the
+  first time in this package:
+  - `createAutoPublishScheduledPostsJob` — every 5 minutes, promotes due
+    `'scheduled'` posts to `'published'` via `setStatus`, across every
+    tenant; a failure on one post is logged and skipped, not fatal to the
+    sweep.
+  - `createPurgeTrashedPostsJob` — daily at 03:00 UTC, hard-deletes
+    `'trashed'` posts older than `payload.retainDays` (default 30).
+  - `registerBlogMaintenanceJobs(config, options?, deps?)` — wires both
+    into one `hazo_jobs` worker via `register_maintenance_jobs`. Returns
+    `null` when `hazo_jobs` isn't installed (dynamic `import()`, same
+    degrade-gracefully shape as `createBlogImageUploadRoute`'s
+    `loadImages` seam) — meant to be called once from the host's own
+    long-running worker process, not a Next.js request handler.
+  - **Integration nuance surfaced by actually type-checking against
+    hazo_jobs' real `.d.ts`** (hazo_jobs happens to be resolvable in this
+    monorepo workspace, confirmed, not assumed): `createJobsClient` needs a
+    raw-SQL `{ raw(sql, values): Promise<rows[]> }` adapter — a lower-level,
+    different contract than the `hazo_connect` adapter
+    `config.getHazoConnect()` returns. `hazo_connect`'s Postgres adapter
+    happens to also expose a working `.raw()` (see `maintainSearchVector`),
+    so Postgres hosts can omit the new `options.rawAdapter` entirely;
+    `hazo_connect`'s SQLite adapter does not (only `.rawQuery`, a different
+    shape), so a SQLite/add-on-mode host must pass its own raw wrapper —
+    hazo_jobs' own README SQLite quick-start shows exactly this recipe over
+    `better-sqlite3`. hazo_jobs' `MaintenanceJob` primitive itself is fully
+    sufficient for both recurring tasks here — no bespoke scheduler needed
+    or invented.
+- **`src/ui/content-status-badge.tsx`** (new) — `ContentStatusBadge`, a
+  colour-coded pill for all six `ContentStatus` values, following
+  `post-list-table.tsx`'s legacy `StatusPill` visual/structural convention
+  (rounded-full, capitalize) but as its own standalone component (the
+  legacy one stays legacy-only). Exported from `./ui`'s barrel — no v2
+  post-list UI exists yet in this package to embed it in directly (still
+  Phase 1a issue 12/15's job on the platform side), same situation
+  `hasPendingChanges` documented in 2.1.0 below.
+- **`src/service/posts.ts`**, **`src/next/post-routes.ts`** — thin
+  req-scoped service wrappers + three new route factories
+  (`createPostStatusRoutes` `POST .../status` body `{ to }`,
+  `createPostTrashRoutes` `POST .../trash`, `createPostRestoreRoutes`
+  `POST .../restore`), same auth-guard + `ok()`/`fail()` envelope
+  convention as every other route in this file.
+  `PostInvalidStatusTransitionError` maps to a 409
+  `INVALID_STATUS_TRANSITION` envelope.
+- Tests: extends `posts.repository.integration.test.ts` (full transition
+  matrix — every valid edge and a representative set of invalid ones, any
+  non-trashed status → trashed, trashed → draft restore, tenant isolation,
+  the `setStatus(..., 'published')`-promotes-a-staged-draft interaction,
+  `findDueScheduledPosts`/`purgeTrashedPosts` cross-tenant behaviour) and
+  `posts.service.test.ts` (service wiring); new `status.test.ts` (pure
+  `isValidStatusTransition` matrix, no DB), `routes.post-status.test.ts`
+  (route-level envelope/auth coverage), `maintenance-jobs.test.ts` (both
+  jobs' handlers against a real SQLite adapter, plus
+  `registerBlogMaintenanceJobs`'s wiring via a fake `hazo_jobs/server`
+  module — see that file's header for why the REAL module is never
+  executed inside this package's jest harness, only type-checked against).
+  A cross-connection staleness gap in backdating timestamps for these tests
+  (a second `better-sqlite3` connection's committed write wasn't visible to
+  the long-lived adapter connection on its next query) surfaced while
+  writing them — fixed by backdating through `adapter.rawQuery` instead of
+  a second connection; documented in both test files' `backdate()` helpers.
+
+## 2.1.0 — 2026-11-06
+
+**Live/draft revision promotion (Phase 1a issue 06).** Additive on top of
+2.0.0's posts + pages foundation (issue 04) — no DDL change, `hazo_blog_posts`'
+`live_revision_id`/`draft_revision_id` and `hazo_blog_revisions` already
+existed; this issue was the promote/discard/compare workflow around them.
+`updatePost()`'s existing behaviour (always stage to `draft_revision_id`,
+never touch `live_revision_id`) turns out to already be correct for both the
+published and unpublished case — confirmed, not changed.
+
+- **`src/repository/posts.ts`** — three new `PostRepository` methods:
+  - `publishDraft(id)` — promotes `draft_revision_id` to `live_revision_id`,
+    clears `draft_revision_id`, bumps `_rev`, and stamps `published_at` on
+    first publish only (a republish never clobbers the original timestamp).
+    The previous live revision is never deleted — `listRevisions` still
+    returns it as history.
+  - `discardDraft(id)` — clears `draft_revision_id` only; every other column
+    (including `_rev`) is left exactly as it was. Idempotent — a no-op when
+    there's nothing staged.
+  - `compareDraftAndLive(id)` — fetches the post's live and draft revisions
+    and returns both payloads plus a field-level diff summary
+    (`PostRevisionDiffField`: title/slug/body/excerpt/seo_title/
+    seo_description/og_image/noindex/canonical_override/custom_fields).
+  - Two new typed errors: `PostNoDraftRevisionError` (nothing staged) and
+    `PostNoLiveRevisionError` (post has never been published) — same
+    constructor shape as the existing `PostNotFoundError`/`PostConflictError`.
+- **`src/service/posts.ts`** — `PostService.publishDraft`/`discardDraft`/
+  `compareDraftAndLive`, same `req`-scoped wrapper pattern as every other
+  method; re-exports the two new error classes.
+- **`src/next/post-routes.ts`** — three new route factories, each mounted on
+  its own `/api/.../posts/[id]/...` resource (same pattern as
+  `createBlogTranslateRoutes`/`createBlogReviewRoutes` in `./routes.js`):
+  `createPostCompareRoutes` (`GET`, `blog:read`), `createPostPublishRoutes`
+  (`POST`, `blog:write`), `createPostDiscardRoutes` (`POST`, `blog:write`).
+  `PostNoDraftRevisionError`/`PostNoLiveRevisionError` map to 409
+  `NO_DRAFT_REVISION`/`NO_LIVE_REVISION` fail() envelopes.
+- **`src/lib/revisions.ts`** (new) — `hasPendingChanges(post)`: a pure
+  `live_revision_id !== null && draft_revision_id !== null` predicate for an
+  admin "pending changes" badge. No v2-model post-list UI exists yet in this
+  package to host an actual badge component in (`src/ui/post-list-table.tsx`
+  and `src/components/admin/post-form.tsx` still operate on the v1.6
+  `BlogPost` shape) — wiring this into a real list view is Phase 1a issue
+  12/15's job. Re-exported from the `./lib` barrel.
+- Tests: `src/__tests__/posts.repository.integration.test.ts` (publish/
+  discard/compare happy paths + edge cases, revision history ordering,
+  published vs. unpublished edit flow, tenant isolation),
+  `src/__tests__/posts.service.test.ts` (service-layer wiring, real SQLite),
+  `src/__tests__/routes.post-revisions.test.ts` (new — route-level auth/scope
+  + envelope coverage for the three new endpoints).
+
 ## 2.0.0 — 2026-10-31
 
 **⚠️ BREAKING — new posts + pages foundation for BlogSketch (Phase 1a issue 04).**