game-asset-mcp

Un servidor MCP que permite a un agente de IA producir activos 3D listos para el juego de principio a fin — imagen de referencia, malla, texturas PBR, procedencia — y retexturizar mallas que ya posees.

La mayoría de las herramientas de generación de activos se detienen en "escribe un prompt, obtén una malla". Esa es la mitad fácil. La mitad que realmente bloquea un proyecto es la malla que ya tienes: el kitbash que modelaste la semana pasada, el prop de marketplace cuyos materiales no coinciden con tu dirección de arte, el greybox que necesita verse como acero corroído para el viernes. texture_existing_asset toma una malla que tú proporcionas y le da nuevos materiales PBR sin regenerar la geometría que ya aprobaste.

Todo queda registrado. Cada trabajo conserva el prompt, la semilla, la versión del modelo del proveedor, el id de tarea del proveedor y un SHA-256 para cada byte descargado — así que dentro de seis meses aún podrás responder "¿qué produjo este archivo?".

El servidor es agnóstico respecto al proveedor por construcción. Hoy impulsa Tripo para 3D y Leonardo.Ai para imágenes de referencia y efectos de sonido, detrás de tres interfaces pequeñas (ImageProvider, Model3DProvider, AudioProvider). Añadir un proveedor no cambia la superficie de herramientas. Consulta docs/architecture.md para saber por qué está construido de esta manera.

Requisitos

• Node.js >= 18.17 — el servidor usa fetch, FormData, Blob y AbortController globales.

• Sin módulos nativos, sin cadena de herramientas de compilación, sin base de datos. Funciona en cualquier lugar donde Node funcione.

• Opcional: una instalación local de Blender 4.x+ habilita la mitad de reparación de normalize_mesh y batch_prepare_meshes. Todas las demás herramientas funcionan sin él; la herramienta se niega con instrucciones cuando no está presente. En macOS Blender no está en PATH, así que establece BLENDER_PATH o confía en el valor predeterminado incluido /Applications/Blender.app.

• Al menos una clave de API de proveedor (ver Configuración). Una es suficiente — se validan de forma perezosa.

Related MCP server: Context3D MCP Server

Instalación

Instala directamente desde GitHub. Ambas formas compilan el TypeScript durante la instalación, así que obtienes un binario game-asset-mcp ejecutable de cualquier manera.

# run it without installing anything permanently
npx github:theisegoria/game-asset-mcp

# or add it to a project
npm install github:theisegoria/game-asset-mcp

# pin a specific version — recommended for anything you depend on
npm install github:theisegoria/game-asset-mcp#v0.3.8

Fija la versión. Sin un sufijo #vX.Y.Z, ambas formas resuelven a lo que sea main en ese momento, lo cual no es una dependencia estable. Cada versión está etiquetada, así que #v0.3.8 te da exactamente ese árbol. Las versiones se listan en github.com/theisegoria/game-asset-mcp/releases, cada una con los defectos que esa versión corrigió.

⛔ No fijes v0.3.0, v0.3.1 o v0.3.2. Una revisión posterior encontró rutas en vivo en esas versiones que destruyen la malla que les pasas y reportan éxito. Están etiquetadas solo para que el historial esté completo. Sus páginas de versión también lo dicen.

O trabaja desde un clon, que es lo que quieres si pretendes cambiar algo:

git clone https://github.com/theisegoria/game-asset-mcp.git
cd game-asset-mcp
npm install
npm run build     # emits dist/
node dist/server.js

No está en npm. No existe npm install @theisegoria/game-asset-mcp — el paquete se distribuye solo desde GitHub. Cualquier cosa que diga lo contrario está desactualizada.

El servidor habla MCP sobre stdio. Iniciado directamente en una terminal, simplemente se quedará esperando a que un cliente le hable — eso es un comportamiento correcto, no un cuelgue. Los registros van a stderr; stdout pertenece al protocolo.

Configuración

Establece estas variables en el bloque env de tu cliente MCP — ver los fragmentos a continuación. No hay carga de .env: el servidor lee process.env y nada más, así que un archivo .env en disco no hace nada a menos que tu shell o cliente lo exporte primero.

⚠️ Los créditos de API de Tripo se facturan por separado de una suscripción a Tripo Studio

