import type { Kysely } from 'kysely';
/**
 * Let a content type say what its list screen shows and how it is ordered.
 *
 * Every list rendered the same five columns — title, path, status, updated, created — which is a
 * reasonable default for a page and tells you nothing useful about an event or a person. What an
 * editor wants to see is the thing that distinguishes one row from the next: an event's start date,
 * a person's job title, a photograph.
 *
 * ## Three columns rather than one blob
 *
 * `list_columns` is JSON because it is genuinely a list, and the two sort columns are separate
 * because they are separate facts — one names an order from a **closed vocabulary** (`ITEM_SORTS`)
 * and the other names a field. Folding them into one JSON object would put a value validated against
 * a fixed set inside a blob nothing type-checks, which is how `sort` ends up holding a column name
 * and the delivery API ends up publishing the schema as its sort vocabulary.
 *
 * ## Nullable, and null means "as before"
 *
 * A type that configures nothing keeps the five columns and `path` ordering it already had. That
 * matters more than usual here: this migration runs against deployments whose lists people are used
 * to, and a migration that changed what every screen looked like would be a surprise nobody asked
 * for. Configuring it is opt-in per type.
 *
 * ## No backfill, and nothing to reindex
 *
 * Unlike `0019` and `0021`, this stores a *preference*, not derived data. The values a column
 * displays come from `content_items.data`, which is already there, and the ordering comes from
 * `content_item_values`, which `planDerivedIndexes` has been maintaining since `0019`. There is no
 * `db:reindex` step.
 */
export declare function up(db: Kysely<any>): Promise<void>;
export declare function down(db: Kysely<any>): Promise<void>;