diodesign/diosix-agent-skills

Revisando Diosix

Cada cambio de código y documentación en Diosix debe pasar una auditoría rigurosa desde múltiples perspectivas antes de ser confirmado o fusionado. Nunca apruebes cambios al vapor, ni firmes código roto, incompleto o no verificado. Los criterios de revisión a continuación reflejan 1:1 developing-diosix y documenting-diosix, de modo que aplicar las habilidades de autoría elimina el retrabajo previo a la confirmación y fusión.

Flujo de Verificación Obligatorio de 4 Pasos

1. Puerta de Compilación, Integridad y Pruebas (Requisitos Básicos):
   • Verifica que la característica esté 100% implementada según lo diseñado, con cero stubs TODO, código muerto o rutas de producción simuladas.
   • Al refactorizar archivos que superen el límite de 500 líneas, nunca trunques funcionalidades o pruebas unitarias; siempre componentiza archivos de gran tamaño en subcarpetas cohesivas (vm/run.zig, panes/modal.zig, tests/gui.zig) en lugar de archivos planos prefix_subname.zig, y verifica que cada submódulo esté referenciado en el bloque test de su padre (_ = @import("vm/run.zig");) para que zig build test ejecute sus pruebas unitarias.
   • Verifica que las pruebas unitarias estén ubicadas en los mismos archivos .zig que prueban y que las pruebas de integración residan en directorios tests/ separados.
   • Limita las comprobaciones de formato de archivo y línea/columna a los directorios fuente rastreados (build.zig, hypervisor, tools, scripts) en lugar de ejecutar globs recursivos sin alcance en .zig-cache/ o zig-out/.
   • Ejecuta ./scripts/build.sh test --summary all y ./scripts/build.sh hasta que el 100% de los pasos de compilación y prueba pasen con cero advertencias o fugas.
2. Revisión en Profundidad de 4 Personajes:
   • Audita cada archivo modificado y su contexto circundante a través de cuatro lentes distintas:
     1. Ingeniero Veterano Escéptico (integridad, modismos, jerarquía de subcarpetas en lugar de archivos planos prefix_subname.zig, literales hexadecimales en minúsculas 0xfff, constantes/ayudantes nombrados como PAGE_OFFSET_MASK y crossesPageBoundary en lugar de máscaras de bits mágicas, cero duplicación de copia-pega de validadores de Spinlock/alineación/ruta, sin arreglos de respaldo históricos de listas de candidatos como DEFAULT_GUEST_CANDIDATES para rutas internas co-versionadas, tipos ABI u64 de ancho fijo explícitos en lugar de usize, anotaciones de tipo usize explícitas en @min/@max con literales, componentización de archivos >500 líneas sin truncar, límite de <=80 columnas, búferes dinámicos vs. estáticos, externalización de políticas a configuración de compilación/ejecución, sin síntesis binaria/ELF/imagen sobre la marcha en Zig, sin archivos generados dentro de tools/overlay-common/)
     2. Experto en Seguridad Paranoico (aislamiento del radio de explosión del hipervisor, prevención de doble captura/TOCTOU de una sola copia en memoria invitada, bloqueo seguro para IRQ mediante atomic.Spinlock, anulación de criptografía/páginas, límites aritméticos verificados)
     3. Mantenedor de Diosix (modularidad, legibilidad, defer/errdefer, aserciones de tamaño/desplazamiento comptime de ABI, compatibilidad hacia atrás de contrato externo vs. migración atómica en el árbol, cobertura de pruebas de submódulo)
     4. Usuario Principiante y Experto (UX sin esfuerzo, errores claros en inglés, flexibilidad de configuración, rendimiento)
3. Auditoría de Ciclo de Vida de Punteros al Estilo Rust:
   • Rastrea manualmente cada puntero, segmento y asignación a través de todas las rutas de flujo de control para garantizar cero Use-After-Free (UAF), doble liberación, invalidación de punteros al redimensionar/remapear, o referencias colgantes a la pila.
4. Puerta de Documentación, Ortografía y Estilo:
   • Verifica que docs/ coincida con todos los cambios de código (incluyendo SBI FIDs, tipos de struct C, banderas de CLI y rutas de archivo modularizadas), esté escrita en inglés americano claro y gramaticalmente correcto con ortografía verificada, y cumpla con docs/style-guide.md y docs/development.md.
   • Vuelve a ejecutar zig fmt --check build.zig hypervisor tools scripts y ./scripts/build.sh test --summary all después de cualquier corrección de revisión.
5. Cuando Tengas Dudas, Detente y Pregunta al Mantenedor Principal: Si una revisión descubre una compensación arquitectónica o una primitiva faltante, detente y pregunta al mantenedor principal para obtener orientación antes de hacer suposiciones.

Guías de Referencia Enfocadas

Consulta estas listas de verificación de referencia durante cada revisión:

• La Lista de Verificación de los 4 Personajes de Revisión: Criterios de inspección detallados para el Ingeniero Veterano Escéptico, el Experto en Seguridad Paranoico, el Mantenedor de Diosix y el Usuario Principiante/Experto.
• Auditoría de Verificación de Préstamos: Metodología paso a paso para rastrear la procedencia de punteros, tiempos de vida, mutabilidad de alias y seguridad de memoria entre privilegios en Zig.
• Puertas Previas a la Confirmación: Comandos de verificación concretos y criterios de aprobación requeridos antes de confirmar o fusionar en devel o stable.