rig-parts 1.5.3 → 1.5.4

package/NOTICE.md

@@ -69,7 +69,7 @@ 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.
-rig-c's [NOTICE.md](https://github.com/firejune/rigc/blob/main/NOTICE.md)
+rig-c's [NOTICE.md](https://github.com/rig-c/core/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:
 

package/README.md

@@ -4,7 +4,7 @@
 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 [rig-c](https://github.com/firejune/rigc)'s
+and a looping idle over them in [rig-c](https://github.com/rig-c/core)'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
@@ -14,12 +14,12 @@ input is silent.
 ## What you get
 
 <p align="center">
-  <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 rigged, breathing, blinking once and swaying her hair, sleeves and skirt in a four-second loop" height="420" />
+  <img src="https://raw.githubusercontent.com/rig-c/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/rig-c/parts/main/assets/demo-idle.png" alt="The same character rigged, 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/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%" />
+  <img src="https://raw.githubusercontent.com/rig-c/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>
@@ -54,7 +54,7 @@ made the contact sheet.
 </em></p>
 
 <p align="center">
-  <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" />
+  <img src="https://raw.githubusercontent.com/rig-c/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>
@@ -148,9 +148,9 @@ atlas written by anything else would have no oracle behind it.
 
 | stage | tool | what it owns |
 | --- | --- | --- |
-| 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 | **[rig-play](https://github.com/firejune/rig-play)** (formerly 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` |
+| painting + See-through layers → parts and specs | **rig-parts** (npm `@rig-c/parts`) | the merge of two runs, the measurements, the rig spec and motion spec |
+| specs → Spine skeleton data | **[rig-c](https://github.com/rig-c/core)** (npm `rig-c`) | 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 | **[rig-play](https://github.com/rig-c/play)** (npm `@rig-c/play`; formerly 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` |
 
 rig-parts never writes Spine data itself. Everything on disk under `check/build/`
 was written by rig-c after its own gate passed.
@@ -388,15 +388,17 @@ before it, at v0.14.0).
 
 ## Requirements
 
-[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
+[Bun](https://bun.sh) 1.2 or later. `npm i -D @rig-c/parts` installs the
+`rig-parts` command (`npm install -g @rig-c/parts` puts it on `PATH`); it hands off
+to Bun and says so in one sentence if Bun is not on `PATH`. **`@rig-c/parts` is the
+package's name; versions 1.0.0-rc.1 to 1.5.3 were published as `rig-parts`, and
+versions up to 0.16.0
 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,
+both former names stay published beside `@rig-c/parts` at every version, as aliases
 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
+project that depends on either keeps receiving every release; a new
+install names `@rig-c/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 —

package/docs/AUTHORING.md

@@ -17,7 +17,7 @@ into `examples/sample/inputs/`.
 
 | what | why | how |
 | --- | --- | --- |
-| [Bun](https://bun.sh) 1.2 or later | rig-parts and rig-c are Bun programs | `npm install -g rig-parts` installs the command; it says so if Bun is missing |
+| [Bun](https://bun.sh) 1.2 or later | rig-parts and rig-c are Bun programs | `npm install -g @rig-c/parts` installs the command; it says so if Bun is missing |
 | [rig-c](https://www.npmjs.com/package/rig-c) | compiles, gates, packs and renders every rig; rig-parts writes no Spine data itself | installed with rig-parts as a dependency (`node_modules/.bin/rigc`); with no Spine runtime beside it, it gates with its own validator, and `rigc --version` says `entry: cli_core.ts` |
 | [See-through](https://github.com/shitagaki-lab/see-through), somewhere | the layer decomposition is the input | any route in README *Getting See-through layers*; it runs twice per character, outside this tool |
 | a GPU, wherever See-through runs | See-through is a diffusion model | nothing in rig-parts itself uses a GPU |

package/docs/MIGRATION.md

@@ -9,14 +9,14 @@ from the pull request that measured it.
 
 ## In one paragraph
 
-Install `rig-parts`. A config that built on 0.16.0 loads and builds unchanged: every
-config change since is a new, opt-in field inside a new mesh mode. The bytes a
-config without that mode builds moved once, by a declared exception (every mesh
-triangle's vertex order, #133); apart from it, each change since 0.16.0 that touched
-the code was measured against the tree before it on the three public examples'
-builds, and moved no byte of them. Inside the automatic mode, one change after the
-candidate moves declared bytes, named in *Since 1.0.0-rc.1*: the skinning envelope's
-reference (#169).
+Install `@rig-c/parts` (the package's name after 1.5.3; *After 1.5.3* below). A
+config that built on 0.16.0 loads and builds unchanged: every config change since is
+a new, opt-in field inside a new mesh mode. The bytes a config without that mode
+builds moved once, by a declared exception (every mesh triangle's vertex order,
+#133); apart from it, each change since 0.16.0 that touched the code was measured
+against the tree before it on the three public examples' builds, and moved no byte
+of them. Inside the automatic mode, one change after the candidate moves declared
+bytes, named in *Since 1.0.0-rc.1*: the skinning envelope's reference (#169).
 
 ## From 0.16.0 to 1.0.0-rc.1
 
@@ -31,7 +31,7 @@ reference (#169).
 | spec ids of the files authors write and this package writes | `spine-parts-requirements/1`, `spine-parts-scene/1`, `spine-parts-keypoints/1`, `spine-parts-bonemap/1`, `spine-parts-basis/1`, `spine-parts-scene-report/1` | unchanged: they name a file format, not the tool, so a file written before the rename still reads |
 | public examples repository | `spine-parts-examples` | unchanged (it keeps the name it was published under) |
 
-What to do: install with `npm install -g rig-parts` and write `rig-parts` in scripts.
+What to do: install with `npm install -g @rig-c/parts` and write `rig-parts` in scripts.
 A script or a dependant that names the alias `spine-parts` keeps working and keeps
 receiving every release; how long the alias stays is RELEASING.md's *The alias stays
 until its retirement questions have written answers*. No build output carries the
@@ -135,3 +135,16 @@ What to do: nothing for a config without `auto`. A config under `auto` that decl
 `motion.residual` may write a different mesh than 1.0.0-rc.1 did, as above; a
 consumer that compares builds byte for byte with 1.0.0-rc.1 expects that move and
 nothing else.
+
+## After 1.5.3: the scoped name
+
+| | 1.0.0 to 1.5.3 | after 1.5.3 |
+| --- | --- | --- |
+| npm package | `rig-parts` | `@rig-c/parts`; `rig-parts` and the alias `spine-parts` are published beside it at every version as aliases, the same files with only the `name` in `package.json` changed |
+| command | `rig-parts`, and the alias `spine-parts` on the same launcher | unchanged |
+| repository | `firejune/rig-parts` (GitHub redirects it) | `rig-c/parts`, beside `rig-c/core` (npm `rig-c`) and `rig-c/play` |
+| spec ids, the config, the bytes a build writes | | unchanged |
+
+What to do: install with `npm i -D @rig-c/parts` (or `npm install -g @rig-c/parts`);
+command lines do not change. A dependant that names `rig-parts` keeps receiving
+every release under it (#222).

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "rig-parts",
-  "version": "1.5.3",
+  "version": "1.5.4",
   "description": "AI-authored 2D character parts from one anime painting and its See-through layer decomposition: measured parts, weighted-mesh rig specs, verified through rig-c before anything is written. A CLI for agents that cannot see the image.",
   "type": "module",
   "bin": {
@@ -14,10 +14,10 @@
   "author": "firejune",
   "repository": {
     "type": "git",
-    "url": "https://github.com/firejune/rig-parts.git"
+    "url": "https://github.com/rig-c/parts.git"
   },
-  "homepage": "https://github.com/firejune/rig-parts#readme",
-  "bugs": "https://github.com/firejune/rig-parts/issues",
+  "homepage": "https://github.com/rig-c/parts#readme",
+  "bugs": "https://github.com/rig-c/parts/issues",
   "keywords": [
     "spine",
     "spine2d",

package/skills/rig-parts/SKILL.md

@@ -2,7 +2,7 @@
 name: rig-parts
 description: Turn one anime character painting and its See-through layer decomposition into a verified 2D character rig (Spine 4.3 skeleton data) — measured parts, weighted meshes, bone chains and a looping idle — with rig-parts, which gates everything through rig-c before it is written. Use for a request to rig or animate a single character painting, to run or read rig-parts layers, sheet, assemble, propose, rig, check, loop or build, or to write or fix a rig-parts config.json. Not for cutting art into parts by hand, for authoring a rig from loose PNGs (that is the rigc skill), for lip-sync or swapping a part's image, or for running See-through itself.
 license: MIT
-compatibility: Requires Bun 1.2 or later. The tool is the npm package rig-parts (bunx rig-parts, or bun add -d rig-parts); rig-c is installed with it. See-through is run separately.
+compatibility: Requires Bun 1.2 or later. The tool is the npm package @rig-c/parts (npm i -D @rig-c/parts, or bun add -d @rig-c/parts), whose command is rig-parts; rig-c is installed with it. See-through is run separately.
 ---
 
 # rig-parts — a painting to a Spine rig, for agents
@@ -150,9 +150,9 @@ share is synthesis where the painting was there to be taken.
 
 ## Where to read next
 
-[docs/AUTHORING.md](https://github.com/firejune/rig-parts/blob/main/docs/AUTHORING.md)
+[docs/AUTHORING.md](https://github.com/rig-c/parts/blob/main/docs/AUTHORING.md)
 first — every config field, the command order, what to read after each stage, every
-refusal. It is in the installed package at `node_modules/rig-parts/docs/AUTHORING.md`,
+refusal. It is in the installed package at `node_modules/@rig-c/parts/docs/AUTHORING.md`,
 the copy that matches the version you run. Two recipes there cover what this package
 leaves to you: