spine-rigc 1.0.0 → 1.0.2

package/docs/AUTHORING.md

@@ -11,8 +11,8 @@ checked against the code that implements it.
 🚨 **The gate cannot see a wrong animation, and it will not tell you so.** `build`
 is green when the file is *valid* — parseable, steppable, nothing degenerate in it.
 Whether the animation is the one you were asked for is a question it does not ask
-and has no way to answer. This is not a caveat: rung 1's first honest run shipped a
-build with **every easing in the file reversed** and the gate passed it green. If you were given pictures, `check` (**§9**) is the half of the loop
+and has no way to answer. This is not a caveat: a build with **every easing in the
+file reversed** gates green. If you were given pictures, `check` (**§9**) is the half of the loop
 that can see that, and a run that skips it has verified nothing about the motion.
 
 - Formats and CLI reference: [README.md](../README.md)
@@ -20,10 +20,11 @@ that can see that, and a run that skips it has verified nothing about the motion
 - The motion spec and emitted shapes: [`src/types.ts`](../src/types.ts)
 - What the motion spec's own parser proves, and which refusals it deliberately
   leaves to compile time: [`src/motion.ts`](../src/motion.ts)
-- What the format holds and rigc covers: `docs/SPEC_COVERAGE.md` — 🚫 **not an
-  authoring input, and deliberately unlinked**: it inventories the benchmark corpus
-  skeleton by skeleton, so it is on the ladder run's forbidden list. Named here for a
-  maintainer, not offered to a run
+- What the Spine 4.3 format holds, field by field: `docs/SPEC_COVERAGE.md` — 🚫 **not
+  an authoring input, and deliberately unlinked**: it and the dated survey it was split
+  from, `docs/SURVEY_2026-08-22.md`, which inventories the benchmark corpus skeleton by
+  skeleton, are both on the ladder run's forbidden list. Named here for a maintainer,
+  not offered to a run
 - Working with a skeleton **somebody else authored** — what the CLI will and will not
   do with a foreign `skeleton.json`, transcribing one into specs, re-pivoting and
   renaming it: `docs/INGEST.md`. 🚫 **Not an authoring input, and deliberately
@@ -52,13 +53,12 @@ property of the tool.
 
 🔒 **A ladder run reads this guide in full and does not follow its references out of
 it.** The guide is allowed reading; not everything it cites is. Citations here are
-provenance for a reader of record — the loop that hit a trap, the issue that closed it —
-and following one can arrive at a stored candidate's own spec, at the corpus inventory,
+provenance for a reader of record, and following one can arrive at a stored candidate's own spec, at the corpus inventory,
 or at the **derivation** of the gate a verdict is read against, none of which a run may
 open. ⭐ The gate's **clause statements** are a different matter and a run may read them:
 they are in
 [GATE.md](https://github.com/firejune/rigc/blob/main/docs/GATE.md), which is
-repository material and not in the published package — item 11 of the allowed list (owner ruling 2026-08-29) — the
+repository material and not in the published package — item 11 of the allowed list — the
 measure, the comparator, the number and the SKIP semantics, with no recorded figure in it.
 So: read the
 document, take its numbered sections as the input, and leave its footprints to whoever
@@ -160,11 +160,11 @@ What the flags mean:
 | `--rig` | the rig spec — skeleton structure |
 | `--motion` | the motion spec — time |
 | `--out` | directory for `skeleton.json` + `skeleton.atlas`; atlas page paths and `skeleton.images` are written relative to it |
-| `--copy-images` | `build` only: also copies every page **the emitted atlas names** into `--out` and rewrites the atlas to the copies, so the directory is self-contained enough to zip or commit on its own, and points `skeleton.images` at `--out` itself so the editor's import finds the parts beside the skeleton (issue #370; §3.1 says why it is spelled `../<out>/` and not `./`). Under `--atlas-in` those pages are the pack's, not one per part (issue #693 — **§0.2**). Default is unchanged — page paths still point at the source art (issue #217) |
-| `--pack` | `build` only: arrange every part onto **shared** atlas page(s), written into `--out` as real PNGs, instead of one page per part. Lossless — nothing is resampled, trimmed or rotated. Default is unchanged (issue #4) — **§0.1** |
+| `--copy-images` | `build` only: also copies every page **the emitted atlas names** into `--out` and rewrites the atlas to the copies, so the directory is self-contained enough to zip or commit on its own, and points `skeleton.images` at `--out` itself so the editor's import finds the parts beside the skeleton (§3.1 says why it is spelled `../<out>/` and not `./`). Under `--atlas-in` those pages are the pack's, not one per part (**§0.2**). Without it, page paths point at the source art |
+| `--pack` | `build` only: arrange every part onto **shared** atlas page(s), written into `--out` as real PNGs, instead of one page per part. Lossless — nothing is resampled, trimmed or rotated. The default is one page per part — **§0.1** |
 | `--page-size` | `build --pack` only: the largest page edge (default `2048`). A ceiling, not the size: page edges are powers of two and the one written is the smallest that holds the pack — **§0.1** |
 | `--padding` | `build --pack` only: the gutter each region reserves on every side (default `2`), filled by extending the region's own edge pixels outwards. `0` is not a legal-but-tight choice, it is bleed — **§0.1** |
-| `--atlas-in` | `build` and `explain`: resolve every part against the **regions of a pre-packed `.atlas`** instead of against loose PNGs. Region geometry is read from the file and sizes are descaled by the page's `scale:`; `build` re-emits the atlas into `--out`, re-anchored, and `explain` writes nothing and poses through it — **§0.2**. On `explain` it is the flag that makes a **size-only** spec readable at all (`ingest --art none`), because posing resolves every attachment against an atlas; without it that pair is refused by name rather than thrown through ([#697](https://github.com/firejune/rigc/issues/697), §5.1) |
+| `--atlas-in` | `build` and `explain`: resolve every part against the **regions of a pre-packed `.atlas`** instead of against loose PNGs. Region geometry is read from the file and sizes are descaled by the page's `scale:`; `build` re-emits the atlas into `--out`, re-anchored, and `explain` writes nothing and poses through it — **§0.2**. On `explain` it is the flag that makes a **size-only** spec readable at all (`ingest --art none`), because posing resolves every attachment against an atlas; without it that pair is refused by name rather than thrown through (§5.1) |
 | `--images` | where the rig spec's `image` names resolve (overrides the rig's own `images` field, and is relative to your working directory). For `pose` it is the directory of **loose part PNGs to place** — every `.png` in it is a part, in name order. For `chainfit` it is only where each attachment's image name **resolves**: the candidate decides what the parts are, so extra PNGs are unused and a missing name is refused by name (§12.3) |
 | `--manifest` | a cut manifest. Only for a rig with **measured art** behind it; a foreign skeleton has none |
 | `--cut` | `build`, `explain` and `validate`: look up a named cut in `--cuts <cuts.json>`, **instead of** `--rig`/`--motion`/`--out` — the two spellings are one build stated two ways and are refused together. A `cuts.json` is `{ "<name>": { "rig": …, "motion": …, "out": …, "manifest"?: … } }`, every path in it relative to the table's own file, so the table lives with the project that owns the art |
@@ -202,19 +202,16 @@ unweighted meshes, packed atlases) — reach for it when you are shipping into
 *that* project, not to be thorough. A report always prints which profile ran and
 lists what that profile left out, on `PROF` lines.
 
-🆕 *Packed atlases* used to be in that list twice over: `--pack --profile
-spine-html` was **refused by name**, because `A06`'s coverage clause said "one
-part per page" flat and rigc's own pack could not satisfy it. Since
-[#266](https://github.com/firejune/rigc/issues/266) that clause is **one part per
-page OR a tiling page**, so the combination is an ordinary build — and it is the
-only one that puts the renderer's own rulebook over shared-page sampling. What a
+*Packed atlases* are in that list for what a page may hold, not for being packed:
+under `spine-html`, `A06`'s coverage clause is **one part per page OR a tiling
+page**, so `--pack --profile spine-html` is an ordinary build — and it is the only
+one that puts the renderer's own rulebook over shared-page sampling. What a
 *tiling* page has to satisfy under that profile is stated where the clause is,
-§5.2's `A06` row: no two regions on one page overlapping. Rotation is still
-refused, and that is a separate clause about rigc's packer never turning a region.
+§5.2's `A06` row: no two regions on one page overlapping. Rotation is refused, and
+that is a separate clause about rigc's packer never turning a region.
 
-⚠️ The other half of that sentence — every region wholly inside the page it names
-— left this profile in [#694](https://github.com/firejune/rigc/issues/694). It is
-**validity**, so no profile switches it off: a rectangle outside its page is
+⚠️ The other half of that clause — every region wholly inside the page it names —
+is **validity**, so no profile switches it off: a rectangle outside its page is
 broken for every consumer, while two regions over the same texels is something
 correct, editor-exported data does.
 
@@ -251,7 +248,7 @@ a gap:
 - **no rotation.** `rotate: 0` on every region, and it is a fact rather than a
   field: the runtime transposes `u2/v2` at 90 and not at 270, and
   `RegionAttachment.computeUVs` assigns a different corner order at 90, so a
-  rotated pack is one rigc's own `--atlas` substitution cannot read (issue #199).
+  rotated pack is one rigc's own `--atlas` substitution cannot read.
   Rotation buys page area; a page that runs out of room spills to a second page
   instead.
 - **no re-ordering of anything the skeleton says.** `skeleton.json` from a packed
@@ -310,7 +307,7 @@ drawing at its own size, which is what an attachment's size means.
 `scale: 0.5` holds texels half the size of the drawings it was packed from — the
 line says so, and an attachment's `width` is in world units, which the runtime
 reads straight out of the skeleton JSON with the atlas nowhere in the expression.
-So the scale has to be undone here or never (issue #267). But the packer wrote
+So the scale has to be undone here or never. But the packer wrote
 `round(drawing × scale)`, so a 373-texel region at `scale: 0.5` is consistent with
 a 745- and a 746-pixel drawing and the file does not say which: an imported size
 is right to within `0.5 / scale` source pixels, and the build report prints the
@@ -324,19 +321,17 @@ texel count beside it so both numbers are visible:
 measures the PNG. Reach for `--atlas-in` when the pack is what you were handed, or
 when drawing through the pack's own texels is the point.
 
-📐 **What you make beside the art stays at the art's size**
-([#762](https://github.com/firejune/rigc/issues/762)). A depth sheet or a soft
+📐 **What you make beside the art stays at the art's size.** A depth sheet or a soft
 mask is read in the drawing's pixels on a `scale:` page as on loose parts — each
 vertex's texel position over the stated scale — and a mesh fit's overshoot is
 printed in them, with the texel it was measured on named beside it. So are a
-`contour`'s `margin` and `tolerance`
-([#779](https://github.com/firejune/rigc/issues/779)): the trace runs on the
+`contour`'s `margin` and `tolerance`: the trace runs on the
 texels there are, and the two distances are applied on them as `value × scale`
 texels — the scale the header states, never a measured one (below). What stays
 in texels is only what is counted off them: a contour's hole count.
 
 🚨 **A page that declares a size it does not have is a different thing, and it is
-refused** ([#715](https://github.com/firejune/rigc/issues/715)). The common shape
+refused.** The common shape
 is a pack whose `4096x4096` pages ship as `2048x2048` PNGs with the atlas
 untouched — every region still stated in 4096-space — and that is **not** what a
 `scale:` line says. A runtime draws it anyway: `TextureAtlas` computes every
@@ -372,14 +367,14 @@ it hits instead of leaving it to be discovered:
   size the atlas declares, or repack.
 
 📐 **`explain` does not refuse such a page — it withholds what it would have
-measured off it** ([#750](https://github.com/firejune/rigc/issues/750)). It never
+measured off it.** It never
 gates, a runtime draws the page, and most of its report — bones, slots, timelines
 — reads no texel at all, so the pack still compiles and the report still prints.
-What it no longer prints is a figure taken at the coordinates the atlas states,
+What it does not print is a figure taken at the coordinates the atlas states,
 because on such a file those are another part of the picture: measured on a pack
 at half resolution, an authored mesh that covers 100.00% of its art and reaches
-16.00px past it printed **68.49%** and **76.24px**, and a `grid` whose depth sheet
-reads 10 of its 12 vertices on undrawn texels printed **12 of 12**. The page is
+16.00px past it would print **68.49%** and **76.24px**, and a `grid` whose depth sheet
+reads 10 of its 12 vertices on undrawn texels would print **12 of 12**. The page is
 named once where the report starts, with the ratio `A06` refuses it by, and every
 withheld figure says so where it would have stood:
 
@@ -402,12 +397,11 @@ on the **coarser** texels the page really has, so a figure that depends on the
 grid need not equal the one the pack the page was halved from reads — and a
 contour's outline is one of them, below.
 
-📐 **A fit's overshoot is stated in the drawing's pixels on every page**
-([#762](https://github.com/firejune/rigc/issues/762)). It is a distance, and on a
-page that declares a `scale:` it is taken on the page's texels — so it used to be
-printed in them, under the same `px`: one mesh over one drawing read 16.00px on
-the declared-size page, **8.00px** on its `scale: 0.5` restatement and **32.00px**
-on a `scale: 2` one. It is now the texel distance over the scale the atlas states,
+📐 **A fit's overshoot is stated in the drawing's pixels on every page.** It is a
+distance, and on a page that declares a `scale:` it is taken on the page's texels —
+counted in them, one mesh over one drawing reads 16.00px on the declared-size page,
+**8.00px** on its `scale: 0.5` restatement and **32.00px** on a `scale: 2` one. So
+it is printed as the texel distance over the scale the atlas states,
 which is the unit an attachment's `width` is in and the one you drew in, and the
 line says which grid it was taken on — a texel of a `scale: 0.5` page is 2.00px of
 the drawing, so that is the step the figure moves in:
@@ -426,14 +420,14 @@ texels are the drawing, and the line is the one it always was. A `contour`'s hol
 count is a count of those cells and says `texel(s)` on such a page.
 
 📐 **A `contour`'s `margin` and `tolerance` are the drawing's pixels on every
-page** ([#779](https://github.com/firejune/rigc/issues/779)). They are your
+page.** They are your
 statement, in the unit every other size in the spec is in, so on a `scale:` page
 the trace applies them as `margin × scale` and `tolerance × scale` texels, and
-`maxVertices` is judged on the outline that asks for. They used to be applied in
-texels unconverted, which asked each page a different question. Measured on
-`halvedMeshPacks`, one spec — `tolerance: 1.5`, `margin: 2`, `maxVertices: 48`:
+`maxVertices` is judged on the outline that asks for. Applied in texels
+unconverted, they would ask each page a different question. Measured on one pack
+at three scales, one spec — `tolerance: 1.5`, `margin: 2`, `maxVertices: 48`:
 
-| page | applied in texels (before) | applied as the drawing's pixels (now) |
+| page | applied in texels | applied as the drawing's pixels (what rigc does) |
 | --- | --- | --- |
 | declared size | 15 vertices | **15** vertices, the same mesh |
 | `scale: 2` | refused: `simplified to 66 vertices at tolerance 1.5, past the 48` | **15** vertices, the declared outline to 0.00px |
@@ -458,7 +452,7 @@ names the figure the spec states, the texels it was applied as and the scale:
 ```
 
 🚨 **A page that is not a PNG is refused by name, before anything is compiled
-against it** ([#732](https://github.com/firejune/rigc/issues/732)). rigc reads PNG
+against it.** rigc reads PNG
 and nothing else — the size `A06` judges, the alpha `A19` judges, the renderer and
 the region lift all decode PNG, and rigc links no decoder for any other format —
 and a file's name is not evidence: a production pack shipped WebP pages called
@@ -483,20 +477,16 @@ a page fails `A06` with the same sentence:
 measures it like any other. ⚠️ `A06` deliberately does not read the width and
 height a WebP header carries in a fixed field. Doing so would print a size that no
 reader in this tree can check — the parse would agree only with the forgery it was
-written against — about a page that is refused either way; and the variant that
-let a size-matching WebP page pass was measured building green under the default
-profile and writing a directory whose next `render` refused the page.
+written against — about a page that is refused either way; and a size-matching
+WebP page let through that way builds green under the default profile and writes
+a directory whose next `render` refuses the page.
 
 **What `--out` holds afterwards:** `skeleton.json` and a `skeleton.atlas` that is
 the pack, page paths pointing back at the pack's own PNGs — so `rigc validate
 <that directory>` reads it green with no flags, exactly as it reads a loose
 build's. Add `--copy-images` and the pack's page PNGs are copied in beside the
 skeleton and the page names become their basenames, which is the same directory
-with nothing outside it left to resolve. ⚠️ Until
-[#693](https://github.com/firejune/rigc/issues/693) that flag rebuilt the atlas
-from the parts the rig declared instead of from the pack, and a rebuild through
-`ingest --art none` declares none: the file written was **zero bytes**, on a build
-that printed `PASS` for all four atlas assertions.
+with nothing outside it left to resolve.
 
 The emitted `skeleton.atlas` **is** the imported one, verbatim except for its page
 name lines, which are paths and have to be re-anchored to `--out`. Fields rigc
@@ -505,17 +495,15 @@ because the text passes through by line; regions the rig does not use stay in th
 file, because a real pack is shared between cuts and an importer that quietly
 dropped half of one would make `--out` disagree with the pack it was built from.
 
-🔸 **The one thing not passed through is the pack's blank lines**
-([#803](https://github.com/firejune/rigc/issues/803)). They are written in the
-shape rigc writes its own packs in: none before the first page, exactly one between
-two page blocks, one trailing newline. Every non-blank line keeps its bytes and its
-order, so a pack already in that shape — every editor export in the example corpus,
-and every pack `--pack` writes — is emitted byte for byte as before. What this
-changes is a pack from a 3.8-era packer, which begins with a blank line: the
-runtime reads a run of blank lines before the first page as nothing, so the pack
-loads, and until #803 `build` re-emitted the blank and refused its own emission as
-`A07_ATLAS_TEXT_SHAPE: line 1: consecutive blank lines`. A run of blank lines
-between two page blocks reads as one to the runtime, and is written as one.
+🔸 **The one thing not passed through is the pack's blank lines.** They are
+written in the shape rigc writes its own packs in: none before the first page,
+exactly one between two page blocks, one trailing newline. Every non-blank line
+keeps its bytes and its order, so a pack already in that shape — every editor
+export in the example corpus, and every pack `--pack` writes — is emitted byte for
+byte. A pack from a 3.8-era packer begins with a blank line: the runtime reads a
+run of blank lines before the first page as nothing, so the pack loads, and
+`build` writes it without the blank. A run of blank lines between two page blocks
+reads as one to the runtime, and is written as one.
 
 Five things are refused rather than warned about, because each of them otherwise
 **loads clean and draws wrong** — or, the last, cannot be read back at all:
@@ -525,17 +513,17 @@ Five things are refused rather than warned about, because each of them otherwise
 | a region name the atlas does not have | `AtlasAttachmentLoader` returns null and the part silently does not draw. The refusal lists the near misses — the usual cause is one character |
 | a size the spec disagrees with | the same silence `A06` exists for, one link earlier: a quad sized against a region of another size collapses |
 | a page the atlas names and the disk lacks | nothing to sample; caught on the way in, so the message names the atlas rather than the artifact rigc wrote from it |
-| a rectangle that runs off its page | `x + width` past the page width makes `u2 > 1`, which samples whatever the wrap mode does. The gate names the same rectangle, under every profile, for a pack that reaches it without passing through here — `A06`, §5.2 ([#694](https://github.com/firejune/rigc/issues/694)) |
-| a page file that is not a PNG | nothing in rigc can read it — not the gate, not `render`, not a mesh generator — so a green build over it would certify pixels nobody opened. Named by what its first bytes are, every such page of the pack in one sentence; the gate says the same for a directory that reaches it another way — `A06`, §5.2 ([#732](https://github.com/firejune/rigc/issues/732)) |
+| a rectangle that runs off its page | `x + width` past the page width makes `u2 > 1`, which samples whatever the wrap mode does. The gate names the same rectangle, under every profile, for a pack that reaches it without passing through here — `A06`, §5.2 |
+| a page file that is not a PNG | nothing in rigc can read it — not the gate, not `render`, not a mesh generator — so a green build over it would certify pixels nobody opened. Named by what its first bytes are, every such page of the pack in one sentence; the gate says the same for a directory that reaches it another way — `A06`, §5.2 |
 
 One limit, stated rather than discovered:
 
 - an **optional state** (a manifest `states:` entry) whose region is not in the
-  pack is a `DROP`, not a refusal — the same documented absence a missing PNG has
-  always been, and the line names the atlas rather than a file nobody opened.
+  pack is a `DROP`, not a refusal — the same documented absence a missing PNG is,
+  and the line names the atlas rather than a file nobody opened.
 
-⭐ **The missing PNG it is the same rule as, spelled out**, because it was left
-implicit here and the two halves are read together. A `states:` entry whose PNG is
+⭐ **The missing PNG it is the same rule as, spelled out**, because the two halves
+are read together. A `states:` entry whose PNG is
 not on disk is a `DROP` too, and the line names the file rather than the pack:
 
 ```bash
@@ -552,11 +540,9 @@ with that part missing, at exit 0 and a green gate. Restore the art, or fix the
 path the manifest states.
 
 🔑 **A refused build prints its `DROP` lines too**, under the refusal on stderr,
-and did not before [#671](https://github.com/firejune/rigc/issues/671): they were
-reported from the compile result and a refusal returns none, so the one output
-naming the file was missing from exactly the run that failed over it.
+so the one output naming the file is there on exactly the run that failed over it.
 
-A **turned** region is not one of them, and used to be (issue #570). A pack made
+A **turned** region is not one of them. A pack made
 by somebody else routinely rotates a region to save space — `rotate: 90`,
 `rotate: 180`, `rotate: 270`, or the format's older `rotate: true` — and rigc
 reads all of them: anything that measures a part's pixels sees the same grid it
@@ -582,15 +568,13 @@ means for the numbers beside it, and the pack states none of this:
 
 Each direction there is **measured** rather than reasoned about: it comes off
 `MeshAttachment.computeUVs` in the linked runtime, the one routine there that
-says where a region's texels are for all four values, and the selftest derives
-the words in that list from the same routine instead of reading them. ⚠️ Do not
+says where a region's texels are for all four values. ⚠️ Do not
 take the turn from `TextureAtlas`'s own `u2`/`v2` — those transpose at a quarter
 turn one way and not at the other, so one of the two pairs describes a rectangle
-the page does not have ([#579](https://github.com/firejune/rigc/issues/579)).
+the page does not have.
 
-`build` now prints the page rectangle on the line for a turned region, so the
-report carries the rectangle to cut instead of leaving it to be derived
-([#718](https://github.com/firejune/rigc/issues/718)):
+`build` prints the page rectangle on the line for a turned region, so the
+report carries the rectangle to cut instead of leaving it to be derived:
 
 ```bash
 #   ..      pendulum   105x139  <- ../export/atlas.png @ 710,16 rotate 90, occupies 139x105
@@ -599,7 +583,7 @@ report carries the rectangle to cut instead of leaving it to be derived
 ⚠️ Two limits here are real and neither is about rotation:
 
 - `--atlas-in` cannot recover what a `scale:` quantised away (above), turned or not;
-- the **renderer** profile still refuses a turned region outright
+- the **renderer** profile refuses a turned region outright
   (`A06`, `--profile spine-html`), because that profile is about artifacts rigc
   itself emits and it never packs one turned. Reading a foreign pack and gating
   one under somebody else's renderer policy are different questions.
@@ -648,7 +632,7 @@ repository builds on every run.
 | `--art loose` (default) | name an `image` per attachment — `<path or placeholder>.png` — so the rebuild resolves loose PNGs and rigc measures them |
 | `--art none` | state `width`/`height` only, so the rebuild is `build --atlas-in <pack.atlas>` and every part resolves out of the pack |
 | `--images <dir>` | **write** the rig spec's own `images` directory, spelled relative to `--out`, so the rebuild is a plain `build --rig … --motion … --out …`. Without it the field is left out and every `image` resolves against `--out` itself, which holds the specs and no art — so every rebuild has to repeat `build --images <dir>`. Refused together with `--art none`, which writes no `image` for it to be the base of |
-| `--stage x,y,w,h` | a setup bounding box to **add** to a skeleton that declares none — without it the absence is carried as `"width": null, "height": null` ([#714](https://github.com/firejune/rigc/issues/714)). An editor export *may* be such a file; every export under `examples/` carries a box and `ingest` reads it straight through — so passing the flag at one of them is **refused**, naming both boxes, rather than silently doing nothing ([#626](https://github.com/firejune/rigc/issues/626)) |
+| `--stage x,y,w,h` | a setup bounding box to **add** to a skeleton that declares none — without it the absence is carried as `"width": null, "height": null`. An editor export *may* be such a file; every export under `examples/` carries a box and `ingest` reads it straight through — so passing the flag at one of them is **refused**, naming both boxes, rather than silently doing nothing |
 | `--name <n>` | the rig spec's `name`, which the motion spec's `archetype` must equal (default: the file's basename) |
 
 ⚠️ **`ingest --images` and `build --images` point opposite ways.** `build --images`
@@ -663,8 +647,8 @@ where the parts are in one convention.
 one — posing the rig gives the *animated* extent, which is a different number from the
 editor's setup box. So a file that declares none is **carried as declaring none**: the
 spec states `"width": null, "height": null` (§3.1), the rebuild emits no box, and
-nothing is recorded, because the rebuild is the file that was read
-([#714](https://github.com/firejune/rigc/issues/714)). `--stage x,y,w,h` *adds* a box —
+nothing is recorded, because the rebuild is the file that was read.
+`--stage x,y,w,h` *adds* a box —
 supply it from the project the file came from, or from the editor's own canvas — and
 is recorded as a `NO_STAGE` judgement. A header stating **half** a stage (an origin
 with no extent) is a `NO_STAGE` blocker: the spec holds a stage as four fields or none.
@@ -672,27 +656,20 @@ with no extent) is a `NO_STAGE` blocker: the spec holds a stage as four fields o
 ⛔ **The flag is refused beside a box the file states.** Two sources for one value, and
 the file is the one that was measured — so `ingest` names both boxes and stops rather
 than writing one of them and saying nothing. Drop the flag, or correct `skeleton` in the
-source if its box is wrong ([#626](https://github.com/firejune/rigc/issues/626)). What
-it does **not** do is refuse an *omitted origin*: inside a declared extent an omitted
-`x`/`y` is `0` — the reading `build` emits and `diff` compares
-([#620](https://github.com/firejune/rigc/issues/620)) — so the written spec states it
-and a `LOSS HEADER_ORIGIN` line says the source omitted it and that the rebuild will
-spell it ([#622](https://github.com/firejune/rigc/issues/622)).
-
-⚠️ **This said an editor export "never" carries one until
-[#594](https://github.com/firejune/rigc/issues/594) measured the corpus.** All twelve
-exports under `examples/` declare `x`, `y`, `width` and `height`, `ingest` takes the
-early return on every one of them, and not one needs the flag. What an editor export
-*may* do is carry none: a rigc build that declares no stage
-([#578](https://github.com/firejune/rigc/issues/578)) came back from a Spine 4.3.26
-round trip with a header of `hash`, `spine`, `images`, `audio` and **no box at all** —
-the editor preserves the absence rather than inventing a stage
-([#616](https://github.com/firejune/rigc/issues/616)). So `--stage` is for a file that
-really has none, and this repository's corpus holds no example of one; a production
-corpus measured for [#714](https://github.com/firejune/rigc/issues/714) holds 48 of 48. It is still the
-value that costs least to get wrong: `diff` reports the box as `stage_present` and
-`stage_box` ([#578](https://github.com/firejune/rigc/issues/578)) and both are
-`(reported)`, so nothing on the ladder consults them.
+source if its box is wrong. What it does **not** do is refuse an *omitted origin*:
+inside a declared extent an omitted `x`/`y` is `0` — the reading `build` emits and
+`diff` compares — so the written spec states it and a `LOSS HEADER_ORIGIN` line says
+the source omitted it and that the rebuild will spell it.
+
+⚠️ **All twelve exports under `examples/` declare `x`, `y`, `width` and `height`**,
+`ingest` reads each box straight through, and not one needs the flag. What an
+editor export *may* do is carry none: a rigc build that declares no stage came back
+from a Spine 4.3.26 round trip with a header of `hash`, `spine`, `images`, `audio`
+and **no box at all** — the editor preserves the absence rather than inventing a
+stage. So `--stage` is for a file that really has none; the example corpus holds no
+such file, and production exports do — 48 of 48 measured. It is the value that
+costs least to get wrong: `diff` reports the box as `stage_present` and
+`stage_box` and both are `(reported)`, so nothing on the ladder consults them.
 
 ⚠️ **The duration is a convention, and it is recorded as one.** Skeleton JSON has no
 duration field. The largest key time is the only derivable answer and it is what a
@@ -709,24 +686,26 @@ the first:
 | --- | --- |
 | `BLOCK` | the spec format cannot say it, so the rebuild will **not** be the file that was read — `point`, a `sequence` block the parser would read as some other series, an unknown field on a bone, slot or constraint, a timeline family the motion spec has no track for. The command exits non-zero **and still writes both specs**, because a spec plus a list of what is missing from it beats no spec |
 | `JUDGE` | the skeleton cannot answer and somebody has to: the stage, and each animation's duration |
-| `LOSS` | the skeleton's spelling and rigc's differ, on purpose, and the line says how: `HEADER_BOOKKEEPING` for a field the spec has no home for, `HEADER_REDERIVED` for the version string, `HEADER_ORIGIN` for an origin the source left to the format and the rebuild writes out (#622) |
+| `LOSS` | the skeleton's spelling and rigc's differ, on purpose, and the line says how: `HEADER_BOOKKEEPING` for a field the spec has no home for, `HEADER_REDERIVED` for the version string, `HEADER_ORIGIN` for an origin the source left to the format and the rebuild writes out |
 
 ⛔ **It reads one generation of the format, and a file from another one ends loud.**
 Spine data is locked to the generation that exported it and a mismatch does not
 throw: 4.3 takes constraints from the top-level `constraints` array alone, so a
 4.0–4.2 file's `ik`/`transform`/`path`/`physics` arrays load as nothing at all — 1,302
 shipped skeletons parsed on a 4.3 runtime and loaded 0 of 8,672 constraints
-([#706](https://github.com/firejune/rigc/issues/706) row 1). So `ingest` reads
+(GENERATIONS.md, row 1). So `ingest` reads
 `skeleton.spine` before it reads a field of the file. A file from another generation is
 a `BLOCK GENERATION_UNSUPPORTED` naming the generation, the string it was read from,
 and what a 4.3 reader loses **on that file**: the constraints parked in those arrays
-counted by kind, the bones carrying 4.2's `transform` where 4.3 spells `inherit`, and
+counted by kind, the bones carrying 4.0/4.1's `transform` where 4.3 spells `inherit`, and
 the physics constraints omitting `inertia`/`damping`, whose default is not the same
 number in the two. A label naming no generation rigc knows — or a header stating none —
 is a `BLOCK GENERATION_UNKNOWN`, never rounded to the nearest: a catalog that rounded
 handed 19 skeletons labelled `3.8.99` a 4.2 runtime and every one of them posed as NaN
-(row 7). Reading a file with *that generation's own* defaults is #706's item 2 and is
-not in this tool — re-export as 4.3, or transcribe by hand ([INGEST.md](INGEST.md) §2).
+(row 7). Reading a file with *that generation's own* defaults is not in this tool —
+re-export as 4.3, or transcribe by hand ([INGEST.md](INGEST.md) §2).
+[GENERATIONS.md](https://github.com/firejune/rigc/blob/main/docs/GENERATIONS.md) is
+the whole policy, and the editor migration it names.
 
 📝 **Do not delete the `note`.** Both written specs carry one saying the file is
 decompiled and naming the skeleton it came from. A decompiled spec is
@@ -770,12 +749,12 @@ bun cli.ts pose     --images path/to/parts --frame poseA.png [--out pose.json]
   `ingest --art none` states sizes and names no image. So the size-only pair
   `build --atlas-in` gates green is readable here through the same flag, and
   without it the pair is refused by name at exit 2 rather than posed
-  ([#697](https://github.com/firejune/rigc/issues/697), §5.1). ⚠️ `--profile`,
+  (§5.1). ⚠️ `--profile`,
   `--pack`, `--page-size`, `--padding` and `--copy-images` are `build`'s and are
   not here: four of them decide what is *written*, and this command writes nothing.
 
   📐 **What it will not measure: the texels of a page that is not its declared
-  size** ([#750](https://github.com/firejune/rigc/issues/750)). Under
+  size.** Under
   `--atlas-in`, a page whose PNG is not the `size:` its atlas states is named once
   at the top of the report, and the figures that would have been read off it — an
   authored mesh's `covers …% of the art, reaching …px past it`, a depth sheet's
@@ -785,7 +764,7 @@ bun cli.ts pose     --images path/to/parts --frame poseA.png [--out pose.json]
   and the repair: §0.2. On a page that **does** declare a `scale:`, the overshoot
   in that line is the drawing's pixels and the line names the texel it was taken
   on (`… measured on the page's texels at scale: 0.5 — a texel is 2.00px of the
-  drawing`, [#762](https://github.com/firejune/rigc/issues/762)).
+  drawing`).
 - **`diff`** compares two skeletons and reports **a ratio per measure** in six
   sections (bones, slots, attachments, constraints, animations, events). It
   deliberately does not combine them into a score: a rig with the right skeleton
@@ -951,24 +930,12 @@ one A09 does compare.
 **R1 — A field is emitted when you declare it, and left out where the parser would
 read the same value without it.** Omit a field and Spine's default stands; write it
 and it reaches the file — unless what you wrote **is** that default, in which case
-the emitter leaves it out, the way the editor's own exporter does (issue
-[#716](https://github.com/firejune/rigc/issues/716)). Writing `x: 0` is still
+the emitter leaves it out, the way the editor's own exporter does. Writing `x: 0` is still
 legitimate, and your spec still says it: the spec is the record of what you wrote,
 and the file is what the runtime reads. The two cannot disagree about a value,
 because a key is left out only where the 4.3 parser loads the same `SkeletonData`
 without it — exact equality with the float the file would hold, so `x: 1e-45` is
-written — and the selftest loads every build both ways to hold that (§10.6c).
-
-⚠️ This rule said *"not 'when it differs from the default'"* until #716, on two
-grounds: that a rig may need to say `x: 0` out loud, and that deciding emission from
-the value would make the file depend on arithmetic. Neither survived being measured.
-What reads the file is the 4.3 parser, which reads the absent key as the same number,
-and the editor, whose own export leaves the same key out — so there is nobody to say
-it out loud *to*; and the decision is an exact comparison with the parser's fallback,
-which is not arithmetic in any sense a reader has to redo. What the
-old rule cost was concrete: a rebuild of an editor export restated **2,338** keys the
-export leaves to the parser, so `ingest → build` could never give an editor's file
-back.
+written (§10.6c).
 
 **R2 — The compiler never invents a value.** No defaults guessed from the art, no
 re-measured plates, no reasonable fallbacks. A missing number is a `CompileError`
@@ -999,8 +966,7 @@ two files put two regions in it and each attachment draws its own (§3.4.2), whi
 two attachments naming the same file share the one region that file made. What
 cannot be reconciled is two *different* files whose basenames collide — only one of
 them can be region `patch` — so rigc refuses the build and names both paths rather
-than letting one of them silently draw the other's pixels
-([#555](https://github.com/firejune/rigc/issues/555)).
+than letting one of them silently draw the other's pixels.
 
 **R6 — A key carries `ease` or `curve`, never both.** A named easing says "this
 shape, wherever it is used" and is the recommended path. `curve` is the escape
@@ -1032,19 +998,16 @@ reads best; the emit keys them the way the Spine editor does. This is the one pl
 reorders anything you wrote, and it is not cosmetic: a `slider`'s animation is a
 **name** in JSON and an **ordinal** in the format's binary half, so an editor that
 re-sorts the object repoints every slider whose animation moved index — silently,
-in a file that still parses and still gates green (§3.5.2,
-[#535](https://github.com/firejune/rigc/issues/535)). Nothing else moves: each
+in a file that still parses and still gates green (§3.5.2). Nothing else moves: each
 animation's own body is byte-identical either way, and every other collection is
 emitted in the order you gave it.
 
 ⚠️ **What that comparator is, measured rather than inferred.** Five name lists
 went through a licensed 4.3.26 editor as JSON and came back as JSON, and the ten
 answers are in the repository as
-`fixtures/editor-order/probe{1..5}.{in,out}.json`
-([#728](https://github.com/firejune/rigc/issues/728)). Every row below is a clause
+`fixtures/editor-order/probe{1..5}.{in,out}.json`. Every row below is a clause
 of the rule with the pair from those files that shows it — nothing here is a
-guess, and the selftest re-derives each row from the files rather than from this
-page:
+guess:
 
 | The editor | Shown by |
 | --- | --- |
@@ -1059,14 +1022,13 @@ page:
 🔸 **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
+production skin's slot keys (§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
+⭐ **A tie is not an ambiguity.** 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
 order** and the editor keeps it. Nothing moves index, so there is nothing to
 refuse: `Turn` beside `turn`, `turn01` beside `turn1`, `1turn` beside `turn`,
@@ -1086,30 +1048,18 @@ So what is left refused is short, and each row is a pair two readings of the
 numbered series that crosses 9 → 10 is keyed **1, 2, … 9, 10, 11, 12**, which is
 what the editor does with it — and is not what a codepoint sort does.
 
-✅ **This rule was a quantifier over comparators until #728, and that is what
-changed.** rigc keyed `animations` codepoint-ascending until
-[#543](https://github.com/firejune/rigc/issues/543) and then emitted a member of
-the "natural, case-insensitive" family, refusing every pair the family could
-disagree about. Both refusals were sound and both over-refused by construction,
-because a quantifier stands in for a measurement: a name with a capital, an
-accent, a space or a folder in it was refused rather than emitted in the order the
-editor returns. Measuring the comparator moves no byte on any set the old rule
-accepted; it stops refusing the ones it did.
-
 **R11 — The `skins` array is written with `default` first and the rest in exactly
 the order R10 describes.** A skin is a **name** in the JSON half of the format and
 an **ordinal** in the binary half — `skins[readInt()]` for an attachment timeline,
 `skins[skinIndex]` for a linked mesh — so an editor that writes the array in
 another order repoints every such reference, silently, in a file that still
 parses. Measured: a rig built `default, zulu, mike, alpha` exported
-`default, alpha, mike, zulu`
-([#541](https://github.com/firejune/rigc/issues/541)).
+`default, alpha, mike, zulu`.
 
 ⚠️ **It is one comparator, and that is measured too.** Two of the five round
 trips carried one name list as **both** collections and both came back in one
-order, which is what retired the wider skin refusal #541 shipped: until #728,
-`Zulu` beside `mike` and `mike10` beside `mike2` built as animation names and were
-refused as skin names. Both build now. `default` is pinned rather than sorted, on
+order, so `Zulu` beside `mike` and `mike10` beside `mike2` build as skin names
+exactly as they do as animation names. `default` is pinned rather than sorted, on
 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.
@@ -1118,16 +1068,14 @@ sorts like one.
 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.
+which is the shape the editor itself exports (§3.4.2).
 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
+because the Spine editor has no representation for it in either spelling (measured
+on 4.3.26 — named, the export re-keys it and the default skin draws
 nothing; unnamed, the import is refused). Put the shared entry in a named skin —
 `base` — and every filler is a named skin. A placeholder only one skin fills is
-emitted exactly as before, in the default skin or anywhere else.
+emitted as written, in the default skin or anywhere else.
 
 ---
 
@@ -1141,8 +1089,7 @@ payloads in this guide are written to illustrate a field, never copied out of a
 reference export — an example lifted from one would be handing an authoring agent an
 answer to the rung it is standing on, which is the rule §10.6 states and the honesty
 rule in [LADDER.md](https://github.com/firejune/rigc/blob/main/docs/LADDER.md) turns on. If a snippet here matches a reference file,
-that is a defect in this guide: report it. (It has happened — 2026-08-23; the incident
-is recorded in `bench/runs/README.md`, *What a run may read*.)
+that is a defect in this guide: report it.
 
 ### 3.1 `skeleton` — the header
 
@@ -1152,53 +1099,49 @@ is recorded in `bench/runs/README.md`, *What a run may read*.)
 | `width`, `height` | setup-pose bounding box size, **or both `null` for "this skeleton declares no stage"** | falls back to the manifest's crop; **with neither the number nor the `null`, the compile fails** |
 | `fps` | nonessential editor hint | `SkeletonData.fps` stays 30 |
 | `referenceScale` | 4.2+ physics/scale reference | parser default 100 |
-| `images` | where the editor's import looks for the part PNGs, as a path from the skeleton file | **written for you**: under `--copy-images` the `--out` directory itself, spelled `../<its basename>/` (a literal `./` is dropped by the editor on import; a named directory is kept and every part is found — measured on 4.3.23); otherwise the relative path from `--out` to the one directory the spec names every part PNG in (the rig's images directory, or the manifest's plates). A declared value is carried through verbatim — and overridden by `--copy-images`, which moved the parts. Parts spread over several directories have no single true path, so nothing is written (issue #370) |
-| `audio` | nonessential: where the editor looks for the skeleton's audio files, as a path from the skeleton file — a string, or `null` for none | **not written unless you state it.** rigc has no audio to point at, so this is a value a spec states or does not; stated, it is carried verbatim, `null` included, because `null` is what an editor export writes when no audio folder is set (all twelve under `examples/` do) and `ingest` carries it from there ([#716](https://github.com/firejune/rigc/issues/716)). Anything but a string or `null` is a compile error naming the value |
+| `images` | where the editor's import looks for the part PNGs, as a path from the skeleton file | **written for you**: under `--copy-images` the `--out` directory itself, spelled `../<its basename>/` (a literal `./` is dropped by the editor on import; a named directory is kept and every part is found — measured on 4.3.23); otherwise the relative path from `--out` to the one directory the spec names every part PNG in (the rig's images directory, or the manifest's plates). A declared value is carried through verbatim — and overridden by `--copy-images`, which moved the parts. Parts spread over several directories have no single true path, so nothing is written |
+| `audio` | nonessential: where the editor looks for the skeleton's audio files, as a path from the skeleton file — a string, or `null` for none | **not written unless you state it.** rigc has no audio to point at, so this is a value a spec states or does not; stated, it is carried verbatim, `null` included, because `null` is what an editor export writes when no audio folder is set (all twelve under `examples/` do) and `ingest` carries it from there. Anything but a string or `null` is a compile error naming the value |
 
 `spine` and `hash` are not yours to write: rigc emits its own version label
 (`A16` re-checks it is on the 4.3 line) and inventing a hash would claim an export
 this file did not come from. The editor's import then warns `Data version 4.3.13
 does not match Spine version 4.3.23. The Spine version should match the version
 that exported the data file.` and imports anyway — the label is the runtime rigc
-links, not the editor that will open the file, and the warning is harmless
-(issue #370).
+links, not the editor that will open the file, and the warning is harmless.
 
 `width`/`height` are what `A14` and `A19` measure against, so a guessed stage is a
 gate measuring against a number nobody wrote down.
 
 ⭐ **A skeleton may declare no stage, and saying so is not the same as saying
-nothing** (issue #578). Write the pair as `null`:
+nothing.** Write the pair as `null`:
 
 ```json
 "skeleton": { "width": null, "height": null }
 ```
 
 and the emitted header carries **none** of `x`/`y`/`width`/`height` — which is
-what an export of a skeleton whose stage was never set looks like, and the shape a
-transcriber of one now has something to write. `null` is this spec's spelling for
-a stated absence wherever it has one (`slots[].attachment` is `null` for "show
-nothing"), so nothing new is introduced here but a third value of a field that
-already existed.
+what an export of a skeleton whose stage was never set looks like. `null` is this
+spec's spelling for a stated absence wherever it has one (`slots[].attachment` is
+`null` for "show nothing").
 
 Three readings stay apart, and the middle one is the point of the other two:
 
 | What the spec says | What happens |
 | --- | --- |
-| a number for each | the stage, as before; a manifest `crop` is the fallback |
+| a number for each | the stage; a manifest `crop` is the fallback |
 | `"width": null, "height": null` | builds, and emits a header with no stage at all — and this **beats** a manifest's `crop`, because a rig spec is where a claim about the skeleton is made |
-| neither | **refused**, exactly as before: `no stage size: …` |
+| neither | **refused**: `no stage size: …` |
 | one `null`, one number | refused — a stage has both extents or neither, and which half was meant is not derivable |
 | the pair `null` **and** an `x` or `y` | refused — an origin for a box that is not there |
 
-What each tool does without one — every reader of the stage in the tree, measured
-for [#714](https://github.com/firejune/rigc/issues/714), and not one of them puts a
-number where the box would be:
+What each tool does without one — not one of them puts a number where the box
+would be:
 
 | Reader | With a stage | Without one |
 | --- | --- | --- |
 | `build` | emits `x`/`y`/`width`/`height` | emits none of them |
 | `A14_NO_FULL_FRAME_MESH` | fails a mesh as big as the stage | **SKIP**, by name |
-| `A19_OVERLAY_PNGS_HAVE_ALPHA` | exempts the base plate a cut manifest names — the part whose window is the crop — and, on a build that names none, the one image that covers the stage | a manifest build exempts the plate it names, exactly as with one ([#770](https://github.com/firejune/rigc/issues/770)). A rig-spec build names no base plate, so an opaque part is refused with *"this skeleton declares no stage size to measure one against, and the build names no base plate"* and the two ways to decide it: a `skeleton` stage the plate covers, or *"build from a cut manifest, whose base plate is the part whose window is the crop"* |
+| `A19_OVERLAY_PNGS_HAVE_ALPHA` | exempts the base plate a cut manifest names — the part whose window is the crop — and, on a build that names none, the one image that covers the stage | a manifest build exempts the plate it names, exactly as with one. A rig-spec build names no base plate, so an opaque part is refused with *"this skeleton declares no stage size to measure one against, and the build names no base plate"* and the two ways to decide it: a `skeleton` stage the plate covers, or *"build from a cut manifest, whose base plate is the part whose window is the crop"* |
 | `diff` | `stage_present` and `stage_box` | `stage_present` 1/1 when neither side declares one (agreement), `stage_box` 0/0 |
 | `explain` | `stage  W x H` | `stage  none declared` |
 | `render` | frames the posed extent of every animation | the same frames, plus a line saying the viewport is the posed extent and no stage |
@@ -1210,7 +1153,7 @@ number where the box would be:
 ⚠️ A stage-less skeleton is **unmeasured, not certified**: `A14_NO_FULL_FRAME_MESH`
 reports **SKIP** on one, because there is no full frame for a mesh to span. And
 `rigc diff` reports it — `skeleton.stage_present` and `skeleton.stage_box`, in the
-header block at the top of the report — so a stage somebody invented now reads
+header block at the top of the report — so a stage somebody invented reads
 below 1.000 against a source that has none.
 
 ⭐ **A stage at `0,0` is not a stage-less one, and an editor export spells it by
@@ -1242,7 +1185,7 @@ it would simply be a second root.
 | `rotation` | degrees, counter-clockwise, y **up** | `0` |
 | `scaleX`, `scaleY` | | `1` |
 | `shearX`, `shearY` | | `0` |
-| `inherit` | `normal` · `onlyTranslation` · `noRotationOrReflection` · `noScale` · `noScaleOrReflection`. The first letter's case is free (`NoScale` loads) and the rest is exact: the runtime folds that one letter and nothing else, so `NOSCALE` is refused — it used to compile and load as **no mode at all** ([#733](https://github.com/firejune/rigc/issues/733)). An animation can change it over time: the `inherit` track (§4.4) | `normal` |
+| `inherit` | `normal` · `onlyTranslation` · `noRotationOrReflection` · `noScale` · `noScaleOrReflection`. The first letter's case is free (`NoScale` loads) and the rest is exact: the runtime folds that one letter and nothing else, so `NOSCALE` is refused — the runtime would load it as **no mode at all**. An animation can change it over time: the `inherit` track (§4.4) | `normal` |
 | `skin` | `BoneData.skinRequired` | `false` |
 | `color` | `rrggbbaa`, editor affordance | — |
 | `icon` | the editor's icon for this bone, e.g. `arrowsB`; editor affordance, no rendering effect. Copied through verbatim — no assertion checks the name, because the icon vocabulary is the editor's and an unknown one is not an error | — |
@@ -1275,18 +1218,13 @@ Declaring a slot no cut fills is therefore normal — it fixes where that slot s
 whether or not this cut has art for it — and transcribing a foreign skeleton that
 carries an empty slot reproduces it exactly.
 
-⚠️ **This changed with issue #575.** Such a slot used to be *dropped*, with no message, and
-the gate allowed the emitted array to be any subsequence of the rig's. What it cost
-is the index: every slot below the dropped one moved up one place, which is what a
-`drawOrder` key's offsets are counted against and what an index-keyed consumer
-splits on. Two production exports declaring 53 and 61 slots built green at 51 and 57
-and read 0.962 and 0.934 under `diff` against the file they were transcribed from.
-If you have a rig that leaned on the drop, the emitted array simply grows; nothing
-else about it moves.
+⚠️ **Keeping the empty slot is what keeps the index.** A `drawOrder` key's offsets
+are counted against the slots array, and so is an index-keyed consumer, so a slot
+dropped from it would move every slot below it up one place.
 
 🚫 **Naming an attachment on a slot nothing fills is refused by name**: `the setup
 pose shows attachment "x" on slot "y", which no skin and no manifest part fills`.
-That is the half-finished wiring-up the old silence hid — the slot is emitted empty
+That is half-finished wiring-up — the slot is emitted empty
 and the name resolves to nothing, so either give the slot an attachment or state the
 setup pose as `null`.
 
@@ -1299,10 +1237,10 @@ called `default`.)
 
 A skin can also say which bones and constraints it **switches on**, and that needs
 one more level, so a skin entry has a second spelling — see §3.4.1. The short one
-above is unchanged and is what almost every rig wants.
+above is what almost every rig wants.
 
 🔸 **`default` is a name, not a requirement, and rigc writes one exactly when the
-spec has one** ([#801](https://github.com/firejune/rigc/issues/801)). A rig may put
+spec has one.** A rig may put
 every attachment in named skins and declare no `default` at all, which is what an
 editor export of a multi-skin character gives back: the 4.3.26 editor took a build
 declaring `skins: [default, alt, base]` with `default` **empty** and exported
@@ -1311,9 +1249,7 @@ key — `"default": {}` included, which is written back empty — or when a mani
 part files its states under it, and **none otherwise**. spine-core loads both
 spellings alike (`SkeletonData.defaultSkin` is null or an empty skin, and neither
 fills a slot), and the binary format has no way to hold an empty default skin at
-all. Until #801 rigc wrote an empty `default` into every build whether the spec
-had one or not, so a rebuild of such an export read `attachments.skins 1/2`
-against it. Two things change for a rig with no default skin, and both are
+all. Two things differ for a rig with no default skin, and both are
 named: a linked mesh that states no `skin` looks for its source in the default
 skin and is refused (the error table in §5.1), and `rigc explain` says the
 skeleton declares no default skin above its slot list instead of printing
@@ -1329,11 +1265,7 @@ with **no pages**, and rigc writes `skeleton.atlas` as an **empty file** (zero
 bytes). Four rules then report SKIP by name rather than a pass, because a page is
 their whole subject: `A07_ATLAS_TEXT_SHAPE`, `A06_ATLAS_PAGE_SIZE_MATCHES_PNG`,
 `A17_ATLAS_PAGE_FILES_EXIST` and — under `spine-html` —
-`A19_OVERLAY_PNGS_HAVE_ALPHA` and `A27_REGION_NAME_MATCHES_PAGE_FILENAME`. Until
-[#608](https://github.com/firejune/rigc/issues/608) the same compile wrote one
-newline instead and `A07` refused it with two findings, so a hit-box skeleton — a
-correct rig, whose geometry `A33_VERTEX_ATTACHMENT_GEOMETRY` passes — could not be
-built at all.
+`A19_OVERLAY_PNGS_HAVE_ALPHA` and `A27_REGION_NAME_MATCHES_PAGE_FILENAME`.
 
 ⚠️ **This is not the case where an attachment WANTS a region.** A region or mesh
 attachment that states `width`/`height` and names no `image` still resolves a
@@ -1349,8 +1281,7 @@ there is nothing to draw`. That is the honest division — the rig is valid Spin
 data, and there is no picture of it. `rigc check` says the same thing one step
 on, since it has no frames to compare; `tools/editor_roundtrip.ts` quotes both
 renderers and reports its step 5 as a **SKIP** naming that, and the round trip
-comes back green on the strength of `validate` and `diff`
-([#621](https://github.com/firejune/rigc/issues/621)). A skin only **one** side
+comes back green on the strength of `validate` and `diff`. A skin only **one** side
 can draw is the other case entirely, and stays red.
 
 **Region attachment** ([Spine: region attachments](http://esotericsoftware.com/spine-regions)),
@@ -1381,15 +1312,10 @@ region does: stated wins, otherwise the PNG's basename when that differs from th
 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
-`hair`, which no atlas has. Until
-[#577](https://github.com/firejune/rigc/issues/577) a region derived it and an
-authored mesh did not, so that rig **built** and then failed
-`A00_ROUNDTRIP_PARSE: threw: Region not found in atlas: hair` — which is the
-loader's sentence and all the report had. Since
-[#589](https://github.com/firejune/rigc/issues/589) the same miss is named by
-`A08_REGION_NAMES_MATCH_ATTACHMENTS`, with the skin, the slot, the placeholder
-and the attachment's own name beside the path.
+with `image: hair_short.png` under a placeholder called `hair` and no derived
+`path` would resolve the region `hair`, which no atlas has. A region that is
+missing anyway is named by `A08_REGION_NAMES_MATCH_ATTACHMENTS`, with the skin,
+the slot, the placeholder and the attachment's own name beside the path.
 
 Where each vertex sits on the **art**:
 
@@ -1404,8 +1330,7 @@ of the **top-left** quadrant's colour and not one pixel of any other, and the sa
 quad given `0.5 → 1` as 3,120 px of the **bottom-right**. Beside it, the runtime's own
 `MeshAttachment.computeUVs`, handed the emitted atlas region, put `(0, 0)` at page
 pixel `(0.00, 0.00)` and `(1, 1)` at `(64.00, 48.00)` — the region's own two
-corners, in the page's y-down pixels. `CUR44` in the selftest holds the sentence
-above against that second measurement.
+corners, in the page's y-down pixels.
 
 Geometry comes in one of two fields:
 
@@ -1424,19 +1349,19 @@ Geometry comes in one of two fields:
 
 ⭐ **Weights bind bones by NAME, like everything else in a rig spec.** A bone's
 `parent`, a slot's `bone`, an ik constraint's `bones` and `target` and a draw-order
-key's `slot` all resolve by name and refuse a miss by name, and mesh weights now do
+key's `slot` all resolve by name and refuse a miss by name, and mesh weights do
 too: an unknown name is a `CompileError` that says which vertex and which name, and
 the compiler resolves the names to indices on emit. So inserting a bone renumbers
 the emitted array and rebinds nothing.
 
-🚨 **The index form is still reachable and it still costs silence.** Spine's own
+🚨 **The index form is reachable, and it costs silence.** Spine's own
 encoding is a flat run — `boneCount, (boneIndex, bindX, bindY, weight) × n, …` —
 where `boneIndex` is a position in the **emitted** bone array, a list the rig spec
 never writes and cannot see. Put one bone ahead of the meshes and every vertex
 rebinds: the file still loads, every index is still in range, every vertex's weights
 still sum to 1, and `A04`, `A20` and `diff` are all quiet, because an index has no
 name to be wrong. (Measured, on the rung 6 transcription: union MAE 3.30 → 15.09,
-worst mesh-slot drift 0.09 px → 9.8 px, with a green gate throughout. Issue #45.)
+worst mesh-slot drift 0.09 px → 9.8 px, with a green gate throughout.)
 rigc therefore refuses a weighted `vertices` run unless the attachment says
 `"boneIndexing": "raw"` out loud — an opt-in, because what is being opted into is
 the silence.
@@ -1465,11 +1390,9 @@ these messages prints the outline walk, because the walk is the fix:
 | outline vertices that are first but zigzag | `hull vertices must trace the outline in order; the triangles' outline runs 0 → 1 → 3 → 5 → … → 4 → 2, so vertex 3 has to follow vertex 1 in the list, and vertex 2 does. Renumber the vertices along that walk` |
 | triangles with no single outline | `the triangles do not tile the outline: 25 vertices with a 16-vertex outline tile as 32 triangles and there are 33` — an unused vertex or a doubled interior triangle; or `the triangles' outline is not one closed loop: vertex 4 has 4 boundary edges` — a pinch, a hole, or a doubled triangle on the perimeter |
 
-🚨 **A row-major grid is the case this catches**, and until
-[#368](https://github.com/firejune/rigc/issues/368) it was `gallery/portrait`'s: a
-5×5 grid's perimeter is 16 of its 25 vertices, interleaved with the interior, so
-no `hull` can describe that list — and `hull: 0`, which rigc used to write there,
-is what the editor repairs on import by making **every** vertex a hull vertex in
+🚨 **A row-major grid is the case this catches**: a 5×5 grid's perimeter is 16 of
+its 25 vertices, interleaved with the interior, so no `hull` can describe that
+list — and `hull: 0` is what the editor repairs on import by making **every** vertex a hull vertex in
 list order and saying so in a WARNING. A two-column strip is the same trap with
 every vertex on the outline: the list zigzags across, the outline runs down one
 side and up the other, and the hull it would declare self-intersects. The fix is
@@ -1489,17 +1412,14 @@ export carries the edges somebody drew — passes through verbatim.
 `width`/`height` are the size of the image the mesh is drawn on. Stated wins;
 omitted, they are the named PNG's measured size (R5), the same number a region
 reads. With neither a size nor an `image`: `a mesh needs width and height — give
-them, or give an "image" and rigc will measure the PNG`. They were written as 0
-before #368 — a size no spec stated.
+them, or give an "image" and rigc will measure the PNG`.
 
 ⚠️ **Authored geometry is not a rigc generator, and the gate says so.** rigc built
 neither its rim nor its rows, so it gets to assume nothing about its topology:
 `A21_MESH_RIM_PINNED` and `A28_RIBBON_ROWS_SHARE_WEIGHTS` **SKIP** on an authored
 mesh with that as the reason, and `A20`'s two generator-policy branches (a mesh here
 is weighted; a generated mesh binds only bones that move it) do not apply to one.
-`A20`'s coherence rules — weights present, in range, summing to 1 — still do. Issue
-#44; before it was fixed, `A21` reported 40 failures on a correct 40-vertex editor
-mesh because an absent `meshKinds` entry read as `ring`.
+`A20`'s coherence rules — weights present, in range, summing to 1 — still do.
 
 ⭐ **Coverage is the exception, and it is reported for an authored mesh too.** Those
 rules are about a mesh's **structure** — where its rim is, how its rows pair —
@@ -1524,15 +1444,13 @@ meant to bend a core while its edges stretch — so the figure informs and the
 decision stays with the author. A mesh with no `image` reports nothing, because
 there is nothing to measure it against.
 
-**The silence was worth closing, and that example is where it was found.** The
-ball is a centre vertex plus 8 rim vertices, and the first version placed them
-*on* the silhouette — but an octagon's sides pass `R · cos(π/8)` from its centre,
-so its whole ink outline between the spokes was not going to be drawn, and every
-assertion passed (issue #277). That is why the command above prints 100.00%
-rather than the figure it was filed over:
+**Why the figure is worth reading.** The ball is a centre vertex plus 8 rim
+vertices, and an octagon's sides pass `R · cos(π/8)` from its centre — so rim
+vertices placed *on* a round silhouette leave the ink outline between the spokes
+undrawn, and every assertion passes.
 [`gallery/squash`](https://github.com/firejune/rigc/tree/main/gallery/squash)'s
 README carries the inradius arithmetic, both coverage readings, and the rim move
-that settled it.
+that fixes it.
 
 **Linked mesh** ([Spine: linked meshes](http://esotericsoftware.com/spine-meshes)) —
 a mesh that draws **another mesh's geometry** with **its own art**. It is the type
@@ -1568,7 +1486,7 @@ skeleton rigc did **not** write, where the compiler never sees the spec:
 `A44_LINKED_MESH_STATES_NO_GEOMETRY_OF_ITS_OWN` (§5.2) names the attachment, the
 keys and whose geometry is drawn instead, and `ingest` reports one as
 `ATTACHMENT_LINK_GEOMETRY` before dropping it
-([INGEST §2.0](INGEST.md)) — [#710](https://github.com/firejune/rigc/issues/710).
+([INGEST §2.0](INGEST.md)).
 
 🚫 **A chain is refused, and so is a link to itself.** A `source` that names
 another linked mesh resolves in the order the file was read: measured through
@@ -1669,7 +1587,7 @@ other vertex attachment.
 | `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` | **stated or measured** ([#804](https://github.com/firejune/rigc/issues/804)). The cumulative length at the end of each curve, and exactly **`vertexCount / 3`** entries on an open path and a closed one alike — the parser's own allocation, which on an open path is one more than its curves: the last entry is the wrap-around curve's cumulative, which the editor writes and nothing reads. **Stated**, it is emitted as stated (float32, like every number in the file) — which is what `ingest` writes from an export, and the only way to carry the editor's number, because the editor measures the pose the first update gives the path constraint, *constraints applied*, and rigc does not pose. A stated array of the wrong count is refused with both counts, `"lengths" has N entry(ies) where the parser sizes M`, and a non-finite entry or one below its predecessor by index. **Left out**, rigc measures it off the geometry: weighted vertices through their bones' setup world transforms, scale, shear and `inherit` included, on the **unconstrained** setup pose — so a path whose bones a constraint moves at rest gets a different figure from the editor's. Only `constantSpeed: false` reads the field at all. What the numbers are — and why *arc length* is the wrong name for them — is §10.6 |
+| `lengths` | **stated or measured**. The cumulative length at the end of each curve, and exactly **`vertexCount / 3`** entries on an open path and a closed one alike — the parser's own allocation, which on an open path is one more than its curves: the last entry is the wrap-around curve's cumulative, which the editor writes and nothing reads. **Stated**, it is emitted as stated (float32, like every number in the file) — which is what `ingest` writes from an export, and the only way to carry the editor's number, because the editor measures the pose the first update gives the path constraint, *constraints applied*, and rigc does not pose. A stated array of the wrong count is refused with both counts, `"lengths" has N entry(ies) where the parser sizes M`, and a non-finite entry or one below its predecessor by index. **Left out**, rigc measures it off the geometry: weighted vertices through their bones' setup world transforms, scale, shear and `inherit` included, on the **unconstrained** setup pose — so a path whose bones a constraint moves at rest gets a different figure from the editor's. Only `constantSpeed: false` reads the field at all. What the numbers are — and why *arc length* is the wrong name for them — is §10.6 |
 
 🚨 **`vertexCount` counts knots AND handles, and it has to be a multiple of 3.**
 The parser hands `vertexCount << 1` to `readVertices` and then walks the result in
@@ -1710,13 +1628,12 @@ mesh counts against that budget, a rig that declares none has a budget of
 beside it: without it `A13_MESH_BUDGET` has nothing to measure against and SKIPs,
 and the `MESH` report line has no budget to print. Authored geometry is exempt in
 the other direction and for the same reason — rigc did not draw it, so leaving it
-unmeasured is the author's call (issue #274).
+unmeasured is the author's call.
 
 ⭐ **The no-manifest path centres the part window on its own slot bone.** There is
 no crop to flip against, so `size` (or, for a contour, the PNG's own size) is
 placed with its centre on the bone the slot names — which is also exactly where a
-plain region attachment with no `x`/`y` would have drawn it. Measured on a ring, a
-ribbon and a moved bone by `CT05` in the selftest (issue #1).
+plain region attachment with no `x`/`y` would have drawn it.
 
 #### `ring` — an aperture that opens inside a pinned seam
 
@@ -1770,13 +1687,9 @@ the centre line all 8 take more weight from the grip on their own side. Splittin
 **moves** authority rather than adding it: every vertex gives its controls the
 same total with one grip, two or three.
 
-⚠️ **This route used to bind only the first name**
-([#684](https://github.com/firejune/rigc/issues/684)). It passed no angles at all,
-so the split collapsed onto `controls[0]` and the rest of the names reached the
-`MESH` line, the bone list and nothing else — and the gate was green, because a
-bone no vertex binds is in no weight, no sum and no index. `A20_MESH_WEIGHTS_COHERENT`
-now names it, so a ring that declares a grip and does not use it is a failure
-rather than a quiet stiffness.
+⚠️ **A grip no vertex binds is a failure, not a quiet stiffness.** A bone no
+vertex binds is in no weight, no sum and no index, so nothing else would notice
+it; `A20_MESH_WEIGHTS_COHERENT` names it.
 
 **Stated limits, each a named refusal rather than a mesh that loads wrong:**
 
@@ -1853,12 +1766,12 @@ detail of the attachment.
 ⭐ **Both keys are the fragment.** Drop the two of them into §1.1's minimal rig in
 place of its `skins`, rename its `box` bone and slot to `cape`, put a
 transparent-margined `cape.png` in `images/`, and it compiles — `invariants`
-included, because without it the generator is refused (issue #274). The
+included, because without it the generator is refused. The
 `meshTriangles` figure is invented; pick the one your renderer can afford.
 
 | Field | Meaning |
 | --- | --- |
-| `tolerance` | **required.** Douglas-Peucker tolerance, in the drawing's pixels — on a packed page that declares a `scale:`, applied as `tolerance × scale` of its texels (§0.2, [#779](https://github.com/firejune/rigc/issues/779)). Bigger spends fewer vertices and cuts more corners |
+| `tolerance` | **required.** Douglas-Peucker tolerance, in the drawing's pixels — on a packed page that declares a `scale:`, applied as `tolerance × scale` of its texels (§0.2). Bigger spends fewer vertices and cuts more corners |
 | `margin` | how far the outline is pushed out past the traced silhouette, in the drawing's pixels (`margin × scale` texels on a `scale:` page). Default `1` |
 | `maxVertices` | refuse rather than emit more outline vertices than this — judged on the outline the two distances above ask for, so a finer `scale:` page of the same art needs no bigger budget. Default `64` |
 | `alpha` | the alpha at or above which a pixel counts as art, `1`..`255`. Default `1` — any pixel that is not fully transparent |
@@ -1880,9 +1793,7 @@ against the mask it came from**. `build` and `explain` print what it measured:
 ```
 
 The budget in that line is the rig's `invariants.meshTriangles` — `(no budget
-declared)` when it declares none, which is the same distinction `A13` SKIPs on. It
-used to be the literal `80` whatever the rig said, so the line an author reads and
-the assertion that measures could print two different numbers (issue #275). A part
+declared)` when it declares none, which is the same distinction `A13` SKIPs on. A part
 whose outline encloses a hole says so too, because nothing else in the output
 moves when one appears:
 
@@ -1916,8 +1827,7 @@ That last one is the guarantee: **the emitted triangles cover at least 99.5% of
 the art**, measured by rasterising them back over the mask, and a build that would
 clip the art is refused rather than shipped. It is not 100% because a
 simplification that could never cut a corner would not be one — the figure a
-given part actually measures is in the `build`/`explain` line above, and the
-selftest's fixture measures 100.000%.
+given part actually measures is in the `build`/`explain` line above.
 
 Self-intersection is refused; **holes are not cut out**; and nothing here does
 interior/Steiner points, so a contour mesh bends only where its outline has
@@ -1947,11 +1857,8 @@ attachment's own `image`, and every vertex is pinned to the slot bone at weight
 
 ⭐ **Positions, because [FACE §4.1](FACE.md) places columns where the drawing
 needs them.** The five above are `gallery/portrait`'s own — dense at the
-silhouette, sparse across the middle, and not reaching the window edge. A
-generator that could only divide evenly would be a step backwards from the table
-it replaces, and it does replace it: the selftest builds that exact mesh from
-those five numbers and requires it to come out identical to the 25 vertex pairs
-and 32 triangles the example shipped by hand.
+silhouette, sparse across the middle, and not reaching the window edge — a
+layout an even division cannot state.
 
 🚨 **The reason to generate this at all is the hull.** Spine's `hull` is a
 **count** — the first `hull` entries of the vertex list are the outline — so the
@@ -1993,9 +1900,9 @@ off a greyscale sheet in the part's own pixel grid:
 
 | Field | Meaning |
 | --- | --- |
-| `image` | **required.** The sheet, relative to the rig's `images` directory, and the **same pixel size as this attachment's `image`**. It is not packed into the atlas — it is a measurement rigc reads at compile time, not art anything draws. Under `--atlas-in` that is still the drawing's size, on a page that declares a `scale:` too: the sheet is read at each vertex's texel position over the scale the atlas states, so one sheet serves the loose parts and every pack of them ([#762](https://github.com/firejune/rigc/issues/762)) |
+| `image` | **required.** The sheet, relative to the rig's `images` directory, and the **same pixel size as this attachment's `image`**. It is not packed into the atlas — it is a measurement rigc reads at compile time, not art anything draws. Under `--atlas-in` that is still the drawing's size, on a page that declares a `scale:` too: the sheet is read at each vertex's texel position over the scale the atlas states, so one sheet serves the loose parts and every pack of them |
 | `near` | **required.** `"white"` or `"black"` — which end of the range is closest to the viewer. Stated rather than defaulted: both conventions are in use, and a sheet read with the wrong one turns the part inside out with every gate still green |
-| `zScale` | **required.** How many world units the map's full range spans, in the attachment's own units — the number `radius` used to carry. 8 bits of level say nothing about scale, so this is authored, never measured |
+| `zScale` | **required.** How many world units the map's full range spans, in the attachment's own units — the number `radius` carries on a cylinder. 8 bits of level say nothing about scale, so this is authored, never measured |
 | `gamma`, `contrast`, `bias` | the tone curve applied to the nearness, defaults `1` / `1` / `0`. State them when a consumer's own renderer curves the same sheet, so the mesh and that renderer describe one surface |
 
 The order is fixed and it matters, because every step is a place two
@@ -2024,9 +1931,7 @@ The loop this replaces is *pick an angle, build, read the refusal, guess again*.
 #### Is the ceiling describing the form, or the sheet's grain?
 
 The lines under the ceiling answer that, and they are **reports only** — nothing
-in them refuses a build or moves a ceiling
-([#412](https://github.com/firejune/rigc/issues/412),
-[#448](https://github.com/firejune/rigc/issues/448)).
+in them refuses a build or moves a ceiling.
 
 The ceiling is the **minimum** of the per-triangle fold angles, and a minimum
 cannot say whether it is the floor of a band or one bad pixel. Measured: a clean
@@ -2110,8 +2015,7 @@ off the screen before it gets there** — fade the slot to alpha 0 (`rgba`, §4.
 swap the attachment away, as the far cheek or ear does while the head turns. That
 third one is measured rather than declared: a deform key whose slot draws no
 pixels at that key's own time is passed over by name, with the reason on the
-stats line and in the `DEFORM` block
-([#401](https://github.com/firejune/rigc/issues/401)). **Alpha exactly 0** — a
+stats line and in the `DEFORM` block. **Alpha exactly 0** — a
 part faded halfway is still refused, and the alpha is in the message.
 
 🚨 **Land the alpha-0 key *before* the folding key, not on it.** The gate measures
@@ -2141,9 +2045,8 @@ u** — and it reaches zero at `tan t = A₀/A_yaw`. Three consequences:
 
 ⛔ It is a **report and never a refusal**. `A39` owns the refusal, from the
 artifact and through the runtime; a second wall here would be the compiler
-inventing a policy out of a measurement. What holds the two together is a
-control: `TC01` requires this number to be the angle `A39` actually fires at, on
-the triangle `A39` actually names, to 0.01°.
+inventing a policy out of a measurement. The two agree: this number is the angle
+`A39` fires at, on the triangle `A39` names, to 0.01°.
 
 🚨 **The one that will catch you: the sheet has to cover the mesh, and usually
 it does not.** A contour mesh puts every vertex *on* the silhouette and pushes it
@@ -2170,15 +2073,13 @@ in it, which is what monocular depth estimation produces — covers its whole gr
 by construction, so the coverage refusal has nothing to hold it to and skips.
 That is right: a full-frame sheet is a legitimate statement and rigc has no
 authority to guess an input away. But the defect the refusal exists to catch is
-still reachable in that encoding, so the report counts it instead
-([#449](https://github.com/firejune/rigc/issues/449)):
+still reachable in that encoding, so the report counts it instead:
 
 ```
         80 of 189 vertices sample a texel the part image does not draw — their z is the sheet's reading of somewhere the part is not
 ```
 
-⚠️ **The reported range is NOT where this shows up**, and this guide said it was
-until it was measured. A background level is a legitimate depth value, so a map
+⚠️ **The reported range is NOT where this shows up.** A background level is a legitimate depth value, so a map
 half of which is background reports exactly as full a range as one that is all
 subject: on the measured build, `z=[0, 223.97]` of a stated 224 — healthy — with
 54 % of the mesh reading background. "Covers its whole grid" is true and about
@@ -2227,21 +2128,18 @@ hanging sleeve.
 | Field | Meaning |
 | --- | --- |
 | `bone` | **required.** The bone the region is carried by. It has to already exist — a bone a physics constraint targets is part of the skeleton, not a side effect of a mesh |
-| `mask` | **required.** A greyscale sheet in the part's own pixel grid: the level IS the weight, black still and white fully carried, sampled at each vertex. Alpha is not read — a transparent pixel is black. The grid is the drawing's, as for a depth map: on a `scale:` page the mask is still the art's size ([#762](https://github.com/firejune/rigc/issues/762)) |
+| `mask` | **required.** A greyscale sheet in the part's own pixel grid: the level IS the weight, black still and white fully carried, sampled at each vertex. Alpha is not read — a transparent pixel is black. The grid is the drawing's, as for a depth map: on a `scale:` page the mask is still the art's size |
 
 The remainder always stays on the slot bone, so every vertex closes at 1 by
 construction rather than by `A20` catching it later. `build` and `explain` report
 the mask's digest, how many vertices were carried outright and how many landed in
 the painted falloff.
 
-🚨 **Why a painted mask and not a depth threshold.** rigc tried the threshold —
-"the near part wobbles" — for exactly one day. It is wrong, and instructively so:
-**softness and prominence are different properties of a drawing.** The most
-prominent thing on a face is the nose, and a nose does not wobble. A threshold
-produced a region that was plausible, gated green and carried the wrong pixels.
-It also claimed something untrue — "no mask painted" — while the renderer this
-was modelled on had a hand-painted spring mask all along. rigc does not get to
-delete an input by guessing it.
+🚨 **Why a painted mask and not a depth threshold.** A threshold — "the near part
+wobbles" — is wrong, and instructively so: **softness and prominence are different
+properties of a drawing.** The most prominent thing on a face is the nose, and a
+nose does not wobble. A threshold produces a region that is plausible, gates green
+and carries the wrong pixels. rigc does not get to delete an input by guessing it.
 
 ⭐ The falloff is painted for the same reason. A `feather` parameter would be
 rigc guessing the shape of something you can simply draw.
@@ -2261,13 +2159,10 @@ bone, must close at 1, and at least one must actually be carried.
 | a mask that is not on disk | `the soft mask "x.png" is not at …` |
 
 ⭐ **One depth pass buys both, on one part.** A carried mesh has two bones on the
-vertices in the mask's falloff, and a `transform` key (§4.12) used to be refused
-on any attachment that did — so the **angle** a raised surface turns through and
-the **impact** a soft one answers had to sit on separate slots. Since
-[#389](https://github.com/firejune/rigc/issues/389) they do not: the model is
-evaluated at each vertex's setup world position and pushed into every influence
-through that bone's own inverse. `SF03` is the case that measures the
-combination. ⚠️ Read §4.11.1 before you add a mask to a part that already turns:
+vertices in the mask's falloff, and a `transform` key (§4.12) works on it: the
+model is evaluated at each vertex's setup world position and pushed into every
+influence through that bone's own inverse, so the **angle** a raised surface turns
+through and the **impact** a soft one answers sit on one slot. ⚠️ Read §4.11.1 before you add a mask to a part that already turns:
 past one bone the model's own coordinates are **world** ones, so `radius` and
 `about` change units.
 #### 3.4.1 A skin that switches bones and constraints on
@@ -2374,13 +2269,11 @@ defaults to it, so an image named after it needs no `path`:
 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:
+🔬 **rigc composes no name here, and nothing needs one.** The editor's refusal of a
+four-skin rig — `Multiple attachments have the same name: patch patch` — reads like
+"one name over several attachments, because a linked mesh resolves its parent by
+name", and a composed `"<skin>/<placeholder>"` on every contested entry like the
+repair. 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
@@ -2393,18 +2286,17 @@ and [#552](https://github.com/firejune/rigc/issues/552) wrote
   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`.
+What the editor does refuse is a rig whose **default** skin fills the contested
+placeholder beside the named ones — the smallest refusing variant is `default` plus
+one named skin — and that shape is refused on measurements of its own, below. A
+composed name would rename every contested attachment at runtime, which
+`slot.attachment.name` shows a consumer; `diff` 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
-**4.3.26** established it by ruling out both of the only two spellings there are
-([#567](https://github.com/firejune/rigc/issues/567)):
+**4.3.26** established it by ruling out both of the only two spellings there are:
 
 - **Give the default skin's entry a name of its own** (`"name": "default/patch"`)
   and the import succeeds — then the export comes back with that name as the
@@ -2444,28 +2336,16 @@ What to know about it, and nothing to author:
   `const regionImage = region && this.regionImages.get(region.name)`, where
   `region` came off the attachment — which `AtlasAttachmentLoader` resolved
   through `path`. Every published version of that renderer keys the same way.
-  ⚠️ `A08` used to carry a `--profile spine-html` clause requiring a
-  placeholder to be spelled exactly like the region it resolves to, which made
-  this shape and a green `spine-html` **mutually exclusive** from
-  [#567](https://github.com/firejune/rigc/issues/567) onwards; the first
-  production rig with named skins hit it three times. That clause is retired —
-  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)).
 - **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)).
+  the skin, the slot, the placeholder and the path if the region is not there.
 - **Each skin's art is measured and atlased on its own.** The example above points
   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).
+  that file. Name the two files **distinctly**: 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
@@ -2475,7 +2355,7 @@ slot across its named skins. The one refusal the editor was measured making is t
 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
+which one.** `render` and
 `check` set no skin unless told to, so every slot resolves through the *default*
 skin alone and the art you just moved into `base`, `zulu` and `mike` draws
 nothing at all. `check` then compares blank against blank and reports a perfect
@@ -2483,8 +2363,7 @@ nothing at all. `check` then compares blank against blank and reports a perfect
 `--skin <name>` to both, once per skin (**§9**); `tools/editor_roundtrip.ts`
 loops over every skin the build and the export both declare for the same reason,
 and names a skin only one of them declares as **lost** (or **added**) **by the
-export**, quoting `diff`'s `attachments.skins`, without rendering it on either side
-([#801](https://github.com/firejune/rigc/issues/801)).
+export**, quoting `diff`'s `attachments.skins`, without rendering it on either side.
 
 #### 3.4.3 `sequence` — a numbered image series on one attachment
 
@@ -2525,8 +2404,7 @@ The loader's own miss would be `Region not found in atlas: glint_0005 (attachmen
 glint)`, which says neither that the region was a frame nor of which series.
 
 ⚠️ **The rest of what is refused**, each a series the parser would load as something
-other than what was written (measured on spine-core 4.3.13,
-[#729](https://github.com/firejune/rigc/issues/729)):
+other than what was written (measured on spine-core 4.3.13):
 
 - a `setup` at or past `count` — `Sequence.resolveIndex` clamps it to the last frame
   (`setup: 7` on four frames showed frame 4);
@@ -2546,8 +2424,7 @@ 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
+sizes — the setup frame's size, the other frames as they are. 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
@@ -2579,11 +2456,7 @@ carrying here:
   finds each from its own group, and a motion spec's `ik` block, `transform`
   block and `path`/`physics`/`slider` tracks each name the kind they mean and
   resolve the same way (§4.9, §4.12). Two constraints **of one kind** sharing a
-  name are refused (§5.1), because no timeline could say which was meant. Until
-  [#692](https://github.com/firejune/rigc/issues/692) the rig spec kept one
-  namespace over the whole array, so a rig the editor exports and the runtime
-  plays — an IK chain and the transform constraint that follows it, both carrying
-  the chain's name — could not be written down at all.
+  name are refused (§5.1), because no timeline could say which was meant.
 - A transform constraint's `properties` names come from a fixed six — `rotate`,
   `x`, `y`, `scaleX`, `scaleY`, `shearY`. rigc refuses anything else by name; in
   raw JSON the parser throws.
@@ -2606,11 +2479,8 @@ carrying here:
   `true` and leaves the rest alone (`Animation.js:2066-2072`). So the flag is one
   constraint's **opt-in to being driven in bulk**, per tuning value, and it does
   nothing on its own. The parser's default for all seven is `false`.
-  The motion spec keys that timeline as **`"physics": "*"`** (§4.4,
-  [#726](https://github.com/firejune/rigc/issues/726)), and rigc writes it under
-  the empty name. Until then rigc emitted the flags and could not emit the
-  timeline that reads them: every physics track named its constraint and the
-  empty name was refused as `keys unknown physics constraint ""`. What rigc does
+  The motion spec keys that timeline as **`"physics": "*"`** (§4.4), and rigc
+  writes it under the empty name. What rigc does
   with the flags is **pass them through**, `false` included: measured, a
   constraint stating none emits none, and one stating `"windGlobal": false` emits
   `"windGlobal": false` rather than dropping it the way the motion spec's
@@ -2620,10 +2490,8 @@ carrying here:
 - `"*"` is **reserved** as a physics constraint's name, in the rig spec and in
   §4.6's table alike: a track naming it could mean either. `compile` refuses one
   by name.
-- ⚠️ `src/rig.ts` called the physics `ScaleYMode` key **`scaleYMode`** until
-  issue #545 — the runtime's field name rather than the format's key — and nothing
-  read it, so a spec that wrote `scaleYMode` set no mode and said nothing. A rig
-  that still writes it is now refused by name, with `scaleY` beside it.
+- ⚠️ **`scaleYMode`** — the runtime's field name rather than the format's key —
+  is refused by name, with `scaleY` beside it.
 
 Every constraint may also carry `skin: true`, which makes it run only under the skin
 that lists it — see §3.4.1, and note that the flag alone does nothing.
@@ -2633,7 +2501,7 @@ that is deliberate. Every key on a constraint object is a Spine field the emitte
 writes; a statement to the gate about who turns the dial is what the artifact cannot
 say about itself, so it lives in `invariants.consumerDrivenMix` (§3.7), beside
 `deformMayFold` — the one other exemption from a named rule, which names its subject
-the same way ([#784](https://github.com/firejune/rigc/issues/784)).
+the same way.
 
 #### 3.5.1 `path` — bones that travel along a curve
 
@@ -2714,7 +2582,7 @@ dial, the gate swings.
 timeline left it: a negative time is not clamped to the first frame, it is a time
 before the animation starts, where `Animation.apply` leaves the pose it found
 untouched. That is the same picture as the first frame only when the first frame
-*is* the rest pose. [measured] `PS140` in `selftest.ts`.
+*is* the rest pose.
 
 | Field | Meaning |
 | --- | --- |
@@ -2739,40 +2607,28 @@ where the message can name both files.
 why R10 exists.** In JSON the reference is a name on both sides. In the format's
 binary half it is an **ordinal** — `constraint.animation = animations[readInt()]`
 (`SkeletonBinary`) — so an editor holding that ordinal writes back whichever
-animation now stands at the position. `gallery/look` went into a licensed editor
-(data version 4.3.26) as `turn, tilt, sweep` with `yaw -> "turn"` and came back
+animation now stands at the position. `gallery/look` taken into a licensed editor
+(data version 4.3.26) as `turn, tilt, sweep` with `yaw -> "turn"` comes back
 `sweep, tilt, turn` with **`yaw -> "sweep"`**: a file that parses, gates green and
-applies the wrong animation. ⭐ Its second slider is what named the mechanism
-rather than a second casualty — `tilt` survived because it sat at index 1 in both
-orderings. rigc now emits animations in the editor's own order so its re-sort
-moves no index ([#535](https://github.com/firejune/rigc/issues/535)); on the same
-rig through the same editor that restored `yaw -> "turn"` and took the
-re-rendered mean absolute error from 10.4655 / 8.4961 / 8.7140 down to
-0.3035 / 0.0769 / 0.0588. (`look`'s three names are ones a codepoint sort orders
-identically, which is what rigc emitted when that trip was measured.)
-
-⚠️ The editor's comparator is natural and case-insensitive
-([#539](https://github.com/firejune/rigc/issues/539)) and is now measured in full
-off five stored round trips
-([#728](https://github.com/firejune/rigc/issues/728)) — so the emit is the
-editor's own order, and only what those files leave open is a compile error.
-**R10** has the rule and the three shapes to avoid.
-
-✅ **What that repair does not reach is a compile error now, not a hazard.** This
-paragraph used to say that names a codepoint sort and a friendlier one disagree
-about — `Turn` / `turn`, `turn2` / `turn10` — were where *the hazard returns*, and
-that nobody had round-tripped such a pair. Somebody has: `Turn, sweep, wave` came
-back `sweep, Turn, wave` and `turn10, turn2, zoom` came back `turn2, turn10, zoom`
-([#539](https://github.com/firejune/rigc/issues/539)). ⇒ rigc no longer leaves
-that to naming discipline — and since
-[#543](https://github.com/firejune/rigc/issues/543) it does better than refusing
-those two, because they are the two sets the editor's answer is **known** for:
-both are emitted in the order it returned. What is still a compile error is the
-set whose order turns on one of the three things the round trips of
-[#728](https://github.com/firejune/rigc/issues/728) leave open, printed with both
-names, which of them decides it, and the rename that settles it. What changed is
-the price of forgetting: a build that stops, rather than a slider that silently
-applies the wrong animation.
+applies the wrong animation — `tilt` survives only because it sits at index 1 in
+both orderings. rigc emits animations in the editor's own order so its re-sort
+moves no index; on the same rig through the same editor that keeps
+`yaw -> "turn"`, at a re-rendered mean absolute error of 0.3035 / 0.0769 / 0.0588
+against 10.4655 / 8.4961 / 8.7140 for the order above.
+
+⚠️ The editor's comparator is natural and case-insensitive, measured off five
+stored round trips — so the emit is the editor's own order, and only what those
+round trips leave open is a compile error. **R10** has the rule and the three
+shapes to avoid.
+
+✅ **What that order does not settle is a compile error, not a hazard.** Names a
+codepoint sort and a friendlier one disagree about — `Turn` / `turn`, `turn2` /
+`turn10` — are emitted in the order the editor returns for them: measured,
+`Turn, sweep, wave` comes back `sweep, Turn, wave` and `turn10, turn2, zoom` comes
+back `turn2, turn10, zoom`. A set whose order turns on one of the three things
+those round trips leave open is refused, printed with both names, which of them
+decides it, and the rename that settles it — a build that stops, rather than a
+slider that silently applies the wrong animation.
 
 ⚠️ **The fields of the model you did not choose are refused, not ignored.** The
 parser reads `time` only in the bone-less branch and `property`/`from`/`to`/`scale`/
@@ -2811,8 +2667,8 @@ one wins today. ⛔ rigc does **not** set the flag for you. The compiler never
 invents a value that is not in the spec, and a rig whose composition was chosen by
 the tool is one nobody can reason about.
 
-⚠️ **And below full authority it is a weighting rather than a quieter erasure**
-([#399](https://github.com/firejune/rigc/issues/399)). An additive slider scales
+⚠️ **And below full authority it is a weighting rather than a quieter erasure.**
+An additive slider scales
 its whole contribution by its own `mix`, so two of them at any pair of mixes are
 still the sum — which is why `A40` skipping below full authority is right: what
 happens there is a weighting, not the erasure it refuses. A **non-additive**
@@ -2822,8 +2678,7 @@ the pose it found*, so the earlier slider is not erased — it is attenuated by
 part of the way down takes that share of every earlier slider on the target with
 it, on every frame, with the gate green — the second reason to write
 `"additive": true` on **every** slider that shares a target and not only on the
-later one. `PS130` in `selftest.ts` poses both models rather than quoting the
-runtime, and [`docs/FACE.md`](FACE.md) §8 is the same rule on a face's two axes.
+later one. [`docs/FACE.md`](FACE.md) §8 is the same rule on a face's two axes.
 
 ⚠️ **And `"additive": true` is not always available.** What composes is bone,
 deform, transform-constraint, path `position` and path `mix`, physics
@@ -2831,36 +2686,27 @@ deform, transform-constraint, path `position` and path `mix`, physics
 a slot colour, an attachment swap, a draw order and a sequence, and also an **ik
 constraint's mix**, a path's `spacing`, and every physics timeline except those
 two — so two sliders sharing one of those overwrite each other whatever you
-write. ⚠️ The four spelled out here used to read as the whole of the complement
-and they are examples of it; `A40` was never reading a list, which is why it
-refuses the ik case this sentence did not name.
+write. ⚠️ Those are examples of the complement, not the whole of it: `A40` reads
+no list.
 
-🚨 **That list is not `Timeline.additive`, and this is what it cost to learn.**
+🚨 **That list is not `Timeline.additive`.**
 The runtime's own flag says a class "supports being applied additively", and on
 two classes it is not what the class does: `PathConstraintMixTimeline` and
 `SliderTimeline` declare themselves non-additive and their `apply` passes the
 `add` argument straight through anyway — every other non-additive timeline either
 hardcodes `false` in the call, zeroes `add` first, or never reads it. So two
 additive sliders keying one path constraint's `mix`, or one slider's `time`,
-**do** compose, as the same sum as everything else above, and `A40` refused both
-by name with a message saying `"additive": true` would not compose them. ✅ **It
-no longer reads the flag: it poses each shared timeline twice with `add` set and
-reads whether the second application accumulated**
-([#655](https://github.com/firejune/rigc/issues/655)), so the two rigs above pass
-and the message names what the class was measured to do. [measured] `PS143` in
-`selftest.ts` poses all thirty spellings of the motion vocabulary under two
-additive sliders and prints the flag beside the behaviour; `PS145` holds the
-probe's verdict to that same pose on every one of them; `PS140` holds the `time`
-case to a grid.
-
-⭐ **The same measurement retired a refusal nothing could have distinguished.**
-Two sliders whose animations both fire **events** were refused as sharing a
-property — and a slider fires no event at all: it applies its animation with
-`firedEvents` null, and `EventTimeline.apply` returns on that. The probe's third
-answer is *this timeline moved no pose at all*, so an events pair, and a physics
-`reset` pair with it, are simply not findings. Nothing else changed: a shared
-slot colour, attachment, draw order, ik mix, path `spacing` or physics property
-is refused exactly as before.
+**do** compose, as the same sum as everything else above. ✅ **So `A40` does not
+read the flag: it poses each shared timeline twice with `add` set and reads
+whether the second application accumulated**, and the message names what the
+class was measured to do.
+
+⭐ **Two sliders whose animations both fire events are not a finding.** A slider
+fires no event at all: it applies its animation with `firedEvents` null, and
+`EventTimeline.apply` returns on that. `A40`'s third answer is *this timeline
+moved no pose at all*, so an events pair, and a physics `reset` pair with it, are
+passed. A shared slot colour, attachment, draw order, ik mix, path `spacing` or
+physics property is refused.
 
 ⇒ **And the `constraints` array decides twice, for two different reasons.**
 *Overwriting* has a direction: the slider **later in the array** puts its own
@@ -2874,16 +2720,11 @@ earlier ik constraint, the `position` of an earlier path constraint or the `wind
 of an earlier physics constraint writes a value nothing reads again, and what
 that constraint drives is dead at every position of the dial.
 
-✅ **That second one is a refusal by name since
-[#658](https://github.com/firejune/rigc/issues/658), and it covers every
-constraint kind since [#665](https://github.com/firejune/rigc/issues/665).**
+✅ **That second one is a refusal by name, for every constraint kind.**
 `A42_DRIVEN_CONSTRAINTS_UPDATE_AFTER_THEIR_DRIVER` names the driving slider, the
 driven constraint and its kind, the property, both `constraints` indices, the
 runtime class whose `update` does the reading and the animation the key sits in,
-and its repair is the reorder. It is a rule of its own rather than a clause of
-`A40` because `A40`'s population is the sliders whose `mix` nothing keys — the
-exclusion *is* the shape of the hole — and not a clause of `A37`, which asks
-whether some animation keys the `mix` above 0 and never which one.
+and its repair is the reorder.
 ⭐ **The runtime repairs this for bones and not for constraints**, which is why an
 author cannot reason it out from the bone case: `Slider.sort` clears `sorted` on
 every bone its animation keys so those bones re-sort *after* the slider, while
@@ -2904,14 +2745,10 @@ round. 🔸 **One spelling is outside the rule and a reorder does not repair it*
 a `physics` `reset` key. It writes no pose and fires only when a frame time is
 crossed, and a slider applies its animation at a single instant — so the key
 never fires in either order, and the SKIP says so rather than advising a move
-that would change nothing. [measured] `PS139`, `PS140`, `PS156`, `PS157`,
-`PS158`, `PS159` and `PS160` in `selftest.ts`.
+that would change nothing.
 
 Swap the two array entries and the answer swaps with them — it is the
-array that decides, not the flags and not which animation the file names first
-(`PS135` in `selftest.ts` poses four such targets both ways; `PS136` poses the
-three that do compose, and they are the same sum §3.5.2 states, over each target's
-own setup value). A40 names this case separately, because the fix is different:
+array that decides, not the flags and not which animation the file names first. A40 names this case separately, because the fix is different:
 key such a property from one slider only, or move both edits into the single
 animation one slider applies.
 
@@ -2920,8 +2757,7 @@ animation one slider applies.
 **A `property` under `local: false` is read through the world transform, and four
 of those readings are bounded.** A range that names values the reader cannot
 return is dead there: the dial moves, the reading does not follow, and nothing at
-runtime says so. [measured] against `spine-core` 4.3.13, one reader at a time —
-`bench/studies/2026-09-06-readers`:
+runtime says so. [measured] against `spine-core` 4.3.13, one reader at a time:
 
 | `property` | `"local"` | Reads | Producible floor | Producible ceiling |
 | --- | --- | --- | --- | --- |
@@ -2952,10 +2788,9 @@ runtime says so. [measured] against `spine-core` 4.3.13, one reader at a time
   🚨 One that dips below it is not *dead*, it **folds**: −2 and +2 read the same
   number, select the same frame and pose the same face, so the axis doubles back
   on itself about the point it should have passed through. Such a range is
-  **refused at compile** (§3.5.2.2, beside the `rotate` circle). [measured]
-  `PS138` sweeps both halves and poses them; `PS151` poses the fold on a dial the
-  refusal leaves standing — a legal `0`..`4` window turned below 0 by a consumer
-  applies the same time at −2 and +2 to the bit, while the same mapping read
+  **refused at compile** (§3.5.2.2, beside the `rotate` circle). [measured] a
+  legal `0`..`4` window turned below 0 by a consumer applies the same time at −2
+  and +2 to the bit, while the same mapping read
   `local: true` is on its own signed mapping at every cell.
 - **`shearY` under `local: false` wraps like `rotate` does, and worse.** It is a
   difference of two `atan2` calls, so at any one bone orientation the readable
@@ -2965,8 +2800,8 @@ runtime says so. [measured] against `spine-core` 4.3.13, one reader at a time
   pointing. Prefer `local: true` for a shear axis.
   ⚠️ **Nothing refuses a `shearY` range, and that is deliberate.** The reader
   keeps its sign — it does not fold the way the two `scale` readers do — and what
-  it does instead is not a fact a rig spec holds: [measured] `PS155` sweeps three
-  orientations across their own seams and each wraps by exactly one turn at
+  it does instead is not a fact a rig spec holds: [measured] three orientations
+  swept across their own seams each wrap by exactly one turn at
   `90° − θx` (90°, 45° and 150° for a dial bone at 0°, 45° and −60°), which any
   animation a consumer writes can move. A range rule here would have to name a
   seam the compiler cannot know, and would pass the case that actually breaks.
@@ -3026,8 +2861,7 @@ examples above each sit within one turn, where a single ±360 gives the same
 answer; past that only the modulo does. [measured] through spine-core, a bone
 parked at **−500°** drives the slider to **3.600000 s**, which is exactly where a
 bone parked at **220°** drives it — so the reading is 220°, not −140°, and a
-refusal naming −140° would be naming a value that reader cannot return at all
-(issue [#431](https://github.com/firejune/rigc/issues/431)). The same on the other
+refusal naming −140° would be naming a value that reader cannot return at all. The same on the other
 side: **900°** drives it to **0.200000 s**, the time a bone at **180°** selects.
 
 📐 **The consequence in that message is computed, not described.** Both refusals
@@ -3062,10 +2896,7 @@ lies outside `[0, 360]` — and not the reach from the boundary to the far end.
 two are the same number for a range that *straddles* a boundary, as `300°..500°`
 does. A range lying **wholly** outside is told its own width instead: `400°..500°`
 reads *"the 100.000° of the range past 360°"*, and `-500°..-300°` *"the 200.000°
-of the range below 0°"* (issue
-[#434](https://github.com/firejune/rigc/issues/434) — both used to print the
-reach, which on the first of those was 140.000°, wider than the 100°-wide range
-it was describing).
+of the range below 0°"*.
 
 ⭐ **A range ending exactly on 360° is legal**, and that is the whole turn: a
 wheel, a turntable, a head that goes all the way round, written `from: 0` with a
@@ -3109,8 +2940,7 @@ the same posed face. The refusal names the arc that is written twice:
 - **A range lying wholly below 0 gets its own sentence** — *"the whole 4.000 of
   this range is below 0, so it reaches none of the animation's 1s"* — and that
   figure is the width **under** the floor, not the reach to the far end, the same
-  distinction [#434](https://github.com/firejune/rigc/issues/434) drew for the
-  circle.
+  distinction the circle's message draws.
 - **`loop: true` changes nothing here**, unlike the circle: a fold is not a
   clamp, so there is no loop branch in the message. [measured] the same ±1.500
   pair applies 1.875000 s either way.
@@ -3118,14 +2948,14 @@ the same posed face. The refusal names the arc that is written twice:
   negative half drives the *first* half of the animation ([measured] −2 →
   0.000 s, +2 → 1.000 s), or moving the range so it does not dip below 0.
 
-[measured] `PS151`–`PS154` in `selftest.ts`. `shearY` has no such rule and
+`shearY` has no such rule and
 §3.5.2.1 says why: that reader keeps its sign and wraps at a seam the bone's own
 orientation places, which a rig spec does not hold.
 
-⚠️ **An artifact can still carry a dead range** — one exported from the editor,
-hand-edited, or built by an older rigc. `A39` reports that from the artifact side
-as a key at a time no dial selects (§4.11.4); the compile refusal above is what
-stops a rig spec in this repository from producing one.
+⚠️ **An artifact can still carry a dead range** — one exported from the editor or
+hand-edited. `A39` reports that from the artifact side as a key at a time no dial
+selects (§4.11.4); the compile refusal above is what stops a rig spec from
+producing one.
 
 📌 **A slider's animation is measured in the slider's own frame** — `A39` inverts
 the mapping above and drives the bone to the value it names, rather than playing
@@ -3133,8 +2963,7 @@ the animation on a track while the slider sits at its neutral. §4.11.4 is what
 that changes and why it matters at `mix: 1`.
 
 🔸 **`scale` is emitted as its float32**, like every other number rigc writes, so
-`1/60` ships as `0.016666668` — 8e-8 relative (it was `0.016667`, 2e-5, on the
-six-decimal grid before issue #716). Invisible in the middle of the range; it
+`1/60` ships as `0.016666668` — 8e-8 relative. Invisible in the middle of the range; it
 shows at the top of it, where a 60° turn then applies at 1.00000008 s rather than
 1 s. With `loop: false` that is the last frame and harmless, with
 `loop: true` it wraps to the start. When the range comes from a *measured* ceiling
@@ -3205,7 +3034,7 @@ stops before the gate with `N mesh slot(s) emitted but the rig "X" allows 0`.
 Geometry rigc built is geometry rigc will not ship unmeasured; geometry the author
 drew is exempt, because rigc did not draw it. So `A13`'s **SKIP** means *this rig
 is unmeasured*, not *this budget is inert* — those are two code paths with one
-name, and reading the SKIP as the whole story is what issue #274 was.
+name.
 
 🔗 **`detached` is a list of forbidden parentages**, and its shape is
 `[{ "bone": …, "notUnder": …, "why"?: … }]`. `A25_DETACHED_BONE_PARENTAGE` walks
@@ -3234,20 +3063,16 @@ is the whole value of it. What the field is for is art that folds on purpose: a
 page turning over, a cloth creasing back on itself, where the reversed winding
 *is* the drawing.
 
-📌 **Nothing in this repository uses it.** `gallery/flex` did, for one leaf whose
-`why` named the issue tracking the defect rather than claiming intent; that
-tracked defect is repaired ([#313](https://github.com/firejune/rigc/issues/313))
-and the entry is gone. ⇒ An exemption whose `why` reads *"known defect, see
-#N"* is a legitimate use of the field and an honest one, but it is a loan
-against a fix, not a fix — and the thing that made it repayable was A39
-measuring the ceiling the art could actually take.
+📌 **An exemption whose `why` reads *"known defect, see #N"* is a legitimate use
+of the field and an honest one**, but it is a loan against a fix, not a fix — and
+what makes it repayable is A39 measuring the ceiling the art can actually take.
 
 🎬 **`editorRoundTrip` is the one field here that names a CONSUMER rather than a
 shape.** Write `"editorRoundTrip": true` when this rig is authored to come back
 out of the Spine editor — imported, hand-edited, exported — and
 `A41_PHYSICS_SURVIVES_EDITOR_ROUND_TRIP` refuses a physics constraint driving a
 component that editor cannot hold. `true` is the only accepted value; a `false`
-would be a key nothing reads ([#545](https://github.com/firejune/rigc/issues/545)).
+would be a key nothing reads.
 
 ⚠️ **Leaving it out is not a weaker gate, and this is the part worth reading.**
 rigc's output is not wrong here: a physics constraint driving `rotate` is valid
@@ -3260,7 +3085,7 @@ constraint and the component:
   SKIP  A41_PHYSICS_SURVIVES_EDITOR_ROUND_TRIP: the rig "look" does not declare `invariants.editorRoundTrip`, so nothing here is gated against the Spine editor. What is here: physics "whip" drives rotate, and the editor's physics model holds x and y only, so a round trip returns that constraint driving nothing at all (issue #540)
 ```
 
-📏 **Measured, not inferred** ([#540](https://github.com/firejune/rigc/issues/540)):
+📏 **Measured, not inferred:**
 three rigs, twelve constraints, predictions written before the round trip. A lone
 `y` came back and `x` + `y` together came back — the rule is membership, not arity
 — while a lone `rotate`, a lone `scaleX` and a lone `shearX` each came back driving
@@ -3273,16 +3098,13 @@ loss seen from the far side: it is what fires on the file the editor hands **bac
 draws no pixels at that key's own time is already passed over — `A39` measures
 that and says so (§4.11, and the `skipped` line in the `DEFORM` block). Declaring
 the slot instead would turn the check off at every angle where the part is fully
-visible too, which is trading a false positive for a blind spot on the same slot
-([#401](https://github.com/firejune/rigc/issues/401)). ⚠️ And land that alpha-0
-key **before** the folding key rather than on it — the frames in between are
-drawn and are gated (§4.11.3); this used to be a rule you had to follow and is
-now one the gate keeps
-([#403](https://github.com/firejune/rigc/issues/403)).
+visible too, which is trading a false positive for a blind spot on the same slot.
+⚠️ And land that alpha-0 key **before** the folding key rather than on it — the
+frames in between are drawn and are gated (§4.11.3).
 
 🎛️ **`consumerDrivenMix` names the ik and transform constraints whose mix the
-CONSUMER sets** — from code, at runtime — rather than any animation in this file
-([#784](https://github.com/firejune/rigc/issues/784)). It is
+CONSUMER sets** — from code, at runtime — rather than any animation in this file.
+It is
 `[{ "constraint": …, "type": "ik" | "transform", "why": … }]`, and it exempts that
 constraint from `A47_IK_CONSTRAINT_NOT_MUTED_THROUGHOUT` or
 `A48_TRANSFORM_CONSTRAINT_NOT_MUTED_THROUGHOUT` (§4.12). A constraint resting muted
@@ -3310,8 +3132,7 @@ spelling of `gallery/look`'s rule that a face angle is a value rather than a tim
 `spec` must be `"rigc-motion/1"`; `archetype` must equal the rig's `name`; `cut` is
 a label for the shot. Always include an `easings` object — an empty one is fine.
 
-⭐ **The file is PARSED, not cast** ([`src/motion.ts`](../src/motion.ts), issue
-#307), so a field of the wrong type is refused before any of it is compiled. Every
+⭐ **The file is PARSED, not cast** ([`src/motion.ts`](../src/motion.ts)), so a field of the wrong type is refused before any of it is compiled. Every
 one of those refusals names the file, the key path, what the value actually is and
 the spelling that works — `path/to/motion.json: \`easings."soft"\` is an array of
 3; a named easing is FOUR finite numbers …`. The split with the compile-time
@@ -3321,7 +3142,7 @@ parser; whether a name resolves against the rig, whether a bone is in that group
 whether a key's value has the right number of channels for its property needs
 something this file does not contain, and stays where it can say so.
 
-⚠️ **An unknown key is still ignored**, exactly as it is in a rig spec — a
+⚠️ **An unknown key is ignored**, exactly as it is in a rig spec — a
 misspelled `"easing"` for `"ease"` plays linear and says nothing. The two formats
 are deliberately consistent here rather than each surprising in its own way.
 
@@ -3332,11 +3153,9 @@ shows. rigc converts them per key into the absolute `(time, value)` control poin
 the JSON actually holds. Writing normalised handles into a raw `curve` instead loads
 without error and plays a different curve.
 
-**Four finite numbers, refused by name if they are not** (#307). `bezierForChannel`
-destructures four handles with no guard of its own, so `[0.42, 0, 0.58]` used to
-emit `"curve": [0.42, 0, 0.58, null]` — a curve with a hole in it, which loads,
-plays, and is not the shape the spec named. A non-numeric handle was the same
-silence one character further in.
+**Four finite numbers, refused by name if they are not.** Unchecked,
+`[0.42, 0, 0.58]` would emit `"curve": [0.42, 0, 0.58, null]` — a curve with a
+hole in it, which loads, plays, and is not the shape the spec named.
 
 ### 4.2 `setup` — the setup pose, per slot
 
@@ -3344,12 +3163,9 @@ silence one character further in.
 channels in 0..1. Both halves are refused by name: an entry that is not that object
 — `"lid_l": null`, or `"lid_l": "plate"` with the attachment name where its wrapper
 belongs — and a colour channel that is not a finite number in 0..1. The second
-spelling is the one worth knowing about, because `.attachment` on a string is
-`undefined`: it used to compile GREEN and **hide the slot**, which is the opposite
-of what was asked (#293). The guard is in the parser rather than the emit path, so
-it also covers a slot the rig declares without attachments and a slot name that
-matches nothing at all — the two corners where the emit-path version stayed silent
-(#307). Declaring a slot's setup pose here **and** on the rig slot is a
+spelling is the one worth knowing about: unchecked it would **hide the slot**,
+which is the opposite of what was asked. The check also covers a slot the rig
+declares without attachments and a slot name that matches nothing at all. Declaring a slot's setup pose here **and** on the rig slot is a
 compile error (R3). Use whichever file owns the decision: a rig that is purely
 structure puts it on the slot; a cut whose overlay mechanism is a decision about
 time puts it here.
@@ -3359,7 +3175,7 @@ time puts it here.
 | Field | Meaning |
 | --- | --- |
 | `duration` | seconds, declared and checked (R7) |
-| `loop` | a **player hint only** — skeleton JSON has no loop field, so this is not emitted and no assertion or diff measure reads it. **Optional**, and 20 of the motion specs in this repository omit it |
+| `loop` | a **player hint only** — skeleton JSON has no loop field, so this is not emitted and no assertion or diff measure reads it. **Optional** |
 | `note` | free text |
 | `tracks` | the timelines |
 | `drawOrder` | the draw-order timeline — §4.7. Not a track: it names no target |
@@ -3383,8 +3199,7 @@ resolves every member against the rig as that. So a `group` is the one target
 where the property picks the family rather than the other way round (§4.4's ⭐ is
 about the three **constraint** families, which are picked by the field), and a
 property that is in none of the three tables is refused naming the group and all
-three vocabularies rather than being read as any of them
-([#661](https://github.com/firejune/rigc/issues/661); §4.4). A group whose members
+three vocabularies rather than being read as any of them (§4.4). A group whose members
 are not all of one family is not refused as such: the first member that is not
 what the property made it is the one named.
 
@@ -3443,60 +3258,22 @@ multipliers where `1` is setup; rotation is in degrees.
 compile error** — `animation "A" bone "B" has no timeline "P" (it has: translate,
 translatex, translatey, scale, scalex, scaley, shear, shearx, sheary, rotate,
 inherit)`, §5.1's row. The eleven are the three rows above read as one list, in the order the
-message prints them, and they are the emitter's own dispatch table (`BONE_TRACKS`
-in `src/compile.ts`): `resolveTargets` asks that table which family a track
-belongs to, `compileValueTrack` writes a key out of the shape it finds there, and
-the refusal prints `Object.keys` of the same object — so what you are told a bone
-accepts is what it accepts.
-
-- Until [#656](https://github.com/firejune/rigc/issues/656) it printed no list at
-  all: the refusal read `bone "B" cannot take slot property "P"`, which named the
-  **slot** family for whatever you had written — `wobble`, `translateX`, `rgb` —
-  and told you nothing about what a bone does take. Nothing wrong reached disk
-  then either, because the dispatch was already this table; what was missing was
-  the way forward.
-- `rgba` and `attachment` are the only two names that sentence was ever right
-  about, and for those the redirect survives as a clause beside the list:
-  `. "rgba" is a slot timeline — put the name in "slot"`. It is read off
-  `SLOT_TRACKS`, so the two halves of the message cannot drift apart. A
+message prints them, and the refusal prints the same table the compiler dispatches
+on — so what you are told a bone accepts is what it accepts.
+
+- For `rgba` and `attachment` the refusal adds a redirect beside the list:
+  `. "rgba" is a slot timeline — put the name in "slot"`. A
   **constraint** property written on a bone track (`mix`, `inertia`, `position`,
   …) never reaches this refusal at all — it is refused first, by the row that
   names the field its constraint's name belongs in (§4.12).
-- **Nothing derives this page's copy of the eleven from the table.** What keeps the
-  two in step is the control that quotes the message — `RF26` in `selftest.ts` —
-  which goes red if the list ever widens without this page moving with it, and
-  `RF27` holds the slot clause the same way. The selftest's spelling census
-  (`PS144`) reads the eleven off the same message and compares them against the
-  eleven it actually poses, both ways, which is what makes the list checkable at
-  all: it was stated there too until the refusal had something to state. It was
-  ten until [#733](https://github.com/firejune/rigc/issues/733) added `inherit`,
-  and that landing is what moved `RF26`, this page and the census together.
 
 ⚠️ **A `slot` track's `property` is one of the six above, and anything else is a
 compile error** — `animation "A" slot "X" has no timeline "P" (it has:
-attachment, rgba, rgb, alpha, rgba2, rgb2)`, §5.1's row. Until
-[#650](https://github.com/firejune/rigc/issues/650) it was not: the emitter had a
-branch for `attachment` and wrote **everything else** as an rgba timeline under
-the name you gave it, so a track spelled `sequence` compiled, emitted
-`slots.X.sequence` with rgba keys, and was refused one stage later by the gate
-(`A00_ROUNDTRIP_PARSE: threw: Invalid timeline type for a slot`) — while the
-one-channel spelling of the same mistake was refused at compile as `rgba value
-needs 4 channels, got 1`, a message about a key you had not written.
-
-- The six are the emitter's own dispatch table (`SLOT_TRACKS` in
-  `src/compile.ts`), in the order `SkeletonJson.readAnimation` switches on
-  them — which makes it the format's whole slot switch: `compileTrack` reads it
-  to pick its branch, and the refusal prints `Object.keys` of the same object,
-  so what you are told a slot accepts is what it accepts.
-- **Nothing derives this page's copy of that list from the table**, and it is
-  six names long: no `DQ*`/`RD*`/`CUR*` control reads §4.4 (the only gated
-  table on this page is §3.5.2.1's, held by `RD01`–`RD06`). What keeps the two
-  in step is the control that quotes the message — `RF23` in `selftest.ts` —
-  which goes red if the accepted list ever widens without this page moving with
-  it. It did, on the day `rgba2` was added
-  ([#690](https://github.com/firejune/rigc/issues/690)) and again when `rgb`,
-  `alpha` and `rgb2` were ([#730](https://github.com/firejune/rigc/issues/730)),
-  which is the mechanism working rather than a hole in it.
+attachment, rgba, rgb, alpha, rgba2, rgb2)`, §5.1's row.
+
+- The six are in the order `SkeletonJson.readAnimation` switches on them — the
+  format's whole slot switch — and the refusal prints the table the compiler
+  dispatches on, so what you are told a slot accepts is what it accepts.
 - 🎨 **`rgb`, `alpha` and `rgb2` are the SEPARABLE colour timelines, and they
   are not spellings of `rgba`.** Each poses part of the slot's colour and leaves
   the rest exactly where it was: `rgb` writes the light colour's r g b and never
@@ -3542,7 +3319,7 @@ needs 4 channels, got 1`, a message about a key you had not written.
 - The six are every slot timeline the format has; anything else is refused
   here, and would be refused by the runtime's own reader too (`Invalid timeline
   type for a slot`). `A12_NO_DARK_COLOR` refuses `rgb2` — and `rgba2`, and the
-  slot field — in a file under the `spine-html` profile (SPEC_COVERAGE §2.1).
+  slot field — in a file under the `spine-html` profile.
   `sequence` is a timeline on an **attachment**, not on a slot — it is the
   family beside `deform`, §4.13.
 
@@ -3552,26 +3329,13 @@ and anything else is a compile error** — `animation "A" group "G" has no timel
 …)`, §5.1's row. It is the only refusal on this page that prints **three** lists,
 and the reason is §4.3's: a group's family is decided by the property, so a
 property no table claims leaves the compiler with no family to answer for. All
-three come from the objects the dispatch reads — `BONE_TRACKS`, `SLOT_TRACKS` and
-`PHYSICS_TRACKS` in `src/compile.ts` — and the refusal is raised in
-`resolveTargets`, after the group's own existence check and before any member is
-resolved against the rig.
-
-- Until [#661](https://github.com/firejune/rigc/issues/661) a group of **bones**
-  with a misspelled bone property read `animation "A" targets unknown slot "M"`:
-  with no table claiming the property the track fell through to the slot branch,
-  and what you were told was that the first member is not a slot — on a file that
-  named neither a slot nor that member. A group of **slots** got §4.4's slot row
-  instead (`slot "M" has no timeline "P" (it has: attachment, rgba, rgba2)`), which is
-  true of the member and names one family out of three on a track whose family
-  nothing had determined.
+three are the tables the compiler dispatches on, and the refusal comes after the
+group's own existence check and before any member is resolved against the rig.
+
 - **A constraint property never reaches it.** `position`, `spacing` and `time` are
   refused first with the field their constraint's name goes in (§4.12), and a
   physics timeline spelled correctly is not an error at all — a group of physics
   constraints is how several are tuned in one track.
-- `RF30`–`RF34` in `selftest.ts` quote this message; the three lists are typed
-  there rather than read off the tables, so widening any of the three without
-  moving this page turns them red.
 
 **A physics constraint's six tuning timelines override §4.6's table for the
 length of an animation.** `{ "physics": "hair", "property": "wind", "keys": […] }`
@@ -3592,21 +3356,19 @@ a delta from the constraint's own setting.
   key states a mass and the pose holds `1 / mass`, so a `mass` key of `0` is an
   infinite inverse mass — every velocity and offset is NaN from the first step.
 - **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
+  error.** `mass` must be
   `> 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
   assertion is where an import is.
-- 🔎 **Each way out of a bound has a basis, and the refusal says which**
-  ([#798](https://github.com/firejune/rigc/issues/798)). **arithmetic** means the
+- 🔎 **Each way out of a bound has a basis, and the refusal says which.**
+  **arithmetic** means the
   runtime cannot compute the value — an expression in the integrator is
   non-finite at it — and the sentence names the expression and its lines;
   **behavioural** means the runtime runs it, finitely, and the rig runs wrongly,
   so refusing it is rigc's call and the sentence says so and says what the value
-  does. Two of the eight ways out are arithmetic. The table is the
-  `PHYSICS_POSE_RULES` rows' own `basis`, verbatim, and `CUR100` holds it to them;
-  every basis is re-measured through spine-core by `T113` on every run.
+  does. Two of the eight ways out are arithmetic.
 
   | field | at rest | on a key | basis |
   | --- | --- | --- | --- |
@@ -3622,18 +3384,15 @@ a delta from the constraint's own setting.
   finite on every one. Every run-away overflows at some horizon, which is why
   `damping` above 1 is behavioural although it diverges.
 - ⚖️ **A negative `mix` is refused on a physics constraint and accepted on a
-  transform constraint, and neither is the runtime's arithmetic**
-  ([#798](https://github.com/firejune/rigc/issues/798)). [measured] both are a
+  transform constraint, and neither is the runtime's arithmetic.** [measured] both are a
   finite, mirrored scale: a physics constraint resting at `mix` −0.5 moves its
   bone by exactly the opposite of +0.5 on every step, and a transform constraint
   at `mixRotate` −0.5 rotates its bone by the negative of +0.5's. What differs is
   the range the runtime documents for each field — `PhysicsConstraintPose.mix` is
   "a percentage (0+)", `TransformConstraintPose.mixRotate` "a percentage
-  (unbounded)" — and each rule follows its own. `T114` holds the mirror and both
-  documented ranges against the runtime; `T105` holds the transform side's
-  acceptance.
+  (unbounded)" — and each rule follows its own.
 - ⚠️ **`damping`'s bound depends on the constraint's `fps`, and a rig played at
-  60 fps hides it** ([#748](https://github.com/firejune/rigc/issues/748)). The
+  60 fps hides it.** The
   decay is `damping ** (60 * step)` with `step` = `1 / fps`, so the exponent is
   exactly 1 at 60 fps, where a negative damping only flips the velocity's sign
   each step and can look like a jiggle settling. Wherever `60 / fps` is not a
@@ -3642,15 +3401,13 @@ a delta from the constraint's own setting.
   stays finite at 60 fps and at 30 (exponent 2), and is NaN within three steps of
   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
+  reason.
+- ✅ **Both ends of `damping` are inside the bound.** `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:
+  `Physics.reset` at 60, 45 and 30 fps on the generated physics fixture. ⚠️ `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
@@ -3666,7 +3423,7 @@ a delta from the constraint's own setting.
   `strength`, 0 takes the restoring term out of the velocity update and leaves
   `damping` and `inertia` applied — the offset is not pulled back *while the key
   holds*, which is "physics released" for that span, and the next key pulls it
-  back ([#727](https://github.com/firejune/rigc/issues/727)). At rest the two
+  back. At rest the two
   part ways: a `strength` of 0 is a constraint nothing pulls back, which `A23`
   refuses, and a `mix` of 0 is a constraint muted until an animation keys it
   above 0 — the next bullet. A **negative** setup `strength` is refused too, with
@@ -3674,11 +3431,9 @@ a delta from the constraint's own setting.
   added to the offset instead of taken out, so the offset is **pushed away** and
   grows — [measured] resting at −100 on the generated physics fixture it grew
   28.35× over 0.5 s with no sign change, where resting at 100 it swung back
-  through 0. `A23` reads which sentence to print off the `strength` row of
-  `PHYSICS_POSE_RULES` (its `outside` arms), and the key's refusal quotes the
-  negative arm from the same row, so the two cannot say different things about
-  one number ([#748](https://github.com/firejune/rigc/issues/748)).
-- ⚠️ **A setup `mix` of `0` is legal when some animation keys it above 0** ([#743](https://github.com/firejune/rigc/issues/743)).
+  through 0. `A23` and the key's refusal read that sentence from one source, so
+  the two cannot say different things about one number.
+- ⚠️ **A setup `mix` of `0` is legal when some animation keys it above 0.**
   A constraint muted *at rest* is a rig whose physics is off until an animation
   switches it on, which is a design rather than the silence `A23` was built for.
   What `A23` refuses is the constraint nothing rescues: muted at setup and keyed
@@ -3690,10 +3445,10 @@ a delta from the constraint's own setting.
   "Keyed above 0" means **any value the timeline poses**, which includes a
   Bezier between two keys of 0 whose handles lie above 0: the runtime
   interpolates through the curve's samples, not between the keys, and such a
-  pair moves the bone ([#752](https://github.com/firejune/rigc/issues/752)). The
+  pair moves the bone. The
   same reading is `A36`'s and `A37`'s (§4.12).
 - 📏 **What a `strength` key of `0` costs, measured through spine-core** on the
-  generated overlay fixture, stepping at 60 fps from `Physics.reset` (#727). With
+  generated overlay fixture, stepping at 60 fps from `Physics.reset`. With
   no wind or gravity the offset coasts to a limit rather than running away — a
   0.5 s release and a 2.0 s release end **0.95 %** apart — and the restoring key
   takes it from 5.5063 back under 0.01 in **54 steps**. With `gravity -40` pulling,
@@ -3705,8 +3460,7 @@ a delta from the constraint's own setting.
   the first sub-step and **still NaN after the restoring key**, and a keyed
   `damping` of `2` was still 6.9e4 two seconds later.
 
-**`"physics": "*"` is the physics timeline that names no constraint**
-([#726](https://github.com/firejune/rigc/issues/726)). The skeleton file writes it
+**`"physics": "*"` is the physics timeline that names no constraint.** The skeleton file writes it
 under the empty name — `animations.<a>.physics[""]`, which `SkeletonJson` loads as
 constraint index `-1` without looking anything up — and the runtime then applies it
 to every active physics constraint whose own data declares the keyed property
@@ -3759,14 +3513,7 @@ consumer's, decided by dressing the skeleton rather than by the animation.
   refusal says which skins were searched and what the slot does have (§5.1).
 - A rig with **no `default` skin at all** — every attachment in named skins,
   which is the shape an editor export of a multi-skin character gives back — is
-  therefore a rig whose attachment keys work. Until
-  [#695](https://github.com/firejune/rigc/issues/695) it was not: keys were
-  checked against the default skin alone, so a named-skin name was refused as
-  unknown, and a rig with no default skin had **every** attachment key refused,
-  including ones whose art is in the first named skin. The setup pose resolved
-  across skins the whole time (§4.2), so the two halves of one slot disagreed —
-  `slots[].attachment: "plain"` was accepted and a key naming `plain` on that
-  same slot was not.
+  therefore a rig whose attachment keys work.
 - ⚠️ **A `deform` track is the other way round and names its skin outright**
   (§4.11.5), because the format keys a deform timeline on a `skin/slot/attachment`
   triple and a deform run is geometry for one attachment object. An attachment
@@ -3782,7 +3529,7 @@ consumer's, decided by dressing the skeleton rather than by the animation.
 - **Key times are emitted as float32s like every other number, and never stored
   LATER than you wrote them.** Every emitted number is the shortest decimal naming
   its float32 — the text the editor writes, and the precision the runtime keeps,
-  because `spine-core` reads a timeline's frames into a `Float32Array` (issue #716).
+  because `spine-core` reads a timeline's frames into a `Float32Array`.
   A time that already names a float — `0.5`, `0.2`, the editor's `1.4333333` — is
   written as you wrote it. A time that does not — `2/12` computed in doubles, a key
   moved by `lag` or `stagger` — steps to the **largest float not above it**, never
@@ -3792,9 +3539,7 @@ consumer's, decided by dressing the skeleton rather than by the animation.
   *larger* than either, so a key stored there is applied at sample **3** of a 12 fps
   playback and not sample 2 — a whole frame late, with nothing raised. On a
   **stepped** timeline (an attachment timeline always is) that is the wrong picture
-  rather than a slightly wrong value: the spineboy run's muzzle flare fired a frame
-  late for exactly this, on the six-decimal grid rigc emitted until #716, until the
-  run's own frame check caught it (issue #99). Stepping down cannot do that; the
+  rather than a slightly wrong value. Stepping down cannot do that; the
   worst it can do is store a key one float early — 1.5e-8 s at 1/6 s — on the sample
   it was written for. ⚠️ What this does **not** protect you from is rounding your
   own times before you write them — write `2/12`, not `0.1667`, and let the compiler
@@ -3808,13 +3553,11 @@ consumer's, decided by dressing the skeleton rather than by the animation.
   and a stepped key there sits above the sample that was meant to see it. On an
   interpolated timeline that costs a few ULPs of value and nothing else. On a
   **stepped** one it is the whole frame — and on the last sample it is the whole
-  event, because there is no later sample to catch it. Measured on rung 5's 6.5 s
-  shot at 12 fps: **13 of its 78 sample times are affected** (f6, f15, f18, f21, f24,
+  event, because there is no later sample to catch it. Measured on a 6.5 s shot
+  at 12 fps: **13 of its 78 sample times are affected** (f6, f15, f18, f21, f24,
   f27, f60, f63, f66, f69, f72, f75, f78), and an attachment key written at the
   declared duration `6.5` never fired at all against an accumulated
-  `6.499999999999994` — which read as a frame-change disagreement the pose series had
-  already fixed, and cost that run three builds
-  ([`2026-08-26-rung5-1`](https://github.com/firejune/rigc/blob/main/bench/runs/2026-08-26-rung5-1/LOOP.md), §8). ⇒ **For a
+  `6.499999999999994`. ⇒ **For a
   stepped timeline, write a time a little below `T` — `T − 1e-6` still works, at
   any magnitude — rather than `T`.** What makes it work is not the size of the step:
   any time below `T` is stored on a float below `T`, because a time that names a
@@ -3831,10 +3574,10 @@ consumer's, decided by dressing the skeleton rather than by the animation.
   step at the duration — 4.8e-7 s at 5 s, 3.8e-6 s at 32 s — which is the most a
   key you put exactly *on* a duration the float cannot hold is stored past it, so
   such a key is fine. R7's frame of slack does not apply in this direction and
-  would not see this: rung 6 rounded its key times to 4 dp somewhere upstream, its
-  one-frame reveal landed 0.000034 s past a 68/12 s duration, another track was
-  already sitting on the declared duration so the animation's *longest* key time
-  looked right — and the reveal never appeared. If you want a key on the last
+  would not see this: key times rounded to 4 dp upstream put a one-frame reveal
+  0.000034 s past a 68/12 s duration while another track sat on the declared
+  duration, so the animation's *longest* key time looked right — and the reveal
+  never appeared. If you want a key on the last
   sample, write the duration's own value; if you want the animation to run longer,
   say so in `duration`.
 - `ease` names an entry of `easings`, or the literal `"stepped"`. Absent = linear —
@@ -3847,7 +3590,7 @@ consumer's, decided by dressing the skeleton rather than by the animation.
   key equals the next key's *as emitted* — a `translate` whose x moves and whose y
   does not is **not** a hold — the curve would run from a value to the same value and
   draw nothing, and the editor writes that segment as `"curve": "stepped"`. So rigc
-  does too (§10.4, issue #369): the frames are byte-identical either way, and a build
+  does too (§10.4): the frames are byte-identical either way, and a build
   stops differing from its own editor export on `diff`'s `animations.curve_kinds`. A
   raw `curve` is **not** rewritten — it states the file's own numbers verbatim, and
   the editor's own exports do carry beziers over holds, so a transcription has to be
@@ -3863,12 +3606,10 @@ consumer's, decided by dressing the skeleton rather than by the animation.
 ### 4.5.1 A group track's per-member values — a map, or a model
 
 ⭐ **`groups` keys several bones identically, and on a face the whole content of
-the motion is that each part gets a *different* number.** That is the complaint
-[#295](https://github.com/firejune/rigc/issues/295) filed. `gallery/portrait`'s
-held 12° yaw was **20 tracks**, sixteen of them the same two properties on six
-sibling bones — identical times, identical easings, identical key counts, six
-different values — and exactly **one** of the twenty was a `groups` entry, the
-pair that happened to share `cos t`.
+the motion is that each part gets a *different* number.** `gallery/portrait`'s
+held 12° yaw, written as plain tracks, is the same two properties on six sibling
+bones — identical times, identical easings, identical key counts, six different
+values.
 
 Two spellings land, and **which one is right depends on whether the numbers are
 decisions or arithmetic.**
@@ -3884,9 +3625,8 @@ would be for that one member, so nothing about the value shapes in §4.4 changes
     { "t": 2.2,  "v": [0] } ] }
 ```
 
-A non-map `v` keeps meaning what it always meant — every member gets it — so no
-existing spec changes, and the emitted file is **byte for byte** the one the six
-separate tracks produced. Reach for this when the six numbers are six
+A non-map `v` means every member gets it, and the emitted file is **byte for
+byte** the one six separate tracks produce. Reach for this when the six numbers are six
 **judgements**: hand-picked swings on a row of hanging locks, a decided offset
 per part.
 
@@ -3905,9 +3645,8 @@ Same move as §4.11.1 on the bone half of the same turn:
 
 ⭐ **The depth table is the reason this is worth more than the map, and it is not
 the line count.** FACE §2's sharp edge is that **`x` is in the file and `z` is
-not** — `grep -c '"z"'` over the worked example's two specs returned `0` and `0`,
-and every depth that produced every number lived only in a README beside them. A
-`derive` key puts them in the file that uses them, and FACE §3's whole argument
+not** — with plain values, every depth that produced every number lives outside
+the specs. A `derive` key puts them in the file that uses them, and FACE §3's whole argument
 is that a **depth** is the decision while a **residual** is not.
 
 **The two kinds, and the property picks the projection:**
@@ -3933,8 +3672,7 @@ a head swing the other way (FACE §2). That sign is the one parameter here no
 assertion can check, so the closed form is the arbiter: a part with
 `depth > carried` gets a **negative** residual, and FACE §3 makes exactly that
 the nose diagnostic — *if the nose's residual is not negative, the depths are
-wrong*. ([#351](https://github.com/firejune/rigc/issues/351) was this sentence
-missing here and stated backwards in the field reference.)
+wrong*.
 
 `carried`
 (default 0) is **the depth whose shift a parent bone already applies** — FACE
@@ -3988,8 +3726,8 @@ iris counter-scale is `1/scaleX` of the socket, and it stays two ordinary
 `groups` entries with one shared value each — because a counter-scale belongs to
 the **socket**, not to the part: `spark_l` at local `x = −11` takes the same
 number as `iris_l` at `0`. A shared value on a group is the correct statement of
-that, and forcing it into a per-member model would have been a worse spec that
-happened to use the new field.
+that, and forcing it into a per-member model would be a worse spec that merely
+used the field.
 
 🔭 **Deliberately not built:** a per-member `v` on a track that names no group (a
 value map needs members to name); per-member **easings** or key **times** (the
@@ -4037,7 +3775,7 @@ group members  (the per-member values of one track, side by side — issue #295)
 that face, because it is the only feature in front of the skull surface — and
 FACE §3 makes it the diagnostic: *if the nose's residual is not negative, the
 depths are wrong.* That check is arithmetic rather than a render, and this block
-is where it is now legible.
+is where it is legible.
 
 **It quotes; it does not re-derive.** Every value is the one the compiler
 emitted, so the block and the artifact cannot disagree — a report that evaluated
@@ -4058,34 +3796,30 @@ 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 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` 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)).
+never settles — both are `A23`, here and on every timeline key that states them;
+a `damping` below 0 is refused as well, and whether it is NaN depends on `fps` —
+§4.4. `damping` is `[0, 1]` with both ends in: `1` never decays and `0` zeroes the
+velocity on every step, both finite at every rate.
 ⚠️ 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
+asked for, which §4.4 states with the measurement behind it. A negative `strength` is
 `A23` here and on a key, and here its sentence is its own: the offset is pushed
-away and grows ([#748](https://github.com/firejune/rigc/issues/748)). `mix: 0` is the one value
+away and grows. `mix: 0` is the one value
 here an animation can answer for: it rests the constraint **muted**, which is
 legal, and `A23` names it only when no timeline in any animation keys that `mix`
-above 0 — on a key it is the mute for a span (§4.4, [#743](https://github.com/firejune/rigc/issues/743)). None of the
+above 0 — on a key it is the mute for a span (§4.4). None of the
 three is a compile error — a setup value this table states reaches the gate, where the whole
 file can be read; it is a **key** outside its bound that `build` refuses (§4.4). Every field but `bone` and `note` must be a finite
-number: a non-number is rounded to `NaN` and emitted as `null`, which the runtime
-reads as **zero**, so `"mass": "heavy"` used to ship a constraint that never
-settles with no word from anybody (#307).
+number: a non-number would reach the file as `null`, which the runtime reads as
+**zero**, so `"mass": "heavy"` would ship a constraint that never settles.
 
 `mix` is a player-side `AnimationStateData` config and is **not** emitted into
-skeleton JSON — which is why nothing looked at it until the parser did: it is
+skeleton JSON, so the parser is the only check it gets: it is
 `{ "default": <seconds>, "pairs"?: [["<from>", "<to>", <seconds>], …] }`, and a
-`default` that is not a number passed the compiler, the gate and the round trip
-before becoming a `NaN` mix duration in the player.
+`default` that is not a number would pass the gate and the round trip before
+becoming a `NaN` mix duration in the player.
 
 ### 4.7 `drawOrder` — reordering the slots over time
 
@@ -4228,11 +3962,9 @@ here was measured off a real rig. Copy the shape, not the values.
   the constraint (`SkeletonJson:155`) and once on **every timeline key**
   (`:912`) — so a key that omits `bendPositive` does not inherit the constraint's
   value, it asserts `true`. A rig declaring `bendPositive: false` under a timeline
-  that keys only `mix` therefore bent the *other* way for the whole animation,
-  with the field still in the file and inert: four builds differing only in those
-  values posed one pose, and the gate was green throughout (issue #273). rigc now
-  stamps the rig's value onto every emitted key, so the declaration reaches the
-  runtime. **Stating a flag on every key still overrides the rig** — the format
+  that keys only `mix` would therefore bend the *other* way for the whole
+  animation, with the field still in the file and inert. So rigc stamps the rig's
+  value onto every emitted key, and the declaration reaches the runtime. **Stating a flag on every key still overrides the rig** — the format
   keys them per key on purpose, a bend that flips partway through is a real thing
   to write, and it is what the editor's own export does.
 - 🔁 **A spec that came out of `ingest` (§0.3) states all three on every key, and
@@ -4488,8 +4220,7 @@ emitted file, measuring the array's length from the attachment rather than assum
 an encoding.
 
 📌 **A run is not required to be an even number of numbers, and it is not required
-to start on an even index.** Two rows stood here saying otherwise until issue
-#576. Nothing in either reader aligns a run to a pair: `SkeletonJson` does
+to start on an even index.** Nothing in either reader aligns a run to a pair: `SkeletonJson` does
 `Utils.arrayCopy(vertices, 0, deform, offset, vertices.length)` — a raw copy, at
 the raw index the key gives — and `SkeletonBinary` reads a count and a start and
 fills `for (let v = start; v < end; v++)`. So a run may begin and end mid-pair,
@@ -4499,24 +4230,21 @@ the whole delta minus one leading zero.
 
 ⭐ **An odd run's last number is an x with no y beside it, and that is a
 statement, not an accident.** It moves that vertex in x and leaves its y at the
-setup value, because the parser copies your numbers and touches nothing else. It
-is also the reason the rule could not stay as an authoring convenience: padding a
-`0` to make the run even *changes what plays* wherever that setup y is non-zero,
-so there is no second spelling of such a key — refusing it would mean no
-transcription of that file can be written in this spec at all. `A35` reached the
-same conclusion from the other side in issue #262, and between that fix and this
-one the two halves of rigc disagreed about what the format holds.
-
-⚠️ What you lose with those rows is a typo filter: `offset: 3` written where
-`fromVertex: 3` was meant now compiles. It always half-did — `offset: 4` meant as
-vertex 4 lands on vertex 2 and was never refused — so read the field name twice.
+setup value, because the parser copies your numbers and touches nothing else.
+Padding a `0` to make the run even *changes what plays* wherever that setup y is
+non-zero, so there is no second spelling of such a key — which is why an odd run
+is accepted rather than refused.
+
+⚠️ What that costs is a typo filter: `offset: 3` written where `fromVertex: 3` was
+meant compiles, as `offset: 4` meant as vertex 4 lands on vertex 2 — so read the
+field name twice.
 `offset` is an index into the deform array; `fromVertex` is a vertex.
 
 🖼️ **Worked examples, and they use a deform for four different things** — all
 four are repository material rather than part of the published package, so the
 links go to GitHub.
 [`gallery/squash`](https://github.com/firejune/rigc/tree/main/gallery/squash) — a 9-vertex ball squashed about its contact point,
-from the two affine transforms its keys now **state**.
+from the two affine transforms its keys **state**.
 [`gallery/portrait`](https://github.com/firejune/rigc/tree/main/gallery/portrait) — a 2.5D head turn, where the keys are the
 **projection of a yaw** rather than a squash: two grid meshes whose columns are
 placed to sample a cosine, and a measured account of the angle past which the
@@ -4545,12 +4273,10 @@ build.
 half: the key names a transform, the compiler evaluates it over the attachment's
 own setup geometry, and the emitted file carries the numbers.
 
-The case that filed it ([#294](https://github.com/firejune/rigc/issues/294)):
-`gallery/portrait`'s held 12° head yaw was **160 hand-written vertex offsets
-across 8 keys**, and not one of them was a judgement — every one is
-`x·(cos t − 1) − z·sin t` at a different column (FACE §1). A second angle was a
-second full table, which is why that example's own angle sweep needed a
-throwaway script that never made it into the repository. It is now four lines:
+`gallery/portrait`'s held 12° head yaw, written as a table, is **160 vertex
+offsets across 8 keys**, and not one of them is a judgement — every one is
+`x·(cos t − 1) − z·sin t` at a different column (FACE §1), and a second angle is
+a second full table. As a model it is four lines:
 
 ```json
 "deform": [
@@ -4591,8 +4317,7 @@ convention:
 **It covers every vertex, always.** A transform is a model of the attachment, not
 an edit of part of it, so it starts at deform index 0 and runs to the end — which
 is why `fromVertex` and `offset` are refused beside it. A model applied to part
-of a run leaves a **step at the run's edge**, and that is one half of the defect
-[#313](https://github.com/firejune/rigc/issues/313) records. If you want a
+of a run leaves a **step at the run's edge**. If you want a
 partial run, write it.
 
 **There is no `parallax` kind, and the reason is worth stating.** A pure depth
@@ -4619,8 +4344,7 @@ parameters that key states, and what happens between two keys is still the
 timeline's own single 0..1 blend channel. Sweeping an angle is editing one number
 per key.
 
-**It works on a weighted attachment, and reads world coordinates there**
-([#389](https://github.com/firejune/rigc/issues/389)). On an unweighted
+**It works on a weighted attachment, and reads world coordinates there.** On an unweighted
 attachment the deform array is one `x, y` per vertex in the slot bone's space,
 and the model is evaluated in that space. The same is true of a weighted
 attachment while every vertex has exactly one bone and they all share it — the
@@ -4660,8 +4384,7 @@ consequences. One kind is the exception and it is an exception with a proof:
 `affine` refuses a determinant at or below zero, and above zero a positive
 determinant means no triangle **can** reverse.
 
-**A model that evaluates to nothing is refused too**
-([#350](https://github.com/firejune/rigc/issues/350)). Every parameter can be
+**A model that evaluates to nothing is refused too.** Every parameter can be
 individually legal and the model still come out as a **run of zeros** — a `wave`
 whose wavelength puts every vertex on a zero crossing, a `bend` over a span the
 part barely enters. The key then claims a deformation, emits the identity and
@@ -4714,19 +4437,17 @@ like every other number, so the same spec emits the same bytes and
 `A18_DETERMINISTIC_EMIT` proves it on a second compile. The grid is absolute on
 purpose: a model's identities — a wave sampled on its zero crossings, a whole
 revolution — are exact zeros float64 misses by ~1e-16, and the refusal of a key
-that states a deformation and evaluates to nothing is decided on it (issue #350);
+that states a deformation and evaluates to nothing is decided on it;
 a float32 alone is relative and has no zero to land on. The runtime then loads
 the numbers into a `Float32Array`, which is equally true of a hand-written table —
-the difference the generator makes is that the numbers now agree with a stated
+the difference the generator makes is that the numbers agree with a stated
 model instead of with a transcription.
 
-🔭 **Both adjacent asks have since landed.**
-[#295](https://github.com/firejune/rigc/issues/295) was the same complaint about
-a different table — the **bone** tracks of the same turn, where the missing
-number is a depth rather than a vertex — and **§4.5.1** is that construct: a
-`derive` kind on a group track, under the same rules as this one. The per-key
-`DEFORM` report block ([#316](https://github.com/firejune/rigc/issues/316))
-quotes the model above rather than re-evaluating it — **§4.11.2**.
+🔭 **The same construct covers the bone half of the turn.** The **bone** tracks of
+the same turn, where the missing number is a depth rather than a vertex, take a
+`derive` kind on a group track, under the same rules as this one — **§4.5.1**. The
+per-key `DEFORM` report block quotes the model above rather than re-evaluating it
+— **§4.11.2**.
 
 ---
 
@@ -4779,7 +4500,7 @@ deform  (what each key does to the geometry — figures with names, never a bar;
 📌 **The frame is the posed one, and the denominator is 1.000 by definition.**
 Both sides of every comparison are taken at the key's own time with the animation
 applied — the deformed mesh against **the same posed bones with the deform
-cleared**. Setup bones were tried and are wrong in principle: a weighted mesh's
+cleared**. Setup bones would be wrong in principle: a weighted mesh's
 offsets are authored in bone space against the pose they land in. So every ratio
 is *the deform's own contribution*, and a `(setup 1.000)` column beside it would
 be printing the definition. It is also what makes a **mirrored** slot bone a
@@ -4863,18 +4584,14 @@ and displaces `x` over row-major quads preserves every signed area exactly.
 ### 4.11.3 The times no key lands on — `A39` between two keys
 
 🚨 **Your keys are not where the runtime is.** It interpolates between them, so a
-deform that is inside its fold angle at *every* key can be past it in between —
-and until issue
-[#403](https://github.com/firejune/rigc/issues/403) nothing looked there. The
-reachable version of that was the fade above: land the alpha-0 key **on** the
+deform that is inside its fold angle at *every* key can be past it in between.
+The reachable version of that is the fade above: land the alpha-0 key **on** the
 folding key and every key is honest — that one really does draw nothing — while
 the frames just before it are drawn, nearly folded, and land on no key at all. On
-the turn probe that is **8 reversed triangles at alpha 0.20, gating green**.
+the turn probe that is **8 reversed triangles at alpha 0.20**.
 
-⇒ `A39` now scans every interval between two consecutive deform keys as well, and
-refuses one with its own sentence. No spec this repository ships produces one — the
-rig it was written from is a probe `selftest.ts` generates and nothing else can
-invoke — so the sentence is described here rather than transcribed.
+⇒ `A39` scans every interval between two consecutive deform keys as well, and
+refuses one with its own sentence.
 
 **What it carries**, in the order it says it: `BETWEEN key <i> (t=…s) and key <j>
 (t=…s)` where a key refusal puts one index; the time the closed form solved for, and
@@ -4887,8 +4604,6 @@ that same instant, present only where it is not 1; and the ways out — for an
 interpolating span the four the table below gives, the fade one among them only
 where the alpha is not 1, and for a stepped one the key it holds instead, with
 `invariants.deformMayFold` the last resort either way.
-[`src/validate.ts`](../src/validate.ts) builds it, beside the key sentence §4.11.2
-quotes.
 
 **What to change when you see it**, in the order worth trying:
 
@@ -4942,8 +4657,7 @@ means one thing: played on track 0. **An animation a `slider` applies (§3.5.2)
 never played that way** — spine-core says so in `SkeletonData.findSliderAnimations`
 — and posing it as though it were is a frame no playthrough contains. The dial
 picks the time, so **the key's time and the applied time are the same number by
-construction**; measuring them independently was issue
-[#407](https://github.com/firejune/rigc/issues/407), and it refused a correct rig.
+construction**, and measuring them independently would refuse a correct rig.
 
 ⇒ For every deform key of an animation some slider applies, `A39` **inverts that
 slider's own mapping** and drives its bone until the runtime selects this key's
@@ -4954,9 +4668,7 @@ time  = to + (value − from) × scale        the slider's mapping (§3.5.2)
 value = from + (time − to) / scale         what A39 sets the dial to
 ```
 
-🔒 **The `DEFORM` block prints the frame on every key**, because the derivation
-changed and a block that went on printing the same figures under a changed meaning
-would be worse than the red it replaced. `gallery/look`'s `turn` is the animation
+🔒 **The `DEFORM` block prints the frame on every key.** `gallery/look`'s `turn` is the animation
 a slider applies, and this is one of its keys:
 
 ```bash
@@ -4976,24 +4688,23 @@ dial and not reached at all through another.
 
 **Three consequences worth knowing before you build a rig like this:**
 
-- ⭐ **A slider at `mix: 1` in setup no longer forces the older idiom.** Muting at
-  setup and keying `slider.<name>.mix` from a playing animation (§4.12) is still
-  legitimate, but it is no longer the only way to keep `A39` honest about a slot
-  the animation itself fades — and it costs `A40_SLIDERS_COMPOSE_ON_A_SHARED_TARGET`,
+- ⭐ **A slider may rest at `mix: 1` in setup.** Muting at setup and keying
+  `slider.<name>.mix` from a playing animation (§4.12) is legitimate too, but it
+  is not needed to keep `A39` honest about a slot the animation itself fades —
+  and it costs `A40_SLIDERS_COMPOSE_ON_A_SHARED_TARGET`,
   which excludes a slider below full authority. A slider muted at setup is **not**
   a way in: `Slider.update` returns before it reads the bone, so its animation
   keeps the track frame.
 - **Two sliders applying one animation are two frames**, and both are measured.
   A fold only one dial can reach is still a fold.
 - ⚠️ **A key at a time no dial can select is named, not passed.** The cause is
-  [#405](https://github.com/firejune/rigc/issues/405)'s wrap: `FromRotate.value`
+  the wrap: `FromRotate.value`
   under `local: false` is an `atan2` ending `if (value < 0) value += 360`, so
   **`[0, 360]` is the whole of its range** and a mapping needing anything outside
-  it selects nothing. 🚨 A **rig spec** can no longer ask for one — the compiler
-  refuses both ends of that circle (§3.5.2), the low one since #405 and the high
-  one since [#417](https://github.com/firejune/rigc/issues/417) — but an
-  **artifact** can, because it may have come from the editor, from a hand edit or
-  from an older rigc, and this is the surface that reads what actually shipped.
+  it selects nothing. 🚨 A **rig spec** cannot ask for one — the compiler refuses
+  both ends of that circle (§3.5.2) — but an **artifact** can, because it may have
+  come from the editor or from a hand edit, and this is the surface that reads
+  what actually shipped.
   `A39` measures the frame the runtime *does* land on, leaves the key out of
   `deformKeysMeasured`, and names it:
 
@@ -5043,10 +4754,8 @@ the line says so rather than picking one silently.**
   tie. ⛔ Neither case is a refusal and neither is guessed past — an ambiguous
   discovery is a thing to report.
 
-**And a `build` says it too, on `A39`'s stats line**
-([#427](https://github.com/firejune/rigc/issues/427)) — because `explain` is not
-the loop you run, and until this the whole finding lived on a line only `explain`
-prints. Nothing appears on a rig where the two answers agreed, which is every
+**And a `build` says it too, on `A39`'s stats line** — because `explain` is not
+the loop you run. Nothing appears on a rig where the two answers agreed, which is every
 `local: true` slider and every gallery example:
 
 ```
@@ -5068,8 +4777,8 @@ deformDialsDisagreed=1 deformDialDisagreed=dial|artifact:knob.x@2.321e-8|reaches
 - A **tie** never carries `probe:`, `reaches:` or `outside:`, and never counts as a
   disagreement. There is one belief there, not two.
 
-**And `explain`'s rollup carries it too, with the breadcrumb its neighbours have**
-([#440](https://github.com/firejune/rigc/issues/440)). The per-key `frame` lines
+**And `explain`'s rollup carries it too, with the breadcrumb its neighbours have.**
+The per-key `frame` lines
 say it once each; the rollup says it once per animation, and ends by naming the
 two readings a `build` prints it under — because they differ by one letter, and a
 breadcrumb naming only one would send a reader to grep for the other:
@@ -5078,10 +4787,8 @@ breadcrumb naming only one would send a reader to grep for the other:
   ..                     1 dial(s) the skeleton and the probe disagree about: the skeleton reads knob.x and the probe drives knob.y, 2 key time(s) outside what the skeleton's own field reaches  <- A39 counts them as deformDialsDisagreed and spells them out as deformDialDisagreed
 ```
 
-The count after `outside` is the length of the stats line's own `outside:` list,
-and `deformDialsDisagreed` / `deformDialDisagreed` are checked against the keys
-`A39` really printed rather than restated — `DW34`. An agreed dial adds no line
-(`DW35`) and a **tie** is never rolled up as a disagreement (`DW36`).
+The count after `outside` is the length of the stats line's own `outside:` list.
+An agreed dial adds no line, and a **tie** is never rolled up as a disagreement.
 
 ⛔ **None of it refuses a build**, and the reason is measured rather than chosen.
 The field the survey drives is the largest response the probe found, so its reach
@@ -5109,33 +4816,21 @@ records that, so a slider-applied animation is measured in its slider frames onl
 §4.11 opens on the triple: a deform timeline is the only one keyed on
 **skin / slot / attachment**. So the skin is not context around the key, it is a
 third of the key's own address — and every pose `A39` and the `DEFORM` block take
-is now taken with **that skin worn**
-([#583](https://github.com/firejune/rigc/issues/583)). You do not ask for it and
-there is no flag: the skin comes out of the timeline.
-
-🚨 **It used to wear nothing at all**, which is `spine-core`'s own initial state
-and the same one `check` reports as `no skin set (the default skin alone)`
-(§9) — every slot resolved through `SkeletonData.defaultSkin` and nothing else.
-Move a deformed mesh into a named skin, which the format not only allows but keys
-the timeline on, and the slot showed **no attachment**. This is what
-`gallery/squash`'s ball printed with its one mesh moved into a skin `suit`, on
-every one of its five keys, before #583:
-
-```
-  DEFORM  bounce  suit/ball/ball  key 1  t=0.340000  transform affine  scale=[0.88, 1.16]
-          skipped    A39 reads no winding off this key: the slot shows no attachment at all at this
-                     time, not this mesh, so the runtime applies no deform to it here and draws
-                     none of it — a triangle that draws no pixels cannot draw them backwards
-```
-
-— `A39` went **PASS → SKIP** on a rig whose only edit was which skin one mesh sat
-in, in a sentence that reads as a verdict on that rig. Worn, the same build
-reports every figure the default-skin one does, to the last digit, and `A39` gates
-it: the two `DEFORM` blocks differ in the skin of the triple and in nothing else.
+is taken with **that skin worn**. You do not ask for it and there is no flag: the
+skin comes out of the timeline.
+
+🚨 **Wearing no skin would measure a named-skin mesh as drawing nothing.** That is
+`spine-core`'s own initial state and the one `check` reports as
+`no skin set (the default skin alone)` (§9): every slot resolves through `SkeletonData.defaultSkin`
+and nothing else, so a deformed mesh in a named skin — which the format not only
+allows but keys the timeline on — would show **no attachment**. Worn, a build with
+its mesh in a named skin reports every figure the default-skin one does, to the
+last digit, and `A39` gates it: the two `DEFORM` blocks differ in the skin of the
+triple and in nothing else.
 
 **Two things follow, and one of them is not about art:**
 
-- ⚠️ **A "nothing is drawn" sentence now names the skin it was measured in** —
+- ⚠️ **A "nothing is drawn" sentence names the skin it was measured in** —
   `the slot shows attachment "away" at this time, with skin "suit" worn, not this
   mesh …`. It is on the *shows-something-else* branch only, because that is the
   branch a skin decides; an alpha is read off the pose and has no skin in it. The
@@ -5145,12 +4840,8 @@ it: the two `DEFORM` blocks differ in the skin of the triple and in nothing else
   `Skeleton.setSkin` calls `updateCache`, which leaves a `skinRequired` bone
   inactive and a `skinRequired` constraint out of the update cache under any skin
   that does not list it. So a **slider** dressed into the same skin as the mesh
-  it drives used to be measured with itself switched off, and failed in two ways
-  depending on its `local` flag: a world-read property never moved, so the frame
-  was reported as *"played on a track"* — an animation a slider is the only way
-  into (§4.11.4) — while a local-read one kept its mapping but never left
-  `SliderPose.time` 0, so every key came back as *"at a time no dial selects"*.
-  Both now reach their own key times.
+  it drives is switched on while that mesh is measured, and reaches its own key
+  times (§4.11.4).
 
 ⛔ **What it does not do is try every skin.** `Attachment.timelineSlots` lets one
 deform reach a second slot — a linked mesh with `inheritTimelines` — and that copy
@@ -5209,23 +4900,19 @@ so `v` is three numbers and not one.
 constraint on from an animation is the idiom (§4.10), so `A36`/`A37` only object to
 all-zero mixes when **no** animation keys that constraint's `mix` **above 0**. If
 you mute one at setup, key it up somewhere. `A23` asks the same question of a
-physics constraint ([#743](https://github.com/firejune/rigc/issues/743)), and the
-three share one reading ([#752](https://github.com/firejune/rigc/issues/752)): the
+physics constraint, and the three share one reading: the
 key **values** the loaded timeline poses, so a `mix` timeline keying 0 only is not a
 rescue, and a Bezier between two keys of 0 whose handles lie above 0 is. A path
 constraint is switched on by a key posing **any one** of its three mixes above 0,
 because `PathConstraint.update` returns only when all three are 0. [measured] on
 generated fixtures, a path constraint and a slider muted at rest and keyed to 0
-only pose every bone exactly where the same rig with no mix timeline does, and until
-#752 both passed. `A23` alone also counts the unnamed global timeline for every
+only pose every bone exactly where the same rig with no mix timeline does. `A23` alone also counts the unnamed global timeline for every
 constraint declaring `mixGlobal`, since only the physics family has one. The refusal
 says both halves — `path constraint "P" has mixRotate 0, mixX 0 and mixY 0 at setup
 and none of the 2 animations keys its mix above 0; …` — and names both repairs.
 
-⚠️ **The same question of an `ik` and a `transform` constraint is `A47` and `A48`**
-([#765](https://github.com/firejune/rigc/issues/765)); until then no assertion asked
-it, and a rig resting either kind muted with nothing keying it gated green with 0
-failures. [measured] on generated fixtures, an ik at `mix` 0 and a transform at
+⚠️ **The same question of an `ik` and a `transform` constraint is `A47` and `A48`.**
+[measured] on generated fixtures, an ik at `mix` 0 and a transform at
 every mix 0, each with nothing keying it and each keyed to 0 only, pose every bone
 exactly where the same rig with no constraint does. They read the timelines through
 the same helper as `A23`/`A36`/`A37`, so a lifted Bezier between two keys of 0 is a
@@ -5253,11 +4940,9 @@ its mix, in the rig spec as invariants.consumerDrivenMix: [{ "constraint": "reac
 "type": "ik", "why": … }]`. A rig resting at 0 and keyed up by the animation that
 needs it — spineboy's aim — is refused by neither.
 
-🎛️ **The third door is for a dial the file cannot show turning**
-([#784](https://github.com/firejune/rigc/issues/784)). A constraint resting muted
-that nothing keys up is either a leftover or a mix a game sets from code, and the two
-export as the same bytes — a production skeleton's rebuild was refused for exactly
-that, over an ik its game switches on at runtime. `invariants.consumerDrivenMix`
+🎛️ **The third door is for a dial the file cannot show turning.** A constraint
+resting muted that nothing keys up is either a leftover or a mix a game sets from
+code, and the two export as the same bytes. `invariants.consumerDrivenMix`
 (§3.7) is the statement the file cannot make, and what it buys is a **SKIP by name,
 never a pass**: the file still shows nothing moving the constraint.
 
@@ -5369,16 +5054,14 @@ first is a **shape** refusal from a spec parser — `parseRigSpec`
 compiled, and ask only what the one file in front of them can answer. Every
 `parseMotionSpec` refusal reads `<file>: \`<key path>\` is <what it actually is>;
 <the spelling that works>`, so its whole wave is **one row per FIELD** rather than
-one per message. (The rig spec's parser predates the convention and its messages
-are prose, so they sit in the second table with everything else.)
+one per message. (The rig spec parser's messages are prose, so they sit in the
+second table with everything else.)
 
 🚨 **A key neither format has is refused by name, in both files.** Not a row in
 the table below, because it is not about one field: every object in a rig spec and
 in a motion spec is checked against the keys its shape actually owns, and a key
-outside that set stops the build. Issue #545 is why — before it, such a key was
-never looked at, never mentioned and never emitted, and the build exited 0 with
-every assertion green. Four keys planted into one physics constraint all vanished,
-and no line of output named any of them.
+outside that set stops the build, because nothing else reads such a key: left
+alone it would be dropped from the emitted skeleton with every assertion green.
 
 ```
 rigc compile error: rig.json: constraint "ctl" (physics) has 4 keys this compiler
@@ -5414,11 +5097,7 @@ nothing and the required-key message below it is what arrives — `a rig spec ne
 **"does not read"** means the key *is* in your file, spelt some other way, and
 **"needs a …"** / **"is absent"** means it is not in the file at all. Where both
 are true at once — a typo beside a key that really is missing — the typo is named
-first, because it is the one you can fix without re-reading the file. Until
-[#672](https://github.com/firejune/rigc/issues/672) the rig spec's required-key
-checks ran *above* its scan, so `"slot"` for `"slots"` printed the sentence asking
-for an array the file already had, one character off, and never named the stray
-key; the motion spec has always had this order.
+first, because it is the one you can fix without re-reading the file.
 
 ⚠️ One check stays above the scan in both parsers: the `spec` version tag. The
 version is what decides *which* key set applies, so a file declaring a version this
@@ -5434,49 +5113,48 @@ one is listed: a rig spec's root, a motion spec's root, an animation, and a
 the compiler tolerates is a key it cannot distinguish from one you meant it to
 read. (The **cut manifest** is deliberately outside this: it is the record of the
 pipeline that produced the art as much as an input, it carries fields the compiler
-states outright that it does not read — `roi` — and the fixtures in this repository
-already give it `note` and `archetype`. It has no shape parse at all, which is the
-same hole issue #307 closed for the motion spec.)
+states outright that it does not read — `roi` — and it may carry `note` and
+`archetype` as well. It has no shape parse at all.)
 
 | Key | Refused when it is not | Why the shape matters |
 | --- | --- | --- |
 | the file itself | a JSON object | the version row below would otherwise report a missing `spec` tag in a file that has no fields at all |
 | `spec` | `"rigc-motion/1"` | §4 |
-| `archetype`, `cut` | a non-empty string | `cut` was read by nothing, so a spec that omitted it compiled green and could not say what it was authored for |
+| `archetype`, `cut` | a non-empty string | a spec with no `cut` cannot say what it was authored for |
 | `note` (at any level) | a string | — |
-| `easings` | an object | it is declared required and nothing asserted it, so an absent table failed at the first key that named an easing instead of at the table |
-| `easings."<name>"` | **four finite numbers** | `bezierForChannel` destructures four handles with no guard: `[0.42, 0, 0.58]` emitted `"curve": [0.42, 0, 0.58, null]` (§4.1) |
-| `groups` | an object keyed by group name | an array compiled green with no group defined. Each group's member LIST stays a compile-time refusal — see the rows further down |
-| `setup` | an object keyed by slot name | every `setup?.[slot]` lookup on an array is `undefined`, so the whole table was silently absent |
-| `setup."<slot>"` | an object of `{ attachment?, color? }` | §4.2 — `"<slot>": "plate"` reads `.attachment` off a string as `undefined` and **hides the slot** (#293) |
+| `easings` | an object | an absent table is refused at the table, not at the first key that names an easing |
+| `easings."<name>"` | **four finite numbers** | `bezierForChannel` destructures four handles with no guard: `[0.42, 0, 0.58]` would emit `"curve": [0.42, 0, 0.58, null]` (§4.1) |
+| `groups` | an object keyed by group name | an array would compile green with no group defined. Each group's member LIST stays a compile-time refusal — see the rows further down |
+| `setup` | an object keyed by slot name | every `setup?.[slot]` lookup on an array is `undefined`, so the whole table would be silently absent |
+| `setup."<slot>"` | an object of `{ attachment?, color? }` | §4.2 — `"<slot>": "plate"` reads `.attachment` off a string as `undefined` and **hides the slot** |
 | `setup."<slot>".attachment` | a string or `null` | whether a string RESOLVES is still the compile-time row below; whether it is a string is this one |
 | `setup."<slot>".color[i]` | a finite number in 0..1 | `channelHex` clamps with `Math.min`/`Math.max`, which pass `NaN` through, and `NaN.toString(16)` is the text `"NaN"` |
 | `physics` | an object keyed by constraint name | as `setup` |
 | `physics."<name>".bone` | a non-empty string | — |
 | `physics."<name>".<tuning field>` | a finite number | rounded to `NaN` and emitted as `null`, which the runtime reads as zero (§4.6) |
 | `mix`, `mix.default`, `mix.pairs[i]` | an object / a number / a `["<from>", "<to>", <seconds>]` triple | not emitted into skeleton JSON, so nothing else ever looks at it (§4.6) |
-| `animations` | an object keyed by animation name | an absent one crashed with a raw `TypeError` that named neither input file; an array compiled green with no animations |
-| `animations."<a>"` | an object | crashed with a raw `TypeError` on `anim.tracks` |
-| `animations."<a>".duration` | a finite number ≥ 0 | R7's check is `Math.abs(compiled − declared) > FRAME`, and a comparison against `NaN` is **false** — so the one guard on the field passed hardest exactly when the field was missing |
+| `animations` | an object keyed by animation name | an absent one would crash with a raw `TypeError` that names neither input file; an array would compile green with no animations |
+| `animations."<a>"` | an object | it would crash with a raw `TypeError` on `anim.tracks` |
+| `animations."<a>".duration` | a finite number ≥ 0 | R7's check is `Math.abs(compiled − declared) > FRAME`, and a comparison against `NaN` is **false** — so the one guard on the field would pass hardest exactly when the field is missing |
 | `animations."<a>".loop` | `true` or `false` | optional; absent means the player decides (§4.3) |
 | `animations."<a>".tracks` | an array | an animation whose timelines are all in the families beside `tracks` still writes `"tracks": []` |
 | `…tracks[i]` | an object | — |
 | `…tracks[i].property` | a non-empty string | which properties exist is the compile-time row below (§4.4) |
 | `…tracks[i].slot`/`.group`/`.bone`/`.physics`/`.path`/`.slider` | a string | whether exactly one is named, and what it resolves to, are compile-time rows below |
-| `…tracks[i].lag`, `.stagger` | a finite number | a string is CONCATENATED onto each key time and a boolean adds 1s, and the resulting refusal blamed the key and the duration for a fault in neither |
+| `…tracks[i].lag`, `.stagger` | a finite number | a string is CONCATENATED onto each key time and a boolean adds 1s, and the resulting refusal would blame the key and the duration for a fault in neither |
 | `…keys[j]` | an object | — |
-| `…keys[j].t` | a finite number | **every** key family, including the three that never had this guard: value tracks, slot tracks and `drawOrder` |
+| `…keys[j].t` | a finite number | **every** key family, value tracks, slot tracks and `drawOrder` included |
 | `…keys[j].ease` | a string | — |
-| `…drawOrder`, `…events`, `…ik`, `…transform`, `…deform` | an array | an object was refused as `no keys`, which is what an EMPTY array says |
-| `…drawOrder[i].offsets` | an array | a key with no offsets is the format's own "back to the setup draw order", and the test for it was true for `{}` — a complete statement of the draw order, made by accident |
+| `…drawOrder`, `…events`, `…ik`, `…transform`, `…deform` | an array | an object would be refused as `no keys`, which is what an EMPTY array says |
+| `…drawOrder[i].offsets` | an array | a key with no offsets is the format's own "back to the setup draw order", and the test for it is true for `{}` — a complete statement of the draw order, made by accident |
 | `…drawOrder[i].offsets[j]` | `{ slot: string, offset: number }` | whether the slot is emitted, and whether the offset is whole and lands inside the array, are compile-time rows below |
-| `…ik[i]`, `…transform[i]`, `…deform[i]` | an object | `null` in one of these lists crashed with a raw `TypeError` on `track.constraint` / `track.skin` |
+| `…ik[i]`, `…transform[i]`, `…deform[i]` | an object | `null` in one of these lists would crash with a raw `TypeError` on `track.constraint` / `track.skin` |
 | `…ik[i].constraint`, `…transform[i].constraint` | a non-empty string | 4.3 writes the group as `ik.<constraint>`, so the name is the only target there is |
 | `…deform[i].slot`, `.attachment`, `.skin` | a string (`skin` optional) | — |
 | `…sequence` | an array | §4.13 — one entry per skin/slot/attachment triple |
 | `…sequence[i].slot`, `.attachment`, `.skin` | a string (`skin` optional) | — |
 | `…sequence[i].keys[j].mode` | one of the seven — `hold`, `once`, `loop`, `pingpong`, `onceReverse`, `loopReverse`, `pingpongReverse` | `SequenceMode[mode]` is `undefined` for anything else and the mode bits store 0: the key loads without a word and plays as `hold` |
-| `…sequence[i].keys[j].index` | a whole number ≥ 0 | stored as `index << 4`, which truncates a fraction (1.5 showed frame 1). Whether it is inside the series' `count` is the compile-time row below |
+| `…sequence[i].keys[j].index` | a whole number ≥ 0 | stored as `index << 4`, which truncates a fraction (1.5 shows frame 1). Whether it is inside the series' `count` is the compile-time row below |
 | `…sequence[i].keys[j].delay` | a finite number ≥ 0 — and **above 0 wherever the mode advances**, counting a delay carried from the key before | `(time - keyTime) / 0` is Infinity and `Infinity \| 0` is 0, so a `loop` at delay 0 shows its first frame throughout. The message reads `` `…keys[j]` plays "loop" at a delay of 0 … which is "hold" spelt as "loop" `` |
 
 The second wave is everything that needed the **other** file, the property table
@@ -5489,13 +5167,13 @@ or the key's position in its own track. These are the frequent ones, verbatim:
 | `a rig spec needs a "slots" array (it may be empty; its ORDER is the draw order)` | §3.3 — write `[]` for a rig that draws nothing. ⚠️ These three arrive only when the key is really absent: **misspelt**, it is the unknown-key refusal above, naming what you wrote |
 | `bone "X" names parent "Y", which is not declared before it` | move `Y` earlier in `bones` |
 | `two bones are called "X"` | bone names are the join key; rename one |
-| `two ik constraints are called "X" — a constraint resolves by name AND type (\`SkeletonData.findConstraint\`), so names are unique PER KIND: an ik and a transform constraint may share one, two of a kind may not` | §3.5 — rename one of the two. The kind in the sentence is the pair's own, so `two transform constraints are called "X"` is the same refusal on another kind; a name shared **across** kinds is not this error and never was one to fix |
+| `two ik constraints are called "X" — a constraint resolves by name AND type (\`SkeletonData.findConstraint\`), so names are unique PER KIND: an ik and a transform constraint may share one, two of a kind may not` | §3.5 — rename one of the two. The kind in the sentence is the pair's own, so `two transform constraints are called "X"` is the same refusal on another kind; a name shared **across** kinds is not this error |
 | `physics constraint "X" is declared in both the rig spec and the motion spec's physics table` | §4.6 — the rig spec declares a physics constraint's structure and the motion spec's `physics` table declares one outright; pick the file it belongs in. Per kind, like every other constraint name: an `ik` "X" in the rig spec beside a `physics` "X" here is two constraints and is not this error |
-| `skin "S" lists "X" under "transform", but the rig declares it as a "ik" constraint — a skin looks its constraints up by name AND type, so this one is a miss and the loader throws` | §3.4.1 — move the name to the list named after the constraint's own kind. A name the rig declares under **no** kind is the other miss and says so (`skin "S" activates ik constraint "X", which this rig does not declare`). ⚠️ A name listed by **several skins** is not an error and no longer was one as of [#725](https://github.com/firejune/rigc/issues/725): the lists are per-skin sets and a bone or constraint in two of them is active under either |
+| `skin "S" lists "X" under "transform", but the rig declares it as a "ik" constraint — a skin looks its constraints up by name AND type, so this one is a miss and the loader throws` | §3.4.1 — move the name to the list named after the constraint's own kind. A name the rig declares under **no** kind is the other miss and says so (`skin "S" activates ik constraint "X", which this rig does not declare`). ⚠️ A name listed by **several skins** is not an error: the lists are per-skin sets and a bone or constraint in two of them is active under either |
 | `slot "X" names bone "Y", which this rig does not declare` | add the bone, or fix the slot's `bone` |
 | `no setup pose for slot "X": give the motion spec a \`setup\` entry or the rig slot an \`attachment\`` | R3 — pick one file and declare it there. A slot **nothing** fills is exempt: its setup pose can only be "show nothing" and is not asked for |
 | `the setup pose shows attachment "A" on slot "X", which no skin and no manifest part fills` | §3.3 — the slot is emitted empty and nothing was ever going to fill it, so `A` resolves to nothing. Give the slot an attachment (a skin entry or a manifest part), or state the setup pose as `null` |
-| `the setup pose shows attachment "A" on slot "X", and the slot is emitted empty because the one manifest state that fills it has no art: "s" (no PNG at p)` | §0.2 — a **different** fault with a similar shape: a manifest part does fill this slot and its art was not where the manifest pointed, so every state of it was dropped. **Restore the file or fix the path** — posing `null` compiles, but it ships the rig with that part missing and the gate green. The path printed is the one rigc tried, which is what tells a deleted file from a misspelt `states:` entry; `all N manifest states that fill it have no art` is the same message where the part has more than one. Under `--atlas-in` the same sentence reads `no region "R" in <atlas>` and asks you to add the region to the pack — no file was opened ([#671](https://github.com/firejune/rigc/issues/671)) |
+| `the setup pose shows attachment "A" on slot "X", and the slot is emitted empty because the one manifest state that fills it has no art: "s" (no PNG at p)` | §0.2 — a **different** fault with a similar shape: a manifest part does fill this slot and its art was not where the manifest pointed, so every state of it was dropped. **Restore the file or fix the path** — posing `null` compiles, but it ships the rig with that part missing and the gate green. The path printed is the one rigc tried, which is what tells a deleted file from a misspelt `states:` entry; `all N manifest states that fill it have no art` is the same message where the part has more than one. Under `--atlas-in` the same sentence reads `no region "R" in <atlas>` and asks you to add the region to the pack — no file was opened |
 | `a region needs width and height — give them, or give an "image" and rigc will measure the PNG` | add `image`, or both sizes |
 | `a mesh needs width and height — give them, or give an "image" and rigc will measure the PNG` | §3.4 — the same rule for a mesh |
 | `"type" is null, which is not a name. An attachment's type is one of region, mesh, linkedmesh, … or the key is absent and reads as "region"` | §6 — **remove the key**. Absent is the format's own default; present-and-null matches no parser case and the attachment is dropped in silence |
@@ -5505,7 +5183,7 @@ or the key's position in its own track. These are the frequent ones, verbatim:
 | `a linked mesh states "uvs", "triangles", …, and a linked mesh has no geometry of its own` | §3.4 — remove them, or remove `source` and author this as a mesh. The parser returns before `readVertices`, so those keys are read by nothing at all |
 | `"source" is "X", and skin "S" … slot "L" … holds 2: "a", "b"` | §3.4 — `source` is the PLACEHOLDER the source is filed under, not its `name`. A clause after the skin and after the slot says whether each was stated or taken from the parser's default — **the default skin** and **this attachment's own slot**, which is the pair that surprises |
 | `"slot" is "X", which the rig does not declare as a slot` / `"skin" is "X", … the rig declares no such skin` | §3.4 — a link resolves both by name. Left to the round trip these are the runtime's `Source mesh slot not found` and `Skin not found`, which name neither the attachment nor where it looked |
-| `no "skin" is stated, so the parser looks for the source "X" in the default skin — and this rig declares no default skin` | §3.4 — state the `skin` the source is filed under. A link with no `skin` resolves through `SkeletonData.defaultSkin`, which is null in a file with no default skin, and the runtime reads `getAttachment` off it with a `TypeError` naming nothing. Before [#801](https://github.com/firejune/rigc/issues/801) every build carried an empty `default`, so the same link failed at the source instead |
+| `no "skin" is stated, so the parser looks for the source "X" in the default skin — and this rig declares no default skin` | §3.4 — state the `skin` the source is filed under. A link with no `skin` resolves through `SkeletonData.defaultSkin`, which is null in a file with no default skin, and the runtime reads `getAttachment` off it with a `TypeError` naming nothing |
 | `"source" is "X", which is itself a linked mesh, and a chain of them is refused` | §3.4 — point `source` at the mesh. A chain resolves in file order and loads nothing at all in one of the two orders, silently |
 | `"source" is "X", which is a "region" attachment and not a mesh` | §3.4 — a link takes another MESH's geometry; off any other type the runtime reads `undefined` and says nothing |
 | `… is a boundingbox and states a "sequence". A sequence is a numbered series of atlas regions, and only the 3 kinds that draw a region carry one — region, mesh, linkedmesh …` | §3.4.3 — put the series on a region or a mesh, or remove it |
@@ -5523,26 +5201,26 @@ or the key's position in its own track. These are the frequent ones, verbatim:
 | `the triangles do not tile the outline: …` / `the triangles' outline is not one closed loop: …` | §3.4 — a doubled triangle, an unused vertex, a pinch or a hole in `triangles` |
 | `vertex N binds bone "X", which the rig does not declare as a bone` | §3.4 — an authored mesh's `weights` bind by NAME, like everything else in a rig spec. Fix the spelling, or declare the bone. The message names the skin, the slot, the placeholder and the vertex, because an index would name none of them |
 | `image "X.png" is not on disk at …` | fix the name, or point `--images` at the right directory |
-| `image "X.png": /…/X.png is a WebP image (…), not a PNG: its first 12 byte(s) are …` | the file is there and is not a PNG — the name ends in `.png` and the bytes decide. Re-export it as PNG; the same sentence says **truncated** for a PNG that runs out before its `IEND`, and then the repair is a whole copy (§0.2, [#732](https://github.com/firejune/rigc/issues/732)) |
-| `a "contour" generator traces the part's own alpha, and "X.png" is lifted off a packed page at the coordinates the atlas states, which on this file are not where its texels are — so there is no silhouette here to trace, only another part of the page. page "p.png" declares …` | the page's PNG is not the size its atlas declares, and the rest of the message is `A06`'s sentence for it: re-declare the page with the `scale:` header it names, or re-export the page at its declared size (§0.2, [#750](https://github.com/firejune/rigc/issues/750)) |
+| `image "X.png": /…/X.png is a WebP image (…), not a PNG: its first 12 byte(s) are …` | the file is there and is not a PNG — the name ends in `.png` and the bytes decide. Re-export it as PNG; the same sentence says **truncated** for a PNG that runs out before its `IEND`, and then the repair is a whole copy (§0.2) |
+| `a "contour" generator traces the part's own alpha, and "X.png" is lifted off a packed page at the coordinates the atlas states, which on this file are not where its texels are — so there is no silhouette here to trace, only another part of the page. page "p.png" declares …` | the page's PNG is not the size its atlas declares, and the rest of the message is `A06`'s sentence for it: re-declare the page with the `scale:` header it names, or re-export the page at its declared size (§0.2) |
 | `--atlas-in <pack>.atlas: N of its M page(s) cannot be read as PNG, and nothing was compiled against the pack — page "p.png": …` | the same, for every page of the pack at once, before the compile: re-export each named page as PNG under the name the atlas gives it (§0.2) |
 | `parts/iris_open.png is 96x64 but slot "iris" declares 96x60` | R5 — a manifest `states:` entry whose art is not the window the part declares. Re-export the PNG, or fix the part's `size`; a quad sized against art of another size is the silence `A06` exists for, and the window is what the quad is built from |
 | `plates/00_stage.png is 256x256 but the manifest window for "stage" is 250x256` | R5 — the same check on the part's unconditional `image`, against the window the crop gives it |
-| `region "00_stage" of <pack>.atlas (declared 256x256 by its offsets) is 256x256 but the manifest window for "stage" is 250x256` | R5 — the row above under `--atlas-in`, and the prefix is the whole point: it says which of the two rigc **measured**, because the remedy differs. A bare path is a loose PNG it opened and you re-export; a `region … of <pack>` was read out of the pack, and you repack or aim the part at another region. This is the size row of §0.2's four, with the message it actually prints |
+| `region "00_stage" of <pack>.atlas (declared 256x256 by its offsets) is 256x256 but the manifest window for "stage" is 250x256` | R5 — the row above under `--atlas-in`, and the prefix is the whole point: it says which of the two rigc **measured**, because the remedy differs. A bare path is a loose PNG it opened and you re-export; a `region … of <pack>` was read out of the pack, and you repack or aim the part at another region. This is the size row of §0.2's table, with the message it actually prints |
 | `duplicate region name "X"` | two PNGs share a basename; one part, one page, one name |
 | `"b/X.png" and the art already atlased as region "X" are two different files — … Rename one of the PNGs.` | R5 — the region name is the basename, so only one of the two can hold it. Rename a file (not a placeholder: the placeholder is free to repeat) |
 | `the image "X.png" was never added to the atlas, so there is no region "X" …` | nothing in the spec — every image an attachment names is measured and atlased, one per file whichever skin names it, so this says rigc skipped one. Report it on [the tracker](https://github.com/firejune/rigc/issues). The `#555` the message itself cites is the change that made one-per-file an invariant, not a place to file against |
 | `motion spec names archetype "A" but the rig spec at … is called "B"` | make `archetype` equal the rig's `name` |
 | `animation "A" declares duration Ns but its last key is at Ms` | R7 — fix whichever of the two you meant |
 | `animation "A" slot "X" attachment: key at Ns is Ms past the declared duration Ds` | §4.5 — the key is past the end of the animation and nothing will sample it. Move the key onto `duration`, or raise `duration` |
-| `animation "A" slot "X" attachment: attachment "N" is not in slot "X" under any skin (searched: default, alt) — the slot has: plain, trim` | §4.4 — the keyed name is in **no** skin, and the two clauses say where the compiler looked and what it would have taken. Fix the spelling, or give some skin a placeholder called `N`. A name only a NAMED skin fills is not this error and never was one to fix — it compiles, and the slot shows nothing under the skins that lack it. Before [#695](https://github.com/firejune/rigc/issues/695) the message read `attachment "N" is not in slot "X"` and was raised against the **default skin alone**, so it fired on correct rigs: any key into named-skin art, and every key in a rig with no default skin. `the slot has no attachments at all` is the same message where nothing fills the slot |
+| `animation "A" slot "X" attachment: attachment "N" is not in slot "X" under any skin (searched: default, alt) — the slot has: plain, trim` | §4.4 — the keyed name is in **no** skin, and the two clauses say where the compiler looked and what it would have taken. Fix the spelling, or give some skin a placeholder called `N`. A name only a NAMED skin fills is not this error — it compiles, and the slot shows nothing under the skins that lack it. `the slot has no attachments at all` is the same message where nothing fills the slot |
 | `animation "A" keys unknown bone "X"` | the track's `bone` is not in the rig |
 | `animation "A" keys physics "*" P, the timeline that names no constraint and drives every physics constraint declaring "PGlobal": true, and none of "C", … does — it would parse and move nothing` | §4.4 — set `"PGlobal": true` on the constraints the track is for (§3.5), or key one by name. For `reset` it reads *every physics constraint the rig has*, and fires only on a rig with none |
 | `` `animations."A".tracks[i].physics` is the string ""; the empty name is how a skeleton file spells a physics timeline that names no constraint, and a motion spec spells that "*" … `` | §4.4 — name one constraint, or write `"*"` |
 | `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 outside its row's bound. The message names the bound and then its basis ([#798](https://github.com/firejune/rigc/issues/798)): where the runtime's arithmetic fails, the expression and its lines (`mass` at 0 is the one here, and `damping` below 0); where the value runs and runs wrongly, that refusing it is rigc's call and what the value does. The bounds: `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) |
+| `animation "A" physics constraint "C" mass key at t=… is 0 (massInverse Infinity); must be > 0 — …` | §4.4 — a keyed physics value outside its row's bound. The message names the bound and then its basis: where the runtime's arithmetic fails, the expression and its lines (`mass` at 0 is the one here, and `damping` below 0); where the value runs and runs wrongly, that refusing it is rigc's call and what the value does. The bounds: `mass` is `> 0`, `damping` is inside `[0, 1]`, both ends included, `mix` and `strength` are `0` or more, and `inertia`/`wind`/`gravity` are bounded nowhere. ⚠️ 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`; a setup `strength` below 0 says the offset is pushed away and grows, the same arm this message quotes for a negative key. 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` |
@@ -5604,19 +5282,19 @@ or the key's position in its own track. These are the frequent ones, verbatim:
 | `animation "A": "position" is a path constraint timeline, and this track names no constraint` | §4.12 — put the name in `"path"` |
 | `rgba value needs 4 channels, got 3` | §4.4 — an `rgba` key is `[r, g, b, a]`. It names no animation, slot or key time, and the only input that reaches it is a slot `rgba` key: the setup pose's `color` is refused earlier, by its own row, with the slot named |
 | `rgba2 value needs 7 channels, got 6` | §4.4 — an `rgba2` key is `[lr, lg, lb, la, dr, dg, db]`: the light colour with its alpha, then the dark colour **without** one. Six is the commonest way to get it wrong, because the dark half looks like it should take an alpha too — the format has no channel for it, and neither does the runtime's `setFrame`. Like the row above it names no animation or key time; the only input that reaches it is a slot `rgba2` key |
-| `rgb value needs 3 channels, got 4` · `alpha value needs 1 channel, got 2` · `rgb2 value needs 6 channels, got 7` | §4.4 — the separable shapes, refused in the words the two above use: an `rgb` key is `[r, g, b]`, an `alpha` key is `[a]`, an `rgb2` key is `[lr, lg, lb, dr, dg, db]`. Four channels on an `rgb` track is the likeliest way to get it wrong — the `rgba` spelling on the timeline that exists to leave the alpha alone — and seven on `rgb2` is the `rgba2` spelling. [#730](https://github.com/firejune/rigc/issues/730) |
+| `rgb value needs 3 channels, got 4` · `alpha value needs 1 channel, got 2` · `rgb2 value needs 6 channels, got 7` | §4.4 — the separable shapes, refused in the words the two above use: an `rgb` key is `[r, g, b]`, an `alpha` key is `[a]`, an `rgb2` key is `[lr, lg, lb, dr, dg, db]`. Four channels on an `rgb` track is the likeliest way to get it wrong — the `rgba` spelling on the timeline that exists to leave the alpha alone — and seven on `rgb2` is the `rgba2` spelling |
 | `animation "A" slot "X" alpha: alpha key value must be [a]` | §4.4 — an alpha key's `v` is a one-element array like every other one-channel track, even though the file writes it bare (`{ time, value }`). The same row exists for each colour shape with its own spelling (`rgb key value must be [r,g,b]`, …) |
 | `animation "A" slot "X" alpha: key at t=T is V; an alpha is a number from 0 to 1 …` | §4.4 — the one colour key stored as a number, so the one nothing clamps on the way out. The runtime clamps the posed alpha only after interpolating, so a key outside 0..1 bends the curve toward a value no pose holds; state the value you mean. 0 and 1 themselves are taken |
 | `animation "A" slot "X": tracks "P" and "Q" both key the slot's alpha — a colour timeline poses its channels at every time …` | §4.4 — two colour tracks of one slot that pose a shared channel (`rgba` + `alpha`, `rgba` + `rgb`, `rgba2` + `rgb2`, …). Each poses its channels at every time, its setup value before its first key included, so the later in the file overwrites the other everywhere and one of them is read by nothing. Key each channel once: `rgb` and `alpha` for two halves on their own key times, `rgba` for both together. The channel named is whichever the two share — `light rgb`, `alpha`, `dark colour` |
-| `animation "A" bone "B" has no timeline "P" (it has: translate, translatex, translatey, scale, scalex, scaley, shear, shearx, sheary, rotate, inherit)` | §4.4 — a bone has exactly eleven timelines and `P` is none of them. Fix the spelling — the single-axis ones are lower-case (`translatex`, not `translateX`). A **constraint** property is refused first, by its own row, naming the field its constraint's name goes in. When `P` is a slot timeline the message says so and where to put the name: `. "rgba" is a slot timeline — put the name in "slot"`. Before [#656](https://github.com/firejune/rigc/issues/656) all of them read `bone "B" cannot take slot property "P"`, which named the slot family whatever you had written and listed nothing |
-| `animation "A" bone "B" inherit key at t=T carries an easing ("E"), and this timeline is stepped by the format — its reader builds no curve, so the mode changes AT the key and holds until the next one. Remove it` (and `… carries a curve, …` for a raw `curve`) | §4.4 — an `inherit` key is a mode, not a value between two others: the parser's `inherit` branch reads `time` and `inherit` and nothing else, so an easing would be written into a key nobody reads (`A05_CURVE_ARRAY_LENGTH` refuses the same `curve` on a file rigc did not write). `"stepped"` is refused too, for the same reason — the timeline already is. Delete the `ease` or `curve` ([#733](https://github.com/firejune/rigc/issues/733)) |
-| `animation "A" bone "B" inherit key at t=T names mode "M"; known: normal, onlyTranslation, noRotationOrReflection, noScale, noScaleOrReflection — the runtime folds the case of the first letter and of nothing else` | §4.4 — `M` is not one of the five. The list and the rule are the setup field's (§3.2) — one resolver reads both — so `NoScale` compiles (and is written `noScale`, the editor's spelling) while `NOSCALE` and `noscale` do not: the runtime would load either as **no mode**, and the bone would keep whatever world transform it had ([#733](https://github.com/firejune/rigc/issues/733)) |
-| `bone "B" has inherit "M"; known: normal, onlyTranslation, noRotationOrReflection, noScale, noScaleOrReflection — the runtime folds the case of the first letter and of nothing else` | §3.2 — the setup half of the row above, and the same list. Before [#733](https://github.com/firejune/rigc/issues/733) this check was case-insensitive, which is wider than the runtime: `"NOSCALE"` compiled, gated green, and loaded as no mode, so the bone's world rotation, scale and shear were never computed — every attachment on it collapsed to a point. Fix the spelling |
-| `animation "A" group "G" has no timeline "P" (a bone group has: translate, translatex, translatey, scale, scalex, scaley, shear, shearx, sheary, rotate, inherit; a slot group has: attachment, rgba, rgb, alpha, rgba2, rgb2; a physics constraint group has: inertia, strength, damping, mass, wind, gravity, mix, reset)` | §4.3, §4.4 — a group's family is decided by the property, and `P` is in none of the three tables, so there is no family to resolve the members as. Fix the spelling and the group becomes whichever family the property names. The group is refused before its members are looked up, so a member the rig does not declare is a **later** message; an unknown group NAME is an earlier one. Before [#661](https://github.com/firejune/rigc/issues/661) a group of bones read `animation "A" targets unknown slot "M"` and a group of slots got the slot row below, naming one family out of three |
-| `animation "A" slot "X" has no timeline "P" (it has: attachment, rgba, rgb, alpha, rgba2, rgb2)` | §4.4 — a slot has exactly six timelines — every one the format has — and `P` is none of them. Fix the spelling; a bone or constraint property written on a slot track is refused by its own row instead. Before [#650](https://github.com/firejune/rigc/issues/650) every other name compiled as an **rgba** timeline called `P`, and what you saw was `A00_ROUNDTRIP_PARSE` on the emitted file — or, for the one-channel spelling, `rgba value needs 4 channels, got 1` |
-| `animation "A" slot "X" rgba2: slot "X" declares no setup "dark", and an "rgba2" timeline poses a slot's dark colour …` — and the same with `rgb2` | §3.3, §4.4 — the two-colour tint has a setup half and a keyed half, and the keyed half cannot exist without the other. `Slot`'s constructor allocates a dark colour only for a slot whose setup pose declares one, and `RGBA2Timeline` writes it unconditionally — so without the `dark` the file loads, and the first `state.apply` throws `TypeError: null is not an object` in the consumer's process. Give the slot the `dark` it holds at rest, or key `rgba` (for `rgb2`, `rgb`) if only the light colour moves. `RGB2Timeline` was measured to throw the same way before `rgb2` joined the refusal ([#730](https://github.com/firejune/rigc/issues/730)). Raised before the keys are read, with the slot named, for the same reason the row above is |
-| `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 |
+| `animation "A" bone "B" has no timeline "P" (it has: translate, translatex, translatey, scale, scalex, scaley, shear, shearx, sheary, rotate, inherit)` | §4.4 — a bone has exactly eleven timelines and `P` is none of them. Fix the spelling — the single-axis ones are lower-case (`translatex`, not `translateX`). A **constraint** property is refused first, by its own row, naming the field its constraint's name goes in. When `P` is a slot timeline the message says so and where to put the name: `. "rgba" is a slot timeline — put the name in "slot"` |
+| `animation "A" bone "B" inherit key at t=T carries an easing ("E"), and this timeline is stepped by the format — its reader builds no curve, so the mode changes AT the key and holds until the next one. Remove it` (and `… carries a curve, …` for a raw `curve`) | §4.4 — an `inherit` key is a mode, not a value between two others: the parser's `inherit` branch reads `time` and `inherit` and nothing else, so an easing would be written into a key nobody reads (`A05_CURVE_ARRAY_LENGTH` refuses the same `curve` on a file rigc did not write). `"stepped"` is refused too, for the same reason — the timeline already is. Delete the `ease` or `curve` |
+| `animation "A" bone "B" inherit key at t=T names mode "M"; known: normal, onlyTranslation, noRotationOrReflection, noScale, noScaleOrReflection — the runtime folds the case of the first letter and of nothing else` | §4.4 — `M` is not one of the five. The list and the rule are the setup field's (§3.2) — one resolver reads both — so `NoScale` compiles (and is written `noScale`, the editor's spelling) while `NOSCALE` and `noscale` do not: the runtime would load either as **no mode**, and the bone would keep whatever world transform it had |
+| `bone "B" has inherit "M"; known: normal, onlyTranslation, noRotationOrReflection, noScale, noScaleOrReflection — the runtime folds the case of the first letter and of nothing else` | §3.2 — the setup half of the row above, and the same list. The check is exactly as wide as the runtime: `"NOSCALE"` would load as no mode, so the bone's world rotation, scale and shear would never be computed — every attachment on it collapses to a point. Fix the spelling |
+| `animation "A" group "G" has no timeline "P" (a bone group has: translate, translatex, translatey, scale, scalex, scaley, shear, shearx, sheary, rotate, inherit; a slot group has: attachment, rgba, rgb, alpha, rgba2, rgb2; a physics constraint group has: inertia, strength, damping, mass, wind, gravity, mix, reset)` | §4.3, §4.4 — a group's family is decided by the property, and `P` is in none of the three tables, so there is no family to resolve the members as. Fix the spelling and the group becomes whichever family the property names. The group is refused before its members are looked up, so a member the rig does not declare is a **later** message; an unknown group NAME is an earlier one |
+| `animation "A" slot "X" has no timeline "P" (it has: attachment, rgba, rgb, alpha, rgba2, rgb2)` | §4.4 — a slot has exactly six timelines — every one the format has — and `P` is none of them. Fix the spelling; a bone or constraint property written on a slot track is refused by its own row instead |
+| `animation "A" slot "X" rgba2: slot "X" declares no setup "dark", and an "rgba2" timeline poses a slot's dark colour …` — and the same with `rgb2` | §3.3, §4.4 — the two-colour tint has a setup half and a keyed half, and the keyed half cannot exist without the other. `Slot`'s constructor allocates a dark colour only for a slot whose setup pose declares one, and `RGBA2Timeline` writes it unconditionally — so without the `dark` the file loads, and the first `state.apply` throws `TypeError: null is not an object` in the consumer's process. Give the slot the `dark` it holds at rest, or key `rgba` (for `rgb2`, `rgb`) if only the light colour moves. `RGB2Timeline` is measured to throw the same way. Raised before the keys are read, with the slot named, for the same reason the row above is |
+| `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` — 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 |
+| `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 |
 | `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 |
 | `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 |
 
@@ -5642,12 +5320,7 @@ Both halves of it are measured rather than fixed text: the count is this pair's,
 where the atlas has a **near miss** the sentence prints that too, in `A08`'s own
 clause and `A08`'s own words. When `--atlas-in` **was** given and the region is still
 absent, the second half names the pack instead and asks you to fix the spec's region
-name or point the flag at the pack that has it. Until
-[#697](https://github.com/firejune/rigc/issues/697) there was no rigc sentence at
-all: the report printed in full and the run then died inside `AtlasAttachmentLoader`
-with `Region not found in atlas: shade (attachment: shade)` and a spine-core stack
-trace, at exit 1 — the runtime's message about rigc's internals standing in for
-rigc's message about your two files.
+name or point the flag at the pack that has it.
 
 ### 5.2 Assertions — the gate
 
@@ -5664,8 +5337,7 @@ The report prints one line per assertion:
 - **PASS** — it ran and held.
 - **SKIP** — it had *nothing to look at*, and the reason says what was missing. A
   skip is never folded into the pass count.
-  🚨 **"Nothing to look at" includes a subject the skeleton does not carry**
-  ([#580](https://github.com/firejune/rigc/issues/580)). A rule named
+  🚨 **"Nothing to look at" includes a subject the skeleton does not carry.** A rule named
   ⟨subject⟩_⟨property⟩ — `A03_REGION_WIDTH_HEIGHT_FINITE`,
   `A04_MESH_TRIANGLES_AND_ENCODING`, `A23_PHYSICS_CONSTRAINT_EFFECTIVE` — walks
   that subject and measures each member, so a skeleton with no region, no mesh or
@@ -5705,59 +5377,59 @@ and with no parse there is nothing for them to look at — so they report `SKIP`
 naming that, *the round trip did not produce a skeleton to measure* or *…an atlas
 to measure*, and the summary's `<S>` goes up while `<M>` collapses. A run in that
 state is not a rig that nearly passed; it is a rig that was measured on one rule.
-Fix A00 and run it again ([#568](https://github.com/firejune/rigc/issues/568)).
+Fix A00 and run it again.
 
 | Assertion | Profile | What tripped it, and where to fix it |
 | --- | --- | --- |
-| `A00_ROUNDTRIP_PARSE` | both | `spine-core` could not parse the skeleton or the atlas. Almost everything else in the report is downstream of this one — fix it first. When it fails, every rule that reads the loaded skeleton or the loaded atlas reports **SKIP** saying so by name, so the row count stays at the full registry and the summary's *measured* figure tells you how little was actually asked ([#568](https://github.com/firejune/rigc/issues/568)). ⚠️ **Two rules run before it and can be upstream of it**: `A31_DRAW_ORDER_OFFSETS_RESOLVE`, because a bad draw-order key makes the loader spin rather than return, and `A08_REGION_NAMES_MATCH_ATTACHMENTS`, because a `path` naming no region makes it throw. The round trip is still attempted either way; when the loader refuses a path A08 has already refused, this row **defers** to A08 by name instead of restating the miss in the parser's poorer words ([#589](https://github.com/firejune/rigc/issues/589)) |
+| `A00_ROUNDTRIP_PARSE` | both | `spine-core` could not parse the skeleton or the atlas. Almost everything else in the report is downstream of this one — fix it first. When it fails, every rule that reads the loaded skeleton or the loaded atlas reports **SKIP** saying so by name, so the row count stays at the full registry and the summary's *measured* figure tells you how little was actually asked. ⚠️ **Two rules run before it and can be upstream of it**: `A31_DRAW_ORDER_OFFSETS_RESOLVE`, because a bad draw-order key makes the loader spin rather than return, and `A08_REGION_NAMES_MATCH_ATTACHMENTS`, because a `path` naming no region makes it throw. The round trip is still attempted either way; when the loader refuses a path A08 has already refused, this row **defers** to A08 by name instead of restating the miss in the parser's poorer words |
 | `A01_NO_LEGACY_TOPLEVEL_CONSTRAINT_ARRAYS` | both | a 4.1/4.2-shaped `ik`/`transform`/`path`/`physics`/`slider` array. rigc emits the 4.3 `constraints` array, so this normally means hand-edited JSON |
-| `A02_NO_BONE_TRANSFORM_KEY` | both | a bone uses 4.2's `transform`; rename it `inherit` in the rig spec |
-| `A03_REGION_WIDTH_HEIGHT_FINITE` | both | a region loaded `NaN` or a non-positive size — the attachment has no `image` and no `width`/`height`. **SKIP** when the skeleton carries no region attachment ([#580](https://github.com/firejune/rigc/issues/580)) |
-| `A04_MESH_TRIANGLES_AND_ENCODING` | both | authored mesh geometry: triangle count not a multiple of 3, an index out of range, or a `vertices` length that disagrees with `uvs` (the weighted/unweighted trap) **SKIP** when the skeleton carries no mesh attachment ([#580](https://github.com/firejune/rigc/issues/580)) |
-| `A05_CURVE_ARRAY_LENGTH` | both | a raw `curve` with the wrong number of values, a non-finite number in one, or a curve on a timeline that cannot take one. Four numbers **per value channel**. **SKIP** when no animation carries a timeline at all ([#580](https://github.com/firejune/rigc/issues/580)). Timelines with no `curve` on any key still PASS: every timeline name is checked against the channel table whether or not a curve sits on one |
-| `A06_ATLAS_PAGE_SIZE_MATCHES_PNG` | both ◑ | the atlas `size:` disagrees with the PNG on disk — the message names the ratio it measured on **each** axis and the header that states the same art truthfully, and §0.2 has the whole of it ([#715](https://github.com/firejune/rigc/issues/715)): a runtime maps a region as a fraction of the DECLARED size and never reads the texture's own, so such a page draws, and what it breaks is every reader that addresses the page in texels. A uniform ratio is a `size:`/`scale:` pair away from honest and the message prints it; two ratios are not, because `scale:` carries one number, and the message says so rather than offering a header that would not work. **Or** a region's rectangle is not inside the page it names — rotation honoured, so a region at `rotate: 90` or `270` occupies `height x width` of the page and a region that fits only because it is turned is inside it. The message names the region, the rectangle it occupies, the page and the page's size. That clause is **validity** and runs under both profiles ([#694](https://github.com/firejune/rigc/issues/694)): a rectangle outside its page makes `u2 > 1` and samples whatever the wrap mode returns, and `--atlas-in` already refuses the same rectangle at compile time (§0.2). Under `spine-html` also: `pma`, rotation, and two regions on one page over the same texels — a packed page must be **one part covering it exactly** (the unpacked convention) or a **tiling** ([#266](https://github.com/firejune/rigc/issues/266)), and what that message names is the pair that shares texels. **Or** the page file is not a PNG at all, and then nothing about its size is measured: the message carries the page's path and the size the atlas declares, and names what the file is by its first bytes — one of WebP, JPEG, GIF, KTX, KTX2 by its signature, or no image format rigc recognises, the bytes in hex either way — or calls it **truncated** when it begins as a PNG and runs out before its `IEND` (§0.2, [#732](https://github.com/firejune/rigc/issues/732)). That clause is validity too: nothing in rigc can read such a page back. **SKIP** when the atlas declares no page ([#580](https://github.com/firejune/rigc/issues/580)) |
-| `A07_ATLAS_TEXT_SHAPE` | both | atlas text: a region name with stray whitespace, or a blank line splitting a page block. rigc writes the atlas, so this means a hand-edited file. Two sentences are about blank lines and name two different repairs ([#803](https://github.com/firejune/rigc/issues/803)): `line 1: the file begins with a blank line` (or `with N blank lines` for a run, one finding) is a blank before the first page name — delete it; `line N: consecutive blank lines` is two blank lines side by side after the first page — delete one. rigc writes neither: under `--atlas-in` the pack's blank lines are put in rigc's shape on re-emission (§0.2), so either sentence means a file rigc did not write, handed to `validate`. ⚠️ An atlas with **no page block at all** — no non-blank line — is not one of those: its subject is absent, so this reports **SKIP** naming the byte count it read, and so do the four rules below whose subject is a page ([#608](https://github.com/firejune/rigc/issues/608)). A rig whose skins need no art writes exactly that file (§3.4), and before #608 this row refused it with two findings naming a page block that was not there. What an empty atlas does **not** excuse is an attachment that wants a region out of it — that is `A08` |
-| `A08_REGION_NAMES_MATCH_ATTACHMENTS` | both | three things, and the message says which: an attachment whose `path` names **no region** of this atlas; a `path` carrying **stray whitespace**, printed quoted so you can see it; an **atlas region name** carrying stray whitespace (`A07` names that same line with its line number). The first two are read off the raw file **before** the loader is asked, so the miss is named here with the skin, the slot, the placeholder and the attachment's own name — the four things `AtlasAttachmentLoader`'s own `Region not found in atlas: <path> (attachment: <name>)` does not carry. Until [#589](https://github.com/firejune/rigc/issues/589) they were unreachable: the loader threw first and the miss arrived as `A00_ROUNDTRIP_PARSE`. There is no `spine-html` clause here any more — a placeholder is free to differ from the region its `path` names ([#574](https://github.com/firejune/rigc/issues/574)) **SKIP** when no attachment names a region *and* the atlas declares none — both of its subjects at once ([#580](https://github.com/firejune/rigc/issues/580)) |
+| `A02_NO_BONE_TRANSFORM_KEY` | both | `bone "…" uses "transform", the key 4.0 and 4.1 spelled; 4.2 and 4.3 spell it "inherit"` — rename it `inherit` in the rig spec |
+| `A03_REGION_WIDTH_HEIGHT_FINITE` | both | a region loaded `NaN` or a non-positive size — the attachment has no `image` and no `width`/`height`. **SKIP** when the skeleton carries no region attachment |
+| `A04_MESH_TRIANGLES_AND_ENCODING` | both | authored mesh geometry: triangle count not a multiple of 3, an index out of range, or a `vertices` length that disagrees with `uvs` (the weighted/unweighted trap) **SKIP** when the skeleton carries no mesh attachment |
+| `A05_CURVE_ARRAY_LENGTH` | both | a raw `curve` with the wrong number of values, a non-finite number in one, or a curve on a timeline that cannot take one. Four numbers **per value channel**. **SKIP** when no animation carries a timeline at all. Timelines with no `curve` on any key still PASS: every timeline name is checked against the channel table whether or not a curve sits on one |
+| `A06_ATLAS_PAGE_SIZE_MATCHES_PNG` | both ◑ | the atlas `size:` disagrees with the PNG on disk — the message names the ratio it measured on **each** axis and the header that states the same art truthfully, and §0.2 has the whole of it: a runtime maps a region as a fraction of the DECLARED size and never reads the texture's own, so such a page draws, and what it breaks is every reader that addresses the page in texels. A uniform ratio is a `size:`/`scale:` pair away from honest and the message prints it; two ratios are not, because `scale:` carries one number, and the message says so rather than offering a header that would not work. **Or** a region's rectangle is not inside the page it names — rotation honoured, so a region at `rotate: 90` or `270` occupies `height x width` of the page and a region that fits only because it is turned is inside it. The message names the region, the rectangle it occupies, the page and the page's size. That clause is **validity** and runs under both profiles: a rectangle outside its page makes `u2 > 1` and samples whatever the wrap mode returns, and `--atlas-in` already refuses the same rectangle at compile time (§0.2). Under `spine-html` also: `pma`, rotation, and two regions on one page over the same texels — a packed page must be **one part covering it exactly** (the unpacked convention) or a **tiling**, and what that message names is the pair that shares texels. **Or** the page file is not a PNG at all, and then nothing about its size is measured: the message carries the page's path and the size the atlas declares, and names what the file is by its first bytes — one of WebP, JPEG, GIF, KTX, KTX2 by its signature, or no image format rigc recognises, the bytes in hex either way — or calls it **truncated** when it begins as a PNG and runs out before its `IEND` (§0.2). That clause is validity too: nothing in rigc can read such a page back. **SKIP** when the atlas declares no page |
+| `A07_ATLAS_TEXT_SHAPE` | both | atlas text: a region name with stray whitespace, or a blank line splitting a page block. rigc writes the atlas, so this means a hand-edited file. Three sentences are about blank lines and name three different repairs: `line 1: the file begins with a blank line` (or `with N blank lines` for a run, one finding) is a blank before the first page name — delete it; `line N: the file ends with a blank line` (or `with N blank lines`, one finding) is a blank after the last page block's final line — delete it, since rigc ends the file on one newline; `line N: consecutive blank lines` is two blank lines side by side between the first page and the last — delete one. None of the three is `the last page block declares no region`, which means a page name and its fields with no region after them. rigc writes none of the three: under `--atlas-in` the pack's blank lines are put in rigc's shape on re-emission (§0.2), so any of them means a file rigc did not write, handed to `validate`. ⚠️ An atlas with **no page block at all** — no non-blank line — is not one of those: its subject is absent, so this reports **SKIP** naming the byte count it read, and so do the four rules below whose subject is a page ([#608](https://github.com/firejune/rigc/issues/608)). A rig whose skins need no art writes exactly that file (§3.4), and before #608 this row refused it with two findings naming a page block that was not there. What an empty atlas does **not** excuse is an attachment that wants a region out of it — that is `A08` |
+| `A08_REGION_NAMES_MATCH_ATTACHMENTS` | both | three things, and the message says which: an attachment whose `path` names **no region** of this atlas; a `path` carrying **stray whitespace**, printed quoted so you can see it; an **atlas region name** carrying stray whitespace (`A07` names that same line with its line number). The first two are read off the raw file **before** the loader is asked, so the miss is named here with the skin, the slot, the placeholder and the attachment's own name — the four things `AtlasAttachmentLoader`'s own `Region not found in atlas: <path> (attachment: <name>)` does not carry. There is no `spine-html` clause here — a placeholder is free to differ from the region its `path` names **SKIP** when no attachment names a region *and* the atlas declares none — both of its subjects at once |
 | `A09_ANIMATION_DURATION_MATCHES_SPEC` | both | the loaded duration ≠ the declared one, or the two sides disagree about which animations exist (R7). Asymmetric by design: a frame of slack for an animation that ends early, and none worth the name for a key *past* the declared end, which is the same rule §4.5 states at compile time — held here against a skeleton the compiler never saw. **SKIP** when neither side has an animation at all — a static rig has no duration |
-| `A10_NO_NAN_AFTER_STEPPING` | both | stepping the animation produced a `NaN` pose. Look for a degenerate curve or a zero scale. 🦴 **It also poses every bone `inherit` key at its own time** ([#733](https://github.com/firejune/rigc/issues/733)): the runtime resolves a mode by folding the case of its first letter and nothing else, and a spelling that misses is stored as **NaN** — the world position stays finite, `updateWorldTransform` matches no mode, and the bone keeps the rotation, scale and shear it had. The detail names the animation, the bone, the key's time and its spelling, beside the five. A bone whose *setup* spelling misses poses no mode at all, and is named the same way from the stepping loop. Neither is reachable from a rig spec — `build` refuses both spellings by name (§5.1) — so on a green build this clause is about files rigc did not write. Which mode a correct spelling poses is not judged here, because the lookup that resolved it is the one that would be checked **SKIP** when the skeleton carries no animation ([#580](https://github.com/firejune/rigc/issues/580)): the NaN is produced by stepping, and a static rig is never stepped — the same subject `A09` skips on |
+| `A10_NO_NAN_AFTER_STEPPING` | both | stepping the animation produced a `NaN` pose. Look for a degenerate curve or a zero scale. 🦴 **It also poses every bone `inherit` key at its own time**: the runtime resolves a mode by folding the case of its first letter and nothing else, and a spelling that misses is stored as **NaN** — the world position stays finite, `updateWorldTransform` matches no mode, and the bone keeps the rotation, scale and shear it had. The detail names the animation, the bone, the key's time and its spelling, beside the five. A bone whose *setup* spelling misses poses no mode at all, and is named the same way from the stepping loop. Neither is reachable from a rig spec — `build` refuses both spellings by name (§5.1) — so on a green build this clause is about files rigc did not write. Which mode a correct spelling poses is not judged here, because the lookup that resolved it is the one that would be checked **SKIP** when the skeleton carries no animation: the NaN is produced by stepping, and a static rig is never stepped — the same subject `A09` skips on |
 | `A11_NO_CLIPPING_ATTACHMENTS` | renderer | a clipping attachment; the target renderer skips them silently |
 | `A12_NO_DARK_COLOR` | renderer | a slot `dark` colour or an `rgba2`/`rgb2` timeline; parsed, then ignored |
-| `A13_MESH_BUDGET` | renderer | more mesh slots than the rig's `invariants.meshSlots`, or a mesh over its `invariants.meshTriangles`. Thin the mesh, or raise the budget in the rig spec. **SKIP** when the rig declares neither — which means *unmeasured*, not that the budget is inert: the same `meshSlots` is a **compile-time** refusal for rigc's own generators, before the gate (§3.7, issue #274) **SKIP** also when the rig budgets **only** triangles and the skeleton carries no mesh ([#580](https://github.com/firejune/rigc/issues/580)). A declared slot budget still PASSes there, because zero mesh slots is a count measured against a ceiling |
+| `A13_MESH_BUDGET` | renderer | more mesh slots than the rig's `invariants.meshSlots`, or a mesh over its `invariants.meshTriangles`. Thin the mesh, or raise the budget in the rig spec. **SKIP** when the rig declares neither — which means *unmeasured*, not that the budget is inert: the same `meshSlots` is a **compile-time** refusal for rigc's own generators, before the gate (§3.7) **SKIP** also when the rig budgets **only** triangles and the skeleton carries no mesh. A declared slot budget still PASSes there, because zero mesh slots is a count measured against a ceiling |
 | `A14_NO_FULL_FRAME_MESH` | renderer | a mesh spans the whole stage — a full-frame canvas that can never dirty-skip. **SKIP** when the skeleton declares no stage (§3.1): there is no full frame to span, and *unmeasured* must not print the same green as *measured and clear* |
-| `A15_IDLE_NO_MESH_BONE_KEYS` | renderer | the `idle` animation keys a bone that drives a mesh, directly or as a control bone. **SKIP** when there is no `idle` animation, or when the one there is carries no bone timeline — a rule whose subject does not exist is unmeasured and not satisfied ([#568](https://github.com/firejune/rigc/issues/568)) |
+| `A15_IDLE_NO_MESH_BONE_KEYS` | renderer | the `idle` animation keys a bone that drives a mesh, directly or as a control bone. **SKIP** when there is no `idle` animation, or when the one there is carries no bone timeline — a rule whose subject does not exist is unmeasured and not satisfied |
 | `A16_SKELETON_VERSION_4_3` | both | the `skeleton.spine` label is not on the 4.3 line (`4.3`, `4.3.N`, `4.3.N-suffix`) |
-| `A17_ATLAS_PAGE_FILES_EXIST` | both | a page the atlas declares is not a file. Check `--images` and `--out`. **SKIP** when the atlas declares no page ([#580](https://github.com/firejune/rigc/issues/580)) — as it is for `A06`, `A19` and `A27`; see `A07` ([#608](https://github.com/firejune/rigc/issues/608)) |
+| `A17_ATLAS_PAGE_FILES_EXIST` | both | a page the atlas declares is not a file. Check `--images` and `--out`. **SKIP** when the atlas declares no page — as it is for `A06`, `A19` and `A27`; see `A07` |
 | `A18_DETERMINISTIC_EMIT` | both | a second compile of the same inputs differed. That is a compiler bug, not a spec bug — report it |
-| `A19_OVERLAY_PNGS_HAVE_ALPHA` | renderer | an overlay part cannot draw a transparent pixel, so it would paint a solid rectangle over what is behind it. **The texels decide, on both routes** ([#777](https://github.com/firejune/rigc/issues/777)); the file header is only the fast negative. A file with no alpha channel (colour type 4 or 6) and no `tRNS` chunk has nowhere to keep a clear texel and is refused without being opened, by a sentence that names its colour type — so re-export it as RGBA, or as an indexed / greyscale PNG that keeps its `tRNS`. A file whose header says it **could** be transparent is opened and read until its first texel below full alpha; one clear texel passes, and none is refused in the words the packed route uses for a region, naming the file and what it can hold — `is opaque in every one of its 200x80 texels` … `its file can hold transparency — colour type 6 (truecolour + alpha) carries an alpha channel — and no texel uses it`. Saving as RGBA is not the repair: the runtime draws the texels, not the declaration. Until #777 the loose route stopped at the header, so the same fully opaque RGBA part passed a loose build and was refused by `--pack` of the same rig. On a loose page the file is the part, so the whole decoded image is the rectangle and no atlas coordinate is read. Only the base plate may be opaque, and which image that is is decided once for both routes ([#770](https://github.com/firejune/rigc/issues/770)): the plate the build names — on a cut manifest, the part whose window is the crop — and, only when it names none, an image at least the stage's size. The rig's statement comes first because the two can disagree: a stage stated small enough for an overlay to cover would otherwise exempt that overlay. A rig spec cannot name a base plate, so a stageless rig-spec build, and `validate <dir>` on a stageless skeleton, has nothing to decide it; an opaque part there is refused with *"nothing here decides which image that is: this skeleton declares no stage size to measure one against"* and the two ways to decide it — a `skeleton` stage the plate covers, or a cut manifest (for `validate`, the specs it was built from: `--rig`, `--motion` and the `--manifest`). Indexed-with-`tRNS` — the usual output of ImageMagick, "Export as PNG-8", GIMP's indexed mode, aseprite and pngquant — **passes**: it is transparent art. On a **shared** page the question is asked per REGION over the decoded page rather than per file, because a packed page's own file all but always declares transparency — its gutter is transparent — and the file-level question would then be answered by the packing rather than by the art ([#266](https://github.com/firejune/rigc/issues/266)). ⚠️ **That scan states its verdict over the texels it READ, and never over texels that are not on the page** ([#705](https://github.com/firejune/rigc/issues/705)): a rectangle partly on its page is judged over the part that is on it, and the message carries both counts — `opaque in every one of the 77 texels of its 12x8 rectangle at -1,-1 … the other 19 of the 96 it declares are not on the page and are not measured here`. A rectangle with **no** texel on the page is reported **not measured** by name — the region, its rectangle, the page image's size, and the pointer to `A06`, which is the rule that judges a region's rectangle — and no verdict about opacity is printed at all. ⚠️ **A page whose IMAGE is not the size the atlas declares for it is the same non-measurement for every region on it** ([#715](https://github.com/firejune/rigc/issues/715)), and #705's clause does not cover that case: a page rescaled after packing leaves most rectangles partly on it, at coordinates that address a different part of the picture, so the scan came back with a confident verdict over texels nobody had located — on a two-region pack at a uniform 0.5 an opaque part's failure **disappeared**, the scan having found a transparent texel 32 texels away from it. The row names the page's two sizes and points at `A06`, which judges the page grid and prints the header that repairs it (§0.2). It stays a failure rather than becoming a SKIP because a SKIP is per ASSERTION: it would delete the verdicts on every other part of the same page, and an assertion cannot be skipped and failed at once without the report counting it twice. Before #705 the walk was silent about its own reach, so a part nobody could read printed *opaque in every one of its 12x8 texels* over zero of them, which is a refusal pointing at the wrong file: the art it names may be transparent, and the repair is the rectangle in `A06`'s row above. ⚠️ **A page file that cannot be read as PNG at all is the same non-measurement for every part on it** ([#732](https://github.com/firejune/rigc/issues/732)): one row per page naming its parts and pointing at `A06`, which names what the file is — where it used to print `threw: cannot decode PNG …: unexpected end of file`, an inflate error about a file that was never a PNG. **SKIP** when the atlas declares no page ([#580](https://github.com/firejune/rigc/issues/580)) |
-| `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)) |
+| `A19_OVERLAY_PNGS_HAVE_ALPHA` | renderer | an overlay part cannot draw a transparent pixel, so it would paint a solid rectangle over what is behind it. **The texels decide, on both routes**; the file header is only the fast negative. A file with no alpha channel (colour type 4 or 6) and no `tRNS` chunk has nowhere to keep a clear texel and is refused without being opened, by a sentence that names its colour type — so re-export it as RGBA, or as an indexed / greyscale PNG that keeps its `tRNS`. A file whose header says it **could** be transparent is opened and read until its first texel below full alpha; one clear texel passes, and none is refused in the words the packed route uses for a region, naming the file and what it can hold — `is opaque in every one of its 200x80 texels` … `its file can hold transparency — colour type 6 (truecolour + alpha) carries an alpha channel — and no texel uses it`. Saving as RGBA is not the repair: the runtime draws the texels, not the declaration. On a loose page the file is the part, so the whole decoded image is the rectangle and no atlas coordinate is read. Only the base plate may be opaque, and which image that is is decided once for both routes: the plate the build names — on a cut manifest, the part whose window is the crop — and, only when it names none, an image at least the stage's size. The rig's statement comes first because the two can disagree: a stage stated small enough for an overlay to cover would otherwise exempt that overlay. A rig spec cannot name a base plate, so a stageless rig-spec build, and `validate <dir>` on a stageless skeleton, has nothing to decide it; an opaque part there is refused with *"nothing here decides which image that is: this skeleton declares no stage size to measure one against"* and the two ways to decide it — a `skeleton` stage the plate covers, or a cut manifest (for `validate`, the specs it was built from: `--rig`, `--motion` and the `--manifest`). Indexed-with-`tRNS` — the usual output of ImageMagick, "Export as PNG-8", GIMP's indexed mode, aseprite and pngquant — **passes**: it is transparent art. On a **shared** page the question is asked per REGION over the decoded page rather than per file, because a packed page's own file all but always declares transparency — its gutter is transparent — and the file-level question would then be answered by the packing rather than by the art. ⚠️ **That scan states its verdict over the texels it READ, and never over texels that are not on the page**: a rectangle partly on its page is judged over the part that is on it, and the message carries both counts — `opaque in every one of the 77 texels of its 12x8 rectangle at -1,-1 … the other 19 of the 96 it declares are not on the page and are not measured here`. A rectangle with **no** texel on the page is reported **not measured** by name — the region, its rectangle, the page image's size, and the pointer to `A06`, which is the rule that judges a region's rectangle — and no verdict about opacity is printed at all. ⚠️ **A page whose IMAGE is not the size the atlas declares for it is the same non-measurement for every region on it**, and the clause above does not cover that case: a page rescaled after packing leaves most rectangles partly on it, at coordinates that address a different part of the picture, so a scan would come back with a confident verdict over texels nobody had located — on a two-region pack at a uniform 0.5 an opaque part's failure **disappears**, the scan finding a transparent texel 32 texels away from it. The row names the page's two sizes and points at `A06`, which judges the page grid and prints the header that repairs it (§0.2). It stays a failure rather than becoming a SKIP because a SKIP is per ASSERTION: it would delete the verdicts on every other part of the same page, and an assertion cannot be skipped and failed at once without the report counting it twice. ⚠️ **A page file that cannot be read as PNG at all is the same non-measurement for every part on it**: one row per page naming its parts and pointing at `A06`, which names what the file is. **SKIP** when the atlas declares no page |
+| `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. Fix the rig spec's `controls`/`chain`, or the manifest's `control_bones`. **SKIP** when the skeleton carries no mesh attachment |
 | `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]`, which says `` physics "C" has damping 1.5; must be inside [0, 1] — the per-step decay is `damping ** (60 * step)`, and the runtime runs this value finitely, so refusing it is rigc's call rather than the runtime's: above 1 every velocity grows on every step and the offset diverges ``, 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; the runtime runs this value finitely, so refusing it is rigc's call rather than the runtime's: at 0 `update` returns before it does anything (`PhysicsConstraint.js:109-111`), so the constraint is muted — rest it above 0, or key its mix above 0 in an animation ``. ⚠️ Every reason A23 prints for a setup value is that value's row `basis` arm (§4.4's table, [#798](https://github.com/firejune/rigc/issues/798)) — an arithmetic arm names its expression (`physics "C" has massInverse Infinity; mass must be > 0 — at 0 …`), a behavioural one says it is rigc's call and what the value does. A setup `mix` **below** 0 is told the jiggle is applied inverted, not that it is muted: until #798 it read "it is muted", of a constraint measured moving its bone by exactly the opposite of a positive mix (`T115`). 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)) |
+| `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 |
+| `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 — or has `damping` outside `[0, 1]`, which says `` physics "C" has damping 1.5; must be inside [0, 1] — the per-step decay is `damping ** (60 * step)`, and the runtime runs this value finitely, so refusing it is rigc's call rather than the runtime's: above 1 every velocity grows on every step and the offset diverges ``, the bound read off the row the key's refusal reads; `1` and `0` are inside, since both are finite at every rate — **at rest, and on every physics timeline key**. 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. 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; the runtime runs this value finitely, so refusing it is rigc's call rather than the runtime's: at 0 `update` returns before it does anything (`PhysicsConstraint.js:109-111`), so the constraint is muted — rest it above 0, or key its mix above 0 in an animation ``. ⚠️ Every reason A23 prints for a setup value is that value's row `basis` arm (§4.4's table) — an arithmetic arm names its expression (`physics "C" has massInverse Infinity; mass must be > 0 — at 0 …`), a behavioural one says it is rigc's call and what the value does. A setup `mix` **below** 0 is told the jiggle is applied inverted, not that it is muted: such a constraint is measured moving its bone by exactly the opposite of a positive mix. 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. `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)), so this sentence is met on a file, never on a decompiled rebuild. **SKIP** when the skeleton declares no physics constraint — the same sentence `A36` and `A37` print 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 |
 | `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 |
-| `A27_REGION_NAME_MATCHES_PAGE_FILENAME` | renderer | a single-region page whose region name is not the PNG's basename. **SKIP** when the atlas declares no region ([#580](https://github.com/firejune/rigc/issues/580)) |
+| `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: the completeness clause reads it as every declared slot lost and names them |
+| `A27_REGION_NAME_MATCHES_PAGE_FILENAME` | renderer | a single-region page whose region name is not the PNG's basename. **SKIP** when the atlas declares no region |
 | `A28_RIBBON_ROWS_SHARE_WEIGHTS` | archetype | the two vertices of a ribbon row carry different weights, so the strip would change width. **SKIPs** on authored geometry and on a contour mesh — neither has rows rigc paired |
 | `A29_STROKE_WITHIN_CONTACT_DEPTH` | archetype | the animation drives deeper than the manifest's measured contact depth |
 | `A30_STROKE_WITHIN_CAP_CONTAINMENT` | archetype | the animation drives past the measured containment ceiling, or scales a bone in the axis subtree |
 | `A31_DRAW_ORDER_OFFSETS_RESOLVE` | both | a draw-order key names a slot the skeleton does not have, offsets one slot twice, puts a slot outside the slots array, or lists its offsets out of slot order (§4.7). The only assertion that runs **before** `A00` — the last of those shapes makes the loader spin rather than return, so the round trip is refused instead of attempted |
 | `A32_EVENT_KEYS_RESOLVE` | both | an event key fires a name the skeleton's `events` block does not declare, sits earlier in time than the key before it, or sets `volume`/`balance` on an event with no `audio` (§4.8). **SKIP** when no animation carries an event timeline |
 | `A33_VERTEX_ATTACHMENT_GEOMETRY` | both | a bounding box, clipping polygon or path whose `vertexCount` is missing or disagrees with its vertex array, a weighted run that decodes to the wrong number of vertices or an out-of-range bone index, a clipping `end` naming a slot the skeleton does not have, a path whose vertex count is not a multiple of 3, or a path `lengths` array that does not strictly increase (§3.4). **SKIP** when the skeleton carries none of the three |
-| `A34_CONSTRAINT_TIMELINE_TARGETS` | both | an `ik`, `transform`, `path`, `physics` or `slider` timeline names a constraint the skeleton does not declare, names one of another type, or carries no keys at all (§4.4, §4.9, §4.10, §4.12). The last is silent: the parser reads key 0, finds nothing, and skips the timeline. The **empty** name under `physics` is not a miss — it is the timeline that names no constraint (§4.4's `"*"`), and it is refused only when it reaches none: `animation "A" physics constraint "" timeline "P": a physics group that names no constraint writes every physics constraint declaring "PGlobal": true, and none of "C", … does — the parser loads it, the runtime walks every constraint, and no constraint takes the key` ([#726](https://github.com/firejune/rigc/issues/726)). Who it reaches is asked of the runtime's own `PhysicsConstraintTimeline.global` on the file's constraints — the reading `A23` and `A42` share. **SKIP** when no animation carries one |
-| `A35_DEFORM_KEYS_FIT_THE_ATTACHMENT` | both | a deform key's run runs past the end of the attachment's deform array, holds a non-finite number, has an empty key array, or names a skin/slot/attachment triple that does not resolve (§4.11). The overrun is the quiet one — the parser copies into a `Float32Array` and drops the tail. ⛔ It does **not** require pair alignment: the runtime has no such rule and a trimmed editor run legitimately starts and ends mid-pair (§4.11, issue #262). **SKIP** when no animation carries a deform timeline |
-| `A36_PATH_CONSTRAINT_EFFECTIVE` | both | a path constraint whose slot has no path attachment in any skin, one that constrains no bone, or one whose three mixes are all 0 at setup with no animation keying any of them **above 0** (§3.5.1, §4.12). The first is the quiet one: `update()` returns on its first line and the constraint reports mixes it never applies. The third reads the values the loaded timeline poses — keys and Bezier samples alike — the way `A23` reads a physics `mix`, so a `mix` timeline keying 0 only is not a rescue: [measured] it poses every bone exactly where no timeline does, and before [#752](https://github.com/firejune/rigc/issues/752) it passed. The detail says both halves: `path constraint "P" has mixRotate 0, mixX 0 and mixY 0 at setup and none of the 2 animations keys its mix above 0; update() returns on all-zero mixes, so nothing ever puts a bone on the path — rest one of the three above 0, or key its mix above 0 in an animation`. **SKIP** when the skeleton declares no path constraint |
-| `A37_SLIDER_CONSTRAINT_EFFECTIVE` | both | a slider whose animation carries no timeline, one that loops a zero-length animation (the applied time is NaN), one driving off a bone at `scale: 0`, or one muted at setup with no animation keying its `mix` **above 0** (§3.5.2, §4.12) — the same reading as `A36`'s, so a `mix` timeline keying 0 only is no rescue ([#752](https://github.com/firejune/rigc/issues/752)): `slider "S" has mix 0 at setup and none of the 2 animations keys its mix above 0; update() returns on mix 0 — rest it above 0, or key its mix above 0 in an animation`. **SKIP** when the skeleton declares no slider |
+| `A34_CONSTRAINT_TIMELINE_TARGETS` | both | an `ik`, `transform`, `path`, `physics` or `slider` timeline names a constraint the skeleton does not declare, names one of another type, or carries no keys at all (§4.4, §4.9, §4.10, §4.12). The last is silent: the parser reads key 0, finds nothing, and skips the timeline. The **empty** name under `physics` is not a miss — it is the timeline that names no constraint (§4.4's `"*"`), and it is refused only when it reaches none: `animation "A" physics constraint "" timeline "P": a physics group that names no constraint writes every physics constraint declaring "PGlobal": true, and none of "C", … does — the parser loads it, the runtime walks every constraint, and no constraint takes the key`. Who it reaches is asked of the runtime's own `PhysicsConstraintTimeline.global` on the file's constraints — the reading `A23` and `A42` share. **SKIP** when no animation carries one |
+| `A35_DEFORM_KEYS_FIT_THE_ATTACHMENT` | both | a deform key's run runs past the end of the attachment's deform array, holds a non-finite number, has an empty key array, or names a skin/slot/attachment triple that does not resolve (§4.11). The overrun is the quiet one — the parser copies into a `Float32Array` and drops the tail. ⛔ It does **not** require pair alignment: the runtime has no such rule and a trimmed editor run legitimately starts and ends mid-pair (§4.11). **SKIP** when no animation carries a deform timeline |
+| `A36_PATH_CONSTRAINT_EFFECTIVE` | both | a path constraint whose slot has no path attachment in any skin, one that constrains no bone, or one whose three mixes are all 0 at setup with no animation keying any of them **above 0** (§3.5.1, §4.12). The first is the quiet one: `update()` returns on its first line and the constraint reports mixes it never applies. The third reads the values the loaded timeline poses — keys and Bezier samples alike — the way `A23` reads a physics `mix`, so a `mix` timeline keying 0 only is not a rescue: [measured] it poses every bone exactly where no timeline does. The detail says both halves: `path constraint "P" has mixRotate 0, mixX 0 and mixY 0 at setup and none of the 2 animations keys its mix above 0; update() returns on all-zero mixes, so nothing ever puts a bone on the path — rest one of the three above 0, or key its mix above 0 in an animation`. **SKIP** when the skeleton declares no path constraint |
+| `A37_SLIDER_CONSTRAINT_EFFECTIVE` | both | a slider whose animation carries no timeline, one that loops a zero-length animation (the applied time is NaN), one driving off a bone at `scale: 0`, or one muted at setup with no animation keying its `mix` **above 0** (§3.5.2, §4.12) — the same reading as `A36`'s, so a `mix` timeline keying 0 only is no rescue: `slider "S" has mix 0 at setup and none of the 2 animations keys its mix above 0; update() returns on mix 0 — rest it above 0, or key its mix above 0 in an animation`. **SKIP** when the skeleton declares no slider |
 | `A38_SKIN_MEMBERS_ARE_SKIN_REQUIRED` | both | a bone or constraint a skin activates that is not `skinRequired` (the list changes nothing), or one that is `skinRequired` and no skin activates (it is never active). Two keys in two places, and only together do they mean "this belongs to that skin" (§3.4.1). **SKIP** when no skin activates anything and nothing is `skinRequired` |
-| `A39_DEFORM_KEEPS_TRIANGLE_WINDING` | archetype | a `deform` key reverses a triangle's winding, so the mesh has locally turned inside out and draws its texture backwards there (§4.11). The detail names the animation, the slot, the attachment, the key index and time, and each reversed triangle with its vertex triple and its signed area before and after. Measured at the key's **own** time, deformed against the same posed bones undeformed, so a mirrored slot bone cancels and a wrong *projection* with intact winding is correctly silent. A projection past its fold angle is the usual cause — [FACE.md §4.2](FACE.md) has the closed form. Legitimate art does fold, so declare `invariants.deformMayFold` (§3.7) for a slot that folds on purpose. ⚠️ A key whose slot **draws no pixels at that key's own time** — faded to alpha exactly 0, or showing another attachment — is measured and then passed over, because "draws its texture backwards" is false when nothing of it is drawn; the key is named on the stats line (`deformKeysNotDrawn`) and in the `DEFORM` block, never silently. The bar is **exactly 0**: at alpha 0.5 the fold is still refused and the alpha is in the message. It is per key and per time, so the same slot folding at full alpha in another animation is refused as before. ⚠️ And the **spans between** consecutive keys are scanned too (§4.11.3, issue #403): the runtime interpolates, so a deform inside its fold angle at every key can be past it in between. That refusal is its own sentence — `BETWEEN key 0 (t=0s) and key 1 (t=0.5s), at t=…` — with the time solved for in closed form and then posed and measured like any key, alpha read at that same moment. `deformSpansScanned` says on every green build that the scan ran. ⚠️ And the **frame** it poses in is the one the animation is reached in (§4.11.4, issue #407): on a track when nothing applies it, and otherwise once per **slider**, with that slider's mapping inverted and its bone driven until the runtime selects the key's own time — because a slider picks the time, so the two are one number and posing them independently is a frame that never occurs. The frame is on every `DEFORM` line, on the stats line as `deformFrames`, and in the refusal itself when it is not the track. A key at a time **no dial value selects** is measured in the frame the runtime does land on, left out of `deformKeysMeasured` and named as `deformKeysUnreachable`/`deformUnreachable` — never refused and never silent. ⚠️ And the **skin** it poses in is the one the timeline is keyed on (§4.11.5, issue #583), since a deform's address is a `skin / slot / attachment` triple: the pose wears that skin, which also switches on any `skin: true` bone or constraint it activates, and the "nothing is drawn" sentence names the skin it was read under. **SKIP** when no animation carries a deform timeline, when nothing keyed has triangles, when every mesh keyed is exempt, when every key measured draws no pixels or is unreachable *and no span between them folds where anything is drawn*, or when there is no rig info at all |
-| `A40_SLIDERS_COMPOSE_ON_A_SHARED_TARGET` | both | two or more sliders whose animations key the same timeline, where a later one is not `additive` — it writes that property outright at `mix: 1` and every earlier slider on it is dead (§3.5.2). Also fires when the shared timeline **cannot** be applied additively (a slot colour, an attachment swap, a draw order, an ik mix, a path's `spacing`, most physics properties), where `"additive": true` is not the fix and one of the two has to go. ⭐ Which of the two it is, is **posed rather than read off `Timeline.additive`**: the shared timeline is applied twice with `add` set and the detail says what it did ([#655](https://github.com/firejune/rigc/issues/655) — two classes declare that flag falsely about themselves, so a path constraint's `mix` and a slider's `time` were refused although they compose). The detail names the bone or slot and the property, every slider keying it in `constraints` order with its flag, which one wins today, and the class that was posed. Four shapes are deliberately not findings: a slider below `mix: 1` or with its `mix` keyed (the apply is then a lerp from the current pose, not an overwrite), two `skinRequired` sliders no skin activates together, two sliders on different properties, and a shared timeline that writes **nothing a pose holds** — an `events` timeline fires no event under a slider (`firedEvents` is null), so neither slider has anything there for the other to erase. **SKIP** when fewer than two sliders are at full authority; a PASS means two were compared |
-| `A41_PHYSICS_SURVIVES_EDITOR_ROUND_TRIP` | both | a physics constraint driving a component the **Spine editor** cannot hold, on a rig that declared `invariants.editorRoundTrip` (§3.7). The editor's physics model holds `x` and `y` only, with no cap on how many at once, so a constraint driving `rotate`, `scaleX` or `shearX` is imported, exported and handed back driving **nothing** — measured over three rigs and twelve constraints with the predictions written first ([#540](https://github.com/firejune/rigc/issues/540)). The detail names the constraint and each component. ⚠️ rigc's own output is correct — every runtime plays a rotation jiggle — so this is opt-in and the default is *not* silence: on a rig that declares nothing it **SKIPs**, and the SKIP names the constraint and the component anyway, so an author learns without having asked. Fix by driving the constraint in `x`/`y`, or by dropping the declaration if the rig never goes near the editor. Disjoint from `A23_PHYSICS_CONSTRAINT_EFFECTIVE` by construction: A23 refuses an **empty** driven set, which is what comes back from the editor, and this refuses a non-empty one that will not survive going in. **SKIP** also when the rig declares the editor and carries no physics constraint at all |
-| `A42_DRIVEN_CONSTRAINTS_UPDATE_AFTER_THEIR_DRIVER` | both | a slider whose animation keys a property of a constraint **at or before it** in `constraints` (§3.5.2) — a slider's `mix` or `time`, an ik or transform mix, a path `position`, `spacing` or `mix`, any physics value. That array is the update order for every kind, and each constraint reads its own applied pose when its turn comes — `Slider.update` takes `mix` as the alpha it applies with and `time` as the time it applies at, `PhysicsConstraint.update` returns on `mix` 0 before reading the rest — so the key lands after the only read of it and `Posed.resetConstrained` discards it before the next frame: what the driven constraint drives is dead at every position of the driving dial, although its pose still holds the number ([#658](https://github.com/firejune/rigc/issues/658), [#665](https://github.com/firejune/rigc/issues/665)). The detail names the slider, the driven constraint with its kind, both array indices, the property, the runtime class whose `update` reads it, and the animation the key sits in. Fix by moving the driver earlier, or by keying that property from a slider that already is. **The two indices equal is the same failure**: a slider cannot key its own `mix` or `time`, and one muted at setup that keys its own `mix` up never applies anything at all — `A37` is silent there, because it asks whether *an* animation keys the mix and not which one. **Two shapes it deliberately leaves out**, both measured: a `physics` `reset` key, which fires on a crossed frame time and so never fires from a slider at all, in either order — the reorder would repair nothing; and a physics timeline naming no constraint, which is every physics constraint declaring that property global and IS refused for the ones already run. Disjoint from `A40` by construction: `A40` asks who writes a shared property last and excludes every slider whose `mix` is keyed, this asks whether anything reads what was written. **SKIP** when the skeleton declares no slider, and when no slider's animation keys a constraint property — that SKIP names any `reset` keys it found — a pass means a driver and a driven were compared |
-| `A43_TWO_COLOR_TINT_LOADS_AND_POSES_AS_WRITTEN` | both | a slot's `dark` (§3.3) or an `rgba2` / `rgb2` timeline (§4.4) that the runtime does not hold as the file states it. Three shapes, all of which parse in silence: a `dark` the slot reader **drops** — it takes the field through a truthiness test, so `""` is discarded without a word and the slot renders with one colour; a `dark` that is **not six hex digits** — `Color.setFromString` slices fixed offsets and stores whatever `parseInt` gives back, so `"4020"` loads a channel of `NaN`; and an `rgba2` or `rgb2` timeline on a slot with **no `dark` at all**, where the runtime allocates no dark colour and the first `state.apply` throws in the consumer's process. The keyed half is read by posing: the animation is stepped to each key's own time — at the key **as the runtime stores it**: spine-core keeps key times as 32-bit floats, so a key at `0.2` is posed at `0.20000000298…`, the later of the two, and not one float step before it, where a first key still shows the setup value and a stepped key the one before (a correct file was refused that way until [#771](https://github.com/firejune/rigc/issues/771)), and the posed `color` and `darkColor` are compared against the hex the key states, to half a quantisation step (`1/510`). The detail names the slot, the value found and the value required. ⚠️ The required value is parsed **here** and not through `Color.fromString`, because a check that read it out of the parser it is checking would agree with that parser whatever it did. `compile.ts` refuses the third shape outright in a rig rigc builds; this is the same fact held against a skeleton it did not write. An `rgb2` key's light colour is compared over its three channels only: the light alpha is not its to state, and that it is left where it was is measured in the selftest (`S85`). **SKIP** when no slot declares a `dark` and no animation keys an `rgba2` or `rgb2` — there is then no two-colour tint to read back |
-| `A44_LINKED_MESH_STATES_NO_GEOMETRY_OF_ITS_OWN` | both | a **linked mesh** (§3.4) — `type: "linkedmesh"`, or a `type: "mesh"` carrying `source` — 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 `setSourceMesh` fills the attachment with the source's arrays instead: the file says one mesh and every runtime draws another, in silence. The detail names the attachment by skin, slot and placeholder, every key it states, the `source` and where the parser looks for it — the two defaults spelled out, because an omitted `skin` is the **default** skin rather than the one the link is written in — and the shape the keys describe beside the shape the attachment loaded. ⚠️ **`width`/`height` are not part of this.** `setSourceMesh` overwrites both with the source's, so they are as dead at runtime — but the parser reads them (`:569-570`), the format carries them on a link and rigc emits them, so refusing them would refuse every link rigc writes (§3.4). `compile.ts` refuses the same shape outright in a rig rigc builds (§5.1); this is that fact held against a skeleton it did not write, and `ingest` reports it as `ATTACHMENT_LINK_GEOMETRY` ([INGEST §2.0](INGEST.md)). **SKIP** when no attachment in the skeleton takes its geometry from another — which is almost every skeleton, so a pass here means a link was read ([#710](https://github.com/firejune/rigc/issues/710)) |
-| `A45_SEPARABLE_COLOR_TIMELINES_OWN_THEIR_CHANNELS_AND_POSE_AS_WRITTEN` | both | an `rgb` or `alpha` timeline (§4.4) the runtime does not hold as the file states it, in one of two shapes that both parse in silence. **A channel keyed twice**: another colour timeline of the same slot in the same animation poses a channel this one poses — `rgba` beside `alpha` is the shape a converter leaves when it writes a separable `rgb` back as `rgba` next to the `alpha` it kept. Every colour timeline poses its channels at every time, the setup value before its first key included, so the one the file states later overwrites the other everywhere; the detail names both timelines, the channel, and which one survives. **A key not posed as written**: the animation is stepped to each key's own time — at the key **as the runtime stores it**: spine-core keeps key times as 32-bit floats, so a key at `0.2` is posed at `0.20000000298…`, the later of the two, and not one float step before it, where a first key still shows the setup value and a stepped key the one before (a correct file was refused that way until [#771](https://github.com/firejune/rigc/issues/771)), and the posed r g b (for `rgb`, against the hex, to half a quantisation step) or alpha (for `alpha`, against `value`, whose absence the parser reads as 0) is compared — a colour that is not six hex digits loads as NaN, and a key whose time another key repeats is read by nothing. ⚠️ An `rgb` alone written as an `rgba` holding the setup alpha is **not** caught and cannot be from the file: it is a correct `rgba`, and the difference shows only under another track that moves the alpha. The loaded timeline class and the channels a separable timeline leaves alone are measured in the selftest (`S83`–`S85`) rather than here, because against the linked parser neither can come out wrong. The channel table is `SLOT_COLOR_CHANNELS` in `src/timelines.ts`, shared with the compiler's refusal and held to the runtime's own property ids (`S89`). **SKIP** when no animation keys an `rgb` or `alpha` — there is then no separable slot colour to read back |
-| `A46_SEQUENCE_ATTACHMENTS_SHOW_THE_FRAME_THE_FILE_STATES` | both | a **numbered series** (§3.4.3, §4.13) that the runtime does not show as the file states it. Every shape below loads without a word, measured on spine-core 4.3.13 ([#729](https://github.com/firejune/rigc/issues/729)). **The block**: a `sequence` with no `count` (`readSequence` reads 0, and the attachment holds no region) or a `setup` at or past `count` (`Sequence.resolveIndex` clamps it to the last frame). **The keys**: a `mode` outside the seven — `hold`, `once`, `loop`, `pingpong`, `onceReverse`, `loopReverse`, `pingpongReverse` — loads as `hold`; an `index` that is fractional (`index << 4` truncates it) or past the end (clamped); an advancing mode at an effective delay of 0 (the parser carries a key's `delay` from the key before; `(time - keyTime) / 0` is Infinity and `Infinity \| 0` is 0, so it never advances); a timeline on an attachment that carries no block (the parser gives every region a one-region series, so every mode shows it). **The pose**: every key is stepped to mid-frame sample times — enough to wrap every mode, and a `hold` key to its own time as the runtime stores it, a 32-bit float ([#771](https://github.com/firejune/rigc/issues/771)) — and the region the slot shows is held to the frame the file's own statement gives, the arithmetic of `SequenceTimeline.applyToSlot` and the names of `Sequence.getPath` transcribed rather than read off the loaded timeline, so the check is not the runtime agreeing with itself. Before the first key the frame is `setup`. ⚠️ A sample where the slot shows another attachment is not compared, because the runtime writes nothing there; a timeline with no comparable sample is counted in `stats.sequenceSamplesUnshown`. `compile.ts` refuses every one of these shapes in a spec (§5.1); this is them held against a skeleton it did not write. **SKIP** when no attachment carries a `sequence` block and no animation keys a `sequence` timeline |
-| `A47_IK_CONSTRAINT_NOT_MUTED_THROUGHOUT` | both | an ik constraint resting at `mix` 0 that no animation keys **away from 0** (§4.9, §4.12). `IkConstraint.update` returns on `mix === 0`, so it sits in the update cache and moves nothing. The keys are read the way `A23`/`A36`/`A37` read theirs — every value the loaded timeline poses on its `mix` channel, Bezier samples included — so a timeline keying 0 only is no rescue: [measured] it poses every bone exactly where the same rig with no constraint does, and before [#765](https://github.com/firejune/rigc/issues/765) it passed. Live is the runtime's `!== 0`, so a negative mix is not refused. `ik constraint "C" has mix 0 at setup and none of the 1 animation keys its mix above 0; update() returns on mix 0, so "upper" never reaches for "goal" — rest it above 0, or key its mix above 0 in an animation, or declare that the consumer drives its mix, in the rig spec as invariants.consumerDrivenMix: [{ "constraint": "C", "type": "ik", "why": … }]`. A constraint the rig spec declares in `invariants.consumerDrivenMix` (§3.7) is not measured, and one the file also switches on is refused: `ik constraint "C" is declared in the rig spec as invariants.consumerDrivenMix, and the file already switches it on — … — so the declaration exempts nothing; drop the entry` ([#784](https://github.com/firejune/rigc/issues/784)). **SKIP** when the skeleton declares no ik constraint, and **SKIP by name** when every ik constraint it declares is declared consumer-driven: `every ik constraint here is declared in the rig spec as invariants.consumerDrivenMix, so its mix is the consumer's to set and nothing in this file shows it moving — "C" (why: …): it rests muted and none of the 1 animation keys its mix above 0`. With a live one beside it the rule measures that one and the stats line names the declared (`ikConsumerDriven`) |
-| `A48_TRANSFORM_CONSTRAINT_NOT_MUTED_THROUGHOUT` | both | a transform constraint none of whose mixes **for a property it drives** is away from 0 at setup or on any value an animation poses (§4.10, §4.12), or one whose `properties` name no `to` at all. A property is applied only when its own mix `!== 0`, and a key that omits a mix reads it as 1, so the six-mix early return of `TransformConstraint.update` would take a key of `mixRotate: 0` alone as a rescue — [measured] that key, and one keying `mixX` 1 on a rotate-only constraint, pose every bone exactly where no constraint does ([#765](https://github.com/firejune/rigc/issues/765)). A negative mix runs, and five transforms in the editor's example exports rest at −1. `transform constraint "C" drives rotate and has mixRotate 0 at setup, and none of the 1 animation keys its mix above 0; a mix is read only for a property the constraint drives, and update() skips each one at 0, so nothing ever moves "follower" — rest mixRotate above 0, or key its mix above 0 in an animation, or declare that the consumer drives its mix, in the rig spec as invariants.consumerDrivenMix: [{ "constraint": "C", "type": "transform", "why": … }]`. A constraint the rig spec declares in `invariants.consumerDrivenMix` (§3.7) is not measured, and one the file also switches on is refused as `A47`'s is; one that drives no property is refused with its own sentence declared or not, since no mix it carries is read by anybody ([#784](https://github.com/firejune/rigc/issues/784)). **SKIP** when the skeleton declares no transform constraint, and **SKIP by name** when every transform constraint it declares is declared consumer-driven: `every transform constraint here is declared in the rig spec as invariants.consumerDrivenMix, so its mix is the consumer's to set and nothing in this file shows it moving — "C" (why: …): it rests muted and none of the 1 animation keys its mix above 0`. With a live one beside it the stats line names the declared (`transformConsumerDriven`) |
+| `A39_DEFORM_KEEPS_TRIANGLE_WINDING` | archetype | a `deform` key reverses a triangle's winding, so the mesh has locally turned inside out and draws its texture backwards there (§4.11). The detail names the animation, the slot, the attachment, the key index and time, and each reversed triangle with its vertex triple and its signed area before and after. Measured at the key's **own** time, deformed against the same posed bones undeformed, so a mirrored slot bone cancels and a wrong *projection* with intact winding is correctly silent. A projection past its fold angle is the usual cause — [FACE.md §4.2](FACE.md) has the closed form. Legitimate art does fold, so declare `invariants.deformMayFold` (§3.7) for a slot that folds on purpose. ⚠️ A key whose slot **draws no pixels at that key's own time** — faded to alpha exactly 0, or showing another attachment — is measured and then passed over, because "draws its texture backwards" is false when nothing of it is drawn; the key is named on the stats line (`deformKeysNotDrawn`) and in the `DEFORM` block, never silently. The bar is **exactly 0**: at alpha 0.5 the fold is still refused and the alpha is in the message. It is per key and per time, so the same slot folding at full alpha in another animation is still refused. ⚠️ And the **spans between** consecutive keys are scanned too (§4.11.3): the runtime interpolates, so a deform inside its fold angle at every key can be past it in between. That refusal is its own sentence — `BETWEEN key 0 (t=0s) and key 1 (t=0.5s), at t=…` — with the time solved for in closed form and then posed and measured like any key, alpha read at that same moment. `deformSpansScanned` says on every green build that the scan ran. ⚠️ And the **frame** it poses in is the one the animation is reached in (§4.11.4): on a track when nothing applies it, and otherwise once per **slider**, with that slider's mapping inverted and its bone driven until the runtime selects the key's own time — because a slider picks the time, so the two are one number and posing them independently is a frame that never occurs. The frame is on every `DEFORM` line, on the stats line as `deformFrames`, and in the refusal itself when it is not the track. A key at a time **no dial value selects** is measured in the frame the runtime does land on, left out of `deformKeysMeasured` and named as `deformKeysUnreachable`/`deformUnreachable` — never refused and never silent. ⚠️ And the **skin** it poses in is the one the timeline is keyed on (§4.11.5), since a deform's address is a `skin / slot / attachment` triple: the pose wears that skin, which also switches on any `skin: true` bone or constraint it activates, and the "nothing is drawn" sentence names the skin it was read under. **SKIP** when no animation carries a deform timeline, when nothing keyed has triangles, when every mesh keyed is exempt, when every key measured draws no pixels or is unreachable *and no span between them folds where anything is drawn*, or when there is no rig info at all |
+| `A40_SLIDERS_COMPOSE_ON_A_SHARED_TARGET` | both | two or more sliders whose animations key the same timeline, where a later one is not `additive` — it writes that property outright at `mix: 1` and every earlier slider on it is dead (§3.5.2). Also fires when the shared timeline **cannot** be applied additively (a slot colour, an attachment swap, a draw order, an ik mix, a path's `spacing`, most physics properties), where `"additive": true` is not the fix and one of the two has to go. ⭐ Which of the two it is, is **posed rather than read off `Timeline.additive`**: the shared timeline is applied twice with `add` set and the detail says what it did (two classes declare that flag falsely about themselves: a path constraint's `mix` and a slider's `time` compose although the flag says they do not). The detail names the bone or slot and the property, every slider keying it in `constraints` order with its flag, which one wins today, and the class that was posed. Four shapes are deliberately not findings: a slider below `mix: 1` or with its `mix` keyed (the apply is then a lerp from the current pose, not an overwrite), two `skinRequired` sliders no skin activates together, two sliders on different properties, and a shared timeline that writes **nothing a pose holds** — an `events` timeline fires no event under a slider (`firedEvents` is null), so neither slider has anything there for the other to erase. **SKIP** when fewer than two sliders are at full authority; a PASS means two were compared |
+| `A41_PHYSICS_SURVIVES_EDITOR_ROUND_TRIP` | both | a physics constraint driving a component the **Spine editor** cannot hold, on a rig that declared `invariants.editorRoundTrip` (§3.7). The editor's physics model holds `x` and `y` only, with no cap on how many at once, so a constraint driving `rotate`, `scaleX` or `shearX` is imported, exported and handed back driving **nothing** — measured over three rigs and twelve constraints with the predictions written first. The detail names the constraint and each component. ⚠️ rigc's own output is correct — every runtime plays a rotation jiggle — so this is opt-in and the default is *not* silence: on a rig that declares nothing it **SKIPs**, and the SKIP names the constraint and the component anyway, so an author learns without having asked. Fix by driving the constraint in `x`/`y`, or by dropping the declaration if the rig never goes near the editor. Disjoint from `A23_PHYSICS_CONSTRAINT_EFFECTIVE` by construction: A23 refuses an **empty** driven set, which is what comes back from the editor, and this refuses a non-empty one that will not survive going in. **SKIP** also when the rig declares the editor and carries no physics constraint at all |
+| `A42_DRIVEN_CONSTRAINTS_UPDATE_AFTER_THEIR_DRIVER` | both | a slider whose animation keys a property of a constraint **at or before it** in `constraints` (§3.5.2) — a slider's `mix` or `time`, an ik or transform mix, a path `position`, `spacing` or `mix`, any physics value. That array is the update order for every kind, and each constraint reads its own applied pose when its turn comes — `Slider.update` takes `mix` as the alpha it applies with and `time` as the time it applies at, `PhysicsConstraint.update` returns on `mix` 0 before reading the rest — so the key lands after the only read of it and `Posed.resetConstrained` discards it before the next frame: what the driven constraint drives is dead at every position of the driving dial, although its pose still holds the number. The detail names the slider, the driven constraint with its kind, both array indices, the property, the runtime class whose `update` reads it, and the animation the key sits in. Fix by moving the driver earlier, or by keying that property from a slider that already is. **The two indices equal is the same failure**: a slider cannot key its own `mix` or `time`, and one muted at setup that keys its own `mix` up never applies anything at all — `A37` is silent there, because it asks whether *an* animation keys the mix and not which one. **Two shapes it deliberately leaves out**, both measured: a `physics` `reset` key, which fires on a crossed frame time and so never fires from a slider at all, in either order — the reorder would repair nothing; and a physics timeline naming no constraint, which is every physics constraint declaring that property global and IS refused for the ones already run. Disjoint from `A40` by construction: `A40` asks who writes a shared property last and excludes every slider whose `mix` is keyed, this asks whether anything reads what was written. **SKIP** when the skeleton declares no slider, and when no slider's animation keys a constraint property — that SKIP names any `reset` keys it found — a pass means a driver and a driven were compared |
+| `A43_TWO_COLOR_TINT_LOADS_AND_POSES_AS_WRITTEN` | both | a slot's `dark` (§3.3) or an `rgba2` / `rgb2` timeline (§4.4) that the runtime does not hold as the file states it. Three shapes, all of which parse in silence: a `dark` the slot reader **drops** — it takes the field through a truthiness test, so `""` is discarded without a word and the slot renders with one colour; a `dark` that is **not six hex digits** — `Color.setFromString` slices fixed offsets and stores whatever `parseInt` gives back, so `"4020"` loads a channel of `NaN`; and an `rgba2` or `rgb2` timeline on a slot with **no `dark` at all**, where the runtime allocates no dark colour and the first `state.apply` throws in the consumer's process. The keyed half is read by posing: the animation is stepped to each key's own time — at the key **as the runtime stores it**: spine-core keeps key times as 32-bit floats, so a key at `0.2` is posed at `0.20000000298…`, the later of the two, and not one float step before it, where a first key still shows the setup value and a stepped key the one before, and the posed `color` and `darkColor` are compared against the hex the key states, to half a quantisation step (`1/510`). The detail names the slot, the value found and the value required. ⚠️ The required value is parsed **here** and not through `Color.fromString`, because a check that read it out of the parser it is checking would agree with that parser whatever it did. `compile.ts` refuses the third shape outright in a rig rigc builds; this is the same fact held against a skeleton it did not write. An `rgb2` key's light colour is compared over its three channels only: the light alpha is not its to state, and it is left where it was. **SKIP** when no slot declares a `dark` and no animation keys an `rgba2` or `rgb2` — there is then no two-colour tint to read back |
+| `A44_LINKED_MESH_STATES_NO_GEOMETRY_OF_ITS_OWN` | both | a **linked mesh** (§3.4) — `type: "linkedmesh"`, or a `type: "mesh"` carrying `source` — 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 `setSourceMesh` fills the attachment with the source's arrays instead: the file says one mesh and every runtime draws another, in silence. The detail names the attachment by skin, slot and placeholder, every key it states, the `source` and where the parser looks for it — the two defaults spelled out, because an omitted `skin` is the **default** skin rather than the one the link is written in — and the shape the keys describe beside the shape the attachment loaded. ⚠️ **`width`/`height` are not part of this.** `setSourceMesh` overwrites both with the source's, so they are as dead at runtime — but the parser reads them (`:569-570`), the format carries them on a link and rigc emits them, so refusing them would refuse every link rigc writes (§3.4). `compile.ts` refuses the same shape outright in a rig rigc builds (§5.1); this is that fact held against a skeleton it did not write, and `ingest` reports it as `ATTACHMENT_LINK_GEOMETRY` ([INGEST §2.0](INGEST.md)). **SKIP** when no attachment in the skeleton takes its geometry from another — which is almost every skeleton, so a pass here means a link was read |
+| `A45_SEPARABLE_COLOR_TIMELINES_OWN_THEIR_CHANNELS_AND_POSE_AS_WRITTEN` | both | an `rgb` or `alpha` timeline (§4.4) the runtime does not hold as the file states it, in one of two shapes that both parse in silence. **A channel keyed twice**: another colour timeline of the same slot in the same animation poses a channel this one poses — `rgba` beside `alpha` is the shape a converter leaves when it writes a separable `rgb` back as `rgba` next to the `alpha` it kept. Every colour timeline poses its channels at every time, the setup value before its first key included, so the one the file states later overwrites the other everywhere; the detail names both timelines, the channel, and which one survives. **A key not posed as written**: the animation is stepped to each key's own time — at the key **as the runtime stores it**: spine-core keeps key times as 32-bit floats, so a key at `0.2` is posed at `0.20000000298…`, the later of the two, and not one float step before it, where a first key still shows the setup value and a stepped key the one before, and the posed r g b (for `rgb`, against the hex, to half a quantisation step) or alpha (for `alpha`, against `value`, whose absence the parser reads as 0) is compared — a colour that is not six hex digits loads as NaN, and a key whose time another key repeats is read by nothing. ⚠️ An `rgb` alone written as an `rgba` holding the setup alpha is **not** caught and cannot be from the file: it is a correct `rgba`, and the difference shows only under another track that moves the alpha. The loaded timeline class and the channels a separable timeline leaves alone are not measured here, because against the linked parser neither can come out wrong. The channel table is `SLOT_COLOR_CHANNELS` in `src/timelines.ts`, shared with the compiler's refusal and held to the runtime's own property ids. **SKIP** when no animation keys an `rgb` or `alpha` — there is then no separable slot colour to read back |
+| `A46_SEQUENCE_ATTACHMENTS_SHOW_THE_FRAME_THE_FILE_STATES` | both | a **numbered series** (§3.4.3, §4.13) that the runtime does not show as the file states it. Every shape below loads without a word, measured on spine-core 4.3.13. **The block**: a `sequence` with no `count` (`readSequence` reads 0, and the attachment holds no region) or a `setup` at or past `count` (`Sequence.resolveIndex` clamps it to the last frame). **The keys**: a `mode` outside the seven — `hold`, `once`, `loop`, `pingpong`, `onceReverse`, `loopReverse`, `pingpongReverse` — loads as `hold`; an `index` that is fractional (`index << 4` truncates it) or past the end (clamped); an advancing mode at an effective delay of 0 (the parser carries a key's `delay` from the key before; `(time - keyTime) / 0` is Infinity and `Infinity \| 0` is 0, so it never advances); a timeline on an attachment that carries no block (the parser gives every region a one-region series, so every mode shows it). **The pose**: every key is stepped to mid-frame sample times — enough to wrap every mode, and a `hold` key to its own time as the runtime stores it, a 32-bit float — and the region the slot shows is held to the frame the file's own statement gives, the arithmetic of `SequenceTimeline.applyToSlot` and the names of `Sequence.getPath` transcribed rather than read off the loaded timeline, so the check is not the runtime agreeing with itself. Before the first key the frame is `setup`. ⚠️ A sample where the slot shows another attachment is not compared, because the runtime writes nothing there; a timeline with no comparable sample is counted in `stats.sequenceSamplesUnshown`. `compile.ts` refuses every one of these shapes in a spec (§5.1); this is them held against a skeleton it did not write. **SKIP** when no attachment carries a `sequence` block and no animation keys a `sequence` timeline |
+| `A47_IK_CONSTRAINT_NOT_MUTED_THROUGHOUT` | both | an ik constraint resting at `mix` 0 that no animation keys **away from 0** (§4.9, §4.12). `IkConstraint.update` returns on `mix === 0`, so it sits in the update cache and moves nothing. The keys are read the way `A23`/`A36`/`A37` read theirs — every value the loaded timeline poses on its `mix` channel, Bezier samples included — so a timeline keying 0 only is no rescue: [measured] it poses every bone exactly where the same rig with no constraint does. Live is the runtime's `!== 0`, so a negative mix is not refused. `ik constraint "C" has mix 0 at setup and none of the 1 animation keys its mix above 0; update() returns on mix 0, so "upper" never reaches for "goal" — rest it above 0, or key its mix above 0 in an animation, or declare that the consumer drives its mix, in the rig spec as invariants.consumerDrivenMix: [{ "constraint": "C", "type": "ik", "why": … }]`. A constraint the rig spec declares in `invariants.consumerDrivenMix` (§3.7) is not measured, and one the file also switches on is refused: `ik constraint "C" is declared in the rig spec as invariants.consumerDrivenMix, and the file already switches it on — … — so the declaration exempts nothing; drop the entry`. **SKIP** when the skeleton declares no ik constraint, and **SKIP by name** when every ik constraint it declares is declared consumer-driven: `every ik constraint here is declared in the rig spec as invariants.consumerDrivenMix, so its mix is the consumer's to set and nothing in this file shows it moving — "C" (why: …): it rests muted and none of the 1 animation keys its mix above 0`. With a live one beside it the rule measures that one and the stats line names the declared (`ikConsumerDriven`) |
+| `A48_TRANSFORM_CONSTRAINT_NOT_MUTED_THROUGHOUT` | both | a transform constraint none of whose mixes **for a property it drives** is away from 0 at setup or on any value an animation poses (§4.10, §4.12), or one whose `properties` name no `to` at all. A property is applied only when its own mix `!== 0`, and a key that omits a mix reads it as 1, so the six-mix early return of `TransformConstraint.update` would take a key of `mixRotate: 0` alone as a rescue — [measured] that key, and one keying `mixX` 1 on a rotate-only constraint, pose every bone exactly where no constraint does. A negative mix runs, and five transforms in the editor's example exports rest at −1. `transform constraint "C" drives rotate and has mixRotate 0 at setup, and none of the 1 animation keys its mix above 0; a mix is read only for a property the constraint drives, and update() skips each one at 0, so nothing ever moves "follower" — rest mixRotate above 0, or key its mix above 0 in an animation, or declare that the consumer drives its mix, in the rig spec as invariants.consumerDrivenMix: [{ "constraint": "C", "type": "transform", "why": … }]`. A constraint the rig spec declares in `invariants.consumerDrivenMix` (§3.7) is not measured, and one the file also switches on is refused as `A47`'s is; one that drives no property is refused with its own sentence declared or not, since no mix it carries is read by anybody. **SKIP** when the skeleton declares no transform constraint, and **SKIP by name** when every transform constraint it declares is declared consumer-driven: `every transform constraint here is declared in the rig spec as invariants.consumerDrivenMix, so its mix is the consumer's to set and nothing in this file shows it moving — "C" (why: …): it rests muted and none of the 1 animation keys its mix above 0`. With a live one beside it the stats line names the declared (`transformConsumerDriven`) |
 
 `both ◑` marks a mixed assertion: its validity half always runs and its policy
 clauses are gated by profile.
@@ -5772,46 +5444,40 @@ own behaviour is worse: an unknown attachment `type` returns `null` and the
 attachment disappears, and a constraint entry with an unrecognised `type` matches no
 case and vanishes.
 
-A deferral carries its reason, and there is one deferred attachment type left:
-**`point` appears nowhere in the benchmark corpus** (SPEC_COVERAGE parts 3-1 and
-4-2), so it is not on the ladder's critical path. The message says so, because a
-deferral without its reason is a wall rather than a work item. `linkedmesh` stood
-beside it until [#691](https://github.com/firejune/rigc/issues/691) and is now
-emitted — §3.4 has its fields.
+A deferral carries its reason, and there is one deferred attachment type:
+**`point` appears nowhere in the benchmark corpus**, so it is not on the ladder's
+critical path. The message says so, because a
+deferral without its reason is a wall rather than a work item.
 
 ⚠️ **A spelling the format does not have is a different refusal and says so.**
 `sequence` is not an attachment type, and a `"type"` that is `null` is not an absent
 one — telling either author that "rigc does not emit it yet" promises work that will
 never be done, on a map the parser would have dropped in silence. Those rows below
-are `CompileError`s, and they name what the format actually defines
-([#577](https://github.com/firejune/rigc/issues/577)).
+are `CompileError`s, and they name what the format actually defines.
 
 | You wrote | You get |
 | --- | --- |
 | attachment `type` of `point` | `this attachment is a "point" — a position and an angle with no geometry at all — "x", "y", "rotation" and "color" …. rigc does not emit it yet, deliberately: it emits region, mesh, linkedmesh, boundingbox, clipping, path, and a point appears nowhere in the benchmark corpus …` — the message names the **construct**, not just its type string, and part 1-6 is where the sentence comes from |
-| a mesh carrying `source` (`type: "mesh"` **or** `type: "linkedmesh"`) | **not a refusal any more** — both spellings compile to a linked mesh (§3.4, [#691](https://github.com/firejune/rigc/issues/691)). They share one parser branch and `source` is what decides between them (SPEC_COVERAGE part 1-6), so `source` on a mesh is a linked mesh whatever `type` says. It was once refused as *2 keys this compiler does not read: "source", "skin" … fix the spelling or remove it*, whose remedy destroys the construct ([#577](https://github.com/firejune/rigc/issues/577)) |
+| a mesh carrying `source` (`type: "mesh"` **or** `type: "linkedmesh"`) | **not a refusal** — both spellings compile to a linked mesh (§3.4). They share one parser branch and `source` is what decides between them (SPEC_COVERAGE part 1-6), so `source` on a mesh is a linked mesh whatever `type` says |
 | attachment `type` of anything else — `sequence`, a typo | `attachment type "X" is not one of the 7 the Spine 4.3 format defines (region, mesh, linkedmesh, boundingbox, path, point, clipping). … the attachment is dropped from the skeleton without a word` — a **`CompileError`**, not a deferral: rigc is not going to implement a name the format does not have. (`sequence` is a key on a region or a mesh, not a type of its own.) |
-| `"type": null` | `"type" is null, which is not a name. … PRESENT-and-null is not absent: getValue(map, "type", "region") takes the default only when the key is missing, so this map matches no case, readAttachment returns null, and the attachment is dropped from the skeleton without a word. Remove the key, or name a type.` Leaving the key **out** is legal and reads as `region`; writing it as `null` is not the same thing ([#577](https://github.com/firejune/rigc/issues/577)) |
+| `"type": null` | `"type" is null, which is not a name. … PRESENT-and-null is not absent: getValue(map, "type", "region") takes the default only when the key is missing, so this map matches no case, readAttachment returns null, and the attachment is dropped from the skeleton without a word. Remove the key, or name a type.` Leaving the key **out** is legal and reads as `region`; writing it as `null` is not the same thing |
 | constraint `type` of anything else | `constraint type "X" is not one Spine 4.3 knows. The five are: ik, transform, path, physics, slider.` — all five are emitted, so this is a typo, and a typo is what the parser drops in silence |
 | any key neither format has, anywhere in either file | `<object> has a key this compiler does not read: "x" (did you mean "y"?) … Known here: …` (§5.1). Not a deferral either: a key nothing reads is a value you wrote and the emitted skeleton does not contain |
 
 Two more limits that are not errors but will shape what you can attempt:
 
-- **The atlas packer and importer exist and are narrow** (issue #4). `--pack`
+- **The atlas packer and importer exist and are narrow.** `--pack`
   arranges the parts onto shared pages and `--atlas-in` resolves them against a
   pack somebody else made — **§0.1** and **§0.2** state what each does and, more
-  usefully, what neither does: no trimming, no rotation, no scaling, and no
-  `--profile spine-html` over a packed atlas. The default is still **one part per
-  page** with `pma: false` and every region covering its whole page, and nothing
+  usefully, what neither does: no trimming, no rotation, no scaling. The default is
+  **one part per page** with `pma: false` and every region covering its whole page, and nothing
   about a build changes unless one of those flags is given.
 - **`drawOrderFolder`** is walked by the validator (so `A05` checks its curves and
   `diff` counts its keys) and cannot be *written*: there is no motion-spec property
-  for it. Everything a motion spec **can** key is §4.4's track table — which now
+  for it. Everything a motion spec **can** key is §4.4's track table — which
   includes the `path` and `slider` groups (§4.12) — plus the six families that sit
   beside `tracks`: `drawOrder` (§4.7), `events` (§4.8), `ik` (§4.9), `transform`
-  (§4.10), `deform` (§4.11) and `sequence` (§4.13). `sequence` stood beside
-  `drawOrderFolder` in this sentence until
-  [#729](https://github.com/firejune/rigc/issues/729) made it writable.
+  (§4.10), `deform` (§4.11) and `sequence` (§4.13).
 
 ---
 
@@ -5820,12 +5486,10 @@ Two more limits that are not errors but will shape what you can attempt:
 1. `build --profile <the one you meant>` exits 0 and the report has **no FAIL**.
    Saying nothing means `spine`, so "the one you meant" is a decision either way —
    the report's first line names the profile that judged it.
-   📎 The two profiles judge attachment **naming** identically since
-   [#574](https://github.com/firejune/rigc/issues/574): `spine-html` adds the
-   renderer and archetype rules and has no opinion about how an attachment is
+   📎 The two profiles judge attachment **naming** identically: `spine-html` adds
+   the renderer and archetype rules and has no opinion about how an attachment is
    spelled, so a rig whose named skins share a placeholder (§3.4.2) is green
-   under either. Before that it was green under exactly one of them, and which
-   one was not a property of the rig.
+   under either.
 2. Read the `SKIP` lines. Each one is a check that did *not* run — make sure none of
    them is a check you were relying on. The summary's *measured* figure is the
    shortest version of this step: it is how many of the rules actually looked at
@@ -5839,7 +5503,7 @@ Two more limits that are not errors but will shape what you can attempt:
    of how it reads: if `A00` failed, most of the SKIP lines say the round trip
    denied them a result, and the handful of `PASS` rows beside them were measured
    on the raw text alone. Step 1 already sent you back; do not take anything from
-   the rest of that report on the way ([#568](https://github.com/firejune/rigc/issues/568)).
+   the rest of that report on the way.
 3. Read the `PROF` lines. They are where "was this rig held to that rule at all"
    gets answered for everything the profile left out — the renderer policy *and*
    the archetype rules. A green under `spine` has been held to neither; a green
@@ -6028,9 +5692,8 @@ part's own height**, from four independent fits, which is the quantity that had
 agree between them and did.
 
 **A value is easier to get right than a curve.** The three traps above are all
-about measuring a *value*, and both ladder runs so far found that the values came
-out right early: rung 1's key values were exact at every keyframe on the second
-build. What was wrong was the *shape between* them — every accelerating segment
+about measuring a *value*, and on the ladder the values come out right early:
+rung 1's key values were exact at every keyframe on the second build. What was wrong was the *shape between* them — every accelerating segment
 had the decelerating curve and vice versa, from one inverted comparison. Nothing
 in a static reading of the file can find that, because both candidates for the
 shape are legal and the file reads fine either way, and a symmetric pair of easings
@@ -6335,8 +5998,7 @@ your candidate under one of its skins (below), `--all-frames` to list
 every frame instead of the worst by MAE, `--json <out>` for the whole per-frame,
 per-slot report.
 
-🚨 **What `check` certifies is the DEFAULT skin, unless you pass `--skin`**
-(issue #571). With no `--skin` no skin is set at all, which is `spine-core`'s own
+🚨 **What `check` certifies is the DEFAULT skin, unless you pass `--skin`.** With no `--skin` no skin is set at all, which is `spine-core`'s own
 initial state: every slot resolves through `SkeletonData.defaultSkin` alone, and a
 slot whose art lives only in a named skin draws **nothing** — on both sides, since
 the reference frames came out of the same renderer. A multi-skin rig checked that
@@ -6376,7 +6038,7 @@ A skin name the candidate does not declare is refused with the ones it does —
 name.** `A39` and the `DEFORM` block pose each key with the skin that key is keyed
 on — a deform timeline's address is a `skin / slot / attachment` triple — so a
 mesh in a named skin is measured in that skin without anything being passed on the
-command line (§4.11.5, issue #583). The difference is where the name comes from,
+command line (§4.11.5). The difference is where the name comes from,
 not which command cares: `check` compares two picture sets and neither of them
 records a skin unless you say so, while a deform key knows its own.
 
@@ -6387,8 +6049,7 @@ frames, and spineboy's `@30fps` sets do the same. The frame table still says
 `frames 2 on disk, candidate samples 311, 2 compared` — those are the files — and a
 **`sheet` line under it** carries the other 309: your candidate sampled at the set's
 own rate, rendered into the same box the frames above were at the sheet's own scale,
-and compared tile by tile (issue #36 — the gap a rung-2 run had already prototyped a
-comparator for, in its own working directory, because the tool could not see its shot).
+and compared tile by tile.
 
 ⚠️ **Read it as a series, not as one number** — §9.2. And note what it does not
 carry: MAE only. The `Δpx` / `ref Δ` thresholds are calibrated at frame scale and a
@@ -6417,8 +6078,8 @@ your shot's length is not a whole number of coarse intervals, expect **both**
 duration the coarse sidecar understates, and a terminal pose only the finer set shows
 you.
 
-`--fps <n>` exists for frame sets that have no `frames.json` beside them, which are
-sets rendered before the sidecar existed: it gives the rate those frames were
+`--fps <n>` exists for frame sets that have no `frames.json` beside them: it gives
+the rate those frames were
 sampled at, and without it the 12 fps protocol rate is assumed and the report says
 so rather than letting the assumption look like a measurement. Passing `--fps` with
 a value the sidecar contradicts is an error, not an override.
@@ -6435,15 +6096,15 @@ fitting it. Two uses:
   MAE moves by more than a point for a fraction of a pixel, that separation is
   worth more than the absolute number.
 
-There used to be a third — *"you already know your candidate's world coordinates
-match the reference's own, declared in `frames.json`"* — and **`check` now does
-that one for you** (issue #52). Before fitting anything it renders your candidate
+A third use — *"you already know your candidate's world coordinates match the
+reference's own, declared in `frames.json`"* — is one **`check` covers for you.** Before
+fitting anything it renders your candidate
 into the box `frames.json` records and measures where your pixels land. If they
 land on the reference's to within a pixel, that box is yours too, and it is used:
 it is not an *estimate* of where the frames were drawn, it is where they were
 drawn, and the framing line says `frames.json's own box — the candidate measured
 into it`. If they do not, the box is refused and your candidate is framed by its
-own pixels exactly as before — which is the ordinary case, because the reference's
+own pixels — which is the ordinary case, because the reference's
 origin is in a file you are not allowed to open.
 
 That is worth a paragraph rather than a line because of what it costs when it is
@@ -6458,11 +6119,7 @@ author could tell that from a wrong animation without running the pin by hand.
 Pinning to paper over a **real** framing difference — rather than one of the two
 cases above — is the dishonest use: it makes a genuine mismatch between your
 candidate and the reference disappear from the report instead of showing up as
-`content`/`rms`/`union residual`. That used to be easy to do by accident, because
-the old quad-corner framing could be wrong by more than a pixel for reasons that had
-nothing to do with either side's motion — two honest ladder runs measured it costing
-30+ points of MAE with no key changed, which is why framing is now fitted to drawn
-pixels rather than quad corners (issue #34, closed by #39; see §9.2). Pin to a box
+`content`/`rms`/`union residual`. Pin to a box
 you can name a reason for, and read the unpinned framing line first when you are not
 sure whether you have one.
 
@@ -6483,7 +6140,7 @@ Why the split falls there, both halves measured on an 8-shot character (147 fram
   that is not in the frames' coordinates puts the pooled correction over the
   one-pixel threshold and the *whole root* falls back to a fit. Per set, the shots
   that qualify read what pinning by hand reads: `idle` **18.77** where a whole-root
-  run read 41.59, with not one key different (issue #100).
+  run read 41.59, with not one key different.
 - **Fitting per set is worse, so `check` does not.** `fitFraming` registers extent,
   and extent is not alignment (see the ⚠️ in §9.2), so on a shot whose silhouette
   genuinely differs one shot's frames do not constrain the fit enough: `hit` reads
@@ -6491,8 +6148,7 @@ Why the split falls there, both halves measured on an 8-shot character (147 fram
   set reads 101.94 against 42.98. More frames is a better-conditioned fit, so the
   fallback is deliberately the shared one.
 
-`--framing shared` measures **every** set in the shared framing, which is what a
-whole-root run used to do. It answers one question and it is a good one — *does a
+`--framing shared` measures **every** set in the shared framing. It answers one question and it is a good one — *does a
 single box serve every set?* — and it is the wrong number to read as one shot's
 fidelity.
 
@@ -6534,7 +6190,7 @@ and [the ladder's honesty rule](https://github.com/firejune/rigc/blob/main/docs/
 them is a candidate's own reading against rendered frames — the exam question, not the
 answer key — so none of them narrows a reference-side measure, and a guide that censored
 them would be teaching less for no gain in honesty. The criterion is under *The honesty
-rule* in [LADDER.md](https://github.com/firejune/rigc/blob/main/docs/LADDER.md) (issue #158); what it *does* seal is a score written
+rule* in [LADDER.md](https://github.com/firejune/rigc/blob/main/docs/LADDER.md); what it *does* seal is a score written
 over a reference's own count, and no such figure appears here.
 
 🚨 **If you drive the runtime yourself, a bone's local transform lives on
@@ -6547,8 +6203,8 @@ first thing it hits is not a subtlety. **spine-core 4.3 keeps a bone's local
 transform on `bone.pose`, not on the bone**, so `bone.rotation = …` — or `.x`,
 `.y`, `.scaleX` — is neither an error nor a rotation: it adds a property nothing
 reads, and every frame renders as the setup pose. Write `bone.pose.rotation`.
-Rung 8 lost a loop to it at a flat 17.3; driven through `bone.pose`, the same
-poses measured **2.76**.
+Written on the bone, rung 8's poses read a flat 17.3; driven through `bone.pose`,
+the same poses measure **2.76**.
 
 🚨 **That trap has a twin one level up: the *setup* transform lives on
 `bone.data.setupPose`, not on `bone.data`.** `BoneData` extends `PosedData`,
@@ -6561,8 +6217,8 @@ trap, because nothing on the path raises: `undefined` propagates to `NaN`, and
 file, the next build reads those as zero, `validate` is green and `check` runs.
 ⇒ **A `null` in your own placements dump is the signature of having read
 `bone.data` directly** — nothing in this format is ever legitimately null. On
-spineboy it cost the candidate MAE 13.0 → 114.6 with a green gate throughout
-(measured in a spineboy attempt's own loop log, §4.1). Note that the two names are not
+spineboy it costs the candidate MAE 13.0 → 114.6 with a green gate throughout.
+Note that the two names are not
 the same thing: `bone.data.setupPose` is
 the setup transform, while `bone.setupPose()` on a `Bone` is the method that
 resets `bone.pose` back to it.
@@ -6572,9 +6228,7 @@ resets `bone.pose` back to it.
 stores; what gets drawn is that stored quad — `computeWorldVertices` reads
 `getOffsets(pose)`, never the fields — so writing them is, again, neither an
 error nor a move. **Call `attachment.updateSequence()` after every write**, or
-every frame renders the quad it was loaded with. A setup fit on spineboy ran
-4,500 renders and reported the same number for all of them before this surfaced
-(the same loop log, §4.2).
+every frame renders the quad it was loaded with.
 
 ⇒ **An MAE that is identical across every pose, and that does not move for any
 parameter you sweep — a bone's local transform, an attachment's offsets — is one
@@ -6751,8 +6405,7 @@ of them.
 ```
 
 **Read the framing block first.** Everything below it is computed on the grid it
-chose, so an error there arrives disguised as motion — which is exactly what
-happened to two honest ladder runs before this was fixed (issue #34).
+chose, so an error there arrives disguised as motion.
 
 Unless the frames' own box already fits you (above), your candidate is framed **by
 its own drawn pixels**. `check` renders it at the frames' own rate and grid, takes
@@ -6786,9 +6439,8 @@ pass count, then one of
 
 That procedure is blind to the two things it must be blind to. **An invisible
 margin cannot move it**: a region's quad runs past its own artwork wherever the art
-is transparent, and that used to set the scale; now nothing outside the drawing is
-looked at (the selftest proves art padded by 20 px on two sides reports numbers
-identical to the last decimal). **A choice of units cannot move it either**: a rig
+is transparent, and nothing outside the drawing is looked at: art padded by 20 px
+on two sides reports numbers identical to the last decimal. **A choice of units cannot move it either**: a rig
 scaled by 2 % renders to the same pixels and reads the same MAE.
 
 The lines, in order:
@@ -6832,11 +6484,11 @@ a difference that would have been cheaper to leave alone. Measured floor: about
 third of a pixel on the ladder's shots. On most that is invisible; on a small
 high-contrast frame it is worth a point or two of MAE — rung 6 measured five, and
 on the spineboy sets a **constant** one or two pixels was worth 10–30 % of the
-figure (issue #146). This is the floor the frames' own box has no share in, which is
+figure. This is the floor the frames' own box has no share in, which is
 why `check` prefers that box whenever your pixels are measured to land in it;
 `--viewport` is how you stop it in the cases that box does not cover.
 
-⭐ **What a fitted framing now does about it: one final whole-pixel pass.** After
+⭐ **What a fitted framing does about it: one final whole-pixel pass.** After
 the fit settles (or cycles), `check` searches every whole-pixel offset within ±2 px
 for the lowest MAE over the reference's own drawn pixels and moves the box to the
 best one, when that is worth at least 1 % of the figure. So a fitted set's numbers
@@ -6869,10 +6521,7 @@ blunter.
 
 ⚠️ **Half of that denominator is yours, so do not optimise against it.** The union
 is the pixels *either* side drew, and a large, mostly transparent sprite adds many
-cheap pixels to it — so the *mean falls* on a candidate that got worse. That is not
-hypothetical: spineboy-2's muzzle flare walked its own scale to 13x under a fitting
-loop doing exactly this, and cost every set in that run its framing (issue #119).
-So the line under the MAE divides the same difference by the pixels the
+cheap pixels to it — so the *mean falls* on a candidate that got worse. So the line under the MAE divides the same difference by the pixels the
 **reference** drew, a denominator nothing you do can grow. Read the union figure to
 compare two builds of your own rig, where both sides cover about the same ground,
 and the reference-denominator figure when you are deciding whether a change made
@@ -6915,7 +6564,7 @@ appear under the MAE:
   is `|MAE − above| ≤ floor`. So `MAE − above` is what the texture explained on these
   frames and `floor` is the most it could ever explain. **A floor near zero is a proof
   that the texture is not your problem** — which is a finding worth having before a
-  day of key-hunting, and one the old recipe could not give.
+  day of key-hunting.
 
 Measured on rung 3: **6.13 / 6.01** with the candidate's own full-resolution atlas,
 of which **4.45 and 4.10 is texture** — about **70 %** — leaving **1.68 / 1.91** that
@@ -6930,8 +6579,8 @@ pixel* across stopped being visible at half scale, so a substituted run can repo
 frame-change disagreement the graded run does not have. Read it for the floor, never as
 the verdict.
 
-🚨 **Do not run this with `--atlas`, which is what the recipe used to say and which
-substitutes region *geometry* along with the texture.** `--atlas` names **your own**
+🚨 **Do not run this with `--atlas`, which substitutes region *geometry* along with
+the texture.** `--atlas` names **your own**
 atlas for the case where it is not beside your skeleton; point it at a foreign one and
 the skeleton is re-loaded against that atlas. An atlas entry is not only a page and a
 rectangle — it carries **`rotate:`** and the trim offsets that say where the opaque part
@@ -6940,15 +6589,14 @@ your attachments are re-seated and the quads change. Worse, `spine-core` impleme
 region's rotated corner assignment for `rotate: 90` and for nothing else, so a
 270-packed region is sampled from the wrong part of the page outright.
 
-⇒ **The tell was unmistakable and it is the reason this is now a flag of its own: the
-number went the wrong way.** A texture floor can only *explain* error, so a diagnostic
+⇒ **The tell is that the number goes the wrong way.** A texture floor can only *explain* error, so a diagnostic
 that sends the MAE **up** on every set has substituted geometry rather than pixels.
-Rung 7 is that case — its pack is `rotate: 270` — and under `--atlas` it read
-24.93 → 28.84 and 19.17 → 27.75, which had to be recorded as **inconclusive**. Under
+Rung 7 is that case — its pack is `rotate: 270` — and under `--atlas` it reads
+24.93 → 28.84 and 19.17 → 27.75, which cannot be read as a floor at all. Under
 `--texture-from` the same rung measures a floor of **1.7 MAE** on every set, about 2 %
 of each figure: there *is* a floor, it is small, and the rig is the story after all.
 
-⇒ **You no longer have to inspect the atlas for `rotate` or trim before running it.**
+⇒ **You do not have to inspect the atlas for `rotate` or trim before running it.**
 `--texture-from` keeps every world vertex where your own atlas put it and remaps only
 the texture coordinates, through the drawing's own coordinate space, so a rotated or
 trimmed pack lands the same artwork in the same place. If a region of yours is missing
@@ -6987,7 +6635,7 @@ same failure as capturing a guard's expected value from a screen that is already
 broken: the baseline records the defect, and then the *repair* is what looks wrong.
 
 ⚖️ **`frames.json`'s own box, and the `declared` line that says whether you got it.**
-Every set now prints one, taken or refused, with the numbers that decided:
+Every set prints one, taken or refused, with the numbers that decided:
 
 ```
      declared   frames.json's own box: TAKEN, coincident — a fit there asks for 0.08 px, under
@@ -7005,14 +6653,14 @@ correction, which is what a different origin or a different unit looks like, and
 
 ⚠️ **The test is on extent, and extent is not the same claim as coordinates.** A
 candidate authored in the frames' own world units — one whose setup box lands on the
-reference's to the pixel — used to fail it whenever its union content box differed by
-a few per cent at the extremes, because `fitFraming` registers extent and a box 6 %
-narrower reads as 6 % of scale, which is arithmetically what a units error reads as.
-Rung 7 was refused on **all twelve** of its sets that way, and the fitted framing it
-fell back to cost every one of them 0.28–2.01 MAE against the declared box. That cost
-was real and it was **not** a sign the coordinates were wrong.
-
-⇒ **`check` now separates the two by asking whether one similarity can explain the
+reference's to the pixel — fails an extent test whenever its union content box
+differs by a few per cent at the extremes, because `fitFraming` registers extent and a
+box 6 % narrower reads as 6 % of scale, which is arithmetically what a units error
+reads as. On extent alone, rung 7 is refused on **all twelve** of its sets, and the
+fitted framing it falls back to costs every one of them 0.28–2.01 MAE against the
+declared box — a real cost, and **not** a sign the coordinates are wrong.
+
+⇒ **`check` separates the two by asking whether one similarity can explain the
 disagreement at all.** A difference of units or of origin *is* a similarity, so the fit
 absorbs it exactly and leaves a residual near zero — a rig at 2 % different units leaves
 0.27 px rms. A silhouette differing at the extremes is not a similarity, so the residual
@@ -7055,8 +6703,7 @@ frame and wrong only in the relation between two:
   structure as matching. The column says `the reference moves here and yours holds
   still`.
 
-Both of those were found by that run writing its own render-diff by hand. Read this
-line whenever the MAE is flat and something still looks wrong: a flat MAE says the
+Read this line whenever the MAE is flat and something still looks wrong: a flat MAE says the
 framing and the art agree, and it says nothing at all about whether your shot holds
 and blinks where the reference does.
 
@@ -7075,8 +6722,7 @@ shifts under three world units and comes back, so the two coarse samples land on
 same pose either side of it. So §10.3's *key both ends of the hold* has to be applied
 **at each committed rate separately**, and equal values are not enough — the two
 samples have to be **keys**, or a planner reduces through one of them and an
-interpolant inside its own tolerance is not equality. That cost two builds on that
-run, the second of them for exactly that reason. ⇒ Measure the frames' own
+interpolant inside its own tolerance is not equality. ⇒ Measure the frames' own
 frame-to-frame change **once per committed rate**, and where a rate holds, pin both
 ends as keys whenever a finer rate moves between them.
 
@@ -7120,9 +6766,9 @@ There are two matchers and the `how` column says which one answered:
   much wider than its box, and may not contain another of your parts' ink. The last
   is the one a dominant part slips through otherwise — rung 2's course is 81 % of a
   blob that also holds the water, the panel and both rings, so the blob is only
-  1.24x its ink and no wider than its box, and the reported *"course drift 11.2 px"*
-  was the distance to a five-part centroid (issue #37). It now falls to the matcher
-  below and reads 0.0 px.
+  1.24x its ink and no wider than its box; on size and width alone, *"course drift
+  11.2 px"* would be the distance to a five-part centroid. The third condition sends
+  it to the matcher below, which reads 0.0 px.
 - `tmpl 0.62` — the reference merged your slot into a neighbour (they touch, or one
   is drawn over the other), so the fallback rendered **your slot on its own** and
   correlated it against the reference around where you drew it. The number is the
@@ -7133,9 +6779,9 @@ There are two matchers and the `how` column says which one answered:
   template pixel you draw something over cannot match the reference wherever the
   slot really is, so it adds the same residual at every offset — and, because
   sliding the template moves those samples onto other pixels, their gradient
-  decides the winner wherever the visible basin is shallow. That is not a
-  hypothetical: it is what made four of the seven examples in this repository
-  report 0.8–2.2 px against frames rendered from themselves (issue #698).
+  decides the winner wherever the visible basin is shallow. Correlated with those
+  pixels, four of the seven examples in this repository report 0.8–2.2 px against
+  frames rendered from themselves.
 
 ⚠️ **Both matchers are capped, and a blank is a real answer.** A part can be
 displaced by about its own size and still be that part in the picture; past that,
@@ -7208,24 +6854,17 @@ never against a number from a page about another rig.** A component match prints
 the other sentence — two centroids have no such bound, only the search radius.
 
 🚨 **The clamp bounds the figure only while the whole-pixel winner is the
-identity, and for a while nothing checked that second half.** Issue #698: four of
-the seven examples in this repository read **0.81, 1.11, 2.13 and 2.21 px** against
-frames rendered from themselves, because the template carried the pixels the
-candidate draws *over itself*. Those match nothing wherever the slot really is, so
-they add a residual at every offset — and sliding the template moves them onto
-other pixels, so their gradient walks the winner off the origin wherever the
-visible basin is shallow. The exhaustive whole-pixel field for `flex`'s backdrop
-had its minimum at `(2, 0)` scoring 7.75 against the identity offset's 8.76.
-Correlating only what shows put all seven back on `(0, 0)`, and `C25`–`C30` of
-the repository's own selftest gate that over every example it ships — so the next
-one is gated by arriving.
-
-🔸 The same page said `3.7 px` before issue #678, for an unrelated reason worth
-keeping: the coarse sweep started at `−radius` and stepped by its stride, so the
-identity offset was on the lattice only when the stride divided the radius, and
-the `±1` refinement around a winner two pixels out could not reach back to it.
-
-**A second example, and the one the repair was measured on.** `gallery/flex` draws
+identity.** That is why the template carries only what shows: with the pixels the
+candidate draws *over itself* in it, four of the seven examples in this repository
+read **0.81, 1.11, 2.13 and 2.21 px** against frames rendered from themselves.
+Those pixels match nothing wherever the slot really is, so they add a residual at
+every offset — and sliding the template moves them onto other pixels, so their
+gradient walks the winner off the origin wherever the visible basin is shallow. The
+exhaustive whole-pixel field for `flex`'s backdrop then has its minimum at `(2, 0)`
+scoring 7.75 against the identity offset's 8.76. Correlating only what shows puts
+all seven on `(0, 0)`.
+
+**A second example, and the one that paragraph was measured on.** `gallery/flex` draws
 a banner and a leaf over a full-stage backdrop, so almost every slot of it reaches
 the template matcher:
 
@@ -7245,8 +6884,6 @@ bun cli.ts check  --candidate <build> --frames <frames>
      per-frame all 29 adjacent pair(s) change by as much as the reference's own frames do
 ```
 
-That figure was **2.21 px** on the same command before #698, on the same slot.
-
 ⭐ **And the same frames plus two deliberately wrong builds are what say which column
 answers which question.** Each differs from the build above in exactly one way —
 every easing reversed `(x1,y1,x2,y2) → (1−x2,1−y2,1−x1,1−y1)`, and the ball's bottom
@@ -7349,9 +6986,9 @@ about your bone tree rather than about a hole in your figure.
 - **A difference smaller than the render scale.** At rung 3's 0.117 px per unit, a
   key 4 units out moves nothing. Author to the frames' precision and record that
   the rest was not checkable.
-- **Whether a mesh is deformed or merely posed.** Since #27 the rasteriser draws
+- **Whether a mesh is deformed or merely posed.** The rasteriser draws
   meshes — weighted, deformed, both — so a rung with meshes is measurable. What it
-  still cannot tell you is *how* a silhouette got its shape: a hull moved by a
+  cannot tell you is *how* a silhouette got its shape: a hull moved by a
   bone chain and the same hull moved by deform keys render to the same pixels, and
   the frames cannot separate them. Choose on what the rig has to do next, not on
   what the frames appear to say. ⚠️ **But `bench` does see it.** Take a disc that
@@ -7385,9 +7022,9 @@ about your bone tree rather than about a hole in your figure.
   was, and the interesting ones are interesting because it left the interval. Rung
   4's ball makes contact entirely inside one twelfth of a second: the sheet puts it
   **40 px below both 12 fps frames that bracket it**, while its x sits within their
-  own range. A search whose reach was scaled from those two frames' own step
-  therefore looked ±9 px for something 40 px away and reported the interpolation
-  back, twice, before the tile was read rather than inferred.
+  own range. A search whose reach is scaled from those two frames' own step
+  therefore looks ±9 px for something 40 px away and reports the interpolation
+  back: read the tile rather than inferring it.
 
 ---
 
@@ -7409,18 +7046,10 @@ frames. Every line is marked with where it comes from:
 - 📗 **stated** — quoted or paraphrased from the page linked in the line.
 - 🧩 **inferred** — this guide's reading of those pages. Spine does not say it.
 - 🔬 **observed** — read off the editor's own export of a rigc build, not from a
-  page. Two round trips stand behind these: [issue
-  #285](https://github.com/firejune/rigc/issues/285) (Spine 4.3.23) and the
-  eight-rig trip of 2026-09-16 (Spine **4.3.26**), whose findings are collected in
-  §10.6. ⚠️ This legend said *"used only where rigc now emits the same thing"*,
-  which was true while every observation had already been adopted; §10.6 then
-  carried one that had **not** been — the path `lengths` disagreement — so an
-  observation is now marked by where it was read, and each says for itself
-  whether rigc agrees with it. ⭐ That outstanding one has since been adopted
-  ([#560](https://github.com/firejune/rigc/issues/560)) and the legend is kept in
-  this shape anyway: the reason to mark an observation by its source rather than
-  by whether rigc follows it is that the second fact goes stale and the first
-  does not.
+  page. Two round trips stand behind these: one through Spine 4.3.23 and an
+  eight-rig trip through Spine **4.3.26**, whose findings are collected in §10.6.
+  An observation is marked by where it was read, and each says for itself whether
+  rigc agrees with it.
 
 ### 10.1 Structure
 
@@ -7461,11 +7090,11 @@ a rig whose names miss reads near zero on all of them however well it is built.
 carry each part's own name straight through — PNG basename → slot → attachment, and
 the bone that moves it — instead of inventing a scheme of your own.
 
-**Both directions are measured.** The one run whose art shipped a separate PNG per
-body part, each named for the part, applied this deliberately and posted `names`
-measures **an order of magnitude** above anything on the ladder before it — without
-either side seeing the other. Every honest run before it read near zero on the same
-measures. It is the largest single thing any run has got out of a convention.
+**Both directions are measured.** On the ladder, a run whose art ships a separate
+PNG per body part, each named for the part, and that carries those names through,
+posts `names` measures **an order of magnitude** above runs that invent their own —
+without either side seeing the other. It is the largest single thing a convention
+has bought on the ladder.
 
 ⚠️ **And the other half, which matters just as much: when the art is *not* named
 after the parts, no naming strategy beats any other and the measure is noise.** On a
@@ -7486,16 +7115,13 @@ two animations' 16 and 2 bone-timeline keys all came back sorted, while the 30
 `bones`, 24 `slots` and 3 `constraints` — arrays — came back in the build's own
 order, element for element, and each slider kept its place among them.
 
-🚨 **Not every array: `skins` it re-sorts.** That sentence read *"leaves every
-ARRAY alone"* for two releases, on those three arrays and nothing else, and
-`skins` is the one it was wrong about — see the paragraph at the end of this
+🚨 **Not every array: `skins` it re-sorts** — see the paragraph at the end of this
 section.
 
 ⚠️ **The order it sorts them into is natural and case-insensitive, not
-codepoint.** This paragraph said codepoint until
-[#539](https://github.com/firejune/rigc/issues/539) measured it: `Turn, sweep,
-wave` came back `sweep, Turn, wave` and `turn10, turn2, zoom` came back
-`turn2, turn10, zoom`. The corpus says the same thing and always did — of its 105
+codepoint.** `Turn, sweep, wave` came back `sweep, Turn, wave` and
+`turn10, turn2, zoom` came back `turn2, turn10, zoom`. The corpus says the same
+thing — of its 105
 name-keyed collections, 102 are consistent with a codepoint sort and **3 are
 not**: `spineboy-pro.json` keys `portal-flare9` *before* `portal-flare10`, which
 no codepoint sort produces. Every natural comparator reproduces all 105. (The
@@ -7506,54 +7132,34 @@ one key, deform blocks counted at each of their three levels;
 ⇒ in rigc: `animations` is emitted sorted (R10), because it is the one
 object measured here whose ORDER is also an index space — every reference into
 the re-sorted *other* objects is by name on both sides, so nothing moves when
-they are re-keyed. ⚠️ Since [#716](https://github.com/firejune/rigc/issues/716)
-a skin's `attachments` slot keys are emitted sorted too, for the **text** and
-for no reference: a rebuild of an editor export is the export only if it is the
-same text (§10.6b), and 11 of the twelve under `examples/` keyed a skin in draw
-order where the export sorts it. Nothing is refused on that map — a pair the
+they are re-keyed. ⚠️ A skin's `attachments` slot keys are emitted sorted too,
+for the **text** and for no reference: a rebuild of an editor export is the export
+only if it is the same text (§10.6b). Nothing is refused on that map — a pair the
 comparator leaves open, or a slot name with a `/` in it, keeps the whole map in
-rigc's order instead. rigc emits **that comparator's own order**, which
-[#728](https://github.com/firejune/rigc/issues/728) then measured in full off five
-stored round trips (R10) rather than quantifying over a family. Sorting the
-105 collections that way reproduces **105 of 105**, the three codepoint cannot
-included, and refuses none of them; the codepoint rule that stood until
-[#543](https://github.com/firejune/rigc/issues/543) reproduced 102 and refused
-those same 3.
-
-✅ **`events` is re-keyed too, and the references into it survive it.** The same
-session measured it: `zebra, mike, alpha` came back `alpha, mike, zebra`, and the
-firings still resolved **by name** — `0.3 -> mike`, `0.6 -> alpha`, payloads
-intact (#539). So the editor treats `events` and `animations` differently, and
+rigc's order instead. rigc emits **that comparator's own order**, measured in full
+off five stored round trips (R10). Sorting the 105 collections that way reproduces
+**105 of 105**, the three codepoint cannot included, and refuses none of them.
+
+✅ **`events` is re-keyed too, and the references into it survive it.** Measured:
+`zebra, mike, alpha` came back `alpha, mike, zebra`, and the firings still resolved
+**by name** — `0.3 -> mike`, `0.6 -> alpha`, payloads intact. So the editor treats `events` and `animations` differently, and
 rigc emits events in the order you declare them.
 
-🚨 **`skins` is re-sorted, with `default` pinned first — measured, and it is the
-first array measured to move.** A four-skin rig built `default, zulu, mike, alpha`
-exported `default, alpha, mike, zulu`
-([#541](https://github.com/firejune/rigc/issues/541)), and the deform timelines
+🚨 **`skins` is re-sorted, with `default` pinned first — measured.** A four-skin rig
+built `default, zulu, mike, alpha` exported `default, alpha, mike, zulu`, and the
+deform timelines
 came back keyed `mike, zulu` rather than `zulu, mike` with it. Note `alpha` sorts
 before `default` under every candidate comparator and still came back second: the
 default skin is **pinned**, not sorted. It matters for the same reason `animations`
 does — `skins` carries ordinals in the binary half, `skins[readInt()]` for an
-attachment timeline and `skins[skinIndex]` for a linked mesh — so this is the
-`animations` defect (#535) in the collection nobody had checked. ⇒ in rigc: R11.
-
-✅ **Which comparator it is was the open half of that, and #728 closed it.**
-`alpha, mike, zulu` is the order codepoint, case-folding and natural order all
-produce, so #541's rig refuted nothing and rigc refused any skin-name pair the
-candidates could disagree about. Two of the five round trips carried one name list
-as **both** collections and both came back in one order, so `skins` and
-`animations` share one comparator — measured, not inferred — and the wider skin
-refusal is gone (R11).
-
-✅ **The two readings this replaces.** A pull request once called `skins` *measured
-preserved*, on the strength of a one-skin rig where a one-element array comes back
-in order whatever the editor does to it;
-[#544](https://github.com/firejune/rigc/issues/544) corrected that to *unmeasured*,
-and added that it could not be measured because the editor refused a four-skin rig
-on import without printing a word. Both readings were the same generalisation — *an
-editor does not move arrays* — off the three arrays that were measured, and the
-"without a word" was rigc's own harness discarding the editor's stderr, which had
-named the cause all along (§3.4.2).
+attachment timeline and `skins[skinIndex]` for a linked mesh — so it carries the
+same hazard as `animations`. ⇒ in rigc: R11.
+
+✅ **Which comparator it is, is measured too.** `alpha, mike, zulu` is the order
+codepoint, case-folding and natural order all produce, so that rig alone decides
+nothing between them. Two of the five round trips carried one name list as
+**both** collections and both came back in one order, so `skins` and `animations`
+share one comparator — measured, not inferred (R11).
 
 ### 10.2 Draw order
 
@@ -7894,15 +7500,15 @@ and a character's body bone almost never has them there, which is the very shape
 paragraph above was written from. Turn the parent by δ and a child *at the origin*
 back by δ and the child is where it was; a child sitting 10 units off swings through
 an arc of that radius first, and the counter-turn only spins it on the spot. The fold
-moves art, so it **changes the picture**. Measured on the second spineboy run, whose
-`hip` carries no attachment and has three children 9–13 units off it: the fold cost
-**3 MAE on every `idle` frame** — mean 23.0 with it against 19.9 without, same search
-— and it was removed. ⇒ Read the children's offsets before you fold. At the origin,
+moves art, so it **changes the picture**. Measured on a spineboy run whose `hip`
+carries no attachment and has three children 9–13 units off it: the fold costs
+**3 MAE on every `idle` frame** — mean 23.0 with it against 19.9 without, same
+search. ⇒ Read the children's offsets before you fold. At the origin,
 fold: it is exact and it is cheap. Off the origin the degeneracy is still there but
 it is **soft**, not exact, and a soft degeneracy is *regularised, not folded* — leave
 the values alone and add a penalty on the gauge direction to the objective instead.
-That run used **2e-5 per squared degree** of hip rotation: invisible at animator-sized
-angles, and still decisive against the +181° against −184° above.
+**2e-5 per squared degree** of hip rotation is enough there: invisible at
+animator-sized angles, and still decisive against the +181° against −184° above.
 
 ### 10.4 Curves
 
@@ -7943,16 +7549,15 @@ by fitting each span's **own** handles, and then writes the nearest entry of a n
 table, has bought a key count at one tolerance and shipped it at another. Nothing in
 the loop can see that: the timeline count, the key count, the curve kinds and the
 duration are all unmoved, so `diff` does not shift and the gate stays green, while
-the rendered result changes by a multiple. Rung 8's first version did exactly this
-and went from **1.07 to 4.65 MAE** — four times its own fit's floor. ⇒ Two passes.
+the rendered result changes by a multiple. Measured on rung 8, that goes from
+**1.07 to 4.65 MAE** — four times the fit's own floor. ⇒ Two passes.
 Pass A fits freely and exists only to *discover* which shapes the shot uses; those
 are clustered into the table; pass B re-plans **every** timeline under the table it
 will actually write. Never fit free handles and substitute the nearest named shape
 after the fact. (The table's size then trades against the key count at a fixed
 tolerance — that shot ran 4 easings/368 keys, 8/314, 12/300, 16/284 — because a
-richer table holds more spans.) This is rung 6's clamp defect in another suit:
-**a constraint that is not enforced where the value is written is not a
-constraint.**
+richer table holds more spans.) **A constraint that is not enforced where the
+value is written is not a constraint.**
 
 🧩 **⇒ A span with no interior sample takes the automatic handles, not linear.** Two
 keys on adjacent samples leave pass B nothing to fit — the samples cannot constrain
@@ -7960,9 +7565,9 @@ that span's shape at all — and a planner with nothing to fit leaves `ease` off
 is linear (§4.5): the one shape this section says to argue for rather than default to.
 "No information" is not an argument for constant speed. Take instead the tangents the
 keys either side imply — the editor's own **automatic handles**, quoted above — and
-snap *those* to the nearest table entry, exactly as you would a fitted span. Rung 8's
-second version did this for its adjacent pairs and the samples barely moved (**17.34 →
-17.26 MAE**) while `curve_kinds` changed wholesale: nil in the frames, large in the
+snap *those* to the nearest table entry, exactly as you would a fitted span. Done for
+rung 8's adjacent pairs, the samples barely move (**17.34 → 17.26 MAE**) while
+`curve_kinds` changes wholesale: nil in the frames, large in the
 structure, which is the signature of a convention rather than a fidelity fix — and
 this section's whole subject.
 
@@ -7984,7 +7589,7 @@ of key does not have a transition, such as slot attachment or event keys"* —
 every key that carried a curve into a segment whose next key holds the same value on
 every channel comes back as `"curve": "stepped"` — 14 keys on the gallery's `nod`
 alone, with every rendered frame byte-identical, because a curve over a flat segment
-draws nothing. rigc emits the same for a **named** easing (§4.5, issue #369), so
+draws nothing. rigc emits the same for a **named** easing (§4.5), so
 `diff`'s `animations.curve_kinds` reads 1.000 between a build and its own export
 rather than charging the hold rewrites against the timing. A raw `curve` stays as
 written: it is the file's own numbers, and the reference corpus has the editor itself
@@ -8012,8 +7617,8 @@ without the box and rebuilds the hull on its own.
 the command line the ⇒ above is the exception rather than the case.** The
 sentence is still true of an export made without the box; what is measured is
 that `-e json` with no export-settings file does not make one. Every field on the
-nonessential list came back present, unchanged and not zero on round trip 6
-(2026-09-16, Spine 4.3.26): the header's `fps` (24 on `fields`, the one rig that
+nonessential list came back present, unchanged and not zero on the eight-rig
+round trip (Spine 4.3.26): the header's `fps` (24 on `fields`, the one rig that
 declares it) and `images`; a mesh's `width`/`height` (64/48) and `edges`
 (16 entries, identical); the editor colours of a **bounding box** (`3cff6bff`), a
 **clipping** polygon (`ff3c6bff`) and a **path** (`ff6b3cff`); and a bone's
@@ -8032,10 +7637,10 @@ binary export is performed using default settings"* —
 those defaults**, so the answer above is measured here and documented nowhere.
 ⇒ In practice: do not plan around fields being dropped. An export you did not
 personally make without the box is an export that has them, and the round trip is
-therefore **richer** than the build rather than poorer — which is why #368's
-hull-and-edges degradation does not return on a second trip (no import warning in
-any of the eight `roundtrip.log`s, and a five-vertex mesh's `hull: 4` came back
-`4` rather than recomputed to `5`). A nonessential-**off** trip would need an
+therefore **richer** than the build rather than poorer — which is why a second
+trip does not degrade a mesh's hull and edges: no import warning on any of the
+eight rigs, and a five-vertex mesh's `hull: 4` came back `4` rather than
+recomputed to `5`. A nonessential-**off** trip would need an
 export-settings JSON, and ❓ the key name inside that file is not documented
 either.
 
@@ -8045,18 +7650,15 @@ omit them in raw JSON and every UV collapses, in silence. Name an `image`.
 
 ✅ **You need not imitate the exporter's omissions — the emitter does it for you.**
 Spine's exporter drops fields equal to their default, which is why the format page is
-a long list of *"assume 0 if omitted"*, and since
-[#716](https://github.com/firejune/rigc/issues/716) rigc's emitter drops the same
-ones (R1, §2; the table is §10.6c). So an author may still state a default — `x: 0`
+a long list of *"assume 0 if omitted"*, and rigc's emitter drops the same ones
+(R1, §2; the table is §10.6c). So an author may still state a default — `x: 0`
 in a rig spec is legitimate and stays in the spec — and the file leaves it out.
-⚠️ This paragraph said *"do not imitate the exporter's omissions … rigc deliberately
-does the opposite"* until then. The advice was re-derived rather than kept: **the
-round trip is the reason.** A rebuild of an editor export that writes back every
-default the export left out is a different file from the export in 2,338 places over
-the twelve under `examples/`, and one that leaves them out is the export's own text
-apart from the header's `hash` and `spine` (`IG83`, and [INGEST §2.3](INGEST.md)).
+**The round trip is the reason.** A rebuild of an editor export that writes back
+every default the export left out is a different file from the export in 2,338
+places over the twelve under `examples/`, and one that leaves them out is the
+export's own text apart from the header's `hash` and `spine` ([INGEST §2.3](INGEST.md)).
 The habit worth carrying over is still not *omit defaults* — it is *declare only what
-the shot needs*; what changed is that stating a default costs nothing in the file.
+the shot needs*; stating a default costs nothing in the file.
 
 ### 10.6 What a round trip gives back
 
@@ -8066,8 +7668,8 @@ is a construct that might vanish there, and an agent cannot see that it did.
 
 🔬 The source is one run: eight discriminator rigs, each built to isolate a group
 of fields, compiled by rigc **0.21.0** (emitting 4.3.13), imported into a licensed
-Spine **4.3.26** through the documented CLI and exported back on 2026-09-16, with
-the predictions written down before anything was opened. **Seven of the eight came
+Spine **4.3.26** through the documented CLI and exported back, with the
+predictions written down before anything was opened. **Seven of the eight came
 back differing from their build in three header fields and nothing else** —
 `hash` and `audio`, which the editor adds, and `spine`, which it stamps with its
 own version. The eighth is the path rig, and it is the last bullet here.
@@ -8078,8 +7680,8 @@ comes back `48.0`) and **omitted defaults** — the export drops any field equal
 its parser default, so the header loses `x: 0` and `y: 0`, a bone loses `x: 0`, and
 a key at t=0 loses its `"time": 0`. Every name-keyed object is also re-sorted, per
 §10.1. None of those is a loss of information, and each is worth knowing before
-you read a `diff`. 🔁 Since [#716](https://github.com/firejune/rigc/issues/716) the
-bone's `x: 0` and the key's `"time": 0` are left out by rigc as well (§10.6c); the
+you read a `diff`. 🔁 rigc leaves out the bone's `x: 0` and the key's `"time": 0`
+as well (§10.6c); the
 header's origin is not, because the 4.3 JSON reader has no default for it
 (`skeletonData.x = skeletonMap.x`, `SkeletonJson.js:70`), so an absent origin loads
 as `undefined` where a written one loads as `0` — writing it is exact for both
@@ -8116,11 +7718,9 @@ evidence that the format will carry what you write.
 - 🔬 **A path attachment's `closed: true` and `constantSpeed: false` survive**, and
   so do its `position`, `spacing` and three-channel `mix` timelines — all three
   channels of every `mix` key, and all twelve curve numbers on each key that
-  carries a curve. ⚠️ Its `lengths` did **not**, which is the last bullet — and
-  since [#560](https://github.com/firejune/rigc/issues/560) they do on that rig,
-  because rigc emits the computation the editor runs rather than one near it.
-  What they are computed ON is a second question, which the round trip could not
-  ask and #804 did: see the end of this section.
+  carries a curve. ⚠️ Its `lengths` came back recomputed — the paragraph after
+  this list says how, and rigc emits that same computation. What they are
+  computed ON is a second question: see the end of this section.
 - 🔬 **`physics.mix` and `physics.reset` timelines survive**, the `reset` key
   included — a key that carries a time and no value at all — and so does the
   physics constraint's setup `mix`.
@@ -8132,8 +7732,7 @@ evidence that the format will carry what you write.
   five-vertex mesh declaring `hull: 4` came back `4`, with its `edges`, `color`,
   `uvs` and `triangles` unchanged. Beside it, on the same rig: the header's
   `referenceScale`, a region's `rotation` / `scaleX` / `scaleY` / `color`, and an
-  attachment whose `path` differs from its placeholder (the mechanism of
-  [#552](https://github.com/firejune/rigc/issues/552)) all survive. A `--pack`
+  attachment whose `path` differs from its placeholder all survive. A `--pack`
   build round-trips too.
 
 🚨 **The one thing that did not come back is a path attachment's `lengths`, and it
@@ -8150,21 +7749,18 @@ under 4.3.26 (`[152.7006, 305.4012, 458.1019, 610.8025]`) and on an open one und
 ⚠️ **That last reading settles the model and cannot settle the spelling.** A
 4-sample chord sum agrees with the runtime's forward difference to about **nine
 significant digits** — *below* what float32 can hold, which is why both spellings
-reproduce both exports exactly, and since issue #716 below what rigc's own file
-holds too, because rigc now writes each number as its float32. Under the six fixed
-decimals it wrote until then the file could tell them apart: on both rigs above
-they rounded apart on the **last** curve, where the running total has accumulated
-most — `610.802519` against `610.802520`, `1127.735817` against `1127.735818`. So
-the editor is the evidence for *what* is computed, and only `PathConstraint`
-itself is evidence for *how* — `PS67`/`PS68` compare the transcription with it at
-double precision.
-
-⭐ **rigc emits the forward difference itself** since
-[#560](https://github.com/firejune/rigc/issues/560) — `pathCurveLengths` in
+reproduce both exports exactly, and below what rigc's own file holds too, because
+rigc writes each number as its float32. At six fixed decimals the two would round
+apart on the **last** curve of both rigs above, where the running total has
+accumulated most — `610.802519` against `610.802520`, `1127.735817` against
+`1127.735818`. So the editor is the evidence for *what* is computed, and only
+`PathConstraint` itself is evidence for *how*.
+
+⭐ **rigc emits the forward difference itself** — `pathCurveLengths` in
 [`src/compile.ts`](../src/compile.ts) is those runtime lines transcribed, down to
 `Math.sqrt(dx * dx + dy * dy)` rather than `Math.hypot` and `0.16666667` rather
 than `1 / 6`, both of which change the emitted file. All seven entries of the two
-exports above now come back at the precision the editor prints them, so a path rig
+exports above come back at the precision the editor prints them, so a path rig
 built here and one authored in the editor parameterise identically. ⚠️ The
 consequence for you is a vocabulary one: `lengths` is **not** an arc length. It
 sits about 0.5 % below the arc by construction, so a physical quantity — how far a
@@ -8175,31 +7771,26 @@ out of the artifact.
 wrap-around curve even on an open path** — that open path's fourth entry,
 `2136.228`, is the closed-chain cumulative. The parser allocates `vertexCount / 3`
 and copies whatever is there, and `PathConstraint` reads at most
-`lengths[curveCount]`, so the trailing entry is never read — and since
-[#804](https://github.com/firejune/rigc/issues/804) rigc writes it too, measured
-over the closed chain, so the `gallery/ride` build ends on the same `2136.228`.
-
-🚨 **"Every digit the editor printed" was true of two rigs and false in
-production** ([#804](https://github.com/firejune/rigc/issues/804)). Both rigs above
-are unweighted, unscaled and unconstrained, and the computation is only half of
-the number — the other half is the geometry it is fed, and there the editor and
-rigc differed twice:
-
-- **Scale.** rigc blended weighted vertices through setup matrices that ignored
-  bone scale, shear and `inherit`: a 50/50-weighted probe path over a bone at
-  scale 2 measured 0.752× the runtime's own `curves`. The matrices are the
-  runtime's now, and an omitted `lengths` measures within 1e-4 of `curves`
-  (`PS186`).
+`lengths[curveCount]`, so the trailing entry is never read — and rigc writes it
+too, measured over the closed chain, so the `gallery/ride` build ends on the same `2136.228`.
+
+🚨 **The computation is only half of the number — the other half is the geometry
+it is fed.** Both rigs above are unweighted, unscaled and unconstrained; on a path
+that is not, two things decide what an omitted `lengths` measures:
+
+- **Scale.** rigc blends weighted vertices through the runtime's own setup
+  matrices — bone scale, shear and `inherit` included — so an omitted `lengths`
+  measures within 1e-4 of the runtime's own `curves`.
 - **Constraints.** The editor measures the pose the first update hands the path
   constraint, with every constraint ordered before it applied; a transform
   constraint on the path's slot bone ordered after it moves nothing. rigc does
   not pose, so it cannot reproduce that — an omitted `lengths` is the
-  **unconstrained** setup figure (`PS190`), and on a path a constraint moves at
+  **unconstrained** setup figure, and on a path a constraint moves at
   rest that is not the editor's number.
 
 ⇒ **A stated `lengths` is carried as stated**, and `ingest` writes the source's
 array into the spec, so a rebuilt export is its export on this field. What rigc
-still measures is an array you left out of a spec you wrote.
+measures is an array you left out of a spec you wrote.
 
 ⇒ **What this means for you.** `lengths` is the one number in a path rig you
 cannot check by looking: `diff` does not compare it, and `A33` asks only that it
@@ -8209,29 +7800,25 @@ path constraint, against **0.0000** on the other seven. If you are comparing a
 path rig against an editor reference and everything structural agrees while the
 picture does not, this is the first place to look.
 
-⚠️ **What decides whether it moves a pixel is the POSITION mode**, and an earlier
-reading of this paragraph put it on `spacingMode: proportional`, which is the one
-mode it cannot be: proportional spacing scales *with* the total, and that is
+⚠️ **What decides whether it moves a pixel is the POSITION mode**, not
+`spacingMode: proportional`, which is the one mode it cannot be: proportional spacing scales *with* the total, and that is
 exactly what cancels. The rig that drifted is `positionMode: fixed`, where an
 absolute `position` is compared against a total that moved. Under
 `positionMode: percent` the position scales with the total too, so a uniform
-change cancels out of both — measured across #560, `gallery/ride` is
-percent/percent and every one of its 74 rendered frames came back **byte
-identical** on an emitted array all three of whose numbers moved. ⇒ Read a
+change cancels out of both — measured: `gallery/ride` is percent/percent, and
+every one of its 74 rendered frames comes back **byte identical** across an
+emitted array all three of whose numbers change. ⇒ Read a
 `lengths` disagreement as *certainly wrong data, and visible only under
 `positionMode: fixed`*.
 
 ### 10.6b The order it writes keys in
 
 🔬 **The editor writes every object's keys in one fixed order per kind of
-object**, and since [#716](https://github.com/firejune/rigc/issues/716) rigc
-writes the same. Read off the twelve exports under `examples/`: for each kind,
+object**, and rigc writes the same. Read off the twelve exports under `examples/`: for each kind,
 every object's key sequence is a subsequence of one order, no two exports
 contradict each other on any kind, and the table below is that order. It lives
 in one place, [`src/keyorder.ts`](../src/keyorder.ts)'s `EDITOR_KEY_ORDER`, and
-the compiler applies it once to the finished skeleton — `CUR83` holds this table
-to that one, and `IG77` holds that one to the exports on every run with a
-corpus.
+the compiler applies it once to the finished skeleton.
 
 | Kind | Keys, in the order the editor writes them |
 | --- | --- |
@@ -8274,8 +7861,8 @@ says which.**
 - **A pair no export carries together has no measured order**, and the row
   places it the way rigc already emitted it — a transform constraint's
   `rotation` before `x`, an ik key's `time` before `mix`, a physics
-  constraint's `x`/`y` before `rotate`. `src/keyorder.ts` lists every such pair.
-  Such a pair did not move, and nothing here says the editor agrees.
+  constraint's `x`/`y` before `rotate`. `src/keyorder.ts` lists every such pair,
+  and nothing here says the editor agrees.
 - **A kind with no row keeps rigc's order whole**: a linked mesh, a path or
   point attachment, a sequence, the path and slider constraints, an event
   definition, and the keys of every timeline the twelve do not key with two
@@ -8289,10 +7876,8 @@ says which.**
   `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
+`examples/`**. The twelve exports carry no mesh `path` or `color` and no slot
+name outside ASCII, 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/`.**
@@ -8300,51 +7885,46 @@ instead:
   `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
+  after `type`. 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**
+  codepoint sort nor the comparator without the fold does. 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`).
+  no-break space — still keeps the map in rigc's order, whole.
 
 🔸 **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
 order they are keyed — for timelines, the order they are applied in — so their
-order is more than a key's position, and rigc already emits the export's own on
-all twelve. A skin's `attachments` slot keys are the one name-keyed map this
-changed: sorted by the editor's comparator (§10.1). The per-slot maps inside are
+order is more than a key's position, and rigc emits the export's own on all
+twelve. A skin's `attachments` slot keys are the one name-keyed map rigc sorts: by
+the editor's comparator (§10.1). The per-slot maps inside are
 the rig's own order.
 
-⇒ **What this means for you: nothing to write.** No input format changed and no
-key order is yours to state — a rig spec is read by name, and its field order
-still means nothing. What changed is that a canonical-form comparison of an
-export's rebuild against the export no longer finds an object whose keys sit
-elsewhere (`IG76`). What it found next was the defaults the export leaves out
-and rigc wrote, `"name": null`, and the three header keys (`IG78`) — and since
-§10.6c it finds the header's `hash` and `spine` and nothing else (`IG83`).
+⇒ **What this means for you: nothing to write.** No key order is yours to state —
+a rig spec is read by name, and its field order means nothing. A canonical-form
+comparison of an export's rebuild against the export finds no object whose keys
+sit elsewhere, and with §10.6c it finds the header's `hash` and `spine` and
+nothing else.
 
 ### 10.6c The keys it leaves out
 
 The editor writes a key only where its value is not the one the parser reads in its
-absence, and since [#716](https://github.com/firejune/rigc/issues/716) rigc's emitter
-does the same, in one pass over the finished skeleton (`withoutParserDefaults` in
+absence, and rigc's emitter does the same, in one pass over the finished skeleton (`withoutParserDefaults` in
 `src/keyorder.ts`, run just before §10.6b's). A key is left out when its value is
 **exactly** the one below — the float the file would hold, not a value near it — so a
 rotation of `1e-45` is written and a rotation of `0` is not. The table is
 `PARSER_DEFAULTS`, and every row is the linked `spine-core` parser's own fallback
-(`getValue(map, key, default)` in `SkeletonJson.js`); the selftest loads an object of
-each kind with the key at that value and without it, and requires the two to be the
-same `SkeletonData` (`S103` on the in-tree builds, `IG82` on the corpus), and deletes
-every key of every in-tree build in turn to find one the table is missing (`S101`):
+(`getValue(map, key, default)` in `SkeletonJson.js`), and an object of each kind
+loads to the same `SkeletonData` with the key at that value and without it:
 
 | Kind | Left out when it is |
 | --- | --- |
@@ -8399,14 +7979,14 @@ read an absent `mixY` as that same `0`. *The key before's* is a sequence key's
   (`skeletonData.x = skeletonMap.x`, `SkeletonJson.js:70`), so an absent origin loads
   as `undefined` and a written `0` as `0`: there is no fallback for them to equal, and
   rigc keeps writing the origin of a declared stage. The editor leaves it out
-  (§10.6's round trip 6), so a rebuild of an export whose stage sits at `0,0` spells
+  (§10.6), so a rebuild of an export whose stage sits at `0,0` spells
   two fields the export does not — `LOSS HEADER_ORIGIN` says so on `ingest`.
 - **A transform constraint's `mixY` and `mixScaleY`.** Their fallback is the
   constraint's `mixX` / `mixScaleX` — but the parser reads those only for a property
   the constraint drives, so on one that drives `y` alone the fallback is the pose's
-  initial `0`, not `1`. A row there was tried and measured wrong: it left out
-  `8-follow-through-pro-ball`'s `"mixY": 1` on two such constraints, they loaded at
-  `0`, and `A48_TRANSFORM_CONSTRAINT_NOT_MUTED_THROUGHOUT` refused the rebuild.
+  initial `0`, not `1`. Measured: a row there would leave out
+  `8-follow-through-pro-ball`'s `"mixY": 1` on two such constraints, they would load
+  at `0`, and `A48_TRANSFORM_CONSTRAINT_NOT_MUTED_THROUGHOUT` refuses that rebuild.
 - **A region's `path`, an attachment's `name`, an event key's payload.** Their
   fallbacks are another value — the attachment's own name, its placeholder, the event
   definition's — which rigc writes only where it differs.
@@ -8417,19 +7997,21 @@ read an absent `mixY` as that same `0`. *The key before's* is a sequence key's
   stated.
 - **Every kind with no row** — the keys of a `shearx`, `sheary`, `inherit`, `alpha`,
   `rgb`, `rgb2`, `rgba2`, path `spacing`/`mix`, physics `gravity`/`reset` or slider
-  timeline, a linked mesh, a point attachment. No build the selftest loads and no
-  export carries an object of those kinds, and a row nothing loads is a claim about
-  the parser nobody has checked — where a missing row only costs a key the parser
-  reads the same either way. `S101` names such a key the day a build emits one.
-
-⚠️ **Why 4.3's defaults, when #706 row 4 says they are not every generation's.**
+  timeline, a linked mesh, a point attachment. No in-tree build and no export
+  carries an object of those kinds, and a row nothing loads is a claim about the
+  parser nobody has checked — where a missing row only costs a key the parser reads
+  the same either way.
+
+⚠️ **Why 4.3's defaults, when they are not every generation's** (row 4 of
+[GENERATIONS.md](https://github.com/firejune/rigc/blob/main/docs/GENERATIONS.md)'s
+table).
 An omitted physics `inertia` is 0.5 to the 4.3 parser and 1 to the 4.2 one, and that
 is exactly why a key is left out only against the parser rigc links: the file states
 `"spine": "4.3.13"`, and the parser it is gated against is that one. Writing the
 default out would not make the file safe for a 4.2 reader: that reader applies its
 own defaults to every *other* key the file leaves out as well — every one the editor's
-own 4.3 export leaves out, too — and #706 rows 1, 2 and 6 measure what reading one
-generation's data on another generation's runtime does, none of it repaired by one
+own 4.3 export leaves out, too — and that table's rows 1, 2 and 6 measure what
+reading one generation's data on another generation's runtime does, none of it repaired by one
 key written out. That misread is refused where it can be seen, on the reading side
 (`GENERATION_UNSUPPORTED` in `ingest`), rather than written for on the emitting one.
 
@@ -8447,7 +8029,7 @@ answer read off the exports:
 - any figure for keys per second, or for how key density scales with frame rate;
 - which curve type any particular example project or studio actually shipped;
 - whether a **corpus** export — one somebody else made, out of the editor's own
-  dialog — was made with Nonessential data checked. ⚠️ §10.5 now answers this for
+  dialog — was made with Nonessential data checked. ⚠️ §10.5 answers this for
   the **CLI's** `-e json`, where it is measured; that measurement says nothing
   about an export you were handed, and the two must not be read as one;
 - how many bones, slots or timelines a rig of a given size ought to have;
@@ -8480,21 +8062,10 @@ placements become a rig and a motion, what goes between two key poses when nothi
 was given for the in-betweens, and how to spread candidates so a `vote` ballot
 informs.
 
-📏 **Instrument re-baseline, 2026-09-03 — [#306](https://github.com/firejune/rigc/issues/306),
-and it applies to §12 as well.** The objective behind every `residual` in both
-commands now interpolates the frame in **premultiplied** space: a tap that
-straddles a silhouette weights each texel's colour by how much material is there,
-so a part is no longer charged for disagreeing with the ground it is drawn
-against. Nothing about the fields, the coordinate contract or the refusals
-changed, and no threshold moved — `--max-residual`, `--min-visible` and
-`--anchor-residual` are the numbers they were. ⚠️ **What did move is the residuals
-themselves**, downward and by small amounts, most on the parts whose edges are in
-the frame. ⇒ A residual measured before that date and one measured after are not
-the same measurement; re-read a frame rather than comparing across it. The worked
-figures live in [MOTION.md](MOTION.md) §6 and
-[BENCHMARK.md](https://github.com/firejune/rigc/blob/main/docs/BENCHMARK.md) —
-repository material, not shipped in the package — each with its own re-baseline
-note.
+📏 **The objective behind every `residual` here and in §12 interpolates the frame in
+premultiplied space**: a tap that straddles a silhouette weights each texel's colour
+by how much material is there, so a part is not charged for disagreeing with the
+ground it is drawn against. The worked figures live in [MOTION.md](MOTION.md) §6.
 
 ### 11.1 It measures an input, so nothing here is a score
 
@@ -8592,9 +8163,7 @@ holds nothing because it already contains every angle.
   an edge of a `--rotation` window narrower than a full turn, the detail names it:
   `best placement at scale 0.500, the floor of --scale 0.5,2 — the truth may lie below the window`.
   That is the case where the window is the first thing to move rather than the
-  frame or the threshold — eleven parts of one frame came back refused at
-  `scale=0.500` against art rendered at `0.311` per part pixel, and the message
-  said only that the residual was above `--max-residual`. The sentence — with its
+  frame or the threshold. The sentence — with its
   *"may lie below"* — is printed on a refusal only.
 - 🔒 **An accepted placement that stopped on a wall says which wall too**, beside
   the value it holds on the console line and in `walls`:
@@ -8646,7 +8215,7 @@ two things.
   with the `visibleShare` it was computed on. ⚠️ **`visibleShare` is a per-frame
   diagnostic and not a summary statistic** — it is measured through the fitted
   placements, so a median or a mean of it is not comparable across fits. §12.3 says
-  what that costs and [the 2026-09-03 study](https://github.com/firejune/rigc/blob/main/bench/studies/2026-09-03-visibleshare/README.md)
+  what that costs and [the `visibleShare` study](https://github.com/firejune/rigc/blob/main/bench/studies/2026-09-03-visibleshare/README.md)
   measures it — repository material, not shipped in the package.
 - **Hierarchy and attachment geometry**, so the search collapses. A child bone
   whose parent is already placed does not have four degrees of freedom: the rig
@@ -8679,7 +8248,7 @@ for the same frame** — `--anchor poseA.json` — and without one it runs that
 internally, over exactly the parts your candidate draws. A part becomes an anchor
 when `pose` came back **unambiguous** with `residual ≤ 0.16` and
 `unexplained ≤ 0.45`; those two numbers are `--anchor-residual` and a reported
-field, and they are the 2026-09-03 measurement run's own *clean frame* criterion
+field, and they are a measurement run's own *clean frame* criterion
 rather than a line invented here.
 
 An anchored part fixes its **whole bone** — four numbers read off the picture for
@@ -8712,9 +8281,9 @@ one of those placements reading `"inward"` to say what it rests on.
 ⚠️ **Which means the inward step reaches exactly the bones that BRANCH.** A bone
 whose children form a single sub-chain can never be determined, however good the
 anchor below it is: two equations, four unknowns. That is `no-bracket`, and it is
-a fact about your rig's topology rather than about the frame. On the 2026-09-03
-spineboy candidate `torso` is the only bone in the whole rig that branches — and
-it is the bone that recorded 30 `no-anchor` frames, which is why this exists.
+a fact about your rig's topology rather than about the frame. On a spineboy
+candidate `torso` is the only bone in the whole rig that branches — and without
+this step it is the bone that records 30 `no-anchor` frames.
 
 | Field on `bone.inward` | Meaning |
 | --- | --- |
@@ -8772,9 +8341,8 @@ themselves.
 evidence lives on the anchors below it. The bone's own `residual` and
 `visibleShare` say how much of the answer *the frame can independently confirm* —
 and **the visibility floor still refuses it** when the answer is one nothing in
-the picture can check. That is deliberate, and it is the second time this call has
-been made in `chainfit`: exempting a placement nothing searched was tried for
-anchors and reverted, because it prints a part nobody can see as READ. The floor
+the picture can check. That is deliberate: exempting a placement nothing searched
+prints a part nobody can see as READ. The floor
 is about what the picture can confirm, not about how the number was arrived at.
 
 ### 12.3 What the report adds to a `pose` report
@@ -8827,15 +8395,14 @@ the answer landed and is *less* steady, not more (p99 0.6588 against 0.5592).
 **The field is reporting a bistable fit faithfully.** What is safe: reading it beside
 its own residual, on its own frame — which is what it exists for. What is safe as a
 corpus statistic: a **maximum**, which saturates. Full method and evidence:
-[`bench/studies/2026-09-03-visibleshare`](https://github.com/firejune/rigc/blob/main/bench/studies/2026-09-03-visibleshare/README.md)
-([#323](https://github.com/firejune/rigc/issues/323)).
+[`bench/studies/2026-09-03-visibleshare`](https://github.com/firejune/rigc/blob/main/bench/studies/2026-09-03-visibleshare/README.md).
 
 And per part:
 
 | Field | Meaning |
 | --- | --- |
 | `role` | `anchor` (taken from the anchor pass, not re-fitted), `chain` (fitted through the rig), `inward` (**determined** from two or more anchored descendants, with nothing searched — §12.2b), `unplaced` |
-| — | ⭐ **A refused ANCHOR is not a contradiction, and it is the most useful row in the table.** The anchor pass judged that placement over the part's *whole* footprint — all `pose` can see, and blind to what covers it — while this instrument has just measured how much of the part is visible at all. Both readings are true. A refused anchor means *the placement may well be right and the confirmation is missing*, and every part whose `anchoredTo` names that bone rests on it. Measured on the 2026-09-03 corpus, `rear-bracer` clears `pose`'s criterion on 81 of 147 frames at a median visible share of **0.1%** — suppressing the refusal there was tried and prints that as READ. ⚠️ **That pair of numbers is on the pre-[#306](https://github.com/firejune/rigc/issues/306) objective** and has not been re-derived: the study is the 2026-09-03 run's own, over its own candidate, and re-running it is a run-scale job rather than a docs edit. A four-frame spot check under #306 (`--min-visible 0`, committed `ess` frames `idle/f0000`, `run/f0002`, `walk/f0004`, `aim/f0000`) moved `rear-bracer`'s anchor residual *down* on all four — 0.1564→0.1555, 0.1519→0.1513, 0.1493→0.1488, 0.1537→0.1534 — and flipped its eligibility on none, while `visibleShare` moved materially on one of the four (0.36→0.89). ⇒ Read the **shape** of the row, not those two digits. 🚨 **And that median in particular is one of the ones the 2026-09-03 study found unsafe**: `rear-bracer`'s share swings by **0.87** on `idle/f0001` inside `pose`'s own convergence band when the chain anchors on `pose`'s criterion — the basis this figure was taken on. The count and the shape are the reading; the 0.1 % is not a number |
+| — | ⭐ **A refused ANCHOR is not a contradiction, and it is the most useful row in the table.** The anchor pass judged that placement over the part's *whole* footprint — all `pose` can see, and blind to what covers it — while this instrument has just measured how much of the part is visible at all. Both readings are true. A refused anchor means *the placement may well be right and the confirmation is missing*, and every part whose `anchoredTo` names that bone rests on it. Measured over the 147 committed `ess` frames, `rear-bracer` clears `pose`'s criterion on 81 of 147 frames at a median visible share of **0.1%** — suppressing the refusal there prints that as READ. ⚠️ **That pair of numbers was taken before the objective interpolated in premultiplied space (§11).** A four-frame spot check on the current objective (`--min-visible 0`, committed `ess` frames `idle/f0000`, `run/f0002`, `walk/f0004`, `aim/f0000`) moved `rear-bracer`'s anchor residual *down* on all four — 0.1564→0.1555, 0.1519→0.1513, 0.1493→0.1488, 0.1537→0.1534 — and flipped its eligibility on none, while `visibleShare` moved materially on one of the four (0.36→0.89). ⇒ Read the **shape** of the row, not those two digits. 🚨 **And that median in particular is one of the ones the `visibleShare` study found unsafe**: `rear-bracer`'s share swings by **0.87** on `idle/f0001` inside `pose`'s own convergence band when the chain anchors on `pose`'s criterion — the basis this figure was taken on. The count and the shape are the reading; the 0.1 % is not a number |
 | — | The **other** parts on an anchored bone are refused on their own numbers too, and there they mean something different again: their placement is the **rig's** prediction from that anchor, so their residual is a measurement of the rig (a goggle plate that will not sit on the head it is parented to shows up exactly here) |
 | `bone` | the bone this hangs off: its `parent`, its `setupRotationDeg`, its `depth` in links from the anchor, `anchoredTo`, the `dof` searched, the `window` taken, the other parts `sharedWith` it on that bone, and `carriedBones` |
 | `bone.dof.pivotFree` | your candidate keys a `translate` timeline on this bone, so the arc this answer sits on has a centre the rig itself moves. The placement is still read off pixels; `localRotationDeg` alone will not reproduce it |
@@ -8857,7 +8424,7 @@ simply unused; a name the directory lacks is refused `no-part-image` by name.
 | --- | --- |
 | `--anchor <pose.json>` | use this `rigc pose` report instead of running one. Refused together with `--scale` / `--rotation`, which size the internal pass that then does not happen |
 | `--atlas` | **refused by name.** Every other `--candidate` command takes it, so trying it here is reasonable — but the part art comes from `--images` and the skeleton is all this needs of the candidate, so a flag that silently did nothing would be worse than one that says why |
-| `--hinge <min,max>` | the window each child's local rotation is searched over, in Spine degrees about its setup value. Default `-180,180` — **a full turn, on purpose**: one degree of freedom is cheap enough to sweep exhaustively, and §11.4's warning about a window that does not contain the truth applies here too. The hinge step `3°` is a **ceiling** on the step, not the step: a window it does not divide is divided into whole steps no coarser than it, and `search` states the step that division produced, so `--hinge -20,20` prints `hinge -20°–20° step 2.857° (15 rungs)` and each chain part's note says it was searched `in 2.857° steps`. The full turn divides it exactly, so the default walks the same rungs it always did |
+| `--hinge <min,max>` | the window each child's local rotation is searched over, in Spine degrees about its setup value. Default `-180,180` — **a full turn, on purpose**: one degree of freedom is cheap enough to sweep exhaustively, and §11.4's warning about a window that does not contain the truth applies here too. The hinge step `3°` is a **ceiling** on the step, not the step: a window it does not divide is divided into whole steps no coarser than it, and `search` states the step that division produced, so `--hinge -20,20` prints `hinge -20°–20° step 2.857° (15 rungs)` and each chain part's note says it was searched `in 2.857° steps`. The full turn divides it exactly |
 | `--stretch <ratio>` | also search a uniform bone scale, this ratio either way. Without it, stretch is searched **only where your own animations key a `scale` timeline on that bone** — a rig that never scales a bone is a rig saying that bone does not stretch |
 | `--min-visible <0..1>` | below this visible share a placement is refused `occluded` instead of reported flat (default `0.25`). A reporting threshold, not a pass bar; the placement is still in the JSON. ⚠️ **It is not inert, though**: a bone whose frozen share is under this floor gets one *unmasked* look before its visible set is fixed, so the flag also changes **where parts land** and not only which rows are refused. Two runs at different `--min-visible` are two fits, and their shares are not one column |
 | `--max-residual <0..1>` | as §11, over the visible pixels (default `0.25`) |