@danxbot/ui 3.4.3 → 3.5.0

package/dist/types/lib/board/index.d.ts

@@ -0,0 +1,14 @@
+/**
+ * The `lib/board` module's own barrel — model.ts, move.ts and use-board.ts
+ * (this agent's three files) plus a re-export of the sibling `types.ts` this
+ * module is built against. Mirrors `lib/dnd/index.ts`'s own shape for the
+ * same reason: a consumer reaching for anything board-related should have
+ * one import path, not one per file.
+ *
+ * NOT wired into the package's top-level `src/index.ts` — that barrel is
+ * owned by the contract's author, not this agent (see this round's brief).
+ */
+export type { BoardAccessors, BoardColumnDef, BoardColumnId, BoardColumnModel, BoardItemId, BoardMove, BoardMoveRequest, BoardMoveSource, BoardMoveVerdict, UseBoardOptions, } from "./types";
+export { buildBoardModel, type BoardModel } from "./model";
+export { applyBoardMoves, resolveMove, type ResolveMoveContext, type ResolvedMove, } from "./move";
+export { useBoard, type UseBoardResult } from "./use-board";

package/dist/types/lib/board/model.d.ts

@@ -0,0 +1,43 @@
+/**
+ * ==== BOARD MODEL ====
+ *
+ * Pure derivation: `items` + column defs + accessors -> one `BoardColumnModel`
+ * per declared column, ready to render. No React, no mutation, no I/O other
+ * than the diagnostic `console.warn` below — the same inputs always produce
+ * the same output, which is what makes this testable without a browser and
+ * safe to call on every render (`use-board.ts` wraps it in a `useMemo`, it
+ * does not need to defend itself).
+ *
+ * WHY AN ITEM THAT MATCHES NO COLUMN IS NEVER DROPPED. GitHub Projects has a
+ * live, cited bug (RES-GAME / tracker) where grouping by parent silently
+ * drops sub-issues that carry a valid link — the item is real, the grouping
+ * key is merely stale, and the user has no way to discover the card still
+ * exists. A board built the same way inherits the identical bug the moment a
+ * column is renamed or retired out from under live data, which is routine
+ * here (a status gets retired, a card's derived status hasn't caught up to a
+ * board's `columns` prop yet, a consumer passes a filtered `columns` list).
+ * So an item whose `getColumnId` names no declared column is never
+ * discarded — it is routed into `unassigned`, a structurally present field
+ * of the model rather than a side channel a caller has to remember to check.
+ * Every item that goes in comes out somewhere: either inside exactly one
+ * `columns[].items`, or inside `unassigned`. That invariant is asserted by
+ * the "floor" test in board-core.test.ts, so a future edit that starts
+ * quietly filtering can't pass silently either.
+ *
+ * A single summarising `console.warn` also fires when any item orphans,
+ * matching the `[danxbot] …` prefix `ErrorBoundary.tsx` already uses (and
+ * unguarded, as that one is — this library has no dev-only convention). It is
+ * a diagnostic ONLY, never the sole signal, since a console message is easy to
+ * miss and impossible to act on from inside a pure function. The `data` itself
+ * is what must never be lost; the warning just makes the gap visible before a
+ * consumer has built an "Unsorted" affordance for `unassigned`.
+ */
+import type { BoardAccessors, BoardColumnDef, BoardColumnModel } from "./types";
+/** The full derivation result. See the file header for why `unassigned` exists. */
+export interface BoardModel<T> {
+    /** One entry per declared column, in the SAME order as the `columns` input. */
+    columns: readonly BoardColumnModel<T>[];
+    /** Items whose `getColumnId` matched no entry in `columns`. Never dropped. */
+    unassigned: readonly T[];
+}
+export declare function buildBoardModel<T>(items: readonly T[], columns: readonly BoardColumnDef[], accessors: BoardAccessors<T>): BoardModel<T>;

