motionloom 2.3.0 → 2.4.0

package/docs/STATUS.md

@@ -4,7 +4,7 @@
 
 ## Current release posture
 
-MotionLoom's repository source and package manifest are prepared for **2.3.0 release metadata**. The publication state of the npm registry and GitHub Release/tag must be verified against the latest release workflow rather than inferred from this document. The repository has a cross-platform CLI, one-command project onboarding, durable Project Memory, Agent interoperability surfaces, artifact-first handoff, runtime evidence, Visual Truth, Remediation Learning, signed attestation, AI-first asset provenance and a browser-based Dev Lab review contract. The protected manual release workflow verifies package/changelog/release-note alignment before publication.
+MotionLoom's repository source and package manifest are prepared for **2.4.0 release metadata**. The publication state of the npm registry and GitHub Release/tag must be verified against the latest release workflow rather than inferred from this document. The repository has a cross-platform CLI, one-command project onboarding, durable Project Memory, Agent interoperability surfaces, artifact-first handoff, runtime evidence, Visual Truth, Remediation Learning, signed attestation, AI-first asset provenance, a truthful code-authored runtime lane and a browser-based Dev Lab review contract. The protected manual release workflow verifies package/changelog/release-note alignment before publication.
 
 The repository is **engineering-ready for continued integration work**, not a universal production certification for every animation framework or every host project. CI status must be read from the latest GitHub Actions run, not inferred from historical audit prose.
 
@@ -30,4 +30,4 @@ Use the following order when sources disagree:
 
 ## Known next work
 
-The bounded analyzer has now been exercised against a labeled external corpus; see the [dated evidence note](audits/external-project-corpus-2026-08-13.md). The highest-value remaining evidence work is paired product evaluation across more real projects and verification of the 2.3.0 version–tag–GitHub Release–npm provenance chain. Missing external projects are reported as `insufficient_evidence`, never as a pass. None of these items should weaken the user-review gate or convert heuristic warnings into approval.
+The bounded analyzer has now been exercised against a labeled external corpus; see the [dated evidence note](audits/external-project-corpus-2026-08-13.md). The highest-value remaining evidence work is paired product evaluation across more real projects and verification of the 2.4.0 version–tag–GitHub Release–npm provenance chain. Missing external projects are reported as `insufficient_evidence`, never as a pass. None of these items should weaken the user-review gate or convert heuristic warnings into approval.

package/docs/audits/data/deep-stress-latest.json

@@ -1,7 +1,7 @@
 {
   "schema_version": "1.0",
   "audit": "motionloom-deep-stress",
-  "generated_at": "2026-08-13T10:13:55.979988Z",
+  "generated_at": "2026-08-14T18:59:00.435638Z",
   "seed": 20260813,
   "requested_iterations": 5000,
   "actual_iterations": 6900,
@@ -29,9 +29,9 @@
       "codes": {
         "equal": 600
       },
-      "p50_ms": 0.018526,
-      "p95_ms": 0.019782,
-      "max_ms": 0.034744,
+      "p50_ms": 0.01868,
+      "p95_ms": 0.022651,
+      "max_ms": 0.041323,
       "pass_rate": 1.0
     },
     "dsse-ed25519-roundtrip": {
@@ -43,9 +43,9 @@
       "codes": {
         "verified": 250
       },
-      "p50_ms": 0.127995,
-      "p95_ms": 0.141972,
-      "max_ms": 0.244296,
+      "p50_ms": 0.129434,
+      "p95_ms": 0.145666,
+      "max_ms": 0.186531,
       "pass_rate": 1.0
     },
     "dsse-ed25519-tamper": {
@@ -57,9 +57,9 @@
       "codes": {
         "invalid-signature": 250
       },
-      "p50_ms": 0.131456,
-      "p95_ms": 0.144911,
-      "max_ms": 0.257528,
+      "p50_ms": 0.131737,
+      "p95_ms": 0.155588,
+      "max_ms": 0.218171,
       "pass_rate": 1.0
     },
     "statement-contract": {
@@ -72,9 +72,9 @@
         "valid": 200,
         "rejected": 400
       },
-      "p50_ms": 0.007304,
-      "p95_ms": 0.008605,
-      "max_ms": 0.063033,
+      "p50_ms": 0.007154,
+      "p95_ms": 0.008546,
+      "max_ms": 0.06488,
       "pass_rate": 1.0
     },
     "attestation-verifier-boundary": {
@@ -89,9 +89,9 @@
         "14": 375,
         "13": 375
       },
