Desacuerdo controlado: la receta mínima.

Se propone una ronda cuando la unidad de trabajo cruza la barra de impacto alto, definida por al menos uno de cinco criterios:

• Cambio de contrato o API entre componentes.
• Cambio de esquema de base de datos o migración.
• Seguridad, autenticación o autorización.
• Concurrencia, condiciones de carrera o transacciones.
• Lógica difícil de revertir o crítica para el negocio.

También cuando hay incertidumbre real: enfoques viables sin claro ganador, baja confianza leyendo el código, o un requerimiento ambiguo y caro de equivocar.

Se omite en cambios locales, reversibles, triviales o por plantilla. Y cada corrida requiere la aprobación explícita del desarrollador: nunca es automática.

El encabezado que se usó en la operación reportada, textual. Va sin tildes a propósito, por robustez de codificación al pasar por la shell:

Después van el contexto del sistema, el plan o el diff completo, los pedidos de ataque específicos del dominio, y el formato de salida: lista numerada con severidad, evidencia archivo:línea y qué cambiaría. La consigna de diff es la misma, aplicada al conjunto de cambios del árbol de trabajo.

El revisor ve el repositorio pero no la conversación del asistente principal: todo el contexto le llega, y solo le llega, por la consigna. Por eso hay que regenerarla después de cada decisión de producto intermedia, o va a objetar contra una versión que ya cambió.

El evento termina cuando cada hallazgo, individualmente, quedó en uno de estos tres estados. Nunca por consenso: el acuerdo entre dos asistentes que comparten datos de entrenamiento no vuelve verdadera una conclusión.

• Resuelto — corregido, con evidencia verificable del cierre.
• Refutado o descartado — con evidencia verificable: cita de código, medición o comportamiento documentado del entorno.
• Transferido al desarrollador — cierra el evento, pero deja el hallazgo abierto y con responsable.

La transferencia tiene cuatro estados terminales propios: deuda aceptada (registrada con identificador y justificación), riesgo aceptado (decisión explícita), mitigación parcial (parte aplicada, resto a deuda) y escalado pendiente (derivado sin decisión registrada, que no es un cierre).

Un archivo de texto versionado junto al código, con una entrada por ronda. El registro mínimo por hallazgo:

• Identificador y severidad.
• Evidencia citada.
• Veredicto del asistente principal tras verificar contra el repositorio.
• Estado de disposición (bloque 03).
• Autoridad que resolvió o aceptó el riesgo, y fecha.
• En una transferencia abierta, el destinatario responsable.

Esa bitácora es lo que sobrevive a la retención de los historiales de sesión, que se borran solos. En la operación reportada, once eventos que no se registraron en el momento hubo que reconstruirlos después.

• Las decisiones de producto. Requieren autoridad y responsabilidad humanas; no son un defecto que un revisor pueda encontrar.
• El descarte sin evidencia. Si no hay con qué refutarlo, el hallazgo se transfiere, no se descarta.
• Lo que no tiene oráculo ejecutable. Los hallazgos que dependen de contratos externos o del entorno real se transfieren al desarrollador.
• La última palabra. Incluso contra el revisor: en el corpus hay un veredicto negativo global que el desarrollador mantuvo por razones de producto, dejando constancia.

Y una advertencia que salió del caso más instructivo: una corrección derivada de un hallazgo es también código nuevo sin cobertura, y merece su propio ciclo o sus propias pruebas antes de darse por cerrada.