Esto atrapa a casi todos. Una suscripción web a Tripo Studio no financia llamadas a la API. Son dos productos diferentes con dos saldos diferentes. Si has estado generando modelos felizmente en la aplicación web de Studio y tu primera llamada a create_3d_asset regresa rechazada por créditos insuficientes, no has configurado mal nada — necesitas créditos de API en la plataforma de desarrolladores. Cómpralos en platform.tripo3d.ai, no en la aplicación de Studio.

Limitando lo que se puede gastar

Establece ASSET_SPEND_LIMIT_CENTS y cada herramienta que consume créditos lo verifica antes de contactar al proveedor en absoluto — incluso antes de que se suba una malla o imagen de referencia — negándose con el saldo restante nombrado en lugar de gastar de más. El límite está en centavos de dólar estadounidense porque los dos proveedores facturan en unidades diferentes — Tripo en créditos de $0.01, Leonardo en USD — y un límite que los mezcle no significaría nada.

Donde un proveedor publica un precio por llamada, lo usamos. Donde no lo hace, el guardián usa un marcador de posición deliberadamente pesimista y get_spend_report dice qué cifras son cuáles. Es un guardián, no una factura: los cargos reales deberían llegar a o por debajo de la estimación, nunca por encima.

Un proveedor es suficiente

Las credenciales se validan de forma perezosa, en el momento en que una herramienta las necesita, nunca al inicio. Si solo estableces TRIPO_API_KEY, el servidor arranca bien y todas las herramientas 3D funcionan; las herramientas de imagen devuelven un error claro CONFIG_MISSING nombrando la variable que te falta. Lo contrario también se cumple. Nunca te ves obligado a tener una cuenta que no quieres solo para usar la mitad del pipeline que sí quieres.

Configuración del cliente MCP

Claude Code / Claude Desktop

Añade a tu configuración de MCP (claude_desktop_config.json, o .mcp.json en un proyecto para Claude Code):

{
  "mcpServers": {
    "game-asset": {
      "command": "node",
      "args": ["/absolute/path/to/game-asset-mcp/dist/server.js"],
      "env": {
        "TRIPO_API_KEY": "tsk_...",
        "LEONARDO_API_KEY": "...",
        "ASSET_OUTPUT_DIR": "/absolute/path/to/your/project/assets/generated",
        "ASSET_LOG_LEVEL": "info"
      }
    }
  }
}

Usa una ruta absoluta para args y para ASSET_OUTPUT_DIR. El directorio de trabajo de un cliente MCP no es el que crees, y un directorio de salida relativo dispersará los activos en algún lugar sorprendente.

Cualquier otro cliente MCP

El mismo servidor, descrito genéricamente — un proceso hijo stdio:

{
  "name": "game-asset",
  "transport": "stdio",
  "command": "npx",
  "args": ["-y", "github:theisegoria/game-asset-mcp"],
  "env": {
    "TRIPO_API_KEY": "tsk_...",
    "LEONARDO_API_KEY": "...",
    "ASSET_OUTPUT_DIR": "/absolute/path/to/assets/generated"
  }
}

Herramientas disponibles

Solo nueve herramientas pueden costarte dinero, y cada una lo indica en su descripción antes de ser llamada.

La mitad local gratuita (sin claves API, sin red)

Once de las veinte herramientas nunca gastan un crédito, y solo dos de esas once usan la red en absoluto: get_asset_job consulta y download_asset descarga; ambas son gratuitas pero son llamadas de red. Las otras nueve funcionan sin conexión. Las cinco siguientes son el pipeline de mallas, y si ya tienes mallas, son todo el producto.

El bucle habitual es validar → normalizar → validar de nuevo, de modo que la reparación queda demostrada en lugar de asumida:

validate_game_asset  modelPath=/art/crate.glb
   → fails: uvs_present   ("nothing can texture this")
normalize_mesh       modelPath=/art/crate.glb  outputDir=/art/out
   → objectsUnwrapped=2, triangles 3183 → 1750
validate_game_asset  modelPath=/art/out/crate_normalized.glb
   → passes

batch_prepare_meshes ejecuta ese bucle sobre una lista e informa de cada elemento por separado. Las mallas que ya pasan se dejan intactas en lugar de reescribirse, un archivo defectuoso nunca detiene la ejecución, y dos fuentes que comparten un nombre base obtienen salidas distintas en lugar de sobrescribirse entre sí.

La falta de UV es el defecto que vale la pena conocer. Una malla sin coordenadas UV no puede ser texturizada por nada: ni esta herramienta, ni un proveedor, ni tú a mano. Los generadores y los activos de marketplace suelen venir sin ellas. validate_game_asset lo menciona primero por esa razón.

