@anchrd/intel-ui 0.18.0 → 0.19.0

package/src/board/board-items/board-items.ts

@@ -1,183 +0,0 @@
-import type { BoardStatus, BoardTask } from "@anchrd/intel-contract";
-import { type BoardTone, labelOf, toneOf } from "@/board/board-status/board-status.ts";
-
-/**
- * One task as a dated thing (anchrd/intel#286).
- *
- * ⚠️ This is THE adapter between a board and every view that arranges by date — the calendar and
- * Gantt (anchrd/intel#293). The shape is deliberately the item model those views already speak
- * (`id`, `name`, `startAt`, `endAt`, `status`), so the second view was a renderer over this list
- * rather than a second reading of `BoardTask`. Two readings would disagree about the one thing that
- * is genuinely subtle here — what a task without a start date spans — and they would disagree
- * quietly, in a picture.
- */
-export interface BoardItem {
-  id: string;
-  name: string;
-  // ⚠️ Both are LOCAL midnight, never UTC. A `BoardTaskDate` is a day and carries no zone by
-  // contract, so `new Date("2026-08-07")` — which JavaScript reads as UTC midnight — would show the
-  // 6th to every reader west of Greenwich. A task due on a day is due on that day for everybody.
-  startAt: Date;
-  endAt: Date;
-  status: { id: string; label: string; tone: BoardTone };
-  // Something it waits for is still open. Carried on the item rather than looked up again by each
-  // view: it is the same question in the calendar, the graph and the card.
-  blocked: boolean;
-  task: BoardTask;
-}
-
-export interface BoardSchedule {
-  items: BoardItem[];
-  /**
-   * The tasks that have no place in a date grid.
-   *
-   * ⚠️ Handed back rather than dropped. A calendar that silently omits everything without a due
-   * date is a calendar that lies about how much work there is — so the view says how many are
-   * missing and where they are instead (the DoD calls this out by name).
-   */
-  undated: BoardTask[];
-}
-
-// A day as the reader's own midnight. Split rather than handed to `new Date(string)` for the reason
-// in `BoardItem.startAt`.
-export function localDay(date: string): Date | null {
-  const parts = /^(\d{4})-(\d{2})-(\d{2})$/.exec(date);
-  if (!parts) return null;
-  const [year, month, day] = [Number(parts[1]), Number(parts[2]), Number(parts[3])];
-  const parsed = new Date(year, month - 1, day);
-  // A `BoardTaskDate` is validated on both sides, so this only catches a real impossibility such as
-  // the 31st of February — which `Date` would roll forward into March rather than refuse.
-  return parsed.getFullYear() === year &&
-    parsed.getMonth() === month - 1 &&
-    parsed.getDate() === day
-    ? parsed
-    : null;
-}
-
-export function sameDay(left: Date, right: Date): boolean {
-  return (
-    left.getFullYear() === right.getFullYear() &&
-    left.getMonth() === right.getMonth() &&
-    left.getDate() === right.getDate()
-  );
-}
-
-/**
- * A day back as the `BoardTaskDate` it is written as — the exact inverse of `localDay`
- * (anchrd/intel#293).
- *
- * ⚠️ Built from the LOCAL components, never from `toISOString()`. That is the same trap as reading a
- * date, in the other direction and with worse consequences: `new Date(2026, 7, 7).toISOString()` is
- * `2026-08-06T22:00:00Z` in Berlin, so a bar dragged onto the 7th would be SAVED as the 6th. Reading
- * it wrong draws the wrong day; writing it wrong stores the wrong day, and every surface then agrees
- * about a date nobody chose.
- *
- * It exists because Gantt writes dates back and the calendar only reads them. One pair of functions
- * in one place, so the two directions cannot disagree about what a day is.
- */
-export function dayValue(day: Date): string {
-  const month = String(day.getMonth() + 1).padStart(2, "0");
-  const date = String(day.getDate()).padStart(2, "0");
-  return `${day.getFullYear()}-${month}-${date}`;
-}
-
-/**
- * The same day, a whole number of days later or earlier.
- *
- * ⚠️ Calendar arithmetic, not milliseconds. `time + 86_400_000` is 23 or 25 hours across a DST
- * boundary, which lands the result on the previous day at 23:00 or the next at 01:00 — and a board
- * whose dates shift by one on the last Sunday in March is a board nobody would trust again. `Date`
- * normalises an out-of-range day (the 32nd of August is the 1st of September), so this needs no
- * month handling of its own.
- */
-export function addDays(day: Date, count: number): Date {
-  return new Date(day.getFullYear(), day.getMonth(), day.getDate() + count);
-}
-
-/**
- * How many days lie between two days, as a whole number.
- *
- * ⚠️ Compared as UTC noon-free day numbers rather than by subtracting local times, for the DST
- * reason above: the difference between two local midnights is not always a multiple of 24 hours, and
- * a `Math.round` over that is right until the one week of the year it is not.
- */
-export function daysBetween(from: Date, to: Date): number {
-  const left = Date.UTC(from.getFullYear(), from.getMonth(), from.getDate());
-  const right = Date.UTC(to.getFullYear(), to.getMonth(), to.getDate());
-  return Math.round((right - left) / 86_400_000);
-}
-
-/**
- * Which task each task hangs under, once the list has been cut down.
- *
- * ⚠️ A task whose parent is not in the list becomes a ROOT rather than disappearing, and that is the
- * whole reason this exists. Hiding the shelf hides archived tasks; an archived epic with two live
- * tasks under it must not take them off the screen with it. The hierarchy is a fact about the board,
- * what is shown is a question the reader asked, and the second must not silently answer the first.
- *
- * ⚠️ A chain that comes back to where it started is broken here, at the task that closes it. The
- * write path refuses a cycle (#285), so this cannot be reached from a board Intel wrote — but the
- * cost of being wrong about that is not a wrong picture, it is a walk that recurses until the tab
- * dies. Depth is capped at five, so the walk is bounded anyway.
- *
- * ⚠️ It lives HERE, beside the dated reading, because the table and Gantt both need it
- * (anchrd/intel#293). Two copies of a rule with two subtleties in it are two copies that drift, and
- * the drift would show up as a task that is a root in one view and a child in the other.
- */
-export function rootedParents(tasks: BoardTask[]): Map<string, string | null> {
-  const byId = new Map(tasks.map((task) => [task.id, task]));
-  const parents = new Map<string, string | null>();
-  for (const task of tasks) {
-    const direct = task.parentId !== null && byId.has(task.parentId) ? task.parentId : null;
-    let cursor = direct;
-    const seen = new Set([task.id]);
-    while (cursor !== null && !seen.has(cursor)) {
-      seen.add(cursor);
-      const next = byId.get(cursor)?.parentId ?? null;
-      cursor = next !== null && byId.has(next) ? next : null;
-    }
-    parents.set(task.id, cursor === null ? direct : null);
-  }
-  return parents;
-}
-
-/**
- * The board as a list of dated items, and the tasks that are not one.
- *
- * ⚠️ `dueDate` is what makes a task an item — a start date alone does not. A bar has to end
- * somewhere, and a task that has only begun would either be drawn to today (a date nobody entered)
- * or to forever. `startDate` therefore only ever shortens or lengthens the span; without one, the
- * item is the single day it is due on.
- */
-export function boardSchedule(
-  tasks: BoardTask[],
-  statuses: BoardStatus[],
-  blockedBy: (task: BoardTask) => BoardTask[],
-): BoardSchedule {
-  const items: BoardItem[] = [];
-  const undated: BoardTask[] = [];
-  for (const task of tasks) {
-    const end = task.dueDate === null ? null : localDay(task.dueDate);
-    if (end === null) {
-      undated.push(task);
-      continue;
-    }
-    const start = task.startDate === null ? null : localDay(task.startDate);
-    items.push({
-      id: task.id,
-      name: task.title,
-      // A start after the due date is a board somebody typed wrong, not a bar drawn backwards. The
-      // due date wins because it is the one the calendar files the task under.
-      startAt: start !== null && start <= end ? start : end,
-      endAt: end,
-      status: {
-        id: task.status,
-        label: labelOf(task.status, statuses),
-        tone: toneOf(task.status, statuses),
-      },
-      blocked: blockedBy(task).length > 0,
-      task,
-    });
-  }
-  return { items, undated };
-}