package/dist/types/lib/board/move.d.ts

@@ -0,0 +1,162 @@
+/**
+ * ==== MOVE ====
+ *
+ * The one validated pipeline every `BoardMoveRequest` passes through, no
+ * matter which of the four `BoardMoveSource` values produced it. `types.ts`
+ * names this the load-bearing rule: pointer drag, keyboard, the mandatory
+ * "Move to…" menu (WCAG 2.5.7) and bulk selection all construct a request
+ * and call the SAME function here. A per-source branch that skips a step is
+ * exactly how the accessible paths rot — the drag path gets exercised daily
+ * and the menu path silently stops agreeing with it, taking the 2.5.7
+ * alternative down with it and nobody notices until an audit.
+ *
+ * TWO RESPONSIBILITIES, DELIBERATELY SEPARATE FUNCTIONS:
+ *
+ *   `resolveMove` decides WHETHER a request may commit. It is the only thing
+ *   `use-board.ts`'s `requestMove` calls, and it never touches `T[]` — it
+ *   returns a verdict plus the subset of moves worth writing.
+ *
+ *   `applyBoardMoves` decides WHAT the resulting `items` array looks like,
+ *   given moves already known to be valid (typically `resolveMove(...).commit`).
+ *   It does no validation of its own — that would duplicate `resolveMove` — and
+ *   it is exported separately because `onMove` on `UseBoardOptions` returns
+ *   `void`: this module hands the consumer a verdict, not a next state, so a
+ *   consumer's own `onMove` needs a correct way to turn "these moves are real"
+ *   into "here is my next `items` array." Without it, every consumer either
+ *   re-derives the exact index arithmetic `applyMove` exists to remove, or
+ *   worse, folds it over a bulk request and gets the trap below.
+ *
+ * WHY `resolveMove` DOES ITS OWN STRUCTURAL CHECKS BEFORE EVER CALLING THE
+ * CALLER'S `validateMove`. `validateMove` is optional and, per `types.ts`,
+ * "Absent means every move is allowed" — so nothing upstream is guaranteed to
+ * have checked that `itemId` names a real item or that a `columnId` names a
+ * declared column. A malformed request must never reach a consumer's domain
+ * rule carrying numbers that don't correspond to reality, and a consumer's
+ * `validateMove` should never have to re-derive checks this module can prove
+ * from its own inputs for free. So structural validity runs FIRST, always on,
+ * not configurable — before `validateMove`, before no-op filtering.
+ *
+ * WHY NO-OP FILTERING IS PER-MOVE BUT VALIDITY IS ALL-OR-NOTHING. These are
+ * different questions. Atomicity ("did the batch survive as one unit")
+ * governs whether the request is safe to commit AT ALL — RES-GAME names this
+ * exactly: "moving five selected cards should not accept the first two and
+ * reject the remaining three." One bad move rejects the whole batch, full
+ * stop. But once a batch is known-good, a card that happens to already be
+ * exactly where it is going is not an error — it is nothing to write.
+ * Dropping that ONE entry from the committed set changes nothing about the
+ * other four having moved correctly, and `onMove`'s own doc on
+ * `UseBoardOptions` names the cost of not doing this: "the previous board
+ * wrote its ordering field on every release that landed where it started."
+ *
+ * NO-OP IS A PER-MOVE, SYNTACTIC CHECK — REUSING `isNoOp` FROM `lib/dnd`,
+ * NOT A FULL SIMULATION OF FINAL POSITION. `isNoOp(from, to)` says "same
+ * column, same index" for exactly one move, taken at face value. For a bulk
+ * request whose moves interact (two items landing in the same column), a
+ * move's own `{column, index}` pair can be untouched while its ABSOLUTE final
+ * position shifts because a sibling move inserted ahead of it. This module
+ * does not attempt to detect that: `to.index` is the caller's stated INTENT,
+ * so a move that literally says "column A index 2 to column A index 2" is
+ * declaring no intended change regardless of what its bulk-mates do, and
+ * that is the same per-item promise the drag engine's own `DragEndEvent.moved`
+ * makes — it never reasoned about siblings either, because a single drag
+ * gesture never has any.
+ *
+ * THE BULK INDEX CONVENTION, AND WHY IT HAS TO BE STATED EXPLICITLY. The
+ * engine's single-item convention — `to.index` counts the destination list
+ * WITH THE DRAGGED ITEM ALREADY REMOVED — has no obvious generalisation to N
+ * items removed from possibly-different columns at once, and `types.ts`
+ * does not pick one; that is this module's decision to make and document.
+ * THE RULE: every move's `to.index`, bulk or not, counts its destination
+ * column's items with EVERY item named ANYWHERE in the same request already
+ * removed — not just itself. For a single-move request that is identical to
+ * the engine's own rule (nothing else is being removed). For a bulk request
+ * it means a UI constructing the request reasons about one shared reference
+ * frame per target column ("insert these three selected cards starting at
+ * position two among the cards that are staying put"), not about where its
+ * OTHER selected cards will land — which is the only version of "bulk move
+ * to a position" an operator selecting five cards can sensibly form an
+ * intention about in the first place.
+ *
+ * THE TRAP THIS CONVENTION EXISTS TO AVOID: SEQUENTIAL applyMove FOLDING
+ * SILENTLY CORRUPTS A BULK REORDER. Applying move 1 then move 2 via
+ * `applyMove` one at a time is NOT equivalent to applying them together,
+ * because move 1's splice shifts every index move 2 was computed against —
+ * and worse, if move 2's stored index is blindly reused against the
+ * ALREADY-SHIFTED array (rather than re-resolved), it can silently pick up
+ * the wrong item's position entirely. `applyBoardMoves` never folds moves
+ * sequentially over a mutating array for this reason. Instead it resolves
+ * every move against ONE shared snapshot — the residual list per column with
+ * every moved item already removed — and inserts all of a column's incoming
+ * items in a single deterministic pass: sorted by `to.index` ascending
+ * (ties broken by the item's original position in `moves`, i.e. request
+ * order), each inserted at `to.index + (insertions already made into this
+ * column)`. That running offset is exactly what accounts for earlier
+ * insertions shifting the positions later ones land at, computed once
+ * instead of re-derived per move. board-core.test.ts pins a concrete bulk
+ * case where the naive sequential-splice answer and this one visibly differ,
+ * so the property is proven rather than incidentally true.
+ *
+ * WHY `applyBoardMoves` CALLS THE SHARED `applyMove` FOR THE ONE CASE WHERE
+ * IT APPLIES, AND HAND-SPLICES EVERYWHERE ELSE. `applyMove(list, from, to)`
+ * splices ONE array — it has no way to express "remove from list A, insert
+ * into list B," because a cross-column move is inherently a two-list
+ * operation. The design system's own `DragDropPage` demo shows this exact
+ * split already: `applyMove` for the same-container branch, a manual
+ * remove-then-insert for the cross-container one. This module follows the
+ * identical rule for the single-move, same-column case (delegates to
+ * `applyMove` outright — see the equivalence test, which proves the general
+ * residual-based path used for every other case produces byte-identical
+ * output to `applyMove` when it degenerates to N=1, same column). Every
+ * other shape — cross-column, or any bulk request — has no single shared
+ * array to splice, so it goes through the residual-and-insert pass above.
+ */
+import type { BoardAccessors, BoardColumnDef, BoardMove, BoardMoveRequest, BoardMoveVerdict } from "./types";
+/** Everything `resolveMove` reads to prove a request is structurally real. */
+export interface ResolveMoveContext<T> {
+    items: readonly T[];
+    columns: readonly BoardColumnDef[];
+    accessors: BoardAccessors<T>;
+    /** Consulted after structural validity holds. See the file header for order. */
+    validateMove?: (request: BoardMoveRequest) => BoardMoveVerdict;
+}
+export interface ResolvedMove {
+    verdict: BoardMoveVerdict;
+    /**
+     * The subset of the request's moves worth committing, in original order.
+     * Empty whenever there is nothing to write — either every move was a
+     * no-op, or `verdict.ok` is false. Only ever meaningful when `verdict.ok`.
+     */
+    commit: readonly BoardMove[];
+}
+export declare function resolveMove<T>(context: ResolveMoveContext<T>, request: BoardMoveRequest): ResolvedMove;
+/**
+ * Turn a set of already-valid moves into the consumer's next `items` array.
+ * Call this with moves already proven valid — typically `resolveMove(...).commit`
+ * — never with raw, unvalidated input: this function does no checking of its
+ * own, on purpose, so it stays a pure array transform with no notion of
+ * "reject." Handles N=1 and N>1 (same-column or cross-column, mixed) with the
+ * one algorithm described in the file header.
+ *
+ * Reorders which COLUMN each item's block appears in within the returned
+ * flat array (columns are emitted in first-seen order, any brand-new target
+ * column appended after); WITHIN a column, order is always exactly what the
+ * moves + original relative order produce. Between-column interleaving in
+ * the input `items` array is not preserved because nothing in this module's
+ * contract depends on it — `BoardAccessors.getColumnId` is what determines
+ * column membership on every subsequent `buildBoardModel` call, and
+ * `buildBoardModel` only ever reads WITHIN-column order.
+ *
+ * NEVER WRITES A FIELD ON ANY ITEM — ONLY REPOSITIONS. `BoardAccessors` has
+ * no setter, on purpose (the file header on `types.ts` — items are opaque),
+ * so this function CANNOT change what `getColumnId` reports for a moved
+ * item; every returned item is the exact same reference it was given, just
+ * possibly in a different slot. For a CROSS-column move this means the
+ * repositioning alone does nothing observable until the caller ALSO updates
+ * the moved item's own underlying field (a `status`, a `columnId`, whatever
+ * the consumer's domain calls it) — that write is the consumer's, entirely
+ * outside this module, because only the consumer's own accessor knows how to
+ * produce it. The usual order is: update the field(s) first, THEN call this
+ * to fix array position — see board-core.test.ts's "what it does and does
+ * not mutate" tests, which pin both halves of this split.
+ */
+export declare function applyBoardMoves<T>(items: readonly T[], accessors: BoardAccessors<T>, moves: readonly BoardMove[]): T[];

