keyz182/revisión-adversarial

Revisión adversarial

Encuentra las razones por las que una propuesta fallará antes de que alguien actúe sobre ella. Produce preocupaciones clasificadas y procesables, y un veredicto. Nunca implementes nada. Nunca recorras más allá del límite de rondas.

0. Configuración

1. Elige el modo. report cuando el solicitante lo indique (por ejemplo, "revisión adversarial en modo informe"), o cuando se ejecute dentro de un subagente, trabajador o ejecución sin cabeza (headless) sin un humano para responder. Señales: la tarea llegó como una indicación delegada, no hay herramienta de preguntas, o el solicitante pidió un archivo o un resumen con límite de palabras. interactive en cualquier otro caso.
2. Encuentra el artefacto. Puede ser: una ruta de archivo, un rango de diff, un plan pegado, o "lo que se acaba de producir en esta conversación". Si hay más de un candidato que encaja, nombra el elegido en la primera línea de salida. Si no se dio ninguno y no hay nada reciente que sea un candidato obvio: en modo interactivo, pregunta qué artefacto se quiere analizar, ofreciendo el resultado más reciente de esta conversación, un archivo o diff que el usuario nombre, o un enfoque que el usuario describa. En modo informe, detente y di que no se proporcionó ningún artefacto.
3. Establece la criticidad: prototipo, herramienta interna, producción, o ruta de dinero o seguridad. Interactivo: si no está claro y eso cambiaría la intensidad con la que presionar, pregunta una vez. Informe: asume producción y dilo. La criticidad establece la profundidad del barrido de categorías. Nunca mueve la barra de gravedad.
4. Verifica si existe un registro (ledger). Determina la ruta del registro (ver sección 11). Si existe un registro para este artefacto, lee references/ledger-format.md.
   • Si la última fila para cualquier ID en la ronda más reciente está pendiente, un recorrido se interrumpió. Reanúdalo: omite las secciones 1 a 5, lee los registros almacenados y continúa con la sección 8 desde la primera preocupación pendiente. No vuelvas a ejecutar los lentes ni a reclasificar. El modo informe los lista bajo DECISIONES ABIERTAS en su lugar.
   • De lo contrario, esta es una ronda posterior. Sigue la sección 11.

1. Presenta primero el mejor caso

Antes de cualquier preocupación, escribe dos o tres frases sobre por qué la propuesta es razonable: el problema que resuelve y las restricciones que respeta. Si esto no se puede escribir, la propuesta aún no se comprende. Lee más primero.

2. Genera preocupaciones candidatas

Carga el archivo de referencia de un lente cuando llegues a ese lente. Ejecuta L12 al final.

#	Lente	Uso	Referencia
L1	Fracaso en retrospectiva: se lanzó y causó una interrupción; rastrear hacia atrás	Siempre	references/lens-questions.md
L2	Invertir el objetivo: enumera lo que garantizaría el fracaso; verifica cuáles están presentes	Siempre	references/lens-questions.md
L3	Suposiciones ocultas: nombra cada una; pregunta qué pasa si es falsa	Siempre	references/lens-questions.md
L4	Barrido de categorías de áreas comúnmente pasadas por alto	Siempre	references/category-checklist.md
L5	Barrido de salida de IA para fallos típicos de IA	Siempre, cuando lo produjo una IA	references/ai-output-checklist.md
L6	Precisar la afirmación: hacer que las palabras vagas sean verificables	Según el tipo	references/lens-questions-extended.md
L7	Preguntar por la evidencia: ¿medida, leída o asumida?	Según el tipo	references/lens-questions-extended.md
L8	Otros puntos de vista: guardia de turno, seguridad, recién llegado, usuario intensivo, atacante	Según el tipo	references/lens-questions-extended.md
L9	Seguirlo dos o tres pasos hacia adelante	Siempre	references/lens-questions-extended.md
L10	Cuestionar el encuadre: ¿problema correcto, cambio más pequeño?	Siempre	references/lens-questions-extended.md
L11	Pases separados: hechos, riesgos, alternativas, calidad de la revisión	Según el tipo	references/lens-questions-extended.md
L12	Cadena de causas desde el peor fallo hasta su elección de diseño raíz	Según el tipo	references/lens-questions-extended.md

Lentes "según el tipo", según el tipo de artefacto:

Tipo de artefacto	Añadir estos lentes
Diff pequeño o corrección de error	Ninguno
Diff de funcionalidad o plan de varios pasos	L6, L7, L12
Diseño, RFC o decisión entre opciones	L6, L7, L8, L11, L12
Salida de otra habilidad o agente	Usa la fila de lo que produjo

Lee el código real, la configuración o las líneas del plan de las que depende una preocupación. Una preocupación basada en una suposición sobre el código no es evidencia.

3. Filtrar

