spine-rigc 0.35.0 → 0.36.0

package/docs/AUTHORING.md

@@ -1045,6 +1045,15 @@ page:
 | leaves a remaining **tie in the order your file declares it** | `turn` before `Turn`; `Mango` before `mango` — each given in that order and returned in it |
 | writes **leaves then folders at the root**, and **sub-folders then leaves inside a folder** | `h` before `f/sub1/deep/q`; `f/sub1/x` before `f/leafA` |
 
+🔸 **One clause of the rule is not from those files.** Before comparing, the
+comparator reads U+3000 IDEOGRAPHIC SPACE as a space and the full-width digits
+U+FF10–U+FF19 as `0`–`9`. No probe carried either; the fold was measured on a
+production skin's slot keys ([#791](https://github.com/firejune/rigc/issues/791),
+§10.6b says what was measured and why it is those two classes and not NFKC), and
+it applies here because R10, R11 and a skin's slot keys are one comparator. So
+`shot２` sorts before `shot10`, and a pair an ideographic space decides is
+ordered rather than refused as `separator`.
+
 ⭐ **A tie is not an ambiguity, and that is what retired most of this rule's
 refusals.** Two names the comparator cannot separate come back in the order the
 file gave them, so the order rigc emits for such a pair is **your own declaration
@@ -1094,12 +1103,14 @@ names the same comparator puts ahead of it — `default` before `2`, `default`
 before `A` — so renaming a skin away from `default` makes it an ordinary name that
 sorts like one.
 