-      "p50_ms": 0.300549,
-      "p95_ms": 0.484133,
-      "max_ms": 0.866072,
+      "p50_ms": 0.297953,
+      "p95_ms": 0.485624,
+      "max_ms": 0.742145,
       "pass_rate": 1.0
     },
     "strict-quality-gate-clean": {
@@ -103,9 +103,9 @@
       "codes": {
         "accepted": 400
       },
-      "p50_ms": 25.817357,
-      "p95_ms": 28.37167,
-      "max_ms": 35.746459,
+      "p50_ms": 25.03624,
+      "p95_ms": 26.647454,
+      "max_ms": 36.626597,
       "pass_rate": 1.0
     },
     "intelligence-p1-clean": {
@@ -117,9 +117,9 @@
       "codes": {
         "accepted": 400
       },
-      "p50_ms": 19.18085,
-      "p95_ms": 21.672868,
-      "max_ms": 29.969583,
+      "p50_ms": 18.137953,
+      "p95_ms": 18.818408,
+      "max_ms": 22.29844,
       "pass_rate": 1.0
     },
     "replay-hash-clean": {
@@ -131,9 +131,9 @@
       "codes": {
         "clean": 475
       },
-      "p50_ms": 7.51816,
-      "p95_ms": 7.916555,
-      "max_ms": 11.545468,
+      "p50_ms": 8.196194,
+      "p95_ms": 8.346516,
+      "max_ms": 9.307598,
       "pass_rate": 1.0
     },
     "semantic-lint-clean": {
@@ -145,9 +145,9 @@
       "codes": {
         "clean": 475
       },
-      "p50_ms": 0.024703,
-      "p95_ms": 0.03313,
-      "max_ms": 0.08727,
+      "p50_ms": 0.02188,
+      "p95_ms": 0.025799,
+      "max_ms": 0.048701,
       "pass_rate": 1.0
     },
     "continuity-clean": {
@@ -159,9 +159,9 @@
       "codes": {
         "clean": 475
       },
-      "p50_ms": 0.024346,
-      "p95_ms": 0.033119,
-      "max_ms": 0.052678,
+      "p50_ms": 0.023042,
+      "p95_ms": 0.026202,
+      "max_ms": 0.045252,
       "pass_rate": 1.0
     },
     "approval-invariant": {
@@ -173,9 +173,9 @@
       "codes": {
         "approval=false": 475
       },
-      "p50_ms": 0.063713,
-      "p95_ms": 0.080847,
-      "max_ms": 0.1211,
+      "p50_ms": 0.056737,
+      "p95_ms": 0.067291,
+      "max_ms": 0.099394,
       "pass_rate": 1.0
     },
     "fault-graph-task-id": {
@@ -187,9 +187,9 @@
       "codes": {
         "rejected": 100
       },
-      "p50_ms": 13.765242,
-      "p95_ms": 15.757552,
-      "max_ms": 17.026196,
+      "p50_ms": 14.317844,
+      "p95_ms": 14.713064,
+      "max_ms": 15.184861,
       "pass_rate": 1.0
     },
     "fault-motion-ir-scene": {
@@ -201,9 +201,9 @@
       "codes": {
         "rejected": 100
       },
-      "p50_ms": 2.148835,
-      "p95_ms": 2.448147,
-      "max_ms": 2.860418,
+      "p50_ms": 2.077654,
+      "p95_ms": 2.140575,
+      "max_ms": 2.284035,
       "pass_rate": 1.0
     },
     "fault-provenance-task-id": {
@@ -215,9 +215,9 @@
       "codes": {
         "rejected": 100
       },
-      "p50_ms": 0.857105,
-      "p95_ms": 1.049827,
-      "max_ms": 1.36859,
+      "p50_ms": 0.849407,
+      "p95_ms": 0.886464,
+      "max_ms": 0.94938,
       "pass_rate": 1.0
     },
     "fault-replay-path-escape": {
@@ -229,9 +229,9 @@
       "codes": {
         "rejected": 100
       },
-      "p50_ms": 8.091177,
-      "p95_ms": 9.353946,
-      "max_ms": 10.112846,
+      "p50_ms": 8.246496,
+      "p95_ms": 8.347693,
+      "max_ms": 9.112055,
       "pass_rate": 1.0
     },
     "fault-p1-fix-plan-hash": {
@@ -243,9 +243,9 @@
       "codes": {
         "rejected": 100
       },
-      "p50_ms": 0.730294,
-      "p95_ms": 0.866361,
-      "max_ms": 1.132574,
+      "p50_ms": 0.735113,
+      "p95_ms": 0.772903,
+      "max_ms": 0.896587,
       "pass_rate": 1.0
     },
     "fault-p1-wrong-scene": {
@@ -257,9 +257,9 @@
       "codes": {
         "rejected": 100
       },
-      "p50_ms": 0.675249,
-      "p95_ms": 0.807189,
-      "max_ms": 1.103894,
+      "p50_ms": 0.709162,
+      "p95_ms": 0.732217,
+      "max_ms": 0.772478,
       "pass_rate": 1.0
     },
     "fault-continuity-structure": {
@@ -271,9 +271,9 @@
       "codes": {
         "rejected": 100
       },
-      "p50_ms": 0.066832,
-      "p95_ms": 0.081028,
-      "max_ms": 0.100648,
+      "p50_ms": 0.098924,
+      "p95_ms": 0.10896,
+      "max_ms": 0.126946,
       "pass_rate": 1.0
     },
     "fault-semantic-structure": {
@@ -285,9 +285,9 @@
       "codes": {
         "rejected": 100
       },
-      "p50_ms": 0.064075,
-      "p95_ms": 0.081449,
-      "max_ms": 0.116428,
+      "p50_ms": 0.094954,
+      "p95_ms": 0.102869,
+      "max_ms": 0.109556,
       "pass_rate": 1.0
     },
     "fault-attestation-approval": {
@@ -299,9 +299,9 @@
       "codes": {
         "10": 100
       },
-      "p50_ms": 0.204615,
-      "p95_ms": 0.265782,
-      "max_ms": 0.341527,
+      "p50_ms": 0.224069,
+      "p95_ms": 0.2494,
+      "max_ms": 0.264081,
       "pass_rate": 1.0
     },
     "fault-attestation-payload": {
@@ -313,9 +313,9 @@
       "codes": {
         "11": 100
       },
-      "p50_ms": 0.262104,
-      "p95_ms": 0.301103,
-      "max_ms": 0.414031,
+      "p50_ms": 0.283996,
+      "p95_ms": 0.310437,
+      "max_ms": 0.370236,
       "pass_rate": 1.0
     }
   },
