1204. Identidad de la lección
Esta lección convierte la entrada de assets en una decisión de producción auditable. Inventariarás un conjunto de assets, crearás registros de validación por requisito, conservarás evidencia trazable, determinarás el estado de cada asset y priorizarás acciones correctivas.
1205. Objetivo de aprendizaje
Al terminar, podrás producir una auditoría de assets con registros de entrada completos, comprobaciones por requisito, estados respaldados por evidencia y acciones priorizadas según su impacto en la producción.
1206. Por qué importa
Un archivo puede existir y, aun así, ser inutilizable, carecer de licencia documentada, tener referencias rotas, quedar fuera del build, estar duplicado o no servir para su función en tiempo de ejecución. Una auditoría repetible permite detectar estas condiciones antes de que provoquen fallos de ejecución o del build.
La auditoría no es un simple listado de carpetas. Consta de tres registros relacionados:
- Manifiesto de assets: qué está dentro del alcance y qué función debe cumplir cada asset.
- Registros de validación: un registro por cada requisito comprobado.
- Lista de acciones: qué debe ocurrir, por qué importa y qué información justifica su prioridad.
La IA puede cuestionar la integridad y coherencia de estos registros, pero no puede aportar evidencia sobre archivos o sistemas que no haya inspeccionado.
1207. Modelo central: Manifiesto → Comprobaciones → Evidencia → Estado → Acción
| Etapa | Pregunta | Resultado |
|---|---|---|
| Manifiesto | ¿Qué assets, versiones, funciones y ubicaciones están dentro del alcance? | Un registro de entrada por asset o grupo justificado |
| Comprobaciones | ¿Qué debe cumplirse para aceptar el asset? | Un registro de validación por requisito |
| Evidencia | ¿Qué observación o prueba respalda el resultado? | Observación, medición, registro o ausencia documentada y trazable |
| Estado | ¿Qué permiten concluir los resultados individuales? | Estado general derivado |
| Acción | ¿Qué debe ocurrir y con qué urgencia? | Acción correctiva o de investigación concreta |
Un estado sin evidencia es una afirmación. Una evidencia sin requisito es una observación aislada. Una acción sin contexto de producción no puede recibir una prioridad defendible.
1208. Registro 1: entrada básica de assets
Crea una entrada del manifiesto por asset. Agrupa entradas solo cuando compartan función, procedencia, restricciones, ownership y ruta de validación, y explica por qué es seguro agruparlas.
Usa esta lista básica y compacta:
| Área de entrada | Qué registrar |
|---|---|
| Identidad y versión | ID estable, nombre descriptivo, versión o revisión y función prevista |
| Procedencia y licencia | Fuente o autor, registro de licencia o uso y cualquier vacío de procedencia |
| Nombre y ubicación | Resultado de la convención de nombres, ruta del repositorio o proyecto y ubicación esperada |
| Formato y restricciones | Formato y restricciones técnicas propias de la función, como dimensiones, escala, canales, duración o compresión cuando correspondan |
| Tamaño o presupuesto | Tamaño medido y presupuesto o límite aplicable |
| Carga y referencias | Ruta de carga, integridad de las referencias y resolución de dependencias |
| Ciclo de vida | Responsable en tiempo de ejecución y expectativa de liberación o descarte cuando corresponda |
| Duplicados o contenido sin uso | Duplicado conocido, posible duplicado, referenciado, conservado de forma intencional o candidato a eliminar |
| Inclusión en el build | Inclusión esperada y evidencia de que el asset se incluye o se excluye deliberadamente |
Usa No aplica solo cuando un campo realmente no corresponda y registra el motivo. La información ausente no significa que no aplique: significa que está pendiente.
Un esquema práctico para el manifiesto es:
ID del asset | Nombre/versión | Función prevista | Procedencia/licencia | Ubicación | Responsable en runtime | Estado de duplicado/uso | Expectativa para el build
El manifiesto puede enlazar a los registros de validación en lugar de acumular todas las pruebas en una sola fila demasiado ancha.
1209. Registro 2: validación por requisito
No combines varios requisitos en un único resultado. Crea un registro por cada pareja de asset y requisito:
ID de comprobación | ID del asset | Requisito | Método | Evidencia | Resultado | Acción correctiva
Usa estos resultados:
- Aprobado: la evidencia registrada satisface el requisito.
- Fallido: la evidencia demuestra que el requisito no se cumple.
- Requiere revisión: la evidencia disponible es insuficiente o contradictoria.
- No aplica: el requisito no corresponde y se ha registrado el motivo.
Si una plantilla de producción exige tokens canónicos, puede usar pass, fail, needs_review y not_applicable como valores internos, mientras presenta las etiquetas legibles anteriores.
La evidencia debe indicar qué podría inspeccionar otra persona: una propiedad medida, el resultado de una prueba, una comprobación de la ruta de referencia, un registro de licencia, un informe del build o una ausencia documentada. «Parece correcto» no basta, salvo que el requisito y las condiciones de inspección den sentido concreto a esa observación.
Cómo determinar el estado general
Deriva el estado del asset a partir de sus comprobaciones:
- Fallido: falla al menos una comprobación obligatoria.
- Requiere revisión: no falla ninguna comprobación obligatoria, pero al menos una sigue pendiente.
- Aprobado: todas las comprobaciones aplicables están aprobadas y cada resultado No aplica incluye una justificación.
Un asset no queda aprobado porque una sola comprobación haya tenido éxito. Por ejemplo, un formato válido no demuestra que la escala, las referencias, la licencia o la inclusión en el build sean correctas.
1210. Ejemplo desarrollado
Supón que ENV-01 es un elemento de entorno previsto para el siguiente build de integración.
Entrada del manifiesto
| ID | Nombre/versión | Función | Procedencia/licencia | Ubicación | Responsable en runtime | Duplicado/uso | Expectativa para el build |
|---|---|---|---|---|---|---|---|
| ENV-01 | Caja, revisión sin registrar | Elemento de entorno | Fuente indicada; falta el registro de licencia | /assets/environment/ |
Se espera que pertenezca a la escena; no se ha documentado su liberación | No se ha comprobado si existe un duplicado | Incluir en el siguiente build de integración |
Registros de validación
| ID de comprobación | Asset | Requisito | Método | Evidencia | Resultado | Acción correctiva |
|---|---|---|---|---|---|---|
| ENV-01-FMT | ENV-01 | El formato debe ser compatible con la especificación de entrada | Comparar la extensión con la especificación | La extensión coincide con un formato admitido | Aprobado | Ninguna |
| ENV-01-SCL | ENV-01 | La escala debe coincidir con el objeto de referencia en contexto | Colocarlo junto al objeto de referencia | No hay ninguna prueba en contexto registrada | Requiere revisión | Ejecutar y capturar la comparación de escala |
| ENV-01-SHP | ENV-01 | La forma debe reconocerse desde la cámara prevista | Inspeccionar desde la cámara prevista | No hay una captura desde esa cámara | Requiere revisión | Capturar la vista desde la cámara prevista |
| ENV-01-LIC | ENV-01 | Debe existir un registro enlazado de licencia o permiso de uso | Revisar los registros de procedencia | La fuente está identificada, pero no hay un permiso de uso enlazado | Requiere revisión | Localizar u obtener el registro antes de usarlo en una entrega |
Por tanto, ENV-01 requiere revisión; no está aprobado. El formato es correcto, pero quedan tres comprobaciones obligatorias pendientes. La auditoría tampoco afirma que haya que sustituir el asset: la evidencia justifica investigar, no reemplazar.
1211. Priorizar sin inventar certeza
La prioridad depende de las consecuencias y del calendario de producción, no de la visibilidad del asset ni de la incertidumbre por sí sola.
Usa esta política:
- P1 — bloqueo: impide ahora una integración, entrega o decisión obligatoria; no hay un sustituto o solución temporal aceptable.
- P2 — riesgo con fecha límite: no bloquea el paso actual, pero debe resolverse antes de un hito o dependencia próximos y definidos.
- P3 — corrección o limpieza rutinaria: puede programarse sin poner en riesgo el hito indicado.
Se permiten prioridades iguales. No fuerces un orden estricto P1/P2/P3 cuando la evidencia no distinga las acciones. Registra la información que falta para decidir, como la fecha del hito, la importancia de la funcionalidad, la disponibilidad de sustitutos, las dependencias posteriores, la disponibilidad de una persona responsable o el coste de retrasar la decisión.
1212. Práctica guiada
Usa únicamente las observaciones y el contexto siguientes.
Contexto de producción
- El siguiente build de integración debe estar listo mañana.
- WORLD-01 es necesario para una prueba de colisiones de ese build y no hay ningún sustituto registrado.
- HUD-01 se necesita para una revisión la próxima semana; ya existe un icono temporal.
- SFX-01 ya está referenciado por la prueba de interacción actual. El archivo se reproduce correctamente, pero el nombre ambiguo supone un riesgo de mantenimiento, no un bloqueo actual de ejecución.
Observaciones de entrada
HUD-01: icono de estado; PNG; 64 × 64; vista previa disponible; parece legible; registro de fuente y licencia enlazado; hay un sustituto temporal.
WORLD-01: elemento pequeño de entorno; archivo de modelo presente; escala prevista sin registrar; no hay vista previa en contexto; se necesita mañana para probar colisiones; no hay sustituto registrado.
SFX-01: sonido de interacción; archivo de audio presente; reproducción confirmada; la referencia actual se resuelve; el nombre no identifica el evento.
Para cada asset:
- Completa los campos básicos del manifiesto. Marca la información ausente como pendiente, no como No aplica.
- Crea registros separados para cada requisito que evalúes.
- Asigna a cada comprobación un método, una evidencia, un resultado y una acción correctiva.
- Deriva el estado del asset a partir de sus comprobaciones.
- Prioriza las acciones con la política indicada.
- Identifica la información ausente que impide tomar una decisión más firme.
Una respuesta defendible puede clasificar la prueba de escala de WORLD-01 como P1 porque bloquea la prueba de colisiones de mañana y no hay sustituto registrado. HUD-01 podría ser P2 o P3 según el requisito concreto de la revisión. Cambiar el nombre de SFX-01 probablemente sea una tarea rutinaria, salvo que aparezca información adicional sobre sus dependencias. Estas conclusiones se derivan del contexto proporcionado; no son prioridades universales.
1213. Flujo de trabajo con IA
Usa la IA para revisar la estructura, no como fuente de observaciones:
- Define tú los campos de entrada y los requisitos de aceptación.
- Registra observaciones, mediciones, resultados de pruebas y ausencias documentadas.
- Proporciona a la IA únicamente los registros que quieras revisar.
- Pídele que señale campos básicos ausentes, requisitos combinados, aprobaciones sin respaldo, acciones desalineadas y prioridades mal justificadas.
- Contrasta cada sugerencia con la evidencia y el contexto de producción.
- Conserva las sugerencias rechazadas o modificadas cuando ayuden a explicar tus decisiones.
Ejemplo de prompt:
Revisa esta auditoría de assets sin inventar propiedades de archivos ni resultados de pruebas. Comprueba que cada requisito tenga su propio método, evidencia, resultado y acción correctiva. Señala aprobaciones sin respaldo, campos de entrada ausentes, usos de No aplica sin justificación y prioridades que carezcan de contexto sobre hitos o dependencias.
1214. Errores frecuentes
- Combinar formato, escala, legibilidad y licencia en una sola comprobación.
- Aprobar un asset porque el archivo se abre o porque supera un único requisito.
- Tratar la falta de evidencia como No aplica.
- Omitir procedencia, licencia, ruta de referencia, responsable en runtime, duplicados o inclusión en el build.
- Presentar una recomendación como si fuera un hecho observado.
- Asignar P1 solo porque el asset es visible o genera incertidumbre.
- Forzar prioridades distintas cuando el contexto permite un empate.
- Permitir que la IA invente evidencia de validación.
1215. Práctica independiente y evaluación práctica
Completa la evaluación práctica enlazada con un pequeño conjunto de assets de tu ejercicio o con un conjunto inventado claramente identificado. Produce:
- Un manifiesto básico que cubra todos los assets incluidos.
- Registros de validación por requisito con identificadores únicos.
- Evidencia trazable y resultados correctos.
- Estados generales derivados.
- Una lista de acciones correctivas con prioridades justificadas e información decisoria pendiente.
- Un breve traspaso que identifique los bloqueos del build y la evidencia útil para la siguiente puerta de aceptación.
La evaluación práctica se puntúa. Una aprobación sin evidencia impide superar la evaluación aunque la puntuación numérica fuera suficiente.
1216. Validación y traspaso
Antes de completar la auditoría, comprueba que:
- Cada asset esté representado o cubierto por una regla de agrupación justificada.
- Se hayan registrado —o marcado explícitamente como pendientes— la identidad, versión, procedencia, licencia, nombre, ubicación, restricciones, presupuesto, referencias, ownership del ciclo de vida, estado de duplicado o uso e inclusión en el build.
- Cada requisito evaluado tenga su propio método, evidencia, resultado y acción.
- Cada resultado No aplica incluya una justificación.
- Los estados generales se deriven de las comprobaciones individuales.
- Las prioridades citen el calendario del hito, el impacto en dependencias, la disponibilidad de sustitutos o la información decisoria que falta.
- Los hechos, las suposiciones, las preguntas abiertas y las recomendaciones permanezcan separados.
Lleva el manifiesto completado, los registros de validación por requisito, los bloqueos pendientes y las acciones priorizadas a 3.10 — Build pipeline como posibles evidencias para la puerta de aceptación del build. Que un build funcione en una máquina local no basta para aceptarlo si siguen pendientes comprobaciones obligatorias de assets, licencias, referencias o inclusión en el build.
1217. Comprobación
Responde estas preguntas por tu cuenta antes de leer las respuestas.
Un asset ha aprobado la comprobación de formato, pero su escala y su registro de licencia siguen sin verificarse. ¿Qué estado general está justificado?
Mostrar respuesta y explicación
Respuesta: Requiere revisión, porque quedan comprobaciones obligatorias pendientes.
Por qué: Aprobar el formato no valida los requisitos independientes de escala y licencia. Si no hay un fallo demostrado pero quedan comprobaciones obligatorias pendientes, el asset requiere revisión.
¿Qué campos pertenecen a un registro de validación por requisito? Selecciona todas las respuestas correctas.
Mostrar respuesta y explicación
Respuesta: ID de comprobación y requisito; Método y evidencia trazable; Resultado y acción correctiva
Por qué: Cada requisito necesita una comprobación identificable, un método, evidencia, un resultado y una acción correctiva adecuada. Una puntuación genérica oculta resultados distintos.
Dos acciones pendientes tienen el mismo impacto conocido sobre el hito y no hay información sobre sustitutos o dependencias. ¿Qué debe hacer quien realiza la auditoría?
Mostrar respuesta y explicación
Respuesta: Asignar la misma prioridad y registrar la información decisoria que falta.
Por qué: La prioridad debe basarse en la evidencia de producción disponible. Se permiten prioridades iguales cuando el contexto no justifica un orden estricto, y debe hacerse explícita la información que falta.
¿Qué uso de No aplica es válido en una auditoría de assets?
Mostrar respuesta y explicación
Respuesta: El requisito realmente no corresponde a la función del asset y el registro explica el motivo.
Por qué: No aplica significa que el requisito no corresponde y exige una justificación. La falta de evidencia, una prueba no realizada o una incertidumbre deben quedar pendientes, no ocultarse como No aplica.