import { type Kysely } from 'kysely';
/**
 * Taxonomies: content-type-agnostic term trees, attachable to any content type.
 *
 * Attachment needs no table of its own. A content type gets a taxonomy by having a `taxonomy`
 * field whose config names the taxonomy, which means the existing field system already carries
 * per-type configuration (required, single vs multiple) without a parallel mechanism for it.
 *
 * Taxonomies classify content. They deliberately carry **no authority**: a term never determines
 * who may edit an item, because "what is this about" is editable by any contributor and "who may
 * change it" must not be — tying them would mean tagging a page for discoverability silently
 * granted someone else edit rights. Roles ended up flat and site-wide, which makes that rule
 * easier to keep rather than harder. See the Roles & permissions section of SCOPE.md.
 *
 * `taxonomy_assignments` is a **derived index**, not the source of truth. The authored value lives
 * in `content_items.data` under the field's `api_id`, like every other field, so that revisions
 * snapshot tags, validation treats them uniformly, and the API contract has one shape. The
 * assignments table is rebuilt from that value inside the same atomic batch as the item write.
 *
 * The duplication buys the one thing JSON cannot: an indexed answer to "which items carry a term
 * in this branch". Without it, filtering a content list by term means scanning every row and
 * parsing its `data` blob, which is unindexable and gets worse with every item added. Storing tags
 * *only* in the join table was the alternative, and it would have made a restored revision quietly
 * lose its tags.
 */
export declare function up(db: Kysely<any>): Promise<void>;
export declare function down(db: Kysely<any>): Promise<void>;