Revisión de código sobre el consumo de la salida

Revisar un cambio que usa la salida de un modelo es, sobre todo, seguir los campos. Se empieza en la línea donde llega la respuesta y se sigue cada campo hasta el sitio donde termina: una página, una consulta, un intérprete, una dirección, un registro. Esos sitios se llaman sumideros. Para cada uno se pregunta lo mismo: cómo interpreta el texto y qué control lo protege en ese contexto exacto.

Que el cambio valide la respuesta contra un esquema al principio es bueno, pero no responde a esa pregunta. Un esquema que dice «texto libre» deja pasar exactamente lo mismo que si no hubiera esquema, así que el control tiene que estar también en el sumidero.

De todos los sumideros, el peor es un intérprete de código: una función que toma un texto y lo evalúa como programa. Ahí no hay codificación que valga, porque el propósito de la función es precisamente ejecutar lo que recibe. Si la salida del modelo llega a un evaluador, cualquier cosa que el modelo escriba se ejecuta con los permisos de la aplicación. La alternativa casi siempre existe: una tabla de operaciones fijas que el modelo solo puede elegir por nombre, o un analizador limitado a lo estrictamente necesario.

Abre el cambio y localiza la función que evalúa como código un campo de la salida.

Con el método de la primera tarea, recorre el cambio línea por línea. Para cada línea donde se usa un campo de la salida, decide si su sumidero tiene el control adecuado: una consulta con parámetros lo tiene; un registro que guarda solo metadatos no expone nada; una asignación como marcado, una evaluación como código o una dirección de imagen tomada tal cual no lo tienen. Ayúdate del esquema para ver qué campos son de texto libre.

Cuenta las líneas que usan la salida en un sumidero sin el control que corresponde.

Una revisión también se revisa. El error más frecuente en cambios con modelos es aprobar con una justificación que suena razonable y es falsa, como suponer que lo que escribe el modelo es inofensivo porque lo genera nuestro propio sistema. Un comentario así no es solo un fallo puntual: enseña a todo el equipo una idea equivocada, y la próxima revisión la repetirá.

Lee los comentarios de la primera revisión y localiza el que aprobó una línea peligrosa con una justificación equivocada.

Al cerrar una revisión, el dictamen tiene que ser concreto: qué se aprueba, qué se pide cambiar y cómo. Aquí hay piezas bien hechas que conviene reconocer (la validación del esquema, la consulta con parámetros, el registro de metadatos) y tres sumideros sin control. Para el marcado, insertar como texto o sanear; para la evaluación, una tabla de fórmulas fijas, como ya pidió un revisor; para la imagen, aceptar solo direcciones de un dominio propio. Y una línea sin comentario también es un hallazgo: lo que nadie miró no está revisado.