package/src/board/board-kanban/board-kanban.ts

@@ -1,137 +0,0 @@
-import type { BoardTask } from "@anchrd/intel-contract";
-import type { MoveTask } from "@/board/board-data/board-data.types.ts";
-import type { KanbanDrop } from "@/components/ui/kanban.tsx";
-
-/**
- * What a drop DID: the one `board_task_move` it is worth, or the reason there is none.
- *
- * ⚠️ Three answers rather than a move or a `null`, and the third one is the whole of
- * anchrd/intel#345. Two of the ways a drag ends write nothing, and they are not the same event to
- * whoever is being told about it: a card let go on its own place stayed put, and a card let go over
- * a lane the board cannot write into was REFUSED. Announced as one — or, as it was, announced as a
- * move that never happened — the difference is exactly the one a reader needs, because since
- * anchrd/intel#315 the announcement is the only feedback the keyboard path has.
- */
-export type DropOutcome =
-  // ⚠️ `status` is optional on the wire — a move may be a reparent and name no column — but a drop
-  // always lands in a lane and always names it. Narrowed here so the sentence a reader hears can
-  // name the lane the card really went into rather than the one the pointer was last over.
-  | { kind: "move"; move: MoveTask & { status: string } }
-  // The status the drop resolved to: drawn by the board, and not one it may write into. Carried
-  // rather than looked up again, so the sentence a reader hears names the lane that said no.
-  | { kind: "refused"; status: string }
-  // Nothing to write and nothing refused: the card ends where it began, or it was let go over
-  // something the board does not draw.
-  | { kind: "unchanged" };
-
-/**
- * ⚠️ Neighbours, never an index. The server mints the fractional key between the two tasks named
- * here (#285), so one drag writes one task and renumbers nothing — the reason a board is addressed
- * by task id and not by position at all. A UI that sent a position would have to send the whole
- * column with it to be unambiguous.
- *
- * ⚠️ Nothing to write for a drag that changed nothing, and that is half the point of this function.
- * dnd-kit reports a drop wherever the pointer was let go, including back on the card's own place;
- * sending a move for that would write a version, bump the board and show up in the audit as work
- * that did not happen.
- *
- * `lanes` is what the board DRAWS — root tasks per column, in order. Subtasks are not lane cards
- * (they are a counter on their parent), so they are not in it and cannot be dropped on either.
- */
-export function dropOutcome(
-  drop: KanbanDrop,
-  lanes: Map<string, BoardTask[]>,
-  byId: Map<string, BoardTask>,
-  // The statuses the board actually lists. ⚠️ Not the same as the lanes: a lane is also drawn for a
-  // status the board no longer has, so that the cards left in it stay visible — and that lane must
-  // not be somewhere a card can be MOVED. The server refuses a task in a status the board does not
-  // have, so a drop there would be a refusal, an invalidation and no word to the reader.
-  writable: ReadonlySet<string>,
-): DropOutcome {
-  const active = byId.get(drop.activeId);
-  // ⚠️ Let go over itself is the commonest drag of all — a click that travelled five pixels — and
-  // it has to be nothing before any of the arithmetic below runs. Read as "dropped on a card", it
-  // would compute a landing place for a card that never left, which is the shape of a write that
-  // says work happened.
-  //
-  // ⚠️ And it is `unchanged` even when the card stands in a lane that cannot be written into: what
-  // happened there is that a card came back to its own place, not that a lane turned a card away.
-  if (drop.overId === null || drop.overId === drop.activeId || active === undefined)
-    return { kind: "unchanged" };
-
-  // The drop landed either on a column's empty space — then its id is the status — or on a card,
-  // and then the column is that card's. A card the board does not draw (a subtask, or one filtered
-  // away) resolves to neither and the drag is a no-op rather than a guess.
-  const overTask = byId.get(drop.overId);
-  const status = overTask?.status ?? (lanes.has(drop.overId) ? drop.overId : null);
-  if (status === null) return { kind: "unchanged" };
-
-  const lane = lanes.get(status) ?? [];
-  // ⚠️ "Is this a card the board draws" is read BEFORE the refusal, and the order is the whole of
-  // it. `byId` holds subtasks too — they are counters on their parent, not lane cards — and one of
-  // them left in a status the board no longer lists resolves to a status without ever standing in
-  // that lane. Refused first, such a drop would be announced as a lane turning the card away while
-  // no lane was involved at all. Nothing renders a subtask as a droppable today; this is a guard on
-  // the order, so that the day one does, the sentence does not start lying.
-  if (overTask !== undefined && !lane.some((task) => task.id === overTask.id))
-    return { kind: "unchanged" };
-  // ⚠️ Refused BEFORE the request, and said so. The lane is drawn and its cards are still sortables,
-  // so a drop lands here on both the pointer path and the keyboard one; the server would answer a
-  // task in a status the board does not have with a refusal.
-  if (!writable.has(status)) return { kind: "refused", status };
-
-  const from = lane.findIndex((task) => task.id === active.id);
-  const rest = lane.filter((task) => task.id !== active.id);
-
-  let landing: number;
-  if (overTask === undefined) {
-    // Let go over the column rather than over a card: the end of it.
-    landing = rest.length;
-  } else {
-    // In the lane (checked above) and not the active card (checked at the top), so it is in `rest`.
-    const overIndex = rest.findIndex((task) => task.id === overTask.id);
-    // Dragged downwards inside its own column, the card takes the place BELOW the one it was let go
-    // over — the same reading `arrayMove` has, and the one the pointer suggests. Every other case
-    // puts it above.
-    const overInLane = lane.findIndex((task) => task.id === overTask.id);
-    landing = from !== -1 && from < overInLane ? overIndex + 1 : overIndex;
-  }
-
-  // Re-inserting where it came from is the arrangement it already had.
-  if (from !== -1 && landing === from) return { kind: "unchanged" };
-
-  return {
-    kind: "move",
-    move: {
-      taskId: active.id,
-      status,
-      afterTaskId: rest[landing - 1]?.id ?? null,
-      beforeTaskId: rest[landing]?.id ?? null,
-    },
-  };
-}
-
-/**
- * How much of a task's subtree is finished — the counter a card carries instead of its children.
- *
- * ⚠️ The whole subtree, not the direct children. A card that says "1/2" while three of the four
- * things under it are open would be worse than no counter: the number would be true of a level
- * nobody is looking at.
- */
-export function subtaskCount(
-  taskId: string,
-  childrenOf: Map<string, BoardTask[]>,
-  settled: (task: BoardTask) => boolean,
-): { done: number; total: number } {
-  let done = 0;
-  let total = 0;
-  const walk = (id: string) => {
-    for (const child of childrenOf.get(id) ?? []) {
-      total += 1;
-      if (settled(child)) done += 1;
-      walk(child.id);
-    }
-  };
-  walk(taskId);
-  return { done, total };
-}

