Verificación de Calidad del Código
Verificación integral de calidad para código recién escrito. Combina cumplimiento de especificaciones, seguridad entre capas y comprobaciones previas a la confirmación.
Paso 1: Identificar qué Cambió
git diff --name-only HEAD
git status
Paso 2: Leer Artefactos de la Tarea y Especificaciones Aplicables
Lee los artefactos de la tarea actual en orden:
prd.mddesign.mdsi existeimplement.mdsi existe
python3 ./.trellis/scripts/get_context.py --mode packages
Para cada paquete/capa modificada, lee el índice de especificaciones y sigue su sección Verificación de Calidad:
cat .trellis/spec/<package>/<layer>/index.md
Lee los archivos de directrices específicos a los que se hace referencia: el índice es un puntero, no el objetivo.
Paso 3: Ejecutar Comprobaciones del Proyecto
Ejecuta los comandos de lint, verificación de tipos y pruebas del proyecto. Corrige cualquier fallo antes de continuar.
Paso 4: Revisar Según la Lista de Verificación
Calidad del Código
- ¿Pasa el linter?
- ¿Pasa el verificador de tipos (si aplica)?
- ¿Pasan las pruebas?
- ¿Se ha dejado algún registro de depuración?
- ¿Hay supresiones de advertencias o evasiones de seguridad de tipos?
Cobertura de Pruebas
- ¿Función nueva → prueba unitaria añadida?
- ¿Corrección de errores → prueba de regresión añadida?
- ¿Comportamiento modificado → pruebas existentes actualizadas?
Sincronización de Especificaciones
- ¿Necesita actualizarse
.trellis/spec/? (nuevos patrones, convenciones, lecciones aprendidas)
"Si corregí un error o descubrí algo no obvio, ¿debería documentarlo para que un futuro yo no se encuentre con el mismo problema?" → Si la respuesta es SÍ, actualiza el documento de especificación correspondiente.
Disciplina de Alcance
- ¿Se ha ordenado código que la tarea no requería?
- ¿Se ha añadido alguna abstracción, configuración o punto de extensión para un caso que aún no existe?
- ¿Hay alguna alternativa especulativa para un estado que no puede ocurrir?
- ¿Se ha modificado algún archivo que los criterios de aceptación no mencionan?
- ¿Se ha añadido una solución temporal en el lugar de la llamada en lugar de una corrección donde realmente reside el comportamiento?
Paso 5: Dimensiones entre Capas (si aplica)
Omite este paso si tu cambio se limita a una sola capa.
A. Flujo de Datos (los cambios afectan a 3+ capas)
- ¿Los flujos de lectura se rastrean correctamente: Almacenamiento → Servicio → API → IU?
- ¿Los flujos de escritura se rastrean correctamente: IU → API → Servicio → Almacenamiento?
- ¿Los tipos/esquemas se pasan correctamente entre capas?
- ¿Los errores se propagan adecuadamente al llamante?
B. Reutilización de Código (modificación de constantes, creación de utilidades)
- ¿Se buscó código similar existente antes de crear uno nuevo?
grep -r "pattern" src/ - Si el mismo valor se repite, ¿representa un concepto estable cuyos llamantes deben cambiar juntos? Extraer solo entonces — dos literales que hoy coinciden casualmente deben permanecer separados.
- Después de una modificación por lotes, ¿se actualizaron todas las ocurrencias?
C. Importaciones/Dependencias (creación de nuevos archivos)
- ¿Rutas de importación correctas (relativas vs absolutas)?
- ¿Sin dependencias circulares?
D. Consistencia dentro de la Misma Capa
- ¿Otros lugares que usan el mismo concepto son consistentes?
Paso 6: Reportar y Corregir
Informa cada violación que encuentres. Luego:
- Mecánico y local (detalle de lint, tipo faltante, importación incorrecta, rama muerta, aserción fallida) → corrige en el lugar, luego vuelve a ejecutar las comprobaciones del proyecto.
- Diseño o criterio (nombrar un concepto compartido, mover un límite de módulo, cambiar una interfaz pública, reasignar dónde reside el comportamiento) → registra la evidencia y tu recomendación, y detente. No lo reescribas silenciosamente.
Si una corrección afectaría archivos fuera del alcance de la tarea actual, dílo y detente en lugar de ampliar el cambio.