spine-rigc 1.1.0 → 1.2.1

package/docs/AUTHORING.md

@@ -123,6 +123,8 @@ bun cli.ts check \
 # …and if nobody gave you frames, LOOK at it instead — neither needs a reference:
 bun cli.ts render  --candidate path/to/spine    # PNG frames + a contact sheet grid
 bun cli.ts preview --candidate path/to/spine    # one .html that plays it in Spine's own player
+#   ↳ a green build ends by naming this command for its own --out; repeat
+#     --candidate for a pane per candidate on one page
 
 # …and where you have several green candidates and no instrument that separates
 # them, ask a human — the one loop step this toolchain cannot run for you:
@@ -141,6 +143,30 @@ the animation is the one in the frames, and there is no assertion that could —
 §9. The two run in that order because `check` needs artifacts on disk and `build`
 only writes them when the gate is green.
 
+🎞️ **When the source is a foreign player — a Live2D model, a Unity scene, a video —
+make the reference frames first, from the source.** rigc reads none of those
+formats and will not ([FACE.md](FACE.md#11-non-goals--stated-so-nobody-proposes-them-as-gaps)
+§11, the paragraph that opens *No Live2D file is read or written*); what it reads
+is the pictures they produce. Render the source at the rate you will check at into
+one directory of `f0000.png`, `f0001.png`… named after the candidate animation it
+shows (or pair the two with `--as`): `check` accepts a set with no `frames.json`
+and takes its rate from `--fps` (§9). What that set cannot carry is its
+**background**, which the sidecar would have recorded — so render it onto an
+**opaque** background of the colour `check`'s no-`frames.json` note names, the one
+after *"the background is this build's default,"*. Running `check` once on any
+frame set with no sidecar prints it, so read it there before rendering rather than
+from a copy here. The content box is found against that colour and alpha is not
+read, so a reference that is not opaque is **refused**, naming the frames and the
+first pixel whose alpha is not 255 (§9). A background that is opaque but another
+colour is not refused and costs you: measured on the 24 frames of `gallery/look`'s
+`turn`, the same drawn pixels read MAE mean **2.25** over the note's colour and
+**5.19** over white, at exit 0 with the same notes. A port with no
+reference frames is **unmeasured, not finished**: green from `build` says the file
+is valid and nothing about whether it is the source's picture. And the parts are
+the source's own texture cut along its drawables, **never a screenshot of it** — a
+screenshot is the composed result, so a part cut from it carries every part under
+it, which is what the first of the three questions under *LOOK* below finds.
+
 🚨 **Read `check`'s per-frame column before its MAE.** The table's headline figures
 are the MAE and the slot drift, and a reader who came for those will skip the
 `per-frame` line printed under them — but that line is the only thing in this
@@ -159,7 +185,7 @@ What the flags mean:
 | --- | --- |
 | `--rig` | the rig spec — skeleton structure |
 | `--motion` | the motion spec — time |
-| `--out` | directory for `skeleton.json` + `skeleton.atlas`; atlas page paths and `skeleton.images` are written relative to it |
+| `--out` | directory for `skeleton.json` + `skeleton.atlas`; atlas page paths and `skeleton.images` are written relative to it. On `check` it is a directory of **pictures** instead: one per frame the table lists (every compared frame under `--all-frames`), reference · candidate · difference · overlay at the comparison grid's native size, as `<dir>/<set>/f####.png` beside a `frames.json` that says what they are pictures of. Each `<dir>/<set>/` is cleared first; a file at `<dir>`, or a directory that is or holds `--frames`, is refused by name — **§9.2.1** |
 | `--copy-images` | `build` only: also copies every page **the emitted atlas names** into `--out` and rewrites the atlas to the copies, so the directory is self-contained enough to zip or commit on its own, and points `skeleton.images` at `--out` itself so the editor's import finds the parts beside the skeleton (§3.1 says why it is spelled `../<out>/` and not `./`). Under `--atlas-in` those pages are the pack's, not one per part (**§0.2**). Without it, page paths point at the source art |
 | `--pack` | `build` only: arrange every part onto **shared** atlas page(s), written into `--out` as real PNGs, instead of one page per part. Lossless — nothing is resampled, trimmed or rotated. The default is one page per part — **§0.1** |
 | `--page-size` | `build --pack` only: the largest page edge (default `2048`). A ceiling, not the size: page edges are powers of two and the one written is the smallest that holds the pack — **§0.1** |
@@ -170,8 +196,8 @@ What the flags mean:
 | `--cut` | `build`, `explain` and `validate`: look up a named cut in `--cuts <cuts.json>`, **instead of** `--rig`/`--motion`/`--out` — the two spellings are one build stated two ways and are refused together. A `cuts.json` is `{ "<name>": { "rig": …, "motion": …, "out": …, "manifest"?: … } }`, every path in it relative to the table's own file, so the table lives with the project that owns the art |
 | `--cuts` | the `cuts.json` `--cut` names. Required beside it — `--cut` alone is refused, with no guess at where the table lives |
 | `--profile` | `spine` = the 34 validity rules (**the default**) · `spine-html` = all 49, opt-in |
-| `--candidate` | `check`, `bench`, `render`, `preview`, `chainfit` and `vote` only: a **compiled** artifact — the directory `build --out` wrote, or a `skeleton.json` path. `--atlas <path>` names the atlas when it does not sit beside the skeleton. **`vote` is the one command that takes it more than once** — repeat it 2–4 times, one per pane, labelled A, B, C, D in the order given; everywhere else a repeat is a typo and is refused |
-| `--animation` | `render`, `preview` and `vote` only: which animation to show. The default is **every** one for `render`, the **first** for `preview`, and for `vote` the first of candidate A. A name the skeleton does not have is refused, with the ones it does have listed — and for `vote`, so is a name that only *some* candidates have |
+| `--candidate` | `check`, `bench`, `render`, `preview`, `chainfit` and `vote` only: a **compiled** artifact — the directory `build --out` wrote, or a `skeleton.json` path. `--atlas <path>` names the atlas when it does not sit beside the skeleton. **`vote` and `preview` take it more than once**: `vote` 2–4 times, one per pane, labelled A, B, C, D in the order given; `preview` any number of times, one pane per candidate in the order given, each headed by its path and its gate line, and the same skeleton twice (a directory and its `skeleton.json` are one) is refused by name. `--atlas` goes with one candidate only. Everywhere else a repeat is a typo and is refused |
+| `--animation` | `render`, `preview` and `vote` only: which animation to show. The default is **every** one for `render`, the **first** for `preview` (each candidate's own first, with several), and for `vote` the first of candidate A. A name the skeleton does not have is refused, with the ones it does have listed — and for `vote` and a several-candidate `preview`, so is a name that only *some* candidates have, naming the one that lacks it |
 | `--record` | `vote` only: a saved vote to check against its ballot and append to the ledger, instead of writing a ballot. This is the command's second mode; it takes no `--candidate` |
 | `--ballot` | `vote --record` only: the ballot the vote answers (default `ballot.html`). Its embedded manifest is what the vote is checked against, so the ballot file is the record of the question |
 | `--ledger` | `vote --record` only: the append-only JSONL the vote lands in (default `votes.jsonl`), one vote per line |
@@ -191,7 +217,12 @@ What the flags mean:
 
 `render` also takes `--fps <n>` (the rate it samples at, default 12 — the same
 protocol rate the reference frames use) and `--max <px>` (the long side of a
-frame, default 256). Three commands take `--out`: a directory for `render`
+frame, default 256). A clipping attachment is applied as the runtime applies it —
+spine-core's own `SkeletonClipping`, in spine-webgl's call order — so a slot from
+the clip's through its `end` slot draws only what falls inside the polygon, in
+`render`, `check` and every other picture rigc's own rasteriser draws (`preview`
+plays in Spine's player, which always clipped); the framing box still counts
+what the clip removes, so adding or keying a mask moves no pixel it leaves drawn. Three commands take `--out`: a directory for `render`
 (default `render/`), the `.html` file for `preview` (default `preview.html`) and
 for `vote` (default `ballot.html`).
 
@@ -749,7 +780,8 @@ bun cli.ts diff     candidate.json reference.json [--as <candidate>=<reference>]
 bun cli.ts check    --candidate path/to/spine --frames path/to/frames [--skin …]
 bun cli.ts bench    3 --candidate path/to/spine [--frames path/to/frames]
 bun cli.ts render   --candidate path/to/spine [--animation …] [--skin …] [--fps 12] [--max 256]
-bun cli.ts preview  --candidate path/to/spine [--animation …] [--out preview.html]
+bun cli.ts render   --candidate path/to/spine --slot <name,…> | --hide <name,…>   # part of the rig, same grid
+bun cli.ts preview  --candidate path/to/spine [--candidate path/to/another …] [--animation …] [--out preview.html]
 bun cli.ts vote     --candidate path/to/a --candidate path/to/b [--out ballot.html]
 bun cli.ts vote     --record vote-<id>.json [--ballot ballot.html] [--ledger votes.jsonl]
 bun cli.ts pose     --images path/to/parts --frame poseA.png [--out pose.json]
@@ -824,12 +856,39 @@ bun cli.ts pose     --images path/to/parts --frame poseA.png [--out pose.json]
   gate can know you did not mean them. `render` writes
   `render/<animation>/f0000.png…` with a `contact.png` grid of **every** frame
   beside them (open that one first — spacing is a comparison across frames) and a
-  `frames.json` sidecar naming the world box they are pictures of. `preview`
+  `frames.json` sidecar naming the world box they are pictures of. `contact.png`
+  is for spacing across frames; a defect is read on **one frame at full size**,
+  because a tile is too small to say which part a pixel belongs to. When a frame
+  looks wrong, render it again with `--hide <slot>` — the **largest attachment**
+  first, since it covers the most and is the likeliest to hide what is under it —
+  and compare the two frames: `--hide` and `--slot <name,…>` draw a subset of the
+  slots on the **same grid** as the whole rig (the viewport is still fitted to
+  every slot), so the frames overlay pixel for pixel and the difference is the
+  part. Three questions to ask of that full-size frame, each answered that way.
+  **Is any picture drawn twice?** Hide the largest attachment and look for a second
+  copy of what it covered, since a ghost under an opaque part is invisible until the
+  part is gone. **Is there a straight edge where the art has none?** A part cut as a
+  rectangle carries a border its drawing never had, and `--slot <that slot>` shows it
+  alone. **Does a part cover a feature the art shows?** An eye slot drawn over the
+  eye is found by hiding the slot and watching the feature come back. A name the skeleton does not declare is refused with every slot it does,
+  in draw order; a slot whose art lives only under another skin is refused naming
+  that skin (pass `--skin`); the two flags together are refused. `frames.json`
+  records the subset as `slots` or `hidden`, and **`check` refuses such a set as
+  a reference** (§9). `preview`
   writes one self-contained `.html`: your skeleton, atlas and page PNGs are
   embedded in it as data URIs and played by the official **Spine Web Player**, so
   double-clicking it is also the interop proof — what plays there was played by
   Esoteric Software's runtime, not by rigc's. The player is loaded from a CDN
-  rather than copied into the file, so the first open needs a network.
+  rather than copied into the file, so the first open needs a network. Its
+  header carries the gate's line for the candidate — the `N assertions: …`
+  summary `rigc validate <dir>` prints for the same files, and its first `FAIL`
+  line when there is one — with the rigc version, measured when the page is
+  written; a refused candidate is still previewed, because looking at a red
+  build is what the page is for. Note that it is the **bare-directory** reading:
+  with no rig spec and no second compile beside the files, `A09` and `A18` report
+  SKIP there, so its counts are not the ones `build` printed. It takes
+  neither `--slot` nor `--hide` — the player draws what the skeleton draws — and
+  refuses both by name rather than playing the whole rig as if it had obeyed.
 - 📐 **`pose` is the only command here that reads an INPUT rather than a result.**
   Everything else takes a spec or a build and tells you something about it; `pose`
   takes a picture the user already has — a key pose — and reports where each loose
@@ -6018,7 +6077,8 @@ rather than the rig (**§9.2**'s atlas floor — and note that it is *not* `--at
 which re-seats your geometry on that atlas's packing), `--skin <name>` to pose
 your candidate under one of its skins (below), `--all-frames` to list
 every frame instead of the worst by MAE, `--json <out>` for the whole per-frame,
-per-slot report.
+per-slot report, `--out <dir>` for the picture each listed frame's figures came from
+(**§9.2.1**).
 
 🚨 **What `check` certifies is the DEFAULT skin, unless you pass `--skin`.** With no `--skin` no skin is set at all, which is `spine-core`'s own
 initial state: every slot resolves through `SkeletonData.defaultSkin` alone, and a
@@ -6056,6 +6116,21 @@ remember:
 A skin name the candidate does not declare is refused with the ones it does —
 `the candidate declares no skin "path"; it declares [default, patch, torn]`.
 
+🚫 **A frame set of PART of a rig is not a reference.** `render --slot`/`--hide`
+(§0) records the subset in `frames.json`, and `check` refuses any set that carries
+`slots` or `hidden`, before posing anything:
+
+```
+rigc check error: --frames frames/ records a slot subset (hidden: head) in frames.json; a partial render is not a reference set — render the reference without --slot/--hide
+```
+
+It is the skin clause one step stronger: two skins are two pictures of one rig,
+while a reference with a part left out is not a picture of the whole rig at all,
+and scoring a whole candidate against it would print a real figure about art the
+reference never drew. There is no flag that makes it comparable. A set with
+neither key — every set rendered without the flags, and every set written before
+they existed — is compared exactly as before.
+
 📌 **Deform measurement needs no such flag, because the timeline carries the
 name.** `A39` and the `DEFORM` block pose each key with the skin that key is keyed
 on — a deform timeline's address is a `skin / slot / attachment` triple — so a
@@ -6106,6 +6181,31 @@ sampled at, and without it the 12 fps protocol rate is assumed and the report sa
 so rather than letting the assumption look like a measurement. Passing `--fps` with
 a value the sidecar contradicts is an error, not an override.
 
+A set with no sidecar is one of two things, and the `⚠️ no frames.json` note says
+which advice goes with which: **a rigc render older than the sidecar** is fixed by
+rendering it again with `rigc render`, and **a foreign source** — a Live2D, Unity or
+video player, whose frames predate nothing — needs the three things the sidecar
+would have said, supplied by whoever made them: an opaque background of the colour
+the note names, `--fps` at the rate it was rendered, and a directory named after
+the candidate animation it shows or `--as <that animation>`. Two of those are
+refused by name when they are wrong, because a figure would come out of either:
+
+```
+rigc check error: --frames frames/turn has no frames.json, and 24 of its 24 compared reference frame(s) are not opaque (f0000.png, f0001.png, f0002.png, and 21 more): f0000.png has alpha 0 at (0, 0), where every pixel must be 255. Without a sidecar the frames are read against the background colour 232, 232, 232, 255 with alpha unread, so a pixel that is not opaque counts by its colour bytes alone: a transparent background counts as drawn and puts the figure over the whole frame, a number about the transparent area and not the rig, which --viewport does not change. Render the frames onto an opaque background of 232, 232, 232, 255.
+rigc check error: no reference frame could be compared, so there is nothing to frame against: the frames were matched to a candidate animation by name, and the candidate has no animation called "idle" (the directory's own name) — it declares [sweep, tilt, turn]. Pass --as <name> with the one these frames show, or name the directory after it
+```
+
+The test is every pixel's alpha, not the border's: a pixel that is not opaque is
+not yet a colour — what it shows depends on what it is composited over — so one
+pixel of alpha 254 in one frame is refused too, naming that frame and that pixel.
+The first is a refusal rather than a note because pinning does not rescue it:
+`--viewport` set to the box the frames were drawn in reads MAE **0.00** on the
+opaque set and **32.90** on the same set made transparent, on every one of its 24
+frames — the transparent area times its distance from the background colour, which
+is a figure about the background and not about the rig. `--as` takes **one**
+candidate animation name; the `<candidate>=<reference>` pair is `diff`'s spelling,
+and `check` refuses it as a name the candidate does not declare.
+
 `--viewport <x>,<y>,<width>,<height>` pins your candidate's world box instead of
 fitting it. Two uses:
 
@@ -7001,6 +7101,66 @@ slots column is a parenthesis rather than a fraction, the deformation it carries
 already being scored inside the chain that owns the slot, and the row is telling you
 about your bone tree rather than about a hole in your figure.
 
+#### 9.2.1 Reading the pictures — `--out`
+
+```bash
+bun cli.ts check --candidate path/to/spine --frames path/to/reference/frames --out check-pictures
+```
+
+The table says **how much** a frame differs; `--out <dir>` writes **where**. For
+every frame the table lists — the frames worth reading, or every compared frame
+under `--all-frames` — it writes `<dir>/<set>/f####.png`, and beside them a
+`frames.json` recording what they are pictures of: the candidate, the frames
+directory, both skins, the framing scope, the grid, and per set the box it was
+framed in and which frames were written. Each picture is four panes, left to right:
+
+| Pane | What it is | The figure in its label |
+| --- | --- | --- |
+| `REFERENCE` | the frame as read from `--frames` | `REF D` — the table's `ref Δ`: pixels the reference moved since its own previous frame (`-` when that frame was not compared) |
+| `CANDIDATE` | your candidate exactly as `check` rendered it onto that grid — same framing, same skin, same texture | `DPX` — the table's `Δpx`, the same count on your side |
+| `DIFFERENCE` | per pixel, the largest of the three channel differences between the two, on a **fixed** grey ramp: 0 is black, 255 is white. Drawn over exactly the pixels the MAE averages over — what your geometry covers or the reference drew — and transparent everywhere else | `MAE` — the frame's MAE, as the table prints it |
+| `OVERLAY` | the two at 50 % each, so a displaced edge reads as a double line and a part drawn twice reads as a ghost | `UNION` — the table's `union px` |
+
+Under the panes, one row per slot of that frame: its drift at the table's
+precision and how it was matched, or why it has none (`not drawn`, `no attributable
+drift`). The frame's worst slot — the one its table row names — is marked `>`. The
+text is the tree's 5x7 bitmap font, so it prints in capitals, and a character the
+font does not carry draws as a solid block rather than disappearing.
+
+- **The ramp is fixed, and deliberately not stretched to the frame's own maximum.**
+  Two runs' pictures are then comparable by eye, and a quiet frame looks quiet. The
+  cost is the other side of the same choice: a frame whose MAE is a texture floor
+  of a few points reads as a **near-black silhouette** of the union, because 7 of
+  255 is dark. That silhouette is not nothing — it is where the two sides drew —
+  and the grey you have to find is the difference you have to fix.
+- **Every pane is at the grid's native size, and there is no upscaling option.** An
+  upscaled difference is a difference the instrument invented: a resampling filter
+  spreads ink into pixels the comparison never measured. Open the file and zoom in
+  your viewer instead, where the magnification is yours and visibly not the data.
+- **Nothing in a picture is a new number.** Every figure in it is one the report
+  already holds. The rasters are the ones the figures were computed on, kept at the
+  moment they were compared rather than rendered again.
+
+What a picture cannot tell you, and does not try to:
+
+- **Which side is right.** The difference pane is symmetric. A pixel lit there is
+  a pixel the two disagree about; whether yours or the reference's is the one to
+  move is yours to read off the other panes.
+- **Anything about a frame it does not show.** The set is the table's listing, so
+  a frame outside it was not pictured — not pictured clean. `--all-frames` widens
+  the set to every compared frame when the listing is not enough.
+
+`<dir>/<set>/` is cleared and rewritten, as `render` clears its own, and nothing
+else under `<dir>` is touched. Two things are refused before anything is compared:
+a **file** at `<dir>` (`check: --out <path> is a file; it names a directory`), and a
+directory that **is `--frames` or holds it** (`check: --out <path> is --frames …` /
+`… holds --frames …`), because clearing a set directory there deletes the frames the
+pictures are of. And a `check --out` directory is not a frame set: pointed at by
+`--frames`, it is refused by the field that says so —
+`` frames.json carries "comparison": it was written by `rigc check --out` `` and the
+rest of the sentence names the frames it was made against. The reference pane inside each
+picture is a frame; the file is four panes and a table.
+
 ### 9.3 What it still cannot see
 
 - **Anything a frame does not contain.** Bone `length`, the setup `inherit` mode,

package/docs/MOTION.md

@@ -1007,6 +1007,7 @@ rigc build --rig semaphore.rig.json --motion semaphore.motion.json --images part
   ..    pages=3 regions=3 bones=4 slots=3 animations=1 version=4.3.13 regionAttachments=3 meshAttachments=0 physicsConstraints=0 rig=semaphore profile=spine
 rigc: wrote …/semaphore/spine/skeleton.json
 rigc: wrote …/semaphore/spine/skeleton.atlas
+rigc: look at it: rigc preview --candidate …/semaphore/spine
 ```
 
 ```bash

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "spine-rigc",
-  "version": "1.1.0",
+  "version": "1.2.1",
   "description": "Rig compiler for Spine — declarative rig specs in, Spine 4.3 skeleton data out, verified by a spine-core round-trip. Built so AI agents can author rigs and check their own work; the output imports into the Spine editor.",
   "type": "module",
   "bin": {

package/skills/rigc/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: rigc
-description: Author, build and validate Spine 4.3 skeleton data (skeleton.json plus its .atlas) from loose part PNGs with rigc, the rig compiler that verifies its own output through a spine-core round-trip before writing it. Use for any request to make a Spine rig or Spine animation from PNG parts, to run or read rigc build, validate, render, preview, check or vote, or to write or fix a *.rig.json or *.motion.json spec; it says which shipped guide to open for the need at hand. Not for Live2D conversion, cutting an illustration into parts, or real-time face tracking.
+description: Author, build and validate Spine 4.3 skeleton data (skeleton.json plus its .atlas) from loose part PNGs with rigc, the rig compiler that verifies its own output through a spine-core round-trip before writing it. Use for any request to make a Spine rig or Spine animation from PNG parts, or where the source is a Live2D, Unity or video model whose pictures you can render, to run or read rigc build, validate, render, preview, check or vote, or to write or fix a *.rig.json or *.motion.json spec; it says which shipped guide to open for the need at hand. Not for Live2D conversion, cutting an illustration into parts, or real-time face tracking.
 license: MIT
 compatibility: Requires Bun 1.2 or later. The tool is the npm package spine-rigc (bunx spine-rigc, or bun add -d spine-rigc); the command it installs is rigc.
 ---
@@ -55,15 +55,38 @@ skill the package ships there, and `rigc skills --help` says what it refuses.
    §4.11.2.
 4. `rigc render --candidate <out>` or `rigc preview --candidate <out>` — look at
    it. A rig with its head off its torso passes the gate; looking is what catches it.
-5. `rigc check --candidate <out> --frames <dir>` when you have reference pictures;
+   Open one frame at full size, not only `contact.png`: the sheet is for spacing
+   across frames, and a defect is read on a frame. Ask it three things — is any
+   picture drawn twice, is there a straight edge where the art has none, does a part
+   cover a feature the art shows — and answer each with `render --hide <slot>` (or
+   `--slot <slot,…>`), which draws the frame again without that part on the same
+   grid, so the two frames say which part a pixel is. AUTHORING §0 holds the three.
+5. `rigc check --candidate <out> --frames <dir>` when you have reference pictures
+   (`--out <dir>` writes the picture each of its numbers came from — open the worst);
    `rigc vote --candidate <a> --candidate <b>` when several candidates are green and
    only a person can choose between them.
 6. `rigc validate <out>` re-gates artifacts already on disk, and
    `rigc <command> --help` is each command's own flag table.
+7. Every finished unit ends with `rigc preview --candidate <out>`, and the report
+   names the `.html` it wrote. The hand-off to a person is part of the work.
 
 The loop in full, with `pose` before it and `chainfit` after the first build:
 AUTHORING §0.
 
+## When the source is not loose PNGs
+
+A Live2D model, a Unity scene or a video is a player, not a set of parts. Make the
+reference frames first: render the source at the rate you will check at, into one
+directory of `f0000.png`, `f0001.png`…, and `rigc check --frames <that dir> --fps <rate>`
+reads them with no `frames.json`. A port with no reference frames is unmeasured,
+not finished. The parts are the source's own texture cut along its drawables, never
+a screenshot: a screenshot is the composed result, and a part cut from it carries
+every part under it. rigc reads none of those formats — FACE §11, the paragraph
+that opens *No Live2D file is read or written*
+([FACE.md](https://github.com/firejune/rigc/blob/main/docs/FACE.md#11-non-goals--stated-so-nobody-proposes-them-as-gaps)) —
+only the pictures they produce. The rule, the background those frames need and
+what a wrong one costs: AUTHORING §0, *When the source is a foreign player*.
+
 ## Which guide, for which need
 
 Read [AUTHORING.md](https://github.com/firejune/rigc/blob/main/docs/AUTHORING.md) first, whatever the need: the two

package/src/ballot.ts

@@ -63,6 +63,9 @@ import {
   dataUri,
   embeddedJson,
   escapeHtml,
+  PANE_STAGE_CSS,
+  paneGridCss,
+  paneSection,
   PLAYER_LINE,
   PLAYER_SCRIPT_URL,
   PLAYER_STYLE_URL,
@@ -592,14 +595,10 @@ export function buildBallot(input: BallotInput): { html: string; manifest: Ballo
     },
   };
 
-  const panes = manifest.candidates
-    .map(
-      (c) => `<section class="pane">
-  <h2>${c.label}</h2>
-  <div class="stage" id="rigc-player-${c.label}"></div>
-</section>`,
-    )
-    .join('\n');
+  // The pane markup and its grid are `preview.ts`'s since issue #837, which
+  // borrowed them for a page of panes that asks nothing; the bytes here are
+  // the ones this page always wrote.
+  const panes = manifest.candidates.map((c) => paneSection(`rigc-player-${c.label}`, `<h2>${c.label}</h2>`)).join('\n');
 
   const choices = [...labels, TIE]
     .map(
@@ -649,11 +648,9 @@ export function buildBallot(input: BallotInput): { html: string; manifest: Ballo
   button { font: inherit; padding: 4px 12px; border: 1px solid rgba(0, 0, 0, 0.35); border-radius: 4px; background: rgba(255, 255, 255, 0.6); cursor: pointer; }
   button:hover { background: rgba(255, 255, 255, 0.95); }
   button[aria-pressed="true"] { background: #1a1a1a; color: #fff; border-color: #1a1a1a; }
-  #panes { display: grid; grid-template-columns: repeat(${manifest.candidates.length}, minmax(0, 1fr)); gap: 1px; background: rgba(0, 0, 0, 0.15); }
-  @media (max-width: 720px) { #panes { grid-template-columns: minmax(0, 1fr); } }
-  .pane { background: ${backgroundHex()}; display: flex; flex-direction: column; min-width: 0; }
+${paneGridCss(manifest.candidates.length)}
   .pane h2 { margin: 0; padding: 6px 14px; font-size: 15px; letter-spacing: 0.12em; }
-  .stage { height: 52vh; min-height: 260px; }
+${PANE_STAGE_CSS}
   #vote { border-top: 1px solid rgba(0, 0, 0, 0.15); display: flex; flex-direction: column; gap: 10px; }
   .row { display: flex; gap: 8px; align-items: center; flex-wrap: wrap; }
   .row > label, .caption { opacity: 0.65; }