@@ -325,5 +325,5 @@
     "false_positive": "A clean canonical case was rejected.",
     "false_negative": "A controlled tamper, binding, revocation or invalid-contract case was accepted."
   },
-  "wall_time_s": 25.354826
+  "wall_time_s": 25.466197
 }

package/docs/releases/2.4.0.md

@@ -0,0 +1,31 @@
+# MotionLoom 2.4.0
+
+## Summary
+
+MotionLoom 2.4.0 adds a **runtime-first, code-authored** path for agents that need to prove animation behavior without misclassifying a code scene as an artist-authored or AI-generated visual asset. The reference Framer Motion pilot moves through Artifact Intake, runtime rendering, integrity verification and identity-bound Dev Lab review while maintaining the existing human-governed release boundary.
+
+## Added
+
+### Truthful runtime-first provenance
+
+The Artifact Intake and provenance surfaces now recognize `code_authored` runtime scenes explicitly. Source code, controls, export data and provenance are hash-bound, but this evidence only permits runtime review. It never grants `artist_authored`, `production_eligible`, `production_approved` or PR authorization.
+
+### Framer Motion end-to-end reference candidate
+
+The repository includes `runtime-pilot-framer`, a code-authored Framer Motion scene rendered by the production adapter at 0%, 50% and 100%. The candidate includes runtime telemetry, an evidence-verifier report, a local-only attestation with `approval: false`, and an identity-bound review handoff for the MotionLoom Dev Lab.
+
+### Identity-bound Quality task resolution
+
+Quality CI resolves the task bundle by the scene declared in `task.json`, instead of requiring a historical `artifacts/<scene>-task` naming convention. The resolver fails closed for absent, ambiguous or mismatched bindings, and its regression coverage includes a task ID that intentionally differs from the scene slug.
+
+## Fixed
+
+The Quality workflow no longer fails during runtime telemetry capture for a correctly bound task bundle whose directory name differs from its scene name. All task-aware steps now consume the resolver map rather than reconstructing task paths independently.
+
+## Verified behavior
+
+Before publication, the target is validated with the full regression harness, `doctor`, documentation audit, Skill validation, package dry-run, diff hygiene and the GitHub Quality, Documentation & Package Hygiene, Security Analysis and Dev Lab Build workflows.
+
+## Trust boundary
+
+The code-authored lane is **runtime-ready, not production-ready**. Runtime evidence, signature verification, task binding and Dev Lab staging do not replace human visual review. The default remains local-only: MotionLoom does not commit, push, open a pull request, tag a release or publish to npm without the relevant explicit user or maintainer action.