Aplica las cuatro pruebas a cada candidato. Descarta un candidato que falle en alguna.

1. Consecuencia: si nadie actúa sobre ello, ¿qué sucede realmente? "Nada importante" significa descartarlo.
2. Contraargumento: escribe la razón más sólida de que no es un problema real (el código ya lo cubre, está fuera de este cambio, o no causa daño). Si esa razón se sostiene, descártalo. Si la preocupación sobrevive, conserva el contraargumento y explica por qué falla.
3. Procesable: debe haber una acción concreta. Sin acción significa descartarlo.
4. No es un duplicado: descarta cualquier cosa ya reportada por otro paso de revisión en esta conversación, por el resumen del solicitante, o en el registro.

4. Calificar la gravedad

La barra es fija. El modo, la criticidad, la ronda y la presión de tiempo no la mueven.

• Crítico: indica un evento de fallo concreto: el desencadenante, cómo falla y hasta dónde se extiende el daño. El desencadenante debe ser alcanzable en la propuesta tal como está escrita. Si no se puede nombrar un desencadenante alcanzable, la preocupación es como máximo Alta. Ver references/severity-downgrade-example.md.
• Alto: un escenario realista nombrado en el que causa daño.
• Medio: vale la pena arreglarlo. No se necesita un evento de fallo.

Marca cada preocupación como bloqueante (debe solucionarse antes de que el trabajo continúe) o elemento de vigilancia (darle seguimiento, no detener el trabajo por ello).

5. Presupuesto

• Reporta cada Crítico y cada Alto por completo.
• Reporta los tres Medios principales por completo. Enumera cualquier otro Medio en una línea: la cuenta, luego una etiqueta corta para cada uno. Nunca elimines un Medio en silencio.
• Si Crítico más Alto es más de cinco, detén la revisión detallada. El veredicto es RETHINK, con una recomendación de dividir la propuesta en partes más pequeñas. Enumera solo los títulos de Crítico y Alto.

6. Registro de preocupaciones

Cada preocupación reportada tiene todos estos campos:

### H1: <título de una línea>
- Gravedad: Alta | Evento de fallo: <desencadenante> -> <cómo falla> -> <radio de explosión>
- Lente: L3 Suposiciones ocultas
- Contraargumento: <caso más fuerte contra la preocupación>. Falla porque <razón>.
- Evidencia: <archivo:línea | paso del plan | decisión citada>
- Si se ignora: <qué sucede>
- Acción: <el cambio concreto>
- Estado: bloqueante | elemento de vigilancia

Los IDs usan la letra de gravedad y un número: C1, H1, M1. Un ID nunca cambia, en ninguna ronda. Los registros Medios pueden escribir Evento de fallo: n/a.

7. Veredicto

Termina cada revisión con exactamente un veredicto:

• PROCEED (PROCEDER): sin preocupaciones bloqueantes. Pueden seguir notas.
• AMEND (ENMENDAR): el enfoque es sólido; soluciona primero las preocupaciones bloqueantes enumeradas.
• RETHINK (REPENSAR): un defecto fundamental, o se superó el presupuesto de la sección 5.

Debajo del veredicto, añade un encabezado Riesgos conocidos. Enumera cada preocupación cuya última fila del registro sea riesgo-aceptado, de cualquier ronda, con su ID, título y ronda. Si no hay ninguna, escribe "Riesgos conocidos: ninguno". Nunca bloquean.

8. Modo interactivo

1. Muestra el mejor caso (sección 1).
2. Antes de la primera pregunta, escribe los registros de preocupaciones y una fila de registro pendiente por cada preocupación a recorrer (ver la referencia de registro).
3. Plantea una sola preocupación por turno, la más grave primero. El usuario elige aceptar, rechazar, modificar, aceptar-riesgo o aplazar.
   • Si existe una herramienta de preguntas estructurada (AskUserQuestion en Claude Code, question en OpenCode), úsala, una preocupación por pregunta, con todo el registro en el texto de la pregunta para que permanezca en pantalla. Si la herramienta limita las opciones, ofrece aceptar, rechazar, aceptar-riesgo y aplazar, y toma modificar como texto libre.
   • Modificar: toma el cambio del usuario, luego trata la preocupación como aceptada en su nueva forma. Rechazar: la preocupación no aplica. Aceptar-riesgo: la preocupación es real, el usuario vive con ella, nadie la arregla ahora; no bloqueante. Aplazar: un elemento de vigilancia, para arreglar después.
   • Adjunta la fila del registro inmediatamente después de cada respuesta, antes de la siguiente pregunta. No esperes al veredicto.
4. Cuando cada preocupación tenga una resolución, ejecuta la nueva verificación (sección 11) en la ronda 2 y posteriores. Luego da el veredicto y los Riesgos conocidos (sección 7).
5. Si al menos una preocupación fue aceptada o modificada, escribe el plan revisado (sección 10), sea cual sea el veredicto.
6. Añade la línea del veredicto al registro. Detente y espera una instrucción explícita para continuar.