package/dist/types/lib/board/types.d.ts

@@ -0,0 +1,158 @@
+/**
+ * The board contract. One model shape, one movement pipeline, read by the
+ * headless core and by the React slot layer above it.
+ *
+ * WHAT A BOARD IS HERE. Columns of items, where the items are OPAQUE to us. The
+ * board never learns what an item means — no `title`, no `priority`, no
+ * `assignee`, no status vocabulary. It knows an item's identity, which column
+ * holds it, and nothing else; everything visible is rendered by the consumer.
+ * That is not squeamishness about coupling, it is the only way the same
+ * component serves a second application: the moment a named prop describes a
+ * domain field, every consumer whose domain differs has to fight it.
+ *
+ * WHY ACCESSORS RATHER THAN A REQUIRED ITEM SHAPE. Demanding
+ * `{id, columnId}` forces every consumer to map their data into our shape and
+ * back out again, and that mapping is where identity gets lost — a remap that
+ * regenerates ids breaks drag mid-gesture, and it breaks silently. Reading the
+ * consumer's own objects through accessor functions means their array IS the
+ * source of truth and no copy exists to drift.
+ *
+ * THE MOVEMENT PIPELINE IS SINGULAR, AND THAT IS THE LOAD-BEARING RULE.
+ * Pointer drag, keyboard, the action menu and a bulk move all terminate in the
+ * SAME validated `onMove`. The alternative — a code path per input — is exactly
+ * how the accessible paths rot: the drag path gets exercised daily and the menu
+ * path silently stops agreeing with it, taking the WCAG 2.5.7 alternative
+ * (below) down with it. There is one funnel, so a fix or a bug reaches every
+ * input at once.
+ *
+ * WCAG 2.2 SC 2.5.7 IS WHY A MENU PATH EXISTS AT ALL, AND KEYBOARD DOES NOT
+ * SATISFY IT. Verbatim from the W3C's own understanding document: "achieving
+ * keyboard equivalence for a dragging operation does not automatically meet
+ * this success criterion, unless that equivalent keyboard operation also
+ * provides controls that can be clicked or tapped with a pointer." A touchscreen
+ * user may have no keyboard at all. So a single-pointer, non-dragging route to
+ * every drag outcome is mandatory rather than a courtesy, and `"menu"` is a
+ * first-class `BoardMoveSource` for that reason.
+ *
+ * INDICES COUNT THE LIST WITH THE MOVED ITEM ALREADY REMOVED. Inherited
+ * deliberately from `lib/dnd`'s `DropTarget` (see its header): it makes
+ * same-column and cross-column moves arithmetically identical and removes the
+ * whole off-by-one class. Every index in this file means that. Restating it
+ * here rather than assuming it, because a board that re-derives its own
+ * convention alongside the engine's is how the two drift.
+ */
+import type { ContainerId, DragId } from "../dnd";
+/**
+ * Identities are the engine's, not parallel types. A board column IS a drag
+ * container and a board item IS a draggable, so aliasing them keeps a value
+ * from having to be cast on its way between the two layers — the kind of cast
+ * that compiles forever and is wrong once.
+ */
+export type BoardColumnId = ContainerId;
+export type BoardItemId = DragId;
+/**
+ * How the board reads the consumer's own objects. `getId` and `getColumnId` are
+ * required because they are the two facts a board cannot function without;
+ * everything else about an item is the consumer's business.
+ */
+export interface BoardAccessors<T> {
+    /** Stable across renders. Never an array index — see the engine's `DragId`. */
+    getId: (item: T) => BoardItemId;
+    getColumnId: (item: T) => BoardColumnId;
+}
+export interface BoardColumnDef {
+    id: BoardColumnId;
+    /**
+     * Spoken in every announcement about this column and shown in the move menu.
+     * Required, unlike the engine's optional `label`: a column whose accessible
+     * name falls back to an id reads as "column c-3-todo" to a screen reader,
+     * which is speakable and useless. The board always has a real name available
+     * because the consumer had to name the column to render its header anyway.
+     */
+    label: string;
+    /**
+     * Soft cap on item count. Exceeding it is a VISUAL event, not a blocked move
+     * — a WIP limit exists to interrupt a human, and a board that refuses the
+     * drop instead just teaches people to work around the board. The core reports
+     * `overWip`; the view layer is responsible for making it loud.
+     */
+    wipLimit?: number;
+}
+/** One item's move. `to.index` counts the destination list without this item. */
+export interface BoardMove {
+    itemId: BoardItemId;
+    from: {
+        columnId: BoardColumnId;
+        index: number;
+    };
+    to: {
+        columnId: BoardColumnId;
+        index: number;
+    };
+}
+/**
+ * Which input produced the move. Kept on the request rather than inferred
+ * downstream because the three that are not `"pointer"` are the ones with no
+ * visible symptom when they break: a consumer's telemetry, and our own tests,
+ * need to assert that all four routes actually reach the funnel.
+ */
+export type BoardMoveSource = "pointer" | "keyboard" | "menu" | "bulk";
+/**
+ * `moves.length > 1` only for `"bulk"`, and then it is ALL-OR-NOTHING.
+ * Partially applying a multi-select move — accepting the first two cards and
+ * rejecting the rest — leaves the operator with a board state they did not ask
+ * for and cannot infer, which is worse than a clean refusal.
+ */
+export interface BoardMoveRequest {
+    moves: readonly BoardMove[];
+    source: BoardMoveSource;
+}
+/**
+ * A rejection MUST carry a reason, and that is why this is a verdict object
+ * rather than a boolean. A bare refusal is the failure mode GitHub Actions is
+ * still generating support threads over — a job sits in "queued" and the UI
+ * cannot say whether it is a concurrency limit, an approval or capacity. The
+ * reason is surfaced to the user and to the live-region announcer, so it is
+ * written for a person to read, not logged.
+ */
+export type BoardMoveVerdict = {
+    ok: true;
+} | {
+    ok: false;
+    reason: string;
+};
+/** A column as the core computes it, ready to render. */
+export interface BoardColumnModel<T> {
+    id: BoardColumnId;
+    label: string;
+    items: readonly T[];
+    /** Count is on the model because the view needs it before it renders rows. */
+    count: number;
+    wipLimit: number | undefined;
+    /** `true` when `count` exceeds `wipLimit`. Always false with no limit set. */
+    overWip: boolean;
+}
+export interface UseBoardOptions<T> {
+    items: readonly T[];
+    columns: readonly BoardColumnDef[];
+    accessors: BoardAccessors<T>;
+    /**
+     * Consulted before ANY move commits, from any of the four sources. Absent
+     * means every move is allowed — the common case, and not something a consumer
+     * should have to write boilerplate to say.
+     */
+    validateMove?: (request: BoardMoveRequest) => BoardMoveVerdict;
+    /**
+     * The single commit point. Fires only for a move that is both valid and not a
+     * no-op: the engine's `DragEndEvent.moved` exists because the previous board
+     * wrote its ordering field on every release that landed where it started, and
+     * a write that changes nothing still costs a request, a re-render and an audit
+     * row. That filtering happens in the core so no consumer has to remember it.
+     */
+    onMove: (request: BoardMoveRequest) => void;
+    /** Selection is board state because bulk atomicity is a board concern. */
+    selection?: {
+        selected: readonly BoardItemId[];
+        onChange: (selected: readonly BoardItemId[]) => void;
+    };
+}