package/docs/releases/npm-publish-from-workstation.md

@@ -1,6 +1,6 @@
 # Publish MotionLoom to npm from your workstation
 
-This guide publishes the prepared `motionloom@2.3.0` package from your own computer. The npm password, authenticator code and access token must stay on your computer; never paste them into chat, GitHub issues or repository files.
+This guide publishes the prepared `motionloom@2.4.0` package from your own computer. The npm password, authenticator code and access token must stay on your computer; never paste them into chat, GitHub issues or repository files.
 
 ## 1. Install prerequisites
 
@@ -25,7 +25,7 @@ git pull --ff-only origin main
 git log -1 --oneline
 ```
 
-The latest commit must be the npm packaging release announced in the task. Do not publish from an older checkout or from a different fork.
+The latest commit must be the npm packaging release announced in the task. Do not publish from an older checkout or from a different fork. This repository declares `pnpm` as its package manager and intentionally does not ship a `package-lock.json`; do **not** run `npm ci` in the repository. The release verifier and package dry-run do not require a dependency install. If a full workspace install is needed, use the declared package manager with `pnpm install --frozen-lockfile`.
 
 ## 3. Authenticate npm locally
 
@@ -48,7 +48,7 @@ npm pack --dry-run --json --ignore-scripts
 npm publish --dry-run --access public
 ```
 
-The dry-run should report `motionloom@2.3.0`, public access, and the current package file list. Do not hard-code a historical file count: inspect the JSON output and compare it with the checked-in package allowlist. The prepack hook removes generated Python bytecode before packaging. Do not publish if the dry-run shows private keys, `.env` files, `artifacts/`, `dev-lab/` or `__pycache__/` entries.
+The dry-run should report `motionloom@2.4.0`, public access, and the current package file list. Do not hard-code a historical file count: inspect the JSON output and compare it with the checked-in package allowlist. The prepack hook removes generated Python bytecode before packaging. Do not publish if the dry-run shows private keys, `.env` files, `artifacts/`, `dev-lab/` or `__pycache__/` entries.
 
 ## 5. Publish the package
 
@@ -58,15 +58,17 @@ When the dry-run is correct and `npm whoami` shows the intended account, publish
 npm publish --access public
 ```
 
-The version `2.3.0` becomes immutable on npm after a successful publish. If npm reports that the version already exists, stop and verify the registry instead of trying to overwrite it.
+Do not add `--provenance` unless the local npm client and its CI/provider integration explicitly support automatic npm provenance. Some workstation setups report `Automatic provenance generation not supported for provider: null`; in that case the package itself is still valid, and the supported fallback for this release is the command above without `--provenance`. Never retry by changing the version or by bypassing the package verification steps.
+
+The version `2.4.0` becomes immutable on npm after a successful publish. If npm reports that the version already exists, stop and verify the registry instead of trying to overwrite it.
 
 ## 6. Verify the registry publication
 
-Run the following commands and confirm that they return `2.3.0` and a tarball URL:
+Run the following commands and confirm that they return `2.4.0` and a tarball URL:
 
 ```bash
 npm view motionloom version --registry=https://registry.npmjs.org/
-npm view motionloom@2.3.0 name version license dist.tarball dist.shasum --json \
+npm view motionloom@2.4.0 name version license dist.tarball dist.shasum --json \
   --registry=https://registry.npmjs.org/
 ```
 
@@ -76,7 +78,7 @@ Then test installation in a clean temporary directory:
 TMP_DIR="$(mktemp -d)"
 cd "$TMP_DIR"
 npm init --yes
-npm install motionloom@2.3.0
+npm install motionloom@2.4.0
 motionloom --help
 motionloom doctor
 ```
@@ -85,4 +87,13 @@ The CLI should print the MotionLoom command surface. `motionloom doctor` should
 
 ## Troubleshooting
 