La normalización necesita Blender (4.x+). Sin él, las herramientas aún validan e informan; simplemente no pueden reparar. En macOS, Blender no está en PATH, así que o establece BLENDER_PATH o confía en el valor predeterminado incluido /Applications/Blender.app.

Flujo de trabajo de ejemplo

Pipeline completo: de la idea al activo inspeccionado

1. generate_asset_reference   → spends image credits, returns assetJobId + N candidates
2. (inspect the images)       → look at the returned reference images and choose one
3. select_reference           → free; records which candidate wins
4. create_3d_asset            → spends 3D credits, returns a task to poll
5. get_asset_job              → free; poll until status is "ready" (or "failed")
6. download_asset             → free; pulls model + textures + previews into the workspace
7. inspect_asset              → free; confirms what actually landed on disk

El paso 2 no es decoración. Elegir la referencia antes de gastar créditos 3D es toda la razón por la que el pipeline se divide aquí: una mala referencia produce una malla derretida, y solo lo descubres después de pagar por la reconstrucción.

Retexturizado: más corto, más barato y el flujo que la mayoría de las herramientas no tienen

Ya tienes la malla. No hay nada que referenciar, nada que seleccionar, nada que reconstruir:

1. texture_existing_asset     → spends texturing credits on a mesh you supply
2. get_asset_job              → free; poll until ready
3. download_asset             → free
4. inspect_asset              → free

Una llamada de pago en lugar de dos, y la geometría que ya aprobaste vuelve sin cambios.

Costos y efectos secundarios

Llamadas que gastan créditos del proveedor: generate_asset_reference, generate_reference_variations, create_3d_asset, texture_existing_asset, generate_sound_effect, rig_asset, animate_asset, retopologize_asset, y el paso de generación de imágenes dentro de create_game_prop. Nada más en este servidor puede cobrarse.

Llamadas gratuitas: select_reference, get_asset_job, download_asset, inspect_asset, list_asset_jobs, preview_asset_prompt, extract_pbr_trio, normalize_mesh, validate_game_asset, batch_prepare_meshes, get_spend_report. Consulta, inspecciona, divide y descarga tantas veces como quieras.

Un POST que consume créditos nunca se reintenta automáticamente. Esta es una regla deliberada y estructural, y vive en la capa HTTP, no en cada punto de llamada. Cuando una solicitud que crea una tarea de generación falla —timeout, socket reset, 502— el cliente no puede saber si el proveedor la aceptó antes de que se rompiera la conexión. Reintentar podría ser gratis; también podría cobrarte el doble por una malla que nunca recibes. Así que no reintenta, el error vuelve directamente, y la decisión de intentarlo de nuevo es tuya. Las lecturas idempotentes —sondeos de estado, descargas de archivos— se reintentan libremente con backoff, porque repetirlas no cuesta nada.

Otros efectos secundarios que vale la pena conocer:

• Los archivos se escriben en disco. Los activos descargados aterrizan en ASSET_OUTPUT_DIR, y una ruta de descarga que escape de la raíz del workspace es rechazada. Tres herramientas son diferentes y deliberadamente: extract_pbr_trio, normalize_mesh y batch_prepare_meshes escriben donde tú les digas, incluso fuera del workspace, porque operan sobre mallas que ya posees y esas no viven en un directorio de generación de activos. Dales un destino que realmente querías.

• download_asset y generate_sound_effect aceptan un destination que anula ASSET_OUTPUT_DIR para esa única llamada. Sigue estando contenido: una ruta que escape de la raíz dada es rechazada.

• ASSET_OUTPUT_DIR debe ser absoluto. Un valor relativo se resuelve contra el directorio de trabajo del servidor, que tu cliente MCP elige —varios se lanzan desde /. El servidor se niega a arrancar con un mensaje que nombra la ruta resuelta y el directorio de trabajo del que proviene. Ese diagnóstico cubre los ocho errnos que esto puede producir de forma realista —ENOENT, EACCES, EPERM, EROFS, ENOTDIR, ELOOP, ENAMETOOLONG y ENOSPC, incluido ASSET_OUTPUT_DIR apuntando a un archivo en lugar de un directorio. Cualquier otra cosa aún se propaga en bruto.

