rig-c 2.21.0 → 2.23.0

package/NOTICE.md

@@ -8,8 +8,10 @@ Copyright (c) 2013-2025 Esoteric Software LLC, licensed under the
 [Spine Runtimes License Agreement](https://esotericsoftware.com/spine-runtimes-license),
 as a **development dependency**: a clone and CI install it, and every Spine file
 `rigc build` writes there is read back through it before it is written. **The
-published package does not carry it** — an install of `spine-rigc` has no Spine
-runtime in it unless one is installed beside it, and then the same `rigc` uses it.
+published package does not carry it** — an install of `rig-c` (or of
+`spine-rigc`, the same files under the name the package first shipped as) has no
+Spine runtime in it unless one is installed beside it, and then the same `rigc`
+uses it.
 
 Its terms, as the licence states them: integration of the Spine Runtimes into
 software is permitted **under the terms and conditions of Section 2 of the

package/README.md

@@ -3,8 +3,8 @@
 </p>
 
 <p align="center">
-  <a href="https://www.npmjs.com/package/spine-rigc"><img src="https://img.shields.io/npm/v/spine-rigc.svg?style=flat-square&color=FF6B4A" alt="npm version" /></a>
-  <a href="https://www.npmjs.com/package/spine-rigc"><img src="https://img.shields.io/npm/dm/spine-rigc.svg?style=flat-square&color=A855F7" alt="npm downloads" /></a>
+  <a href="https://www.npmjs.com/package/rig-c"><img src="https://img.shields.io/npm/v/rig-c.svg?style=flat-square&color=FF6B4A" alt="npm version" /></a>
+  <a href="https://www.npmjs.com/package/rig-c"><img src="https://img.shields.io/npm/dm/rig-c.svg?style=flat-square&color=A855F7" alt="npm downloads" /></a>
   <a href="LICENSE"><img src="https://img.shields.io/badge/license-MIT-38BDF8.svg?style=flat-square" alt="license" /></a>
 </p>
 
@@ -13,7 +13,8 @@ a rig compiler for Spine: a rig spec and a motion spec in, Spine 4.3 skeleton da
 gated by a list of named assertions before a byte is written — rigc's own validator in
 the published package, held to a `spine-core` round trip's verdicts in this
 repository's CI. Built so AI agents can author rigs and check their own work; it ships
-as an agent skill.
+as an agent skill. On npm it is `rig-c` — the same package as `spine-rigc`, the name it
+first shipped under, which is published beside it with the same files at every version.
 
 ## What you get
 
@@ -143,18 +144,22 @@ runners and on Linux at the declared minimum, Bun 1.2.0 (the `installs` and
 repository material, not in the npm package); a platform
 whose leg is red there is not one the package is known to run on.
 
-**The npm package is `spine-rigc`; the command it installs is `rigc`.** npm
+**The npm package is `rig-c`; the command it installs is `rigc`.** npm
 refuses the name `rigc` as too similar to packages that already exist, so the
-project, this repository and the executable keep their name and only the
-registry entry is spelled out.
+project, this repository and the executable keep their name and the registry
+entry carries one hyphen. **`spine-rigc` is the same package**: it is the name
+every version up to 2.20.4 shipped under, and it stays published as an alias —
+every version from 2.20.4 on is on both names, with the same files — so a
+project that depends on `spine-rigc` keeps receiving every release. A new
+project installs `rig-c`.
 
 ```bash
-bunx spine-rigc --help    # run it without installing
-bun add -g spine-rigc     # or install the command
-bun add -d spine-rigc     # or pin it in a project
+bunx rig-c --help    # run it without installing
+bun add -g rig-c     # or install the command
+bun add -d rig-c     # or pin it in a project
 ```
 
-`npx spine-rigc` works too, as long as Bun is on `PATH` — the executable is a
+`npx rig-c` works too, as long as Bun is on `PATH` — the executable is a
 Bun script, and npm only writes the shim that calls it.
 
 Installed, the command is `rigc`. The examples below spell it `bun cli.ts`
@@ -194,7 +199,7 @@ plugin marketplace:
 /plugin install rigc@rigc
 ```
 
-With the package already installed, `claude --plugin-dir node_modules/spine-rigc`
+With the package already installed, `claude --plugin-dir node_modules/rig-c`
 loads the same skills without a marketplace. The plugin carries no version of its
 own — `/plugin update` follows `main` commit by commit, and the only version on
 disk stays the one in `package.json`.
@@ -206,12 +211,12 @@ Codex, Gemini CLI and Antigravity read skills from one directory in the workspac
 `node_modules`. With the package installed, one command puts every skill there:
 
 ```shell
-bun add -d spine-rigc
-bun rigc skills install          # relative links: .agents/skills/rigc -> ../../node_modules/spine-rigc/skills/rigc
+bun add -d rig-c
+bun rigc skills install          # relative links: .agents/skills/rigc -> ../../node_modules/rig-c/skills/rigc
 bun rigc skills install --copy   # the folders themselves, for a host that does not follow a link
 ```
 
-Run it through the project's own install, as above: `bunx spine-rigc skills install`
+Run it through the project's own install, as above: `bunx rig-c skills install`
 in a project that has the package was measured running the registry's copy instead
 of the project's. A link reaches every upgrade of the package with no second run,
 and a second run has nothing to do; an entry already there that this command did not
@@ -242,11 +247,11 @@ reference export, so nothing you read in a quickstart is an answer to anything
 **1. Install the command.**
 
 ```bash
-bun add -g spine-rigc     # installs `rigc`
+bun add -g rig-c     # installs `rigc`
 ```
 
 Or skip the install and prefix every command below with `bunx `, e.g.
-`bunx spine-rigc build …`.
+`bunx rig-c build …`.
 
 **2. Make a directory and three plates.** rigc measures PNGs rather than trusting
 a number you typed (R5), so the art has to exist. These three are solid colours a
@@ -450,7 +455,7 @@ that does not belong to it. See
   field by field, the emission rules, every named failure mapped to the file that
   has to change, and §8–§9 for reproducing a shot you were given as pictures. It
   ships inside the npm package too, at
-  `node_modules/spine-rigc/docs/AUTHORING.md`.
+  `node_modules/rig-c/docs/AUTHORING.md`.
 - `rigc explain --rig buoy.rig.json --motion buoy.motion.json --out spine` prints
   the compiled rig as a table — every bone with its resolved parent, the slots in
   draw order, every timeline key by key — and writes nothing. It is what to reach
@@ -744,7 +749,7 @@ letting `A17` blame the editor for the harness's own doing.
 
 | Document | For |
 | --- | --- |
-| 📘 **[docs/AUTHORING.md](docs/AUTHORING.md)** | **the format guide, and the one to read before writing a spec.** Both input files field by field with a complete minimal example each, every field with its Spine meaning, the rules that decide what is emitted, the build → read the report → fix → repeat loop, the map from every named failure to the file that has to change, and the features rigc refuses by name so you do not spend a loop discovering them. It travels **inside the npm package**, at `node_modules/spine-rigc/docs/AUTHORING.md` |
+| 📘 **[docs/AUTHORING.md](docs/AUTHORING.md)** | **the format guide, and the one to read before writing a spec.** Both input files field by field with a complete minimal example each, every field with its Spine meaning, the rules that decide what is emitted, the build → read the report → fix → repeat loop, the map from every named failure to the file that has to change, and the features rigc refuses by name so you do not spend a loop discovering them. It travels **inside the npm package**, at `node_modules/rig-c/docs/AUTHORING.md` |
 | 🦴 **[docs/RIGGING.md](docs/RIGGING.md)** | **authoring the hierarchy.** Where a bone goes and why the art is pushed out on an offset, why a pivot in the wrong place looks like a search failure and what identifies one, moving a pivot and the child row that gets forgotten, gauges, siblings-not-a-chain, what a chain can reach and how many links it needs, why a local key is not a world key, duplicate art at mirrored pivots, and constraints as structure. Every section is a stumble the run records hold more than once, ranked by how often. Ships in the package too |
 | 🎞️ **[docs/MOTION.md](docs/MOTION.md)** | **the key-pose recipe.** How to get two poses, what a pair of poses does and does not fix, the in-betweening rules and where each comes from, and how to spread candidates so a ballot informs. Ships in the package too |
 | 🙂 **[docs/FACE.md](docs/FACE.md)** | **authoring a face.** A blink, a gaze and a 2.5D head turn on plain Spine data: the one line of yaw arithmetic every number in a turn comes from, depth as the parameter you are actually authoring, where to put a grid's columns and the angle at which any grid folds, what foreshortens and what does not, channel allocation before the first key, and the three cliffs with their angles. Also the deform audit gap, demonstrated — a folded mesh gates green — and the differential check that works today |

package/docs/AUTHORING.md

@@ -275,14 +275,14 @@ for `vote` (default `ballot.html`).
 `skills install` is the one command that is not about a rig: it puts the agent
 skills the package ships where an agent host looks for them. Run it through the
 project's own install — `bun rigc skills install` — so the links point into that
-project's `node_modules/spine-rigc/skills/`. A second run has nothing to do and
+project's `node_modules/rig-c/skills/`. A second run has nothing to do and
 exits 0. An entry already at `<dir>/<name>` that is not a link to the same folder
 (or, under `--copy`, not the same bytes) is refused, exit 1, and **nothing is
 written** — every such entry is named with what is there and what was required:
 
 ```text
 rigc skills install: <n> of the <m> skill(s) cannot be installed into <dir>, and nothing was written:
-  <dir>/rigc-motion is a plain file; a symlink to ../../node_modules/spine-rigc/skills/rigc-motion was required
+  <dir>/rigc-motion is a plain file; a symlink to ../../node_modules/rig-c/skills/rigc-motion was required
 Remove the entries named above, or pass --dir to install somewhere else.
 ```
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "rig-c",
-  "version": "2.21.0",
+  "version": "2.23.0",
   "description": "AI-authored Spine 2D rigging and animation, verified before it is written. rigc compiles a rig spec into Spine 4.3 skeleton data, gates it with named assertions held to a spine-core round trip's verdicts, and emits nothing that fails. Output imports into the Spine editor. Ships as an agent skill.",
   "type": "module",
   "bin": {

package/skills/rigc/SKILL.md

@@ -2,7 +2,7 @@
 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 with named assertions 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.
+compatibility: Requires Bun 1.2 or later. The tool is the npm package rig-c (bunx rig-c, or bun add -d rig-c); the command it installs is rigc.
 ---
 
 # rigc — a rig compiler for agents
@@ -35,8 +35,8 @@ whole interface, and this skill only says which of them to open.
 ## Install
 
 ```shell
-bunx spine-rigc --help       # run it without installing
-bun add -d spine-rigc        # or pin it in the project; the command is `rigc`
+bunx rig-c --help       # run it without installing
+bun add -d rig-c        # or pin it in the project; the command is `rigc`
 bun rigc skills install      # then link these skills into .agents/skills
 ```
 
@@ -126,8 +126,8 @@ spec files field by field, the emission rules, the loop, and the failure map. Th
 | a **skeleton.json somebody else authored** — read it, repair it, extend it | [INGEST.md](https://github.com/firejune/rigc/blob/main/docs/INGEST.md) | `rigc-ingest` |
 | you are the **person operating** the agent rather than the agent | [PROMPTING.md](https://github.com/firejune/rigc/blob/main/docs/PROMPTING.md) | — |
 
-Every guide linked here is in the installed package at `node_modules/spine-rigc/docs/`,
+Every guide linked here is in the installed package at `node_modules/rig-c/docs/`,
 which is the copy that matches the rigc you run; the links go to the repository's
 `main`. Inside the Claude Code plugin the same files are at `${CLAUDE_PLUGIN_ROOT}/docs/`.
 Formats, the CLI reference and the licence chain:
-[README.md](https://github.com/firejune/rigc/blob/main/README.md), installed at `node_modules/spine-rigc/README.md`.
+[README.md](https://github.com/firejune/rigc/blob/main/README.md), installed at `node_modules/rig-c/README.md`.

package/skills/rigc-face/SKILL.md

@@ -2,7 +2,7 @@
 name: rigc-face
 description: Author a face on plain Spine data with rigc — a blink, a gaze shift, a breathing portrait and a head turn a few degrees off axis, built from deform timelines and per-part parallax. Use when the request is a talking or living portrait, a standing character, an expression or a head turn, such as "rig this face", "make the portrait blink and look around" or "turn the head". Not for Live2D file conversion, cutting a face illustration into parts, or VTuber-style real-time face tracking.
 license: MIT
-compatibility: Requires Bun 1.2 or later and the npm package spine-rigc.
+compatibility: Requires Bun 1.2 or later and the npm package rig-c.
 ---
 
 # Face — a turn, a gaze and a blink
@@ -52,7 +52,7 @@ differential audit and the three limits it does not lift.
    rather than this closed form, and [INGEST.md](https://github.com/firejune/rigc/blob/main/docs/INGEST.md) if the head
    arrived as a compiled skeleton.
 
-Every guide linked here is in the installed package at `node_modules/spine-rigc/docs/`,
+Every guide linked here is in the installed package at `node_modules/rig-c/docs/`,
 which is the copy that matches the rigc you run; the links go to the repository's
 `main`. Inside the Claude Code plugin the same files are at `${CLAUDE_PLUGIN_ROOT}/docs/`.
 

package/skills/rigc-ingest/SKILL.md

@@ -2,7 +2,7 @@
 name: rigc-ingest
 description: Work with a Spine skeleton.json somebody else authored — exported from the Spine editor or another tool — using rigc. Read and validate it, understand a complaint rigc raised about it, decompile it into rigc specs with `rigc ingest`, normalise, re-pivot or rename it, and extend it with an animation it does not have. Use when the input is an existing skeleton.json with its .atlas and page images rather than loose part PNGs. Not for Live2D file conversion or runtime tracking.
 license: MIT
-compatibility: Requires Bun 1.2 or later and the npm package spine-rigc.
+compatibility: Requires Bun 1.2 or later and the npm package rig-c.
 ---
 
 # Ingest — a skeleton you did not author
@@ -70,7 +70,7 @@ thing to reach for; transcription by hand is what you fall back on for a constru
 3. Then [RIGGING.md](https://github.com/firejune/rigc/blob/main/docs/RIGGING.md) for why the re-pivot edit has the shape
    it has, and [MOTION.md](https://github.com/firejune/rigc/blob/main/docs/MOTION.md) for the animation you are adding.
 
-Every guide linked here is in the installed package at `node_modules/spine-rigc/docs/`,
+Every guide linked here is in the installed package at `node_modules/rig-c/docs/`,
 which is the copy that matches the rigc you run; the links go to the repository's
 `main`. Inside the Claude Code plugin the same files are at `${CLAUDE_PLUGIN_ROOT}/docs/`.
 

package/skills/rigc-motion/SKILL.md

@@ -2,7 +2,7 @@
 name: rigc-motion
 description: Author a Spine animation with rigc from key poses — an idle, a loop, a move from one picture to another — with timing and spacing, ease in and out, anticipation, arcs, overlap, follow-through, squash and stretch, and candidate variants a person can choose between. Use when the request is a movement on an existing or planned rig, in the animator's words too: "animate this rig", "make it breathe", "go from pose A to pose B", "make it feel heavier", "the cape should follow through". Not for Live2D, separating an image into parts, or real-time tracking.
 license: MIT
-compatibility: Requires Bun 1.2 or later and the npm package spine-rigc.
+compatibility: Requires Bun 1.2 or later and the npm package rig-c.
 ---
 
 # Motion — what goes between two poses
@@ -43,7 +43,7 @@ thing that judges a movement is a person's eye through `rigc vote` — MOTION §
    head turn; [INGEST.md](https://github.com/firejune/rigc/blob/main/docs/INGEST.md) if the rig arrived as a compiled
    skeleton rather than loose parts.
 
-Every guide linked here is in the installed package at `node_modules/spine-rigc/docs/`,
+Every guide linked here is in the installed package at `node_modules/rig-c/docs/`,
 which is the copy that matches the rigc you run; the links go to the repository's
 `main`. Inside the Claude Code plugin the same files are at `${CLAUDE_PLUGIN_ROOT}/docs/`.
 

package/skills/rigc-rigging/SKILL.md

@@ -2,7 +2,7 @@
 name: rigc-rigging
 description: Decide a Spine rig's hierarchy with rigc — how many bones, where each pivot sits, what hangs off what, offsets, chains and what a chain can reach, siblings versus chains, constraints as structure — and which of those decisions the reference frames can check. Use when the request is a skeleton from loose part PNGs, such as "rig these parts", "make a Spine skeleton" or "where do the joints go", before any motion is authored. Not for Live2D, cutting an illustration into parts, or VTuber-style tracking.
 license: MIT
-compatibility: Requires Bun 1.2 or later and the npm package spine-rigc.
+compatibility: Requires Bun 1.2 or later and the npm package rig-c.
 ---
 
 # Rigging — the hierarchy itself
@@ -41,7 +41,7 @@ are named in RIGGING §11 — neither as a pass bar.
    [INGEST.md](https://github.com/firejune/rigc/blob/main/docs/INGEST.md) if the skeleton was handed to you already
    compiled.
 
-Every guide linked here is in the installed package at `node_modules/spine-rigc/docs/`,
+Every guide linked here is in the installed package at `node_modules/rig-c/docs/`,
 which is the copy that matches the rigc you run; the links go to the repository's
 `main`. Inside the Claude Code plugin the same files are at `${CLAUDE_PLUGIN_ROOT}/docs/`.
 

package/src/areaband.ts

@@ -8,7 +8,7 @@
  * — and `stretchSingularValues` after them (issue #1230), for the motion
  * comparison (`src/meshcompare.ts`), which reads a triangle's stretch the way
  * the deform survey does and must not reach the compiler either.
- * They moved because a module the `spine-rigc/mesh` entry reaches has to read
+ * They moved because a module the `rig-c/mesh` entry reaches has to read
  * the same band, and `src/deformsurvey.ts` reaches the compiler and the core
  * (`src/deformstructure.ts`, `src/core/`) — a geometry entry that loaded the
  * compiler to read three numbers would also close an import cycle through

package/src/cli/shared.ts

@@ -905,7 +905,7 @@ export const DEFAULT_LEDGER = 'votes.jsonl';
 // skills install — put the shipped skills where an agent host looks (issue #831)
 // ---------------------------------------------------------------------------
 //
-// After `bun add -d spine-rigc` the skills sit at `node_modules/spine-rigc/skills/`,
+// After `bun add -d rig-c` the skills sit at `node_modules/rig-c/skills/`,
 // which no host reads. Codex, Gemini CLI and Antigravity all read
 // `<workspace>/.agents/skills/<name>/`, so this links every `skills/<name>/` the
 // package ships into one directory — `.agents/skills` under the working

package/src/mesh.ts

@@ -46,7 +46,7 @@ import type { ModelBinding, ModelVertices } from './model.ts';
 
 // The mesh-quality measurement and its report (issue #1224) live in their own
 // module and reach a dependant through this file, which is what
-// `spine-rigc/mesh` names. That module imports helpers from this one, so the
+// `rig-c/mesh` names. That module imports helpers from this one, so the
 // two form an import cycle: safe only because neither reads the other's
 // bindings while it is being evaluated — every use is inside a function.
 // The reduction (`reduceMesh`, stage B2 of #1224) sits in the same cycle, by
@@ -163,7 +163,7 @@ export class MeshError extends Error {}
  * ⚠️ Defined here and not in `src/meshquality.ts`, because that module imports
  * this one and this one re-exports it: a class that extends `MeshError` at the
  * top of the importing module would read `MeshError` before this module had
- * run, and every import of `spine-rigc/mesh` would throw.
+ * run, and every import of `rig-c/mesh` would throw.
  */
 export class MeshReductionError extends MeshError {
   readonly code: string;
@@ -1253,8 +1253,9 @@ export function traceAlphaOutline(
  * `background` is how the flood steps: 4 through edges, 8 through corners too.
  * The trace floods 8 — the dual of its 4-connected island, so background that
  * meets the outside at a corner is outside — and says why where it calls this.
- * The authored-mesh measurement floods 4, as it always has; the two agree on
- * every mask the trace accepts.
+ * The authored-mesh measurement floods 4 by default, as it always has, and 8
+ * when its caller asks (issue #1262); the two agree on every mask the trace
+ * accepts.
  */
 export function fillEnclosed(
   inside: Uint8Array,
@@ -1479,16 +1480,57 @@ export interface MeshFitReport {
  * is never refused, so every figure needs a number — hence the exact distance
  * transform below rather than a neighbourhood search that would have to stop
  * somewhere.
+ *
+ * ## Which background is enclosed — `connectivity` (issue #1262)
+ *
+ * The background is flooded 4-connected by default, as it always has been, so
+ * every call that passes four arguments reads exactly what it read before.
+ * `8` floods through corners too — the fill `measureMeshQuality`'s
+ * `MQ_OVERSHOOT` and `MQ_HOLES` rows are taken against (P12), by the same
+ * `fillEnclosed` call — so a background pocket joined to the outside only
+ * diagonally is read as outside, and a caller gating with this figure reads
+ * the number the rows read. The two fills agree on every mask without such a
+ * pocket. Any other value is refused by name: a silent fallback to one of the
+ * two would answer a question the caller did not ask.
  */
 export function measureAuthoredMeshFit(
   mask: AlphaMask,
   threshold: number,
   points: Array<[number, number]>,
   triangles: number[],
+  connectivity: 4 | 8 = 4,
 ): MeshFitReport {
+  return authoredMeshFitOf(mask, threshold, points, triangles, connectivity, null).report;
+}
+
+/**
+ * A fault planted on purpose in `authoredMeshFitOf`, for the mesh-quality
+ * suite's negative control: `'fill-4-under-8'` takes the connectivity it is
+ * passed and floods 4 whatever it was. `measureAuthoredMeshFit` plants none.
+ */
+export type AuthoredFitPlant = 'fill-4-under-8';
+
+/**
+ * `measureAuthoredMeshFit`'s measurement, with the pixel its overshoot is
+ * read at — the first covered pixel outside the filled silhouette at the
+ * largest distance, by the tie rule `MQ_OVERSHOOT` names its pixel with, or
+ * -1 when no covered pixel lies outside — so a control can name where two
+ * readings part.
+ */
+export function authoredMeshFitOf(
+  mask: AlphaMask,
+  threshold: number,
+  points: Array<[number, number]>,
+  triangles: number[],
+  connectivity: 4 | 8,
+  plant: AuthoredFitPlant | null,
+): { report: MeshFitReport; overshootAt: number } {
+  if (connectivity !== 4 && connectivity !== 8) {
+    throw new MeshError(`measureAuthoredMeshFit: connectivity is ${JSON.stringify(connectivity)}; required 4 (the default, the legacy fill) or 8 (the fill MQ_OVERSHOOT reads, P12)`);
+  }
   const { width: w, height: h } = mask;
   const art = artOf(mask, threshold);
-  const { filled } = fillEnclosed(art, w, h, 4);
+  const { filled } = fillEnclosed(art, w, h, plant === 'fill-4-under-8' ? 4 : connectivity);
   const covered = rasteriseTriangles(points, triangles, w, h);
   let artPixels = 0;
   let coveredArt = 0;
@@ -1499,15 +1541,22 @@ export function measureAuthoredMeshFit(
   }
   const squared = squaredDistanceToSet(filled, w, h);
   let worst = 0;
+  let overshootAt = -1;
   for (let i = 0; i < covered.length; i++) {
     if (!covered[i] || filled[i]) continue;
-    if (squared[i] > worst) worst = squared[i];
+    if (overshootAt === -1 || squared[i] > worst) {
+      overshootAt = i;
+      worst = squared[i];
+    }
   }
   return {
-    artPixels,
-    coveredArt,
-    coverage: artPixels === 0 ? 0 : coveredArt / artPixels,
-    overshoot: r6(Math.sqrt(worst)),
+    report: {
+      artPixels,
+      coveredArt,
+      coverage: artPixels === 0 ? 0 : coveredArt / artPixels,
+      overshoot: r6(Math.sqrt(worst)),
+    },
+    overshootAt,
   };
 }
 

package/src/meshquality.ts

@@ -32,7 +32,8 @@
  *   taken at (`MeasureRow.art.threshold`); a measurement claims nothing at any
  *   other.
  * - **Change the legacy fit.** `measureAuthoredMeshFit` (`src/mesh.ts`) keeps
- *   its 4-connected fill for every existing caller. The rows here fill with the
+ *   its 4-connected fill for every existing caller (its `connectivity: 8`,
+ *   issue #1262, is the fill the rows read). The rows here fill with the
  *   tracer's 8-connected background flood over all art (P12), and where the two
  *   fills differ — a diagonal pinch — both labelled results are rows.
  * - **Pose, or link the runtime.** Pure: no clock, no randomness, no network,
@@ -694,8 +695,21 @@ function validateInput(input: MeshMeasureInput): void {
 
 type Pt = readonly [number, number];
 
-/** Is `p` inside or on the closed polygon? On the boundary within `ON_BOUNDARY` counts as inside. */
-function inClosedPolygon(p: Pt, poly: readonly Pt[]): boolean {
+/**
+ * Is `p` inside or on the closed polygon? On the boundary within `ON_BOUNDARY` counts as inside.
+ *
+ * The rule, exactly, because `closedPolygonCentres` reproduces it bit for bit:
+ * `p` is in when its `distanceToSegment` to some side `poly[i]`–`poly[i+1]`
+ * is at most `ON_BOUNDARY` (1e-9 px) — a point on an edge or at a vertex is in,
+ * whatever the ray says; otherwise by **even-odd** parity of a ray towards +x,
+ * where the side from `poly[j]` to `poly[i]` (`j` the one before `i`) crosses
+ * when exactly one of its ends has a y strictly greater than `p`'s — `yi > py`
+ * differs from `yj > py`, so the half-open rule counts a vertex at `p`'s height
+ * once and a horizontal side never — at
+ * `xc = ((xj − xi)·(py − yi)) / (yj − yi) + xi`, and the crossing counts when
+ * `px < xc` strictly.
+ */
+export function inClosedPolygon(p: Pt, poly: readonly Pt[]): boolean {
   const n = poly.length;
   for (let i = 0; i < n; i++) if (distanceToSegment(p, poly[i], poly[(i + 1) % n]) <= ON_BOUNDARY) return true;
   let inside = false;
@@ -707,6 +721,112 @@ function inClosedPolygon(p: Pt, poly: readonly Pt[]): boolean {
   return inside;
 }
 
+/**
+ * A fault planted on purpose in `closedPolygonCentres`, for the mesh-quality
+ * suite's negative control: `'crossing-half-pixel'` moves every ray crossing
+ * half a pixel towards +x. `regionRows` plants none.
+ */
+export type ScanlinePlant = 'crossing-half-pixel';
+
+/**
+ * Which pixel centres of a `w`×`h` grid lie in or on a closed polygon given
+ * in drawing px — `inClosedPolygon` of every centre `((x + 0.5) / scale,
+ * (y + 0.5) / scale)`, 1 where it is true, by scanline (issue #1263).
+ *
+ * The same decision, not a cleaner one: each row's crossings are the sides
+ * `inClosedPolygon` counts for that row's centre height, by its own
+ * half-open test, at the `xc` it computes with the same expression in the same
+ * order, so they are the same doubles; sorted, the number of them a centre
+ * lies strictly left of is the number its ray counts, and its parity is the
+ * answer. The boundary band is then added side by side, each centre near a
+ * side tested with `distanceToSegment` against `ON_BOUNDARY` — the predicate's
+ * own test — so a centre on an edge or at a vertex is in exactly when the
+ * predicate says so. The rows and columns visited around a side are widened by
+ * a pixel past where it can reach, and only the exact tests decide.
+ *
+ * O(rows × sides + pixels) where testing every centre against every side is
+ * O(pixels × sides).
+ */
+export function closedPolygonCentres(poly: readonly Pt[], w: number, h: number, scale: number, plant: ScanlinePlant | null = null): Uint8Array {
+  const marks = new Uint8Array(w * h);
+  const n = poly.length;
+  if (n === 0 || w <= 0 || h <= 0) return marks;
+  const cx = (x: number): number => (x + 0.5) / scale;
+  const cy = (y: number): number => (y + 0.5) / scale;
+  const shift = plant === 'crossing-half-pixel' ? 0.5 / scale : 0;
+  /** The grid row or column of a drawing coordinate, rounded one way and widened by `slack`; NaN visits nothing. */
+  const cellOf = (v: number, round: (u: number) => number, slack: number, size: number): number => {
+    const c = round(v * scale - 0.5) + slack;
+    if (Number.isNaN(c)) return slack < 0 ? size : -1;
+    return c;
+  };
+
+  // Even-odd: per row, the crossings of a ray towards +x from the row's centre height.
+  const crossings: Array<number[] | undefined> = new Array<number[] | undefined>(h);
+  for (let i = 0, j = n - 1; i < n; j = i++) {
+    const [xi, yi] = poly[i];
+    const [xj, yj] = poly[j];
+    const y0 = Math.max(0, cellOf(Math.min(yi, yj), Math.floor, -1, h));
+    const y1 = Math.min(h - 1, cellOf(Math.max(yi, yj), Math.ceil, 1, h));
+    for (let y = y0; y <= y1; y++) {
+      const py = cy(y);
+      if (yi > py !== yj > py) {
+        let row = crossings[y];
+        if (row === undefined) {
+          row = [];
+          crossings[y] = row;
+        }
+        row.push(((xj - xi) * (py - yi)) / (yj - yi) + xi + shift);
+      }
+    }
+  }
+  for (let y = 0; y < h; y++) {
+    const row = crossings[y];
+    if (row === undefined) continue;
+    row.sort((a, b) => a - b);
+    const x0 = Math.max(0, cellOf(row[0], Math.floor, -1, w));
+    const x1 = Math.min(w - 1, cellOf(row[row.length - 1], Math.ceil, 1, w));
+    let left = 0;
+    for (let x = x0; x <= x1; x++) {
+      const px = cx(x);
+      while (left < row.length && !(px < row[left])) left++;
+      if ((row.length - left) & 1) marks[y * w + x] = 1;
+    }
+  }
+
+  // On the boundary: within ON_BOUNDARY of a side. Per side, the rows its ends span and, per row, the columns
+  // the side passes within a pixel of that row's centre height, each widened by a pixel; the exact test decides.
+  const unit = 1 / scale;
+  for (let i = 0; i < n; i++) {
+    const a = poly[i];
+    const b = poly[(i + 1) % n];
+    const y0 = Math.max(0, cellOf(Math.min(a[1], b[1]), Math.floor, -1, h));
+    const y1 = Math.min(h - 1, cellOf(Math.max(a[1], b[1]), Math.ceil, 1, h));
+    const dy = b[1] - a[1];
+    for (let y = y0; y <= y1; y++) {
+      let lo = Math.min(a[0], b[0]);
+      let hi = Math.max(a[0], b[0]);
+      if (dy !== 0) {
+        const py = cy(y);
+        const t0 = Math.max(0, Math.min(1, (py - unit - a[1]) / dy));
+        const t1 = Math.max(0, Math.min(1, (py + unit - a[1]) / dy));
+        const xa = a[0] + (b[0] - a[0]) * t0;
+        const xb = a[0] + (b[0] - a[0]) * t1;
+        lo = Math.min(xa, xb);
+        hi = Math.max(xa, xb);
+      }
+      const x0 = Math.max(0, cellOf(lo, Math.floor, -1, w));
+      const x1 = Math.min(w - 1, cellOf(hi, Math.ceil, 1, w));
+      for (let x = x0; x <= x1; x++) {
+        const k = y * w + x;
+        if (marks[k]) continue;
+        if (distanceToSegment([cx(x), cy(y)], a, b) <= ON_BOUNDARY) marks[k] = 1;
+      }
+    }
+  }
+  return marks;
+}
+
 /** Does the segment `a`–`b` meet the closed polygon — an endpoint inside or on it, or any crossing or touch? */
 function segmentMeetsPolygon(a: Pt, b: Pt, poly: readonly Pt[]): boolean {
   if (inClosedPolygon(a, poly) || inClosedPolygon(b, poly)) return true;
@@ -1154,7 +1274,7 @@ export function measureMeshQuality(input: MeshMeasureInput): MeshQualityReport {
  * taken from another art are refused (`REDUCE_ART_RASTERS_MISMATCH`), never
  * read.
  *
- * Internal: it is on `spine-rigc/mesh` only because that entry re-exports this
+ * Internal: it is on `rig-c/mesh` only because that entry re-exports this
  * module with `export *`, and a symbol that is merely exported is not promised
  * (RELEASING.md, *The import surface*).
  */
@@ -1673,8 +1793,10 @@ function regionRows(input: MeshMeasureInput, outline: MeshOutline, hullPolygon:
     // would keep, in the same order.
     const centreOf = (i: number): Pt => [((i % mask.width) + 0.5) / scale, (Math.floor(i / mask.width) + 0.5) / scale];
     const inRegion = (): Int32Array => {
+      // `inClosedPolygon` of every art pixel centre, by scanline (`closedPolygonCentres`, issue #1263).
+      const inside = closedPolygonCentres(poly, mask.width, mask.height, scale);
       const kept: number[] = [];
-      for (let i = 0; i < artBits.length; i++) if (artBits[i] && inClosedPolygon(centreOf(i), poly)) kept.push(i);
+      for (let i = 0; i < artBits.length; i++) if (artBits[i] && inside[i]) kept.push(i);
       return Int32Array.from(kept);
     };
     const regionPixels = steps === null ? inRegion() : steps.regionPixels(poly, inRegion);

package/src/meshrasters.ts

@@ -31,7 +31,7 @@
  * the value the rasters were taken at and the value the input requires
  * (`checkArtRasters`, `src/meshquality.ts`).
  *
- * Not re-exported by `src/mesh.ts`: nothing here is on `spine-rigc/mesh`.
+ * Not re-exported by `src/mesh.ts`: nothing here is on `rig-c/mesh`.
  */
 import { artOf, distancePassesOf, fillEnclosed, labelIslands, MeshError, pixelCentreInTriangle, prunePolygon, squaredDistanceToSet, traceAlphaOutline, triangleRasterBox } from './mesh.ts';
 import type { ArtInput } from './meshquality.ts';

package/src/meshreduce.ts

@@ -1211,7 +1211,7 @@ export function reduceMesh(input: MeshReductionInput): MeshReductionResult {
  * which is the path the carried one is held equal to. Step rasters made over
  * another rasters object are refused by the same code.
  *
- * Internal: it is on `spine-rigc/mesh` only because that entry re-exports this
+ * Internal: it is on `rig-c/mesh` only because that entry re-exports this
  * module with `export *`, and a symbol that is merely exported is not promised
  * (RELEASING.md, *The import surface*).
  */