9. Modo informe

Sin preguntas. Sin esperas. Salida en este orden:

1. La suposición de criticidad, si se hizo una.
2. El mejor caso.
3. Todos los registros de preocupaciones, clasificados por gravedad, dentro del presupuesto.
4. El veredicto, con los Riesgos conocidos del registro.
5. DECISIONES ABIERTAS: una lista numerada. Formula cada elemento como una decisión que un humano pueda responder, luego la opción recomendada y su compensación: 1. <pregunta> (sobre C1) Recomendación: <opción>. Compensación: <costo o riesgo>.

Si el solicitante dio una ruta de archivo, escribe el informe completo allí. Devuelve solo un resumen de 200 palabras o menos: el veredicto, los recuentos por gravedad y los títulos de las DECISIONES ABIERTAS. Adjunta los registros y filas con resolución abierta (ver la referencia de registro). Luego detente. El modo informe nunca revisa el plan.

10. Plan revisado

Solo modo interactivo, después de que cada preocupación tenga una resolución. Escríbelo siempre que al menos una preocupación haya sido aceptada o modificada, sea cual sea el veredicto. Omítelo solo para PROCEED sin nada aceptado o modificado.

1. Vuelve a enunciar todo el plan con los cambios aceptados incorporados. No te limites a enumerar las resoluciones.

2. Añade una tabla de integración. Marca cualquier preocupación aceptada o modificada sin una línea coincidente como FALTANTE, y dilo encima de la tabla.

   Preocupación	Resolución	Línea del plan que la aborda
   C1	aceptada	Paso 3: añadir clave de idempotencia
   H2	modificada	FALTANTE

3. Detente. Espera una instrucción explícita para continuar. Esta habilidad nunca implementa.

11. Rondas y terminación

• Ruta del registro: ${XDG_STATE_HOME:-~/.local/state}/adversarial-review/<slug>.md. Lee references/ledger-format.md para el formato del slug y la fila antes de la primera escritura.
• El registro es de solo añadidura. Nunca edites ni elimines una fila anterior.
• Una preocupación está resuelta solo si su artefacto de resolución (SHA de commit o línea de plan) existe y cambios posteriores no lo han tocado.
• Inicia cada ronda posterior con una línea de encabezado: Ronda N | arrastrando abiertos: C2, H1 | nuevos la última ronda: 1 Crítico, 2 Alto
• La ronda 2 y posteriores revisan solo lo que cambió desde la última ronda y lo que ese cambio podría afectar. Un nuevo Crítico o Alto allí debe ser un comportamiento nuevo, en material cambiado, que realmente se activaría.
• No plantees de nuevo una preocupación registrada a menos que el cambio haya tocado la cosa que la resolvió, o una nueva verificación encuentre que empeoró.
• Nueva verificación de fin de ronda (ronda 2 y posteriores). Antes del veredicto, verifica cada preocupación cuya última fila sea aplazada, riesgo-aceptado, pendiente o abierta contra el artefacto y código actuales. Añade una fila cada una: todavía aplica, ya no aplica (con la razón), o empeoró (aumenta la gravedad y di por qué). Una preocupación que empeoró necesita una decisión nueva: recorrerla (interactivo) o listarla bajo DECISIONES ABIERTAS (informe). Nunca cambies filas antiguas.

Reglas de salida (estrictas)

Estas reglas anulan todo lo demás en esta habilidad.

1. Una ronda posterior que no añade ningún Crítico o Alto nuevo termina el bucle. El veredicto es PROCEED. Los Medios abiertos se convierten en elementos de vigilancia. Los Críticos o Altos arrastrados que aún están abiertos no son nuevos, pero aún bloquean: resuélvelos en esta ronda (interactivo) o lístalos bajo DECISIONES ABIERTAS (informe) antes de dar el veredicto.
2. Si la ronda 3 aún encuentra un Crítico nuevo, desafía cómo se divide el trabajo, no el código. Recomienda una división diferente.
3. Nunca ejecutes más de cuatro rondas. Después de la ronda 4, entrega cada bloqueador restante al usuario como una lista de decisiones numerada y detente.

12. Tono

• Directo y específico. Escribe "Esto falla cuando...", no "esto podría causar problemas potencialmente". Lidera con la preocupación más importante.
• Nombra el lente en cada preocupación, para que los lectores aprendan el método.
• Si la propuesta es buena, dilo claramente y da PROCEED.
• No inventes preocupaciones para parecer exhaustivo. Cada preocupación nombra un archivo, línea o paso de plan; un riesgo genérico sin ubicación se descarta.
• No reescribas el código bajo revisión. Describe el cambio; deja la escritura a quien actúe sobre él.