• Nada se sobrescribe en silencio. Un nombre de salida derivado recibe un sufijo numérico (crate, crate_2, …) en lugar de destruir un resultado que quizás ya hayas revisado, y el nombre se reclama mediante creación exclusiva para que dos elementos en un mismo lote no puedan competir por él. Un outputPath explícito es rechazado de plano si ya hay un archivo ahí, a menos que pases overwrite: true —y es rechazado incondicionalmente, sin opción de exclusión, si se resuelve sobre la malla de entrada. Esa resolución tiene en cuenta symlinks, hardlinks, volúmenes que no distinguen mayúsculas y el hábito del exportador de reescribir la extensión, porque cada uno de esos ha destruido una malla fuente aquí.

• Las descargas están limitadas a ASSET_MAX_DOWNLOAD_BYTES y el límite se aplica durante el streaming, no desde la cabecera Content-Length —un servidor que mienta sobre el tamaño no puede agotar tu memoria.

• Solo HTTPS. Las URLs que no son HTTPS son rechazadas de plano, incluidas las que llegan dentro de la respuesta de un proveedor.

• Las claves API se redactan de los logs de forma centralizada, así que ningún punto de llamada de log individual puede filtrar una.

Diseño del workspace

Cada activo recibe un directorio autocontenido. Ábrelo en un explorador de archivos seis meses después y sigue explicándose por sí mismo:

assets/generated/
├── .jobs/                          job records, one JSON file per job
│   └── asset_<uuid>.json
└── <asset_name>/
    ├── asset.json                  complete provenance: spec, prompt, seed,
    │                               model version, provider ids, file hashes
    ├── source/                     the reference image(s) the mesh was built from
    ├── model/                      the mesh (GLB by default)
    ├── textures/                   extracted PBR maps
    ├── previews/                   provider-rendered turnarounds

<asset_name> es el nombre de tu spec, saneado: en minúsculas, los no alfanuméricos colapsados a guiones bajos. El directorio .jobs es un dot-directory a propósito —navegar por tu workspace de activos debería mostrar activos, no contabilidad.

Solución de problemas

Cada error lleva un campo error legible por máquina que nombra la clase, más un indicador retryable, para que un agente pueda decidir qué hacer a continuación sin analizar prosa. Los nombres siguientes son los valores de ese campo error.

El servidor arranca y sale inmediatamente —el cliente solo dice "connection closed". Tres causas conocidas, y el servidor ahora nombra las dos primeras por sí mismo en lugar de morir en silencio.

• Un ASSET_OUTPUT_DIR relativo. Se resuelve contra el directorio de trabajo del servidor, que tu cliente MCP elige —varios se lanzan desde /, donde assets/generated se convierte en /assets y no se puede crear. Usa una ruta absoluta. El rechazo nombra la ruta resuelta y el directorio de trabajo del que proviene.

• Un workspace al que el proceso no puede escribir. El mismo rechazo, distinto errno.

• Una compilación obsoleta. Si dist/ es anterior a un cambio en el punto de entrada, recompila. npm run verify compila y luego completa un handshake MCP real, que es la forma más rápida de distinguir un servidor roto de una configuración de cliente rota.

normalize_mesh o batch_prepare_meshes se niegan con "Blender not found". No hay un Blender local en PATH. En macOS el bundle de la aplicación no está en PATH incluso cuando Blender está instalado —establece BLENDER_PATH al ejecutable dentro del bundle. batch_prepare_meshes degrada en lugar de fallar: aún valida cada malla e informa de lo que necesitaría reparación.

CONFIG_MISSING —falta una credencial. La herramienta que llamaste necesita un proveedor que no has configurado. El mensaje nombra la variable de entorno exacta. Establécela en el bloque env de tu cliente MCP y reinicia el cliente. Un archivo .env nunca se lee: no hay dependencia de dotenv, así que la variable debe ser exportada por lo que sea que lance el servidor.

PROVIDER_HTTP con estado 401/403 —clave API inválida. La clave es incorrecta, está revocada, o es del proveedor equivocado. Dos trampas específicas: las claves de Leonardo necesitan acceso a API habilitado en la cuenta (un inicio de sesión web por sí solo no lo concede), y una clave de Tripo sin saldo de crédito de API puede fallar en la primera llamada de pago aunque la clave en sí sea válida. Consulta la advertencia de créditos anterior.

