El método
Disensor es la implementación de referencia de un método: desacuerdo controlado. Esta página explica la idea. El contrato exacto, con las claves del esquema, los enums y las reglas del validador, vive en la referencia y en la guía de llenado.
El problema
Sección titulada «El problema»Un asistente de código que revisa su propio trabajo comparte los puntos ciegos del trabajo. Pedirle que se autocritique produce autocrítica, no revisión: los supuestos que no vio al escribir tampoco los ve al releer.
La respuesta del método es decorrelacionar. Que ataque un modelo de otra familia, cuyo entrenamiento y cuyos modos de fallar son distintos. Acá no sirve por más capaz. Sirve porque falla en otros lugares.
El ciclo
Sección titulada «El ciclo»- Genera. Un modelo produce el plan o el diff.
- Ataca. Un modelo de otra familia lo revisa con una consigna adversarial, cuyo hash queda registrado: cualquiera puede recomputarlo y ver qué se le pidió realmente al revisor.
- Verifica. El generador contrasta cada hallazgo contra el repositorio y lo lleva a un estado terminal: incorporado, deuda registrada, decisión del dueño, refutado o escalado sin resolver. Una refutación verificable tiene que traer evidencia; una interpretativa tiene que mirarla un humano.
- Declara. El ciclo cierra cuando todo hallazgo llegó a un estado terminal.
El paso interesante es el tercero. Un hallazgo del revisor no es automáticamente cierto: puede ser un falso positivo, y el método exige que la refutación traiga evidencia, no opinión. Cuando la refutación es interpretativa y no verificable, el artefacto obliga a que la mire un humano.
Esa exigencia es del método. Hasta dónde la hace cumplir el validador cambia con cada versión del esquema, y los límites conocidos se declaran en la referencia: no todo lo que el método pide es algo que una máquina pueda verificar.
La declaración de residuo
Sección titulada «La declaración de residuo»Lo que la herramienta define y hace cumplir es el artefacto con el que el ciclo termina: un JSON versionado en el repositorio, al lado del código que juzga.
Registra los actores y su familia, cada hallazgo con su estado terminal, las métricas del evento y el residuo, que es el bloque que le da nombre a todo: lo que el ciclo no pudo cerrar por sí mismo y descansa sobre el juicio de alguien.
Por qué residuo y no cobertura
Sección titulada «Por qué residuo y no cobertura»Es la decisión de diseño que ordena todo el resto.
Un artefacto que reportara cobertura se leería como un sello de calidad, y un sello de calidad invita a dejar de mirar. La declaración lista lo que el ciclo no pudo cerrar por sí mismo, con nombre y con la evidencia que haya. Dirige el escrutinio del revisor humano hacia los puntos donde el ciclo se quedó corto.
El residuo es más ancho que “lo que quedó abierto”. Un hallazgo que el generador
refutó con evidencia queda cerrado y aun así entra, porque la refutación es del
principal sobre el revisor y alguien tiene que poder auditarla. El residuo tiene
tres clases: escalado sin decisión, refutación del principal y gap de
ejecución. El esquema residue/v0.4 agrega dos más para los modos degradados,
reviewer_correlation y reviewer_hardening_gap, que registran las
limitaciones del revisor y no las del código.
Eso tiene un costo que el método acepta a sabiendas: una declaración honesta puede verse peor que una falsa. Más automatización no lo arregla, así que el método lo declara.
El límite
Sección titulada «El límite»El validador detecta el campo vacío y el marcador genérico. No detecta la declaración falsa, y ninguna herramienta puede. Alguien tiene que abrir PR ya mergeados al azar y leerlos.
El gate, además, corre dentro del workflow que audita. Esa frontera no la cruza ningún código propio; la resuelven la plataforma y el despliegue. Son cinco controles, y son requisito, no sugerencia:
- Un required check estricto, o una merge queue.
- CODEOWNERS sobre la configuración efectiva y sobre
.github/workflows/. - Un ruleset o required workflow definido fuera del repositorio auditado.
- El pin de la Action por SHA en lugar de por tag.
- Un bootstrap administrativo, porque el primer PR que agrega el gate no puede convertirse a sí mismo en raíz de confianza.
El porqué de cada uno está en requisitos de despliegue.
El paper
Sección titulada «El paper»Rocchia, N. (2026). Desacuerdo controlado: revisión adversarial automatizada con un segundo asistente de código en el desarrollo de software. DOI 10.5281/zenodo.21633495.
La terminología del paper es en español; el contrato del esquema y la CLI están en inglés desde la v0.2. La referencia incluye el glosario que mapea una cosa a la otra.