-**R12 — A placeholder that more than one skin fills gets a per-skin attachment
-`name`, and the `default` skin may not be one of those skins.** rigc writes
-`"name": "<skin>/<placeholder>"` on each of those entries and restates `path`
-beside it so the texture still resolves where it did; you do not author that and
-there is nothing to do about it, but it is visible in the emitted file, so §3.4.2
-says what it is and why. What you *do* author is where the shared art lives: a
+**R12 — An attachment's `name` is written exactly when the spec states it, and
+the `default` skin may not share a placeholder with a named skin.** rigc derives
+no name. A placeholder several skins fill is emitted under that placeholder in
+each skin, carrying the `name` each entry states and none where it states none —
+which is the shape the editor itself exports (§3.4.2). Until
+[#796](https://github.com/firejune/rigc/issues/796) rigc composed
+`"<skin>/<placeholder>"` there, which renamed every such attachment at runtime.
+What you *do* author is where the shared art lives: a
 placeholder the `default` skin shares with a named skin is a **compile error**,
 because the Spine editor has no representation for it in either spelling (#567,
 measured on 4.3.26 — named, the export re-keys it and the default skin draws
@@ -1323,25 +1334,26 @@ the default `type`:
 | Field | Meaning |
 | --- | --- |
 | `type` | `"region"`, or omit |
+| `name` | the attachment's **own name**, when it is not the placeholder: what the runtime calls it (`Attachment.name`, which is what `slot.attachment.name` returns) and what `path` defaults to. Optional — absent, the runtime names the attachment by its placeholder. Written **verbatim**, as the attachment's first key, exactly when you state it; rigc never makes one up (R12, §3.4.2). Nothing resolves an attachment *by* it: a slot's setup `attachment`, every timeline and a linked mesh's `source` use the placeholder. Every type takes it. Not a string is refused — `"name" is 7, which is not a string` |
 | `image` | **rigc extension.** A PNG relative to the rig's `images` directory; rigc measures it (R5) |
 | `width`, `height` | required by the format — give them, or give an `image` |
-| `path` | the atlas region to resolve; defaults to the attachment's own name. rigc sets it for you when the PNG basename differs from the placeholder, and whenever it composes a `name` because more than one skin fills this placeholder (§3.4.2). **One rule, both kinds** — see the note under *Mesh attachment* |
+| `path` | the atlas region to resolve; defaults to the attachment's name — its `name`, else the placeholder. rigc sets it for you when the PNG basename differs from that name. **One rule, both kinds** — see the note under *Mesh attachment* |
 | `x`, `y` | offset from the bone, in the bone's local space |
 | `rotation` | degrees; cancels a rotated bone for a plate authored screen-upright |
 | `scaleX`, `scaleY`, `color` | as Spine |
-| `sequence` | a **numbered image series** instead of one region: `{ "count", "start"?, "digits"?, "setup"? }`, and `path` (or the placeholder) is the series' stem. No `image` beside it — the frames are the images. §3.4.3 |
+| `sequence` | a **numbered image series** instead of one region: `{ "count", "start"?, "digits"?, "setup"? }`, and `path` (or, with none, the `name`, or the placeholder) is the series' stem. No `image` beside it — the frames are the images. §3.4.3 |
 
 **Mesh attachment** ([Spine: meshes](http://esotericsoftware.com/spine-meshes)) —
 either authored geometry (`uvs` + `triangles` + geometry) **or** a `generator`,
 never both. `hull`, `edges`, `width` and `height` may be stated; whichever is
 omitted, rigc derives — `hull` and `edges` from the triangles, the size from the
-PNG — and the rules are a few paragraphs down. `type`, `image`, `path`, `color` and
-`sequence` mean exactly what they mean on a region (a sequence mesh takes authored
+PNG — and the rules are a few paragraphs down. `type`, `name`, `image`, `path`,
+`color` and `sequence` mean exactly what they mean on a region (a sequence mesh takes authored
 geometry, never a `generator` — §3.4.3).
 
 🔑 **`path` is one rule for both kinds.** A mesh derives it from `image` the way a
 region does: stated wins, otherwise the PNG's basename when that differs from the
-placeholder, otherwise nothing. The parser reads `path` off both with the same line
+attachment's name — its `name`, else the placeholder — otherwise nothing. The parser reads `path` off both with the same line
 (`getValue(map, "path", name)`, `SkeletonJson.ts:541` and `:570`), and `path`
 defaults to the attachment's **name** rather than to the placeholder — so a mesh
 with `image: hair_short.png` under a placeholder called `hair` resolves the region
@@ -1506,11 +1518,11 @@ them (`SkeletonJson.ts:568-569`, `:582`), so rigc reads them the same way.
 
 | Field | Meaning |
 | --- | --- |
-| `source` | **required.** The **placeholder** of the mesh whose geometry this one draws — the key it is filed under in its skin, not its `name`. A miss is refused naming the skin, the slot and what that slot holds |
+| `source` | **required.** The **placeholder** of the mesh whose geometry this one draws — the key it is filed under in its skin, not its `name`. A miss is refused naming the skin, the slot and what that slot holds; a `source` that spells the source's `name` instead is that miss, because the runtime looks the source up by skin, slot and key and never by name — measured, it throws `Source mesh not found` |
 | `slot` | the slot the source lives in. Default: **this attachment's own slot**. Resolved by name against the rig's slots |
 | `skin` | the skin the source lives in. Default: **`default`** — the default skin, *not* the skin this link is written in. Resolved by name |
 | `timelines` | default **`true`**: the link plays the source's `deform` keys. `false` makes it its own timeline target, so only keys written against the link move it |
-| `image`, `path`, `width`, `height`, `color` | exactly as on a mesh — the link resolves **its own** region, which is the point of the type |
+| `name`, `image`, `path`, `width`, `height`, `color` | exactly as on a mesh — the link resolves **its own** region, which is the point of the type |
 
 ```json
 "skins": {
@@ -1596,6 +1608,7 @@ region, a trigger volume — that moves with the skeleton and draws nothing.
 | Field | Meaning |
 | --- | --- |
 | `type` | `"boundingbox"`. **Required**: an omitted `type` is `"region"`, and a region has nowhere to put these keys — measured, the refusal reads `attachment "mask" (region) has 2 keys this compiler does not read: "vertexCount", "vertices"` |
+| `name` | as on a region: the runtime's name for the attachment, written only when stated. A polygon resolves no region, so here it is the name and nothing else |
 | `vertexCount` | **required**, 3 or more. No default — the paragraph above is why |
 | `vertices` | the unweighted `x, y` run, in the slot bone's local space; or the index-encoded weighted run, behind `boneIndexing` |
 | `weights` | the by-name form: one entry per vertex, each a list of `{ "bone": …, "x": …, "y": …, "weight": … }`, each pair in that bone's local space. Never beside `vertices` |
@@ -1610,7 +1623,7 @@ attachment rather than a second set of art.
 | Field | Meaning |
 | --- | --- |
 | `type` | `"clipping"`. **Required** |
-| `vertexCount`, `vertices`, `weights`, `boneIndexing`, `color` | exactly as on a bounding box |
+| `name`, `vertexCount`, `vertices`, `weights`, `boneIndexing`, `color` | exactly as on a bounding box |
 | `end` | the last slot the clip applies to, **by name**. Absent is the parser's own encoding for *clip everything after this one*, which is why a typo cannot be told from an omission once the file is loaded: `findSlot` returns null on a miss and the parser assigns that null without a word, so the clip runs to the bottom of the draw order and takes every slot below it with it. rigc refuses a name the rig does not declare — `end names slot "X", which this rig does not declare` — and `A33` refuses it again on a skeleton rigc did not write |
 | `convex` | default **false**. True tells the runtime the polygon is convex so it can clip without triangulating it, and a polygon that deforms concave is clipped by its convex hull instead (`ClippingAttachment.convex`). Nothing here checks that the polygon is in fact convex |
 | `inverse` | default **false**. True makes everything **outside** the polygon visible instead of everything inside, and inverse clipping is always treated as convex (`ClippingAttachment.inverse`) |
@@ -1628,7 +1641,7 @@ other vertex attachment.
 | Field | Meaning |
 | --- | --- |
 | `type` | `"path"`. **Required** |
-| `vertexCount`, `vertices`, `weights`, `boneIndexing`, `color` | as on a bounding box — except that these vertices are knots **and** their handles, which the count rule below is about |
+| `name`, `vertexCount`, `vertices`, `weights`, `boneIndexing`, `color` | as on a bounding box — except that these vertices are knots **and** their handles, which the count rule below is about |
 | `closed` | default **false**. True joins the last knot back to the first |
 | `constantSpeed` | default **true** — note the direction. Leaving it out asks for the expensive-and-correct traversal, in which the runtime re-measures the path every frame and `lengths` is never read. `false` makes the runtime trust the emitted `lengths` instead: cheaper, exact only while the path holds its setup shape, and the reason a deformed path wants the default |
 | `lengths` | 🚫 **refused by name.** rigc measures the setup length of each curve off the geometry and emits it, the way it measures a region's size off its PNG: `"lengths" is not authored — rigc measures the setup arc length of each curve…`. The field is declared only so the refusal can say that rather than report a misspelt key. What the numbers are — and why *arc length* is the wrong name for them — is §10.6 |
@@ -2303,41 +2316,64 @@ beside them is refused rather than ignored (an ignored slot is an attachment tha
 vanishes), and a rig with a *slot* of one of those names is refused too, because
 there the two forms are genuinely ambiguous. Rename the slot.
 
-#### 3.4.2 Two skins, one placeholder — the `name` rigc writes for you
-
-Two skins putting different art under one placeholder is what a skin is *for*, and
-it is the one shape rigc emitted wrongly until
-[#541](https://github.com/firejune/rigc/issues/541). Without a `name` field an
-attachment's name **is** its placeholder (`SkeletonJson.ts:526`), so four skins
-filling `patch` are four different attachments all called `patch`. spine-core never
-notices — its skin table is keyed by placeholder, so the two never meet — and the
-whole gate is green. The Spine editor refuses the import outright:
-
-```
-ERROR: Unable to import skeleton.
-[error] Error reading skeleton: skins
-Cause: [error] Error reading attachment: patch (MOw)
-Cause: [error] Multiple attachments have the same name: patch patch
-```
+#### 3.4.2 Two skins, one placeholder — and the `name` you may state
 
-⇒ rigc now writes each of those entries a name of its own, composed from the two
-names you already gave it:
+Two skins putting different art under one placeholder is what a skin is *for*. Each
+entry is its own attachment, filed under that placeholder in its own skin, and with
+no `name` field the runtime names every one of them by the placeholder
+(`getValue(map, "name", placeholder)`, `SkeletonJson.js:526`). That is legal Spine
+data, and it is the shape the editor exports: rigc emits it exactly as you wrote it.
 
 ```json
 "skins": {
   "default": { "block": { "block": { "image": "block.png" } } },
   "base":    { "patch": { "patch": { "image": "patch_a.png" } } },
-  "zulu":    { "patch": { "patch": { "image": "patch_a.png", "x": 4 } } }
+  "zulu":    { "patch": { "patch": { "image": "patch_b.png", "x": 4 } } }
 }
 ```
 
-emits, for slot `patch`
+emits two `patch` attachments in slot `patch`, one per skin, each with the `path` its
+image gives it (`patch_a`, `patch_b`) and **no `name`** — both answer to `patch` at
+runtime, and each is the one its skin shows.
+
+🔑 **State a `name` when the attachment's own name is not its placeholder.** A
+transcription of an export that carries one — `ingest` writes it for you — or any
+rig whose consumer reads `slot.attachment.name`. It is written verbatim, and `path`
+defaults to it, so an image named after it needs no `path`:
 
 ```json
-{ "name": "base/patch", "path": "patch", "width": 64, "height": 64 }
-{ "name": "zulu/patch", "path": "patch", "width": 64, "height": 64, "x": 4 }
+"base": { "patch": { "patch": { "name": "patch-base", "image": "patch-base.png" } } }
 ```
 
+emits `"name": "patch-base"` first and no `path`, and the runtime draws region
+`patch-base` for an attachment it calls `patch-base`, filed under `patch`.
+
+🔬 **Until [#796](https://github.com/firejune/rigc/issues/796) rigc composed a name
+here, and the reason it did was measured wrong.**
+[#541](https://github.com/firejune/rigc/issues/541) read the editor's refusal of a
+four-skin rig — `Multiple attachments have the same name: patch patch` — as "one
+name over several attachments, because a linked mesh resolves its parent by name",
+and [#552](https://github.com/firejune/rigc/issues/552) wrote
+`"<skin>/<placeholder>"` on every contested entry. Both halves fail a measurement:
+
+- **A linked mesh finds its source by skin, slot and KEY.** Through spine-core
+  4.3.13, two skins each fill `C` with a different mesh and no `name`, both load
+  named `C`, and a link with `source: "C"` binds the mesh of the skin its own
+  `skin` names. A `source` that spells a source's `name` instead throws
+  `Source mesh not found` — which rigc refuses by name before that (§3.4, *Linked
+  mesh*).
+- **The editor imports the uncomposed shape.** A production rig whose placeholders
+  are each filled by two named skins, meshes and linked meshes among them, imported
+  through Spine 4.3.26 with every composed name stripped. It is the file that editor
+  exported.
+
+What #541 had bisected was a rig whose **default** skin filled the contested
+placeholder beside the named ones — its smallest refusing variant was `default` plus
+one named skin — and that shape is refused on measurements of its own, below. The
+composition renamed every contested attachment of every multi-skin export at
+runtime, which `slot.attachment.name` shows a consumer and no gate could see; `diff`
+now reads it as `attachments.runtime_name`.
+
 🚨 **Every skin that shares a placeholder has to be a named one — the default
 skin may not be among them, and rigc refuses the rig if it is.** That is not a
 style rule; it is the editor's model, and two round trips through Spine
@@ -2368,18 +2404,9 @@ style rule; it is the editor's model, and two round trips through Spine
   are the same namespace, and both are `patch`.
 
 ⇒ **The rule: move the shared art into a named skin.** Call it `base`. Every
-filler of that placeholder is then a named skin, rigc composes all of them, and
-the names are unique within the slot — which is all
-[#541](https://github.com/firejune/rigc/issues/541) needed: `base/patch`,
-`zulu/patch` and `mike/patch` are three names. That shape is the one the editor
-does hold: the same three fillers in named skins imported, exported and measured
-**0.00 mean MAE** with names and paths intact.
-
-📎 **The earlier reading, kept because it was reasonable and wrong.** Between the
-two trips this guide said *compose off the default skin only* — keep the default
-skin's entry as its placeholder and name the others. Trip 7 supported it and trip
-8 refuted it: that is the spelling the editor refuses at the door. There is no
-third spelling, which is why this is a refusal rather than a naming scheme.
+filler of that placeholder is then a named skin, which is the shape the editor
+holds. Stating a `name` on the default skin's entry does not lift the refusal: that
+is the first of the two spellings above.
 
 What to know about it, and nothing to author:
 
@@ -2399,39 +2426,27 @@ What to know about it, and nothing to author:
   restated as the join the renderer actually performs it was a tautology over
   the resolve check beside it
   ([#574](https://github.com/firejune/rigc/issues/574)).
-- **`path` is restated, and it has to be.** `path` defaults to the attachment's
-  **name**, not to its placeholder, so an entry given a name and no path would
-  resolve its texture at `zulu/patch` and find no such region.
-  `A08_REGION_NAMES_MATCH_ATTACHMENTS` says so if it is ever dropped, naming the
-  skin, the slot, the placeholder and the path
-  ([#589](https://github.com/firejune/rigc/issues/589)); `A00_ROUNDTRIP_PARSE`
-  reported it in the parser's own words until then, and now defers to A08.
-- **Only contested placeholders are touched.** One skin filling a placeholder, or
-  two skins filling a slot under *different* placeholders, emit exactly what they
-  always did — every rig in this repository is byte-identical across the change.
-- **A composed name that collides is a compile error, not a surprise.** If some
-  other placeholder in the same slot is literally called `zulu/patch`, rigc refuses
-  and names both sites rather than emitting two attachments with one name again.
-  The walk covers every *uncontested* entry's plain name too, the default skin's
-  included — a name that composed nothing can still be the one another skin
-  composes.
-  (`/` is the separator because it appears in **0** of the 160 placeholder names and
-  159 atlas region names in `examples/` and `gallery/`, where `-` appears in 85 and
-  `_` in 37.)
+- **A stated `name` with no `path` resolves the region the name spells.** `path`
+  defaults to the attachment's **name**, not to its placeholder, so an entry naming
+  `patch-base` and drawing `patch_a.png` needs a `path` — and gets one, because the
+  image basename differs from the name. `A08_REGION_NAMES_MATCH_ATTACHMENTS` names
+  the skin, the slot, the placeholder and the path if the region is not there
+  ([#589](https://github.com/firejune/rigc/issues/589)).
 - **Each skin's art is measured and atlased on its own.** The example above points
-  both skins at one PNG, so there is one region; point them at two and there are
-  two, each attachment's `path` resolving to the file that attachment named and its
-  `width`/`height` measured off that file. Until
-  [#555](https://github.com/firejune/rigc/issues/555) only the first skin's PNG was
-  ever opened, and the second skin's art reached neither the atlas nor the
-  measurement — so name the two files **distinctly**, because the region name is
-  the basename and `a/patch.png` beside `b/patch.png` is refused (R5).
-
-⚠️ **The uniqueness scope is the slot, not the skeleton.** `spineboy-pro.json`,
-which the editor wrote, gives the name `head` to a region in slot `head` and to a
-bounding box in slot `head-bb`, and reuses `hoverglow-small` across eight slots. So
-a name shared between slots is normal and rigc leaves it alone; what #541 refused
-was one slot holding two.
+  the two skins at two PNGs, so there are two regions, each attachment's `path`
+  resolving to the file that attachment named and its `width`/`height` measured off
+  that file. Until [#555](https://github.com/firejune/rigc/issues/555) only the
+  first skin's PNG was ever opened, and the second skin's art reached neither the
+  atlas nor the measurement — so name the two files **distinctly**, because the
+  region name is the basename and `a/patch.png` beside `b/patch.png` is refused
+  (R5).
+
+⚠️ **Nothing measured says the editor wants names unique within a slot.**
+`spineboy-pro.json`, which the editor wrote, gives the name `head` to a region in
+slot `head` and to a bounding box in slot `head-bb`, and reuses `hoverglow-small`
+across eight slots; the production rig above holds same-named attachments in one
+slot across its named skins. The one refusal the editor was measured making is the
+default-skin share, and that is the rule rigc enforces.
 
 🚨 **Once a rig has named skins, no instrument here can see them until you say
 which one** ([#571](https://github.com/firejune/rigc/issues/571)). `render` and
@@ -2497,11 +2512,18 @@ other than what was written (measured on spine-core 4.3.13,
   only on the three kinds that draw a region, so it would be dropped in silence. The
   refusal names region, mesh and linkedmesh.
 
-`width` and `height` are the attachment's one size, every frame drawn into it. Omit
-them and rigc takes the frames' size — **only when every frame measures the same**;
-frames of different sizes are refused until you state the size, because picking one
-of them would be the compiler choosing a value. Under `--atlas-in` a stated size that
-disagrees with a packed frame is refused, as it is for one region.
+`width` and `height` are the attachment's one size, every frame drawn into it. The
+frames **may differ in size**: the runtime scales each frame's region into the
+attachment's size (`RegionAttachment.computeUVs`, `width / region.originalWidth`), so a
+stated size is emitted as stated and compared with no frame, on the loose route and
+under `--atlas-in` alike. That is what an editor exports for a series that mixes image
+sizes — the setup frame's size, the other frames as they are
+([#795](https://github.com/firejune/rigc/issues/795)). Omit them and rigc takes the
+frames' size — **only when every frame measures the same**; frames of different sizes
+are refused until you state the size, because picking one of them would be the
+compiler choosing a value. ⚠️ One region is different: its `width` is its image's size
+in every editor export, so under `--atlas-in` a stated size that disagrees with its
+packed region is still refused.
 `A46_SEQUENCE_ATTACHMENTS_SHOW_THE_FRAME_THE_FILE_STATES` (§5.2) holds the block and
 every frame the timelines show against the file.
 
@@ -3542,7 +3564,7 @@ a delta from the constraint's own setting.
   infinite inverse mass — the constraint stops moving.
 - **Four of the seven are bounded, and a key outside its bound is a compile
   error** ([#610](https://github.com/firejune/rigc/issues/610)). `mass` must be
-  `> 0`, `damping` must be strictly inside `(0, 1)`, and `mix` and `strength`
+  `> 0`, `damping` must be inside the closed `[0, 1]`, and `mix` and `strength`
   must be `0` or more. `A23_PHYSICS_CONSTRAINT_EFFECTIVE` applies the same four to
   a file rigc did not write, naming the animation, the constraint, the key time
   and the value — so the compiler is where a spec you wrote is refused, and the
@@ -3555,9 +3577,19 @@ a delta from the constraint's own setting.
   whole number the same negative is raised to a fractional power, which is NaN.
   [measured] one planted `damping` key of −0.5 on the generated physics fixture
   stays finite at 60 fps and at 30 (exponent 2), and is NaN within three steps of
-  the key at 45 and at 120. `1` never decays and above `1` diverges at every
-  rate. The refusal names the exponent and the rate for this reason, and `T101`
-  holds it to the two-rate measurement.
+  the key at 45 and at 120. Above `1` every velocity grows on every step and
+  diverges at every rate. The refusal names the exponent and the rate for this
+  reason, and `T101` holds it to the two-rate measurement.
+- ✅ **Both ends of `damping` are inside the bound**
+  ([#794](https://github.com/firejune/rigc/issues/794)). `1 ** x` is 1 and
+  `0 ** x` is 0 for every positive exponent, so neither depends on `fps`: at `1`
+  the velocity never decays and the jiggle holds for as long as it runs, and at
+  `0` every velocity is zeroed on every step, so the offset follows the bone with
+  no overshoot. Both are finite, at rest and keyed — [measured] 120 steps from
+  `Physics.reset` at 60, 45 and 30 fps on the generated physics fixture, which
+  `T109`–`T111` hold. ⚠️ `1` is also what a 4.2 file means by saying nothing:
+  4.2's parser reads an omitted `damping` as `1` where 4.3's reads `0.85`
+  (§4.6), so a rig migrated from 4.2 that keys "the default" keys `1`.
 - 🚫 **`inertia`, `wind` and `gravity` are bounded nowhere, and neither is the top
   of `mix`.** The runtime documents no range for the first three, and
   `PhysicsConstraintPose` documents `mix` as "a percentage (0+)" — so a negative
@@ -3962,11 +3994,16 @@ key times. One lag, one place.
 mass?, wind?, gravity?, mix?, fps?, limit? }`. These are emitted into the 4.3
 `constraints` array. Seven of them — the six tuning numbers and `mix` — can also
 be **keyed over time** as `tracks` entries naming this constraint (§4.4); this
-table is the value at rest, and a timeline overrides it while it plays. `mass: 0` becomes an infinite inverse mass and `damping ≥ 1`
+table is the value at rest, and a timeline overrides it while it plays. `mass: 0` becomes an infinite inverse mass and a `damping` above 1
 never settles — both are `A23`, here and on every timeline key that states them
-([#610](https://github.com/firejune/rigc/issues/610)); a `damping` at or below 0
-is refused as well, and below 0 whether it is NaN depends on `fps` — §4.4
-([#748](https://github.com/firejune/rigc/issues/748)). ⚠️ `strength: 0` is `A23` **here and not on a key**:
+([#610](https://github.com/firejune/rigc/issues/610)); a `damping` below 0
+is refused as well, and whether it is NaN depends on `fps` — §4.4
+([#748](https://github.com/firejune/rigc/issues/748)). `damping` is `[0, 1]`
+with both ends in: `1` never decays and `0` zeroes the velocity on every step,
+both finite at every rate ([#794](https://github.com/firejune/rigc/issues/794)).
+⚠️ An omitted `damping` is `0.85` to 4.3's parser (`SkeletonJson.js:308` in
+4.3.13) and `1` to 4.2's (`SkeletonJson.js:242` in 4.2.120), so a constraint
+migrated from 4.2 that stated nothing may arrive stating `1` — which builds. ⚠️ `strength: 0` is `A23` **here and not on a key**:
 at rest it is a constraint nothing pulls back, and on a key it is a release somebody
 asked for, which §4.4 states with the measurement behind it
 ([#727](https://github.com/firejune/rigc/issues/727)). A negative `strength` is
@@ -5441,7 +5478,7 @@ or the key's position in its own track. These are the frequent ones, verbatim:
 | `physics constraint "*": the name is reserved — …` / `` `physics."*"` names a physics constraint "*", and that name is reserved … `` | §3.5 — `"*"` is the target of the timeline that names no constraint; rename the constraint |
 | `animation "A": group "G" lists "*", which is not a constraint but the target that names none …` | §4.4 — write `"*"` as the track's `physics` field |
 | `animation "A" bone "X" translatex: key value must be an array of 1 number(s)` | the value shape must match the property (§4.4) |
-| `animation "A" physics constraint "C" mass key at t=… is 0 (massInverse Infinity); must be > 0 — …` | §4.4 — a keyed physics value the runtime cannot use. The message names the bound and the `PhysicsConstraint.js` lines that make it one: `mass` is `> 0`, `damping` is inside `(0, 1)`, `mix` and `strength` are `0` or more, and `inertia`/`wind`/`gravity` are bounded nowhere ([#610](https://github.com/firejune/rigc/issues/610)). ⚠️ Those are the bounds a **key** is held to. A setup `strength` of `0` is refused too, but by `A23` rather than here, and with its own sentence — `physics "C" has strength 0; nothing pulls it back` ([#727](https://github.com/firejune/rigc/issues/727)); a setup `strength` below 0 says the offset is pushed away and grows, the same arm this message quotes for a negative key ([#748](https://github.com/firejune/rigc/issues/748)). A `damping` key's sentence names the exponent `60 * step` and why a negative is NaN at any `fps` where `60 / fps` is not whole (§4.4) |
+| `animation "A" physics constraint "C" mass key at t=… is 0 (massInverse Infinity); must be > 0 — …` | §4.4 — a keyed physics value the runtime cannot use. The message names the bound and the `PhysicsConstraint.js` lines that make it one: `mass` is `> 0`, `damping` is inside `[0, 1]`, both ends included ([#794](https://github.com/firejune/rigc/issues/794)), `mix` and `strength` are `0` or more, and `inertia`/`wind`/`gravity` are bounded nowhere ([#610](https://github.com/firejune/rigc/issues/610)). ⚠️ Those are the bounds a **key** is held to. A setup `strength` of `0` is refused too, but by `A23` rather than here, and with its own sentence — `physics "C" has strength 0; nothing pulls it back` ([#727](https://github.com/firejune/rigc/issues/727)); a setup `strength` below 0 says the offset is pushed away and grows, the same arm this message quotes for a negative key ([#748](https://github.com/firejune/rigc/issues/748)). A `damping` key's sentence names the exponent `60 * step` and why a negative is NaN at any `fps` where `60 / fps` is not whole (§4.4) |
 | `a key carries both a named easing and a raw curve; pick one` | R6 |
 | `last key carries an easing but has nothing to ease to` | drop `ease`/`curve` from the final key |
 | `key times must strictly increase (at t=…)` | including after `lag` and `stagger` |
@@ -5516,7 +5553,7 @@ or the key's position in its own track. These are the frequent ones, verbatim:
 | `N pair(s) of animation names have no one order: … "Fx/a" / "fx/b" (folder) — "Fx/a" and "fx/b" sit in the sibling folders "Fx" and "fx", which the comparator leaves in one place …; rename one of the two folders so they differ by more than letter case, spacing or a leading zero` | **R10** — rename until no pair is left. The kind in brackets says which of the three things the five stored round trips leave open decides the pair: `number` (two digit runs that are each one number written twice, pointing opposite ways), `separator` (a whitespace character that is not a space) or `folder` (two sibling folders the comparator cannot separate). rigc keys `animations` in the editor's own comparator, read off `fixtures/editor-order/probe{1..5}.{in,out}.json` ([#728](https://github.com/firejune/rigc/issues/728)) — so a pair those files settle is emitted rather than refused, **including a pair that differs only in case**, whose order is then the one your spec declared. On the three that are left, the editor's re-key repoints every slider whose animation moves index ([#535](https://github.com/firejune/rigc/issues/535)) |
 | `N pair(s) of skin names have no one order: … "Fx/a" / "fx/b" (folder) — …` | **R11** — rename until no pair is left. The same shape and the same three kinds as the row above, because it is the same comparator: two of the five round trips carried one name list as both collections and both came back in one order ([#728](https://github.com/firejune/rigc/issues/728)). ⚠️ This row was **wider** than R10's until then — `Zulu`/`mike` and `mike10`/`mike2` built as animation names and were refused as skin names ([#541](https://github.com/firejune/rigc/issues/541)) — and both build now |
 | `slot "patch": placeholder "patch" is filled by the "default" skin AND by skins "zulu", "mike", and the Spine editor has no way to hold that … Move the default skin's entry for this slot into a named skin — call it "base"` | **R12** — do what it says: move that entry out of `default` into a named skin. The editor has no representation for a placeholder the default skin shares with a named one, in either spelling, and §3.4.2 has both measurements. Renaming the placeholder does not help; the shape is what is refused |
-| `N attachment name collision(s): a placeholder that more than one skin fills is emitted with the name "<skin>/<placeholder>" … slot "patch": skin "base" placeholder "zulu/patch" and skin "zulu" placeholder "patch" would both be named "zulu/patch"` | **R12** — rename the placeholder or the skin. rigc composes an attachment name for every placeholder more than one skin fills (§3.4.2), and this fires when a composed name is one another entry in the same slot already answers to — including a plain name in the default skin, which composed nothing. Both sites are named; either rename ends it |
+| `skin "S" slot "X" attachment "P": "name" is V, which is not a string. An attachment's name is the runtime's `Attachment.name` …` | §3.4 — write the name as a string, or leave the key out and the attachment is named by its placeholder. It is written verbatim and `path` defaults to it, so a number there would reach the atlas as a region name nobody spelled |
 
 ⚠️ **One refusal in this section is not a `CompileError`, and it is `explain`'s.**
 `explain` prints the `DEFORM` block by **posing** the rig, and a pose resolves every
@@ -5630,7 +5667,7 @@ Fix A00 and run it again ([#568](https://github.com/firejune/rigc/issues/568)).
 | `A20_MESH_WEIGHTS_COHERENT` | both ◑ | a weighted vertex with no bone, a negative weight, a bone index out of range, or weights that do not sum to 1. Under `spine-html` also: an unweighted mesh, a binding at weight 0, or **a bone the mesh declares that no vertex binds** — `mesh "x" declares bone "grip_b" and none of its 25 vertices binds it; the weights reference "box", "grip_a"`. Those three are one sentence about rigc's own generators: the bone set a generated mesh declares is the bone set its weights reference, so a `controls` or `chain` name that moves nothing is a defect where a foreign mesh's is not ([#684](https://github.com/firejune/rigc/issues/684)). Fix the rig spec's `controls`/`chain`, or the manifest's `control_bones`. **SKIP** when the skeleton carries no mesh attachment ([#580](https://github.com/firejune/rigc/issues/580)) |
 | `A21_MESH_RIM_PINNED` | archetype | a generated ring's rim, a ribbon's entry row, or a contour's outline (which is all of it) is not pinned to its anchor bone at weight 1 |
 | `A22_MESH_UVS_IN_UNIT_RANGE` | both | a mesh UV outside its region, or a UV array that disagrees with the vertex count. **SKIP** when the skeleton carries no mesh attachment ([#580](https://github.com/firejune/rigc/issues/580)) |
-| `A23_PHYSICS_CONSTRAINT_EFFECTIVE` | both | a physics constraint that drives no component, rests at `mix: 0` with **no timeline in any animation keying that `mix` above 0**, has `mass: 0`, has `strength` at or below 0 — `0` says `nothing pulls it back`, below 0 says the offset `is pushed away and grows with every step`, both read off the row's `outside` arms, which the key's refusal quotes too ([#748](https://github.com/firejune/rigc/issues/748)) — or has `damping` outside `(0, 1)` so it never settles — **at rest, and on every physics timeline key** ([#610](https://github.com/firejune/rigc/issues/610), [#743](https://github.com/firejune/rigc/issues/743)). The timeline arm reads each key through the runtime's own `PhysicsConstraint*Timeline.set`, so a keyed `mass` is judged as the `massInverse` it becomes, and the detail names the animation, the constraint, the key time, the value and the bound. Two differences between the two arms, and the runtime is the reason for both: a **key** of `mix: 0` is accepted, because `update` opens with `if (mix === 0) return;` and muting a constraint for a stretch is what a mix timeline is for — the editor's own `sack-pro` example keys it there on 24 of its 36 mix keys — and a **key** of `strength: 0` is accepted, because it releases the constraint for the span with `damping` and `inertia` still applied and the next key pulls the offset back, measured through spine-core at no NaN, a coast to a limit and a return in 54 steps ([#727](https://github.com/firejune/rigc/issues/727)). As a **setup** value `strength: 0` is still refused by the arm above, and `mix: 0` is refused only when nothing keys it above 0. The `mix` branch above is why `mix` is the one setup value a key can answer for: at rest the constraint is **inert** rather than broken, so a rig that rests muted and is keyed above 0 is refused by nothing, while a rig resting at `mass: 0` is `massInverse` Infinity before anything plays and no key reaches back into that. The detail of the refusal says both halves and how many animations were searched: `physics "C" has mix 0 and none of the 3 animations keys its mix above 0; it is muted — rest it above 0, or key its mix above 0 in an animation`. The search counts the unnamed global timeline for every constraint whose own `mixGlobal` is set, reads each key through the runtime's accessor, counts every sample of a Bezier between two keys as a value the timeline poses — so two keys of 0 joined by a curve lifted above 0 are a rescue, measured to move the bone — and takes an animation a slider applies like any other. It is the one reading `A36` and `A37` use as well ([#752](https://github.com/firejune/rigc/issues/752)). `inertia`, `wind`, `gravity` and the top of `mix` are bounded nowhere, at rest or keyed. `ingest` does not carry a constraint that drives no component into the spec it writes: it omits it with its timelines and reports `PHYSICS_DRIVES_NOTHING` ([INGEST §2.0](INGEST.md), [#731](https://github.com/firejune/rigc/issues/731)), so this sentence is met on a file, never on a decompiled rebuild. **SKIP** when the skeleton declares no physics constraint ([#580](https://github.com/firejune/rigc/issues/580)) — the same sentence `A36` and `A37` have always printed for their own constraint types |
+| `A23_PHYSICS_CONSTRAINT_EFFECTIVE` | both | a physics constraint that drives no component, rests at `mix: 0` with **no timeline in any animation keying that `mix` above 0**, has `mass: 0`, has `strength` at or below 0 — `0` says `nothing pulls it back`, below 0 says the offset `is pushed away and grows with every step`, both read off the row's `outside` arms, which the key's refusal quotes too ([#748](https://github.com/firejune/rigc/issues/748)) — or has `damping` outside `[0, 1]`, which says `physics "C" has damping 1.5; must be inside [0, 1] — above 1 every velocity grows on every step, and below 0 it is NaN at any fps where 60 / fps is not whole`, the bound read off the row the key's refusal reads; `1` and `0` are inside, since both are finite at every rate ([#794](https://github.com/firejune/rigc/issues/794)) — **at rest, and on every physics timeline key** ([#610](https://github.com/firejune/rigc/issues/610), [#743](https://github.com/firejune/rigc/issues/743)). The timeline arm reads each key through the runtime's own `PhysicsConstraint*Timeline.set`, so a keyed `mass` is judged as the `massInverse` it becomes, and the detail names the animation, the constraint, the key time, the value and the bound. Two differences between the two arms, and the runtime is the reason for both: a **key** of `mix: 0` is accepted, because `update` opens with `if (mix === 0) return;` and muting a constraint for a stretch is what a mix timeline is for — the editor's own `sack-pro` example keys it there on 24 of its 36 mix keys — and a **key** of `strength: 0` is accepted, because it releases the constraint for the span with `damping` and `inertia` still applied and the next key pulls the offset back, measured through spine-core at no NaN, a coast to a limit and a return in 54 steps ([#727](https://github.com/firejune/rigc/issues/727)). As a **setup** value `strength: 0` is still refused by the arm above, and `mix: 0` is refused only when nothing keys it above 0. The `mix` branch above is why `mix` is the one setup value a key can answer for: at rest the constraint is **inert** rather than broken, so a rig that rests muted and is keyed above 0 is refused by nothing, while a rig resting at `mass: 0` is `massInverse` Infinity before anything plays and no key reaches back into that. The detail of the refusal says both halves and how many animations were searched: `physics "C" has mix 0 and none of the 3 animations keys its mix above 0; it is muted — rest it above 0, or key its mix above 0 in an animation`. The search counts the unnamed global timeline for every constraint whose own `mixGlobal` is set, reads each key through the runtime's accessor, counts every sample of a Bezier between two keys as a value the timeline poses — so two keys of 0 joined by a curve lifted above 0 are a rescue, measured to move the bone — and takes an animation a slider applies like any other. It is the one reading `A36` and `A37` use as well ([#752](https://github.com/firejune/rigc/issues/752)). `inertia`, `wind`, `gravity` and the top of `mix` are bounded nowhere, at rest or keyed. `ingest` does not carry a constraint that drives no component into the spec it writes: it omits it with its timelines and reports `PHYSICS_DRIVES_NOTHING` ([INGEST §2.0](INGEST.md), [#731](https://github.com/firejune/rigc/issues/731)), so this sentence is met on a file, never on a decompiled rebuild. **SKIP** when the skeleton declares no physics constraint ([#580](https://github.com/firejune/rigc/issues/580)) — the same sentence `A36` and `A37` have always printed for their own constraint types |
 | `A24_AXIS_SPACE_STROKE` | archetype | a bone under the rig's `axisBone` was keyed with a screen-space Y component, or the axis bone itself was keyed. **SKIP** when the rig declares no axis bone, and also when no animation keys that bone or anything under it ([#580](https://github.com/firejune/rigc/issues/580)) |
 | `A25_DETACHED_BONE_PARENTAGE` | archetype | a bone the rig declares `detached` is a descendant of the bone it must never hang under |
 | `A26_SLOT_DRAW_ORDER` | archetype | the emitted slots are not the rig's slot table — a slot is out of order, is not in the table at all, or is in the table and missing from the skeleton (§3.3). **SKIP** when the rig declares no canonical slot order. ⚠️ A skeleton with **no** slot beside a rig that declares some is **not** a skip, and it is the one rule in this family where an empty loop is not a vacuous pass ([#580](https://github.com/firejune/rigc/issues/580)): the completeness clause reads it as every declared slot lost and names them, which is the maximal case of what [#575](https://github.com/firejune/rigc/issues/575) filed |
@@ -8161,6 +8198,33 @@ says which.**
   t=0, so the editor wrote them `value` alone, and that rule would have moved
   `time` — first in every other key kind the editor writes — behind `value`.
 
+🔬 **Two positions and one fold are measured on a production set, not on
+`examples/`** ([#791](https://github.com/firejune/rigc/issues/791)). The twelve
+exports carry no mesh `path` or `color` and no slot name outside ASCII — `IG84`
+and `IG85` count both on every run with a corpus — so the table cannot learn
+either, and what rigc writes for them was read off 42 production exports
+instead:
+
+- **A mesh attachment writes `path` and `color` right after `type`, `path` before `color` — measured on a production set (#791), not on `examples/`.**
+  18 meshes whose `path` differs from their name wrote it second, and 1 with a
+  `color` wrote that second; no mesh carried both. The row does not list them,
+  so the position is the constructor's — `meshTextureKeys` in
+  [`src/compile.ts`](../src/compile.ts), which every mesh route spreads right
+  after `type` (`S104`). A region's `path` and a linked mesh's keys stay where
+  they were: neither was in the set, and an analogy is not a measurement.
+- **A skin's slot keys are compared after `foldBeforeComparing`, which reads U+3000 as U+0020 and U+FF10–U+FF19 as U+0030–U+0039** —
+  the ideographic space as a space, the full-width digits as `0`–`9`
+  (`EDITOR_NAME_FOLD`). One map of 95 slot keys, 7 of them carrying those
+  characters, came back in an order this reproduces 95 of 95 and neither a
+  codepoint sort nor the comparator without the fold does (`S105`). It is **not**
+  `normalize('NFKC')`, though NFKC folds both the same way: NFKC, a classifier
+  that reads every Unicode digit as a digit and every space separator as a space,
+  and a width fold alone all reproduce that map and disagree past it (on `fi`,
+  `²`, `٣`, `Ａ`, a no-break space), and what all three agree on is exactly
+  these two classes. The comparator is R10's, so animation and skin names are
+  compared after the fold too. A pair the fold does not close — a tab, a
+  no-break space — still keeps the map in rigc's order, whole (`S106`).
+
 🔸 **An object keyed by NAMES is not a field order**, and the table does not
 touch one. A bone's or a slot's timelines, and a transform constraint's
 `properties` and each `to` inside them, are read into the runtime's arrays in the

package/docs/FACE.md

@@ -1474,7 +1474,9 @@ is the card for having left the sentence standing:
   names. ⚠️ **The editor was never silent**: it named the section, the attachment
   and the rule, and `tools/editor_roundtrip.ts` had discarded its stdout and
   stderr. What changed is [#552](https://github.com/firejune/rigc/issues/552) —
-  the composed `<skin>/<placeholder>` name, with `default` pinned first — and what
+  the composed `<skin>/<placeholder>` name, with `default` pinned first; the
+  composition was retired by [#796](https://github.com/firejune/rigc/issues/796),
+  which measured that it was never what the editor objected to — and what
   still binds is [#567](https://github.com/firejune/rigc/issues/567): a
   `CompileError` when the default skin shares a placeholder with a named one. ⇒
   Skins are not the reason to stay at one, and every figure on this page was

package/docs/INGEST.md

@@ -621,7 +621,6 @@ is the one failure a comparison of two sets cannot show you.
 | `ANIMATION_GROUP` | `BLOCK` | 1 | the animation carries a group the motion spec has no home for. The detail names the ten it does carry. `drawOrderFolder` is the group to know about: the runtime reads it and builds a timeline from it, and no export in this corpus carries one | transcribe that group by hand (§2), or accept that the rebuild does not carry it |
 | `ATTACHMENT_<TYPE>` | `BLOCK` | 1 | an attachment of a type rigc does not emit; the code is composed from the type, so on the one type left it reads `ATTACHMENT_POINT`. rigc emits region, mesh, linkedmesh, boundingbox, clipping and path — `linkedmesh` since [#691](https://github.com/firejune/rigc/issues/691), and `point` is the remaining deferred type | the rebuild will not have that attachment at all. `docs/SPEC_COVERAGE.md` part 1-6 says what a deferred type would carry |
 | `ATTACHMENT_LINK_GEOMETRY` | `LOSS` | 0 | a **linked mesh** that also states `uvs`, `triangles`, `vertices`, `hull` or `edges`. The parser returns from the `source` branch before `readVertices` (`SkeletonJson.ts:582-586`), so those keys are read by nothing at all and the attachment draws the geometry its `source` names; the rig spec has no home for them either, because `build` refuses geometry on a link by name. The detail lists the keys and the source. Until [#710](https://github.com/firejune/rigc/issues/710) the rebuild dropped them with no line at all, so an `ingest` that normalised somebody's file said nothing about it | nothing. The rebuild is the mesh the runtime was already drawing — and if those keys were the geometry you meant, take `source` off and author it as a mesh of its own. `A44_LINKED_MESH_STATES_NO_GEOMETRY_OF_ITS_OWN` is the same fact at the gate |
-| `ATTACHMENT_NAME` | `LOSS` | 0 | the rebuilt attachment answers to a different name than the source's. **Two shapes, one comparison.** Where only **one** skin fills the placeholder, any stated `name` is lost: rigc writes none — it composes `<skin>/<placeholder>` exactly where a placeholder is contested. Where the placeholder **is** contested, rigc composes that name, and the source's name — what it states, or its placeholder where it states none (`SkeletonJson.js:526`) — is compared with it: equal is rigc's own emit and prints nothing, different is a rename and the detail states **both strings**. Until [#746](https://github.com/firejune/rigc/issues/746) the contested half printed nothing at all. A contested placeholder the **default** skin fills gets no line — the compiler composes nothing there and refuses the rebuild by name. 🚨 **The name is also the ATLAS REGION KEY**, and the detail says what became of it: `readAttachment` reads `name = getValue(map, "name", placeholder)` and then `path = getValue(map, "path", name)`, so `path` defaults to the **name** and not to the placeholder. A name that differs from the placeholder is therefore **kept as `path`** on an attachment that resolves a region — region, mesh, linked mesh — and the detail names the region. The three shapes that keep nothing say which they are: the source stated its own `path` (carried unchanged), the name **is** the placeholder (same region either way), or the type resolves no region at all (`boundingbox`, `clipping`, `path`). Until [#742](https://github.com/firejune/rigc/issues/742) nothing was written, so the rebuild asked the atlas for the placeholder and `A08_REGION_NAMES_MATCH_ATTACHMENTS` refused it | nothing about the art, which is carried. The **name** is what is gone, so this matters where something downstream looks that attachment up by the name the source gave it |
 | `ATTACHMENT_SEQUENCE` | `BLOCK` | 1 | a `sequence` block — a numbered image series — that the rig spec cannot say **as written**. Since [#729](https://github.com/firejune/rigc/issues/729) a well-formed block on a region, mesh or linked mesh is carried field for field, with no `image` on the loose route (the frames `<path><number>` are the art), and a `sequence` timeline with it; what is left here is a block the parser reads into a series other than the one written — no `count` (0 regions), a `setup` past the end (clamped), a fraction — or one on a `boundingbox`, `clipping` or `path`, where the parser never reads it. The detail quotes the block and says which | the rebuild draws the single region the attachment names. Fix the block in the source — a `count` is the usual one — and ingest again |
 | `ATTACHMENT_TIMELINE` | `BLOCK` | 1 | an attachment timeline that is neither `deform` nor `sequence`. Both are carried since [#729](https://github.com/firejune/rigc/issues/729), and `readAnimation` tests an attachment timeline for exactly those two names and ignores anything else (`SkeletonJson.js:1147-1201`) — so what reaches this line is a name outside the format, which no player plays either | fix the timeline's name in the source, or accept that the rebuild does not carry it |
 | `BONE_FIELD` | `BLOCK` | 1 | a bone field with no rig-spec field, so it is dropped. A 4.0/4.1 export spelling `transform` where 4.3 spells `inherit` lands here; so does a misspelling | check the name against AUTHORING §3 first — a typo and an unsupported field read exactly the same |
@@ -651,18 +650,16 @@ is the one failure a comparison of two sets cannot show you.
 | `TIMELINE_KEY_RESTATED` | `LOSS` | 0 | an editor omits a channel that equals the parser's default, and the motion spec's `v` is positional, so the omission is written out at that default **in the spec** — and the line is printed only where the **file** will carry it too. It was the commonest line in a real run until [#716](https://github.com/firejune/rigc/issues/716): the emitter now leaves a channel out wherever it is the one the parser reads without it ([AUTHORING §10.6c](AUTHORING.md)), so on every key kind with a row the rebuild is the source's own text and nothing is said — measured on the twelve exports, 341 tracks printed it before and 0 after. What still prints it is a timeline whose keys have no row (`shearx`, `alpha`, path `spacing`, …), and an `inherit` key: one that omits the mode is written as `normal` — the parser's default — and one spelled with a capital first letter (`NoScale`) as the editor's `noScale`, the same mode either way | nothing. The same values the runtime reads, spelled out — a larger file and the same animation |
 | `TRANSFORM_KEY_FIELD` | `BLOCK` | 1 | as `IK_KEY_FIELD`, on a `transform` timeline | as `IK_KEY_FIELD` |
 
-⚠️ **One thing the table cannot carry: the region key is kept where a placeholder is
-CONTESTED too, whether or not a line is printed.** On a contested placeholder rigc
-composes `<skin>/<placeholder>`, so `ATTACHMENT_NAME` fires there only where the
-source's name differs from that composed one ([#746](https://github.com/firejune/rigc/issues/746);
-`IG68`–`IG70` hold both directions) — and until
-[#742](https://github.com/firejune/rigc/issues/742) the region went with the name anyway:
-`compile` pins a composed name's `path` at the **placeholder**, so two skins naming two
-regions rebuilt onto **one**, neither of them the art the source drew, with no line
-printed. `ingest` now writes the source's region as `path` on both, and `IG53` in
-`bun run selftest` is what holds it — the clause it measures is the count of *distinct*
-regions, because every row can name a region the pack has and still be one region doing
-the work of two.
+⚠️ **An attachment's `name` has no row, because nothing about it is lost any more.**
+Until [#796](https://github.com/firejune/rigc/issues/796) the rig spec had no field for
+one, so `ATTACHMENT_NAME` reported it as a `LOSS` in two shapes: a stated name on a
+placeholder one skin fills was kept only as `path` and the rebuild answered to the
+placeholder, and a contested placeholder was renamed `<skin>/<placeholder>` by the
+compiler. The field exists now, `ingest` carries a stated `name` verbatim — equal to its
+key or not, exactly as the source spells it — and writes none where the source states
+none, and `compile` emits exactly what the spec states. The code went with the loss it
+named; `IG86`–`IG89` in `bun run selftest` hold the carry, the rebuild's loaded names and
+regions, and the two-skin shape with a link in each.
 
 ### Transcription — the route that made a foreign skeleton yours
 

package/docs/SPEC_COVERAGE.md

@@ -633,20 +633,21 @@ with the member's own `skin: true` — either half alone is refused, because `Sk
 | `clipping` | ✅ under `--profile spine` · 🚫 under `spine-html` | `end` (refused when it names no slot), `convex`, `inverse`, `vertexCount`, geometry, `color`. **A33**, and **A11_NO_CLIPPING_ATTACHMENTS** is the renderer-profile refusal |
 | `sequence` block | ✅ | on a region, a mesh or a linked mesh: `count` (required — the parser's 0 loads no region), `start`, `digits`, `setup`, emitted as stated. The frames are the regions `<path><start + i>` zero-padded to `digits`, each atlased by name — the loose route's PNG of that name, or `--atlas-in`'s region — and a missing frame is refused with its number and the name looked for. A `setup` past the end (clamped), a fraction, an `image` or a `generator` beside it, and a `sequence` on any other kind are refused by name. **A46_SEQUENCE_ATTACHMENTS_SHOW_THE_FRAME_THE_FILE_STATES** ([#729](https://github.com/firejune/rigc/issues/729)) |
 
-Across all five types, rigc emits the attachment's own **`name`** in exactly one case: a placeholder
-that more than one skin fills (`compile.ts`'s `composeSkinAttachmentName` and `nameSkinAttachment`).
-Part 1-5 above states why it matters — `name` defaults to the placeholder and `path` defaults to
-`name` — so several skins under one placeholder are several attachments with one name, which
-spine-core accepts and the Spine editor refuses on import
-([#541](https://github.com/firejune/rigc/issues/541)). The composed name is `<skin>/<placeholder>`,
-`path` is restated beside it so the region still resolves, and a placeholder one skin fills is
-emitted with neither. ⚠️ The **`default` skin may not be one of those skins**, and that is a
-`CompileError` rather than an emission rule: the editor holds no placeholder the default skin shares
-with a named one in either spelling — named, the export re-keys the attachment by its name and the
-slot's setup attachment stops resolving; unnamed, the import is refused with `Multiple attachments
-have the same name` ([#567](https://github.com/firejune/rigc/issues/567), Spine 4.3.26, round trips
-7 and 8). Nothing else in the tree carries a `name`: of the twelve editor exports in `examples/`,
-**0** attachments do, because all twelve declare one skin.
+Across all six types rigc emits, the attachment's own **`name`** is written exactly when the rig
+spec states it, verbatim, as the attachment's first key — and never derived
+([#796](https://github.com/firejune/rigc/issues/796)). Part 1-5 above states why it matters:
+`name` defaults to the placeholder and `path` defaults to `name`, so it is the runtime's
+`Attachment.name` and, on a type that draws, the region it resolves; nothing resolves an
+attachment by it. From [#541](https://github.com/firejune/rigc/issues/541) to #796 rigc composed
+`<skin>/<placeholder>` for a placeholder several skins fill, on the reading that a linked mesh
+resolves its source by name; it resolves it by skin, slot and key, and the editor imports the
+uncomposed shape. ⚠️ The **`default` skin may not be one of the skins sharing a placeholder**, and
+that is a `CompileError` rather than an emission rule: the editor holds no placeholder the default
+skin shares with a named one in either spelling — named, the export re-keys the attachment by its
+name and the slot's setup attachment stops resolving; unnamed, the import is refused with
+`Multiple attachments have the same name` ([#567](https://github.com/firejune/rigc/issues/567),
+Spine 4.3.26, round trips 7 and 8). Of the twelve editor exports in `examples/`, **0**
+attachments state a `name`, because all twelve declare one skin.
 
 Mesh geometry is generated by exactly three procedural generators (`mesh.ts`): `buildRingMesh`
 (three concentric rings + hub, outer two pinned), `buildRibbonMesh` (a two-wide strip along a bone

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "spine-rigc",
-  "version": "0.35.0",
+  "version": "0.36.0",
   "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": {