Revisar los serializadores de un proyecto entero

Un barrido empieza por las señales que cada framework deja en el código cuando el objeto se enlaza o se serializa sin elegir campos. En Django REST Framework, un serializador de modelo con fields = "__all__" toma todas las columnas; con exclude se convierte en una lista negada; con depth anida los objetos relacionados con todos sus campos. En Laravel, las señales son $request->all() o except hacia un modelo, $guarded (vacío o como lista negada) y forceFill. En JavaScript, copiar el cuerpo de la petición con Object.assign o con el operador de propagación.

Cada resultado se clasifica con tres preguntas: ¿la dirección es de entrada (escritura) o de salida (lectura)?, ¿quién llama a esa ruta?, ¿qué columnas tiene hoy el modelo? Un fields = "__all__" en una vista de solo lectura para personal interno pesa distinto que en una ruta pública o en una que escriben los socios.

Abre el laboratorio, entra en la carpeta pulsoandino-proyecto y cruza serializers.py con views.py y con modelos.txt. Empieza por la salida: busca el serializador de una vista pública cuya lista negada se quedó corta cuando el modelo creció.

Ahora la entrada. Busca la vista en la que escriben los socios y el serializador que usa. Revisa en modelos.txt qué campo de ese modelo decide algo que solo debería decidir la pasarela.

Abre respuesta-comentarios.json. La lista de campos del serializador de comentarios es explícita, y aun así el autor sale con correo, fecha de nacimiento y deuda.

Lee busqueda-patrones.txt con el criterio del cliente: las pruebas y las semillas se anotan, pero no entran en la lista de revisión. Lo que queda es el inventario que se entrega, aunque algún resultado resulte inofensivo al revisarlo.