@brickclay-org/ui 0.1.93 → 0.1.94

package/index.d.ts

@@ -4899,81 +4899,117 @@ declare const BK_TABLE: readonly [typeof BkTable, typeof BkTableTitle, typeof Bk
 /**
  * Types for bk-kanban.
  *
- * The board is content-agnostic by design (see the component's own doc
- * comment): it only ever moves opaque `T` values between columns and reports
- * what happened. Every type here describes either a column, or one of the
- * events the board reports — never anything about what a card renders as.
+ * Columns own their items — a single nested tree is the source of truth:
+ * `columns: KanbanColumn<T>[]`, each carrying its own `items: T[]`. There is
+ * no separate flat cards array anywhere; grouping, ordering, and lookup all
+ * fall out of the tree itself.
+ *
+ * Every drag, add, and remove operation emits only the column(s) actually
+ * affected — never the whole board — each with its complete, current
+ * `items` (column *reordering* is the one exception — see
+ * `BkKanbanColumnReorderPayload`). There's deliberately no
+ * `itemsMovedWithin` / `itemsMovedBetween` pair of "what changed" fields:
+ * the consumer already gets the complete, ordered `items` for every affected
+ * column, so diffing that against whatever it had before tells it exactly
+ * what moved and where without the board also maintaining a second,
+ * redundant description of the same fact.
+ */
+/**
+ * Minimum shape every item must satisfy. `label` is the one content field
+ * the board itself ever reads (for the built-in add/remove affordances'
+ * aria-labels, and as the default new-item label) — everything past the
+ * four required fields is entirely up to the consumer via the index
+ * signature (`type`, `priority`, `assignee`, `dueDate`, whatever a real card
+ * needs).
  */
-/** One column/status definition. Any number of columns — no fixed status set
- *  assumed; a workflow with two lanes and one with fifteen both just pass a
- *  `columns` array of the size they need. */
-interface BkKanbanColumn {
+interface ColumnItem {
     id: string;
     label: string;
-    /** Cap on cards in this column. Omit for no limit — see `wipLimitBehavior`. */
-    wipLimit?: number;
-    /**
-     * Extra class(es) appended to this column's header bar — the row holding
-     * the label, the count badge, and `columnHeaderActionsTemplate`, if any.
-     * Named `colHeaderClass` (not `headerClass`) so it reads unambiguously as
-     * "this column's header" once a column is nested inside `bk-kanban`. Same
-     * idea as `panelClass` on `bk-dialog`/`bk-popover`, or `headerClass` on
-     * `bk-grid`'s `TableColumn`: it only adds to the header's own classes,
-     * bk-kanban's own layout still stands, and nothing stops you passing
-     * whatever you'd pass any other element — a single class, several, a
-     * whole Tailwind utility stack.
-     *
-     * For properties the header doesn't already declare (a `border`,
-     * `box-shadow`, rounded corners) a plain class works exactly as you'd
-     * expect. For its **background** specifically, set the
-     * `--bk-kanban-header-bg` custom property instead of a `bg-*` utility —
-     * Angular injects this component's own stylesheet after the page's
-     * global one, so a same-specificity utility class can never outrank the
-     * header's own background declaration; the custom property exists
-     * precisely so `colHeaderClass` still has a reliable way to change it.
-     */
+    sortOrder: number;
+    /** The id of the column that currently owns this item. Kept in sync by
+     *  the board on every move — never write this yourself. */
+    parentId: string;
+    [key: string]: unknown;
+}
+/** One column, owning its own items — the array the board mutates in place
+ *  on every drag/add/remove, the same way the old flat `cards` array used to
+ *  be mutated (see the component's own doc comment). */
+interface KanbanColumn<T extends ColumnItem = ColumnItem> {
+    id: string;
+    label: string;
+    /** Cap on items in this column. Omit for no limit — see `wipLimitBehavior`. */
+    limit?: number;
+    sortOrder: number;
+    items: T[];
+    /** Whether this column accepts a new item — gates the built-in "+" button
+     *  (alongside the board-wide `showAddItem`) *and* `addItem()`/the
+     *  `addItem` template context function itself, so a column marked
+     *  `allowAdd: false` can't be added to through any path, built-in or
+     *  custom. Omit (or `true`) to allow — see §14. */
+    allowAdd?: boolean;
+    /** Whether an item can be removed from this column — same gating as
+     *  `allowAdd`, covering the built-in remove button, `removeItem()`, and
+     *  `BkKanbanCardContext.removeItem`. Omit (or `true`) to allow. */
+    allowRemove?: boolean;
+    /** Per-column override of the board-wide `emptyMessage`, shown while
+     *  `items` is empty. Ignored once `emptyStateTemplate` is supplied — a
+     *  template is a bigger override than swapping in different words. */
+    emptyMessage?: string;
+    /** Extra class(es) appended to this column's header bar. Same idea as
+     *  `panelClass` on `bk-dialog`/`bk-popover` — it only adds to the header's
+     *  own classes, and reliably wins over the header's own default styling
+     *  for any property, background included (the component's base rules are
+     *  written with `:where(...)` in kanban.css specifically so a plain
+     *  utility class here always outranks them, regardless of stylesheet load
+     *  order). `--bk-kanban-header-bg` is also there as an alternative way to
+     *  set just the background, e.g. from an inline style. */
     colHeaderClass?: string;
-    /**
-     * Extra class(es) appended to this column's own wrapper — the element
-     * `wipLimit` feedback (`bk-kanban-column-warn`/`bk-kanban-column-live-over`)
-     * already lands on, and the ancestor `colHeaderClass` reaches the header
-     * through. Same idea as `colHeaderClass` one level up: it only adds to the
-     * wrapper's own classes, nothing here replaces bk-kanban's own layout.
-     *
-     * Same background caveat as `colHeaderClass` too — set the
-     * `--bk-kanban-column-bg` custom property rather than a `bg-*` utility to
-     * change the wrapper's background reliably; see `colHeaderClass`'s doc
-     * comment for why.
-     */
+    /** Extra class(es) appended to this column's own wrapper. Same reasoning
+     *  as `colHeaderClass` — reliably wins for any property; `--bk-kanban-column-bg`
+     *  is the equivalent background alternative here. */
     columnClass?: string;
-    /**
-     * Placeholder text shown in this column's body when it holds no cards,
-     * overriding the board-wide `noDataText` input for this column alone.
-     * Ignored once `emptyStateTemplate` is supplied — a template is a bigger
-     * override than swapping in different words, so it wins outright rather
-     * than being handed a piece of text it may not even render.
-     */
-    noDataText?: string;
+    /** Cross-column move, source side: the id of the item that just left. */
+    sentChildId?: string;
+    /** Cross-column move, destination side: the id of the item that just arrived. */
+    receivedChildId?: string;
+    /** A just-added item's id. */
+    newAddedItemId?: string;
+    /** Set alongside `newAddedItemId`, always `true` — never present on a
+     *  column for any other kind of change. Exists so a consumer can branch on
+     *  "did creation succeed" without having to check `newAddedItemId` for
+     *  both existence *and* the right meaning; see §10/§11. */
+    newItemCreated?: boolean;
+    /** A just-removed item's id. */
+    removedItemId?: string;
 }
 /**
- * How far a drag is allowed to travel.
+ * How far a card drag is allowed to travel — the single control for both
+ * "is dragging on at all" and "how far", so there's nothing to keep in sync
+ * between two separate inputs.
  *
- * `'same'` only reorders within a column (manual prioritization on a board
- * whose statuses shouldn't change from a drag). `'cross'` only moves cards
- * between columns, with no in-column reordering. `'both'` (the default)
- * allows either.
+ * `'within'` only reorders inside a column (manual prioritization on
+ * a board whose statuses shouldn't change from a drag). `'between'`
+ * only moves items across columns, with no in-column reordering. `'both'`
+ * (the default) allows either. `'none'` turns card dragging off entirely —
+ * every card's own `cdkDrag` and every column body's own `cdkDropList` are
+ * disabled, the same as the old `dragEnabled: false` used to do. Unrelated
+ * to `dragColumn`, which is its own separate switch for dragging
+ * *columns* themselves.
  */
-type BkKanbanDragScope = 'same' | 'cross' | 'both';
+type BkKanbanMovementRestriction = 'within' | 'between' | 'both' | 'none';
 /**
- * What happens when a drop would push a column's card count past its
- * `wipLimit`.
+ * What happens when a drop or an add would push a column's item count past
+ * its `limit`.
  *
- * `'block'` rejects the drop — nothing is mutated, so the card returns to
- * its origin the same way any cancelled CDK drag does. `'warn'` lets the
- * drop through but flags the column. `'none'` ignores limits at drop time
- * entirely (they still show in the header, purely as information).
- * `columnLimitExceeded` fires whenever a drop *would* exceed the limit,
- * regardless of which of the three is active.
+ * `'block'` rejects the operation — nothing is mutated (a drop returns the
+ * item to its origin the same way any cancelled CDK drag does; an add via
+ * `addItem` simply does nothing). `'warn'` lets it through but flags the
+ * column. `'none'` ignores limits at drop/add time entirely (still shown in
+ * the header, purely as information). `columnLimitExceeded` fires whenever
+ * an operation *would* exceed the limit, regardless of which of the three is
+ * active. Only ever applies to adding or a cross-column move — reordering
+ * within a column never changes that column's count, so it's never checked
+ * against the limit.
  */
 type BkKanbanWipLimitBehavior = 'block' | 'warn' | 'none';
 /**
@@ -4981,289 +5017,471 @@ type BkKanbanWipLimitBehavior = 'block' | 'warn' | 'none';
  *
  * `'live'` (default) highlights the hovered column the moment it would go
  * over, while the drag is still in progress. `'on-drop'` says nothing until
- * release, when `wipLimitBehavior` takes over. See the component doc for why
- * `'live'` is the recommended default.
+ * release, when `wipLimitBehavior` takes over.
  */
 type BkKanbanDragPreviewMode = 'live' | 'on-drop';
 /**
  * Where *vertical* scrolling lives once content outgrows the board's given
- * height (see the doc comment on `.bk-kanban` in `kanban.css` for how that
- * height is resolved from the host in the first place). Horizontal
- * scrolling — across columns — always lives on the board itself
- * (`.bk-kanban`'s own `overflow-x: auto`) regardless of this setting; only
- * the vertical axis moves.
+ * height. Horizontal scrolling — across columns — always lives on the board
+ * itself regardless of this setting; only the vertical axis moves.
  *
- * `'body'` (default): each column is stretched to the board's height and
- * scrolls *independently* — its own header stays fixed, only
- * `.bk-kanban-column-body` (the card list beneath it) scrolls, so a long
- * column never pushes its own header out of view, and every column can be
- * at a different scroll position at once.
+ * `'column'` (default): each column is stretched to the board's height and
+ * scrolls *independently* — its own header stays fixed, only the card list
+ * beneath it scrolls, so a long column never pushes its own header out of
+ * view, and every column can be at a different scroll position at once.
  *
- * `'wrapper'`: the board itself — `.bk-kanban`, the element containing every
- * column — is what scrolls vertically, all columns together as a single
- * region (headers included). Columns fall back to their own natural height
- * here rather than being stretched, since nothing needs bounding
- * individually any more once the board is the one doing the scrolling.
+ * `'wrapper'`: the board itself — the element containing every column — is
+ * what scrolls vertically, all columns together as a single region (headers
+ * included). Columns fall back to their own natural height here rather than
+ * being stretched, since nothing needs bounding individually any more once
+ * the board is the one doing the scrolling.
  */
-type BkKanbanColumnScrollMode = 'body' | 'wrapper';
-/** Emitted once a drag-and-drop completes — a same-column reorder or a
- *  cross-column move. `fromColumnId === toColumnId` for the former. */
-interface BkKanbanCardMovedEvent<T = any> {
-    card: T;
-    fromColumnId: string;
-    toColumnId: string;
-    newIndex: number;
+type BkKanbanColumnScrollMode = 'column' | 'wrapper';
+/**
+ * How much a column-reorder `columnsChanged` emission carries, per column —
+ * see `BkKanbanColumnSummary`. Only ever affects a *column* reorder; every
+ * other operation (item reorder, cross-column move, add, remove) always
+ * emits complete `KanbanColumn<T>` entries regardless of this setting.
+ *
+ * `'summary'` (lighter): just `{ id, sortOrder }` for every column in the
+ * board, in its resulting order — enough for a consumer that only persists
+ * column ordering and doesn't need each column's `items` echoed back.
+ *
+ * `'complete'` (default): the full `KanbanColumn<T>` for every column,
+ * `items` included — the same shape every other operation already emits.
+ */
+type BkKanbanColumnReorderPayload = 'summary' | 'complete';
+/** The lightweight per-column entry a `'summary'`-mode column reorder emits
+ *  — see `BkKanbanColumnReorderPayload`. */
+interface BkKanbanColumnSummary {
+    id: string;
+    sortOrder: number;
 }
-/** Emitted once a column reorder completes — see `columnDragEnabled`. Unlike
- *  `cardMoved`, there's only one axis to report: columns don't nest inside
- *  one another, so a move is always "this column, from this index, to this
- *  one" rather than needing a from/to pair of containers. */
-interface BkKanbanColumnMovedEvent {
+/**
+ * Emitted after any operation that changes the board — a column reorder, an
+ * item reorder within a column, a cross-column move, an add, or a remove.
+ * Carries only the column(s) actually affected, each reflecting state
+ * *after* the operation succeeded.
+ *
+ * Which change-metadata field is set on a given entry tells you which
+ * operation just happened:
+ *
+ * - a `BkKanbanColumnSummary` entry (just `id` + `sortOrder`, no `items`) →
+ *   a column reorder with `columnReorderPayload: 'summary'`; every column in
+ *   the board is present, not just the ones that moved.
+ * - a complete `KanbanColumn<T>` with no change-metadata field set → a
+ *   column reorder with `columnReorderPayload: 'complete'` (the default);
+ *   again every column in the board is present.
+ * - `newAddedItemId` + `newItemCreated: true` set → an item was added to
+ *   this column (one entry).
+ * - `removedItemId` set → an item was removed from this column (one entry).
+ * - `sentChildId` **or** `receivedChildId` set → a cross-column move
+ *   (`columns` has exactly two entries, source and destination).
+ * - none of the above, one entry → an item was reordered inside that column;
+ *   compare its `items` against what you had before to see what moved.
+ */
+interface BkKanbanColumnsChangedEvent<T extends ColumnItem = ColumnItem> {
+    columns: Array<KanbanColumn<T> | BkKanbanColumnSummary>;
+}
+/** Emitted when a drop or an add would put a column over its `limit` — see
+ *  `BkKanbanWipLimitBehavior` for when the operation itself still succeeds. */
+interface BkKanbanColumnLimitExceededEvent {
     columnId: string;
-    fromIndex: number;
-    toIndex: number;
+    limit: number;
+    attemptedCount: number;
 }
 /**
- * Emitted when a card (or a region inside it) is clicked.
+ * Emitted when an item (or a region inside it) is clicked.
  *
- * `target` is `'card'` for a click anywhere on the card that isn't a more
+ * `target` is `'card'` for a click anywhere on the item that isn't a more
  * specific region, or whatever name was given to a
  * `[bkKanbanClickTarget]="'…'"` element the click landed inside.
  */
-interface BkKanbanCardClickedEvent<T = any> {
-    card: T;
+interface BkKanbanItemClickedEvent<T extends ColumnItem = ColumnItem> {
+    item: T;
     target: string;
 }
-/** Emitted when a drop would put a column over its `wipLimit` — see
- *  `BkKanbanWipLimitBehavior` for when the drop itself still succeeds. */
-interface BkKanbanColumnLimitExceededEvent {
-    columnId: string;
-    wipLimit: number;
-    attemptedCount: number;
-}
 /** Reserved: see `columnActionTriggered` on `BkKanban` and
  *  `BkKanbanColumnActionsContext.trigger`. */
 interface BkKanbanColumnActionTriggeredEvent {
     columnId: string;
 }
+/** What a consumer hands back to `BkKanbanItemMoveBetweenColumnsEvent.resolve`
+ *  — see that event's doc comment and §5-§9/§23 of the spec this shipped
+ *  against. */
+interface BkKanbanItemMoveValidationResult {
+    success: boolean;
+}
+/**
+ * Emitted for a cross-column drag, after the user releases the item but
+ * **before** any board state is touched — only when
+ * `validateMove` is on. (Off, the default, a cross-column
+ * drop commits immediately, same as a same-column reorder, and this event
+ * never fires at all.) Once opted in, the board waits for `resolve` to be
+ * called before it does anything else. Call it with `{ success: true }` to
+ * let the move proceed (source loses the item, destination gains it,
+ * `columnsChanged` fires with the final state) or `{ success: false }` to
+ * reject it outright (nothing is mutated; since nothing was ever mutated in
+ * the first place, the item is already exactly where it started — see the
+ * component doc for why that's automatic rather than something this event
+ * has to arrange itself). `resolve` can be called synchronously, right
+ * inside your handler, or later — after an `await`, a server round-trip,
+ * whatever the validation needs — the board simply waits either way.
+ *
+ * Only fires for an actual cross-column attempt (`sourceColumn.id !==
+ * destinationColumn.id`); a same-column reorder never touches this event
+ * regardless of `validateMove`. Once that input is on,
+ * binding this event and calling `resolve` becomes mandatory — leave it
+ * unbound and `resolve` is never called, so the move never completes.
+ *
+ * `sourceColumn`/`destinationColumn` are snapshots of each column exactly as
+ * it stood the instant before this fired — still carrying the moved item in
+ * `sourceColumn.items`, not yet in `destinationColumn.items`.
+ */
+interface BkKanbanItemMoveBetweenColumnsEvent<T extends ColumnItem = ColumnItem> {
+    /** The item being moved, as it stood in its source column pre-move. */
+    item: T;
+    sourceColumn: KanbanColumn<T>;
+    destinationColumn: KanbanColumn<T>;
+    /** Whichever item the moved one would land next to in the destination —
+     *  `null` when dropping into an empty column, or at a position with no
+     *  neighbor either side (shouldn't happen past an empty column, but kept
+     *  nullable rather than asserted). */
+    targetItem: T | null;
+    /** Index within `destinationColumn.items` the item would be inserted at. */
+    targetIndex: number;
+    resolve: (result: BkKanbanItemMoveValidationResult) => void;
+}
 /**
  * Template context for `columnHeaderActionsTemplate`.
  *
- * `$implicit` and `column` are the same value — both are provided so the
- * template can use either `let-column` or the more explicit
- * `let-column="column"`. `trigger()` is there purely for
- * `columnActionTriggered`; most consumers bind their own click handler on
- * their own template instead and never call it.
+ * `$implicit` and `column` are the same value. `addItem` is how a custom
+ * header template wires its own "add" button up to the board's own add
+ * logic (id generation, `sortOrder`/`parentId`, the WIP-limit check, and the
+ * `columnsChanged`/`columnLimitExceeded` emissions) without reimplementing
+ * any of it — call it with at least a `label`; an `id` you supply is used
+ * as-is, otherwise one is generated. It's also exactly what the board's own
+ * built-in "+" button (shown whenever `showAddItem` is true, no
+ * `columnHeaderActionsTemplate` content replaces it, and the column's own
+ * `allowAdd` isn't `false`) calls under the hood. `trigger()` is reserved
+ * for `columnActionTriggered`; most consumers bind their own click handler
+ * instead and never call it.
  */
-interface BkKanbanColumnActionsContext {
-    $implicit: BkKanbanColumn;
-    column: BkKanbanColumn;
+interface BkKanbanColumnActionsContext<T extends ColumnItem = ColumnItem> {
+    $implicit: KanbanColumn<T>;
+    column: KanbanColumn<T>;
+    addItem: (item: {
+        id?: string;
+        label: string;
+        [key: string]: unknown;
+    }) => void;
     trigger: () => void;
 }
 /** Template context for `emptyStateTemplate`. */
-interface BkKanbanEmptyStateContext {
-    $implicit: BkKanbanColumn;
-    column: BkKanbanColumn;
+interface BkKanbanEmptyStateContext<T extends ColumnItem = ColumnItem> {
+    $implicit: KanbanColumn<T>;
+    column: KanbanColumn<T>;
 }
-/** Template context for `cardTemplate`. */
-interface BkKanbanCardContext<T = any> {
+/**
+ * Template context for `cardTemplate`.
+ *
+ * `removeItem()` is how a fully custom card body wires its own remove
+ * affordance up to the board's own remove logic, the same way
+ * `BkKanbanColumnActionsContext.addItem` does for adding — it's what the
+ * board's own built-in remove button (shown whenever `showRemoveItem` is
+ * true and the column's own `allowRemove` isn't `false`) calls under the
+ * hood. Unlike the built-in button's *visibility*, calling this function is
+ * never gated by `showRemoveItem` — that input only controls whether the
+ * board renders its own button, so a fully custom card body can wire this up
+ * on its own even with the built-in button off (it's still gated by the
+ * column's own `allowRemove`, same as the built-in button, and must handle
+ * its own click/drag isolation when it does — see the component's own
+ * remove button markup in `kanban.html` for the pattern to copy).
+ */
+interface BkKanbanCardContext<T extends ColumnItem = ColumnItem> {
     $implicit: T;
     card: T;
-    column: BkKanbanColumn;
+    column: KanbanColumn<T>;
     index: number;
+    removeItem: () => void;
 }
 
 /**
- * Content-agnostic kanban board: column layout, card positioning and
- * drag-and-drop, and nothing about what a card contains or what a click on
- * one should do.
+ * Kanban board: column layout, item positioning and drag-and-drop, add and
+ * remove, and nothing about what an item's *body* renders as beyond the
+ * fixed `id` / `label` / `sortOrder` / `parentId` every `ColumnItem` carries.
  *
- * The board never renders a card's insides itself — `cardTemplate` does that,
- * receiving the card and its column as context:
+ * Columns own their items — a single nested tree is the source of truth:
  *
  *   <bk-kanban
- *     [columns]="columns"
- *     [cards]="cards()"
+ *     [columns]="columns()"
  *     [cardTemplate]="card"
- *     (cardMoved)="onCardMoved($event)"
- *     (cardClicked)="onCardClicked($event)"
+ *     [showAddItem]="true"
+ *     [showRemoveItem]="true"
+ *     (columnsChanged)="onColumnsChanged($event)"
+ *     (itemClicked)="onItemClicked($event)"
  *   ></bk-kanban>
  *
  *   <ng-template #card let-card let-column="column">
  *     <div [bkKanbanClickTarget]="'hours'">{{ card.hours }}h</div>
- *     {{ card.title }}
+ *     {{ card.label }}
  *   </ng-template>
  *
- * That is deliberate, not an oversight — see the package spec's Design
- * Principles. Three consequences fall out of it directly:
+ * Three consequences fall out of that directly:
  *
- * - **Data ownership stays with the caller.** A move is reported through
- *   `cardMoved`, not applied to some copy of `cards` this component keeps to
- *   itself. Internally it *does* mutate the card objects it was handed
- *   (`columnIdField`'s field, and an `order` field used to remember position
- *   within a column) so the board redraws in the right place immediately,
- *   exactly the way `bk-grid`'s own row-drag mutates `result` in place and
- *   renumbers `sortOrder` — but persistence, and reverting the view if a
- *   save fails, are the host's job. Reverting is just handing back a
- *   `cards` array (or updated objects) that reflect the pre-move state; nothing
+ * - **Data ownership stays with the caller.** Every operation is reported
+ *   through `columnsChanged` (only the column(s) actually affected, each
+ *   with its complete current `items` — column reordering aside, see
+ *   `columnReorderPayload`), not applied to some copy of `columns` this
+ *   component keeps to itself. Internally it *does* mutate the column/item
+ *   objects it was handed (`items`, `sortOrder`, `parentId`) so the board
+ *   redraws in the right place immediately — but persistence, and reverting
+ *   the view if a save fails, are the host's job. Reverting is just handing
+ *   back a `columns` array that reflects the pre-operation state; nothing
  *   further to undo on this end.
- * - **Clicks are reported, never acted on.** `cardClicked` says which card and
- *   which named region (see `[bkKanbanClickTarget]`); opening a popup or
+ * - **A cross-column move commits immediately by default** — same as a
+ *   same-column reorder, nothing to bind. Turn on
+ *   `validateMove` and that flips: dragging an item onto a
+ *   different column then doesn't touch `columns()` at all until the
+ *   consumer answers `itemMoveBetweenColumns` — see that event's doc comment
+ *   and `onItemDrop` below for the full flow.
+ * - **Clicks are reported, never acted on.** `itemClicked` says which item
+ *   and which named region (see `[bkKanbanClickTarget]`); opening a popup or
  *   doing nothing at all is entirely up to whoever is listening.
- * - **A card's own shape is never inspected**, beyond the two fields above.
- *   Tags, hours, avatars, due dates — the board doesn't know they exist.
+ * - **An item's own shape past the four required fields is never
+ *   inspected.** Tags, hours, avatars, due dates — the board doesn't know
+ *   they exist. `label` is the one exception: the board reads it for the
+ *   built-in add/remove buttons' aria-labels and as the default label an
+ *   add gets when no custom `columnHeaderActionsTemplate` supplies one.
  */
-declare class BkKanban<T = any> {
-    /** Column/status definitions. Unlimited — the board renders whatever it's given. */
-    columns: _angular_core.InputSignal<BkKanbanColumn[]>;
-    /** Flat card list. Grouped into columns via `columnIdField`, ordered within
-     *  a column by an `order` field when the cards carry one, otherwise left in
-     *  the sequence they appear here. */
-    cards: _angular_core.InputSignal<readonly T[]>;
-    /** Renders a card's body. Receives `{ $implicit: card, card, column, index }`. */
+declare class BkKanban<T extends ColumnItem = ColumnItem> {
+    /** Columns, each owning its own `items` — the single source of truth.
+     *  Unlimited columns, unlimited items per column; the board renders
+     *  whatever it's given. Mutated in place on every drag/add/remove — see
+     *  the component doc. */
+    columns: _angular_core.InputSignal<KanbanColumn<T>[]>;
+    /** Renders an item's body. Receives `{ $implicit: card, card, column,
+     *  index, removeItem }`. */
     cardTemplate: _angular_core.InputSignal<TemplateRef<BkKanbanCardContext<T>>>;
-    /** Field name, or a resolver function, that gives a card's column id.
-     *
-     *  A field name can be both read and written, so a cross-column drop
-     *  updates it directly. A resolver function is read-only — the board still
-     *  reports the move via `cardMoved`, but leaves updating the source data to
-     *  the host, since there's nowhere on a function to write the new value. */
-    columnIdField: _angular_core.InputSignal<string | ((card: T) => string)>;
-    dragEnabled: _angular_core.InputSignal<boolean>;
-    dragScope: _angular_core.InputSignal<BkKanbanDragScope>;
+    /** How far (and whether at all) a card can be dragged — see
+     *  `BkKanbanMovementRestriction`. One control instead of a separate
+     *  on/off switch plus a restriction, so there's nothing to keep in sync
+     *  between two inputs: `'none'` is what used to be `dragEnabled: false`. */
+    movementRestriction: _angular_core.InputSignal<BkKanbanMovementRestriction>;
     wipLimitBehavior: _angular_core.InputSignal<BkKanbanWipLimitBehavior>;
     /** Lets columns themselves be dragged into a new order, via their header
-     *  (`.bk-kanban-column-header` is the drag handle — a card's own drag
+     *  (`.bk-kanban-column-header` is the drag handle — an item's own drag
      *  keeps working independently, since it's a separate, unconnected drop
      *  list one level down). Off by default: reordering the board's own
-     *  columns is a bigger commitment than reordering cards within it, and not
+     *  columns is a bigger commitment than reordering items within it, and not
      *  every consumer wants a "To do / In progress / Done" pipeline to be
-     *  rearrangeable. `columns` is mutated in place the same way `cards` is
-     *  (see the component doc) — persisting the new order, if it needs to be,
-     *  is the host's job, done from `columnMoved`. */
-    columnDragEnabled: _angular_core.InputSignal<boolean>;
+     *  rearrangeable. */
+    dragColumn: _angular_core.InputSignal<boolean>;
+    /** How much a column-reorder `columnsChanged` emission carries — see
+     *  `BkKanbanColumnReorderPayload`. Only affects column reordering; every
+     *  other operation always emits complete columns regardless. */
+    columnReorderPayload: _angular_core.InputSignal<BkKanbanColumnReorderPayload>;
+    /** Off by default: a cross-column drop commits immediately, exactly like
+     *  a same-column reorder — `itemMoveBetweenColumns` never fires, and
+     *  there's nothing to bind. Turn this on to gate cross-column moves behind
+     *  that event instead — see its own doc comment and `onItemDrop` for the
+     *  full validate-before-commit flow this switches on. */
+    validateMove: _angular_core.InputSignal<boolean>;
     /** See `BkKanbanColumnScrollMode`. */
     columnScrollMode: _angular_core.InputSignal<BkKanbanColumnScrollMode>;
-    /** Extra class(es) appended to the board's own wrapper — `.bk-kanban-board`
-     *  in `kanban.html`, the element that directly contains the scrollable
-     *  region holding every column. Same idea as `columnClass`/`colHeaderClass`
-     *  one level down: it only adds classes, nothing here replaces bk-kanban's
-     *  own layout.
+    /** Extra class(es) appended to the board's own wrapper — the element that
+     *  directly contains the scrollable region holding every column. Same
+     *  idea as `columnClass`/`colHeaderClass` one level down: it only adds
+     *  classes, nothing here replaces bk-kanban's own layout.
      *
-     *  Deliberately kept off the *scrolling* element itself
-     *  (`.bk-kanban`, one level further in): a `padding` or `border` in here
-     *  would otherwise become part of what has to be scrolled past, and change
-     *  where the scrollbar itself ends up sitting relative to the columns —
-     *  this wrapper exists specifically so `boardClass` can decorate (a
-     *  background, a border, padding around the whole board) without ever
-     *  touching the box CDK and `columnScrollMode` are actually scrolling. */
+     *  Deliberately kept off the *scrolling* element itself: a `padding` or
+     *  `border` in here would otherwise become part of what has to be
+     *  scrolled past, and change where the scrollbar itself ends up sitting
+     *  relative to the columns — this wrapper exists specifically so
+     *  `boardClass` can decorate (a background, a border, padding around the
+     *  whole board) without ever touching the box CDK and `columnScrollMode`
+     *  are actually scrolling. */
     boardClass: _angular_core.InputSignal<string>;
-    /** Identity for `@for`'s `track`. Defaults to position in the rendered column. */
+    /** Identity for `@for`'s `track`. Defaults to `card.id` — every
+     *  `ColumnItem` is guaranteed to have one. */
     trackBy: _angular_core.InputSignal<((card: T) => string | number) | null>;
-    /** Rendered in a fixed slot in every column's header — e.g. an "add card"
-     *  button. Receives `BkKanbanColumnActionsContext`. The board owns where it
-     *  sits; the consumer owns what it does. */
-    columnHeaderActionsTemplate: _angular_core.InputSignal<TemplateRef<BkKanbanColumnActionsContext> | null>;
-    /** Overrides the built-in "No cards" placeholder for an empty column.
-     *  Receives `BkKanbanEmptyStateContext`. Takes priority over both
-     *  `noDataText` and a column's own `noDataText` — see `emptyStateText`. */
-    emptyStateTemplate: _angular_core.InputSignal<TemplateRef<BkKanbanEmptyStateContext> | null>;
-    /** Board-wide placeholder text for an empty column, used whenever a column
-     *  doesn't set its own `noDataText`. Only read when `emptyStateTemplate`
-     *  isn't supplied — see `emptyStateText`. */
-    noDataText: _angular_core.InputSignal<string>;
-    /** Whether a column flags an over-limit drop while still dragging (`'live'`)
-     *  or only once the drop is attempted (`'on-drop'`). See the doc block on
-     *  `isLiveOverLimit` for how the two relate to `wipLimitBehavior`. */
+    /** Rendered in a fixed slot in every column's header, alongside the
+     *  built-in add button when `showAddItem` is on. Receives
+     *  `BkKanbanColumnActionsContext` — its `addItem` is the same logic the
+     *  built-in button calls, so a fully custom header action can drive it
+     *  too instead of reimplementing id generation / limit checks. */
+    columnHeaderActionsTemplate: _angular_core.InputSignal<TemplateRef<BkKanbanColumnActionsContext<T>> | null>;
+    /** Overrides the built-in empty-column placeholder. Receives
+     *  `BkKanbanEmptyStateContext`. Takes priority over both `emptyMessage`
+     *  and a column's own `emptyMessage`. */
+    emptyStateTemplate: _angular_core.InputSignal<TemplateRef<BkKanbanEmptyStateContext<T>> | null>;
+    /** Board-wide placeholder text for an empty column, used whenever a
+     *  column doesn't set its own `emptyMessage`. Only read when
+     *  `emptyStateTemplate` isn't supplied. */
+    emptyMessage: _angular_core.InputSignal<string>;
+    /** Whether a column flags an over-limit drop while still dragging
+     *  (`'live'`) or only once the drop is attempted (`'on-drop'`). */
     dragPreviewMode: _angular_core.InputSignal<BkKanbanDragPreviewMode>;
-    cardMoved: _angular_core.OutputEmitterRef<BkKanbanCardMovedEvent<T>>;
-    cardClicked: _angular_core.OutputEmitterRef<BkKanbanCardClickedEvent<T>>;
+    /** Shows a built-in "+" button in every column's header (unless that
+     *  column's own `allowAdd` is `false`) when true. It calls the same
+     *  `addItem` logic exposed to `columnHeaderActionsTemplate` — with a
+     *  default `{ label: 'New item' }` — so out-of-the-box adding works with
+     *  zero template configuration. Renders alongside, not instead of,
+     *  `columnHeaderActionsTemplate` when both are supplied. */
+    showAddItem: _angular_core.InputSignal<boolean>;
+    /** Shows a built-in remove button on every card (unless that card's
+     *  column has `allowRemove: false`) when true — board-owned chrome, not
+     *  part of `cardTemplate`, so click/drag isolation is guaranteed by the
+     *  board itself rather than left to every consumer's own template to get
+     *  right. */
+    showRemoveItem: _angular_core.InputSignal<boolean>;
+    /** Fires after any operation that changes the board. See
+     *  `BkKanbanColumnsChangedEvent`'s doc comment for how to tell which
+     *  operation happened from the metadata field a returned column carries. */
+    columnsChanged: _angular_core.OutputEmitterRef<BkKanbanColumnsChangedEvent<T>>;
     columnLimitExceeded: _angular_core.OutputEmitterRef<BkKanbanColumnLimitExceededEvent>;
-    /** A column reorder completed — see `columnDragEnabled`. */
-    columnMoved: _angular_core.OutputEmitterRef<BkKanbanColumnMovedEvent>;
+    itemClicked: _angular_core.OutputEmitterRef<BkKanbanItemClickedEvent<T>>;
+    /** Fires for a cross-column drag before any state changes — only when
+     *  `validateMove` is on; see the event's own doc comment
+     *  and `onItemDrop`. Must be bound (and resolved) once that's on, or
+     *  cross-column drag-and-drop stops having any effect. */
+    itemMoveBetweenColumns: _angular_core.OutputEmitterRef<BkKanbanItemMoveBetweenColumnsEvent<T>>;
     /** Reserved — see `BkKanbanColumnActionsContext.trigger`. Most consumers
      *  bind a click handler directly on their own header-actions template and
      *  never reach for this. */
     columnActionTriggered: _angular_core.OutputEmitterRef<BkKanbanColumnActionTriggeredEvent>;
     /**
-     * Bumped after every in-place mutation (`setColumnId`, `renumber`) so
-     * `grouped` re-runs even though neither `cards()`'s array identity nor any
-     * card's object identity changed — the same trick as the table demo's
-     * `pgSelectionTick`, needed for exactly the same reason: signals only
-     * notice a new reference, and mutating fields in place is what lets a drop
-     * redraw in the right place without waiting on the host to hand back a
-     * whole new array.
+     * Bumped after every in-place mutation so the template re-reads
+     * `boardColumns()` even though neither `columns()`'s own array identity
+     * nor any column/item's object identity necessarily changed — mutating
+     * fields in place is what lets a drop/add/remove redraw in the right
+     * place without waiting on the host to hand back a whole new array.
      */
     private readonly structureTick;
-    /** Cards grouped by column id, each group in `order` order when present
-     *  (falling back to their sequence in `cards()` otherwise). Cards whose
-     *  resolved column id matches no known column are dropped silently rather
-     *  than rendered nowhere. */
-    private readonly grouped;
-    /** The cards to render for one column, in display order. */
-    cardsFor(columnId: string): T[];
-    private resolveColumnId;
-    private cardOrder;
+    /** What the template actually iterates — a signal that re-evaluates on
+     *  every `structureTick` bump, so in-place mutations to `columns()`'s own
+     *  items/sortOrder are always picked up. */
+    readonly boardColumns: _angular_core.Signal<KanbanColumn<T>[]>;
     resolveTrackBy(card: T, index: number): string | number;
+    private columnById;
     /** Column-header count badge, flagged once the column is over its limit —
      *  only while `wipLimitBehavior` is `'warn'`; `'block'` should never let a
      *  column get there and `'none'` treats the number as pure information. */
-    isColumnOverLimit(column: BkKanbanColumn): boolean;
+    isColumnOverLimit(column: KanbanColumn<T>): boolean;
     /** "3" with no limit, "3 / 5" with one — the header count badge's label. */
-    columnCountLabel(column: BkKanbanColumn): string;
-    columnActionsContext(column: BkKanbanColumn): BkKanbanColumnActionsContext;
-    emptyStateContext(column: BkKanbanColumn): BkKanbanEmptyStateContext;
+    columnCountLabel(column: KanbanColumn<T>): string;
+    /** Whether the built-in "+" button should render for this column —
+     *  `showAddItem` board-wide, unless this column opted itself out. */
+    showAddButton(column: KanbanColumn<T>): boolean;
+    /** Whether the built-in remove button should render for this card's
+     *  column — `showRemoveItem` board-wide, unless this column opted
+     *  itself out. */
+    showRemoveButton(column: KanbanColumn<T>): boolean;
+    columnActionsContext(column: KanbanColumn<T>): BkKanbanColumnActionsContext<T>;
+    emptyStateContext(column: KanbanColumn<T>): BkKanbanEmptyStateContext<T>;
     /** Text for the built-in empty-column placeholder: a column's own
-     *  `noDataText` when it sets one, else the board-wide `noDataText` input.
-     *  Only consulted when `emptyStateTemplate` isn't supplied — the template
-     *  wins outright once given, exactly like `emptyStateContext` itself. */
-    emptyStateText(column: BkKanbanColumn): string;
-    cardContext(card: T, column: BkKanbanColumn, index: number): BkKanbanCardContext<T>;
-    /** Which columns a column's drop list connects to, per `dragScope`. */
+     *  `emptyMessage` when it sets one, else the board-wide `emptyMessage`
+     *  input. Only consulted when `emptyStateTemplate` isn't supplied. */
+    emptyMessageFor(column: KanbanColumn<T>): string;
+    cardContext(card: T, column: KanbanColumn<T>, index: number): BkKanbanCardContext<T>;
+    /** Whether any card dragging is active at all — false only for
+     *  `movementRestriction: 'none'`. Drives both the column body's own
+     *  `cdkDropListDisabled` and each card's own `cdkDragDisabled`. */
+    readonly dragActive: _angular_core.Signal<boolean>;
+    /** Which columns a column's drop list connects to, per `movementRestriction`. */
     connectedListIds(columnId: string): string[];
-    /** `'cross'` means *only* moves between columns — reordering within one has
-     *  to be switched off at the list level, since a scoped-out `connectedTo`
-     *  alone still leaves the list free to sort itself. */
+    /** `'between'` means *only* moves between columns — reordering
+     *  within one has to be switched off at the list level, since a
+     *  scoped-out `connectedTo` alone still leaves the list free to sort
+     *  itself. `'none'` doesn't need to appear here too: `cdkDropListDisabled`
+     *  (bound to `dragActive`) already switches the whole list off, so whether
+     *  sorting specifically is "disabled" on top of that is moot. */
     readonly sortingDisabled: _angular_core.Signal<boolean>;
     /**
-     * `columns` is reordered in place — same trick as `cards` (see the
+     * `columns` is reordered in place — same trick as items (see the
      * component doc): the array reference the host handed in is mutated
-     * directly (`moveItemInArray`) rather than swapped for a new one, so the
-     * next render just reflects the new order. There's no `structureTick`-style
-     * signal to bump here the way card moves need one — nothing derives
-     * columns through a `computed()` the way `cardsFor` derives through
-     * `grouped`; the template reads `columns()` directly in its `@for`, so the
-     * drop event's own change detection pass is enough.
-     */
-    onColumnDrop(event: CdkDragDrop<BkKanbanColumn[]>): void;
+     * directly (`moveItemInArray`) rather than swapped for a new one.
+     * `sortOrder` is then renumbered for the whole array, and — unlike every
+     * other operation, which reports only the column(s) actually affected —
+     * *every* column in the board is reported here, in its resulting order,
+     * shaped per `columnReorderPayload`: consumers persisting a full column
+     * order need to see the whole list, not just the entries that happened to
+     * shift.
+     */
+    onColumnDrop(event: CdkDragDrop<KanbanColumn<T>[]>): void;
     private readonly dragSourceColumnId;
     private readonly hoveredOverLimitColumnId;
-    onDragStarted(column: BkKanbanColumn): void;
+    onDragStarted(column: KanbanColumn<T>): void;
     onDragEnded(): void;
     /**
-     * Live WIP-limit preview (§12 of the spec): as the dragged card enters a
-     * column, work out whether *landing* here would exceed its `wipLimit` and
-     * flag it immediately — before release, and independent of
-     * `wipLimitBehavior`, which only governs what happens once the card is
-     * actually dropped. A card re-entering its own source column doesn't grow
-     * that column's count, so only a genuine cross-column entry counts as +1.
-     */
-    onListEntered(event: CdkDragEnter<T[]>, column: BkKanbanColumn): void;
-    onListExited(column: BkKanbanColumn): void;
-    isLiveOverLimit(column: BkKanbanColumn): boolean;
-    onDrop(event: CdkDragDrop<T[]>, column: BkKanbanColumn): void;
-    private setColumnId;
+     * Live WIP-limit preview: as the dragged item enters a column, work out
+     * whether *landing* here would exceed its `limit` and flag it immediately
+     * — before release, and independent of `wipLimitBehavior`, which only
+     * governs what happens once the item is actually dropped. An item
+     * re-entering its own source column doesn't grow that column's count, so
+     * only a genuine cross-column entry counts as +1.
+     */
+    onListEntered(event: CdkDragEnter<T[]>, column: KanbanColumn<T>): void;
+    onListExited(column: KanbanColumn<T>): void;
+    isLiveOverLimit(column: KanbanColumn<T>): boolean;
     private renumber;
+    /**
+     * Same-column reorder commits immediately (nothing to validate — the
+     * column's own membership never changes) and reports the one affected
+     * column with its complete, re-ordered `items`. A genuine cross-column
+     * drop is a different story: see the second half of this method and
+     * `itemMoveBetweenColumns`'s own doc comment for why it does *not*
+     * mutate anything here.
+     */
+    onItemDrop(event: CdkDragDrop<T[]>, column: KanbanColumn<T>): void;
+    /** The actual cross-column mutation, run only once `resolve({ success:
+     *  true })` comes back from `itemMoveBetweenColumns` — see `onItemDrop`. */
+    private commitCrossColumnMove;
+    private generateId;
+    /** Adds a new item to a column — the logic backing both the built-in "+"
+     *  button (`showAddItem`) and `BkKanbanColumnActionsContext.addItem`
+     *  for a fully custom header template. Supply at least `label`; an `id`
+     *  given is used as-is, otherwise one is generated. Respects
+     *  `wipLimitBehavior` exactly like a cross-column drop does, and does
+     *  nothing at all for a column with `allowAdd: false` or an empty/missing
+     *  `label` — see §11. */
+    addItem(columnId: string, data: {
+        id?: string;
+        label: string;
+        [key: string]: unknown;
+    }): void;
+    /** Removes an item from a column — the logic backing both the built-in
+     *  remove button (`showRemoveItem`) and `BkKanbanCardContext.removeItem`
+     *  for a fully custom card body. Does nothing for a column with
+     *  `allowRemove: false`, or if the item isn't actually there. */
+    removeItem(columnId: string, itemId: string): void;
+    onAddButtonClick(column: KanbanColumn<T>): void;
+    /** The remove button's own click handler. It's a `bk-icon-button`, so its
+     *  own `(clicked)` output only ever carries a boolean, not the originating
+     *  event — isolation happens entirely in the template instead, via native
+     *  `mousedown`/`pointerdown`/`click` listeners bound directly on the
+     *  `<bk-icon-button>` host: `mousedown`/`pointerdown` are stopped before
+     *  CDK's drag-start detection (which listens on the card itself, an
+     *  ancestor of this button) ever sees the press, and stopping `click` too
+     *  keeps it from also reaching `onItemClick` on the card underneath. See
+     *  §18/§12 of the spec this shipped against. */
+    onRemoveButtonClick(column: KanbanColumn<T>, card: T): void;
+    private readonly hoveredRemoveItemId;
+    removeButtonVariant(card: T): IconButtonVariant;
+    removeButtonIcon(card: T): string;
+    onRemoveButtonHover(card: T, hovered: boolean): void;
     /**
      * One listener per card resolves both the whole-card click and every
      * `[bkKanbanClickTarget]` region: `closest()` from the actual event target
      * finds the nearest marked ancestor within this card, or there isn't one
      * and it's a plain card click. Either way this fires exactly once — never
-     * once for the region and again for the card underneath it.
+     * once for the region and again for the card underneath it. The remove
+     * button (when shown) stops its own click from ever reaching here — see
+     * `onRemoveButtonClick`.
      */
-    onCardClick(event: MouseEvent, card: T): void;
+    onItemClick(event: MouseEvent, card: T): void;
     static ɵfac: _angular_core.ɵɵFactoryDeclaration<BkKanban<any>, never>;
-    static ɵcmp: _angular_core.ɵɵComponentDeclaration<BkKanban<any>, "bk-kanban", ["bkKanban"], { "columns": { "alias": "columns"; "required": true; "isSignal": true; }; "cards": { "alias": "cards"; "required": true; "isSignal": true; }; "cardTemplate": { "alias": "cardTemplate"; "required": true; "isSignal": true; }; "columnIdField": { "alias": "columnIdField"; "required": false; "isSignal": true; }; "dragEnabled": { "alias": "dragEnabled"; "required": false; "isSignal": true; }; "dragScope": { "alias": "dragScope"; "required": false; "isSignal": true; }; "wipLimitBehavior": { "alias": "wipLimitBehavior"; "required": false; "isSignal": true; }; "columnDragEnabled": { "alias": "columnDragEnabled"; "required": false; "isSignal": true; }; "columnScrollMode": { "alias": "columnScrollMode"; "required": false; "isSignal": true; }; "boardClass": { "alias": "boardClass"; "required": false; "isSignal": true; }; "trackBy": { "alias": "trackBy"; "required": false; "isSignal": true; }; "columnHeaderActionsTemplate": { "alias": "columnHeaderActionsTemplate"; "required": false; "isSignal": true; }; "emptyStateTemplate": { "alias": "emptyStateTemplate"; "required": false; "isSignal": true; }; "noDataText": { "alias": "noDataText"; "required": false; "isSignal": true; }; "dragPreviewMode": { "alias": "dragPreviewMode"; "required": false; "isSignal": true; }; }, { "cardMoved": "cardMoved"; "cardClicked": "cardClicked"; "columnLimitExceeded": "columnLimitExceeded"; "columnMoved": "columnMoved"; "columnActionTriggered": "columnActionTriggered"; }, never, never, true, never>;
+    static ɵcmp: _angular_core.ɵɵComponentDeclaration<BkKanban<any>, "bk-kanban", ["bkKanban"], { "columns": { "alias": "columns"; "required": true; "isSignal": true; }; "cardTemplate": { "alias": "cardTemplate"; "required": true; "isSignal": true; }; "movementRestriction": { "alias": "movementRestriction"; "required": false; "isSignal": true; }; "wipLimitBehavior": { "alias": "wipLimitBehavior"; "required": false; "isSignal": true; }; "dragColumn": { "alias": "dragColumn"; "required": false; "isSignal": true; }; "columnReorderPayload": { "alias": "columnReorderPayload"; "required": false; "isSignal": true; }; "validateMove": { "alias": "validateMove"; "required": false; "isSignal": true; }; "columnScrollMode": { "alias": "columnScrollMode"; "required": false; "isSignal": true; }; "boardClass": { "alias": "boardClass"; "required": false; "isSignal": true; }; "trackBy": { "alias": "trackBy"; "required": false; "isSignal": true; }; "columnHeaderActionsTemplate": { "alias": "columnHeaderActionsTemplate"; "required": false; "isSignal": true; }; "emptyStateTemplate": { "alias": "emptyStateTemplate"; "required": false; "isSignal": true; }; "emptyMessage": { "alias": "emptyMessage"; "required": false; "isSignal": true; }; "dragPreviewMode": { "alias": "dragPreviewMode"; "required": false; "isSignal": true; }; "showAddItem": { "alias": "showAddItem"; "required": false; "isSignal": true; }; "showRemoveItem": { "alias": "showRemoveItem"; "required": false; "isSignal": true; }; }, { "columnsChanged": "columnsChanged"; "columnLimitExceeded": "columnLimitExceeded"; "itemClicked": "itemClicked"; "itemMoveBetweenColumns": "itemMoveBetweenColumns"; "columnActionTriggered": "columnActionTriggered"; }, never, never, true, never>;
 }
 
 /**
@@ -5294,4 +5512,4 @@ declare class BkKanbanClickTarget {
 }
 
 export { ARROW_CORNER_GAP, BKTooltipDirective, BK_DEFAULT_DIALOG_CONFIG, BK_DIALOG_DATA, BK_DIALOG_GLOBAL_CONFIG, BK_TABLE, BkAvatar, BkAvatarGroup, BkAvatarUploader, BkBadge, BkBreadcrumb, BkButton, BkButtonGroup, BkCalendarManagerService, BkCheckbox, BkColumnFilterService, BkColumnSelect, BkCustomCalendar, BkDialogActions, BkDialogClose, BkDialogContent, BkDialogModule, BkDialogRef, BkDialogService, BkDialogTitle, BkDragHandle, BkDropdown, BkFileCard, BkFilePicker, BkGrid, BkHierarchicalSelect, BkIconButton, BkInput, BkInputChips, BkKanban, BkKanbanClickTarget, BkLoader, BkMenu, BkPagination, BkPill, BkPopover, BkRadioButton, BkScheduledDatePicker, BkSelect, BkSpinner, BkTable, BkTableDrag, BkTableFooter, BkTableSummary, BkTableTitle, BkTabs, BkTd, BkTextarea, BkTh, BkTimePicker, BkToastr, BkToastrService, BkToggle, BkTooltipInteractionService, BkTrExpand, BkTreeDrag, BkValidator, BkVirtualScroll, BrickclayIcons, BrickclayLib, CalendarModule, CalendarMonth, CalendarSelection, CalendarWeekday, ColumnFilterOption, DEFAULT_COUNTRY_OPTIONS, NEUTRAL_APPEARANCE, OPPOSITE_SIDE, POPOVER_PLACEMENTS, clamp, containsBkTreeNode, deriveAppearance, flattenBkTreeData, getDialogBackdropAnimation, getDialogPanelAnimation, joinPlacement, moveBkTreeNode, normalizeBkTableSize, parseColor, splitPlacement };
-export type { AvatarFallback, AvatarGroupItem, AvatarSize, AvatarVariant, BadgeColor, BadgeSize, BadgeVariant, BkAnimationKeyframes, BkAvatarFallback, BkAvatarSize, BkCellAlign, BkColumnRef, BkColumnSelectPosition, BkDialogAnimation, BkDialogConfig, BkDialogPosition, BkFilterFn, BkFilterOption, BkInputAutoCapitalize, BkInputAutoComplete, BkInputMode, BkInputSize, BkInputType, BkKanbanCardClickedEvent, BkKanbanCardContext, BkKanbanCardMovedEvent, BkKanbanColumn, BkKanbanColumnActionTriggeredEvent, BkKanbanColumnActionsContext, BkKanbanColumnLimitExceededEvent, BkKanbanColumnMovedEvent, BkKanbanColumnScrollMode, BkKanbanDragPreviewMode, BkKanbanDragScope, BkKanbanEmptyStateContext, BkKanbanWipLimitBehavior, BkLoaderVariant, BkPageSize, BkPageSizeVisibility, BkSelectGridColumn, BkSortDirection, BkSortFn, BkSortOrder, BkTableNoResult, BkTableQueryParams, BkTableScroll, BkTableSelection, BkTableSize, BkTableSizeToken, BkTextAreaAutoCapitalize, BkTextAreaAutoComplete, BkTextAreaInputMode, BkTooltipDismissible, BkTreeDragScope, BkTreeDropEvent, BkTreeDropPosition, BkTreeRow, BreadcrumbItem, ButtonSize, ButtonVariant, CalendarRange, ColorAppearance, ColorFill, CountryOption, CustomRangesConfig, DotPosition, DotStatus, DropdownItem, DropdownPlacement, DropdownSize, DropdownTrigger, DropdownVariant, FileState, GroupItem, GroupMode, HierarchicalNode, IconButtonSize, IconButtonVariant, IconOrientation, MenuItem, MenuOrientation, MenuPopupSide, MenuSize, MenuSubmenuMode, MenuTrigger, PillColor, PillSize, PillVariant, PopoverAlign, PopoverPlacement, PopoverSide, ScheduledDateSelection, SortDirection, SpinnerSize, TabIconDirection, TabItem, TableAction, TableBadge, TableColumn, TableIcon, TableRows, TabsColors, TabsOrientation, TabsVariant, TimeConfiguration, ToastConfig, ToastMessage, ToastMethodOptions, ToastPosition, ToastSeverity };
+export type { AvatarFallback, AvatarGroupItem, AvatarSize, AvatarVariant, BadgeColor, BadgeSize, BadgeVariant, BkAnimationKeyframes, BkAvatarFallback, BkAvatarSize, BkCellAlign, BkColumnRef, BkColumnSelectPosition, BkDialogAnimation, BkDialogConfig, BkDialogPosition, BkFilterFn, BkFilterOption, BkInputAutoCapitalize, BkInputAutoComplete, BkInputMode, BkInputSize, BkInputType, BkKanbanCardContext, BkKanbanColumnActionTriggeredEvent, BkKanbanColumnActionsContext, BkKanbanColumnLimitExceededEvent, BkKanbanColumnReorderPayload, BkKanbanColumnScrollMode, BkKanbanColumnSummary, BkKanbanColumnsChangedEvent, BkKanbanDragPreviewMode, BkKanbanEmptyStateContext, BkKanbanItemClickedEvent, BkKanbanItemMoveBetweenColumnsEvent, BkKanbanItemMoveValidationResult, BkKanbanMovementRestriction, BkKanbanWipLimitBehavior, BkLoaderVariant, BkPageSize, BkPageSizeVisibility, BkSelectGridColumn, BkSortDirection, BkSortFn, BkSortOrder, BkTableNoResult, BkTableQueryParams, BkTableScroll, BkTableSelection, BkTableSize, BkTableSizeToken, BkTextAreaAutoCapitalize, BkTextAreaAutoComplete, BkTextAreaInputMode, BkTooltipDismissible, BkTreeDragScope, BkTreeDropEvent, BkTreeDropPosition, BkTreeRow, BreadcrumbItem, ButtonSize, ButtonVariant, CalendarRange, ColorAppearance, ColorFill, ColumnItem, CountryOption, CustomRangesConfig, DotPosition, DotStatus, DropdownItem, DropdownPlacement, DropdownSize, DropdownTrigger, DropdownVariant, FileState, GroupItem, GroupMode, HierarchicalNode, IconButtonSize, IconButtonVariant, IconOrientation, KanbanColumn, MenuItem, MenuOrientation, MenuPopupSide, MenuSize, MenuSubmenuMode, MenuTrigger, PillColor, PillSize, PillVariant, PopoverAlign, PopoverPlacement, PopoverSide, ScheduledDateSelection, SortDirection, SpinnerSize, TabIconDirection, TabItem, TableAction, TableBadge, TableColumn, TableIcon, TableRows, TabsColors, TabsOrientation, TabsVariant, TimeConfiguration, ToastConfig, ToastMessage, ToastMethodOptions, ToastPosition, ToastSeverity };