cursedbelt 2.7.0 → 3.0.0

package/src/core/file-tree/fileTreeModel.ts

@@ -1,511 +0,0 @@
-/**
- * The arithmetic behind `react/file-tree` — what is in the tree, what is on screen, and
- * which drops are legal. No DOM, so all of it is unit-tested; the pointer handling, the
- * markers and the keyboard live in the component and are not.
- *
- * ── Where this came from, and why it is here rather than in an app ──────────────────────
- * Owner, 2026-09-08: *"the spreadsheet app has a much better file tree sidebar than
- * collections has. Add the file tree viewer from it into cb so apps like collections can
- * use it."* `cursed-embeddable-spreadsheet`'s `FileTree` is the tree he means — it has been
- * carrying that app's whole navigation for weeks. What made it good is mostly in this file:
- * a drop that cannot happen is never OFFERED, so there is no marker, no highlight and no
- * error toast after the fact — the cursor simply says no while the row is still in the air.
- *
- * ── 🔴 Why this is not `core/folder-tree` ──────────────────────────────────────────────
- * `folder-tree` derives a hierarchy from delimited PATH STRINGS that items carry, and its
- * nodes are the result of that derivation. This models a tree that already exists, whatever
- * produced it: a node has an id, a kind and children, and an app may hand over folders
- * derived from paths (collections), rows from a table, or a mix of both under one root. The
- * two are complementary — collections feeds `buildFolderTree`'s output straight into this —
- * and collapsing them would force every consumer of one to adopt the other's storage shape.
- */
-
-/** What a row IS. `folder` may hold children and accept drops; `file` is a leaf. */
-export type FileTreeNodeKind = 'folder' | 'file';
-
-/**
- * How visible a node is, generalised from collections' private/locked folders.
- *
- * 🔴 It is a LABEL, never an enforcement. The server decides what a session may see, and a
- * tree that hides a row the server sent (or shows one it did not) is a second, weaker
- * opinion about access that will disagree with the first. collections' server already omits
- * what a locked session may not see — see `albums.ts:folderTree` — so a `private` row here
- * means "you are unlocked and this is one of the protected ones", which is a thing to MARK.
- */
-export type FileTreeAccess = 'normal' | 'private' | 'locked';
-
-export interface FileTreeNode {
-  /** Stable across re-derivation — it is the React key, the selection value and the drag id. */
-  id: string;
-  name: string;
-  kind: FileTreeNodeKind;
-  /** Folders only. A folder with `[]` is empty; a file's is ignored. */
-  children?: readonly FileTreeNode[];
-  /**
-   * Whether this folder draws a twisty. **Default `true` for every folder**, empty ones
-   * included — pass `false` only for a row that is a folder in name and can never hold
-   * anything.
-   *
-   * 🔴 2026-09-11, the owner: *"Make them use an arrow icon next to a dir even when the dir
-   * is empty."* It used to default to `children.length > 0`, and that was wrong twice over.
-   * For a LAZY tree it is a trap door — a consumer that fetches a row's contents only while
-   * it is open produces a collapsed row with no children, which loses its caret and can
-   * never be reopened (`apps/collections` hit exactly that, and had to pass this flag to get
-   * out of it). And for an EAGER tree it makes an empty folder look like a file: the arrow
-   * is the only thing on the row that says "this is a place", so a folder you have not put
-   * anything in yet is drawn as a leaf until the moment it stops being empty.
-   *
-   * VS Code draws the chevron on every folder and opens an empty one onto nothing, which is
-   * what this now matches.
-   */
-  expandable?: boolean;
-  /**
-   * A picture of THIS row's contents, drawn in the glyph box in place of its type icon.
-   *
-   * 🔴 2026-09-11, the owner: *"For media files show a thumbnail instead of the file type
-   * icon to the left of the name."* A folder of photographs is a list of rows whose type
-   * icons are all identical, so the glyph column says nothing at all — the thumbnail is the
-   * only thing in the row that distinguishes one picture from the next before you open it.
-   *
-   * It takes the SAME 16px box the type icon uses rather than growing the row: the row's
-   * height is pinned to the glyph by `fleet/standards/file-tree-geometry.json`, and a tree
-   * whose rows change height per file is one you cannot scan. A thumbnail that 404s falls
-   * back to the type icon exactly once — see `FileTree`'s `RowGlyph`. Omit it for anything
-   * that has no picture, and never point it at the full-size object: this is a 16px box, and
-   * a tree of 200 rows pointed at originals is 200 full downloads.
-   */
-  thumbnailUrl?: string;
-  /** Badge on the row — usually "everything at or under here". Omit for none. */
-  count?: number;
-  access?: FileTreeAccess;
-  /**
-   * Refuse drops INTO this node even though it is a folder.
-   *
-   * The consumer's veto, for a rule the tree cannot know: collections uses it so a folder
-   * cannot be dragged across album boundaries, which the server has no route for. Defaults
-   * to true for folders and is meaningless for files.
-   */
-  acceptsDrop?: boolean;
-  /**
-   * Whether this row can be picked up. Default true once `onMove` is wired.
-   *
-   * Not every row in a tree is a thing you can move: collections puts its ALBUMS at the top
-   * level, and albums have no order and no parent to be moved into. A row that cannot go
-   * anywhere must not start a drag — otherwise the gesture begins, follows the cursor, and
-   * refuses everywhere, which reads as a broken tree rather than a fixed one.
-   */
-  draggable?: boolean;
-  /** Whatever the consumer needs back in a callback. Never read here. */
-  meta?: unknown;
-}
-
-/** Where a drag would put the thing it is carrying. */
-export type FileTreeDrop =
-  | { kind: 'into'; parentId: string }
-  /**
-   * Out of every folder, at the top of the tree.
-   *
-   * The blank space under the last row is what expresses "get this out of here" — the
-   * gesture every file explorer has and the only one that does not need a target row.
-   */
-  | { kind: 'root' }
-  /** Between two rows, when the consumer stores an order. See {@link ResolveDropOptions}. */
-  | { kind: 'before'; siblingId: string; parentId: string | null }
-  | { kind: 'after'; siblingId: string; parentId: string | null };
-
-/** A pointer position resolved against the tree: a target, or a refusal with words. */
-export interface DropOffer {
-  target: FileTreeDrop | null;
-  refused: boolean;
-  /**
-   * Why, in words, when it is refused.
-   *
-   * `DESIGN.md`'s law: a control that cannot do a thing says so. A drop that is silently
-   * ignored reads as a broken app rather than a refused one.
-   */
-  reason: string | null;
-}
-
-/** One row as drawn, top to bottom. */
-export interface FileTreeRow {
-  node: FileTreeNode;
-  /** How far in it is drawn — 0 at the top level. */
-  depth: number;
-  parentId: string | null;
-  /** Its position among its own siblings, which is what a keyboard move needs. */
-  index: number;
-  /** True when it is a folder with children (so it gets a twisty). */
-  expandable: boolean;
-  expanded: boolean;
-}
-
-const childrenOf = (node: FileTreeNode): readonly FileTreeNode[] =>
-  node.kind === 'folder' ? (node.children ?? []) : [];
-
-/** Every node in the tree, depth-first — the order the rows would be in fully expanded. */
-export function walkFileTree(nodes: readonly FileTreeNode[]): FileTreeNode[] {
-  const out: FileTreeNode[] = [];
-  const visit = (list: readonly FileTreeNode[]): void => {
-    for (const node of list) {
-      out.push(node);
-      visit(childrenOf(node));
-    }
-  };
-  visit(nodes);
-  return out;
-}
-
-export function findFileTreeNode(
-  nodes: readonly FileTreeNode[],
-  id: string,
-): FileTreeNode | null {
-  for (const node of walkFileTree(nodes)) if (node.id === id) return node;
-  return null;
-}
-
-/**
- * The rows actually on screen, given which folders are shut.
- *
- * 🔴 `collapsed` is the exception list, not `expanded`. A tree derived fresh from the server
- * on every refresh gets new nodes constantly, and an expanded-set model shows each of them
- * shut — so a newly created folder would appear closed and empty at the moment its contents
- * are the thing you are looking for. The exception list defaults everything open, which is
- * also what reads best for the small trees these sidebars hold.
- */
-export function flattenFileTree(
-  nodes: readonly FileTreeNode[],
-  collapsed: Iterable<string>,
-): FileTreeRow[] {
-  const shut = new Set(collapsed);
-  const out: FileTreeRow[] = [];
-  const visit = (list: readonly FileTreeNode[], depth: number, parentId: string | null): void => {
-    list.forEach((node, index) => {
-      const kids = childrenOf(node);
-      /*
-       * 🔴 EVERY folder is expandable unless it says otherwise (2026-09-11).
-       *
-       * Owner: *"Make them use an arrow icon next to a dir even when the dir is empty."*
-       * This was `kids.length > 0` and it was wrong in both directions. For a LAZY tree it
-       * is a trap door — a consumer that loads a row's contents only while it is open gives
-       * a collapsed row no children, the row loses its twisty, and it can never be opened
-       * again (measured in `apps/collections`, whose sidebar fetches one folder's files at a
-       * time). For an EAGER tree it draws an empty folder as a leaf, so the one mark that
-       * distinguishes a place from a file disappears exactly while the folder is new and
-       * being filled.
-       *
-       * "A row that claims to open onto nothing is its own small lie" was the old reasoning
-       * and it is answered by what VS Code does: the chevron says *folder*, not *occupied*,
-       * and opening an empty one onto nothing is the honest answer, not a broken promise.
-       * `node.expandable === false` is still honoured for a row that can never hold anything.
-       */
-      const expandable = node.kind === 'folder' && (node.expandable ?? true);
-      const expanded = expandable && !shut.has(node.id);
-      out.push({ node, depth, parentId, index, expandable, expanded });
-      if (expanded) visit(kids, depth + 1, node.id);
-    });
-  };
-  visit(nodes, 0, null);
-  return out;
-}
-
-/** `id` and everything under it — the set a drag may not land inside. */
-export function descendantIdsOf(nodes: readonly FileTreeNode[], id: string): Set<string> {
-  const node = findFileTreeNode(nodes, id);
-  const out = new Set<string>();
-  if (!node) return out;
-  const visit = (n: FileTreeNode): void => {
-    out.add(n.id);
-    for (const child of childrenOf(n)) visit(child);
-  };
-  visit(node);
-  return out;
-}
-
-/**
- * The id of the folder a node sits in — `null` at the top level, and `null` for a node this
- * tree does not contain.
- *
- * 🔴 The two nulls are deliberately one answer. Every caller is asking "where would a move
- * put this", and for a row the tree no longer holds the honest answer is the top level
- * rather than a throw: a tree re-derived from the server between the press and the release
- * can genuinely lose the row under the pointer.
- */
-export function parentIdOf(nodes: readonly FileTreeNode[], id: string): string | null {
-  const visit = (
-    list: readonly FileTreeNode[],
-    parent: string | null,
-  ): { at: string | null } | null => {
-    for (const node of list) {
-      if (node.id === id) return { at: parent };
-      const found = visit(childrenOf(node), node.id);
-      if (found) return found;
-    }
-    return null;
-  };
-  return visit(nodes, null)?.at ?? null;
-}
-
-/** The share of a folder row's height that means "into" rather than "between". */
-export const INTO_ZONE = 0.5;
-
-export interface ResolveDropOptions {
-  nodes: readonly FileTreeNode[];
-  /** The row under the pointer, or null over blank space below the tree. */
-  row: FileTreeRow | null;
-  /** How far down that row the pointer is, 0 at its top edge and 1 at its bottom. */
-  offsetRatio: number;
-  /** What is being dragged — a node id from this tree, or null for an external payload. */
-  dragId: string | null;
-  /**
-   * Whether the consumer stores a sibling ORDER.
-   *
-   * 🔴 Off by default, and collections is why. Its folders are DERIVED from the paths its
-   * files carry and are always sorted by name, so there is no order to change — offering a
-   * between-rows marker would draw a promise the app cannot keep. Off, a row is only ever
-   * dropped INTO something, which is the whole of what that app can do.
-   */
-  allowReorder?: boolean;
-  /** Words for refusing a drop into a folder whose `acceptsDrop` is false. */
-  lockedReason?: string;
-  /**
-   * The consumer's veto, for a refusal that depends on WHAT is being dragged.
-   *
-   * `acceptsDrop` is a property of the target alone and cannot express "this folder takes
-   * files but not folders from another album" — which is collections' actual rule, because
-   * its server has a route for re-pathing a folder inside one album and none for moving one
-   * across albums. Return the words; return null to allow.
-   *
-   * 🔴 Consulted BEFORE the target is offered, never after the drop. The whole design of
-   * this tree is that an impossible drop is never drawn as possible.
-   */
-  canDrop?: (dragId: string | null, target: FileTreeDrop) => string | null;
-}
-
-/**
- * Where the pointer currently is, as a decision.
- *
- * The rule the whole gesture is built around: **a drop that cannot happen is never
- * offered.** Every refusal below returns a reason rather than a null target, so the cursor
- * and the chip can say no while the row is still in the air.
- */
-export function resolveDrop({
-  nodes,
-  row,
-  offsetRatio,
-  dragId,
-  allowReorder = false,
-  lockedReason = 'That folder is locked',
-  canDrop,
-}: ResolveDropOptions): DropOffer {
-  // Blank space under the last row: out of every folder. The one gesture that needs no
-  // target, and the only way to say "top level" when the top level has no row of its own.
-  if (!row)
-    return canDrop?.(dragId, { kind: 'root' })
-      ? { target: null, refused: true, reason: canDrop(dragId, { kind: 'root' }) }
-      : { target: { kind: 'root' }, refused: false, reason: null };
-
-  const forbidden = dragId ? descendantIdsOf(nodes, dragId) : new Set<string>();
-  const target = row.node;
-
-  /** The consumer's last word on an otherwise-legal target. */
-  const vetted = (offer: DropOffer): DropOffer => {
-    if (!offer.target || !canDrop) return offer;
-    const reason = canDrop(dragId, offer.target);
-    return reason ? { target: null, refused: true, reason } : offer;
-  };
-
-  const intoFolder = (): DropOffer => {
-    if (target.kind !== 'folder') return { target: null, refused: false, reason: null };
-    if (forbidden.has(target.id))
-      return {
-        target: null,
-        refused: true,
-        reason:
-          target.id === dragId
-            ? 'A folder cannot go inside itself'
-            : 'A folder cannot go inside one of its own folders',
-      };
-    if (target.acceptsDrop === false)
-      return { target: null, refused: true, reason: lockedReason };
-    return vetted({ target: { kind: 'into', parentId: target.id }, refused: false, reason: null });
-  };
-
-  // A FILE row means "the folder that row is in" — what every file explorer does, and what
-  // keeps a long list of files from being a wall of rows nothing can be dropped on.
-  if (target.kind === 'file' && !allowReorder) {
-    if (row.parentId === null)
-      return vetted({ target: { kind: 'root' }, refused: false, reason: null });
-    const parent = findFileTreeNode(nodes, row.parentId);
-    if (parent && parent.acceptsDrop === false)
-      return { target: null, refused: true, reason: lockedReason };
-    if (parent && forbidden.has(parent.id))
-      return { target: null, refused: true, reason: 'A folder cannot go inside itself' };
-    return vetted({ target: { kind: 'into', parentId: row.parentId }, refused: false, reason: null });
-  }
-
-  if (!allowReorder) return intoFolder();
-
-  // With an order to change, the middle half of a folder row is "into" and the edges are
-  // "between". A file row is all edges — there is no inside of a file.
-  const edge = target.kind === 'folder' ? (1 - INTO_ZONE) / 2 : 0.5;
-  if (target.kind === 'folder' && offsetRatio > edge && offsetRatio < 1 - edge) return intoFolder();
-
-  const side = offsetRatio < 0.5 ? 'before' : 'after';
-  if (forbidden.has(target.id))
-    return { target: null, refused: true, reason: 'A folder cannot go inside itself' };
-  return vetted({
-    target: { kind: side, siblingId: target.id, parentId: row.parentId },
-    refused: false,
-    reason: null,
-  });
-}
-
-export interface KeyboardMoveOptions {
-  nodes: readonly FileTreeNode[];
-  /** The rows on screen — siblings are read off these, which is every sibling by construction. */
-  rows: readonly FileTreeRow[];
-  /** The row the keyboard is on. */
-  row: FileTreeRow;
-  /** `in` demotes into the nearest folder above it; `out` promotes to its grandparent. */
-  direction: 'in' | 'out';
-  lockedReason?: string;
-  canDrop?: (dragId: string | null, target: FileTreeDrop) => string | null;
-}
-
-/**
- * Where ⌥→ / ⌥← would put the focused row — the keyboard's half of the drag.
- *
- * 🔴 It exists because a gesture with no keyboard route is a gesture half the people using
- * it cannot perform, and because TOUCH has no drag here at all: a sidebar row is a small
- * target on a surface whose one constant gesture is the flick, so the pointer drag gives
- * that up and this is what is left. `cursedesk`'s tree has carried it since it was written;
- * this one shipped with the drag alone.
- *
- * The two directions are the only two a keyboard can mean unambiguously. **→ demotes into
- * the nearest folder ABOVE it among its own siblings** — the one place a demotion can go
- * without asking which of several folders was meant — and **← promotes out to the folder its
- * own folder is in**, which is `root` at depth 1.
- *
- * 🔴 Every refusal the DRAG honours is honoured here, from the same fields: `acceptsDrop`,
- * the consumer's `canDrop`, and the descendant rule. A keyboard route that can reach a
- * destination the pointer refuses is a second, weaker opinion about what is legal — and it
- * is the one nobody looks at, because the pointer is what gets tested by hand.
- *
- * There is deliberately no ⌥↑/⌥↓ here. Those would move a row among its siblings, which is
- * only meaningful when the consumer stores an order — and when it does, the sibling before
- * and after are already reachable as `before`/`after` drops. Offering them unconditionally
- * would write a position nothing reads and then draw the row back where it started.
- */
-export function resolveKeyboardMove({
-  nodes,
-  rows,
-  row,
-  direction,
-  lockedReason = 'That folder is locked',
-  canDrop,
-}: KeyboardMoveOptions): DropOffer {
-  const vetted = (target: FileTreeDrop): DropOffer => {
-    const reason = canDrop?.(row.node.id, target);
-    return reason
-      ? { target: null, refused: true, reason }
-      : { target, refused: false, reason: null };
-  };
-
-  if (direction === 'out') {
-    if (row.parentId === null)
-      return { target: null, refused: true, reason: 'It is already at the top level' };
-    const grandparentId = parentIdOf(nodes, row.parentId);
-    if (grandparentId === null) return vetted({ kind: 'root' });
-    const grandparent = findFileTreeNode(nodes, grandparentId);
-    if (grandparent?.acceptsDrop === false)
-      return { target: null, refused: true, reason: lockedReason };
-    return vetted({ kind: 'into', parentId: grandparentId });
-  }
-
-  // A row's siblings are all on screen whenever the row itself is — a shut folder hides its
-  // CHILDREN, never its peers — so the visible rows are the whole level.
-  const level = rows.filter((entry) => entry.parentId === row.parentId);
-  const above = level
-    .filter((entry) => entry.index < row.index && entry.node.kind === 'folder')
-    .at(-1);
-  if (!above)
-    return { target: null, refused: true, reason: 'There is no folder above it to move into' };
-  if (above.node.acceptsDrop === false)
-    return { target: null, refused: true, reason: lockedReason };
-  // Belt and braces: a folder cannot go inside itself, and `above` is a sibling rather than
-  // a descendant — but the rule is the tree's, not this function's, and stating it once here
-  // is cheaper than discovering the day someone changes what `above` means.
-  if (descendantIdsOf(nodes, row.node.id).has(above.node.id))
-    return { target: null, refused: true, reason: 'A folder cannot go inside itself' };
-  return vetted({ kind: 'into', parentId: above.node.id });
-}
-
-/**
- * Where a drop would put the thing being carried, in words — for the chip under the cursor
- * and for the screen reader that cannot see it.
- *
- * 🔴 A drag that says only WHAT is held answers half the question. Owner, of the tree this
- * one was ported from: *"dragging an item from one place to another does not have any
- * indication that it is working until you drop it somewhere new and see it move."* The chip
- * following the cursor answers "it is working"; this answers "and it is going there", which
- * is what stops a wrong drop before the pointer is lifted rather than after.
- *
- * Empty for no target — a refusal has its own words and this must never carry a second "no".
- */
-export function describeDrop(nodes: readonly FileTreeNode[], drop: FileTreeDrop | null): string {
-  if (!drop) return '';
-  if (drop.kind === 'root') return 'To the top level';
-  if (drop.kind === 'into') {
-    const folder = findFileTreeNode(nodes, drop.parentId);
-    return folder ? `Into ${folder.name}` : 'Into this folder';
-  }
-  const sibling = findFileTreeNode(nodes, drop.siblingId);
-  const where = drop.kind === 'before' ? 'Above' : 'Below';
-  return sibling ? `${where} ${sibling.name}` : `${where} this row`;
-}
-
-/**
- * The next row whose name starts with `query`, searching from `fromIndex` and wrapping.
- *
- * Typeahead is what makes a long tree usable without a search box — `bud` jumps to
- * `budget-2026` — and wrapping is what stops it dying at the bottom of the list.
- */
-export function matchTypeahead(
-  rows: readonly FileTreeRow[],
-  query: string,
-  fromIndex: number,
-): number {
-  if (!query) return -1;
-  const needle = query.toLowerCase();
-  for (let step = 1; step <= rows.length; step += 1) {
-    const index = (fromIndex + step + rows.length) % rows.length;
-    const row = rows[index];
-    if (row?.node.name.toLowerCase().startsWith(needle)) return index;
-  }
-  return -1;
-}
-
-/**
- * The tree narrowed to what matches, with the folders on the way to a match kept.
- *
- * A folder that matches keeps ALL of its contents — searching for a folder means you want
- * to see what is in it, not a folder that looks empty because its children spell something
- * else.
- */
-export function filterFileTree(
-  nodes: readonly FileTreeNode[],
-  query: string,
-): readonly FileTreeNode[] {
-  const needle = query.trim().toLowerCase();
-  if (!needle) return nodes;
-  const keep = (node: FileTreeNode): FileTreeNode | null => {
-    const hit = node.name.toLowerCase().includes(needle);
-    if (hit) return node;
-    const kids = childrenOf(node)
-      .map(keep)
-      .filter((n): n is FileTreeNode => n !== null);
-    if (kids.length === 0) return null;
-    return { ...node, children: kids };
-  };
-  return nodes.map(keep).filter((n): n is FileTreeNode => n !== null);
-}

