Animation moved into `@step(animation=...)`, embedded in the document's
sidecar. Nothing looks beside the document for a companion ES module any more,
so a project carrying one across the cutover got exactly the outcome law 10
forbids: a model that used to articulate renders inert, at exit 0, with no
message anywhere. Law 8 wants that file to fail and name its replacement.
The build refuses it. The check sits in `_validate_step_target`, the per-target
gate every `python model.py` and `cadgen step build` passes through, rather
than inside the build itself: a model whose tree is already current takes the
no-op path, and a check that only ran when geometry was recomputed would let
the stale file survive every later run.
The viewer does the opposite, because a door never refuses a document (law 1).
`artifact_status` attaches a warning naming `@step(animation=...)` to whatever
state it returns, and `cadgen_ops` keeps it on the narrowed compile offer --
the branch such a model most often lands in. `cadgen step snapshot --animation`
already taught the same thing and is unchanged.
The docs said the opposite in both places. `skills/cad/references/migrations.md`
claimed a companion `.js` is read when a decorator names it, which is no longer
how any of it works. The 0.4 -> 0.5 guide describes the 0.5.0 arrangement
throughout, so rather than rewrite its history it gains a "Since 0.5.1: the
render module moved into the decorator" section up front that the `.step.js`
passages now point to, with each of those passages corrected to match.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WdPH8Hshoe4ZPmSWhQDSB4
Claude
7952e9e17a