RIJUDEVx/interrogate

Interrogar

Genera un revisor por modelo configurado para revisar cambios de código de forma adversaria. Cada modelo recibe el mismo prompt y la misma rúbrica. La señal adversaria proviene de la diversidad de modelos, no de personalidades asignadas.

Un hallazgo solo sobrevive cuando una ejecución lo demuestra.

El entregable es un veredicto sintetizado. NO apliques cambios automáticamente.

Paso 1: Determinar el alcance

Identifica qué revisar a partir del contexto:

• Si el usuario señala archivos específicos o un diff, usa eso
• Si estás en una rama de funcionalidad, ejecuta git diff main...HEAD (o la rama base correspondiente) para obtener el conjunto completo de cambios
• Si el mensaje del usuario hace referencia a trabajo reciente, recopila los archivos relevantes

Empaqueta el diff (o el contenido de los archivos) junto con cualquier archivo de contexto adicional que los revisores necesiten para entender el código.

Paso 2: Declarar la intención

Antes de lanzar los revisores, declara la intención explícitamente. Dedúcela de:

• El mensaje del usuario
• Los mensajes de commit
• La descripción del PR si existe
• El código mismo

Escribe un párrafo claro. Si no estás seguro de la intención, pregunta al usuario antes de continuar.

Paso 3: Lanzar revisores

Lanza todos los revisores en un solo mensaje, uno por ranura, usando la herramienta de subagente del arnés o delegate_task.

Busca diversidad de modelos: diferentes familias de modelos detectan diferentes errores. En T3 Code, elige 3-4 modelos sólidos de los favoritos del usuario, de distintas familias, e inicia cada uno con delegate_task (la habilidad t3-tools tiene los pasos). En otros lugares, elige 3-4 modelos distintos de alta capacidad que el arnés exponga. Si no puedes seleccionar un modelo por subagente, lanza revisores sin sobrescribir el modelo y obtén diversidad de contextos independientes.

Subagente	Rol
Revisor A	revisor de razonamiento pesado
Revisor B	segunda familia de modelos independiente
Revisor C	una tercera familia, rápida/diferente
Revisor D	revisor adversario/estricto de calidad de código

Para cada revisor, lanza un subagente de propósito general:

• OpenCode / Codex: subagent_type: general (a través de la herramienta task)
• Claude Code: subagent_type: general-purpose
• Otros arneses: el subagente general más cercano que pueda leer el repositorio

Mantén a los revisores como solo lectura en espíritu: no deben editar archivos. Un revisor que necesite una reproducción la ejecuta en su propia copia o árbol de trabajo, nunca en el lugar.

Dale a cada revisor este resumen junto con la plantilla rellenada:

Rompe este cambio. Demuestra cada hallazgo con una ejecución contra el código real, como una prueba que falla, un script de reproducción o una salida de comando que muestre el comportamiento incorrecto. Para un diseño o plan, ejecuta un prototipo o explora el árbol actual. Mantén las reproducciones en tu propio árbol de trabajo. Reporta cada hallazgo con un título, el comando exacto, la salida que imprimió y la salida que requiere la intención. Omite cualquier cosa que no hayas ejecutado. Eso cubre estilo, nombres, estructura y riesgos que necesitan un cambio futuro para ser relevantes. Ningún hallazgo es un resultado válido.

Si un identificador de modelo es rechazado como no resoluble, verifica los identificadores válidos en el mensaje de error de la herramienta Tarea, elige el equivalente más cercano (prefiere el nivel de razonamiento más alto de la misma familia) y lanza con el identificador válido. No bloquees la revisión por el problema del identificador.

Lee references/reviewer-prompt.md y rellena la plantilla con:

1. La intención declarada
2. El diff o el contenido de los archivos
3. La rúbrica de revisión de references/rubric.md
4. El lente de calidad de código de references/code-quality-review.md

La misma plantilla rellenada va a todos los revisores, para que cada modelo aplique el lente de calidad de código.

Paso 4: Sintetizar

A medida que llegan los resultados, construye una imagen unificada:

1. Verifica cada hallazgo volviendo a ejecutar su comando. Conserva un hallazgo cuando la salida muestre el fallo y ese fallo rompa la intención. Descarta el resto. Fusiona hallazgos que compartan una causa raíz.
2. Analiza todos los hallazgos de los revisores
3. Identifica consensos. Los hallazgos planteados por 2+ modelos de forma independiente son la señal más fuerte.
4. Identifica hallazgos de un solo modelo. Aún vale la pena leerlos, pero pondera en consecuencia.
5. Desduplica. Diferentes modelos pueden describir el mismo problema de manera distinta. Fusiona estos y anota qué modelos lo plantearon.
6. Anota desacuerdos. Si un modelo marca algo y otro dice explícitamente lo contrario, ese es un contexto útil para el veredicto.

Paso 5: Juicio principal

Eres el revisor principal, un ingeniero senior pragmático, no un agregador neutral.

Lee references/lead-judgment.md para el marco completo.

Clasifica cada hallazgo en estos grupos:

• Actuar. Problemas reales que afectan corrección, seguridad o mantenibilidad dados los objetivos reales. Estos bloquearían un PR real.
• Considerar. Puntos legítimos, pero no estás seguro de que superen el costo de abordarlos ahora mismo. Vale la pena que el usuario los tenga en cuenta.
• Notado. Técnicamente válido pero no accionable. Depende del contexto, optimización prematura o bajo impacto dado el estado actual.
• Descartado. Incorrecto, quisquilloso o sin contexto. Breve explicación del porqué.

Para cada hallazgo, incluye:

• Qué modelo(s) lo plantearon
• La categoría (actuar / considerar / notado / descartado)
• Una justificación de una línea para la categorización

Formato de salida

Presenta el veredicto en esta estructura:

Intención

[El párrafo de intención declarada del Paso 2]

Revisores

• Revisor [etiqueta]: [nombre del modelo], [N hallazgos] (una viñeta por revisor)

Actuar

[Hallazgos que deben abordarse. Para cada uno: descripción, qué modelos lo plantearon, por qué es importante.]

Considerar

[Hallazgos que vale la pena considerar. Para cada uno: descripción, qué modelos lo plantearon, compensación involucrada.]

Notado

[Válido pero baja prioridad. Lista breve.]

Descartado

[Hallazgos rechazados con breve justificación, incluyendo hallazgos que ninguna ejecución demostró.]

Mapa de acuerdos

[¿Dónde coincidieron los modelos, dónde divergieron y qué nos dice el patrón de acuerdo/desacuerdo?]

Radio de explosión

Usa este modo cuando un cambio es pequeño pero aún no es confiable, y la pregunta es qué rompe más allá del diff. Enumerar los llamadores no es el trabajo. Grep los encuentra en un segundo. El trabajo es la rotura que grep no mostrará.

No confíes en tu propio informe

Un informe de lo que un cambio rompe que suena bien no vale nada. Se lee como convincente sea o no verdadero. Así que no devuelvas el informe. Encuentra el único o los dos hechos de los que depende todo y demuéstralos ejecutando código.

¿Qué tan seguro estás?

Para cada hecho del que depende la seguridad del cambio, llévalo tan abajo en esta lista como sea barato, y di dónde se detuvo.

1. Tú lo dijiste. No vale nada por sí solo.
2. Señalaste la línea. Un archivo:línea real, o el código fuente de la biblioteca.
3. Mostraste que el caso malo no puede ocurrir. Recorriste el fallo paso a paso y no alcanza.
4. Lo ejecutaste. Un script o prueba que llama al código real y falla fuerte si estás equivocado.
5. Lo reprodujiste en la aplicación en ejecución.

Cualquier hecho de seguridad que no puedas llevar al paso 4, dilo. No lo escribas como resuelto. El paso 4 suele ser un pequeño script que importa la misma biblioteca que la aplicación usa y llama a la función exacta que te preocupa.

Pasos

1. Lee el cambio. El diff, los símbolos que añade, cambia y elimina, y qué hace ahora de manera diferente, incluyendo la parte que el diff no detalla. Extrae los mensajes del PR y del commit para conocer la razón.
2. Encuentra el único hecho por el que es seguro. La mayoría de los cambios que parecen riesgosos son seguros debido a un solo hecho, como "esta llamada solo elimina entradas de caché ya muertas y no hace nada más". Encuentra ese hecho. Si se cumple, la mayoría de los casos riesgosos se aclaran de inmediato. Dedica tu tiempo aquí, no a una larga lista de quizás.
3. Mira hasta dónde llega grep. Lee el código fuente de la biblioteca que llamas, y verifica su versión fija y cualquier parche local. Averigua cuándo se ejecutan las cosas: microtareas, desmontaje y limpieza, Solid versus React. Sigue lo que una búsqueda de símbolos pasa por alto: el JSON que devuelve una API, una columna de BD, un formato de cable, otro idioma leyendo los mismos bytes, un feature flag, código tres saltos aguas abajo.
4. Sé honesto con cada riesgo. Dale una probabilidad real de que ocurra y un costo real si ocurre. Conserva los riesgos que confirmaste. Enumera los que verificaste y descartaste por separado. Cita un archivo:línea real, una búsqueda que no encuentra nada sigue siendo una respuesta, y nunca inventes un llamador o una API.
5. Demuestra el único hecho. Escribe un script o prueba que ejecute el código real, ejecútalo y pega lo que sucedió. Si no puedes demostrarlo de forma barata, márcalo como no probado. No exageres.
6. Para un cambio grande o extenso, pásalo por la revisión anterior con varios modelos. Diferentes modelos detectan diferentes errores reales.

Qué entregar

• Qué hace. Lo que cambió, incluyendo la parte que no es obvia.
• El único hecho por el que es seguro. Dilo, indica en qué paso lo detuviste y muestra la prueba. Si no pudiste probarlo, escribe no probado.
• Riesgos. Solo los reales. Cada uno nombra cómo rompe, el archivo:línea, qué tan probable y qué tan malo, y cómo verificarlo. Pega la prueba para los que importan.
• Descartados. Lo que verificaste y por qué está bien.
• Antes de fusionar. La prueba o reproducción más barata que detecta el error real, incluyendo el script que escribiste.

Escríbelo con unslop, cita código real y elimina cualquier cosa privada antes de que vaya a algún lugar público.

Respuesta: el informe anterior, con el único hecho de seguridad probado o marcado como no probado.