package/src/board/board-kanban/board-kanban.tsx

@@ -1,257 +0,0 @@
-import { ArchivedBoardStatusId, type BoardTask } from "@anchrd/intel-contract";
-import { useMemo } from "react";
-import { BoardCardBody } from "@/board/board-card/board-card.tsx";
-import { visibleStatuses } from "@/board/board-data/board-data.ts";
-import { labelOf, toneOf } from "@/board/board-status/board-status.ts";
-import type { BoardViewProps } from "@/board/board-views/board-views.types.ts";
-import {
-  KanbanBoard,
-  KanbanCard,
-  KanbanCards,
-  KanbanHeader,
-  KanbanProvider,
-} from "@/components/ui/kanban.tsx";
-import { useI18n } from "@/i18n/i18n-context.tsx";
-import { dropOutcome, subtaskCount } from "./board-kanban.ts";
-
-/**
- * The board as lanes (anchrd/intel#286).
- *
- * ⚠️ Lanes are the board's `statuses` in their own order — not a list this view keeps. Renaming a
- * column in `board_configure` renames the lane, and the id under it never moves, so no task has to
- * be rewritten to follow.
- *
- * ⚠️ Only root tasks are cards. A subtask is a counter on its parent (`subtaskCount`); drawing it
- * as a lane card as well would put one piece of work on the board twice, once inside its parent and
- * once beside it. The whole hierarchy is the table's job and the detail panel's.
- */
-export function BoardKanban({ board, select, showArchived }: BoardViewProps) {
-  const i18n = useI18n();
-
-  const columns = useMemo(() => {
-    // ⚠️ `archived` is not a lane by default and is not a stage either — it is the shelf a task
-    // is swept onto, and a board that shows it always spends a fifth of its width on work
-    // somebody has finished with. The switch that brings it back is in the bar above.
-    /**
-     * ⚠️ One lane per status id, however often the list names it (anchrd/intel#321).
-     *
-     * Two lanes under one id is the half of that ticket that does not throw, which is what makes it
-     * the worse half: `lanes.get(column.id)` answers both of them with the same cards, so the same
-     * work stands in two columns, `useDroppable` registers one id twice and a drop has two targets
-     * that are one — a screen that looks like it is working. The bundle import refuses such a
-     * document now; a board imported before it is still stored as it was written, and the first
-     * mention is the lane to keep because it is the one `labelOf` and `toneOf` already answer with
-     * — a lane drawn under the second label would have carried the first one's colour.
-     */
-    const seen = new Set<string>();
-    const listed = (showArchived ? board.statuses : visibleStatuses(board.statuses))
-      .filter((status) => {
-        if (seen.has(status.id)) return false;
-        seen.add(status.id);
-        return true;
-      })
-      .map((status) => ({ id: status.id, name: status.label }));
-    /**
-     * ⚠️ And a lane at the end for every status a task still stands in that the board no longer
-     * lists.
-     *
-     * Configuring a column away does not rewrite the tasks that were in it (#285), so this is
-     * reachable — through `board_configure` over MCP, which has no dialog stopping it. Without the
-     * extra lane those cards would be in `board.tasks`, counted in the title line, and drawn
-     * nowhere: gone from the one view a board is opened for, with nothing saying so. The other
-     * others already keep them (`orderedTasks` sorts them last, `labelOf` falls back to the raw
-     * id), and no two views may disagree about what is on the board.
-     */
-    const known = new Set(listed.map((column) => column.id));
-    const stray = new Set(
-      board.tasks
-        .filter((task) => task.parentId === null && !known.has(task.status))
-        .filter((task) => showArchived || task.status !== ArchivedBoardStatusId)
-        .map((task) => task.status),
-    );
-    return [
-      ...listed.map((column) => ({ ...column, writable: true })),
-      // ⚠️ Drawn, never written into. The server refuses a task in a status the board does not have,
-      // so a card dropped here would be a refusal, an invalidation and nothing said to the reader.
-      // The lane is a place work is VISIBLE, not a place it can be put.
-      ...[...stray].map((id) => ({ id, name: labelOf(id, board.statuses), writable: false })),
-    ];
-  }, [board.statuses, board.tasks, showArchived]);
-
-  const writable = useMemo(
-    () => new Set(columns.filter((column) => column.writable).map((column) => column.id)),
-    [columns],
-  );
-
-  const lanes = useMemo(() => {
-    const byStatus = new Map<string, BoardTask[]>();
-    for (const column of columns) byStatus.set(column.id, []);
-    for (const task of board.tasks) {
-      if (task.parentId !== null) continue;
-      byStatus.get(task.status)?.push(task);
-    }
-    return byStatus;
-  }, [board.tasks, columns]);
-
-  const itemsByColumn = useMemo(
-    () => new Map([...lanes].map(([status, tasks]) => [status, tasks.map((task) => task.id)])),
-    [lanes],
-  );
-
-  /**
-   * What a finished drag is announced as — and it is the OUTCOME that is announced, not what the
-   * pointer was last over (anchrd/intel#345).
-   *
-   * ⚠️ Asked of the same function the write is asked of, which is the point: a second reading of a
-   * drop would be a second opinion about it, and the one a reader hears would be the one nothing
-   * checks. Two of the three answers write nothing, and each says so in its own words — a lane that
-   * cannot take the card names itself, and a card that came back to its own place says it stayed.
-   * Announced as "dropped into X" (which is what all three used to say), a keyboard user who never
-   * sees the card jump has nothing to correct it with.
-   */
-  const dropped = (activeId: string, overId: string | null) => {
-    const active = board.byId.get(activeId);
-    const task = active?.title ?? "";
-    const from = columnName(active?.status ?? "", columns);
-    const outcome = dropOutcome({ activeId, overId }, lanes, board.byId, writable);
-    if (outcome.kind === "move")
-      return i18n.t("board.dnd.end", { task, lane: columnName(outcome.move.status, columns) });
-    if (outcome.kind === "refused")
-      return i18n.t("board.dnd.endRefused", {
-        task,
-        lane: columnName(outcome.status, columns),
-        from,
-      });
-    return i18n.t("board.dnd.endUnchanged", { task, lane: from });
-  };
-
-  const card = (task: BoardTask) => (
-    <BoardCardBody
-      task={task}
-      statusLabel={labelOf(task.status, board.statuses)}
-      toneDot={toneOf(task.status, board.statuses).dot}
-      blocked={board.blockedBy(task).length > 0}
-      subtasks={subtaskCount(task.id, board.childrenOf, board.settled)}
-    />
-  );
-
-  return (
-    <div className="min-h-0 flex-1 overflow-x-auto p-6">
-      <KanbanProvider
-        columns={columns}
-        itemsByColumn={itemsByColumn}
-        className="min-w-max"
-        announcements={{
-          onDragStart: ({ active }) =>
-            i18n.t("board.dnd.start", { task: board.byId.get(String(active.id))?.title ?? "" }),
-          onDragOver: ({ active, over }) =>
-            i18n.t("board.dnd.over", {
-              task: board.byId.get(String(active.id))?.title ?? "",
-              lane: over === null ? "" : laneName(String(over.id), board, columns),
-            }),
-          onDragEnd: ({ active, over }) =>
-            dropped(String(active.id), over === null ? null : String(over.id)),
-          onDragCancel: ({ active }) =>
-            i18n.t("board.dnd.cancel", { task: board.byId.get(String(active.id))?.title ?? "" }),
-        }}
-        instructions={i18n.t("board.dnd.instructions")}
-        overlay={(activeId) => {
-          const task = board.byId.get(activeId);
-          return task ? (
-            <div
-              data-slot="board-card-overlay"
-              className="w-72 rounded-lg border bg-card p-3 shadow-lg ring-2 ring-ring"
-            >
-              {card(task)}
-            </div>
-          ) : null;
-        }}
-        // ⚠️ Exactly one write per drag, and only when the card actually went somewhere.
-        // `dropOutcome` answers with something other than a move for a drop back onto its own place
-        // and for a lane the board cannot write into, and the mutation names the NEIGHBOURS rather
-        // than an index — the server mints the order key between them, so one drag writes one task
-        // and the other cards are not touched (#285). The same answer is what the reader is told
-        // about (anchrd/intel#345), so the sentence and the write can never drift apart.
-        onDrop={(drop) => {
-          const outcome = dropOutcome(drop, lanes, board.byId, writable);
-          if (outcome.kind === "move") board.move.mutate(outcome.move);
-        }}
-      >
-        {(column) => (
-          <KanbanBoard
-            id={column.id}
-            // ⚠️ Read back off the list rather than off the argument: `KanbanProvider` hands its
-            // children a `KanbanColumn`, which is an id and a name — the primitive has no business
-            // knowing which of a board's columns may be written to.
-            droppable={columns.find((entry) => entry.id === column.id)?.writable !== false}
-            className="w-72 shrink-0"
-          >
-            <KanbanHeader>
-              <span
-                aria-hidden="true"
-                className={`size-2 rounded-full ${toneOf(column.id, board.statuses).dot}`}
-              />
-              <span className="min-w-0 truncate">{column.name}</span>
-              <span className="ml-auto text-xs font-normal text-muted-foreground tabular-nums">
-                {lanes.get(column.id)?.length ?? 0}
-              </span>
-            </KanbanHeader>
-            <KanbanCards id={column.id}>
-              {(lanes.get(column.id) ?? []).map((task) => (
-                <KanbanCard
-                  key={task.id}
-                  id={task.id}
-                  roleDescription={i18n.t("board.card.roleDescription")}
-                >
-                  {/* ⚠️ ONE control per card, and it means two things — click or Enter opens the
-                      task, Space picks it up to be moved by the arrow keys (anchrd/intel#315).
-                      `control` is what makes the second half true: it carries dnd-kit's activator
-                      ref, so the keyboard sensor accepts a key press here and nowhere else in the
-                      card, and the `aria-roledescription`/`aria-describedby` that say so.
-
-                      The pointer sensor's four-pixel threshold is what keeps a click from counting
-                      as a drag of nothing. */}
-                  {({ ref, ...control }) => (
-                    <button
-                      type="button"
-                      ref={ref}
-                      {...control}
-                      className="w-full rounded text-left outline-none focus-visible:ring-2 focus-visible:ring-ring"
-                      onClick={() => select(task.id)}
-                    >
-                      {card(task)}
-                    </button>
-                  )}
-                </KanbanCard>
-              ))}
-              {(lanes.get(column.id) ?? []).length === 0 ? (
-                <p className="px-1 py-2 text-xs text-muted-foreground">
-                  {column.id === ArchivedBoardStatusId
-                    ? i18n.t("board.archivedEmpty")
-                    : i18n.t("board.laneEmpty")}
-                </p>
-              ) : null}
-            </KanbanCards>
-          </KanbanBoard>
-        )}
-      </KanbanProvider>
-    </div>
-  );
-}
-
-// What stands over a lane: the column's name, and the raw status id for a lane the board no longer
-// lists — the same fallback `labelOf` makes, so one status is not called two things on one screen.
-function columnName(statusId: string, columns: { id: string; name: string }[]): string {
-  return columns.find((column) => column.id === statusId)?.name ?? statusId;
-}
-
-// What a drag is currently OVER, read as a lane: a card answers with its own lane, a column with
-// itself. Only the running commentary needs this — what a finished drag is announced as comes from
-// the outcome, not from the thing under the pointer (anchrd/intel#345).
-function laneName(
-  overId: string,
-  board: BoardViewProps["board"],
-  columns: { id: string; name: string }[],
-): string {
-  return columnName(board.byId.get(overId)?.status ?? overId, columns);
-}

