import type { Kysely } from 'kysely';
/**
 * Content Releases: a named batch of staged content that goes live together.
 *
 * The feature this table exists for is "tuition changes across a dozen live pages, all at 9am on
 * the same day". Until now Taproot had nowhere to put that: `content_items` holds exactly one row
 * per item, so editing a published page changed what the public saw at the moment of the save.
 * There was no pending version, and therefore nothing to coordinate.
 *
 * `release_items` is that pending version. It carries its own `title`, `slug`, `data`, and `seo`
 * rather than pointing at a revision, and the distinction is load-bearing: revisions are an
 * append-only record of what the *live* item has been, so staging by reference would mean every
 * edit to a not-yet-live version wrote a line into the history of a page that never showed it.
 * A staged version is editable and belongs to the release; a revision is frozen and belongs to the
 * item.
 *
 * `parent_id` is deliberately not staged, matching what revisions capture. Re-parenting is a
 * structural change to the tree rather than a change to a page's content, and staging it would mean
 * a release could rearrange the site's hierarchy as a side effect of a copy change. A staged `slug`
 * *is* captured, because it is authored alongside the title — publishing one cascades paths and
 * writes redirects through the ordinary update path, exactly as renaming would.
 */
export declare function up(db: Kysely<any>): Promise<void>;
export declare function down(db: Kysely<any>): Promise<void>;