package/dist/types/lib/board/use-board.d.ts

@@ -0,0 +1,47 @@
+/**
+ * ==== USE BOARD ====
+ *
+ * The React binding over the two pure modules. Deliberately thin: every claim
+ * this hook makes has already been proven in model.ts and move.ts without a
+ * browser, so the only thing left for React-specific code to get wrong is
+ * memoisation and the selection wiring — logic that lived INSIDE a hook
+ * instead of a pure function would be logic no test in board-core.test.ts
+ * could reach without mounting a component. `renderHook` here exists only to
+ * prove the composition wires up, not to re-prove validation or bulk
+ * atomicity, which are already pinned in the pure-module tests.
+ *
+ * `requestMove` IS THE SINGLE FUNNEL. Pointer drag's `onDragEnd`, a keyboard
+ * handler, the mandatory "Move to…" menu (WCAG 2.5.7 — see `types.ts`), and a
+ * bulk-selection action all construct a `BoardMoveRequest` and call this ONE
+ * function. It never mutates `items` itself — `UseBoardOptions.onMove` returns
+ * `void` by contract, so the actual next `items` array is the CONSUMER's to
+ * produce, typically via `applyBoardMoves` from `./move`. `requestMove` only
+ * decides whether that consumer callback fires at all, and returns the verdict
+ * synchronously so the caller (e.g. the menu) can show a rejection reason
+ * immediately rather than guessing from a UI that just didn't change.
+ *
+ * SELECTION IS FULLY CONTROLLED, NOT A SECOND SOURCE OF TRUTH. `selection` on
+ * `UseBoardOptions` supplies BOTH `selected` and `onChange` — this hook never
+ * keeps its own copy of which ids are selected, for the same reason `items`
+ * is never copied: a second copy is a copy that can drift. What this hook
+ * "owns" is the BEHAVIOUR built on top of that controlled pair (toggle one,
+ * replace the set, clear) so every input source computes a selection change
+ * the same way, mirroring why `requestMove` exists as a single funnel for
+ * moves rather than one per source.
+ */
+import type { BoardColumnModel, BoardItemId, BoardMoveRequest, BoardMoveVerdict, UseBoardOptions } from "./types";
+export interface UseBoardResult<T> {
+    /** One entry per declared column, in `columns` order, ready to render. */
+    columns: readonly BoardColumnModel<T>[];
+    /** Items whose `getColumnId` matched no declared column. See model.ts. */
+    unassigned: readonly T[];
+    /** The current controlled selection, or `[]` when `selection` was not supplied. */
+    selected: readonly BoardItemId[];
+    /** No-ops when `selection` was not supplied — see the file header. */
+    toggleSelected: (id: BoardItemId) => void;
+    setSelected: (ids: readonly BoardItemId[]) => void;
+    clearSelection: () => void;
+    /** The single funnel every input source calls. See the file header. */
+    requestMove: (request: BoardMoveRequest) => BoardMoveVerdict;
+}
+export declare function useBoard<T>(options: UseBoardOptions<T>): UseBoardResult<T>;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@danxbot/ui",
-  "version": "3.4.3",
+  "version": "3.5.0",
   "type": "module",
   "description": "Danxbot — a domain-agnostic React design system with motion as a first-class primitive.",
   "license": "MIT",