package/src/board/board-status/board-status.ts

@@ -1,59 +0,0 @@
-import { ArchivedBoardStatusId, type BoardStatus } from "@anchrd/intel-contract";
-
-/**
- * How a status looks, in the three places a colour has to be spelled differently.
- *
- * `token` is the CSS variable name rather than a value, because Sigma paints to a canvas and cannot
- * read a class (`resolveGraphColor` turns it into sRGB there). `dot` and `chip` are Tailwind
- * classes for everything that is drawn in the DOM.
- */
-export interface BoardTone {
-  token: string;
-  dot: string;
-  chip: string;
-}
-
-// ⚠️ Written out rather than built from a template string. Tailwind reads the source to decide
-// which classes to emit, and a class assembled at runtime — `bg-board-status-${n}` — is a class it
-// never sees and therefore never generates. The board would then be uncoloured in the production
-// build and correct in dev, which is the worst shape a bug can have.
-const Ramp: readonly BoardTone[] = [
-  { token: "--board-status-1", dot: "bg-board-status-1", chip: "border-board-status-1" },
-  { token: "--board-status-2", dot: "bg-board-status-2", chip: "border-board-status-2" },
-  { token: "--board-status-3", dot: "bg-board-status-3", chip: "border-board-status-3" },
-  { token: "--board-status-4", dot: "bg-board-status-4", chip: "border-board-status-4" },
-  { token: "--board-status-5", dot: "bg-board-status-5", chip: "border-board-status-5" },
-  { token: "--board-status-6", dot: "bg-board-status-6", chip: "border-board-status-6" },
-];
-
-// The shelf, and everything the board no longer has a column for. Both are "not a stage", and both
-// have to read as background rather than as one more colour competing with the stages.
-const Shelved: BoardTone = {
-  token: "--muted-foreground",
-  dot: "bg-muted-foreground",
-  chip: "border-border",
-};
-
-/**
- * The colour a status is drawn in.
- *
- * ⚠️ By POSITION in the board's own list, not by id. A status list is configured per board, so
- * `done` is no more a colour than "the fourth column" is a name — and a board that renames a column
- * must not have its whole ramp shift underneath it. Positions count the working columns only, so
- * moving `archived` around in the list cannot recolour everything after it.
- */
-export function toneOf(statusId: string, statuses: BoardStatus[]): BoardTone {
-  if (statusId === ArchivedBoardStatusId) return Shelved;
-  const position = statuses
-    .filter((status) => status.id !== ArchivedBoardStatusId)
-    .findIndex((status) => status.id === statusId);
-  if (position === -1) return Shelved;
-  return Ramp[position % Ramp.length] ?? Shelved;
-}
-
-// The label a reader sees. A task can hold a status the board no longer lists — configuring a
-// column away does not rewrite the tasks that stood in it — and the raw id is then the only honest
-// answer: it says which column is missing instead of pretending the task has none.
-export function labelOf(statusId: string, statuses: BoardStatus[]): string {
-  return statuses.find((status) => status.id === statusId)?.label ?? statusId;
-}