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 —claves del esquema, enums, reglas del validador— vive en la referencia y en la guía de llenado, que se bajan del último tag publicado de la herramienta.
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. No porque sea más capaz, sino 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 —con evidencia si es verificable, con atención humana si es interpretativo— o escalado sin resolver.
- 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.
La declaración de residuo
Sección titulada «La declaración de residuo»Lo que la herramienta define y hace cumplir no es el ciclo, 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 bloque que da nombre a todo— el residuo: 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 hace lo contrario: 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.
No es lo mismo que “lo que quedó abierto”. Un hallazgo que el generador refutó con evidencia queda cerrado y aun así entra al residuo, 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.
De ahí sale una propiedad incómoda y deliberada: una declaración honesta puede verse peor que una falsa. El método no la resuelve con más automatización, porque no se puede. La resuelve diciéndolo en voz alta.
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. El muestreo humano de PR cerrados sigue siendo la única defensa real contra el cumplimiento cosmético.
Del mismo modo, el gate 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: required check estricto (o
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, y un
bootstrap administrativo, porque el primer PR que agrega el gate no puede
convertirse a sí mismo en raíz de confianza. La lista con su porqué 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.