Verificación por riesgo
Verificación por riesgo
Objetivos
- Aplicar la verificación que corresponde a cada nivel.
- Saber qué activa un verificador independiente y qué no.
- Preparar el traspaso a un verificador.
- Clasificar un hallazgo como bloqueo o aviso.
Los tres niveles
La verificación de un writer delegado sigue la misma regla con RDD activo o inactivo. El nivel se juzga por lo que toca el cambio:
| Nivel | Qué toca | Qué se hace |
|---|---|---|
| Passive | Documentación, imágenes o comentarios sin efecto ejecutable | Lectura estructural |
| Medium | Un cambio de comportamiento ordinario con pruebas enfocadas | Autoverificación del writer |
| High | Un punto de la lista de alto riesgo, nombrado | Autoverificación más un verificador independiente |
flowchart TD
A["Termina un cambio"] --> B{"¿Solo docs, imágenes<br/>o comentarios pasivos?"}
B -->|"Sí"| C["Lectura estructural"]
B -->|"No"| D["El writer ejecuta ## Verification<br/>y reporta comando y resultado"]
D --> E{"¿Se nombra un punto de alto riesgo?"}
E -->|"Sí"| F["Verificador independiente"]
E -->|"No"| G["La autoverificación es suficiente"]
C --> H["Comprobación del parent:<br/>reejecutar un comando"]
F --> H
G --> HEn todos los niveles
La comprobación del parent se mantiene siempre: volver a ejecutar un comando informado antes de entregar.
El verificador corre lo menos posible
La regla central es estrecha. El verificador independiente corre cuando, y solo cuando, el cambio toca un punto de alto riesgo y el parent lo nombra.
| Situación | ¿Agrega verificador? |
|---|---|
| El cambio toca un punto de alto riesgo nombrado | Sí |
| El cambio es muy grande | No |
El nivel nativo dice high sin punto nombrado | No: solo informa, y el parent nombra el punto si aplica |
| La evaluación falló o es desconocida | No |
| El cambio no está claro | No, hasta que el parent nombre el punto que aplica |
| Lo escribió un modelo pequeño | No |
Con la CLI, nombrar el punto se hace así:
gentle-ai review assess --cwd <repo> --agent <runtime> --json \
--escalate-item 2 --escalate-reason "cambia la validación del token de sesión"Cuándo corre: al final o por unidad
Cuando se escribieron inline varias entregas de una feature, corre un verificador al final de la feature, no uno por entrega. Se verifica por unidad solo si esa unidad nombra un punto de alto riesgo, ya sea en su línea Risk o en el escalamiento sobre su diff real.
Los límites de corrección
flowchart LR
A["Bloqueos del verificador"] --> B["Un lote que corrige<br/>todos los bloqueos"]
B --> C["Una recomprobación<br/>limitada a esos bloqueos"]
C --> D{"¿El mismo bloqueo sigue fallando?"}
D -->|"No"| E["Listo"]
D -->|"Sí"| F["Una segunda corrección"]
F --> G{"¿Sigue abierto?"}
G -->|"No"| E
G -->|"Sí"| H["Un resultado<br/>Needs your decision"]- La recomprobación no es un barrido nuevo.
- Un hallazgo nuevo no da derecho a una segunda corrección.
- La autorrevisión de un writer sigue el mismo límite, y luego informa
partial.
Preparar a un verificador
El traspaso es una lista exacta:
- El documento de feature completo, con todas las
S#y no una sola tarea. - El commit base.
- Las formas de los comandos de sondeo.
Si no hay documento de feature, se pasa el pedido textual.
Sondas derivadas de la especificación
El contrato del verificador de OpenCode empieza con una frase que resume su actitud: verificar el pedido, no el trabajo del writer. Las pruebas y ejemplos del writer no son evidencia de corrección, porque una prueba del writer puede fijar un defecto.
Debe cubrir:
| # | Elemento | Qué hace |
|---|---|---|
| 1 | Sondas propias | Deriva ejemplos positivos, casos negativos y límites a partir del pedido textual y de cada regla numerada |
| 2 | Invariantes | Los datos quedan idénticos byte a byte tras un comando rechazado, comprobado con hash. Los comandos previos dan la misma salida que en la base |
| 3 | Interacciones | Los datos nuevos fluyen por reportes, totales y exportaciones existentes |
| 4 | Build y alcance | Corre el chequeo de tipos o el build si existe, y marca lo que está fuera del pedido |
| 5 | Todos los elementos | Un veredicto por cada S#: cumplida, no cumplida o no implementada. Lo no verificado cuenta como no cumplido |
| 6 | Sondas duraderas | Devuelve las sondas como pruebas listas para commit, que el writer incorpora. El verificador nunca las escribe |
Dónde corren las sondas
En el primer lanzamiento, sin esperar otra autorización, dentro de una copia nueva creada con mktemp -d bajo el directorio temporal del sistema. Nunca dentro del espacio de trabajo, donde no debe dejar archivos nuevos.
Los ejemplos de la especificación que mutan datos corren solo sobre estado aislado. Los ejemplos autorizados por el parent son los únicos comandos del espacio de trabajo además de esas sondas.
Severidad
flowchart TD
A["Hallazgo"] --> B{"¿Silencia una opción explícita con éxito,<br/>o cambia salida existente sin pedirlo?"}
B -->|"Sí"| C["Bloqueo, siempre"]
B -->|"No"| D{"¿Se reproduce con entrada realista?"}
D -->|"No, valor fuera de dominio"| E["Aviso"]
D -->|"Sí"| F{"¿Ya se reproducía en la base?"}
F -->|"Sí"| E
F -->|"No"| C| Hallazgo | Severidad |
|---|---|
| Defecto causado por el cambio, reproducido con entrada realista | Bloqueo |
| Elemento de especificación sin cumplir | Bloqueo |
| Ignorar en silencio una opción explícita, devolviendo éxito | Bloqueo, siempre |
| Cambiar salida existente que nadie pidió cambiar | Bloqueo, siempre |
| Defecto que ya existía en la base | Aviso |
| Valor fuera de dominio | Aviso |
El verificador debe reproducir un posible bloqueo en la base antes de llamarlo así.
El contrato de comprobación
Reglas complementarias que aplican a toda verificación:
- Un documento o imagen pasivo no necesita un subagente semántico artificial.
- El contenido activo, mixto, operativo, ejecutable o desconocido recibe verificación funcional.
- Una comprobación rápida aplicable corre una vez.
- El trabajo largo recibe una estimación de costo y efectos antes de lanzarse.
- Un verificador no disponible se informa como no disponible: no se simula ni se reintenta sin fin.
- El resultado de una comprobación nunca autoriza la entrega.
La forma reducida
Algunos runtimes no tienen subagentes, así que no hay writer ni verificador separados. El orquestador hace la acción y su propia verificación, y usa el nivel nativo:
| Nivel | Conducta |
|---|---|
| Passive | Lectura estructural. No se ejecutan los comandos de ## Verification |
| Medium o high | Se ejecutan esos comandos exactos, en primer plano, y se informa el resultado |
Una evaluación fallida no significa lo mismo en todos los contextos
Aquí hay una diferencia que conviene tener presente:
| Contexto | Si review assess falla |
|---|---|
| Verificador independiente con delegación disponible | Solo informa. La autoverificación del writer se mantiene y no se agrega verificador |
| Forma reducida, sin delegación | Se trata como high y se ejecutan los comandos de verificación |
| Preflight de revisión RDD | Nunca baja el nivel: el commit se trata como debido y se ejecuta el STATUS de preflight |
En los tres se mantiene la misma regla: nunca se deduce riesgo bajo a partir de una evaluación fallida.
Actividad
Toma una función con persistencia en tu proyecto y escribe cuatro sondas para un cambio hipotético: un caso positivo, un límite, una entrada rechazada con comprobación de hash y un comando existente comparado con la base. Indica en qué copia temporal correrían.
Autoevaluación
-
Un cambio de 1200 líneas de comportamiento ordinario sin puntos de alto riesgo recibe:
- A. Un verificador por ser grande
- B. Dos verificadores en paralelo
- C. Autoverificación del writer, sin verificador
- D. Solo lectura estructural
-
Tras la recomprobación aparece un hallazgo nuevo. ¿Da derecho a una segunda corrección?
- A. Sí, si es grave
- B. No: la segunda corrección es solo para el mismo bloqueo que sigue fallando
- C. Sí, automáticamente
- D. Solo si lo aprueba otro verificador
-
Un comando acepta
--dry-run, lo ignora y devuelve éxito. ¿Cómo se clasifica?- A. Bloqueo, siempre
- B. Aviso, porque no lanza error
- C. Depende del tamaño del diff
- D. No se considera defecto
-
¿Dónde corre un verificador sus sondas?
- A. En el espacio de trabajo, para ahorrar tiempo
- B. En producción
- C. En una rama nueva del repositorio
- D. En una copia creada con
mktemp -d, fuera del espacio de trabajo
Respuestas
- C. El tamaño no agrega un verificador.
- B. “A new finding never earns one.”
- A. Es uno de los dos casos que siempre son bloqueo.
- D. No debe dejar archivos nuevos en el espacio de trabajo.
Lista de control
- Sé qué nivel corresponde sin fijarme en el tamaño.
- Solo pido un verificador cuando puedo nombrar el punto.
- Entrego el documento completo al verificador.
- Aplico los límites de corrección sin ciclos adicionales.
- Clasifico hallazgos reproduciéndolos antes en la base.
Fuentes
internal/assets/skills/_shared/odd-orchestrator-sections.md, internal/assets/opencode/agents/gentle-ai-verify.md, internal/components/agentguidance/routing.go, odd/tasks/verify-always-rdd-high.md, docs/review-integration.md.