Diagnóstico con fuente
El caso separa síntoma, impacto, reproducción, responsabilidad del sistema y causa raíz.
← MARTINEZ AI STUDIOS 2.0
EVIDENCIA INTERNA VERIFICADA
Prueba antes que promesas.
Esta biblioteca conecta el posicionamiento de Studio 2.0 con trabajo real de producción. Cada caso publicado proviene de un incidente interno de CONTRABAND documentado con causa raíz, corrección, validación y evidencia pública segura.
Transparencia: son casos internos de Martinez AI Studios, no testimonios ni resultados de clientes. No se presentan como prueba de todas las ofertas de Studio 2.0.
01 / QUÉ DEMUESTRA EL MÉTODO
Corrección mínima
La solución se describe por el cambio necesario, no por volumen de código o herramientas usadas.
Protección contra regresión
La validación deja una forma concreta de comprobar que el mismo fallo no reaparece silenciosamente.
Lección reutilizable
Cada incidente termina en una regla transferible a futuros sistemas, agentes y flujos de producción.
02 / CASOS PUBLICADOS
5 incidentes. Evidencia real.
La colección reúne casos internos publicados y respaldados por evidencia. Cada uno enlaza al análisis completo en Academy.
Distancia de llegada a Keros: dos caminos, dos posiciones
Last Run enseñaba un warp real Keros ↔ Belu. El salto de vuelta no compartía la pose near-dock del teletransporte scripted.
LECCIÓN GENERALIZABLE
El id de sistema no es la pose. Dos entradas que comparten etiqueta siguen necesitando un contrato de colocación compartido. Mezclar espacio local y mundo se ve como un “bug de warp” para el jugador y como un vector de una línea para un asistente de IA. Posee una política de llegada por intención (vista vs near-dock) y testa metros, no solo flags.
EVIDENCIA (3)
LEER CASO COMPLETO →- Log de desarrollo de CONTRABAND, 19 ago 2026, v0.4.155–v0.4.157 (near-dock de Keros / segundo salto).
- last-run-map-warps.test.mjs (metros de muelle, dos caminos de llegada, reglas de cierre del mapa).
- Comentarios en last-run-map-lesson.js y lastRunSecondKerosArrivalUsesNearDock; samples de muelle confiables en galaxy-arrival.
Pointer lock frente a diálogo clicable
El vuelo quiere el ratón capturado. Los botones de elección 1/2 necesitan el ratón libre. Esos estados chocaron en Last Run.
LECCIÓN GENERALIZABLE
Los modos de captura son excluyentes con overlays clicables. Posee la transición: sal del lock, dile al jugador cómo, y no ates ESC a dos verbos. La UI por dispositivo (ocultar el aviso en mando) es corrección, no pulido.
EVIDENCIA (3)
LEER CASO COMPLETO →- Log de desarrollo de CONTRABAND, 19 ago 2026, v0.4.148–v0.4.153 (aviso ESC / recaptura).
- lastRunShouldShowReleaseMouseHint; pointer-lock-policy.js historia vs combate live.
- last-run-from-verge.test.mjs
Lifecycle de WebGL: dispose no es liberar
Astillero, holograma de lock, mapa 3D, hangar e inventario abrían cada uno un contexto GPU. El canvas de vuelo pagaba la cuenta.
LECCIÓN GENERALIZABLE
Los contextos GPU son un presupuesto compartido, no un campo privado de un componente. El lifecycle es pausar vs destruir. Una IA que “limpia” con dispose() en cada unmount estilo React puede tumbar la vista del juego. Cuenta renderers vivos; testa bucles de reopen, no un solo open.
EVIDENCIA (3)
LEER CASO COMPLETO →- Comentario de cabecera de webgl-preview-pool.js y API acquire/pause/destroy.
- Log de desarrollo de CONTRABAND, 19 ago 2026, v0.4.158; notas anteriores de canvas blanco / churn de astillero.
- webgl-preview-lifecycle.test.mjs
Progresión de Supervivencia: umbral, duplicados, dificultad
El desbloqueo de cascos, el pago por baja y diez perfiles de dificultad tenían que ser contratos independientes.
LECCIÓN GENERALIZABLE
Los campos de economía necesitan nombre por consumidor (tienda vs desbloqueo vs reparación). Un += compartido de créditos es cómo nacen las recompensas duplicadas. Dificultad, botín y progresión son tres perillas; acoplarlas en un prompt “balanceará” la equivocada.
EVIDENCIA (3)
LEER CASO COMPLETO →- Log de desarrollo de CONTRABAND, 20 ago 2026, v0.4.159.
- survival-progression-rewards.test.mjs
- ships.js survivalProgressionPrice vs price; survival-progression.js; combat.js isKaelaSurvivalKill.
Gates de release: QA, cloud, luego un build
Un App ID de Steam en la tienda no sustituye un gate local que pueda fallar.
LECCIÓN GENERALIZABLE
Publicar es una checklist que puede fallar, no un screenshot de la tienda. Codifica idioma, input y persistencia como celdas. Nunca pongas la identidad admin de Steamworks en textos educativos. Una IA que “solo sube el build” se salta los únicos tests que pillan Last Run y el orden de cloud.
EVIDENCIA (3)
LEER CASO COMPLETO →- Scripts de package.json qa:release y qa:release:logic (unit + grafo de historia + validate-release + QA Electron).
- Log de desarrollo de CONTRABAND, 15 ago 2026, v0.4.89–v0.4.91.
- play/systems/steam-cloud.js (solo conducta pública: archivo de save con nombre, debounce, backup).
03 / ACADEMY × STUDIO 2.0
La misma evidencia sirve para enseñar y para evaluar cómo trabajamos.
Academy conserva el caso técnico completo. Studio 2.0 usa esa capa de evidencia para que un comprador pueda distinguir entre una promesa comercial y una práctica realmente documentada.
EXPLORAR CASOS EN ACADEMY →04 / PRÓXIMO PASO
Trae un flujo de trabajo difícil. Empecemos por lo que se puede verificar.
Para producción de juegos o sistemas creativos, podemos empezar con un problema acotado, definir evidencia y criterios de aceptación, y construir desde ahí.
GUÍA DE LECTURA Y APLICACIÓN
Lee un incidente como una cadena de evidencia.
Un caso útil explica qué falló, por qué la explicación encaja con las observaciones y cómo se comprobó la corrección. Antes de reutilizar una lección, identifica su alcance: corregir un renderizado demuestra algo de ese recorrido, no de todas las capacidades del estudio. Los casos enlazados de Academy conservan el análisis técnico completo.
Ejercicio de lectura: un síntoma visual puede tener causa de estado
Imagina que una recompensa ficticia aparece dos veces tras cargar una partida. La captura confirma el síntoma, pero no la causa. La investigación necesita una secuencia repetible, el estado antes y después y la ruta que concede la recompensa. Cambiar el texto visible no demostraría que el estado quedó corregido.
Un informe útil separa observación e hipótesis, registra la corrección mínima y repite la secuencia con casos cercanos. Ese método de lectura se aplica a los incidentes internos de esta colección. El ejemplo anterior es explicativo; las páginas enlazadas son la fuente de lo que ocurrió realmente en CONTRABAND.
| Evidencia | Pregunta útil | Qué no demuestra |
|---|---|---|
| Reproducción | ¿Otra persona puede provocar el fallo desde el punto inicial descrito? | Una captura por sí sola no identifica el subsistema responsable. |
| Corrección | ¿El cambio corrige la causa y conserva el comportamiento cercano? | Más código u otra herramienta no demuestra corrección. |
| Prueba de regresión | ¿La comprobación falla antes y pasa después de corregir? | Un caso aprobado no cubre todos los equipos, estados o cambios futuros. |
Ejercicio para tu proyecto
- Abre un incidente de Academy y resume síntoma y condiciones iniciales antes de leer la solución.
- Compara tu hipótesis con la causa documentada. Identifica qué evidencia permite distinguirlas.
- Escribe un caso cercano que aún podría fallar y qué observación necesitarías para probarlo.
Conceptos que conviene distinguir
- Causa raíz
- Mecanismo que explica el fallo observado y al que se dirige la corrección.
- Regresión
- Comportamiento que funcionaba y se rompe tras un cambio; hay que verificar tanto comportamiento como contenido.
- Alcance de la evidencia
- Condiciones precisas respaldadas por un resultado, incluyendo lo que no se probó.