rig-parts 0.16.0 → 1.0.0

package/NOTICE.md

@@ -1,9 +1,9 @@
 # Third-party notices
 
-spine-parts' own code is MIT (see `LICENSE`). It depends on, reads the output
+rig-parts' own code is MIT (see `LICENSE`). It depends on, reads the output
 of, or reimplements the behaviour of the third-party work below, each under its
 own terms. Naming a project here identifies where something comes from; it does
-not imply that its authors endorse spine-parts.
+not imply that its authors endorse rig-parts.
 
 Every statement below is either quoted from the named source or marked
 **[observed]** with the date and the place it was read. Upstream terms can
@@ -11,10 +11,10 @@ change; check the source when it matters.
 
 ## 1. See-through
 
-spine-parts takes See-through's output as its input. **spine-parts does not
+rig-parts takes See-through's output as its input. **rig-parts does not
 vendor, embed or redistribute See-through code or weights**: the user runs
 See-through by one of the routes in the README (*See-through routes*) and points
-spine-parts at what it wrote.
+rig-parts at what it wrote.
 
 - Project: [shitagaki-lab/see-through](https://github.com/shitagaki-lab/see-through)
 - Paper: Jian Lin, Chengze Li, Haoyun Qin, Kwun Wang Chan, Yanghua Jin, Hanyuan
@@ -31,7 +31,7 @@ spine-parts at what it wrote.
   repository (`LICENSE` on the default branch `master` returns 404, and GitHub
   reports no licence); `pyproject.toml` declares `license = "MIT"`.
 
-spine-parts reads the wrapper's `layers.json` manifest format; it contains no
+rig-parts reads the wrapper's `layers.json` manifest format; it contains no
 wrapper code.
 
 ### Weights
@@ -46,52 +46,52 @@ wrapper code.
 Maintainer statement, on the Hugging Face discussion
 [`layerdifforg/seethroughv0.0.2_layerdiff3d/discussions/1`](https://huggingface.co/layerdifforg/seethroughv0.0.2_layerdiff3d/discussions/1)
 (user `24yearsold`, 2026-04-07): *"Yes all our models are aligned with our main
-repo to use Apache 2.0."* The 2026-09-28 card revision above narrows that: Apache-2.0 for the maintainers' contributions, with the base models' Open RAIL terms inherited. spine-parts does not distribute these weights; a user who fetches them accepts the terms the card states on the day they fetch.
+repo to use Apache 2.0."* The 2026-09-28 card revision above narrows that: Apache-2.0 for the maintainers' contributions, with the base models' Open RAIL terms inherited. rig-parts does not distribute these weights; a user who fetches them accepts the terms the card states on the day they fetch.
 
 ### Training data
 
 The paper describes its own supervision this way: *"we introduce a scalable
 engine that bootstraps high-quality supervision from commercial Live2D models,
 capturing pixel-perfect semantics and hidden geometry."* That is the paper's
-description of how See-through was trained. spine-parts does not use,
+description of how See-through was trained. rig-parts does not use,
 include or redistribute any of that data, any Live2D model, or anything derived
 from them beyond the layers See-through itself writes for the user's own image.
 
-## 2. Spine Runtimes, through spine-rigc
+## 2. Spine Runtimes, through rig-c
 
-spine-parts depends on [`spine-rigc`](https://www.npmjs.com/package/spine-rigc)
+rig-parts depends on [`rig-c`](https://www.npmjs.com/package/rig-c)
 (MIT, same author), which compiles and validates Spine skeleton data. Its round
 trip runs through `@esotericsoftware/spine-core`, part of the
 [Spine Runtimes](https://github.com/EsotericSoftware/spine-runtimes), under the
 [Spine Runtimes License Agreement](https://esotericsoftware.com/spine-runtimes-license).
-Since spine-rigc 2.0 neither package installs the runtime: spine-rigc carries it
-only as a development dependency, and an install of spine-rigc gates a build with
-its own validator. spine-parts does not install it either; it is this repository's
-development dependency, at the version spine-rigc develops against, for the round
+Since rig-c 2.0 neither package installs the runtime: rig-c carries it
+only as a development dependency, and an install of rig-c gates a build with
+its own validator. rig-parts does not install it either; it is this repository's
+development dependency, at the version rig-c develops against, for the round
 trip in the selftest and CI and the selftest's posing oracle.
-spine-rigc's [NOTICE.md](https://github.com/firejune/rigc/blob/main/NOTICE.md)
+rig-c's [NOTICE.md](https://github.com/firejune/rigc/blob/main/NOTICE.md)
 sets out the chain in full; briefly, as a restatement of Esoteric Software's
 terms and not a term of this project:
 
-1. What spine-parts produces is input to spine-rigc, whose output **is Spine
+1. What rig-parts produces is input to rig-c, whose output **is Spine
    skeleton data**.
 2. Playing Spine skeleton data in a product requires a Spine Runtime, and the
    Spine Runtimes License requires **each user of such a product to own a
    Spine Editor license**.
-3. spine-rigc no longer installs `spine-core`, and spine-parts does not either;
-   the obligation in 2 attaches to the Spine skeleton data spine-rigc writes,
-   which the stages of spine-parts that call it produce, and to `spine-core`
+3. rig-c no longer installs `spine-core`, and rig-parts does not either;
+   the obligation in 2 attaches to the Spine skeleton data rig-c writes,
+   which the stages of rig-parts that call it produce, and to `spine-core`
    wherever it is installed beside them — this repository's development
    dependency included.
 
-spine-parts also imports spine-rigc's own modules directly, by deep path: its PNG codec
+rig-parts also imports rig-c's own modules directly, by deep path: its PNG codec
 (`tools/plate.ts`, `src/png.ts`), its 5x7 label font (`tools/font5x7.ts`) and
-its coordinate conversion (`src/transform.ts`). Those are spine-rigc's MIT code.
+its coordinate conversion (`src/transform.ts`). Those are rig-c's MIT code.
 
 ## 3. Checkpoints
 
-Generating the painting is an **optional** adapter (`spine-parts comfy paint`).
-The checkpoint, any LoRA and any ControlNet it runs are the user's: spine-parts
+Generating the painting is an **optional** adapter (`rig-parts comfy paint`).
+The checkpoint, any LoRA and any ControlNet it runs are the user's: rig-parts
 ships none and downloads none, and the terms that govern an image they produce
 are the terms of those models. A painting from any other source works the same
 way.
@@ -121,7 +121,7 @@ function's comment says which call it stands in for and what was measured.
 
 | Package | Licence | Why |
 | --- | --- | --- |
-| [`spine-rigc`](https://www.npmjs.com/package/spine-rigc) | MIT | compile, gate, render and check; its PNG codec, font and coordinate conversion |
+| [`rig-c`](https://www.npmjs.com/package/rig-c) | MIT | compile, gate, render and check; its PNG codec, font and coordinate conversion |
 | [`ag-psd`](https://www.npmjs.com/package/ag-psd) | MIT | reading an upstream See-through `.psd` |
 | ↳ [`pako`](https://www.npmjs.com/package/pako) | MIT AND Zlib | ag-psd's deflate |
 | ↳ [`base64-js`](https://www.npmjs.com/package/base64-js) | MIT | ag-psd's base64 |
@@ -129,6 +129,6 @@ function's comment says which call it stands in for and what was measured.
 Development only, not installed with the package: `typescript` (Apache-2.0),
 `eslint` (MIT), `typescript-eslint` (MIT), `@types/bun` (MIT), and
 [`@esotericsoftware/spine-core`](https://www.npmjs.com/package/@esotericsoftware/spine-core)
-(Spine Runtimes License; section 2), pinned to the version spine-rigc develops
+(Spine Runtimes License; section 2), pinned to the version rig-c develops
 against (`TY10`): the round trip in the selftest and CI, the selftest's posing
 oracle, and `tools/atlas_population.ts` and `tools/idle_cost.ts`.

package/README.md

@@ -1,11 +1,11 @@
-# spine-parts
+# rig-parts
 
 **AI-authored Spine 2D character rigs from one anime painting, verified before they
-are written.** spine-parts takes a single character painting and the layers
+are written.** rig-parts takes a single character painting and the layers
 [See-through](https://github.com/shitagaki-lab/see-through) decomposed it into,
 merges them into measured rig-space parts, authors weighted meshes, bone chains
-and a looping idle over them in [spine-rigc](https://github.com/firejune/rigc)'s
-spec, and hands that spec to spine-rigc to compile, gate, pack, render and check.
+and a looping idle over them in [rig-c](https://github.com/firejune/rigc)'s
+spec, and hands that spec to rig-c to compile, gate, pack, render and check.
 It is built for agents that cannot see the image: every stage prints named,
 numeric findings, a refusal names the object, the value found and the value
 required, nothing is written after a red, and no value is invented where the
@@ -14,20 +14,21 @@ input is silent.
 ## What you get
 
 <p align="center">
-  <img src="https://raw.githubusercontent.com/firejune/spine-parts/main/assets/demo-source.png" alt="The demo painting: a generated full-body character in a white and pink frilled dress with long pink twin tails, standing with her hands clasped" height="420" />
-  <img src="https://raw.githubusercontent.com/firejune/spine-parts/main/assets/demo-idle.png" alt="The same character as a Spine rig, breathing, blinking once and swaying her hair, sleeves and skirt in a four-second loop" height="420" />
+  <img src="https://raw.githubusercontent.com/firejune/rig-parts/main/assets/demo-source.png" alt="The demo painting: a generated full-body character in a white and pink frilled dress with long pink twin tails, standing with her hands clasped" height="420" />
+  <img src="https://raw.githubusercontent.com/firejune/rig-parts/main/assets/demo-idle.png" alt="The same character as a Spine rig, breathing, blinking once and swaying her hair, sleeves and skirt in a four-second loop" height="420" />
 </p>
 
 <p align="center">
-  <img src="https://raw.githubusercontent.com/firejune/spine-parts/main/assets/demo-parts.png" alt="Contact sheet of the painting and the 22 assembled parts it was split into: hair, dress, sleeves, shoes, face, eyes, brows, mouth and ornaments" width="100%" />
+  <img src="https://raw.githubusercontent.com/firejune/rig-parts/main/assets/demo-parts.png" alt="Contact sheet of the painting and the 22 assembled parts it was split into: hair, dress, sleeves, shoes, face, eyes, brows, mouth and ornaments" width="100%" />
 </p>
 
 <p align="center"><em>
 The painting was generated for this repository with a public checkpoint (Pony
 Diffusion V6 XL) and no LoRA; its generation record, See-through layers and licence
-are in <a href="https://github.com/firejune/spine-parts-examples">spine-parts-examples</a>.
+are in <a href="https://github.com/firejune/spine-parts-examples">spine-parts-examples</a>
+(that repository keeps the name it was published under before this package's rename).
 See-through ran twice, once on the whole figure and once on a square head crop.
-Then one command: <code>spine-parts build --seam silhouette --loop</code>. The
+Then one command: <code>rig-parts build --seam silhouette --loop</code>. The
 proposer's bones, meshes, regions and motion were used <b>unedited</b>. Two input-stage
 edits were made by hand for the reference run this example reproduces: the head box
 was shifted down into the canvas (its proposal ran 118 px above the top edge;
@@ -41,19 +42,19 @@ is taken from the full run, because the twin tails leave the head crop sideways
 <code>--seam silhouette</code> repaired the navy blobs the default rule leaves on the white
 blouse (recomposite error pixels 11,050 → 9,540); the default stays
 <code>near-white</code>, the reference implementation's rule, so the examples stay
-comparable with it. The loop is <code>spine-parts loop --palette</code>'s indexed APNG, 48 frames at
+comparable with it. The loop is <code>rig-parts loop --palette</code>'s indexed APNG, 48 frames at
 12 fps, 1,706,719 bytes, one 256-entry palette at a measured error of max 57, mean 1.601
 per channel over every frame (the lossless APNG beside it, the exactness record, is
 13,645,503 bytes; the GIF, at the same error, 1,812,288). Frame 29 (2.417 s) is the
 closed eye: the blink holds for 0.084 s, one 12 fps frame rounded up, where the
 reference implementation held 0.04 s and no frame of its loop showed the eyes shut
 (issue #32); the painting is shown at half size, resampled and written
-by this package's PNG codec (nothing here encodes JPEG). <code>spine-parts sheet</code>
+by this package's PNG codec (nothing here encodes JPEG). <code>rig-parts sheet</code>
 made the contact sheet.
 </em></p>
 
 <p align="center">
-  <img src="https://raw.githubusercontent.com/firejune/spine-parts/main/assets/sample-parts.png" alt="Contact sheet of the sample character's painting and its 20 parts" width="560" />
+  <img src="https://raw.githubusercontent.com/firejune/rig-parts/main/assets/sample-parts.png" alt="Contact sheet of the sample character's painting and its 20 parts" width="560" />
 </p>
 
 <p align="center"><em>
@@ -86,7 +87,7 @@ is this port's own build (<a href="examples/scarf/README.md">examples/scarf</a>)
     the stacking order being the draw order.
 - **A character config** (`config.json`) — the part plan, the head box, the bones,
   which bones may pull which layer, the idle's sines, and optionally `constraints`
-  in spine-rigc's own rig-spec shape (ik, transform, path, physics, slider), handed
+  in rig-c's own rig-spec shape (ik, transform, path, physics, slider), handed
   to rigc as written once every bone they name resolves; a scene target is a bone
   under `root` a constraint names. `src/config.ts` is its
   schema and documents every field; the loader refuses an unknown or a missing field
@@ -96,14 +97,14 @@ is this port's own build (<a href="examples/scarf/README.md">examples/scarf</a>)
 
 ## What it gives out
 
-`spine-parts build` ends the way a Spine editor export does — with **one packed atlas
+`rig-parts build` ends the way a Spine editor export does — with **one packed atlas
 page** (issue #2):
 
 | path under `--out` | what |
 | --- | --- |
 | `check/build/skeleton.json`, `skeleton.atlas`, `skeleton.png` | **the artifact** — Spine 4.3 skeleton data and one packed page, written by `rigc build --pack --page-edges free --pack-shape polygon` and gated under `spine-html`, which holds every rule `spine` measures (on the demo, rigc 2.1.3 and 2.10.1: the 14 rules `validate --profile spine` measures are among the build's 24; 16 are not in `spine`) |
 | `parts/*.png`, `parts.json`, `recomposite_rig.png`, `recomposite_error_rig.png` | the loose parts, each cropped to its alpha box; the record of where every part came from, how many of its pixels were re-taken from the painting, and the recomposite's uncovered holes with their boxes; the flat stack of parts; its error map — red where no part covers a pixel the painting has, blue where a part covers it in the wrong colour |
-| `rig/` | `rig.json` and `motion.json` in spine-rigc's spec, `mesh_report.json`, the padded `images/` |
+| `rig/` | `rig.json` and `motion.json` in rig-c's spec, `mesh_report.json`, the padded `images/` |
 | `check/` | both gate files verbatim, the idle's frames and their `geometry.json` (skinned vertices per frame), `contact.png`, `motion_heat.png`, `check.json` (with `pack_mode`, the `--page-edges` and `--pack-shape` the page was packed under) |
 | `idle.png`, `idle-indexed.png`, `idle.gif` | with `--loop`: the idle as a lossless APNG (the exactness record), an indexed APNG with one shared palette (the small one) and a GIF; the last two print their palette error |
 
@@ -130,7 +131,7 @@ consumer that mipmaps or repeats the page; it writes exactly the page builds wro
 before the flag existed. The measurements are in
 [AUTHORING §5, *Page edges*](docs/AUTHORING.md#5-after-each-stage-what-to-read).
 
-The pack shape is `polygon` by default (spine-rigc 2.1): a region only meshes draw is
+The pack shape is `polygon` by default (rig-c 2.1): a region only meshes draw is
 packed by its emitted hull, so a neighbour may sit inside its rectangle where the hull
 is not; a region attachment stays its rectangle. On the two examples that takes the
 free page from 967x1338 to 922x1348 (covered 91.2 % to 95.0 %, 3.9 % less area) and
@@ -140,32 +141,32 @@ already has: every idle frame within 1 level of the `rect` build's, and no figur
 0.7.0 wrote. The measurements are in
 [AUTHORING §5, *Pack shape*](docs/AUTHORING.md#5-after-each-stage-what-to-read).
 
-The packer is spine-rigc's, and no other: a packed region is a lossless copy, and an
+The packer is rig-c's, and no other: a packed region is a lossless copy, and an
 atlas written by anything else would have no oracle behind it.
 
 ## Painting → parts → rig → browser
 
 | stage | tool | what it owns |
 | --- | --- | --- |
-| painting + See-through layers → parts and specs | **spine-parts** | the merge of two runs, the measurements, the rig spec and motion spec |
-| specs → Spine skeleton data | **[spine-rigc](https://github.com/firejune/rigc)** | compile, the gate (rigc's own validator in an install; the round trip through `spine-core` where the runtime is beside it, as in this repository's CI), the named assertions, the packer, the renderer |
+| painting + See-through layers → parts and specs | **rig-parts** | the merge of two runs, the measurements, the rig spec and motion spec |
+| specs → Spine skeleton data | **[rig-c](https://github.com/firejune/rigc)** | compile, the gate (rigc's own validator in an install; the round trip through `spine-core` where the runtime is beside it, as in this repository's CI), the named assertions, the packer, the renderer |
 | skeleton data → a page | **[spine-html](https://github.com/firejune/spine-html)**, a sibling project | a DOM renderer; rigc's `spine-html` profile is its policy, and every build here is gated under that profile as well as under `spine` |
 
-spine-parts never writes Spine data itself. Everything on disk under `check/build/`
-was written by spine-rigc after its own gate passed.
+rig-parts never writes Spine data itself. Everything on disk under `check/build/`
+was written by rig-c after its own gate passed.
 
 ## Getting See-through layers
 
-See-through is required; how you run it is not. spine-parts does not vendor, embed or
+See-through is required; how you run it is not. rig-parts does not vendor, embed or
 redistribute See-through code or weights — run it by any of these and point
-spine-parts at what it wrote:
+rig-parts at what it wrote:
 
-| Route | Where | Output spine-parts reads |
+| Route | Where | Output rig-parts reads |
 | --- | --- | --- |
 | Hugging Face Space | [24yearsold/see-through-demo](https://huggingface.co/spaces/24yearsold/see-through-demo) (ZeroGPU; upstream states 1-2 extractions a day for a registered user) | the `.psd` it produces |
 | ModelScope demo | [ljsabc/See-Through](https://modelscope.cn/studios/ljsabc/See-Through), linked from the upstream README | the `.psd` it produces |
 | Upstream CLI | `python inference/scripts/inference_psd.py --srcp <image> --save_to_psd` in a checkout of [shitagaki-lab/see-through](https://github.com/shitagaki-lab/see-through) | the `.psd` in `workspace/layerdiff_output/` |
-| ComfyUI wrapper | [jtydhr88/ComfyUI-See-through](https://github.com/jtydhr88/ComfyUI-See-through) on your own ComfyUI box; the optional `comfy` adapter (`spine-parts comfy seethrough`) drives it | the `layers.json` + PNGs it writes |
+| ComfyUI wrapper | [jtydhr88/ComfyUI-See-through](https://github.com/jtydhr88/ComfyUI-See-through) on your own ComfyUI box; the optional `comfy` adapter (`rig-parts comfy seethrough`) drives it | the `layers.json` + PNGs it writes |
 
 **The head run is needed on every route that was read.** See-through's model
 already separates the head in a second stage of its own: it crops the head the
@@ -189,7 +190,7 @@ head run on `st_input_head.png` is what gives the eyes more pixels
   and the head run's 60×38: the head run is still needed.
 
 **See-through is required; ComfyUI is not.** The wrapper is one route among
-four, and `spine-parts comfy` is only a convenience for that route: every
+four, and `rig-parts comfy` is only a convenience for that route: every
 stage after See-through reads files, whichever route wrote them. On the two
 public examples each run took 171–199 s through the wrapper (each run's
 `meta.json`, in [spine-parts-examples](https://github.com/firejune/spine-parts-examples)).
@@ -197,7 +198,7 @@ public examples each run took 171–199 s through the wrapper (each run's
 ### The two images See-through is fed: `inputs`
 
 ```sh
-spine-parts inputs --source painting.png --config config.json --out <dir>
+rig-parts inputs --source painting.png --config config.json --out <dir>
 ```
 
 cuts the two images See-through is fed: the painting centred on a white square
@@ -210,8 +211,8 @@ For a user who has a ComfyUI box, two
 commands drive it; nothing else in the pipeline needs one:
 
 ```sh
-spine-parts comfy paint --config config.json --out <dir> --host http://<box>:8188
-spine-parts comfy seethrough --image st_input_full.png --out layers/full --host http://<box>:8188 --offload
+rig-parts comfy paint --config config.json --out <dir> --host http://<box>:8188
+rig-parts comfy seethrough --image st_input_full.png --out layers/full --host http://<box>:8188 --offload
 ```
 
 `comfy paint` generates `painting_<seed>.png` from the config's inline
@@ -227,27 +228,27 @@ than queueing behind someone else's job.
 ## The loop, for an agent
 
 ```sh
-spine-parts inputs --source painting.png --config config.json --out inputs   # st_input_full.png
-#    See-through on st_input_full.png (external, or `spine-parts comfy seethrough`) -> layers/full
-spine-parts layers layers/full                      # every layer: box, opaque px, depth, plausibility figures; WARN lines
-spine-parts propose --head-box --full layers/full --canvas 1664x2432
+rig-parts inputs --source painting.png --config config.json --out inputs   # st_input_full.png
+#    See-through on st_input_full.png (external, or `rig-parts comfy seethrough`) -> layers/full
+rig-parts layers layers/full                      # every layer: box, opaque px, depth, plausibility figures; WARN lines
+rig-parts propose --head-box --full layers/full --canvas 1664x2432
 #    -> seethrough.head_box into config.json
-spine-parts inputs --source painting.png --config config.json --out inputs   # now st_input_head.png too
-#    See-through on st_input_head.png (external, or `spine-parts comfy seethrough`) -> layers/head
-spine-parts sheet --source painting.png --layers layers/full --layers layers/head --out sheets/layers.png
-spine-parts assemble --propose-plan --source painting.png --full layers/full --head layers/head --config config.json
+rig-parts inputs --source painting.png --config config.json --out inputs   # now st_input_head.png too
+#    See-through on st_input_head.png (external, or `rig-parts comfy seethrough`) -> layers/head
+rig-parts sheet --source painting.png --layers layers/full --layers layers/head --out sheets/layers.png
+rig-parts assemble --propose-plan --source painting.png --full layers/full --head layers/head --config config.json
 #    -> assemble.plan and extend_below_crop
-spine-parts assemble --source painting.png --full layers/full --head layers/head --config config.json --out work
+rig-parts assemble --source painting.png --full layers/full --head layers/head --config config.json --out work
 #    -> work/rig: parts.json and parts/; the config holds no bones, meshes, regions or motion yet
 #    -> read the `uncovered hole N:` lines and look at work/render/recomposite_error_rig.png:
 #       red is painting that no part holds, and no later gate can see it
 #    -> a large red hole neither run holds? add an assemble.patches entry (cut from the painting) and assemble again
-spine-parts propose --parts work/rig --source painting.png --out work
+rig-parts propose --parts work/rig --source painting.png --out work
 #    -> proposal.json, basis.json (what each bone rests on) and render/landmarks.png; per-bone coverage lines;
 #       correct it, copy bones/meshes/regions/motion into config.json
-spine-parts propose --parts work/rig --source painting.png --out work --from-config config.json
+rig-parts propose --parts work/rig --source painting.png --out work --from-config config.json
 #    -> LINT lines; exit 1 while any remain
-spine-parts build --config config.json --source painting.png --full layers/full --head layers/head --out out --loop
+rig-parts build --config config.json --source painting.png --full layers/full --head layers/head --out out --loop
 #    -> read out/check/check.json; every FAIL line names what has to change
 ```
 
@@ -264,7 +265,7 @@ against its overlay, and a config with bones is `build`'s input. `rig`, `check`
 `loop` are the same stages one at a time. [docs/AUTHORING.md](docs/AUTHORING.md) is
 the guide an agent authors from — every config field, what to look at after each
 stage, what each refusal means and which field it points at — and
-[`skills/spine-parts/SKILL.md`](skills/spine-parts/SKILL.md) is the same loop as an
+[`skills/rig-parts/SKILL.md`](skills/rig-parts/SKILL.md) is the same loop as an
 agent skill.
 
 ## Commands
@@ -283,15 +284,20 @@ agent skill.
 | `propose … --keypoints <file> [--person <id>]` | read a posed figure's joints from one explicit file (space, image size, people, each joint observed, occluded or missing, its source): a joint with a position places the neck, hip, chest or a sleeve chain as given, a note says how every joint was used or which rule stood in, and LINT reads the torso and sleeves along the joints instead of by screen y ([AUTHORING §3](docs/AUTHORING.md)) |
 | `propose … --from-config <config>` | draw and LINT the config's current bones (by the joints too, given `--keypoints`) |
 | `compare --left <file> --right <file> [--map <bonemap.json>]` | compare two skeletons — a config, a proposal or a `rig.json` — bone by bone: origin, parent, tip, length and direction per pair, the bones neither side pairs, the required ones missing, and each side's roles read off the spec; no frame is guessed, and nothing pairs by resemblance (`propose --compare` reads origins only) |
-| `rig --config --parts --out [--idle-keys ctl\|direct]` | author `rig.json` + `motion.json`, written only after spine-rigc's gate is green; every chain link is turned along its chain and carries its `length`, so a physics constraint added later has a lever, with every offset under it in the turned frame so nothing moves; `--idle-keys` says whether the idle's keys on mesh-driving bones go through `<bone>_ctl` parents (default) or stay on the bones with `invariants.idleDrivesMeshes` declared; the config's `constraints` go to rigc as written, and a two-bone ik over keyed links needs `--idle-keys direct` (on `rig` or `build`) |
-| `check --rig --out [--parts] [--source] [--requirements]` | build packed, gated under `spine-html`, render the idle, measure seam, loop and the six judgement lines (mesh texture stretch among them, from the idle's `render --geometry`), and report the recomposite's holes from `parts.json`; on a rig spec with no `parts.json` or no `idle` (a merged rig, issue #77) the gate still runs and every line that needs the missing input says SKIP by name; `--source <painting.png>` adds `SETUP_POSE_VS_SOURCE`, the setup pose against the painting by assemble's recomposite figures; `--requirements <scene.json>` measures what a scene declares of the motion — a contact, a follow fraction, an aim, a joint range, a mesh's stretch, the seam between two parts over the motion — each against the author's own bar, from spine-rigc's posed frames, one line each, PASS, FAIL or NOT MEASURABLE (AUTHORING §7, *Declared requirements*) |
+| `rig --config --parts --out [--idle-keys ctl\|direct]` | author `rig.json` + `motion.json`, written only after rig-c's gate is green; each mesh is in the mode its config entry names — `grid` (the lattice, what `propose` writes), `contour` (the traced outline with declared interior points) or `auto` (the contour mesh at alpha 1 and above, reduced and locally refined by rig-c's `reduceMesh` under the author's declared bounds, written only when its motion against the unreduced source on the idle passes the author's `motion` bounds through rig-c's `compareMeshesInMotion`; [AUTHORING §3](docs/AUTHORING.md)); every chain link is turned along its chain and carries its `length`, so a physics constraint added later has a lever, with every offset under it in the turned frame so nothing moves; `--idle-keys` says whether the idle's keys on mesh-driving bones go through `<bone>_ctl` parents (default) or stay on the bones with `invariants.idleDrivesMeshes` declared; the config's `constraints` go to rigc as written, and a two-bone ik over keyed links needs `--idle-keys direct` (on `rig` or `build`) |
+| `check --rig --out [--parts] [--source] [--requirements]` | build packed, gated under `spine-html`, render the idle, measure seam, loop and the six judgement lines (mesh texture stretch among them, from the idle's `render --geometry`), and report the recomposite's holes from `parts.json`; on a rig spec with no `parts.json` or no `idle` (a merged rig, issue #77) the gate still runs and every line that needs the missing input says SKIP by name; `--source <painting.png>` adds `SETUP_POSE_VS_SOURCE`, the setup pose against the painting by assemble's recomposite figures; `--requirements <scene.json>` measures what a scene declares of the motion — a contact, a follow fraction, an aim, a joint range, a mesh's stretch, the seam between two parts over the motion — each against the author's own bar, from rig-c's posed frames, one line each, PASS, FAIL or NOT MEASURABLE (AUTHORING §7, *Declared requirements*) |
 | `loop --frames <dir> --out <file.gif \| file.png> [--palette]` | encode a rendered idle as a looping GIF, lossless APNG, or indexed APNG (`--palette`) |
 | `build --config --source --full --head --out [--seam] [--project] [--loop] [--requirements] [--idle-keys ctl\|direct]` | assemble, rig and check in one process, stopping at the first refusal; `--requirements` is forwarded to check, `--idle-keys` to rig |
-| `compose --scene <scene.json> --out [--requirements]` | bind several characters' green builds into one rig: every name prefixed `<id>:` under one shared root, each character's offset added at its first-level bones, an optional background plate (its provenance recorded, judged by nothing) drawn first, and the draw order between the characters' slots as the scene file declares it — nothing inferred, nothing scaled; gated through spine-rigc as `rig` is, then checked ([AUTHORING §7](docs/AUTHORING.md), *Composing several characters*) |
+| `compose --scene <scene.json> --out [--requirements]` | bind several characters' green builds into one rig: every name prefixed `<id>:` under one shared root, each character's offset added at its first-level bones, an optional background plate (its provenance recorded, judged by nothing) drawn first, and the draw order between the characters' slots as the scene file declares it — nothing inferred, nothing scaled; gated through rig-c as `rig` is, then checked ([AUTHORING §7](docs/AUTHORING.md), *Composing several characters*) |
 
-`spine-parts --help` has every flag. Exit codes: 0 done, 1 input refused (every
+`rig-parts --help` has every flag. Exit codes: 0 done, 1 input refused (every
 reason is a FAIL line), 2 a usage error or a command this version does not implement.
 
+What 1.0.0 holds stable — these commands and their flags, the config
+fields, the files a build writes and their spec ids, the environment, and what this
+package relies on in rig-c — and what is not, is [docs/STABILITY.md](docs/STABILITY.md).
+Coming from 0.16.0: [docs/MIGRATION.md](docs/MIGRATION.md).
+
 ## What it does not do
 
 These are limits of the approach, stated so nobody reads more into a green run:
@@ -361,10 +367,17 @@ before it, at v0.14.0).
 
 ## Requirements
 
-[Bun](https://bun.sh) 1.2 or later. `npm install -g spine-parts` installs the
-`spine-parts` command; it hands off to Bun and says so in one sentence if Bun is not
-on `PATH`. spine-rigc comes with it as a dependency. No Spine runtime does: since
-spine-rigc 2.0 the installed `rigc` gates every build with its own validator over the
+[Bun](https://bun.sh) 1.2 or later. `npm install -g rig-parts` installs the
+`rig-parts` command; it hands off to Bun and says so in one sentence if Bun is not
+on `PATH`. **`rig-parts` is the package's name; versions up to 0.16.0 were published
+as `spine-parts`, its former name**, and the install keeps a `spine-parts` command
+beside `rig-parts` for the transition, the same launcher under both names. On npm
+the alias `spine-parts` stays published beside `rig-parts` at every version,
+carrying the same files with only the `name` in `package.json` changed, so a
+project that depends on the former name keeps receiving every release; a new
+install names `rig-parts` ([RELEASING.md](RELEASING.md), *The registry side*). rig-c
+comes with it as a dependency. No Spine runtime does: since
+rig-c 2.0 the installed `rigc` gates every build with its own validator over the
 compiled model document, and `rigc --version` says `entry: cli_core.ts —
 @esotericsoftware/spine-core absent`. With `@esotericsoftware/spine-core` installed
 beside it, the same `rigc` runs the spine-core round trip instead, as this repository's
@@ -372,7 +385,7 @@ selftest and CI do; `check.json`'s `rigc_entry` records which one gated a build.
 
 ## Licence posture
 
-spine-parts is MIT, and it depends on spine-rigc, whose output is Spine skeleton data:
+rig-parts is MIT, and it depends on rig-c, whose output is Spine skeleton data:
 using what it produces in a product requires a Spine Editor licence, as any Spine data
 does. Neither package installs Esoteric Software's `spine-core` any more; this
 repository uses it in development, for the round trip in its selftest and CI. [NOTICE.md](NOTICE.md) records that chain and every other
@@ -390,7 +403,8 @@ bun run smoke            # pack, install into an empty directory, run from the i
 ```
 
 [CLAUDE.md](CLAUDE.md) is the doctrine, [CONTRIBUTING.md](CONTRIBUTING.md) the
-practice, [RELEASING.md](RELEASING.md) the cut.
+practice, [RELEASING.md](RELEASING.md) the cut, [docs/STABILITY.md](docs/STABILITY.md)
+the interface it holds.
 
 ## Licence
 

package/bin/{spine-parts.cjs → rig-parts.cjs}

@@ -2,16 +2,20 @@
 'use strict';
 
 /**
- * spine-parts' `bin` entry has one job: hand off to Bun.
+ * rig-parts' `bin` entry has one job: hand off to Bun.
  *
  * npm's `bin` field has to be something any installed Node can run, but
- * spine-parts is a Bun program (it runs its TypeScript sources directly, and so
- * does spine-rigc underneath it). Without this file, a machine with no Bun
+ * rig-parts is a Bun program (it runs its TypeScript sources directly, and so
+ * does rig-c underneath it). Without this file, a machine with no Bun
  * would fail as a bare `env: bun: No such file or directory`, with no hint
  * why. So: if `bun` is on PATH, run the real CLI (cli.ts, next to this file)
  * under it and disappear — argv, stdio, the exit code and signals all pass
  * straight through. If it isn't, say so once and stop. No downloads, no
  * network, no writes — just the hand-off or the message.
+ *
+ * package.json installs this one file under two command names: `rig-parts`,
+ * and the package's former name, kept as a second `bin` entry for the
+ * transition so a script written against it still runs.
  */
 
 const path = require('node:path');
@@ -22,9 +26,9 @@ const result = spawnSync('bun', [cli, ...process.argv.slice(2)], { stdio: 'inher
 
 if (result.error) {
   if (result.error.code === 'ENOENT') {
-    process.stderr.write('spine-parts runs on Bun, which was not found on PATH — install it from https://bun.sh\n');
+    process.stderr.write('rig-parts runs on Bun, which was not found on PATH — install it from https://bun.sh\n');
   } else {
-    process.stderr.write(`spine-parts: could not launch bun: ${result.error.message}\n`);
+    process.stderr.write(`rig-parts: could not launch bun: ${result.error.message}\n`);
   }
   process.exit(1);
 }