package/src/core/folder-tree/actions.spec.ts

@@ -1,103 +0,0 @@
-/**
- * The two folder moves that read almost identically and are not the same operation.
- *
- * The owner's example, verbatim: *"I could move rock songs from a folder 'extra-rock-songs'
- * to a 'rock' folder with it."* That is a MERGE — `extra-rock-songs` stops existing. The
- * other verb, `planFolderMove`, makes it `rock/extra-rock-songs`: the files are all present
- * and the folder he was trying to get rid of is still there, one level down. Nothing about
- * the result looks wrong until you go looking for the folder you dissolved, which is why
- * both are pinned here side by side rather than each in isolation.
- */
-import { describe, expect, test } from "bun:test";
-import { folderMoveTargets, planFolderMergeInto } from "./actions";
-import { buildFolderTree, planFolderMove } from "./tree";
-
-const PATHS = [
-	"rock",
-	"rock/live",
-	"extra-rock-songs",
-	"extra-rock-songs/live",
-	"jazz",
-	"jazz/bebop",
-];
-
-const remaps = (list: { from: string; to: string }[]) =>
-	list.map((r) => `${r.from} → ${r.to}`).sort();
-
-describe("planFolderMergeInto", () => {
-	test("the owner's example: extra-rock-songs empties into rock", () => {
-		expect(remaps(planFolderMergeInto(PATHS, ["extra-rock-songs"], ["rock"]))).toEqual([
-			"extra-rock-songs → rock",
-			"extra-rock-songs/live → rock/live",
-		]);
-	});
-
-	test("🔴 and it is NOT planFolderMove — that one keeps the folder", () => {
-		expect(remaps(planFolderMove(PATHS, ["extra-rock-songs"], ["rock"]))).toEqual([
-			"extra-rock-songs → rock/extra-rock-songs",
-			"extra-rock-songs/live → rock/extra-rock-songs/live",
-		]);
-	});
-
-	test("an empty destination takes the contents out of any folder", () => {
-		// 🔴 `jazz` itself maps to the ROOT, which serializes to the empty string. A rewrite
-		// TO nothing is a real instruction — "this item is no longer in any folder" — so the
-		// consumer is told about it rather than it being silently dropped for looking empty.
-		expect(remaps(planFolderMergeInto(PATHS, ["jazz"], []))).toEqual([
-			"jazz → ",
-			"jazz/bebop → bebop",
-		]);
-	});
-
-	test("it refuses to eat itself", () => {
-		expect(() => planFolderMergeInto(PATHS, ["rock"], ["rock"])).toThrow();
-		expect(() => planFolderMergeInto(PATHS, ["rock"], ["rock", "live"])).toThrow();
-		expect(() => planFolderMergeInto(PATHS, [], ["rock"])).toThrow();
-	});
-
-	test("folders it does not name are left alone", () => {
-		const out = planFolderMergeInto(PATHS, ["extra-rock-songs"], ["rock"]);
-		expect(out.some((r) => r.from.startsWith("jazz"))).toBe(false);
-	});
-});
-
-describe("folderMoveTargets", () => {
-	const nodes = buildFolderTree(PATHS);
-
-	test("🔴 never offers the folder itself or anything under it", () => {
-		const labels = folderMoveTargets(nodes, ["rock"]).map((t) => t.label);
-		expect(labels).not.toContain("rock");
-		expect(labels).not.toContain("rock › live");
-	});
-
-	test("never offers the parent it is already in — an entry that does nothing", () => {
-		const labels = folderMoveTargets(nodes, ["rock", "live"]).map((t) => t.label);
-		expect(labels).not.toContain("rock");
-		expect(labels).toContain("jazz");
-	});
-
-	test("offers the root only when the folder is not already at the top", () => {
-		expect(folderMoveTargets(nodes, ["rock"]).some((t) => t.path.length === 0)).toBe(false);
-		expect(folderMoveTargets(nodes, ["rock", "live"]).some((t) => t.path.length === 0)).toBe(
-			true,
-		);
-	});
-
-	test("🔴 a refused branch does not hide its children — only the SUBTREE is unreachable", () => {
-		// `rock` is `rock/live`'s parent and so not a target, but `rock`'s OTHER children
-		// would be perfectly good ones. Walking must not stop at the refusal.
-		const deep = buildFolderTree(["a/b", "a/c", "a/c/d"]);
-		const labels = folderMoveTargets(deep, ["a", "b"]).map((t) => t.label);
-		expect(labels).toContain("a › c");
-		expect(labels).toContain("a › c › d");
-		expect(labels).not.toContain("a");
-	});
-
-	test("every target it offers is one planFolderMove accepts", () => {
-		for (const source of [["rock"], ["rock", "live"], ["jazz", "bebop"]]) {
-			for (const target of folderMoveTargets(nodes, source)) {
-				expect(() => planFolderMove(PATHS, source, target.path)).not.toThrow();
-			}
-		}
-	});
-});