A graph that grew past one screen needs somewhere to say what a part of it is for (#38)

The graph could hold any number of nodes and said nothing about which of them
belonged together. Groups and comments are two separate things, as decided in
the issue: a group is a titled box that carries the nodes it encloses, a
comment is free text that carries nothing.

Both live as optional arrays on Graph, not as registry nodes. A comment that
were a real node would run through the interpreter, show up in the drop
palettes and be compiled into a shader — the wrong place for a piece of text.
As arrays on Graph they exist in all four graph kinds at once, and a document
without them means exactly "no groups", so no format bump.

Membership is computed when the box is grabbed, never stored: the center of a
node inside the box travels with it, and a node dragged out is simply out. A
box inside a box travels with the outer one, its own nodes included. A group
is grabbed by its title bar only — its body stays transparent to the pointer,
or a rubber band could never be drawn across the nodes it holds. Deleting a
box deletes the box; the nodes stay where they are, because a box that
silently took ten nodes with it would be the most expensive surprise in the
feature.

The color is a free picker, and the title color follows from it: relative
luminance per WCAG, threshold at 0.179 where the two contrast ratios meet —
not 0.5, which would pick white on mid grey where black reads better.

Resizing snaps the far edge to the grid, not the width, so the corner that is
not being dragged stays put. The minimum size rises in whole steps for that
reason: 80 is no multiple of 24, so a box squeezed to the stop would have sat
off-grid in exactly the mode meant to keep it on.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

src/ui/Theme.ts

@@ -70,6 +70,8 @@ export const Theme = {
     portAny: 0xbdbdbd,
     /** Ring around the port a running edge drag would connect to. */
     portTarget: 0xffffff,
+    /** Groups and comments that were never given a colour of their own. */
+    annotation: 0x3c4352,
     hot: 0xffc857,
   },
 } as const;

src/ui/color.ts

@@ -22,6 +22,28 @@ export function parseHex(text: string): number | null {
   return null;
 }
 
+/**
+ * Relative luminance (WCAG): the perceived brightness of a colour, 0 for black and 1 for white.
+ * Green weighs most because the eye sees it best – an average of the channels would call a
+ * saturated blue as bright as a yellow.
+ */
+export function luminance(color: number): number {
+  const channel = (shift: number) => {
+    const v = ((color >> shift) & 0xff) / 255;
+    return v <= 0.04045 ? v / 12.92 : ((v + 0.055) / 1.055) ** 2.4;
+  };
+  return 0.2126 * channel(16) + 0.7152 * channel(8) + 0.0722 * channel(0);
+}
+
+/**
+ * Black or white, whichever is easier to read on `background`. The threshold is where the two
+ * contrast ratios meet, not 0.5: white on mid grey is worse than black on it. This is what lets a
+ * free colour picker stay safe – whatever colour is chosen, its text is still legible.
+ */
+export function readableTextColor(background: number): number {
+  return luminance(background) > 0.179 ? 0x000000 : 0xffffff;
+}
+
 /** Greys report hue 0 and saturation 0, so a round trip through `hsvToRgb` is exact. */
 export function rgbToHsv(color: number): HSV {
   const r = ((color >> 16) & 0xff) / 255;

src/ui/index.ts

@@ -38,5 +38,15 @@ export { TextField, type TextFieldOptions } from './widgets/TextField';
 export { NumberField } from './widgets/NumberField';
 export { ColorField } from './widgets/ColorField';
 export { ColorPicker } from './widgets/ColorPicker';
-export { type HSV, hsvToRgb, paintHueBar, paintSvSquare, parseHex, rgbToHsv, toHex } from './color';
+export {
+  type HSV,
+  hsvToRgb,
+  luminance,
+  paintHueBar,
+  paintSvSquare,
+  parseHex,
+  readableTextColor,
+  rgbToHsv,
+  toHex,
+} from './color';
 export { pressCount } from './clicks';