git:20260909.39ef018 to git:20260910.85302b4

---

name: character-pipeline-2d

description: |

Skill de pipeline 2D de personagem e orquestracao geral do pipeline character-to-runtime. Cobre as

---

# Character Pipeline 2D — Derivacao, Geracao 2D Nativa e Orquestracao

Pipeline para produzir sprites, animacoes e assets 2D de personagem de forma automatizavel em CLI —

seja derivando de um personagem 3D ja rigado, seja gerando 2D nativamente via IA. Cobre tambem a

camada de orquestracao: o contrato `MotionPlan.json`, o CLI `assetctl`, e a arquitetura de testes/CI

que trata o pipeline como um compilador.

## Governanca Global

Esta skill segue `GLOBAL.md`, `policies/execution.md`, `policies/source-driven.md` e

`policies/token-efficiency.md`.

Conteudo denso vive em `references/` — carregar so o arquivo relevante a task, nao os quatro de cara:

| Assunto | Arquivo |

|---|---|

| CLI `assetctl` completo (todos os subcomandos, exemplo end-to-end, isolamento de ambiente Python) | `references/assetctl-cli-reference.md` |

| Tabela de licenciamento completa (14 ferramentas) + classes de hardware com VRAM real | `references/licensing-and-hardware.md` |

| Os 5 grupos de teste/CI, exemplo de GitHub Actions, build graph content-addressed | `references/testing-and-ci.md` |

Esta skill **assume que o pipeline 3D ate GLB ja existe**. Para AccuRIG->Blender->retargeting->bake em

profundidade (matematica de quaternion, bpy, normalizacao de rig 3D), ver

`skills/68-character-animation-3d/SKILL.md` — aquela skill entrega `character.glb`+`animation.glb`

certificados; esta parte deles (ou de arte 2D nativa) para derivar sprites, atlases, rigs 2D, e prover

o `MotionPlan.json` que orquestra ambas.

## Quando Usar

- decidir qual das cinco estrategias de producao 2D usar para um personagem/projeto especifico

- projetar ou validar um `MotionPlan.json` — a intencao/timing/fases/contatos/eventos de uma acao,

antes de qualquer resolucao em transform de bone

- gerar assets 2D nativos via IA (Qwen-Image-Layered, Qwen-Image-Edit) a partir de um personagem

master, incluindo decomposicao em camadas e correcao de occlusion

- extrair movimento de video de referencia (DWPose/MMPose) ou usar Wan como motion reference/previs

sem cair no anti-padrao de usar video gerado como frame final

- montar ou revisar workflows ComfyUI headless com provenance e versionamento correto

- escolher ferramenta de rig 2D esqueletal (Blender Grease Pencil, Spine, LoongBones) por requisito

de automacao/licenca

- implementar rasterizacao deterministica (render ortografico -> spritesheet) ou packing de atlas

- separar hitbox/hurtbox de pixel alpha, ou integrar assets 2D em Godot/Phaser

- desenhar o CLI `assetctl` ou a arquitetura de testes/CI do pipeline de asset de personagem

- checar licenciamento de qualquer ferramenta citada nesta skill antes de redistribuir

## Quando Nao Usar

- matematica de retargeting 3D, normalizacao de rig no Blender via bpy, ou detalhe de export FBX do

AccuRIG — `skills/68-character-animation-3d/SKILL.md`

- geracao de imagem generica sem ser parte do pipeline de personagem (hero image, OG card, icone) —

`skills/17-image-generator/SKILL.md`

- decisao de arquitetura/balance de gameplay (nao visual) — `skills/66-game-architecture-design/SKILL.md`

- implementacao de codigo de engine em Unity/Unreal alem do que entra via GLB/atlas — `skills/67-game-engine-development/SKILL.md`

## Entradas Esperadas

- fonte do personagem: mesh 3D rigado e certificado (via skill 68) OU concept art/master 2D