RATE_LIMITED —HTTP 429. Marcado como reintentable. Los sondeos hacen backoff y reintentan automáticamente (400 ms, 800 ms, 1600 ms, con tope en 8 s). Las descargas no reintentan —download_asset transmite en un solo intento, así que vuelve a emitirlo tú mismo; como las URLs del proveedor expiran, vuelve a sondear con get_asset_job primero en lugar de reintentar una URL obsoleta. Las solicitudes de generación tampoco reintentan, deliberadamente, porque cuestan dinero. Un 429 durante una descarga aparece como PROVIDER_HTTP con estado 429, no como RATE_LIMITED.

PROVIDER_TASK_FAILED —la tarea falló en el lado del proveedor. La llamada HTTP tuvo éxito y la generación no. El mensaje propio del proveedor se conserva en los detalles del error. Un rechazo de moderación también aterriza aquí: reescribe el prompt en lugar de reintentarlo sin cambios. Ten en cuenta que una respuesta de Tripo puede llevar HTTP 200 con un code de envoltura distinto de cero; eso es un fallo, y este servidor lo trata como tal en lugar de informar de un éxito fantasma.

La descarga falla con PROVIDER_HTTP 403/404 —la URL expiró. Esta es la sorpresa más común con diferencia. Las URLs de modelo y vista previa del proveedor son de corta duración. Están firmadas, expiran, y una URL que funcionó hace veinte minutos ahora está muerta. La solución no es reintentar la misma URL —llama a get_asset_job de nuevo para volver a sondear al proveedor y obtener URLs frescas, luego download_asset inmediatamente. Como hábito: descarga en cuanto un trabajo informe ready, no al final de una sesión larga.

INVALID_INPUT —formato de imagen no soportado. Las imágenes de referencia deberían ser formatos raster estándar seguros para web (PNG, JPEG, WebP). HDR, EXR, PSD con capas, SVG y TIFF multipágina no son entradas reconstruibles. Para texture_existing_asset, las mallas deben ser GLB, GLTF, FBX, OBJ o STL. Convierte primero; el proveedor no lo hará por ti.

PROVIDER_MALFORMED_RESPONSE —el proveedor devolvió algo inesperado. Cuerpo no JSON, una envoltura vacía, un éxito sin datos, o una subida que no devolvió token de archivo. Normalmente significa un incidente del lado del proveedor o una deriva de versión de API. Establece ASSET_LOG_LEVEL=debug para ver la forma de la solicitud (las claves están redactadas), y consulta la página de estado del proveedor antes de asumir que el error es local.

DOWNLOAD_TOO_LARGE. El archivo superó ASSET_MAX_DOWNLOAD_BYTES. Un GLB PBR de alta calidad puede ser grande; sube el límite si realmente quieres el archivo.

PATH_ESCAPE. Un nombre de archivo suministrado por el proveedor intentó resolverse fuera de tu workspace. La escritura fue rechazada. Esto no debería ocurrir en operación normal —por favor, abre un issue si ocurre.

Estado

Esto es software temprano, y las partes con más probabilidad de derivar están marcadas como tales en lugar de asumirse en silencio.

Las rutas de endpoint v3 de Tripo están fijadas en exactamente un módulo (src/providers/model3d/tripo.ts) y documentadas en un comentario al principio del mismo. La documentación pública de Tripo describe la superficie v3 de dos maneras diferentes —un endpoint de tarea genérico y rutas por operación— y ambas aparecen en la documentación actual. Este cliente implementa la forma de tarea, que coincide con el comportamiento observable de que cada generación devuelve un task_id para sondear, y expone TRIPO_BASE_URL para que puedas redirigir sin editar código. Si están equivocadas, verás un 404 que se ve exactamente como una clave API mala, así que comprueba la ruta antes que la clave.

Nunca se ha hecho ninguna llamada a una API de proveedor en vivo. Esta es la advertencia más importante aquí, así que se declara claramente en lugar de enterrarse. Cada una de las 394 pruebas se ejecuta contra mocks o el sistema de archivos local. Cubren la construcción de prompts, el mapeo de estados, la seguridad de rutas, el almacén de trabajos, las reglas de reintento y redirección de la capa HTTP, y la inspección de glTF contra archivos reales —pero una suite en verde no dice nada sobre si Leonardo y Tripo se comportan como este cliente asume.

Concretamente, estos siguen sin verificar:

• Las rutas de endpoint v3 de Tripo descritas arriba.

• Si texture_model acepta una malla subida (file_token) o solo una malla producida por una tarea previa de Tripo (original_model_task_id). Esto decide si puedes retexturizar un modelo que ya posees, que es la función para la que existe este servidor. Resolverlo cuesta una llamada de textura HD.

