Assay
Usa esta habilidad para realizar una revisión de código estática, basada en puertas de calidad, a nivel local. La revisión abre las puertas de calidad en orden; una falla en una puerta inferior bloquea las puertas superiores porque los juicios posteriores no son útiles cuando la higiene básica, los nombres o el manejo de errores ya están rotos.
Esta habilidad no llama servicios remotos, no publica comentarios, no aprueba código ni modifica archivos. Revisa entradas locales o pegadas y produce un informe estructurado.
Flujo de trabajo
Fase 0: Resolver entrada local
Normaliza la entrada del usuario en un alcance de revisión:
| Entrada | Resolución |
|---|---|
| Código o diff pegado | Revisar el contenido proporcionado directamente |
| Ruta(s) de archivo local(es) | Leer el contenido completo del archivo; sin contexto de diff a menos que esté disponible |
| Diff git local | Revisar los archivos modificados y los hunks |
| Hash de commit o rango | Usar diff git local cuando esté disponible |
| Nombre de rama | Usar diff git de merge-base local cuando esté disponible |
| Solicitud ambigua | Preguntar por archivos, diff, commit/rango, rama o código pegado |
No obtengas datos de MR/PR, llames APIs remotas ni requieras autenticación. Si se necesita contexto remoto, pide al usuario que proporcione un diff local o contenido pegado.
Fase 1: Calibrar profundidad de revisión
Elige cuántas puertas abrir. Por defecto, Puertas 1-5 para cambios locales ordinarios.
| Contexto | Rango de puertas |
|---|---|
| Borrador, WIP, código exploratorio | Puertas 1-3 |
| Funcionalidad ordinaria o herramienta interna | Puertas 1-5 |
| Biblioteca compartida, ruta de producción o API pública | Puertas 1-7 |
| Código sensible a seguridad, autenticación, criptografía, ejecución de comandos o límite de entrada de usuario | Puertas 1-8 |
Cuando sea ambiguo, preguntar cuál es el destino o el nivel de riesgo del código.
Fase 2: Triage de ámbitos grandes
Cuando el alcance de la revisión contenga más de 5 archivos, realiza un triage rápido antes de la inspección profunda. Para 5 archivos o menos, omite el triage y procede a la extracción estructural.
Verificaciones de triage:
| # | Verificación | Señal de fallo |
|---|---|---|
| 1 | Código muerto | Código comentado, importaciones no usadas, salida de depuración |
| 2 | Claridad de nombres | Nombres públicos vagos o engañosos |
| 3 | Profundidad de anidación | Anidación más profunda de 3 niveles |
| 4 | Longitud de función | Funciones suficientemente largas para ocultar múltiples responsabilidades |
| 5 | Captura de errores | Catch/except vacío o fallo ignorado |
| 6 | Mezcla de dominios | E/S y lógica de negocio mezcladas en una unidad |
| 7 | Ensamblaje de campo bruto | Condiciones complejas sin ayudantes semánticos |
| 8 | Olor a duplicación | Lógica similar aparece repetidamente |
| 9 | Olor de seguridad | Secretos, interpolación insegura, logs sensibles, entrada peligrosa sin verificar |
Clasificar archivos:
| Clase | Criterio | Próxima acción |
|---|---|---|
| Rojo | 3 o más verificaciones fallan | Inspección completa de puertas |
| Amarillo | 1-2 verificaciones fallan | Inspeccionar puerta específica y todas las puertas inferiores |
| Verde | 0 verificaciones fallan | Pasar a menos que se solicite específicamente |
El olor de seguridad es de doble vía: reportarlo como alerta de triage incluso si la Puerta 8 está bloqueada por una puerta inferior.
Fase 3: Extracción estructural
Antes de abrir puertas, extraer la estructura de cada función, clase, módulo o unidad de código relevante revisada. Usar la extracción para guiar la revisión de puertas; no confiar solo en el texto bruto del diff.
Registrar:
- Cierres, callbacks o funciones anidadas.
- Objetos en línea o entidades locales con comportamiento.
- Operaciones de E/S y efectos secundarios externos.
- Anidación más profunda y su razón.
- Distribución de dominio: infraestructura, negocio, presentación o mixto.
- Ciclo de vida: único, persistente o mixto.
- Variables capturadas y dependencias ocultas.
- Anomalías obvias descubiertas durante la extracción.
- Fuente de verdad disponible para Puerta 6: localizar cualquier spec o documento de gobierno (
openspec/,PROJECT.md,AGENTS.md, ADRs, un issue vinculado) para juzgar la lógica, o anotar que no se encontró ninguna.
Fase 4: Revisión secuencial de puertas
Leer references/gates.md para definiciones de puertas.
Abrir puertas en orden. Si una puerta falla, dejar de abrir puertas superiores para ese archivo o alcance de revisión. No fabricar hallazgos. El silencio significa cumplimiento para las secciones detalladas; el índice de puertas aún registra qué puertas se abrieron, pasaron, fallaron o fueron bloqueadas.
Fase 5: Informe
Producir un informe usando este formato:
## Registro de revisión
**Fuente**: [referencia de entrada]
**Calibración**: Puertas 1-[N] ([razón])
**Triage**: [omitido | Rojo M / Amarillo N / Verde K]
**Veredicto**: [PASA | FALLA en Puerta N]
### Índice de puertas
| Puerta | Enfoque | Estado |
|---:|---|---|
| 1 | Higiene de formato y sintaxis | [pasa | falla | bloqueado | no inspeccionado] |
| 2 | Nombres y legibilidad | [pasa | falla | bloqueado | no inspeccionado] |
| 3 | Manejo de errores y observabilidad | [pasa | falla | bloqueado | no inspeccionado] |
| 4 | Flujo de control y claridad estructural | [pasa | falla | bloqueado | no inspeccionado] |
| 5 | Responsabilidad y límites | [pasa | falla | bloqueado | no inspeccionado] |
| 6 | Integridad de la lógica de negocio | [pasa | falla | bloqueado | no inspeccionado] |
| 7 | Desduplicación y composición | [pasa | falla | bloqueado | no inspeccionado] |
| 8 | Seguridad e integridad de parámetros | [pasa | falla | bloqueado | no inspeccionado] |
### Alerta de triage de seguridad
[Incluir solo cuando falla la verificación 9 de triage.]
### Puerta N: [nombre]
| # | Ubicación | Violación | Corrección |
|---|---|---|---|
| 1 | `archivo:línea` | Puerta N: estándar específico violado | Corrección concreta |
### Apéndice estructural
[Incluir resúmenes de unidades de código relacionadas con los hallazgos.]
Fase 6: Plan de corrección opcional
Producir un plan de corrección solo cuando el usuario lo solicite.
Reglas del plan de corrección:
- Una violación por corrección.
- El orden de corrección sigue el orden de las puertas.
- Dentro de la misma puerta, ordenar por archivo y línea a menos que dependencias lógicas requieran otro orden.
- Sin correcciones oportunistas.
- Cada corrección incluye criterios de verificación.
Reglas
- Revisar solo; no modificar código.
- Usar solo entradas locales o pegadas; no llamar APIs remotas de PR/MR.
- Abrir puertas secuencialmente y detenerse en la primera puerta que falle.
- Reportar alertas de triage de seguridad incluso cuando la inspección profunda de seguridad esté bloqueada.
- Dar correcciones concretas; evitar sugerencias vagas como "considerar mejorar".
- Si todas las puertas abiertas pasan, el Índice de puertas es el informe; no inventar hallazgos.
- Mencionar cuando las pruebas, compilaciones o verificaciones en tiempo de ejecución no se hayan ejecutado.
- Mantenerse en el ámbito; transferir en el límite. Esta habilidad es solo de revisión estática local. Para corrección en tiempo de ejecución/comportamiento, señalar a
verify; para análisis de seguridad profunda más allá de las comprobaciones superficiales de la Puerta 8, señalar asecurity-review. Nombrar la transferencia en lugar de hacer a medias el trabajo de la otra habilidad.