- a acao/biblioteca de acoes a produzir, com intencao em linguagem natural (ex.: "ataque pesado de

espada de cima para baixo, antecipacao clara, avanco curto")

- estrategia de producao 2D desejada, ou pedido de recomendacao com base no caso de uso

- engine/runtime alvo (Godot, Phaser, outro) para saber qual formato de atlas/rig exportar

- classe de hardware disponivel, quando a task envolve geracao generativa pesada (Qwen/Wan/SAM)

## Saidas Esperadas

- `MotionPlan.json` validado (schema Pydantic) por acao, sem ambiguidade de fase/evento/contato

- assets 2D: `frame_*.png` deterministicos, `atlas.png`+`atlas.json`, ou projeto `.spine`/rig Grease

Pencil, conforme a estrategia

- JSON de hitbox/hurtbox por frame, separado de pixel

- manifest de provenance para qualquer output gerado por IA (workflow, model revision, seed, hashes)

- quando aplicavel: `assetctl` invocavel end-to-end e suite de teste dos 5 grupos cobrindo o asset

## Principio Central — Seis Elementos Independentes

O elemento mais importante da arquitetura **nao e nenhum modelo de IA especifico** — e a separacao

estrita entre `CHARACTER ≠ RIG ≠ MOTION ≠ MOTION PLAN ≠ GAMEPLAY ≠ VISUAL REPRESENTATION`. Com esses

seis elementos independentes, uma biblioteca de acoes (locomotion: idle/walk/run/sprint/jump; combat:

jab/cross/kick/overhead_slash/horizontal_slash/uppercut/dodge/parry; reactions: light_hit/heavy_hit/

knockback/knockdown/death) e criada **uma unica vez** e aplicada a multiplos personagens em multiplos

formatos (3D, spritesheet, ilustrado 2D, rig Spine).

O erro raiz a evitar: **nao ter multiplas representacoes concorrentes do movimento**. Deve existir

apenas um `CanonicalMotion` e um `MotionPlan` por acao — FBX certificado, GLB, animacao 2D, hitboxes e

spritesheet sao todos **derivados reprodutiveis** desses dados, nunca fontes de verdade paralelas que

podem divergir. Isso transforma IA de "gerador ocasional de imagem" em infraestrutura de producao de

asset reproduzivel, testavel e escalavel.

## AccuRIG como Fronteira de Certificacao do Rig

A documentacao publica atual do AccuRIG descreve o produto como aplicacao standalone guiada (import,

rigging, ajuste, export por interface) — **nao existe CLI/API headless publica e suportada**. Nao

fingir suporte a um comando `accurig --input foo.fbx --output foo_rigged.fbx` que nao existe. Por isso

o AccuRIG e tratado como uma **fronteira de certificacao**: mesh/personagem entra, sai um FBX rigado

certificado, e a partir dali o pipeline inteiro (Blender CLI -> Canonical Rig -> MotionPlan -> Motion

Resolver -> Retarget+Bake -> runtime) e 100% CLI/headless. Tres solucoes possiveis para o passo manual:

| Solucao | Automacao | Robustez | Recomendacao |

|---|---|---|---|

| Operador exporta FBX uma vez por corpo/topologia | ~95% | Muito alta | **Producao** |

| UI automation / RPA sobre o AccuRIG | ~100% | Baixa | Apenas laboratorio |

| Trocar AccuRIG por outro auto-rigger no lane unattended | 100% | Alta | Apenas se "zero humanos" for requisito rigido |

A primeira e a recomendacao: certificar o rig **uma vez** por corpo/topologia — animacoes posteriores

sao automaticas. Ingest do FBX no Blender (validacao de armature, bone_map) esta na skill 68; aqui o

que importa e que **o AccuRIG nunca entra no job de CI** — o CI comeca em `accurig/knight_01_accurig.fbx`

ja certificado, validado por hash (ver `references/testing-and-ci.md`).

## MotionPlan.json — LLM como Diretor, Nao Animador

**LLM = diretor, nao animador.** Um LLM que recebe "ataque pesado de espada de cima para baixo, com

antecipacao clara, avanco curto e janela ativa curta; recuperar lentamente; permitir cancel para dodge

apenas depois do impacto" deve devolver um `MotionPlan.json` estruturado com **semantica e

constraints** — nunca Euler angles ou rotacao de bone diretamente. Pedir angulos de quarenta bones a

uma LLM e um erro de arquitetura: um `MotionResolver` deterministico resolve os transforms a partir da

intencao declarada.

Tres camadas separadas, cada uma com autoridade diferente: **LLM = diretor** (produz `MotionPlan.json`

— intencao, timing, fases, contatos, root motion, eventos de VFX/hitbox, restricoes; nunca transform

final); **pose/mocap = movimento autoritativo** (DWPose/MMPose, video de referencia, ou clips

canonicos transformam a intencao em trajetorias reais de skeleton); **IA generativa de imagem/video =

aparencia e referencia**, nunca a fonte final dos frames de gameplay.

Campos do schema `MotionPlan`: `$schema`, `version`, `action_id`, `character_class`, `timebase`

(fps, frames), `intent` (category, style[], dominant_side), `phases` (anticipation/startup/active/

follow_through/recovery com start/end em frames), `motion_source` (type: reference_video, ref,

preferred_pose_backend), `pose_targets` (frame, name, constraints como `weapon_above_head`,

`weight_on_rear_foot`), `root_motion` (enabled, forward_m, vertical_m), `contacts` (effector foot_l/

foot_r, from/to frame, lock bool), `weapon` (bone, trajectory type/direction/arc_deg), `events` (frame,

type vfx/hitbox_on/hitbox_off/camera_shake/cancel_window, id/intensity/target), `render_2d` (views,

fps, hold_keyframes), `qa` (max_foot_slide_cm, require_ground_contact, require_no_self_intersection).

Schema completo comentado em `references/assetctl-cli-reference.md`.

**Validacao obrigatoria com Pydantic antes de qualquer execucao** — `Phase` valida `end >= start`,

`Timebase` limita `fps` (1-240) e `frames` (1-10000), `MotionPlan` usa `version: Literal["1.0"]`,

`action_id` com pattern `^[a-z0-9_]+$`, `character_class: Literal["humanoid"]`, e

`model_config = ConfigDict(extra="forbid")` para rejeitar qualquer campo fora do schema. Exemplo

completo em `references/assetctl-cli-reference.md`.

A LLM **nunca** deve produzir Python executavel diretamente — deve produzir dados declarativos sujeitos

a schema. Isso reduz erros E riscos de prompt injection (um `MotionPlan` malformado falha validacao

antes de tocar em qualquer subprocess; codigo executavel gerado por LLM nao tem essa barreira).

## Estrutura de Pastas e Contrato de Artefato

Estrutura por personagem: `source/` (concept + mesh + textures) -> `accurig/` (FBX certificado) ->

`config/` (`character.yaml` + `bone_map.json`) -> `motions/` (`motionplan.json` + references) ->

`build/` (`normalized.blend`, `animated.blend`, pose, frames) -> `dist/` (`3d/`, `2d/`, `manifest.json`).

`.blend` **nao e o formato do produto** — e artefato de compilacao intermediario. Preferir `.glb` a

`.fbx` para 3D final (GLB e container binario glTF; `.gltf` textual referencia buffers/imagens

externos — bom para debug, ruim para distribuicao). Contrato runtime-vs-build: apenas `character.glb`,

`animation.glb`, `rig.json`, `atlas.png`+`atlas.json` e o output nativo do rig 2D (`.spine`/`.atlas`)

vao para o runtime; `source.*`, `*_accurig.fbx`, `*.blend` e `frame_*.png` sao build/debug, nao

embarcam no jogo. `manifest.json` e recomendado em todo build. Tabela artefato-por-artefato completa

em `references/assetctl-cli-reference.md`.

O skeleton canonico usa **nomes semanticos** (`root -> hips -> spine_01 -> spine_02 -> chest ->

{neck -> head, clavicle_l -> upper_arm_l -> lower_arm_l -> hand_l, clavicle_r -> ...}`,

`upper_leg_l -> lower_leg_l -> foot_l -> toe_l`, espelhado a direita). O mapping Reallusion

(`hips -> CC_Base_Hip`, `spine_01 -> CC_Base_Waist`, etc.) fica em JSON separado. **Nunca** colocar

logica de gameplay nos nomes fisicos — o jogo conhece `hand_l`, nao `CC_Base_L_Hand`. Isso permite

trocar o AccuRIG por outro auto-rigger sem reescrever animacao, hitboxes ou VFX.

## As Cinco Estrategias de Producao 2D

| Estrategia | Recomendo para | Automatizacao | Consistencia |

|---|---|---:|---:|

| **3D -> render ortografico -> spritesheet** | muitos personagens, golpes, skins, fighting/RPG | Excelente | Excelente |

| **arte 2D -> layers -> rig skeletal 2D** | estilo ilustrado forte | Boa | Muito boa |

| video IA -> frames PNG | prototipos/concept | Facil | Fraca |

| frame-by-frame IA independente | concept/pixel art assistida | Media | Fraca sem controle |

| **hibrido rig + replacement frames** | personagem principal 2D | Muito boa | Excelente |

Se AccuRIG+Blender ja sao o centro do processo (via skill 68), 3D como fonte de movimento e 2D como

output e a arquitetura mais escalavel: o mesmo `heavy_slash_01` gera GLB animado, spritesheet lateral,

e serve de pose conditioning para o Qwen produzir versao ilustrada — **uma unica fonte de movimento,

multiplas representacoes derivadas**. O hibrido rig+replacement e o teto de qualidade para estilo

ilustrado forte sem perder consistencia: `3D -> animacao canonica -> render ortografico -> sprites

base -> Qwen style/edit -> keyframes de replacement`. A IA nao reinventa anatomia a cada frame — so

reestiliza keyframes que o rig ja posiciona corretamente.

## Geracao 2D Nativa via IA

A ferramenta mais relevante para geracao/edicao 2D nao e o SAM — e o **Qwen-Image-Layered**. Decompoe

uma imagem em quantidade variavel de camadas RGBA, com decomposicao recursiva das proprias camadas.

Apache 2.0, resolucao recomendada atual 640. Pipeline: `character_master.png -> Qwen-Image-Layered ->

coarse layers -> semantic classifier -> recursive decomposition -> SAM refinement -> canonical layers`

(ex.: `hair_back.png`, `torso.png`, `head.png`, `upper_arm_l.png`, `lower_arm_l.png`, `hand_l.png`

[espelhado para direita], pernas espelhadas, `weapon.png`, `hair_front.png`).

**SAM 3.1 e segunda passagem, nao gerador primario** — limpeza/refinamento de mascara, tracking,

isolamento de objeto. Requer Python 3.12+, PyTorch 2.7+, stack CUDA recente, ~848 milhoes de

parametros.

**Occlusion completion.** Se na imagem original um braco esta na frente do torso, os pixels do torso

**por baixo do braco nao existem** — separar so os pixels visiveis e rotacionar o braco produz um

buraco transparente. Solucao: `segmentation -> layer extraction -> expand bounding region ->

Qwen-Image-Edit inpaint hidden region -> clean alpha mask`. Qwen-Image-Edit-2511 (Apache 2.0) melhorou

consistencia de personagem, reducao de drift, multiplas imagens de input; uso via

`diffusers.QwenImageEditPlusPipeline`, `Qwen/Qwen-Image-Edit-2511`, bfloat16, lista

`[master, pose_guide]` + prompt de preservacao de identidade + seed fixo.

**Regra de ouro — nao gerar cada frame do zero.** Mau: prompt frame 01, frame 02... independentes

(drift garantido). Correto: `master + canonical pose + previous approved key pose -> Qwen edit -> nova

key pose`, e o rig **interpola** entre key poses aprovadas — a IA gera so as poses-chave, nunca os

frames intermediarios.

## Movimento a Partir de Video — DWPose, MMPose e Wan

Extracao: `ffmpeg -i video.mp4 -vf fps=30 frames/%06d.png`, depois `extract_pose.py --backend dwpose`

(2D) ou `--backend mmpose-3d` (3D com profundidade). DWPose (Apache 2.0, variantes tiny/small/medium/

large) e whole-body pose estimation essencialmente **2D** — excelente para sprites, mas inferir

animacao **3D** diretamente dele e causa comum de movimento ruim. MMPose (Apache 2.0) cobre pose 2D

**e** 3D — para retarget 3D onde profundidade importa, preferir seu predictor 3D ou fonte real

3D/mocap. Passo intermediario obrigatorio: `DWPose format -> CanonicalPoseSequence (fps,

coordinate_space, dimensions, frames com joints e position+confidence) -> game runtime`. **Nunca**

`DWPose format -> game runtime` direto.

**Wan como motion reference/previs — nunca fonte final.** Entra **antes** do `CanonicalPoseSequence`.

Wan2.2-Animate permite character animation/replacement; Wan-Animate-2 (Agosto 2026) recebe imagem de

referencia + driving video diretamente. Apache 2.0, Python 3.11/PyTorch 2.7/CUDA 12.6. Funcao correta:

`"quero este ataque" -> MotionPlan -> referencia OU Wan visual rehearsal -> pose extraction ->

CanonicalMotion -> retarget`. **ANTI-PADRAO EXPLICITO**: `Wan -> MP4 -> cortar em PNG -> ship

diretamente` — carrega inconsistencia generativa direto para o gameplay.

## ComfyUI como Servidor de Inferencia

ComfyUI encaixa como **servidor de inferencia**, nao dono da logica de negocio: REST+WebSocket,

`/prompt` valida e enfileira workflows headless (`python main.py --disable-auto-launch --listen

127.0.0.1 --port 8188`). Workflows versionados com nome semantico (`qwen_character_edit.v3.json` —

**nunca** `workflow_final_FINAL_7.json`). Cada output exige provenance JSON (`generator`, `model`

com revision pinned-commit-sha, `generation` com seed/steps, `inputs` com hashes) — schema completo em

`references/assetctl-cli-reference.md`.

## Rig 2D Esqueletal

| Ferramenta | Licenca | Automacao headless | Escolher quando |

|---|---|---|---|

| **Blender + Grease Pencil** (2D + deformacao com Armature) | GPL | Excelente (mais automatizavel, open-source) | open-source + 100% headless |

| **Spine** | Comercial propria | CLI oficial (`Spine -i x.spine -o dist -e export.json`); maioria headless, so export de imagem/video exige windowing | melhor authoring skeletal dedicado |

| **LoongBones** | MIT | Editor web interativo, sem CLI comparavel ao Spine | open-source + editor tradicional, aceitando gap de CI |

| So sprites raster | — | Total | Blender raster -> atlas, sem rig esqueletal |

Preservar os `.spine` originais — a versao de export deve casar com a dos runtimes consumidores.

LoongBones tem IK, mesh/weights, FFD, slots, atlas, import PSD, mas sem CLI headless confiavel.

## Rasterizacao Deterministica

Segredo para evitar "sprite shake": **nunca** recalcular a camera em cada frame (mau: `frame 0 -> fit

bounding box`, `frame 1 -> fit bounding box`... move implicitamente o personagem em relacao ao

sprite). Configurar **fixo**: camera ortografica, root anchor, canvas, ground line, pixel density.

Script bpy: resolucao fixa, PNG RGBA, `film_transparent=True`, itera `frame_start..frame_end` com

`scene.frame_set(frame)` + `render(write_still=True)`, salvando metadata (`fps`, `frames`, `origin`,

`events`) por animacao.

Atlas open-source via Pillow: packing em grelha **deterministico** (`pack_grid` ordena PNGs, compoe

sheet RGBA, gera JSON `x/y/w/h` compativel com TexturePacker) — nao e o mais eficiente, mas e

reprodutivel. TexturePacker e a opcao comercial madura para escala — **CI/automacao requer licenca

Docker/CI especifica; licencas desktop nao cobrem build/servidor**.

Separar sempre "frames visuais" de "dados de gameplay": sprite atlas = o que aparece | motionplan =

quando acontece | hitbox = onde acerta | hurtbox = onde recebe dano. **Nao** codificar hitbox no pixel

alpha — JSON proprio por frame (shape capsule/box, coordenadas a/b, radius), associado a action, para

poder refazer sprites em outro estilo sem alterar combate.

## Integracao Runtime

**Godot** (4.7.2) consome os tres mundos: 3D (`character.glb -> AnimationPlayer -> AnimationTree`), 2D

raster (`atlas.png -> SpriteFrames -> AnimatedSprite2D`), 2D skeletal (`Skeleton2D -> Bone2D ->

Polygon2D`). **Phaser** carrega spritesheets/atlases JSON (Array/Hash) via `this.load.atlas()` +

`this.anims.create({generateFrameNames})`, e Phaser 4 tem integracao Spine nativa (skeleton JSON/

`.skel` + `.atlas` + texturas).

## Licenciamento e Hardware

Cita ferramentas de terceiro com licencas variadas — **preservar sempre a tabela completa**, sem

esconder as restritivas (SAM License propria, Spine comercial, TexturePacker comercial, Hunyuan3D

Tencent restrita). Tabela completa (14 entradas) e classes de hardware com VRAM real em

`references/licensing-and-hardware.md` — carregar antes de decisao de redistribuicao ou de

dimensionamento de maquina.

## Testes, CI/CD e Build Graph

A pipeline deve ser testada como compilador — um asset que "parece razoavel" mas altera silenciosamente

skeleton/frame count/pivot e um **build quebrado**. Os 5 grupos de teste, exemplo de GitHub Actions, e

o build graph content-addressed (cache de Qwen/SAM/pose/retarget/render/atlas por hash de input) estao

em `references/testing-and-ci.md` — carregar ao montar CI ou ao decidir se um rebuild e necessario.

**Checkpoint:** teste de um dos 5 grupos falhando invalida o cache content-addressed daquele estágio (não só o output final) — recalcular a partir do estágio que falhou, nunca aceitar o asset com "só esse teste não passou" quando skeleton/frame count/pivot está entre os afetados.

## Regras Duras

| Nunca | Em vez disso |

|---|---|

| Pedir a LLM Euler angles/rotacao de bone diretamente | LLM produz `MotionPlan.json`; `MotionResolver` deterministico resolve o transform |

| Fingir que o AccuRIG tem CLI/API headless publica | Tratar como fronteira de certificacao — operador exporta FBX uma vez por corpo |

| Usar video gerado pelo Wan como frame final de gameplay | Wan e previs — sempre `pose extraction -> CanonicalMotion -> retarget` |

| Ir de `DWPose format` direto para o game runtime | Passar sempre por `CanonicalPoseSequence` intermediario |

| Gerar cada frame do zero com prompts independentes | `master + pose + previous key pose -> edit -> nova key pose`, rig interpola |

| Usar SAM como gerador primario de camadas | Qwen-Image-Layered decompoe; SAM so refina mascara na segunda passagem |

| Separar um braco do torso sem tratar occlusion | `expand bounding region -> Qwen-Image-Edit inpaint -> clean alpha mask` |

| Recalcular bounding box da camera a cada frame | Camera ortografica fixa, root anchor fixo, canvas fixo, ground line fixa |

| Codificar hitbox dentro do pixel alpha do sprite | JSON proprio de hitbox/hurtbox por frame, associado a action |

| Manter mais de um `CanonicalMotion`/`MotionPlan` por acao | Fonte unica; todo o resto e derivado reprodutivel |

| Instalar Qwen/SAM/Wan/Blender no mesmo virtualenv | Isolar por worker ou Docker services separados |

| Usar SHA-256 do PNG como golden test de visual regression | Validacao estrutural/perceptual + artefato de auditoria |

| Assumir que licenca pessoal/comercial do rig cobre o ecossistema (ex. CC Components) | Auditar assets adquiridos separadamente do programa que fez o rig |

## Handoff

### Recebe de

- Skill 68 (Character Animation 3D) — `character.glb`+`animation.glb` certificados e rig canonico

normalizado, para derivar 2D ou servir de fonte de pose

- Skill 66 (Game Architecture Design) — biblioteca de acoes (locomotion/combat/reactions) que vira

`MotionPlan.json` por acao

- Skill 09 (Orchestrator) — quando a task maior decide que producao/derivacao 2D e a proxima etapa

### Entrega para

- Skill 67 (Game Engine Development) — atlas/rig 2D prontos para integracao runtime via codigo

- Skill 68 (Character Animation 3D) — quando a derivacao 2D revela que o rig/retargeting 3D precisa de

ajuste (ex.: pose_target inatingivel na mesh)

- Skill 20 (Observability/SRE) — quando o build de asset roda em CI continuo e precisa de

alerta/rollback proprio

## Evidencia de Conclusao

- `MotionPlan.json` validado por schema Pydantic, sem campo fora do schema (`extra="forbid"`)

- assets 2D com manifest de provenance completo quando envolvem IA generativa

- hitbox/hurtbox em JSON separado, nunca inferido de pixel alpha

- para asset derivado de 3D: camera/canvas/anchor fixos documentados, sem "shake" entre frames

- teste cobrindo os grupos aplicaveis (schema sempre; skeleton/motion com rig; visual-regression com

render; round-trip com export para runtime)

## Fontes

Conteudo desta skill e pesquisa tecnica original do usuario (whitepaper proprio, nao material de

terceiro sujeito a licenca de conteudo) sobre pipeline completo de personagem, fornecido integralmente

para curadoria. Estrutura em `references/` segue o formato padrao deste kit; o conteudo tecnico

(schemas, comandos, tabelas, decisoes) foi preservado sem generalizacao.

O documento cita ferramentas de terceiro com licencas variadas — tabela completa (14 entradas, sem

omitir as restritivas: SAM License propria, Spine comercial, TexturePacker comercial, Hunyuan3D

Tencent restrita) em `references/licensing-and-hardware.md`, junto das classes de hardware.

Curadoria em 2026-08-27.