-If `npm whoami` returns `ENEEDAUTH`, repeat `npm login` on the same computer and registry. If publishing returns `E403`, check package ownership, organization publish permission and 2FA policy; do not disable security controls. If the package name is already claimed, stop and choose a scoped name such as `@your-npm-user/motionloom`, then update `name` and `publishConfig` before publishing a new package identity. Never place an npm token in `package.json`, `.npmrc` committed to Git, shell history or chat.
+If `npm whoami` returns `ENEEDAUTH`, repeat `npm login` on the same computer and registry. If `npm ci` reports that no `package-lock.json` exists, skip it and use the release verifier directly; this repository is pnpm-managed. If `npm publish --provenance` reports that the provider is `null` or unsupported, retry `npm publish --access public` without that flag. If publishing returns `E404` on the `PUT` request, do not change the package name or version yet. First run these read-only checks against the public registry:
+
+```bash
+npm config get registry
+npm whoami --registry=https://registry.npmjs.org/
+npm view motionloom name version maintainers --json --registry=https://registry.npmjs.org/
+npm access list collaborators motionloom --json --registry=https://registry.npmjs.org/
+```
+
+The `npm whoami` result must be the intended publisher, and the collaborators result must show that account with publish-capable access. A mismatch usually means the workstation is authenticated as a different npm user, is using a stale token, or the package is owned by another account or team. Re-authenticate only on the workstation with `npm logout` followed by `npm login --registry=https://registry.npmjs.org/`; never paste the token into chat. If the account is correct but publish access is absent, the package owner must grant the account read-write access or publish from the owner account. If publishing returns `E403`, check package ownership, organization publish permission and 2FA policy; do not disable security controls. If the package name is already claimed by an account you do not control, stop and do not rename this release without an explicit release decision. Never place an npm token in `package.json`, `.npmrc` committed to Git, shell history or chat.

package/docs/research/agent-skill-ecosystem-notes.md

@@ -0,0 +1,47 @@
+# Ghi chú evidence: kỹ năng nội bộ và Agent Skills đa nền tảng
+
+**Ngày khảo sát:** 15 tháng 8 năm 2026
+
+## ImageGen nội bộ
+
+Skill `imagegen` hiện có của Agent là một bộ hướng dẫn routing/production cho visual deliverable. Với game asset, skill đặt tiêu chí là silhouette tái sử dụng, perspective nhất quán và clean edges; với transparent asset, tiêu chí gồm alpha sạch, subject đầy đủ, không colored fringe hoặc background/shadow không mong muốn. Skill yêu cầu phân biệt creation/editing mang tính semantic với image processing thuần deterministic, và yêu cầu lightweight validation trước delivery.
+
+Điều này tạo một boundary rõ cho MotionLoom: ImageGen có thể là **nguồn tạo hoặc chỉnh visual asset**, còn MotionLoom nhận output cùng metadata, đo alpha/geometry/atlas/runtime và quản lý evidence/review. Không được giả định ImageGen tự phát hành seed, model version, license, rig map hoặc production approval. Vì không có API/credential contract trong core MotionLoom, adapter ban đầu phải là `scaffold` receipt importer, không phải provider invoker.
+
+## Codex Skills
+
+OpenAI mô tả Skill là bundle có version gồm file và `SKILL.md`, hỗ trợ local shell hoặc hosted container, và tương thích Agent Skills standard. Khi skill được mount, model nhìn metadata rồi quyết định kích hoạt; tài liệu cũng yêu cầu xem Skill là code/instruction đặc quyền, kiểm tra trước khi tích hợp và đặt approval cho high-impact action. [1]
+
+MotionLoom cần tiếp tục giữ `SKILL.md`, artifacts và local-only default, đồng thời chỉ nhận generator metadata từ một skill đã được user/project cài đặt. Một skill descriptor không phải bằng chứng rằng output asset đã được tạo đúng hoặc được người dùng phê duyệt.
+
+## Claude Code Skills
+
+Claude Code mô tả Skill là thư mục có `SKILL.md`, có thể được load khi relevant hoặc gọi trực tiếp; built-in skills như `/debug`, `/code-review` và `/verify` cũng là prompt-based orchestration. Tài liệu đặc biệt có giá trị với MotionLoom ở ý tưởng ghi lại run/verify recipe trong project skill để agent sau đó lặp lại workflow đã thành công thay vì suy đoán lại environment. [2]
+
+MotionLoom đã đi theo cùng hướng với Project Memory và `setup/status/repair`. Adapter registry sẽ chỉ lưu provider capability/evidence, không tự động chạy một external skill hay mở PR.
+
+## Gemini CLI Skills
+
+Gemini CLI cũng dùng Agent Skills standard với lifecycle discovery → activation → consent → injection → execution. Tài liệu nêu built-in, extension, user và workspace tiers; `.agents/skills/` được dùng làm alias interoperable. Activation cần consent và skill folder trở thành permitted path sau approval. [3]
+
+Điều này củng cố hai yêu cầu cho MotionLoom: registry phải mô tả **capability** thay vì vendor prompt; và skill/adapter có side effect phải có explicit user approval. MotionLoom nên phát hành artifacts portable tại workspace/package level, nhưng không được trở thành một catalog tải/chạy skills tùy ý.
+
+## Contract decision
+
+Adapter registry sẽ dùng các giá trị sau:
+
+| Field | Quyết định |
+|---|---|
+| `adapter_id` | Tên capability ổn định, ví dụ `local-fixture` hoặc `internal-imagegen`, không phải claim về ownership/model quality. |
+| `kind` | `fixture`, `internal_skill`, `external_provider` hoặc `manual_import`. |
+| `status` | `verified`, `scaffold` hoặc `blocked`, chỉ `verified` khi có regression và runtime evidence đúng phạm vi. |
+| `invocation_mode` | `none`, `manual`, `agent-mediated` hoặc `api`; core validator không thực thi invocation. |
+| `cost_class` | `included`, `metered`, `external`, `unknown`; informational only, không phải billing proof. |
+| `evidence_requirements` | Receipt, output hashes, source/provenance reference và runtime evidence tùy output kind. |
+| `approval` | Luôn external/user; registry/receipt không chứa quyền mở PR hay production approval. |
+
+## References
+
+[1]: https://developers.openai.com/api/docs/guides/tools-skills "OpenAI API — Skills"
+[2]: https://code.claude.com/docs/en/skills "Claude Code — Skills"
+[3]: https://geminicli.com/docs/cli/skills/ "Gemini CLI — Agent Skills"

