docs: añadir sección de bugs reales al README

README.md

@@ -103,3 +103,7 @@ Pendiente — requieren cuenta/credenciales externas propias, aplazados delibera
 - [ ] (Stretch) Endpoint que categorice un gasto automáticamente llamando a un LLM (necesita API key propia)
 
 Cada uno de estos pendientes debería vivir como un issue individual en GitHub, con su propia rama y PR, para que el historial del repo muestre trabajo incremental.
+
+## Bugs reales encontrados construyendo esto
+
+1. **`ExpenseUpdate.date` solo aceptaba `null`** — `PATCH /expenses/{id}` rechazaba con 422 cualquier intento de cambiar la fecha de un gasto. Causa: para una asignación anotada dentro del cuerpo de una clase (`date: Optional[date] = None`), Python guarda el valor de la derecha (`None`) bajo el nombre `date` en el namespace de la clase *antes* de evaluar la anotación `Optional[date]` — así que cuando la anotación se evalúa, `date` ya no apunta al tipo `datetime.date` importado, apunta a `None`. `Optional[None]` colapsa a `NoneType`, y por eso el schema de OpenAPI generado mostraba `"date": {"type": "null"}` en vez de una unión real de fecha/null. Solo ocurre porque `ExpenseUpdate.date` tiene un valor por defecto (`= None`) — `ExpenseCreate.date` y `ExpenseRead.date`, campos obligatorios sin default, nunca lo sufrieron, y esa asimetría es lo que lo hizo fácil de pasar por alto. Detectado desde el cliente tipado del frontend (`openapi-typescript` generaba `date?: null`, que no compilaba contra una fecha real) — ningún test existente lo capturó, porque `update_expense` solo estaba testeado con mocks que construyen `ExpenseUpdate` directamente en Python, sin pasar por la capa HTTP+Pydantic donde vivía el bug real. Arreglado importando el tipo bajo alias (`from datetime import date as date_`) y añadiendo `tests/integration/test_expenses.py` con este caso como regresión explícita.