@@ -63,7 +63,8 @@
     "build:types": "tsc -p tsconfig.build.json",
     "build:demo": "vite build",
     "build": "npm run build:lib && npm run build:demo",
-    "verify": "npm run typecheck && npm run test && npm run build && npm run typecheck:previews && npm run audit:previews",
+    "verify": "npm run typecheck && npm run test && npm run build && npm run typecheck:previews && npm run audit:previews && npm run audit:visual-stale",
+    "audit:visual-stale": "node scripts/audit-visual-stale.mjs",
     "preview": "vite preview",
     "preview:built": "vite preview --outDir demo-dist --port 5801 --strictPort",
     "gates": "npm run shoot && npm run a11y && node scripts/shoot-overlays.mjs && npm run probe",

package/dist/types/components/kanban/resolve.d.ts

@@ -1,31 +0,0 @@
-import type { DragEndEvent } from "../../lib/dnd";
-import type { KanbanLane, KanbanMove, KanbanRefusal } from "./types";
-export type KanbanDrop = 
-/** Nothing happened: the card was put back where it came from. */
-{
-    kind: "none";
-} | {
-    kind: "refused";
-    refusal: KanbanRefusal;
-} | {
-    kind: "move";
-    move: KanbanMove;
-};
-export declare function resolveKanbanDrop<T>(lanes: readonly KanbanLane<T>[], event: DragEndEvent): KanbanDrop;
-export interface KanbanDropHandlers {
-    onMove: (move: KanbanMove) => void;
-    onRefuse?: (refusal: KanbanRefusal) => void;
-}
-/**
- * Resolve a drop and hand it to exactly one of the two callbacks.
- *
- * The dispatch is here rather than inline in the component because it is the
- * other half of the same decision, and the half a resolver test cannot see: a
- * board that resolved "refused" correctly and then called `onMove` anyway would
- * keep every test in `resolveKanbanDrop` green while writing the move the
- * refusal was supposed to stop. Found by mutation — the inline version was the
- * one thing in this component nothing failed on.
- *
- * EXACTLY ONE, OR NEITHER. Never both.
- */
-export declare function handleKanbanDrop<T>(lanes: readonly KanbanLane<T>[], event: DragEndEvent, handlers: KanbanDropHandlers): KanbanDrop;