package/docs/research/ai-animation-tools-2026-notes.md

@@ -0,0 +1,81 @@
+# AI Animation and Asset Tools — Research Notes
+
+> Working research notes. Claims below are discovery leads from official-site search results and must be verified by opening the source pages before inclusion in the final report.
+
+## Initial source leads
+
+| Tool / family | Official URL | Discovery lead to verify |
+|---|---|---|
+| PixelLab | https://www.pixellab.ai/ | AI pixel-art game assets, animated characters, sprite sheets and environments. |
+| PixelLab API | https://www.pixellab.ai/pixellab-api | API-oriented generation of characters, animations and environments for procedural/live asset creation. |
+| Runway | https://runway.com/product | Text-to-video and image-to-video generation, plus image generation/editing. |
+| DeepMotion | https://www.deepmotion.com/ | Browser-based AI motion capture and body tracking that produces 3D animation from video. |
+| Rokoko Vision | https://www.rokoko.com/products/vision | Video-to-3D animation through an AI mocap solver. |
+| Scenario | https://www.scenario.com/ | Style-consistent game asset generation and animated video positioning; workflow details require verification. |
+| Leonardo AI | https://leonardo.ai/news/how-to-generate-a-full-game-asset-suite-with-leonardo-ai | Game asset ideation, iteration and refinement workflow; official article requires verification. |
+| Ludo.ai | https://ludo.ai/features/sprite-generator | Sprite generation and animation workflow; official feature page requires verification. |
+| GameLab Studio | https://gamelabstudio.co/ | AI sprite-sheet and transparent animation generation; official claims require verification. |
+
+## Planned comparison dimensions
+
+1. Input controls: text, reference image, video, pose/motion reference, style training or project memory.
+2. Output model: raster frames, sprite sheet, atlas, 2D rig, 3D skeleton animation, video, vector/timeline or runtime component.
+3. Temporal/identity consistency: seed, reference locking, character/style model, pose control, frame geometry and loop controls.
+4. Production integration: export formats, API/CLI, engine/runtime adapters, metadata, versioning and deterministic replay.
+5. Human governance: provenance, license/source records, review checkpoints, editability and approval boundaries.
+6. MotionLoom relevance: which capability belongs in project memory, contracts, analyzers, runtime evidence, Dev Lab or handoff.
+
+## Verified findings — PixelLab
+
+Source pages opened:
+
+- https://www.pixellab.ai/
+- https://www.pixellab.ai/docs/tools/animate-with-skeletons
+
+The official product page exposes separate workflows for one-click animation, skeleton-based animation and text-described animation. It also lists 4/8 directional rotation, reference-based style consistency, true inpainting, scenes, tilesets and UI elements. The animation copy explicitly targets walking, running, attacking and custom sprite-sheet animations. The page also positions scene animation as text-described motion for animated environments and dynamic backgrounds.
+
+The skeleton documentation page is currently a product/tutorial-style page rather than a full API specification. It confirms the product surface includes skeleton controls, automatic character animation and reference-driven generation, but it does not yet provide enough public detail to claim deterministic skeleton export, frame hashing, atlas metadata or runtime bindings. Those remain questions for MotionLoom to verify at the artifact/export boundary instead of inferring them from visual output.
+
+Initial design lesson: a useful AI asset tool separates **character identity/style editing**, **motion authoring**, **directional rotation**, **environment/tileset generation** and **inpainting** into distinct operations. MotionLoom should model these as explicit artifact stages and contracts, not as one generic "generate animation" action.
+
+The official PixelLab API page exposes a more structured pipeline than the homepage alone suggests. It separates image generation, image operations, animation, rotation, inpainting/editing, map/tileset generation, character/object state management and prompt enhancement. Relevant animation operations include text animation, text animation v3 with optional start/end frames and up to 16 frames, skeleton animation, skeleton estimation, character animation and animation editing. It also exposes interpolation between images/animations and outfit transfer across frames. Character and object operations are persisted as reusable entities with later states and animations, which is a useful identity-first model.
+
+The API page also reveals concrete limits and options such as transparent output, forced palettes, init images, inpainting, direction/view controls, maximum canvas/frame sizes and explicit frame counts. These are implementation facts for PixelLab's API surface, not evidence that every output is production-safe. MotionLoom should treat them as source metadata and then measure the returned artifacts independently.
+
+The official style-reference guide states that users add one or more style reference images, describe the desired asset and generate multiple variations. It describes a grid/frame-output relationship based on the largest reference-image dimension and exposes a large reference-image count at small sizes. The important lesson is that style consistency is reference-conditioned and parameterized by output geometry; it is not merely a textual prompt convention. MotionLoom's identity manifest, palette/camera/scale fields and frame-geometry analyzer are the natural verification layer after such a generator.
+
+## Verified findings — Runway and DeepMotion
+
+Runway's official Gen-4 research page describes a reference-conditioned video workflow: visual references plus instructions are used to create images/videos while maintaining consistent characters, locations, objects, style, mood and cinematographic elements across scenes and perspectives. It emphasizes that this is achieved without fine-tuning or additional training. For MotionLoom, the transferable idea is a reusable **reference bundle** and scene-level identity rather than re-prompting a character from scratch for every shot. The non-transferable assumption is that visual consistency alone proves a game-ready frame contract; raster bounds, sockets, timing and runtime evidence still need independent checks.
+
+DeepMotion's official homepage exposes two distinct products/workflows: SayMotion for text-to-3D animation and Animate 3D for video-to-3D animation. It also exposes an Animate 3D API surface in the site navigation. The key architectural lesson is the separation between **motion source acquisition** (text or video) and **3D animation output**. MotionLoom should model body animation as a source-bound motion artifact with rig/skeleton compatibility, retargeting metadata and runtime evidence, not as an opaque generated clip.
+
+Rokoko Vision 3.0's official page describes a four-step workflow: upload a video, generate 3D motion, edit/view/loop the capture in Rokoko Studio, upload a character for retargeting, then export to FBX or BVH for tools such as Blender, Unity and Unreal. This is a strong reference for MotionLoom's body-rig path because it makes cleanup, looping, skeleton choice and export explicit stages after AI inference. The page also links integrations and motion-data workflows, reinforcing that the generated result is an editable motion artifact rather than only a rendered video.
+
+Luma's official Ray3.2 page positions multi-keyframe control, Modify Video and Motion/Structure settings as first-class controls. The page exposes FAQ topics for preserving actor/performance, lip-sync/dialogue timing, source-video frame rate, footage suitability and keyframe counts. Even where the page does not expose all answers in static extraction, the architecture is clear: preserve source motion/structure while changing appearance, and use explicit keyframes to direct continuity. MotionLoom can learn the separation between source motion, structural constraints and appearance transformation, while still requiring its own runtime telemetry and artifact checks.
+
+Scenario's official platform page describes an AI creative infrastructure spanning image, video, audio and 3D, with a custom-model workflow that trains on 5–100 reference images, supports custom LoRA models and embeds brand/style guidance. It also exposes visual multi-step workflows, batch generation, reusable templates, API and MCP integration. The page lists concrete game-oriented workflows such as splitting a character/object/scene into isolated components, pose transfer and character variation, 2D animation rigging sheets, 3D auto-rigging and concept-to-game-ready 3D. The lesson for MotionLoom is to treat an AI tool as an orchestrated graph of reusable steps and agents, not only a single model call. Any claims about Scenario's internal model quality or production readiness still require artifact-level validation.
+
+The previously discovered Adobe Firefly Video Model blog URL returned HTTP 404 when opened, so it is excluded as evidence for this report. Adobe Firefly remains a candidate source for a later pass using a currently valid official product or help page; no unsupported claim is made from the stale search snippet.
+
+Cascadeur's official AI-tools documentation is unusually explicit about the division of labor. It lists AutoPosing, Inbetweening, AutoInterpolation and Video Mocap as ML-based tools, while separating AutoPhysics, Ragdoll, Animation Unbaking and Fulcrum Motion Cleaning as non-ML tools. AutoPosing predicts a pose from activated manipulators and their locations; Inbetweening predicts motion between keyed poses using pose, timing, keyframe count and style; AutoInterpolation predicts interpolation/kinematics types; Video Mocap extracts actor poses and applies them to a rigged character. Cascadeur also states that its tools assist rather than replace the animator, and that users' animations are not collected for training. This is a strong model for MotionLoom's human-governed boundary: AI proposes or fills motion, deterministic tools clean/measure it, and the user remains the authority for acceptance.
+
+The current Adobe Firefly Help URL was found through official search results but returned no extractable page content in this browser session. It is therefore not treated as fully verified evidence here. The candidate workflow is camera-motion transfer from a reference video with a start frame, but this requires a future successful page extraction before being used for a strong claim.
+
+Kinetix's current official homepage describes video-to-animation models for 3D character animation and points to integration into Unity Muse, an in-game Emote Creator for OVERDARE, and AI-assisted animation in Adobe Mixamo. This is relevant because the output is positioned as reusable in-game 3D animation, not merely a video render, and because moderation is mentioned for the player-generated emote workflow. The official publication URL suggested by the page returned 404, so no additional technical claim is taken from it.
+
+## Cross-tool pipeline synthesis
+
+Across the verified sources, the strongest tools do not rely on one prompt-to-final-output step. They expose a sequence of controls and artifacts:
+
+| Pipeline layer | Patterns observed | MotionLoom implication |
+|---|---|---|
+| Identity/style | Reference images, custom style models, init images, palettes, persisted characters/objects | Keep identity manifest, reference hashes, palette/camera/scale and derivation chain as first-class inputs. |
+| Motion source | Text action description, skeleton/pose controls, keyed poses, video performance or camera-motion reference | Bind the source type and source hash to the motion spec; do not treat generated pixels as the only source of truth. |
+| Temporal construction | Explicit frame counts, start/end frames, inbetweening, interpolation, multi-keyframes, animation-to-animation editing | Expand action-set with source keyframes, timing, loop seam and editable intermediate evidence. |
+| Spatial/rig mapping | Skeleton estimation, retargeting, 2D rig sheets, 3D auto-rigging, camera/direction/projection controls | Add rig compatibility, socket map, anchor/pivot and coordinate-system metadata before runtime rendering. |
+| Cleanup/measurement | Studio cleanup, looping, physics tools, inpainting, frame editing, palette/geometry limits | Separate deterministic cleanup and measurement from model generation; fail closed on contamination/drift. |
+| Packaging/runtime | Sprite sheets, FBX/BVH, game-engine integration, API/MCP, reusable templates and persisted states | Make export contract, runtime adapter and Dev Lab evidence mandatory for claims of readiness. |
+| Governance | Licensed training data disclosures, moderation, style ownership, human review and approval boundaries | Keep provenance and user approval separate; record source/license/model details without self-asserted authority. |
+
+This synthesis suggests that MotionLoom's differentiator should not be another generator. It should be the **artifact compiler and review governor between generators and real runtimes**: accept outputs from multiple tools, normalize their source/identity/motion metadata, measure the artifacts, render them in the target runtime, and return a user-facing evidence bundle before any PR action.