• La generación de efectos de sonido no está verificada. Leonardo documenta el contrato de solicitud de Sound Effects v2 (model, prompt, duration 1-22s, prompt_influence, loop, quantity) pero no su forma de respuesta ni cómo se recupera el audio terminado. El cliente lee el id de generación y las URLs de audio de varias formas plausibles y lanza con los NOMBRES de las claves de nivel superior de la respuesta adjuntos (no el cuerpo, que podría ser grande o llevar una URL firmada) cuando ninguna coincide, en lugar de informar de un éxito vacío. Espera que la primera llamada real necesite un arreglo, y por favor abre un issue con la forma del payload que viste.

• Los ids de modelo de Leonardo en src/providers/image/leonardo.ts, que se transcribieron de documentación publicada. Compruébalos contra GET /platformModels; un id obsoleto falla como un HTTP 400 que se lee como un cuerpo de solicitud malformado. Tanto LEONARDO_MODEL_ID como un modelId por llamada existen como vías de escape.

Si eres la primera persona en ejecutar esto con claves reales, espera tener que arreglar una ruta de endpoint, y por favor abre un issue con lo que encontraste.

Lo que sí está verificado: npm run verify compila el servidor, lo arranca sobre stdio con un cliente MCP real, completa el handshake y afirma que las veinte herramientas se registran. Eso es un round-trip de protocolo, no una cadena de versión —un servidor que no logra registrar sus herramientas aún arranca perfectamente feliz.

Partes del pipeline local —inspect_asset, extract_pbr_trio, normalize_mesh, validate_game_asset— se comprueban además contra activos de juego reales enviados, en lugar de fixtures, porque un fixture sintético y el parser que lo lee pueden compartir el mismo error y ambos verse en verde. Ha ocurrido aquí: una constante mágica de glTF incorrecta sobrevivió a una suite sintética completa y solo la atrapó un archivo real. La malla sin UV que usan está commiteada aquí en lugar de leerse de un checkout hermano. Solía leerse en vivo del repo del juego, y cuando esa malla fue reparada estas pruebas se pusieron en rojo por un cambio que era completamente correcto —una aserción que fijaba un hecho sobre un archivo que este proyecto no controla. Una prueba no puede depender de contenido que no posee.

Una prueba lanza el servidor compilado a través de un bin enlazado simbólicamente — lo que node_modules/.bin realmente contiene — y le habla mediante MCP, porque ahí es donde falló la protección del punto de entrada: el servidor salía al instante en cada instalación mientras pasaba todas las demás pruebas. Enlaza simbólicamente en lugar de instalar, por lo que no puede detectar una regresión de empaquetado en files o prepare; una instalación real de npm install desde GitHub sigue siendo una comprobación manual.

Por qué el número de pruebas no es el punto

En 0.3.4, cada una de las cinco correcciones principales de la versión anterior se revirtió una a la vez y se volvió a ejecutar la suite. Las cinco sobrevivieron: cada mutante estaba completamente en verde. Las correcciones eran reales; nada en la suite las estaba reteniendo. La causa era una única suposición compartida: cada Blender simulado salía con 0 e imprimía exactamente un recibo, por lo que ninguna de las mejoras del protocolo de subprocesos era observable por ninguna prueba.

Eso vale la pena declararlo en un README porque es la lectura honesta de cualquier número de pruebas, incluido este. Una suite certifica las suposiciones del autor, y un defecto que vive dentro de una suposición es invisible para todas las pruebas escritas bajo ella. Lo que cambió es la disciplina, no el número: las correcciones ahora están fijadas por pruebas que se ejecutaron contra el código revertido y se observó que fallaban, y los simulacros compartidos se tratan como sospechosos en lugar de infraestructura.

La misma comprobación atrapó una mala prueba dos veces en una sola sesión. Dos fixtures sucesivos escritos para probar una corrección de umbral de soldadura informaron un recuento de triángulos idéntico con el código correcto y con el código roto, y cualquiera de los dos se habría enviado como evidencia. Un fixture no es prueba hasta que se haya ejecutado tanto con el código corregido como con el roto y se hayan impreso los dos números.

Contribuciones

Los issues y las pull requests son bienvenidos. Si añades un proveedor, implementa ImageProvider o Model3DProvider y no cambies nada más: si un nuevo proveedor obliga a cambiar la superficie de la herramienta, la abstracción está mal y ese es el error que vale la pena discutir primero.

Licencia

MIT © 2026 Ben Haire. Ver LICENSE.