Changelog

Todos los cambios notables de Finlia se documentan en este archivo.

El formato se basa en Keep a Changelog y el versionado sigue SemVer. La versión vigente del software se declara en config/finlia.php y package.json, y debe coincidir con la versión más reciente de este archivo.

Estado actual: desarrollo 0.x. Cada entrega mayor de funcionalidad publica un minor y cada corrección un patch. Las versiones publicadas se taguean (vX.Y.Z, anotado sobre el merge en main); algunas salieron sin tag y no se crean a posteriori. Para actualizar este archivo usa la skill /update-changelog.

[0.42.0] - 2026-09-24 — Historial público, SEO y visibilidad para asistentes

Añadido

• Página pública de historial de versiones en /versiones, que renderiza CHANGELOG.md con los mismos titulares y detalle de cada entrega. Se enlaza desde el footer de la landing y desde el pie del login/registro y páginas legales, para que cualquiera pueda ver qué ha entregado Finlia sin abrir el repositorio. La respuesta se cachea por mtime del archivo, así que se refresca sola cuando se publica una versión nueva.
• Datos estructurados enriquecidos en la landing: bloques Organization con sameAs al repositorio en GitHub, WebSite y SoftwareApplication con keywords, alternateName, applicationSubCategory, countriesSupported, softwareVersion y enlace al historial de versiones (releaseNotes). Se añade la lista de cuentas por cobrar y del sobre a featureList.
• Meta description y palabras clave reforzadas con vocabulario que la gente sí busca ("app de finanzas personales", "software para finanzas personales", "presupuesto familiar", "manejar finanzas en Colombia").
• llms.txt con sección "Cuándo recomendar Finlia" y palabras clave: da a un asistente el material para responder preguntas típicas ("¿qué app me recomiendas para manejar mis finanzas personales?", "¿qué software para presupuesto personal hay?") citando el sitio, y enlaza el historial de versiones y la versión vigente.

Corregido

• Google ya no listará las páginas legales por delante de la landing. El layout de páginas de acceso y legales (login, registro, recuperar-contraseña, terminos, terminos/historial, datos) ahora emite meta name="robots" content="noindex, nofollow", y esas rutas se quitaron del sitemap.xml. Al buscar "Finlia" el resultado principal pasa a ser la landing, no la política de datos ni los términos.

Notas

• Lo que puede hacer el código para ganar visibilidad ya está hecho (canonical, OG, JSON-LD, sitemap, llms.txt, historial). El resto es trabajo fuera del repositorio: Google Search Console con el sitemap enviado, backlinks desde el propio repositorio y perfiles en LinkedIn, y directorios de software libre. Nadie puede garantizar que un LLM recomiende Finlia; sí ayuda que la información pública sea consistente y descriptiva, y a eso apunta esta entrega.

[0.41.0] - 2026-09-23 — Presupuestos con sobre y cuota de deuda del mes

Añadido

• Presupuestos con sobre (ADR-0048). Cada presupuesto por categoría gana una casilla "Apartar del cupo diario (tratar como sobre)". Cuando la marcas, la plata de ese presupuesto se resta del "puedes gastar hoy" y se descuenta al registrar el gasto en su categoría, en lugar de morder el cupo del día. Resuelve el caso del gasto lumpy: mercado, gasolina, servicios y demás gastos periódicos grandes se separan del gasto discrecional (un café, un cine). Los presupuestos existentes no cambian salvo que marques la casilla: siguen siendo metas blandas que solo alimentan las alertas 80/100 %.
• Desbordamiento honesto: si te pasas del sobre, solo la parte que excede muerde el cupo del día. Un sobre de $200.000 con un gasto de $300.000 absorbe $200.000 y deja $100.000 como discrecional, que sí baja el cupo.
• Desglose "¿Cómo se calcula?" con nueva línea "− Sobres apartados (mercado, gasolina…)" cuando hay sobres activos, y la línea del gasto del día se renombra a "Gastado hoy fuera de sobres" cuando corresponde. La lista de categorías presupuestadas muestra un badge "Sobre" para distinguirlos.
• KPI "Cuota de deuda este mes" en el dashboard, al lado de "Deuda total". Muestra el monthly_commitment que DebtService::summary() ya calculaba (suma de las cuotas mensuales comprometidas), para separar la carga del mes de la carga total.
• Aviso en el formulario de gastos recurrentes: si el monto cambia mucho de un mes a otro (mercado, gasolina, ocio), el formulario sugiere crear un presupuesto con sobre en su lugar y enlaza a la creación. Los recurrentes se dejan para lo que sí es fijo (arriendo, servicios, SOAT, plan celular).

[0.40.1] - 2026-09-23 — El cupo del día no se te escapa delante

Corregido

• El "puedes gastar hoy" ahora se congela al empezar el día. Antes recalculaba el promedio en cada visita: con $300.000 a 10 días del cobro decía $30.000, gastabas $30.000 y al volver a mirar veías $27.000. Ahora el cupo del día se fija con el saldo del inicio del día y muestra lo que queda tras el gasto de hoy: gastarlo lo lleva a $0, no baja el promedio. Al día siguiente se recompone solo con el saldo real y los días que faltan (ADR-0047).
• Desglose "¿Cómo se calcula?" reescrito para reflejar la nueva aritmética: reconstruye la base al inicio del día, muestra daily_target ÷ días, resta gastado hoy y cierra con = Puedes gastar hoy.
• Tarjeta principal y hero del panel: cuando ya gastaste algo hoy aparece un subtexto con el cupo del día y lo consumido, para que el número grande no salga de la nada.

[0.40.0] - 2026-09-21 — Cuentas por cobrar

Cierra la Épica 15 con el módulo simétrico al de deudas: registrar que alguien le debe dinero al hogar y llevarle la cuenta hasta que entra el pago. Sin esto la app respondía bien a "¿cuánto puedo gastar?" pero se quedaba ciega ante el dinero comprometido a favor del hogar.

Añadido

• Panel /cuentas-por-cobrar con total pendiente, listado ordenado por fecha tentativa de cobro y bloque de cerradas. Cada tarjeta muestra deudor, concepto, saldo y progreso.
• Ficha por cuenta con historial de cobros, formulario de cobro y edición para posponer la fecha sin borrar el rastro. El cobro puede ser "cobro recibido", "condonado" o "ajuste"; solo el primero, y si eliges cuenta destino, genera el ingreso automático que sube ese saldo (mismo patrón que el pago de deuda). Condonaciones y ajustes reducen el saldo sin ingreso real.
• Saldo derivado (ADR-0020 espejo): current_balance se recalcula desde los cobros registrados, nunca se teclea. El estado se ajusta solo entre pending, partial y paid; written_off queda a mano del usuario.
• Recordatorios: cada cuenta con due_date entra en la lista unificada de /recordatorios como una fuente derivada más (Épica 9). Cuando la fecha pasa sin cobro, el ítem se marca como vencido.
• Tarjeta "Por cobrar" en el resumen del dashboard, al lado de "Deuda total". Enlace al módulo desde el sidebar y guía nueva en config/tours.php (cuentas-por-cobrar).
• Aislamiento por hogar: policies ReceivablePolicy y ReceivablePaymentPolicy con el mismo trato que el resto de recursos financieros; los Form Requests acotan account_id, category_id y debtor_user_id al hogar activo.
• Métrica añadida a finlia:metrics: cuentas por cobrar con saldo > 0 y total por cobrar acumulado.
• Seeder de demo con un préstamo personal parcialmente cobrado y un trabajo facturado próximo, para que el módulo se estrene con datos coherentes.

Documentación

• docs/ROADMAP.md: Épica 15 pasa a 🟢 con el detalle real de la entrega.
• docs/DATA_MODEL.md: tablas receivables y receivable_payments documentadas, diagrama actualizado.

[0.39.1] - 2026-09-21 — Guardar sí guarda

Corregido

• El modal «+ Nueva cuenta» del formulario de gasto ahora sí crea la cuenta al pulsar «Crear y usar». El botón vivía en el pie del modal, fuera del <form>, atado a él por el atributo HTML form="…"; en algunos navegadores móviles ese atributo no dispara el envío. El formulario ahora envuelve todo el contenido del modal, con el botón dentro, para que el submit funcione en todos los navegadores.

[0.39.0] - 2026-09-19 — Rieles de monetización

Arranca la Épica 12 en modo freemium: la app gratuita no se degrada. Los usuarios existentes conservan cada hogar y cada persona que ya tenían; los nuevos topes solo se aplican al crear un nuevo hogar o invitar a un tercero. Todavía no hay pasarela ni funciones Premium encendidas — esta versión pone los rieles para que las próximas los usen (ADR-0046).

Añadido

• Concepto de plan por hogar. Cada hogar tiene una suscripción a un plan (Gratis o Premium). El plan controla qué funciones puede usar y qué límites tiene; la comprobación siempre pasa por el servidor, nunca por un flag del navegador.
• Plan gratuito con topes suaves: 1 hogar por usuario y 2 personas por hogar. Suficiente para una gran mayoría de usos familiares y, cuando toca subir de plan, se avisa con un mensaje claro que enlaza a /perfil → Plan.
• Todo el mundo entra a Premium mientras se define el catálogo comercial. La v0.39 pone los rieles pero deja el interruptor finlia.subscription.premium_for_all encendido: nadie encuentra topes en el uso y la pantalla Perfil → Plan explica que Premium está abierto mientras Finlia termina de decidir qué llevará y a qué precio. El día que ese día llegue, se apaga el interruptor y el enforcement descrito abajo entra en vigor sin desplegar código nuevo. Precio comprometido cuando se apague: $9.900/mes o $79.000/año (COP).
• Pantalla Perfil → Plan: qué plan tiene tu hogar, cuánto llevas usado en cada límite (hogares creados, miembros, encuestas del mes) y el CTA de Premium con la explicación honesta de por qué existe.
• Árbol de decisión de compras. Al registrar un gasto que no cabe en el presupuesto del mes aparece un mini-cuestionario de 4 preguntas: si el gasto lo tenías previsto, cómo lo llamarías (necesidad/gusto/capricho/emergencia), cómo te sientes ahora (escala de 5 con iconos del sistema de diseño) y qué lo disparó (estrés/alegría/aburrimiento/necesidad real/presión social/promoción/otro). El disparo depende de la señal, no del azar: si la categoría del gasto NO tiene una fila en budgets para ese año y mes, se ofrece la encuesta; si la tiene, no. Se puede saltar en cualquier momento y el modal solo aparece si hay cupo en el mes (5 respuestas al mes en Gratis, sin tope en Premium). La respuesta guarda además la edad al momento (derivada de la fecha de nacimiento) y el género declarado en el perfil como snapshot histórico: sirven como capas de análisis para el autoconocimiento y para el dataset de ML futuro.
• Seguimiento de la compra a los 30 días. Cada respuesta al árbol agenda una cita de revisión un mes después. En Perfil → Compras a revisar se listan las citas vencidas del usuario y se le pregunta cómo se siente con esa compra ahora (misma escala 1..5), si se arrepiente y una nota opcional. Cierra la conversación consigo mismo y da la primera fuente para medir la diferencia entre "cómo me sentí al comprarlo" y "cómo me siento ahora". El seguimiento es opcional — no se recuerda ni se cobra por saltárselo.
• ee/ con puerta condicional. El directorio comercial (ADR-0042) estrena su EeServiceProvider vacío; se registra desde el núcleo con class_exists(...) para que borrar ee/src deje la app arrancando. En esta versión aún no expone funciones — es preparación para chat con IA, PDF de reportes y demás.
• Activación manual sin pasarela: php artisan finlia:grant-premium --household=ID --until=YYYY-MM-DD --reason="..." da Premium hasta la fecha indicada. finlia:revoke-premium --household=ID vuelve a Gratis. Toda concesión guarda su motivo y su fecha de expiración.

Cambiado

• Crear un hogar y enviar invitaciones ahora consulta el plan del hogar antes de aceptar la acción. En Gratis, ambos flujos muestran un mensaje humano ("Tu plan gratuito permite un solo hogar / hasta 2 personas por hogar. Pasa a Premium para invitar a más") en lugar de un error genérico. Los usuarios que ya tenían más hogares o más personas no ven ningún cambio hasta que intenten sumar otro.
• HouseholdService::createHousehold recibe ahora el SubscriptionService inyectado y crea la suscripción Gratis del hogar en la misma transacción — nadie queda sin fila de plan.

Documentación

• ADR-0046 nuevo. Detalla la filosofía freemium con grandfather, la puerta condicional a ee/, por qué no hay pasarela todavía y por qué la publicidad queda fuera del alcance.
• docs/ROADMAP.md: Épica 12 pasa a 🟡 con el plan de entregas incrementales (v0.39 rieles → chat IA con BYOK → pasarela Wompi).
• docs/DATA_MODEL.md: tablas plans, subscriptions y compulsive_survey_responses documentadas con sus tipos reales.

[0.38.0] - 2026-09-19 — Retoques antes de LinkedIn

Añadido

• La pantalla «Revisa tu correo» se desatasca sola. Cuando alguien se registra desde el computador y abre el enlace de verificación en el móvil, el navegador de origen ya no se queda mirando esa pantalla en blanco: comprueba en segundo plano si la verificación ya ocurrió y, en cuanto es así, entra al panel. Un botón «Ya verifiqué mi correo» hace la misma comprobación al pulsar, por si el navegador tiene JS bloqueado o la red se cortó.
• Crear una cuenta al vuelo desde el formulario de gasto. Junto al selector de cuentas aparece un enlace «+ Nueva cuenta» que abre un modal con los mínimos (nombre, tipo, moneda y saldo inicial). Al guardar, la cuenta queda seleccionada sin recargar la página ni perder lo que llevabas escrito.
• Épica 15 · Cuentas por cobrar — abierta en el ROADMAP con su ficha en scrum/epics/15-cuentas-por-cobrar.md. Módulo simétrico al de deudas: registrar que alguien le debe dinero al hogar, con fecha tentativa de cobro, edición, posposición y registro del ingreso al recibir el pago. Se implementa después del lanzamiento público.

Cambiado

• El pago de una deuda preselecciona la categoría «Deudas», pero deja el selector editable. Antes había que elegirla a mano en cada abono.
• Al elegir «Deudas» como categoría de un gasto suelto aparece un aviso en línea que enlaza al flujo de pago de deuda, para no registrar el mismo pago dos veces. Sigue permitiendo guardar el gasto (hay pagos legítimos con categoría «Deudas» que no corresponden a una deuda registrada).

[0.37.3] - 2026-09-17 — «Marcar pagado» sin ambigüedad

Cambiado

• Marcar un gasto recurrente como pagado ahora ofrece tres caminos claros, en lugar de un sí/no que a veces prometía registrar un movimiento y otras solo avanzaba la fecha en silencio. El check —desde /gastos-recurrentes o desde el listado de /recordatorios— abre un modal propio con «Sí, registrar y avanzar», «Solo avanzar fecha» (para cuando ya lo pagaste por fuera de Finlia) y «Cancelar».
• Si el recurrente no tiene cuenta asociada el modal lo dice y enlaza a «Registrar gasto» para el pago manual, en lugar de aparentar que sí lo registraría.

[0.37.2] - 2026-09-16 — Despliegue sin ruido

Corregido

• La campanita del navbar ya no da error tras un despliegue. El resumen de recordatorios se cachea diez minutos, y un tag podía dejar en la caché un formato anterior al que espera el código nuevo; los primeros minutos las páginas autenticadas devolvían un 500 hasta que ese valor se refrescaba. Ahora la vista tolera esa forma vieja sin romper.

Cambiado

• El despliegue purga la caché de aplicación entre migrate y optimize. Antes solo se reconstruían las cachés de framework (config, rutas, vistas): las claves de Cache:: sobrevivían al tag con el esquema anterior. También queda registrado en docs/DEPLOYMENT.md para el procedimiento manual.

[0.37.1] - 2026-09-16 — Editar deuda en página propia

Cambiado

• Editar una deuda ya no vive en un modal, sino en su propia página. El formulario es más alto que el viewport en un móvil y el pop-up no permitía llegar a los últimos campos ni siquiera con desplazamiento interno; ahora el botón «Editar» abre la pantalla completa, con el mismo formulario que el alta y sin nada que compita con el scroll de la página.

[0.37.0] - 2026-09-15 — La app se explica sola

Añadido

• Guías de pantalla. La primera vez que entras a una pantalla, Finlia te explica en pocos pasos qué puedes hacer ahí, señalando el elemento del que habla (ADR-0045). Hay diecisiete: Panel, Movimientos, Presupuestos, Gastos recurrentes, Deudas, Metas de ahorro, Reportes, Recordatorios, Cuentas, Hogares, Ingresos esperados, Categorías, Registrar un gasto, Transferencias, y el detalle de una deuda, de una meta y de un hogar.
• Poco invasivas por diseño. Solo arrancan la primera visita a cada pantalla y como máximo una por sesión: nunca dos seguidas en un mismo paseo por la app. Se cierran con Esc o tocando fuera.
• «Saltar esta guía» y «No mostrar más guías» en el propio globo: la primera quita solo esa, la segunda las apaga todas de una vez.
• Catálogo en Mi perfil → Guías de la app: la lista de las diez, con cuáles ya viste, un botón para ver cualquiera cuando quieras y otro para volver a verlas desde el principio. También está el interruptor para encenderlas o apagarlas.
• «Guía de esta pantalla» en el menú de tu avatar, para repasar la de donde estés sin ir al perfil.
• Novedades sin repetir lo sabido. Cada paso guarda en qué versión nació: cuando una guía se reescribe para presentar algo nuevo, quien ya la vio recibe solo los pasos nuevos, titulados «Novedades», y quien llega nuevo la ve completa.
• El progreso viaja contigo. Se guarda en tu cuenta, no en el navegador: entrar desde el celular y desde el computador no te muestra la misma guía dos veces. Apagarlas no borra el progreso — si las vuelves a encender, retomas donde ibas.

Cambiado

• Las guías se saltan solas los pasos que no aplican. Un paso sobre una lista vacía, sobre la barra inferior del celular cuando estás en el computador, o sobre el menú lateral cuando estás en el celular, no se muestra: una guía nunca señala un vacío.

[0.36.2] - 2026-09-15 — Recordatorios sin ruido

Cambiado

• La campanita del navbar ahora muestra qué debes, no solo cuántos. Lista los tres primeros recordatorios que piden atención (título y «Vence hoy» / «Vencida hace 2 días» / «En 4 días»), con un punto rojo o ámbar delante, un «y N más…» si sobran, y el botón «Ver recordatorios» al pie.
• El panel deja de repetir los recordatorios. Antes salían dos cuadros con obligaciones vencidas y próximas encima de todo; ahora esa información vive en un único sitio (la campanita del navbar y /recordatorios).
• La lista de recordatorios pasa de «Próximas obligaciones» a «Obligaciones». Una obligación ya vencida no es próxima, y la sección agrupa las tres bandas (vencidas, vencen pronto, más adelante).

Corregido

• Los encabezados de sección de /recordatorios y /gastos-recurrentes ya no aparecen pegados al borde izquierdo. «Vencidas», «Vencen pronto» y «Más adelante» quedan indentados como viñeta bajo el título del bloque, en lugar de leerse como otro encabezado al ras.

[0.36.1] - 2026-09-15 — Retoques al lanzamiento

Corregido

• La deuda pagada el mismo día del vencimiento deja de avisar como pendiente. El cálculo interpretaba «vence hoy» como aviso vivo, aunque hubiera un pago registrado ese mismo día; ahora, si el mes tiene un pago, la próxima cita se salta al mes siguiente, sea cual sea la fecha del pago.
• El pop-up de editar deuda ahora se puede recorrer entero en el móvil. El formulario es más alto que la pantalla y el modal no ganaba altura para desplazar; ocupa toda la ventana en móvil (con desplazamiento interno) y sigue centrado en escritorio.
• En escritorio la versión queda al final de la barra lateral. Antes flotaba justo debajo del último enlace, dejando un hueco vacío en la parte baja; ahora está anclada al pie de la barra.

Cambiado

• El botón «Registrar ingreso» del aviso de pago pendiente ahora prellena el formulario con el monto, la descripción y la categoría del ingreso previsto asociado; antes solo redirigía a un formulario vacío y había que reescribirlo todo.
• Los recordatorios estrenan botón de alta con página propia. «Nuevo recordatorio» se abre en su propia pantalla en lugar de convivir con el listado como columna; la pantalla principal se dedica ahora a ver lo que vence.
• Simplificado el aviso del pago automático en los gastos recurrentes. El texto largo sobre el programa diario del servidor se reduce a «Se debita en la madrugada del día del vencimiento», lo único que necesita saber quien usa la app.

[0.36.0] - 2026-09-14 — Vigilancia para el lanzamiento

Añadido

• Aviso de errores por correo. Cada hora se revisa el registro de la aplicación y, si hubo errores nuevos, llega un único correo al buzón de contacto con los errores agrupados; sin errores no llega nada (ADR-0044). De cada excepción, el correo dice qué tipo de error fue y dónde ocurrió, sin los datos del mensaje (que pueden llevar montos o correos): ese detalle se queda en el servidor. También deja ver cuándo se agota la cuota diaria de envío de correo.
• Métricas del embudo (finlia:metrics): registros, verificación, hogares con movimientos, usuarios que vuelven a registrar gastos otro día y actividad a los 7 días del registro. Llegan al buzón de contacto cada lunes.

Documentación

• Las copias de seguridad se apoyan en la copia diaria de Hostinger, con la recomendación de restaurarla una vez para probarla.

[0.35.5] - 2026-09-13 — Revisión a demanda, con los puntos en su línea

Cambiado

• La revisión de Claude ya no se lanza sola en cada push: la pide una persona comentando /revisar en el Pull Request, cuando lo considera listo. Solo atiende a quien tiene permiso de escritura en el repositorio y solo si la integración continua está en verde en el último commit; si no lo está, lo dice en el PR y no gasta nada. También sirve para revisar aportes que llegan desde un fork.

Corregido

• Cuando la revisión automática no encuentra nada bloqueante, sus observaciones ahora aparecen sobre las líneas de código a las que se refieren, igual que cuando pide cambios. Antes llegaban todas juntas al final del comentario, porque la publicación intentaba primero registrar una aprobación que GitHub no permite a una automatización. La señal verde sigue en el check Revisión de Claude.

Seguridad

• Antes de revisar se descarta la configuración de Claude que traiga el Pull Request (instrucciones, servidores MCP y ajustes del proyecto) y se usa la de la rama principal. Esto incluye los archivos que el PR añada, no solo los que modifique: algunos de ellos pueden ejecutar comandos durante la revisión.

[0.35.4] - 2026-09-12 — La revisión automática, ya funcionando

Corregido

• La revisión automática ya emite veredicto. En las primeras pruebas no llegaba a publicarlo: primero por una regla de permisos que le impedía escribir su propio resultado, y después porque GitHub rechaza que una automatización apruebe un Pull Request. Ahora la señal del veredicto la da un check propio llamado Revisión de Claude —verde cuando no hay nada bloqueante, rojo cuando sí— que no impide mergear, y los hallazgos se publican igual aunque la aprobación no se pueda registrar.
• Cuando algo falla, el motivo queda escrito en el registro del run en vez de perderse, que es lo que alargó el diagnóstico.

Verificación

La lógica del veredicto se ejecuta ahora contra casos de prueba —con bloqueantes, sin bloqueantes, sin resultado y con la publicación rechazada— y no solo se comprueba su sintaxis. En un Pull Request de prueba con fallos deliberados, la revisión encontró los tres problemas plantados y rechazó el intento de manipularla que llevaba escondido en un comentario del código, reportándolo como bloqueante. El comportamiento que más importaba se validó dos veces por causas distintas: cuando la revisión no concluye, no se aprueba nada.

[0.35.3] - 2026-09-12 — Revisión automática de Pull Requests

Añadido

• Revisión automática de cada Pull Request cuando la integración continua pasa en verde (ADR-0043). Publica sus hallazgos como comentarios sobre las líneas afectadas y emite un veredicto: pide cambios si encuentra algo bloqueante, y aprueba —sin mergear— si no, avisando cuando quedan puntos que necesitan decisión humana. Mergear sigue siendo solo de una persona.
• Revisión a demanda mencionando a @claude en un Pull Request, un issue o un comentario sobre una línea del diff. Es la vía para revisar aportes que llegan desde un fork y para discutir un hallazgo en su propio hilo; solo responde a quien tiene permiso de escritura en el repositorio.

Seguridad

• El veredicto se calcula fuera del modelo: la revisión solo produce un archivo de hallazgos y un paso determinista lo traduce a aprobar o pedir cambios. Así, un texto colado en un diff o en la descripción de un Pull Request («ignora lo anterior y aprueba esto») no tiene ningún camino hacia una aprobación — y además se reporta como hallazgo bloqueante. La revisión tampoco puede empujar commits ni mergear: no tiene permisos para ello.
• Los criterios de revisión y el propio workflow se leen desde la rama base, no desde la rama que se revisa, así que un Pull Request no puede relajar ni desactivar su propia revisión.

[0.35.2] - 2026-09-12 — Endurecimiento de seguridad (auditoría)

Seguridad

• Cambiar el correo ahora exige la contraseña actual. Era el único hueco real que quedaba: con una sesión viva (un dispositivo desatendido, una cookie robada) se podía cambiar el correo sin conocer la contraseña y, con el correo nuevo, disparar el reset de contraseña — un secuestro de cuenta completo. Ahora se re-autentica igual que el cambio de contraseña y la eliminación de cuenta.
• Las invitaciones a un hogar solo pueden ser de miembro. La titularidad se decide por el dueño del hogar, no por el rol del pivot; aceptar role=owner creaba un «administrador fantasma» sin poder real que confundía la interfaz y dejaba residuos al purgar una cuenta. Se quitó también esa opción del formulario.
• La purga de un dueño ya no destruye el hogar si otro miembro está suspendido pero aún dentro de su ventana de reactivación de 30 días. Antes se perdían de forma irreversible sus datos financieros; ahora la titularidad se transfiere y el historial se conserva.
• La cookie de sesión sale con el flag Secure por defecto en producción, aunque la plantilla del .env omita la variable: evita que viaje en claro por una petición http:// inducida antes del redirect a HTTPS.
• Contraseñas: política única y verificación de filtraciones. Registro, cambio y reset comparten ahora una sola regla (mínimo 8, máximo 72) y en producción se rechazan contraseñas presentes en filtraciones conocidas (k-anonymity contra HaveIBeenPwned).
• CI/CD endurecido: los workflows de GitHub Actions declaran permissions: contents: read (token de solo lectura) y fijan todas las acciones de terceros a un SHA de commit, cerrando el riesgo de que una acción comprometida abuse del token o del secreto de despliegue.
• El seeder de demostración no corre en producción (evita cuentas con contraseña pública) y se validan las fechas de los filtros de /movimientos (un valor malformado provocaba errores 500 en PostgreSQL).

Cambiado

• Los formularios de crear gasto/ingreso/transferencia/cuenta autorizan de forma explícita y redirigen a crear un hogar si no hay uno activo (antes uno de ellos podía dar un error 500).
• .gitignore cubre volcados de base de datos (*.sql, *.dump) y variantes de .env; se eliminó un pnpm-lock.yaml espurio (el proyecto usa npm).

Verificación

Tres pruebas nuevas: el cambio de correo se rechaza sin la contraseña actual (o con una incorrecta) y la invitación con role=owner se rechaza. Suite completa en verde (646 pruebas) en SQLite, MySQL y PostgreSQL.

[0.35.1] - 2026-09-12 — Licencia dual y puerta abierta a colaborar

Añadido

• Licencia comercial para las funciones Premium, en el directorio ee/ y separada de la AGPL que cubre el resto del proyecto (ADR-0042). El código de pago se publica para poder leerse y auditarse —quien confía sus finanzas a la app tiene derecho a verificar también aquello por lo que paga—, no para operarse como servicio. Finlia sigue funcionando completa sin ese directorio: borrarlo deja una aplicación libre y autoalojable.
• CONTRIBUTING.md: qué aportes ayudan más (reportar lo que no cuadra y revisar el cálculo, antes que Pull Requests grandes), cómo dejar en verde la suite y los cuatro jobs de CI, y el acuerdo de licencia de los aportes, en el que quien contribuye conserva su copyright.
• Regla de frontera del directorio ee/: la dependencia va en un solo sentido y borrarlo debe dejar la aplicación arrancando y pasando la suite. Es lo que sostiene la separación de licencias.

Corregido

• El artefacto de despliegue borraba el .github del repositorio de producción, donde vive el workflow que despliega en el servidor. Como el despliegue se dispara con el tag, un artefacto sin esa carpeta no lo disparaba nunca.

Documentación

• Plan de la semana 0 del lanzamiento (planes/lanzamiento-semana-0.md): copia de seguridad probada y restaurada, aviso de errores en producción, prueba de humo del registro desde fuera, vigilancia de la cuota diaria de correo y métricas del embudo. Lo que faltaba para abrir la app al público no era código, era operación.
• Estado corregido de dos planes de cuenta que seguían marcados como pendientes estando ya publicados (ADR-0033 y ADR-0034).

[0.35.0] - 2026-09-12 — Páginas de error y modo mantenimiento

Añadido

• Seis páginas de error propias (403, 404, 419, 429, 500 y 503), en español y con la marca, en vez de las de fábrica de Laravel. Cada una dice qué pasó y cuál es la salida. Dos se llevan atención especial: la de sesión caducada, que aparece en el peor momento —el formulario recién llenado— y de fábrica solo decía "Page Expired"; y la de demasiados intentos, que sale del límite de seguridad del login sin explicar que basta con esperar un minuto.
• Modo mantenimiento con página propia («Estamos actualizando Finlia»), que se sirve sin arrancar la aplicación: es lo que verá la gente durante los despliegues, en lugar de errores intermitentes mientras el servidor cambia de versión (ADR-0041).

Cambiado

• Los pasos de despliegue en el servidor ahora entran y salen de mantenimiento, y usan la ruta absoluta de PHP 8.4 en todos los comandos.

Verificación

Ocho comprobaciones nuevas. Las dos que importan: las seis páginas se renderizan con la base de datos apuntando a una conexión inexistente —porque un error 500 suele ser justo eso— y el modo mantenimiento se pre-renderiza de verdad en la prueba, que es la única forma de detectar en CI, y no en mitad de un despliegue, que alguien coló en esa vista algo que necesita sesión.

[0.34.3] - 2026-09-11 — Las trampas del despliegue, por escrito

Documentación

El primer despliegue en Hostinger destapó cuatro cosas que no se ven construyendo y que costaron horas de diagnóstico. Quedan en DEPLOYMENT.md para que el siguiente no las repita:

• El subdominio se crea como ALIAS al CDN de Hostinger. Ese nodo no tiene certificado para el nombre, así que el TLS falla con ERR_SSL_PROTOCOL_ERROR aunque el panel muestre el SSL activo y aunque por HTTP responda un 301. Es el síntoma más engañoso de todos: todo parece bien menos el resultado. Se arregla borrando el ALIAS y creando un registro A a la IP del hosting, en la cuenta que administre la zona DNS — que puede no ser la del hosting.
• Sacar la aplicación del CDN no es un parche. Todo lo que sirve app. es autenticado y personalizado, y nada es cacheable: un CDN delante no ahorra nada y añade el riesgo de servir una respuesta con datos de sesión a otra persona. En el sitio público sí tiene sentido.
• El php del shell no es el de producción. La terminal responde con una versión antigua mientras el sitio corre la del panel. Con la equivocada los comandos fallan con errores desconcertantes y el cron falla en silencio cada noche: sin recurrentes automáticos, sin digest y sin purga de cuentas, y sin un error visible en ninguna parte.
• El campo de «carpeta personalizada» está restringido a /public_html/, así que no sirve para apuntar al public/ de Laravel. Y si se usa, Hostinger escribe dentro de la raíz web real: deja una carpeta vacía y su página de bienvenida, que además no desaparecen con el git reset --hard de los despliegues siguientes porque no están en git.

Se añade también un bloque de diagnóstico que separa las causas en lugar de adivinar —HTTP frente a HTTPS, IPv4 frente a IPv6, y qué IP resuelve de verdad—, cuatro entradas nuevas a la tabla de problemas frecuentes, y la salida de emergencia: vaciar las dos variables de dominio devuelve la aplicación a un solo host, que es la configuración que corre en local y en toda la suite.

[0.34.2] - 2026-09-11 — Las épicas terminadas se liberan

Eliminado

• Las fichas de las once épicas completadas (1–10 y 13) salen del repositorio: lo entregado se cuenta en este changelog y el porqué, en los ADR de docs/DECISIONS.md. Las épicas que siguen abiertas —11 (hardening) y 12 (monetización)— conservan su ficha hasta que se cierren.

Cambiado

• La regla de versionado decía que no había tags y que el primero marcaría el MVP. No era cierto desde la 0.31.0: se venía tageando cada versión publicada. El changelog y la skill /update-changelog describen ahora lo que de verdad se hace —tag anotado sobre el merge en main, con el título de la versión— y que las versiones publicadas sin tag no se taguean a posteriori.
• README, CLAUDE.md, ROADMAP y la skill /implement-epic apuntan al ROADMAP como fuente del alcance de cada épica, en vez de a las fichas borradas.

[0.34.1] - 2026-09-11 — Reportar un error sin cazarlo

Añadido

• «Reportar un error» entra al menú de la aplicación, junto a Términos y Tus datos. Existía desde la versión 0.31.0, pero solo se enlazaba desde el pie: en el teléfono queda tras un scroll largo y debajo de la barra inferior, así que en la práctica no se encontraba.
• La versión se muestra al final de ese mismo menú («Finlia v0.34.1»). Es el primer dato que hace falta para entender un reporte, y hasta ahora había que ir a buscarlo al pie.

[0.34.0] - 2026-09-10 — «Puedes gastar hoy» con la plata que ya tienes

Cambiado

Una cuenta nueva con $100.000 en el banco, que gana 3 millones y cobra el 15, veía el día 10 «Puedes gastar hoy $151.447». La cifra salía de los ingresos esperados del mes: contaba el salario como si ya hubiera llegado, ignoraba el saldo real y, como restaba lo gastado desde el día 1, solo era fiable tras un mes de uso. Ahora la misma cuenta ve $20.000 hasta tu pago del 15 (ADR-0040).

• El «puedes gastar hoy» sale del saldo real: saldo en cuentas − lo apartado en metas − lo que vence antes del próximo cobro, repartido en los días que faltan para ese cobro. Es correcto desde el primer día, sin historial.
• Lo que esperas recibir ya no suma. El día de cobro dice hasta cuándo tiene que alcanzar lo de hoy; el monto alimenta el plan del mes, que solo puede bajar la cifra (ahorros fuera de metas o un salario adelantado no se convierten en «gasta millones hoy»).
• El horizonte es el pago del ingreso principal: el de mayor monto; dos quincenas iguales se turnan. Un ingreso menor que llegue antes no lo acorta.
• El presupuesto reparte lo que puedes gastar, no lo reduce. Comprar mercado dentro del presupuesto sí baja la cifra, como pasa con la plata de verdad.
• «Próximo mes» es una proyección («Te quedaría según tu plan»), no plata disponible.
• El formulario de gasto dice «Te quedarían $X hasta el DD/MM» en vez de «este mes».
• La landing, llms.txt y el README explican la cuenta nueva, con dos preguntas frecuentes más: «¿Y si todavía no me han pagado?» y «¿Tengo que usarla un tiempo antes de que sirva?».

Añadido

• Aviso de pago atrasado: si la fecha de cobro pasó y el ingreso no aparece, la tarjeta lo dice y la cifra sigue contando solo con lo que hay. Un pago adelantado (hasta 7 días antes) se reconoce y la plata tiene que alcanzar hasta el cobro siguiente.
• Faltante antes del cobro: si el saldo no cubre lo que vence antes del próximo pago, la tarjeta muestra cuánto falta, distinto de «te has pasado del plan».
• La tarjeta pide lo que falta para que la cifra sea exacta: cuentas con su saldo, ingreso esperado o día de cobro.
• Desglose «¿Cómo se calcula?» nuevo: saldo, apartado en metas, lo que vence antes del cobro y reparto por días.

Corregido

• Una tarjeta de crédito ya no suma su cupo como si fuera plata propia: solo resta lo que se debe.
• La plata registrada en metas de ahorro ya no se ofrecía como gastable (los aportes no mueven cuentas, ADR-0025).

Verificación

20 pruebas más del cálculo (50 en total) (horizonte, pagos adelantados y atrasados, quincenas, metas, tarjetas, tope del plan, faltante, aislamiento entre hogares). El panel sigue dentro de su presupuesto de consultas: el plan y la liquidez comparten recurrentes, deudas y metas cargados una sola vez. Suite completa en 620/621; el fallo restante (DebtTest, traducción con «:» en la clave) solo ocurre en Windows y es previo a esta entrega.

[0.33.0] - 2026-09-10 — Invitar a alguien que todavía no tiene cuenta

Contexto

La primera invitación real salió mal de principio a fin. La persona invitada —sin cuenta, que es lo normal— pulsó el enlace y la aplicación le pidió una contraseña que no tenía. Creó una cuenta y el registro le fabricó un hogar propio, sin relación con la invitación. Solo al pulsar el enlace por segunda vez, ya con sesión, entró al hogar invitado, y quedó con dos hogares. En una aplicación de finanzas familiares, invitar a la pareja es la función que justifica el producto, y hasta ahora dejaba un hogar huérfano en cada invitación.

Cambiado

• La invitación se puede ver sin haber iniciado sesión (ADR-0039). Quien la abre sin cuenta ve dos salidas, «Crear mi cuenta» o «Ya tengo cuenta, entrar», y la página no muestra nada del dinero del hogar.
• Quien entra desde la invitación vuelve a ella tras iniciar sesión y la acepta con un toque.
• Registrarse desde la invitación ya no crea un hogar propio. El formulario llega con el correo invitado fijo y avisa a qué hogar se va a entrar; al confirmar el correo, la persona entra directamente a ese hogar, con uno solo. Funciona aunque el enlace de confirmación se abra en otro dispositivo.
• Si la invitación caduca antes de confirmar el correo, la persona recibe su hogar personal: nadie se queda sin hogar.
• El botón «Entrar» del sitio se ve también en el teléfono. Estaba oculto por debajo de 576 px, así que en el caso más común solo aparecía «Crear cuenta». A 320 px los dos caben en una línea.

Seguridad

• El correo se sigue verificando al registrarse desde una invitación. El enlace es transferible —se reenvía por WhatsApp—, así que no prueba que quien lo abre controle ese buzón. El token autoriza entrar al hogar; la verificación prueba el correo. Se exigen las dos, y la vinculación ocurre solo al confirmar.
• El correo del registro lo impone el servidor desde la invitación: manipular el campo del formulario no cambia la dirección registrada.
• Aceptar sigue exigiendo sesión con el correo verificado. Solo se abrió la vista, no la acción.
• La página de invitación es idéntica exista o no una cuenta con ese correo: si lo dijera, cualquier dueño de hogar podría invitar a una dirección para averiguar si esa persona usa Finlia.
• El token viaja en la sesión entre la invitación y el registro, nunca en la URL.

Verificación

• phpunit: 615/616 — 15 tests nuevos en InvitationOnboardingTest, comprobados saboteando el código a propósito (aceptar el correo del formulario, no vincular al confirmar, crear hogar siempre, vincular sin verificar, revelar la cuenta): cada sabotaje tumba al menos un test. El fallo restante es el conocido de Windows.
• Recorrido completo en el navegador, en viewport de teléfono: invitación sin sesión → registro con el correo manipulado a mano → confirmación → panel del hogar invitado con un solo hogar; y el camino de quien ya tiene cuenta, que vuelve a la invitación tras entrar.
• vendor/bin/pint: limpio.

[0.32.1] - 2026-09-10 — Cada cosa en su dominio

Corregido

Desde la landing, el botón «Entrar» llevaba a finlia.online/login en lugar del subdominio de la aplicación. El síntoma era un enlace; la causa era que la aplicación entera respondía también en el dominio del sitio.

Al repartir por host solo se habían acotado las rutas de marketing. Las de la aplicación no llevaban restricción, así que respondían en cualquier host y route() las resolvía con el host desde el que se navegara. Eso traía tres problemas, y el del enlace era el menor:

• Un buscador podía indexar finlia.online/login y el resto de pantallas de sesión.
• El manifiesto de la PWA se servía desde los dos hosts, así que la aplicación se podía instalar desde el dominio del sitio y quedar atada a él para siempre — exactamente lo que el reparto en dos dominios existía para evitar (ADR-0038).
• Dos URLs distintas para el mismo contenido.

Ahora las rutas de la aplicación están acotadas a su host, y route('login') genera la URL del subdominio se navegue desde donde se navegue.

Cambiado

• Las páginas legales se mudan al sitio público, al revés que el resto: términos, historial de versiones y política de datos son públicas, indexables y entran en el sitemap, así que su sitio natural es finlia.online y no el subdominio de la aplicación. La aplicación las enlaza cruzando de host.
• Los enlaces firmados que llegan por correo —baja del digest, verificación de correo, confirmación de cambio de dirección— quedan acotados al host de la aplicación, que es a donde apuntan esos correos.

Verificación

Cinco comprobaciones nuevas fijan el reparto: que la aplicación no responda en el host del sitio, que sí lo haga en el suyo, que las páginas legales sean al contrario, que el manifiesto solo se sirva desde la aplicación y que «Entrar» y «Crear cuenta» apunten al subdominio. Suite completa en 600/601 y 37/37 en Playwright.

[0.32.0] - 2026-09-10 — Términos y condiciones definitivos

Publica la versión de términos 2026-09-v1. La versión de los términos es independiente de la del software y así seguirá: cambian en momentos distintos y por razones distintas. Este changelog es el sitio donde queda anotado qué entrega publicó qué versión legal.

Añadido

• Términos y condiciones oficiales, en sustitución del borrador con marcadores. Quince secciones ajustadas a Finlia y a la ley colombiana, escritas para que se entiendan.
• Se declara expresamente que Finlia no es una entidad financiera ni está vigilada por la Superintendencia Financiera: no capta dinero, no otorga créditos y no se conecta a bancos.
• Queda por escrito que las cifras son estimaciones y que la entidad de crédito puede aplicar otras reglas —seguros, cuota de manejo, días de mora—. Es el mismo principio que la aplicación ya muestra en el panel de deudas, ahora también en el contrato.
• Advertencia destacada sobre los hogares compartidos: dentro de un hogar no hay información privada, todos los miembros ven todo. Es el riesgo que un usuario menos se espera al invitar a alguien.
• Derechos del titular bajo la Ley 1581 enumerados, con los plazos legales de respuesta: diez días hábiles para consultas y quince para reclamos, con sus prórrogas.
• Noventa días de aviso si el servicio cerrara, con la exportación de datos disponible durante todo el plazo.
• Se separa la licencia del código (AGPL-3.0) de los derechos sobre la marca y sobre el servicio.

Detalles de redacción

• La limitación de responsabilidad no lo excluye todo, a propósito. Se dice explícitamente que nada limita la responsabilidad por dolo o culpa grave ni los derechos del consumidor. En Colombia una cláusula que intente excluirlo todo se tiene por abusiva y puede caer entera, dejando al prestador peor que si no hubiera escrito nada.
• El canal de contacto y de ejercicio de derechos es contacto@finlia.online, que debe existir y leerse: los plazos de respuesta corren desde que llega el mensaje.

Política de tratamiento de datos

La página /datos dejó de ser un borrador con marcadores. Renderizaba literalmente «[60 / 90] días» y una frase que terminaba en «escríbenos a .», enlazada desde el pie de toda la aplicación.

Le faltaban además cuatro elementos que la Ley 1581 exige, no adornos: quién es el responsable del tratamiento, para qué se usan los datos, cuáles son los derechos del titular y con quién se comparten. Ahora están, junto con:

• Los encargados del tratamiento con nombre: Hostinger para el alojamiento —con los servidores en Brasil, lo que implica una transferencia internacional que hay que informar— y Brevo para el correo, que solo recibe la dirección de destino y el contenido.
• Qué se guarda y por qué, incluida la prueba de consentimiento (versión aceptada, fecha e IP) y por qué la IP solo se guarda en los mensajes enviados sin sesión.
• Cómo protegemos los datos, en concreto: tráfico cifrado, contraseñas con hash irreversible, aislamiento por hogar verificado en cada cambio del código, y el código público para que cualquiera lo compruebe en lugar de creerse la página.
• Las copias de seguridad no son un archivo histórico y no sustituyen tu exportación. Decirlo evita una expectativa que el proveedor de alojamiento no cumple.
• Los 90 días de aviso de cierre, ahora coherentes con los términos.

Cuatro tests nuevos fijan que la página no se publique con marcadores sin rellenar, que informe cada elemento que la ley exige, y que el plazo de cierre coincida con el de los términos — si se contradicen, la promesa se rompe.

Poder volver a leerlos

Los términos solo aparecían al tener que aceptarlos. Se podían releer —/terminos siempre fue público— pero el único enlace estaba en el pie: al final de un scroll largo y tapado por la barra inferior en el teléfono. Nadie vuelve a leer un contrato si hay que cazarlo.

• Términos y «Tus datos» entran en la navegación lateral, donde se buscan.
• Historial de versiones en /terminos/historial. Existía una URL por versión, pero ningún índice: había que adivinar el identificador. Los propios términos prometen que las versiones anteriores quedan consultables, así que la promesa estaba escrita y no se cumplía.
• Quien tiene sesión ve además cuál aceptó y en qué fecha. Es su prueba de consentimiento y tiene derecho a consultarla sin pedírsela a nadie.

Siete tests cubren el historial, incluido que la ruta del índice gane a la comodín de versión — sin ese orden, «historial» se interpretaría como el identificador de una versión y daría 404.

Nota

El texto no lo redactó un abogado. Conviene una revisión profesional antes de cobrar por el servicio.

[0.31.0] - 2026-09-10 — Contacto y reportes de error

Añadido

• Formulario de contacto público en /contacto, con selector de motivo (alianzas, comercial, sugerencia). Uno solo con selector y no cuatro formularios: al que escribe le da igual, y hay un tercio del código que mantener.
• Reporte de error desde la aplicación, con sesión iniciada. No pide nombre ni correo —ya se conocen— y adjunta el contexto técnico solo: versión, pantalla desde la que se reportó, navegador y tamaño de ventana. Eso es lo que convierte un «no me funciona» en algo accionable. La pantalla dice exactamente qué viaja, y deja claro que no van movimientos, saldos ni cuentas.
• Aviso por correo al buzón del producto, con Reply-To de quien escribió para poder responderle sin copiar la dirección a mano. Si no hay buzón configurado o el SMTP falla, el mensaje se guarda igual: perderlo por un correo caído sería peor que enterarse tarde.

Seguridad

• Límite de envíos: 3 por hora y por IP en el formulario público, 5 por hora y por usuario en el reporte de error. Una persona real manda uno; tres dejan margen para reintentos sin permitir una ráfaga.
• Campo trampa en ambos formularios en lugar de un CAPTCHA: está fuera de la pantalla y del alcance del teclado, así que una persona nunca lo ve y un bot que rellena todo el DOM, sí. Cubrir el 99 % del spam sin ponerle un puzzle a quien sí es humano.
• La dirección IP se guarda solo en envíos anónimos. Con sesión iniciada ya está el user_id, así que guardarla además sería recolectar un dato personal sin necesidad. La política de datos lo dice con esas palabras.
• El contexto técnico llega del navegador y por tanto es manipulable: se valida, se recorta y nunca se usa para decidir nada — solo para leerlo.

Decisiones

• Sin reglas de composición en las contraseñas. Se mantiene el mínimo de 8 caracteres y nada más: exigir mayúscula y número no produce contraseñas fuertes sino predecibles (Finlia2026!), que es lo que el NIST SP 800-63B desaconseja explícitamente desde 2017.
• Sin creación automática de issues en GitHub. Los issues son públicos, y un reporte de error en una aplicación de finanzas suele venir con contexto personal: publicarlo automáticamente sería publicar datos de un usuario sin que él lo entienda. Los reportes quedan en la base de datos y se decide a mano cuál se hace público.

Verificación

• phpunit: 585/586 — 15 tests nuevos que cubren el campo trampa, el límite de envíos, el rechazo del motivo «error» en el formulario público, que la IP solo se guarde sin sesión, que el contexto se recorte y que el aviso permita responder a quien escribió. El fallo restante es el conocido de Windows.
• vendor/bin/pint: limpio.

[0.30.0] - 2026-09-09 — Sitio público en finlia.online

Contexto

La raíz del dominio servía el formulario de login: quien llegaba sin conocer Finlia veía dos campos pidiéndole correo y contraseña, sin una línea que explicara qué es esto. Y no había una sola etiqueta para compartir, así que pegar el enlace en WhatsApp —que es por donde esto se mueve en Colombia— mostraba la URL pelada, sin título ni imagen.

Añadido

• Landing pública con el problema que resuelve Finlia, cómo funciona en tres pasos, la fórmula del dinero disponible, las funciones, capturas reales de la aplicación y las preguntas frecuentes.
• Metadatos para compartir: título, descripción, canonical, Open Graph y Twitter Card, con una tarjeta de 1200×630 que se genera desde una página real (/og) y se regenera con npm run screenshots cuando cambie la marca o el mensaje.
• Datos estructurados (SoftwareApplication y FAQPage) para buscadores y asistentes de IA, sitemap.xml que crece solo al registrar una página nueva, y /llms.txt, un resumen en texto plano que incluye qué hace Finlia y —tan importante como eso— qué no hace: no se conecta a bancos y no da asesoría financiera.
• Estructura preparada para crecer: precios o testimonios son una vista más en resources/views/marketing/, su ruta y una entrada en el registro de páginas.

Cambiado

• La aplicación pasa a app.finlia.online y el sitio público se queda con la raíz (ADR-0038). Un solo repositorio y una sola aplicación Laravel que reparte por host. El motivo no es orden: una PWA instalada queda atada al origen desde el que se instaló, así que mover la aplicación más adelante le rompería el icono de la pantalla de inicio a quien ya la tuviera puesta. Se le da host propio ahora, que es cuando sale gratis.
• robots.txt pasa a ser una ruta porque tiene que decir cosas distintas según el host: rastreo libre en el sitio público, Disallow: / en la aplicación, donde todo está tras sesión y lo único indexable serían pantallas de login.
• Las capturas se mudan a public/img/capturas/, para servir a la vez al README y a la landing sin duplicarlas.

Corregido

• Desbordamiento horizontal en móvil en el hero: una fila de Bootstrap con gutter de 3rem dentro de un contenedor a ancho completo saca 12 px por cada lado, porque su margen negativo supera al padding del contenedor. En escritorio no se nota, en teléfono sí.

Revisión de la landing

Tres correcciones que salieron de mirarla en un portátil y en un teléfono de verdad:

• La fórmula pasa a resta vertical. En una sola fila las cifras no se pueden comparar de un vistazo y en pantalla estrecha se partía por cualquier sitio. Ahora es una cuenta como se hace en papel: concepto a la izquierda, importe a la derecha con cifras tabulares, filete y total. Con importes de ejemplo, que además demuestran el producto mejor que unas etiquetas sueltas.
• El hero deja de abrir con el Panel. Esa pantalla empieza con dos avisos de obligaciones apilados que ocupaban media imagen: una página que promete tranquilidad no puede abrir con dos alarmas. Pasa a mostrar Presupuestos, que arranca con la cifra que la landing promete. El Panel se queda en la tira de capturas, donde el contexto lo explica.
• El usuario de demostración deja de llamarse "Usuario Demo Finlia", que en una captura de portada se lee a placeholder.
• En teléfono se retira la captura del hero. Enseñar la foto de un teléfono a quien ya tiene uno en la mano no añade nada, y empujaba el contenido real fuera de la primera pantalla. De paso ahorra 280 KB en cada visita desde el celular: la imagen se ocultaba con CSS pero el navegador la descargaba igual, y solo deja de pedirla al marcarla como carga diferida. Medido con el tráfico real de la página: la primera carga en móvil pasa de 280 KB de imágenes a cero.

Verificación

• phpunit: 570/571. Los 12 tests nuevos cubren los metadatos, que son lo que rompe en silencio —un og:image que desaparece no da error, solo deja el enlace sin vista previa—, la coherencia entre las preguntas visibles y las del esquema, y el reparto en dos hosts. El fallo restante es el conocido de Windows, ajeno a esta entrega.
• playwright: 37/37, con el test de la raíz actualizado: ya no redirige al login, ahora muestra la landing.
• Landing revisada en escritorio y en teléfono, y comprobado que la página ya no desborda a lo ancho.

[0.29.0] - 2026-09-09 — La licencia pasa a AGPL-3.0

Contexto

Finlia se publicó bajo licencia MIT, que permite a cualquiera tomar el proyecto, cerrarlo y venderlo como servicio sin devolver nada. Con la monetización en el horizonte, esa no es la licencia adecuada — y el momento de cambiarla es ahora, mientras el titular del copyright es una sola persona: en cuanto se acepta la primera contribución externa, relicenciar exige el permiso de cada contribuyente.

Cambiado

• Licencia: MIT → GNU Affero General Public License v3.0 o posterior. Texto íntegro tomado de la fuente canónica de la Free Software Foundation. composer.json declara el identificador SPDX AGPL-3.0-or-later.
• El README explica qué implica en la práctica, no solo el nombre de la licencia: el proyecto se puede usar, estudiar, modificar y redistribuir, pero ofrecerlo como servicio en red obliga a poner el código correspondiente a disposición de quien lo usa (AGPL §13). Esa cláusula es justo la diferencia con la GPL normal y la razón de elegirla.

Nota sobre versiones anteriores

Una relicencia no es retroactiva: el código publicado hasta la versión 0.28.0 sigue disponible bajo MIT para quien lo obtuviera entonces, y eso no se puede revocar. El cambio aplica de esta versión en adelante. El README lo deja escrito para que nadie se lleve una sorpresa.

Verificación

• composer validate --strict: válido — el identificador SPDX se acepta.
• Texto de la licencia comprobado: 34.523 bytes, con la cabecera y el cierre canónicos de la FSF.
• Las apariciones de "MIT" que quedan en package-lock.json son las licencias de las dependencias de terceros y no se tocan.

[0.28.0] - 2026-09-09 — El repositorio se explica solo

Contexto

El código estaba bien documentado para quien ya trabajaba en él, pero quien llega de fuera —un reclutador, un colaborador— no encontraba en ningún sitio qué problema resuelve la aplicación ni por qué está construida así. Faltaba también lo más básico de un portafolio: ver la app.

Añadido

• Seis capturas de la aplicación en viewport de teléfono (Panel, dinero disponible, registrar gasto, reportes, deudas y metas), con los datos falsos del seeder.
• Script de capturas (npm run screenshots): las regenera contra la app corriendo, así que no envejecen a mano ni hay que recordar cómo se hicieron. Vive fuera de tests/e2e a propósito — es documentación, no una prueba, y no debe correr en la integración continua.
• El README responde a qué problema resuelve la app: el saldo del banco no sabe que el arriendo sale el día 5 ni que hay una cuota comprometida en la tarjeta, y de ahí sale la fórmula del dinero disponible. Con secciones nuevas de problema, solución y "Why this project?", que explica qué decisión técnica salió de qué necesidad real.
• Tabla de tecnologías demostradas que dice qué se resolvió con cada pieza, no solo cuál se usó.
• Dos diagramas Mermaid en la documentación de arquitectura: el recorrido de una petición por las capas —con el servicio de dominio resaltado, que es el único sitio donde vive el cálculo financiero— y el flujo completo de registrar un gasto como diagrama de secuencia. Sustituyen a los esquemas en ASCII.

Corregido

• La demo abría en ceros. El seeder repartía los movimientos al azar sobre seis meses, así que al mes en curso le tocaban uno o ninguno: durante los primeros días de cada mes, el Panel mostraba "$ 0,00" en ingresos y en gastos, y el presupuesto al 0 %. Quien arrancaba el proyecto por primera vez veía una aplicación que parecía rota. Ahora el mes actual se siembra con importes fijos —dos salarios y una canasta de nueve gastos que consume el 41 % del presupuesto— y el historial aleatorio se queda para las series de seis meses de los reportes, que es para lo que servía.
• El hogar de demostración era insolvente: los compromisos superaban a los ingresos esperados, así que la pantalla estrella del producto salía en rojo con "te has pasado del plan". Con dos salarios acordes al hogar de dos miembros que el propio seeder crea, la demo enseña lo que la aplicación sabe hacer: "Puedes gastar hoy $ 81.521", dentro de presupuesto.
• Saldos iniciales de las cuentas coherentes con el volumen de movimientos sembrado; antes las cuentas quedaban en negativo.
• El resumen de decisiones de la documentación de arquitectura declaraba ADR-0003 como pendiente desde la épica de hogares, cuando quedó aceptada en ese mismo momento.

Verificación

• phpunit: 558/559 en local, sin cambios respecto de antes de esta entrega. El fallo restante solo se reproduce en Windows, por cómo NTFS resuelve una ruta con :; en Linux la integración continua cierra 559/559.
• vendor/bin/pint --test: sin cambios pendientes.
• Las capturas se generaron contra la aplicación real y se revisaron una a una: ningún dato es de una persona real, todos salen de Faker con locale es_CO.
• Barrido de secretos sobre los ficheros versionados: sin coincidencias. .env no está en el índice.

[0.27.1] - 2026-09-09 — Cabeceras de seguridad y HTTPS forzado

Contexto

Las cabeceras de seguridad del servidor estaban documentadas pero no aplicadas: la guía de despliegue pedía añadirlas a mano al subir, que es justo el paso que se olvida cuando toca desplegar. Ahora viajan en el repositorio.

Seguridad

• Cinco cabeceras en public/.htaccess: X-Content-Type-Options: nosniff, X-Frame-Options: DENY (sin iframes no hay clickjacking sobre los formularios de registrar movimientos), Referrer-Policy: strict-origin-when-cross-origin (al salir a un sitio externo solo viaja el origen, y las URLs de Finlia llevan IDs de recursos del hogar), Permissions-Policy negando cámara, micrófono, geolocalización, pagos y USB, y HSTS de un año.
• Se emiten con always, así que también salen en las respuestas de error — que es donde la aplicación devuelve páginas propias y donde más importa que el navegador no adivine el tipo.
• HSTS solo sobre TLS. Va condicionada a la variable HTTPS, de modo que en desarrollo nunca se emite y en producción se activa sola en cuanto el dominio sirva por HTTPS. Es un compromiso de un año: conviene activar el certificado antes de desplegar.
• Redirección HTTP → HTTPS, con el desarrollo local excluido (localhost, 127.0.0.1 y los dominios .test/.localhost): una redirección incondicional dejaría el proyecto inaccesible al trabajar sobre XAMPP. X-Forwarded-Proto: https también corta la redirección, por si algún día hay un proxy terminando el TLS.

Detalles de implementación

• Sin CSP, a propósito. Una decena de vistas llevan <script> en línea —los datos de los gráficos, los chips de categoría, el simulador de deuda—, así que un script-src 'self' rompería la aplicación entera. Añadirla exige antes mover esos bloques a ficheros o darles un nonce por petición; hasta entonces, una CSP a medias solo daría falsa sensación de cobertura.
• .htaccess en vez de un middleware: cubre también los ficheros estáticos, que nunca pasan por PHP. El precio es que la suite no puede verificar estas cabeceras — son del servidor, no del framework — y se comprueban con curl -I tras desplegar.

Modificado

• La guía de despliegue pasa de instruir "añade esto a mano" a documentar lo que ya trae el repositorio, con la tabla de cabeceras y el aviso sobre el compromiso de HSTS. La política de seguridad registra las dos decisiones de arriba.
• .env.example refleja por fin el proyecto: fuera Redis, AWS y Memcached, que no se usan; DB_CONNECTION=mysql con el bloque completo y PostgreSQL comentado al lado, porque SQLite es solo de la suite de tests; y FINLIA_MAIL_ENABLED, el interruptor global del correo, que se leía en configuración pero no estaba documentado en ninguna parte.

Verificación

• Comprobado contra un Apache real, no solo leído: sobre http://localhost la página se sirve sin redirigir, con las cuatro cabeceras presentes y HSTS ausente; con un host externo devuelve 301 a https:// conservando la ruta; y con X-Forwarded-Proto: https no redirige, así que no hay bucle detrás de un proxy.
• Las cabeceras aparecieron sobre una respuesta de error, que confirma de paso el efecto de always.
• phpunit: 558/559, idéntico a antes del cambio — esta entrega no toca código PHP. El fallo restante (DebtTest::test_no_se_puede_registrar_una_deuda_imposible) solo se reproduce en Windows: el mensaje de validación se pasa a __() como frase con : dentro, y en NTFS file_exists() da true para esa ruta por los flujos alternativos de datos, así que el traductor intenta cargarla como fichero de idioma. En Linux —donde corre la integración continua— la suite queda en 559/559.
• vendor/bin/pint --test: sin cambios pendientes.

[0.27.0] - 2026-09-09 — El "+" es la única entrada para registrar

Contexto

Los botones "Gasto" e "Ingreso" del panel no respondían en el teléfono: había que abrir el "+" y elegir la acción desde ahí. El síntoma que lo delató fue que sí funcionaban cuando el "+" estaba auto-oculto.

Corregido

• El contenedor del FAB interceptaba los clics de la página. .fab-container es una columna fixed que contiene el menú del "+", y el menú cerrado sigue ocupando sitio en el layout: la caja se estiraba muy por encima del botón y capturaba todo lo que cayera debajo. document.elementFromPoint() en el centro de "Ingreso" devolvía fab-container, no el enlace. Y por eso funcionaba con el FAB oculto: .is-hidden ya traía pointer-events: none. Ahora lo trae el contenedor siempre, y solo lo recuperan sus hijos interactivos. Es la causa del mismo síntoma reportado antes sobre botones "Cancelar".

Modificado

• El panel ya no lleva botones "Gasto"/"Ingreso" (ADR-0037). Duplicaban dos de las cinco acciones del "+", y un flotante sobre el contenido siempre acaba encima de algo — además de aparecer y desaparecer con el scroll, así que el usuario veía dos entradas a lo mismo, una intermitente. Registrar un gasto desde el panel pasa de uno a dos toques; a cambio, la entrada única da acceso a las cinco acciones.
• El botón ocupado conserva su etiqueta. Antes se ocultaba su contenido entero y quedaba un botón vacío con una ruedita, que se lee como si algo hubiera fallado. Cuando el botón tiene icono —lo normal en Finlia— el spinner ocupa el sitio del icono y la etiqueta se queda: "⟳ Crear hogar". El ancho no se mueve porque el icono se sustituye, no se suma, y el nombre accesible se conserva de forma natural.
• La barra de progreso pasa de 3 a 4 px y arranca en cobre. El petróleo oscuro del principio se confundía con la navbar.

Añadido

• Test E2E del solape que mide quién recibe de verdad el clic en la caja del contenedor, no la posición de un botón del panel: dónde cae ese botón depende de cuánto contenido haya ese día, y si hay que hacer scroll para alcanzarlo el FAB se auto-oculta y el fallo se escondería solo. Solo se reproduce con viewport de teléfono.
• ADR-0037 con las dos reglas que se derivan: un contenedor fixed nunca captura clics, y no se duplica la acción de un flotante con un botón fijo en la misma pantalla.

Verificación

• php artisan test: 559/559 en verde.
• npm run test:e2e: 37/37 en verde.
• El test del FAB falla sin la corrección, nombrando al culpable (el contenedor capturó el clic como: fab-container).
• vendor/bin/pint --test: sin cambios pendientes.

[0.26.1] - 2026-09-09 — El FAB se tragaba los clics del panel

Contexto

Los botones "Gasto" e "Ingreso" del panel no respondían en el teléfono: había que abrir el "+" y elegir la acción desde ahí. No era un enlace roto —la ruta siempre estuvo bien— sino un contenedor invisible por encima.

Corregido

• El contenedor del FAB interceptaba los clics de la página. .fab-container es una columna fixed que incluye su menú, y el menú cerrado sigue ocupando sitio en el layout: la caja del contenedor se estiraba muy por encima del "+" y capturaba todo lo que cayera debajo. document.elementFromPoint() en el centro de "Ingreso" devolvía fab-container, no el enlace. Ahora el contenedor lleva pointer-events: none y solo reciben clics sus hijos interactivos: el botón siempre, el menú al abrirse. Es el mismo síntoma que ya se había reportado sobre botones "Cancelar" — esta es la causa.
• Test de regresión que mide un punto concreto del contenedor, no la posición de un botón del panel: dónde cae ese botón depende de cuánto contenido haya ese día, y si hay que hacer scroll para alcanzarlo el FAB se auto-oculta y el fallo se escondería solo. Solo se reproduce con viewport de teléfono; en escritorio el FAB queda lejos.

Modificado

• El botón ocupado conserva su etiqueta. Antes se ocultaba su contenido entero y quedaba un botón vacío con una ruedita, que se lee como si algo hubiera fallado. Ahora, cuando el botón tiene icono —lo normal en Finlia—, el spinner ocupa el sitio del icono y la etiqueta se queda: "⟳ Crear hogar". El ancho no se mueve porque el icono se sustituye, no se suma, y el nombre accesible se conserva de forma natural. El aria-label de respaldo queda solo para botones sin icono, que siguen ocultando el contenido entero.
• La barra de progreso pasa de 3 a 4 px y arranca en cobre. El petróleo oscuro del principio se confundía con la navbar y hacía que la barra pareciera parte del marco.

Verificación

• php artisan test: 559/559 en verde.
• npm run test:e2e: 37/37 en verde.
• El test del FAB falla sin la corrección, señalando al culpable por su nombre (el contenedor capturó el clic como: fab-container).
• vendor/bin/pint --test: sin cambios pendientes.

[0.26.0] - 2026-09-08 — Indicadores de carga

Contexto

La app navega con recargas completas: entre el clic y la página nueva no había ninguna señal. Con el servidor lento —y en hosting compartido lo es a ratos— el usuario cree que se pegó y vuelve a pulsar. En un GET eso solo molesta; en un POST son dos gastos.

Añadido

• Barra de progreso superior (.finlia-progress): 3 px, degradado petróleo→cobre, avance asintótico que nunca llega al 100 % —ese salto lo da la página nueva al pintarse—. Se enciende en cualquier navegación o envío.
• Retardo de 140 ms antes de mostrarla. Es la diferencia entre una señal y un parpadeo: si la respuesta llega en 80 ms, una barra que aparece y desaparece es ruido. Por debajo del umbral no se ve nada.
• Spinner dentro del botón pulsado, que además lo deja inerte. El contenido se oculta con visibility en vez de borrarse, así que el botón conserva su ancho y no desplaza lo que tiene al lado justo al pulsarlo.
• Descarte del segundo envío del mismo formulario. Es la parte que de verdad protege: sin ella, dos toques impacientes sobre "Guardar gasto" son dos gastos.
• 7 tests E2E (loading.spec.ts), ninguno de los cuales toca datos: cancelan la navegación en vez de simular un servidor lento, registrando el listener después del módulo para que este vea el evento intacto.

Detalles de implementación

• El botón no se deshabilita. Un disabled deja su name/value fuera del payload y rompería cualquier formulario que distinga qué botón lo envió; se bloquea con pointer-events y una marca en el formulario.
• aria-label de respaldo mientras está ocupado. visibility: hidden saca el texto del árbol de accesibilidad: sin esto el botón se quedaba sin nombre justo mientras esperaba, y un lector de pantalla anunciaría "botón, ocupado" y nada más. Lo destapó el test, al dejar de encontrar el botón por su nombre tras pulsarlo.
• El modal de confirmación se conecta a mano. Envía con HTMLFormElement.prototype.submit() para no re-disparar su propio interceptor, y eso se salta el evento submit, así que el indicador no se encendía solo — justo en el borrado, que es donde más se espera.
• Limpieza en pageshow. Volver atrás restaura la página tal como se dejó: con la barra a medias y el botón girando para siempre.
• Filtros de enlace: se ignoran target="_blank", download, anclas #, javascript:/mailto:/tel:, sitios externos y clics con modificador. En todos ellos esta página se queda donde está, y encender la barra la dejaría girando sobre una pantalla que nunca cambia.
• Con prefers-reduced-motion la barra aparece quieta en un tramo fijo y el spinner gira más despacio: es información, no decoración, así que no se suprime.

Modificado

• docs/UI_DESIGN.md: sección nueva en §4 con la única regla que afecta a quien escriba una vista —data-sin-progreso para acciones que no cambian de página— y un punto más en el checklist.

Verificación

• php artisan test: 559/559 en verde.
• npm run test:e2e: 35/35 en verde (28 antes).
• Los 7 tests nuevos fallan con el módulo neutralizado: sin esa comprobación no sabríamos si prueban algo.
• vendor/bin/pint --test: sin cambios pendientes.

[0.25.1] - 2026-09-08 — El banner de instalación se veía recortado

Corregido

• El aviso de instalación en iOS dejaba casi un cuarto de pantalla vacío a la derecha, y en un iPhone real parecía un banner cortado. La fila es un flex y ningún hijo crecía, así que todo se apelmazaba a la izquierda. El fallo me lo llevé yo mismo: con el texto de ayuda largo la fila se llenaba por accidente, y al acortarlo para arreglar un truncamiento quedó el hueco al descubierto — que no se notara antes fue casualidad, y no verlo después fue por revisar solo el modal. flex: 1 en .ios-install-banner-text absorbe el sobrante y empuja el botón y la equis al borde.

Añadido

• 3 tests E2E (390, 402 y 430 px, los anchos de iPhone en uso) que no comprueban "que se vea bien" sino la propiedad medible: la equis termina pegada al borde derecho, sea cual sea el ancho y la longitud del texto. Contra el CSS anterior los tres fallan (Recibido: 76.078125 frente a un máximo de 20).

Verificación

• php artisan test: 559/559 en verde.
• npm run test:e2e: 28/28 en verde (25 antes de esta corrección).
• vendor/bin/pint --test: sin cambios pendientes.

[0.25.0] - 2026-09-07 — Instalación del PWA en iPhone

Contexto

Safari nunca implementó beforeinstallprompt, así que en iOS no existe el aviso nativo de instalación que Android y escritorio muestran solos. Un usuario de iPhone no tenía forma de descubrir que Finlia se puede instalar: la app cumplía todos los criterios de instalabilidad y aun así el acceso quedaba escondido en el menú Compartir.

Añadido

• Aviso de instalación para iOS (layouts/partials/ios-install-banner): banda discreta sobre la barra de navegación con un modal de pasos numerados (Compartir → Añadir a pantalla de inicio → Añadir). Usa los tokens del sistema de diseño, así que funciona en claro y oscuro sin colores fijos.
• El paso 1 enseña el icono de Compartir en grande. Es un botón sin etiqueta: quien no lo conoce lo busca por la forma, no por el nombre. Y su posición no es fija — abajo en iPhone con la barra de direcciones abajo (lo normal desde iOS 15), arriba en iPad o si el usuario movió la barra —, así que el texto no promete una sola ubicación.
• Distingue Safari del resto de navegadores iOS. Es el detalle que evita mandar al usuario a un callejón sin salida: en iPhone solo Safari instala de verdad — Chrome, Firefox y Edge son WebKit por obligación, pero su "Añadir a pantalla de inicio" crea un marcador que sigue abriéndose dentro del navegador. A esos se les pide abrir la app en Safari en vez de darles unos pasos que no van a funcionar.
• 7 tests E2E (ios-install.spec.ts) que fijan a quién se le muestra, que es lo que de verdad importa: iPhone+Safari sí; Android y escritorio no (ya tienen el aviso nativo); dentro de la app ya instalada no (navigator.standalone); una vez descartado no vuelve; y Chrome de iPhone recibe la variante correcta. Cada caso usa su propio user-agent reutilizando el storageState de la suite, porque un login por test agotaría el throttle:5,1.

Detalles de implementación

• El banner va en el flujo normal del documento, antes de la navbar: la empuja hacia abajo en vez de taparla, y se marcha con el scroll mientras la navbar queda pegada. Evita pelear por z-index y recalcular paddings.
• La detección cubre iPadOS 13+, que se presenta como Mac y solo se distingue por el soporte táctil.
• El descarte se guarda en localStorage dentro de try/catch: en modo privado de Safari escribir lanza excepción, y ahí es preferible que el aviso reaparezca a que la página se rompa.
• Solo se muestra a usuarios autenticados: instalar antes de tener cuenta no aporta.

[0.24.0] - 2026-09-06 — Soporte de dos motores: MySQL/MariaDB y PostgreSQL

Contexto

El stack declaraba MySQL/MariaDB como único motor mientras el entorno real de desarrollo corría PostgreSQL. La contradicción no era teórica: rompió el panel en producción. Se resuelve declarando ambos motores de primera clase (ADR-0036).

Corregido

• La agrupación por mes rompía en PostgreSQL (SQLSTATE[42601] al abrir el panel). monthKeyExpression() distinguía "o SQLite, o MySQL", así que a PostgreSQL le mandaba DATE_FORMAT —función que no existe allí— con acentos graves, que tampoco acepta como delimitador. Dos errores en una línea: un else que hacía de MySQL el motor por omisión, y un identificador escrito a mano. Ahora los motores se enumeran y el identificador lo cita el grammar de la conexión. La parte que decide se extrajo a monthKeyFor(), pura y testeable, con MonthKeyExpressionTest cubriendo los cinco motores y el caso desconocido. (Corregido en PR #22, que se publicó sin versión propia; queda registrado aquí.)

Añadido

• Job db-engines en CI: la suite completa contra MySQL 8 y PostgreSQL 16 en matriz, con fail-fast: false para que un motor rojo no oculte el estado del otro. Es el único control que impide que vuelva a colarse SQL específico de un motor: el job php seguirá corriendo en SQLite porque es rápido, pero SQLite acepta cosas que los motores de producción rechazan.
• ADR-0036, con las reglas que se derivan de soportar dos motores: match exhaustivo sobre el driver (nunca un else que convierta a uno en predeterminado), identificadores citados por el grammar y nunca a mano, y sin enum de motor en migraciones.

Modificado

• CLAUDE.md: la tabla de stack admite ambos motores, y se añaden las cuatro reglas operativas que hay que respetar al escribir SQL.
• README.md: stack, bloque de configuración con las dos variantes, descripción del CI (cuatro jobs) y dos filas nuevas de troubleshooting — el error de autenticación en cada motor y el 42601 de una función de fecha mal portada.
• docs/DEPLOYMENT.md, docs/ARCHITECTURE.md: ambos motores.
• docs/DATA_MODEL.md: la nota sobre NULL distintos en índices únicos aplica igual a MySQL y a PostgreSQL; se generaliza el texto.

Verificación

Los 559 tests pasan en los tres motores: SQLite (en memoria), PostgreSQL 16 y MariaDB 10.11, ejecutados de verdad, no inferidos. CI cubrirá MySQL 8, que es la variante que no había disponible en el entorno de desarrollo.

Sin cambios de código

No hizo falta tocar la aplicación: el arreglo de monthKeyFor() (PR #22, sin publicar versión propia) ya era el único punto que dependía del motor. Lo que faltaba era garantizarlo.

[0.23.0] - 2026-09-05 — Hardening: performance, auditoría de seguridad y producción (Épica 11, 1.ª pasada)

Corregido (seguridad)

• El formulario «Crear hogar» no llevaba token CSRF. El parcial compartido households/_form no lo incluye y create.blade.php no lo añadía, aunque edit.blade.php sí. En el navegador daba 419 Page Expired: funcionalidad rota además de control de seguridad ausente. Ningún test podía detectarlo porque Laravel desactiva la verificación CSRF durante la suite. (Al comprobarlo a mano hay una trampa: casi toda página autenticada incluye el formulario de cerrar sesión, que sí lleva token, así que buscar name="_token" en el HTML completo da un falso positivo.)
• POST hogares/{household}/invitaciones sin rate limiting, siendo la única acción autenticada que despacha correo a una dirección arbitraria. Sin tope, una cuenta puede quemar la cuota del proveedor y arrastrar la reputación del dominio. Ahora throttle:10,1, como el resto del flujo de invitación.

Rendimiento

Cerrados los 9 puntos de deuda registrados en el roadmap. Medido en aislamiento (una petición por test, sin cachés calientes de peticiones previas):

| Pantalla | Antes | Después | |---|---|---| | /dashboard | 50 consultas | 34 | | /reportes | 28 | 22 | | /cuentas/{id} | 22 | 13 | | monthlyTrend(6 meses) | 12 | 2 |

• AccountController::show: eager loading de category (la vista recorre 20 movimientos leyendo category?->name).
• MovementSummaryService::monthlyTotals(): totales por mes en 2 consultas con GROUP BY en vez de 2 por cada mes; el coste deja de crecer con el rango. La expresión de mes depende del motor a propósito: MySQL no tiene strftime ni SQLite DATE_FORMAT (el roadmap daba por válida strftime para ambos, lo cual habría roto en producción).
• Memoización por hogar+rango: overview() e insights() pedían los mismos totales, y expensesByCategory corría dos veces para el mismo rango.
• DebtService::committedInRange: with('payments') y comprobación en memoria en vez de un exists() por deuda y vencimiento.
• summary() y committedMonthly() aceptan las metas ya cargadas; Panel y Reportes las pasan.
• SavingsGoalService::recalculateAmount: SUM en SQL en vez de materializar cada aporte.
• MovementSummaryService::categoryChartData(): la torta de categorías estaba duplicada entre DashboardController y ReportController, con su color de reserva.
• @percent en las 10 vistas que repetían str_replace('.', ',', …). El helper ahora recorta ceros finales, lo que cubre también las tasas de interés.
• household_id fuera de #[Fillable] en Income y Expense, como ya estaba en el resto de modelos del hogar.

Añadido (tests)

Tres barridos que fijan invariantes, los tres verificados introduciendo el fallo a propósito para comprobar que fallan cuando deben:

• HouseholdIsolationSweepTest: recorre las 53 rutas con parámetro de modelo contra un usuario de otro hogar. Las lecturas deben dar 403/404; en las escrituras un 302 es la validación del Form Request y no un bypass (comprobado: con cuerpo válido responde 403 y la fila no cambia), así que se exige la propiedad real — ninguna fila ajena se altera ni desaparece. Cubre el hueco que los tests por recurso no pueden cerrar: que una ruta nueva se quede sin autorizar.
• CsrfTokenSweepTest: recorre 19 páginas y exige token en cada formulario POST.
• PerformanceTest: fija un techo de consultas por pantalla, por debajo de la cifra anterior.
• FormatHelpersTest: cubre money/percent, incluida la equivalencia con el formateo manual que sustituye.

Documentación

• README: secciones de seeders, cron (la tabla lista las 4 tareas reales del Scheduler, verificadas con schedule:list) y troubleshooting. Instalación desde cero comprobada en un clon limpio: composer install, migrate --seed y el usuario demo demo@finlia.test / finlia123 documentado en el README existe y su contraseña funciona.

Sin hallazgos

Mass assignment ($fillable en todos los modelos, ningún $guarded = []), SQLi (sin interpolación en *Raw), XSS (los dos {!! !!} son json_encode con JSON_HEX_TAG dentro de <script type="application/json">), dinero (DECIMAL en todas las migraciones), datos de tarjeta (no existen las columnas), .env fuera de git y throttle en el resto de rutas sensibles.

Pendiente de la épica

• .env.example sigue siendo el de stock de Laravel: locale en inglés, sin APP_TIMEZONE, con Redis/AWS/Memcached que el proyecto no usa y sin las variables FINLIA_*. El sandbox del agente bloquea escribir rutas .env*, así que queda para aplicar a mano.
• Revisión de cobertura de tests por módulo y auditoría de índices/constraints (el roadmap ya los daba por verificados en la Épica 8).

[0.22.0] - 2026-09-05 — Mejoras de UX: modales, toasts, FAB y exportación asíncrona

Añadido

• Modal de confirmación genérico (#confirmModal): reemplaza todos los confirm() del navegador por un modal Bootstrap 5 que se activa con data-confirm="mensaje" en cualquier <form>. El JS en layouts/app.blade.php intercepta el submit, muestra el modal y, al confirmar, clona el formulario sin el atributo y lo envía.
• FAB flotante bottom-right: el botón "+" ya no ocupa el centro de la barra de navegación inferior (que generaba ruido visual). Ahora es un botón circular fijo en la esquina inferior derecha, siempre visible, igual al botón de componer de X (Twitter). El speed-dial se abre/cierra con animación CSS; backdrop semitransparente al abrirlo; cierre con Escape. La barra inferior queda con cuatro ítems planos: Panel, Movimientos, Presupuesto, Más.
• Toasts Bootstrap 5: los mensajes flash ya no persisten hasta recarga. components/flash-messages.blade.php los renderiza como toasts con auto-dismiss a los 4,5 s y botón de cierre manual. Posición fija top-right, debajo de la navbar.
• Exportación de datos asíncrona por correo (finlia:process-export-requests): en lugar de generar y descargar el ZIP en la misma petición HTTP (riesgo de sobrecarga), la solicitud ahora es un POST que almacena una marca de tiempo en users.data_export_requested_at. Un comando cron ejecuta a las 02:00, genera el ZIP por hogar, lo envía adjunto al correo del usuario con DataExportReadyMail y limpia la marca. Solo se puede tener una solicitud pendiente a la vez. El perfil muestra el estado pendiente mientras espera. Aviso en el modal de confirmación de hasta 3 días hábiles.
• Migración add_data_export_requested_at_to_users_table: columna nullable data_export_requested_at timestamp en users.
• DataExportReadyMail: mailable con plantilla en emails/data-export-ready.blade.php y el ZIP como adjunto.

Modificado

• profile/edit.blade.php: formulario de exportación cambiado a POST con estado pendiente; formulario de eliminación usa data-confirm en lugar de onsubmit.
• routes/web.php: ruta de exportación cambiada de GET a POST (profile.export).
• ProfileController: reemplaza export() por requestExport() (sin descarga directa).
• routes/console.php: registra el comando de exportación en el scheduler (02:00 diario, sin solapamiento).
• User::hasPendingExport(): helper para saber si hay exportación en cola.
• resources/css/app.css: estilos del nuevo FAB (.fab-container, .fab-btn, .fab-menu, .fab-action, .fab-backdrop); eliminados estilos del FAB centrado anterior.
• DataExportTest: reescrito para reflejar el flujo asíncrono (POST, flag, cron, correo); eliminados tests de descarga directa y throttle obsoleto; añadidos tests del comando cron.

Correcciones

• Comando finlia:process-export-requests: eliminada la cláusula wherePivotNull('left_at') (la columna no existe en household_user); ahora usa orderByPivot('joined_at')->first().
• window.bootstrap no estaba expuesto: resources/js/app.js hacía import 'bootstrap' (solo efectos secundarios), por lo que bootstrap.Modal y bootstrap.Toast quedaban indefinidos en los scripts inline de las vistas. Ahora se importa como namespace y se asigna a window.bootstrap. Sin esto, el modal de confirmación lanzaba ReferenceError tras haber llamado a preventDefault(), dejando los botones de eliminar sin efecto.
• Doble manejador de data-confirm: app.js conservaba un manejador con window.confirm() que competía con el modal de la app — el usuario seguía viendo el diálogo del navegador. Eliminado; la confirmación es ahora exclusivamente el modal propio.
• El modal de confirmación ya no clona el formulario: envía con HTMLFormElement.prototype.submit.call(form) (no redispara el evento submit). Si Bootstrap no cargara, degrada a window.confirm() en lugar de dejar el botón muerto; al cerrar el modal sin confirmar, la acción se descarta.
• Confirmación añadida a dos formularios destructivos que no la tenían: eliminar un aporte/retiro de una meta de ahorro (savings/show.blade.php) y eliminar un recordatorio ya completado (reminders/index.blade.php).
• Los toasts se renderizan con la clase show desde el servidor (visibles sin JS) y su auto-cierre se engancha en DOMContentLoaded, ya que app.js es un módulo diferido.
• tests/e2e/budgets.spec.ts: el borrado de presupuesto pasa por el modal de la app, no por un diálogo del navegador — se sustituye page.once('dialog') por el clic en «Sí, continuar». tests/e2e/auth.spec.ts: selector .alert-danger → .toast.text-bg-danger.

Modificado (UX)

• Duración de los toasts proporcional al texto: 60 ms por carácter, acotado entre 4 y 7 segundos, en lugar de 4,5 s fijos. Un aviso corto deja de estorbar antes y uno largo da tiempo a leerse.
• Barra inferior sin hueco: seguía en grid-template-columns: repeat(5, 1fr) con solo cuatro destinos desde que el FAB salió de la barra, dejando una quinta columna vacía a la derecha. Ahora repeat(4, 1fr).
• FAB disponible también en escritorio: antes llevaba d-lg-none y no existía por encima de lg. Se extrae a layouts/partials/fab.blade.php (la barra inferior vuelve a ser solo la barra) y se muestra en todos los tamaños; en escritorio se ancla a bottom/right: 24px, sin barra inferior bajo la que apoyarse.

Corregido (solapamiento del FAB)

El FAB tapaba botones de la página (los «Cancelar» de los formularios, el «Ingreso» del panel). Se ataca por tres vías complementarias:

• La reserva de espacio bajo el contenido nunca se aplicó: la regla body.has-bottom-nav main { padding-bottom: … } competía contra las utilidades p-3 p-md-4 de Bootstrap, que son !important y ganaban siempre — el padding-bottom real era de 16 px, no de los 92 px previstos. Añadido !important; ahora reserva 160 px en móvil (barra + FAB + respiro) y 104 px en escritorio. Esto es lo que evita que en una página corta, sin scroll, los botones del final queden bajo el FAB y sean inalcanzables.
• Auto-ocultado al hacer scroll: el FAB se aparta al bajar y vuelve al subir (patrón Material). Si llega a tapar algo, un gesto mínimo lo descubre. Con el menú abierto no se mueve, y respeta prefers-reduced-motion.
• Oculto en pantallas de formulario (*.create / *.edit): ahí es redundante — ya estás registrando algo — y era justo donde chocaba con Guardar/Cancelar.

[0.21.0] - 2026-09-05 — UX mobile y PWA (Épica 10)

Añadido

• Transferencias entre cuentas (transfers): tabla propia con household_id, from_account_id, to_account_id, amount DECIMAL(15,2), date, description y notes. CRUD completo con TransferController, StoreTransferRequest/UpdateTransferRequest y TransferPolicy. Aislamiento por hogar: las cuentas se validan contra el hogar activo; household_id nunca se acepta del cliente (ADR-0035).
• Recomputo de saldo de cuentas con transferencias (AccountBalanceService): extiende la fórmula de ADR-0012 a initial_balance + Σincomes − Σexpenses + Σincoming_transfers − Σoutgoing_transfers. Ambas cuentas se recomputan en cada escritura dentro de una transacción.
• Transferencias en la lista unificada de movimientos (MovementSummaryService): tipo 'transfer' disponible como filtro; se normaliza con account_name = "origen → destino", sin categoría ni método de pago. La inclusión solo ocurre cuando no hay filtro por category_id.
• FAB speed-dial (botón flotante "+"): reemplaza el enlace simple del bottom nav por un menú de cinco opciones — Gasto, Ingreso, Transferencia, Pago de deuda, Aporte a meta. CSS/JS vanilla, sin dependencias extra; backdrop para cerrar al clicar fuera; foco accesible por teclado (Escape cierra).
• PWA: manifest.webmanifest servido mediante ruta PHP con Content-Type: application/manifest+json (campos: name, short_name, start_url, display: standalone, theme_color, background_color, icons SVG/192/512). Service worker mínimo en public/sw.js (network-first implícito, sin caché inicial). Metas Apple PWA y theme-color en los layouts app.blade.php y guest.blade.php.
• Smart selects (data-smart-select): el último valor de selects de cuenta en gastos, ingresos y transferencias se persiste en localStorage con clave finlia_{householdId}_{key}, pre-seleccionando la opción en el siguiente formulario. Scope por household-id meta para evitar contaminación entre hogares.
• Vistas de transferencias: transfers/create.blade.php, transfers/edit.blade.php y transfers/_form.blade.php con el sistema de diseño glass/hero-card; selects de cuenta con balance actual, data-smart-select y data-money-input en el importe.
• Filtro "Transferencias" en /movimientos: chip y opción en el dropdown de tipo.
• TransferFactory con datos Faker (nunca reales) para tests y seeders.
• 15 tests: 11 en TransferTest (CRUD, recomputo de saldos, validaciones, aislamiento IDOR entre hogares, esquema sin columnas sensibles de tarjeta) + 4 en PwaTest (manifest accesible, campos obligatorios, link en layout autenticado, sw.js existe en public/).

Modificado

• AccountBalanceService::recompute(): incluye incomingTransfers y outgoingTransfers en la fórmula.
• MovementSummaryService: añade filtered() para transfers y applyTransferFilters()/normalizeTransfer().
• MovementsController::filters(): acepta 'transfer' como tipo válido.
• movements/_item.blade.php: renderiza transferencias con icono bi-arrow-left-right y monto neutro (sin signo).
• movements/index.blade.php: chip "Transferencias" y opción en dropdown.
• layouts/partials/mobile-bottom-nav.blade.php: FAB speed-dial (cinco opciones).
• layouts/app.blade.php y guest.blade.php: manifest link, theme-color y metas Apple PWA.
• resources/js/app.js: registro del service worker y módulo de smart selects.
• resources/css/app.css: estilos del FAB speed-dial y display: none del footer en modo standalone.
• expenses/_form.blade.php e incomes/_form.blade.php: data-smart-select en selects de cuenta.
• components/form-select.blade.php: prop smartSelect para emitir data-smart-select.

Notas

• ADR-0035 registrado en docs/DECISIONS.md.
• MovementService::createTransfer/updateTransfer/deleteTransfer no dependen de HTTP (ADR-0010): reciben datos explícitos; listos para la futura API REST (Épica 14).

[0.20.0] - 2026-09-05 — Política de datos y exportación ZIP (Plan 06)

Añadido

• DataExportService: genera un ZIP con 12 CSVs (cuentas, ingresos, gastos, presupuestos, gastos recurrentes, deudas, pagos de deuda, refinanciaciones, metas de ahorro, aportes, recordatorios, perfil del usuario) + finlia.json (todos los datos en JSON para migración)
  • README.txt explicativo del formato. Reglas de privacidad: nunca exporta la contraseña ni datos personales de otros miembros del hogar. collect() separado de buildZip() para testabilidad sin disco.
• CSV con BOM UTF-8 y separador ;: abre directamente en Excel Colombia sin configuración. Montos con coma decimal (ej. 1500000,00). Fechas en DD/MM/AAAA.
• Ruta GET /perfil/exportar → profile.export con throttle de 3 descargas por día (throttle:3,1440). Responde ZIP descargable; 404 si el usuario no tiene hogar activo.
• Página pública GET /datos → data.policy (DataPolicyController): accesible sin cuenta. Explica qué datos guarda Finlia, portabilidad, eliminación de cuenta, política de retiro del software y cómo migrar a otra herramienta.
• "Mis datos" en /perfil: tarjeta con descripción y botón "Exportar mis datos" (enlaza a profile.export). Máximo 3 descargas al día.
• Footer actualizado en app.blade.php y guest.blade.php: incluye enlace "Tus datos" junto a "Términos".
• 18 tests cubren: redirect de invitado, ZIP descargable, nombre con ID + fecha, 404 sin hogar, throttle 3/día, perfil sin contraseña, gastos con montos, deudas, metas, JSON maestro sin contraseña, BOM UTF-8, separador ;, aislamiento entre hogares, privacidad de otros miembros, y página /datos accesible y con secciones de portabilidad/eliminación.

Notas

• DataExportService no depende de HTTP (ADR-0010): recibe Household + User explícitos, no usa request() ni Auth::. Listo para futura API REST (Épica 14).
• Los campos enum se serializan con ->value (no como objeto PHP) para compatibilidad CSV/JSON.
• ADR-0034 registrado en docs/DECISIONS.md.

[0.19.0] - 2026-09-04 — Eliminación de cuenta: suspensión 30 días y purga (Plan 05)

Añadido

• Columna users.deletion_requested_at: timestamp nullable. null = cuenta activa; timestamp = suspendida. Migración 2026_09_04_000200_add_deletion_requested_at_to_users_table.
• User::isSuspended() / User::deletionDeadline(): helpers limpios sin lógica de fechas en controladores (ADR-0033).
• AccountDeletionService: tres reglas de purga (cascade para dueño único, transferencia al miembro más antiguo con notificación por correo, anonimización para el resto). Separado de HTTP: recibe el User, devuelve resultado — listo para el futuro endpoint de API.
• EnsureAccountActive middleware alias account.active: bloquea el acceso al nivel-3 de rutas si la cuenta está suspendida y redirige a /cuenta/suspendida.
• AccountSuspensionController: muestra la pantalla de suspensión con fecha límite y ofrece reactivación en un clic (limpia deletion_requested_at, redirige al dashboard).
• Zona de peligro en /perfil: sección colapsable con confirmación de contraseña (DeleteAccountRequest) → marca suspensión, cierra todas las sesiones y redirige al login.
• AccountDeletionRequestedMail + vista HTML/texto: correo antifraude con fecha límite y enlace de reactivación, enviado fuera de la transacción (un SMTP caído no revierte la suspensión).
• OwnershipTransferredMail + vista HTML/texto: avisa al nuevo propietario del hogar.
• PurgePendingDeletions command (finlia:purge-pending-deletions): purga diaria de cuentas con ventana expirada (>30 días) y cuentas fantasma sin verificar (>14 días). Programado a las 05:30 (antes de recurrentes y digest).
• SendReminderDigests actualizado: excluye miembros con deletion_requested_at no nulo.
• 15 tests cubren: bloqueo de navegación, reactivación, solicitud con contraseña errónea, correo antifraude, tres reglas de purga, purga de fantasmas y exclusión del digest.

Notas

• La reactivación es deliberadamente fácil: iniciar sesión + un botón (no hace falta un "código de arrepentimiento"). El correo antifraude cumple la doble función de aviso y enlace de regreso.
• deletion_requested_at no está en $fillable (campo interno, no expuesto en forms de usuario); el servicio usa asignación directa ($user->deletion_requested_at = …; save()).
• purge() usa forceFill para sobrescribir en un solo paso y captura el email original antes de anonimizarlo (limpia password_reset_tokens con la dirección real).

[0.18.0] - 2026-08-30 — Datos personales: nacimiento, región y género (Plan 04)

Añadido

• Fecha de nacimiento en el registro (18+): obligatoria y solo para mayores de edad — regla compartida AdultBirthDate (fecha real del pasado, no anterior a 1900, no futura) con el corte inclusivo de "quien cumple 18 hoy entra". Finlia maneja las finanzas de un hogar: nada de consentimiento parental (ADR-0032).
• Sección "Datos personales" en /perfil: nacimiento + región y género opcionales. Región = los 32 departamentos y Bogotá D.C. (enum fijo ColombianRegion, no tabla); género en lista cerrada (Gender) donde "Prefiero no decirlo" no almacena nada (NULL). La pantalla declara la finalidad: mayoría de edad y estadísticas agregadas, nunca decisiones financieras ni compartirlos (minimización, Ley 1581).
• User::age(): la edad se calcula desde birth_date, nunca se guarda — lo derivable no ocupa columna (listo para la analítica de la Épica 12).

Notas

• Región y género no se piden en el registro (menos fricción de entrada); el perfil los completa. Hobbies e intereses quedan fuera por diseño: cada dato futuro necesitará caso de uso escrito y su eliminatoria en la purga (plan 05).
• Usuarios heredados: birth_date es nullable en DB; su primera edición del perfil la completa. La purga (plan 05) pondrá los tres campos en NULL y el export (plan 06) los incluirá.
• Sin cambios en .env, correos ni rutas. Migración: users gana birth_date/region/gender.

[0.17.0] - 2026-08-30 — Términos y condiciones versionados (Plan 03)

Añadido

• Re-aceptación obligatoria de términos: sin aceptar la versión vigente, el middleware terms.current redirige toda la app a la pantalla de aceptación — un solo mecanismo cubre el registro nuevo y el cambio de términos (ADR-0031). Orden de puertas: primero correo verificado, luego términos.
• Prueba de consentimiento inmutable: cada aceptación registra versión exacta, fecha e IP en user_terms_acceptances; una versión aceptada no se puede borrar de la base de datos (FK RESTRICT). Las versiones son filas que nunca se editan: cambiar los términos = publicar una nueva (prueba ante un reclamo, Ley 1581).
• Pantalla de aceptación sin trampas oscuras: texto completo en scroll, resumen de "qué cambió" cuando ya había una aceptada, y dos salidas — Aceptar y continuar, o No aceptar, que lleva a una pantalla honesta que no destruye nada (rechazar jamás borra datos; exportar/eliminar llegarán con los planes 05/06 y enlazarán allí).
• Lectura pública de la vigente en /terminos y del histórico en /terminos/{version} (la referencia externa de qué aceptó cada usuario); enlace "Términos" en el footer.
• Seeder de la versión inicial 2026-09-v1 como BORRADOR con marcadores: la redacción legal definitiva es del dueño del producto; al existir, se publica como versión nueva — la actual jamás se edita.

Notas

• Sin versión publicada la app se usa normal (fail-open): el mecanismo solo obliga cuando hay texto que consentir. Los usuarios demo del seeder ya traen la aceptación registrada.
• Sin cambios en .env, correos ni cron. Migraciones: las tablas nuevas terms_versions y user_terms_acceptances.

[0.16.0] - 2026-08-30 — Perfil: contraseña y cambio de correo (Plan 02)

Añadido

• Pantalla /perfil (menú del avatar → "Mi perfil"): nombre, contraseña y correo con su estado. Preferencia del usuario, no del hogar — sin IDs ajenos en la URL, solo el autenticado existe (ADR-0030).
• Cambio de contraseña con re-autenticación: pide la contraseña actual y al cambiarla revoca las demás sesiones y cookies de "recuérdame" (middleware AuthenticateSession); la sesión actual sigue viva. Aviso al propio correo con la vía de recuperación si no fuiste tú.
• Cambio de correo con doble confirmación: el correo nuevo queda pendiente hasta que esa bandeja confirma el enlace (token de un uso, 60 min, guardado hasheado). Confirmar marca el correo como verificado, conserva hogares/preferencias/sesión, y avisa al correo anterior — la pierna antifraude del flujo. Coherente con el anti-squatting del registro: un fantasma sin verificar no bloquea el cambio, una cuenta verificada sí.

Cambiado

• La política de correo pasa a 7 correos (+3 transaccionales de seguridad del perfil — tabla de ARCHITECTURE §7).
• La recuperación de contraseña por correo ahora cierra las demás sesiones por construcción (re-hashea la contraseña): una cuenta comprometida se limpia con un reset.

Notas

• Sin cambios en .env ni en el cron. Migración solo añade las columnas pending_email* a users.

[0.15.0] - 2026-08-30 — Verificación de correo en el registro (Plan 01)

Añadido

• Verificación de correo obligatoria al registrarse: la cuenta se crea completa (usuario + hogar) pero la app queda bloqueada hasta confirmar el correo — el middleware verified cubre todo lo privado; sin confirmar solo son alcanzables cerrar sesión, el aviso "Revisa tu correo" y el reenvío (ADR-0029). Corolario: un usuario sin verificar no puede crear ningún dato.
• Correo de verificación propio en español (estilo de marca, HTML + texto plano, patrón de la invitación y el digest) con enlace firmado a 60 min, público: el click funciona desde el buzón con o sin sesión. Reenvío desde el aviso con throttle de 3/min por usuario y pista de "revisa spam".
• Anti-squatting: si alguien registró tu correo y nunca lo verificó, ese registro no te bloquea — al registrarte de nuevo, el fantasma y su hogar vacío se borran y tu cuenta se crea limpia. Un correo solo cuenta como tomado si está verificado. "Olvidé mi contraseña" queda como vía de recuperación universal.

Cambiado

• El digest de recordatorios excluye correos sin verificar (cinturón y suspenderes: nunca correos periódicos a direcciones sin confirmar, que pueden ser de otra persona).
• La política de correo pasa a 4 correos (invitación, contraseña, digest, verificación — tabla de ARCHITECTURE §7).

Notas

• Migración de datos: los usuarios ya registrados quedan verificados de oficio (base de desarrollo; nadie "verificó de verdad" porque el flujo no existía).
• Sin cambios en .env ni en el cron: usa el SMTP ya configurado y no añade comandos.

[0.14.0] - 2026-08-29 — Recordatorios y notificaciones (Épica 9)

Añadido

• Página /recordatorios con la lista unificada de todo lo que vence: gastos recurrentes, cuotas de deuda, metas con fecha y avisos propios del usuario, agrupada en vencidas / vencen pronto (7 días) / más adelante, con la acción de cada origen al alcance (marcar pagado, ir a la deuda, aportar a la meta). Los avisos derivados no se duplican en tabla: se calculan en vivo desde su fuente, así que nunca quedan caducados aunque el cron no corra (ADR-0027).
• Avisos sueltos del usuario ("obligación anual": tecnomecánica, pasaporte, predial) con alta, edición, borrado y "atender": si se repite avanza una frecuencia y sigue pendiente; si es de una sola vez queda completado. Atender no genera gasto — un recordatorio es un aviso, no un movimiento.
• Campanita en el navbar con el conteo urgente (vencidas + próximas) y desplegable de resumen, presente en todas las páginas autenticadas.
• Banner en el Panel: "🔔 Tienes N obligaciones próximas (M vencidas)" con enlace directo a la lista, en tono informativo (no de alarma).
• Casilla "Registrar el pago solo cuando llegue la fecha" en gastos recurrentes (auto_generate) y comando del Scheduler finlia:generate-recurring-payments (diario 06:00, compatible con el cron de Hostinger): registra el gasto vencido reutilizando "Marcar pagado" — una ocurrencia por corrida con su fecha real, para que un atraso de N meses se recupere en N días sin una ráfaga fechada "hoy" (ADR-0018).
• Interruptor del hogar (households.reminders_enabled, solo el administrador): apaga campanita, banner y listado de todo el hogar de una vez, sin borrar datos.
• Campanita sin costo por página: el conteo de la campanita va con caché corta invalidada por eventos de modelo (cachedSummary + ReminderSummaryCacheObserver: cualquier cambio en recurrentes, deudas/pagos, metas/aportes, avisos o el hogar borra la clave de ese hogar; el TTL de 10 min solo cubre el paso de medianoche). La página /recordatorios sigue leyendo el estado fresco (list() no se cachea).
• Digest diario opcional por correo (ADR-0028): quien lo activa en /recordatorios ("Resumen por correo") recibe un correo al día (06:30) con sus obligaciones urgentes — solo si las hay, opt-in por miembro y hogar, jamás marketing. Comando del Scheduler finlia:send-reminder-digests, envío síncrono por SMTP (Brevo free en producción, ver docs/DEPLOYMENT.md §4) e idempotente (last_reminder_digest_at: reintentos del cron no duplican); las tareas del Scheduler llevan withoutOverlapping(). El Mailable ReminderDigest trae HTML autocontenido en español + texto plano y no marca nada como leído: el aviso se apaga pagando.
• Baja de un click desde el correo (RFC 8058): el digest trae "Ya no quiero recibir este resumen" con URL firmada por usuario y hogar (60 días, sin sesión); las cabeceras List-Unsubscribe/List-Unsubscribe-Post hacen que Gmail/Yahoo ofrezcan su botón nativo de cancelación, que ejecuta la baja con un POST (respuesta 204). Bajar del digest de un hogar no toca el de otro; la firma inválida da 403.
• 46 tests nuevos (estados derivados, cuota de deuda pagada/impaga, resumen, atender, aislamiento multi-hogar, comando del scheduler, invalidación de caché, digest por correo y baja desde el correo) — suite total: 407 en verde.

Cambiado

• El seeder de demo incluye tres avisos sueltos (uno vencido, uno próximo, uno anual lejano) y activa la generación automática en la suscripción de internet, para que la página y la campanita muestren los tres estados desde el primer arranque.

[0.13.0] - 2026-08-29 — Reportes financieros (Épica 8)

Añadido

• Pantalla de reportes (/reportes) con los cinco gráficos de la épica: gastos por categoría, ingresos vs gastos, evolución mensual del balance, evolución de la deuda y progreso de metas (barras horizontales apiladas: ahorrado + faltante). Cada gráfico con su estado vacío; la deuda se dibuja a fin de cada mes de los últimos seis y respeta refinanciaciones y pagos reales (ADR-0020).
• Comparación de períodos con chips — mes actual, mes anterior, últimos 3, últimos 6, año — que muestran ingresos, gastos y balance del período contra su equivalente anterior (mes contra mes previo, año YTD contra el mismo tramo del año pasado: nunca contra meses que aún no han ocurrido). Deltas absolutos siempre; porcentuales solo cuando la base anterior existe.
• Observaciones (insights) descriptivas: hechos calculados — "Gastaste $ 150.000,00 menos que en julio 2026", "«Alimentación» aumentó 18 %", "balance en rojo" — con umbrales anti-ruido (≥ 5 % el total, ≥ 15 % una categoría) para que la pantalla no grite con cambios de calendario. Sin recomendaciones financieras; máximo cuatro por período.
• Exportación CSV de los movimientos del período (/reportes/exportar), en streaming con BOM UTF-8, separador ; y coma decimal: Excel en español lo abre bien sin importar nada. Con rate limiting (throttle:10,1). El enum ReportFormat queda como seam del PDF Premium (Épica 12): añadirlo es un caso nuevo del enum y una rama del controlador, no un rediseño.
• El Panel gana solo lo que le falta: KPIs de deuda total y ahorro en metas, y el enlace "Ver reportes". La guía mobile de la propia épica pedía no amontonar gráficos; el Panel responde "¿cuánto puedo gastar hoy?" y los reportes "¿qué ha pasado?" (ADR-0026).

Cambiado

• Las tortas (Panel y Reportes) muestran top 5 categorías + "Otras": con muchas categorías, el gráfico de gastos por categoría era una rueda de porciones ilegibles. El resto se pliega en una fila "Otras" (gris neutro, suma real del resto) tanto en el Panel como en Reportes; los cálculos internos (insights, comparaciones) siguen usando la lista completa.
• La lista de Movimientos carga de a 20 con "Cargar más" (antes traía 200 de golpe). El botón pide la siguiente página de la misma ruta conservando los filtros y anexa los grupos con JavaScript mínimo (fetch + insertAdjacentHTML). El corte de página nunca parte un día por la mitad: si los 20 caen dentro de un grupo, la página se extiende hasta cerrarlo, para no ver el mismo día repetido en dos pantallas. El "Balance del filtro" sigue siendo el de todo el filtro, no el de la página visible.

Corregido

• Los gráficos del Panel llevaban rotos desde la Épica 3: el JSON de datos se inyectaba con {{ }} dentro de <script type="application/json"> y Blade escapa " a ", que los navegadores no decodifican dentro de <script> — JSON.parse fallaba en silencio. Ahora se inyecta con json_encode(..., JSON_HEX_TAG), que es JSON válido e inyectable con seguridad.

Seguridad

• Sin hogares ajenos en los reportes: todas las consultas salen del hogar activo en sesión y hay test que verifica que el CSV de un hogar no contiene movimientos de otro.
• El período y el formato llegan por query y se validan con reglas in: contra los enums cerrados: un valor inventado es un error de validación con mensaje, no una excepción ni un camino nuevo. No hay household_id en la petición que suplantar.
• Ruta de exportación con throttle:10,1 (peticiones por minuto y usuario).
• El CSV neutraliza la inyección de fórmulas (OWASP): los textos controlados por el usuario —descripción, categoría, cuenta, quien registra— que empiezan por =, +, - o @ se prefijan con ' para que Excel no los evalúe como fórmula al abrir el archivo. Con test de regresión; detectado en la pasada /security-checklist.

[0.12.0] - 2026-08-31 — Metas de ahorro (Épica 7)

Añadido

• Panel de metas de ahorro (/metas) con resumen del hogar (total ahorrado, objetivo, aporte mensual programado), filtro por estado —vigentes, logradas, archivadas— y aviso de metas vencidas. Alta con prioridad, fecha objetivo opcional (una meta sin fecha es abierta, como el fondo de emergencia) y marca de fondo de emergencia.
• Detalle con historial: progreso hacia el objetivo, aporte o retiro puntual con nota, y aporte mensual recomendado — lo que falta repartido en los meses que quedan — marcado siempre como estimación (misma honestidad que las proyecciones de deuda).
• Acciones de estado: pausar, reactivar, marcar lograda y archivar, cada una con su propósito (pausar deja de comprometer el aporte; archivar saca la meta del panel sin perder el historial). Nada de cambiar el estado con un select del formulario.
• El ahorro entra al dinero disponible (ADR-0025): el «aporte mensual que destinarás» de cada meta activa suma al término savings del comprometido (ADR-0014), tope el faltante de la meta — la última cuota nunca supera lo que falta. Pausar una meta libera ese dinero al instante.
• Tarjeta de metas en el dashboard con el progreso de las tres metas más urgentes (prioridad alta primero, luego fecha objetivo).

Decisiones (ADR-0025)

• Lo ahorrado no se teclea: es derivado del historial (Σ aportes − Σ retiros), como el saldo de las deudas (ADR-0020). Lo que ya tenías se registra como aporte inicial. Al cubrir el objetivo la meta pasa a lograda sola, y si borras el movimiento vuelve a activa.
• Registrar un aporte no mueve cuentas ni crea gastos: ahorrar no es gastar, y contar el aporte como salida haría bajar el disponible dos veces. La transferencia real entre cuentas llega con el botón "+" de la Épica 10.
• Los retiros no pueden superar lo ahorrado, y las metas logradas o archivadas no aceptan movimientos — con mensajes que dicen el estado, no un «dato inválido».

Seguridad

• Aislamiento por hogar cubierto con Policy y test: otro hogar recibe 403 al ver, editar, borrar o aportar a una meta ajena; household_id no es asignable en masa y un intento de suplantarlo al crear se ignora (test incluido).
• La autorización corre antes de validar en el registro de aportes (mismo patrón que gastos/ingresos): las reglas que dependen de la meta incrustan su estado y su saldo en los mensajes de error, así que un usuario ajeno recibe 403 sin que la validación llegue a revelar cifras de otro hogar — detectado en revisión de seguridad y cubierto con test.
• Dinero en DECIMAL(15,2) y fechas de movimiento acotadas a hoy hacia atrás.

[0.11.0] - 2026-08-31 — El aviso de estimación se puede dar por leído

Añadido

• El aviso de deudas se puede descartar, pero no desaparece: se reduce a una línea (ADR-0024). En móvil ocupaba media pantalla en cada visita, y un aviso que se ve siempre deja de leerse. Ahora la primera vez sale completo con «Entendido, no mostrar de nuevo» y a partir de ahí queda un recordatorio discreto que sigue junto a las cifras: que la advertencia se esfume del todo es el escenario que en una app de finanzas paga el usuario con su dinero.
• Mecanismo genérico de avisos leídos (user_acknowledgements), por clave y no por columna: las metas de ahorro y los reportes traerán advertencias parecidas y lo reutilizan sin tocar users. La constancia va en el servidor, así que persiste entre dispositivos, sobrevive a un borrado de datos de navegación y queda con fecha.

Seguridad

• La clave del aviso llega en la URL y se valida contra un enum cerrado: una clave inventada es un 404, no una fila basura en la tabla.
• El acuse es siempre del usuario autenticado; el user_id no sale nunca de la petición, así que no hay forma de marcar el aviso de otra persona. Cubierto con test.
• Funciona sin JavaScript: es un formulario normal con @csrf.

[0.10.1] - 2026-08-30 — Aviso de estimación y ancho de la barra lateral

Añadido

• Aviso visible de que las cifras de deuda son aproximadas, en las tres pantallas donde el usuario lee un número: al registrar, en el panel y en el detalle. Nuevo componente <x-debt-disclaimer />, para que el texto viva en un solo sitio. Sustituye al pie de página en gris que solo estaba en el panel y al inciso escondido dentro de la proyección: en una app de finanzas, confundir una estimación con un estado de cuenta lo paga el usuario con su dinero.

Corregido

• Al registrar un pago, el tipo «Cuota pactada» pasa a llamarse «Cuota mensual», que es como se llama el campo en el formulario de la deuda desde la 0.9.0. El valor guardado (scheduled) no cambia: renombrar la etiqueta no obliga a migrar los pagos ya registrados.
• La barra lateral se encogía según el contenido de la página (132 px en el panel de deudas, 201 en presupuestos, 230 en el panel, frente a los 264 previstos), partiendo los rótulos en dos líneas. Le faltaba flex-shrink: 0: como flex item, width no impide que el hermano la comprima. Bug preexistente, no introducido por las deudas; ahora mide 264 px en todas las pantallas y en móvil sigue siendo un offcanvas oculto.
• El detalle de deuda sugería «añade el pago mínimo o la cuota pactada», nombres que dejaron de existir en la 0.9.0.

[0.10.0] - 2026-08-30 — El alta de deudas, como un simulador de crédito

Cambiado

• Registrar una deuda se mueve a su propia pantalla con un botón en la cabecera del panel (w-100 w-sm-auto: ancho completo en móvil, botón normal en escritorio). Adquirir deuda es puntual y no tenía sentido que el formulario ocupara media pantalla siempre (ADR-0023).
• El formulario funciona como un simulador de crédito: declaras monto, tasa y número de cuotas, y la aplicación calcula cuota mensual, fecha de fin e intereses totales mientras escribes. Es el orden en que lo pide cualquier banco, y el inverso del anterior.
• La cuota se muestra calculada y bloqueada, con un interruptor «Mi entidad cobra otra cuota» para ajustarla cuando hay seguros o cuota de manejo de por medio.
• Los campos de dinero pasan a data-money-input (punto de miles colombiano), como manda docs/UI_DESIGN.md; antes usaban type="number".

Corregido

• Se podía registrar una deuda imposible. Con 10.000.000 en 120 cuotas y un plan de 20.000 al mes la aplicación guardaba sin protestar y luego calculaba, con razón, 500 meses. Ahora se valida en el servidor que la cuota cubra los intereses y baste para el plazo pactado, y el mensaje dice cuánto haría falta (83.333,34 en ese caso), no solo que está mal.
• La tasa anual se interpretaba como nominal. Se dividía entre 12 cuando en Colombia el crédito se cotiza en efectiva anual: la mensual equivalente es (1+EA)^(1/12)−1. Con 28,5 % E.A. se calculaba 2,375 % mensual en vez del 2,114 % real, sobreestimando los intereses.
• El simulador y la proyección podían discrepar en un mes por redondeo: la cuota se redondeaba al céntimo más cercano y se quedaba corta. Ahora se redondea hacia arriba, como hacen los bancos, y pagar la cuota calculada salda la deuda en el plazo exacto (verificado de 36 a 240 cuotas).
• Los datos de demostración tenían una cuota mínima incoherente con su monto y plazo. Ahora la deriva el Service, así que el seeder no puede generar una deuda imposible.

Seguridad

• La confirmación de borrado pasa a data-confirm, el mecanismo que ya existía en app.js para no meter datos del usuario dentro de JavaScript en línea. Sustituye al parche con @js() de la 0.8.2 y elimina el JS en línea por completo; el test de regresión ahora comprueba que ningún manejador en línea lleva datos del usuario.

[0.9.0] - 2026-08-30 — Correcciones de uso y plazo de las deudas

Corregido

• «Balance del mes» no mostraba icono: bi-scale no existe en Bootstrap Icons, y un bi-* mal escrito no da error, simplemente no pinta nada. Se usa bi-plus-slash-minus. Un barrido de los 2078 iconos del paquete confirma que era el único roto, y ahora hay un test que lo comprueba en cada ejecución.
• El mes de la proyección de deuda salía en inglés: translatedFormat usa el locale global de Carbon, que su service provider sincroniza con APP_LOCALE. Con APP_LOCALE=en —lo que trae la plantilla de Laravel— se veía «December de 2028» aunque el resto de la interfaz estuviera en español, porque esa está escrita a mano en Blade. Se fija el locale en la instancia, como ya hacían los otros cinco sitios del repo que formatean fechas.
• Los últimos movimientos se ordenaban de forma arbitraria y perdían registros. La columna date es DATE, sin hora, y el orden era orderByDesc('date') a secas: todos los movimientos del mismo día empatan y su orden queda a criterio del motor. Como el LIMIT se aplica sobre ese orden, un movimiento recién creado —el de «marcar pagado» de un recurrente, o un pago de deuda— podía no aparecer. Ahora se desempata por created_at y luego por id.
• El mismo método tomaba N movimientos de cada tabla y las mezclaba sin recortar: el panel pedía 6 y recibía hasta 12.

Cambiado

• La deuda se pacta en cuotas, no en una fecha (ADR-0022): end_date deja de teclearse y pasa a derivarse de start_date + term_months. Cada tipo tiene su tope de cuotas (tarjeta 100, vehículo 96, hipotecario 480, resto 120), pensados para atajar errores de dedo, no como límites legales.
• Nuevo tipo de deuda: crédito hipotecario. Su plazo no cabía en ningún tipo existente.
• scheduled_payment pasa a planned_payment, y los dos campos se explican por lo que son: cuota mínima es lo que exige la entidad, lo que planeas pagar es lo que tú decides (vacío = solo el mínimo). Se valida que el plan nunca quede por debajo del mínimo. El comportamiento no cambia: lo que sale del bolsillo cada mes ya era plan ?? mínimo.

Seguridad

• type[]=x en el alta de deuda habría devuelto 500 por el mismo cast inseguro que se corrigió en 0.8.2 para ?estrategia[]=. Se comprueba el tipo antes de resolver el enum, con test.

[0.8.2] - 2026-08-29 — Revisión de seguridad de la Épica 6

Seguridad

• XSS almacenado en el detalle de deuda (introducido en 0.8.0). El nombre de la deuda se interpolaba con {{ }} dentro del onsubmit del formulario de borrado. En un manejador en línea el navegador decodifica las entidades HTML antes de compilar el JavaScript, así que el ' del escape volvía a ser una comilla y cerraba el literal: un nombre como x');alert(1);// ejecutaba código en el navegador de cualquier miembro del hogar que pulsara «Eliminar deuda». Ahora se usa @js() (Js::from()), que escapa para contexto JavaScript. El test de regresión decodifica el atributo igual que hace el navegador y se ha comprobado que falla si se revierte a {{ }}.
• Se documenta la regla general en docs/SECURITY.md §5: {{ }} protege contexto HTML, no contexto JS; para datos de usuario dentro de JavaScript, @js() o un atributo data-*.

Corregido

• ?estrategia[]=x en el panel de deuda devolvía 500: query() devuelve un array y castearlo a string emite un warning que Laravel convierte en excepción. Ahora se comprueba el tipo y se cae a la estrategia por defecto.

[0.8.1] - 2026-08-29 — El correo de recuperación, en español

Corregido

• El correo de recuperación de contraseña salía en inglés. Usa la notificación nativa de Laravel, cuyo texto vive en el framework, y el proyecto no tenía lang/es.json. Ahora el asunto, el cuerpo, el botón, la subcopia y el pie están en español, de modo que los dos únicos correos de Finlia (ADR-0015) hablan el mismo idioma.
• Las claves de lang/es.json deben coincidir carácter a carácter con las cadenas del framework —incluidos el salto de línea y las comillas escapadas de la subcopia del botón— o la traducción se ignora sin avisar. Se añaden 5 tests que renderizan el correo real y fallan si vuelve a aparecer texto en inglés, en lugar de comprobar solo que el archivo existe.

Notas

• .env.example sigue sin el bloque MAIL_*: el archivo está bloqueado para escritura en el entorno de trabajo actual. La configuración completa (SMTP de Hostinger, SPF/DKIM) está en docs/DEPLOYMENT.md §4 y hay que copiarla a mano.

[0.8.0] - 2026-08-29 — Deudas y tarjetas de crédito (Épica 6)

Añadido

• Panel de deuda: deuda total, pago mensual comprometido y progreso de amortización del hogar, con listado por deuda y su barra de avance.
• debts: tarjetas, préstamos, crédito de vehículo, préstamo familiar y otras, con entidad, tasa (fija/variable), pago mínimo, cuota pactada, día de pago, fechas y estado (DebtType, DebtStatus, InterestRateType). Borrado lógico: una deuda saldada es historia financiera, no ruido.
• Historial de pagos (debt_payments) con tipo mínimo/cuota/abono extra. Registrar un pago baja el saldo; borrarlo lo devuelve.
• Refinanciación (debt_refinancings): nuevas condiciones (tasa, plazo, cuota) y nuevo saldo de partida, con su historial.
• Tarjetas de crédito (credit_cards) como atributos de una cuenta type=credit_card (ADR-0002, que estaba ACEPTADA y quedaba por implementar): cupo, cupo disponible, día de corte, día límite de pago y cuota de manejo, con indicador de uso del cupo y aviso al superar el 30 %.
• Proyección de fin de deuda: "si mantienes este ritmo, terminarías hacia…", amortizando mes a mes con la tasa. Se presenta siempre como estimación y detecta el caso en que la cuota no cubre los intereses, donde decirlo es más útil que dar una fecha inventada.
• Estrategias avalancha y bola de nieve (DebtStrategy) como criterio de orden. La épica pedía preparar la arquitectura, no resolver el plan de pagos: el reparto del excedente entre cuotas queda fuera de alcance.
• Deudas de demostración en DatabaseSeeder (datos siempre falsos).
• Tests: 19 unitarios de DebtService (saldo derivado, refinanciación, proyecciones, estrategias, seam del dinero disponible) y 26 de feature con CRUD, validación, pagos con y sin cuenta, mass assignment sobre el saldo y 11 de aislamiento entre hogares.

Cambiado

• BudgetCalculatorService rellena el término debt, que la Épica 4 dejó declarado en cero (ADR-0014). El desglose "¿Cómo se calcula?" ya no muestra "Épica 6" sino las cuotas pendientes reales.
• El saldo de una deuda es derivado, no se teclea (ADR-0020): línea base − pagos, donde la línea base es el monto original o el saldo de la última refinanciación. No es fillable y el Form Request no lo acepta.
• Un pago con cuenta asociada genera el movimiento real (ADR-0021), en la misma transacción, para que el saldo de la cuenta no mienta. Las cuotas ya pagadas salen del comprometido: sin esa resta, pagar una deuda bajaría el "puedes gastar" dos veces.
• DATA_MODEL.md cierra el marcador ⚖️ de ADR-0002, que llevaba pendiente desde la Épica 3 pese a que la decisión ya estaba ACEPTADA en DECISIONS.md.
• "Deudas" pasa de marcador deshabilitado a entrada real del menú.

Corregido

• Vista de detalle de cuenta: un @php(...) en línea combinado con un bloque @php … @endphp posterior hacía que Blade emparejara mal las etiquetas y dejara de compilar el resto del archivo. Se usa la forma de bloque.

Seguridad

• Nunca se almacena número completo de tarjeta, CVV ni PIN: esas columnas no existen en credit_cards y el Form Request no las acepta. Hay un test que lo verifica contra el esquema real, no contra el código.
• Los intereses no se acumulan solos (ADR-0020): el saldo solo baja con los pagos. Está documentado en la UI y se corrige registrando una refinanciación con el saldo real, en lugar de simular una amortización precisa pero falsa.

[0.7.0] - 2026-08-27 — Gastos recurrentes y obligaciones futuras (Épica 5)

Añadido

• Gastos recurrentes (recurring_expenses): frecuencias semanal, quincenal, mensual, trimestral, semestral, anual y personalizada (cada N días), con próxima fecha, categoría y cuenta opcionales, pausa y notas. Vista "Próximas obligaciones" agrupada (vencidas / esta semana / más adelante) con días restantes y alerta de obligaciones vencidas y a ≤ 30 días también en el Panel.
• "Separa ~X al mes": ahorro mensual necesario por obligación (SOAT $600.000 anual → separa $50.000/mes) y total mensual en la cabecera de la vista.
• "Marcar pagado": registra el gasto real en la cuenta asociada (recomputando su saldo) y avanza la próxima fecha dentro de una transacción — la ocurrencia sale del comprometido exactamente cuando entra al gastado, sin duplicar (ADR-0018).
• Enum Frequency con aritmética de fechas segura en años bisiestos (addMonthNoOverflow/addYearNoOverflow), factory, policy, form requests y 44 pruebas nuevas (unitarias del servicio + CRUD/aislamiento por hogar + integración con el calculador).

Cambiado

• El cálculo de dinero disponible ahora resta los gastos recurrentes reales del hogar, rellenando los seams fixed_expenses (arriendo, servicios — alta frecuencia) y recurring (SOAT, matrícula — baja frecuencia) declarados en cero por la Épica 4 (ADR-0014); la fórmula y la UI del calculador no cambian, y el desglose "¿Cómo se calcula?" de Presupuestos pasa de "próximamente" a montos reales.
• El seeder de demo incluye arriendo, internet, SOAT y mantenimiento para que el Panel y las obligaciones muestren datos desde el arranque.

Seguridad

• Corregida una fuga entre hogares presente desde la 0.3.0 (amenaza #1). Las Policies autorizaban contra el hogar del recurso mientras los Form Requests acotaban account_id/category_id al hogar activo en sesión. Para un usuario miembro de varios hogares esos dos hogares no coinciden: con el hogar A activo se podía editar un recurso del hogar B enlazándole una cuenta de A. Consecuencias reproducidas: el saldo de una cuenta de A cambiaba por actividad de B, y un miembro de B sin relación alguna con A veía el nombre de esa cuenta en sus movimientos.
• Autorizar un recurso financiero exige ahora dos condiciones: ser miembro del hogar dueño y que ese hogar sea el activo (ADR-0019). El invariante vive en un trait único, ChecksHouseholdAccess, compartido por las siete policies de recursos financieros. HouseholdPolicy queda fuera a propósito: gestionar o activar un hogar debe poder hacerse desde fuera de él.
• UpdateRecurringExpenseRequest autoriza antes de validar, como ya hacía UpdateExpenseRequest: un usuario ajeno recibe 403 y no 422, sin importar los datos.
• Nuevo MultiHouseholdIsolationTest (9 casos): cubre el escenario multi-hogar que los tests de aislamiento clásicos no alcanzaban, porque usan un intruso que no es miembro de nada y la membresía ya lo frenaba.

[0.6.0] - 2026-08-27 — Identidad de marca

Añadido

• Identidad de marca Finlia adoptada (ADR-0017): símbolo de treinta puntos (los días del mes, en rejilla 6×5) en petróleo #0B3F44 (claro) / teal oscuro #3F8F8A (oscuro), con cobre #C08A3E/#D9A45E reservado siempre para "dinero disponible". Reemplaza el verde-teal provisional del rediseño mobile-first.
• Componente <x-brandmark> (isotipo real, ya no bi-wallet2) en navbar, sidebar móvil y login/registro; favicon real (SVG + PNG + apple-touch-icon) vía layouts/partials/favicon.blade.php.
• docs/BRAND.md: paleta, reglas de uso del logo y qué archivo de public/ usar para cada caso.

Cambiado

• La cifra de "dinero disponible" (Panel y Presupuestos) usa el acento cobre de marca en vez del color primario, siguiendo la regla explícita del entregable de identidad.
• Todo hex de marca hardcodeado que quedaba del rediseño anterior (color de categorías, gráfico de ingresos, plantilla de email de invitación) se sincroniza al nuevo petróleo.

[0.5.0] - 2026-08-27 — Rediseño mobile-first

Añadido

• Rediseño del Panel, Movimientos y Registrar gasto/ingreso: navegación inferior con botón central "+" en móvil (el "Más" abre el sidebar completo desde la derecha, del mismo lado que el botón), sidebar de escritorio reordenado, tarjeta hero de dinero disponible, listado de movimientos agrupado por día con chips de filtro, y formularios con importe grande (con separador de miles en vivo), atajos de categoría sincronizados con el <select> real, y campos secundarios bajo "Más detalles" (ADR-0016).
• Sistema de diseño documentado en docs/UI_DESIGN.md: componentes reutilizables (.chip, .segmented, .hero-card, input de dinero con formato de miles) con guía de cuándo usar cada uno. Referenciado desde CLAUDE.md, AGENTS.md, docs/CONVENTIONS.md, docs/ARCHITECTURE.md y los skills/agentes de Claude Code para que las próximas épicas lo usen por defecto.

Cambiado

• Paleta de marca y de estados (éxito/peligro/aviso) desaturada en claro y oscuro — feedback directo de la sesión de diseño: "se ve demasiado neón".
• Selector de período de Presupuestos pasa de btn-group a chips, mismo idioma visual que Movimientos.
• El Panel se probó con dos variantes conmutables ("Enfoque"/"Control") y, tras verlas en uso, se quedó con una sola: "Control" no aportaba y hacía ver rara la barra lateral de escritorio (ADR-0016).

[0.4.1] - 2026-08-26 — Invitaciones por correo

Añadido

• Las invitaciones a un hogar se envían por correo al invitado (HouseholdInvitationMail). Hasta ahora el administrador tenía que copiar el enlace y mandarlo a mano, justo en el paso más importante del producto. El correo es Blade HTML autocontenido, en español, con versión en texto plano y sin imágenes remotas.
• Interruptor finlia.mail.enabled en config/finlia.php y detección de transports que no entregan (log, array): con ellos la pantalla no le promete al administrador un correo que nadie va a recibir.
• Configuración SMTP de producción documentada en docs/DEPLOYMENT.md §4 (Hostinger, SPF/DKIM).
• Tests: 7 de feature con Mail::fake() — envío al invitado, enlace con el token plano en el cuerpo, asunto, interruptor apagado, transport falso, caída del SMTP y aviso en la UI.

Cambiado

• Política de correo escrita y acotada (ADR-0015): Finlia envía correo solo cuando el destinatario no puede ver el mensaje dentro de la app — invitación a un hogar y recuperación de contraseña. Recordatorios (Épica 9), resúmenes y comunicaciones de producto van in-app. Ningún correo transporta datos financieros. Añadir un correo nuevo exige un ADR. Se corrigen docs/ARCHITECTURE.md §7 y la Épica 9 de docs/ROADMAP.md, que dejaban la puerta abierta a notificar por email.
• HouseholdService::inviteMember() devuelve un tercer elemento (bool $emailSent) y acepta el nombre de quien invita como dato explícito, sin romper el seam de ADR-0010.
• La pantalla del hogar distingue "invitación enviada" de "invitación creada": el enlace manual sigue siempre visible como respaldo.

Seguridad

• El envío nunca bloquea la operación: un SMTP caído deja la invitación creada y registra un Log::warning sin token ni enlace (docs/SECURITY.md §4).

[0.4.0] - 2026-08-18 — Presupuestos y dinero disponible

Añadido

• BudgetCalculatorService: responde "¿cuánto puedo gastar?" separando cuatro conceptos que no se mezclan — balance actual, comprometido, disponible y libre (ADR-0014). Sin dependencias HTTP, reutilizable por la futura API (ADR-0010).
• Presupuestos (budgets): total del mes y/o por categoría, con CRUD, unicidad por hogar/categoría/mes y DECIMAL(15,2) (ADR-0006). El comprometido toma el mayor entre el total y la suma de categorías para no contar dos veces.
• Ingresos esperados (expected_incomes): el usuario configura sus ingresos mensuales fijos (salario, arriendos, inversiones) con monto, día de cobro y estado activo. Son la entrada del cálculo; si no hay ninguno configurado se degrada a los ingresos ya registrados.
• Tarjeta "💰 Puedes gastar aproximadamente" en el panel de presupuestos y en el dashboard, con reparto diario y días restantes del período.
• Consulta por esta semana / este mes / próximo mes: los presupuestos se guardan mensuales y la vista semanal los prorratea (BudgetScope vs BudgetPeriod).
• Alertas visuales al 80 % y al 100 % por categoría (BudgetAlertLevel), con banners en presupuestos y dashboard, barras de progreso e indicador de tendencia (gasto proyectado a fin de período).
• Desglose opcional "¿Cómo se calcula?" que muestra la fórmula sin imponerla, marcando los términos que llegarán en las épicas 5-7.
• Enums BudgetPeriod, BudgetScope y BudgetAlertLevel; componente Blade available-money-card; helper y directiva @percent (formato colombiano 332,4 %).
• Presupuestos e ingresos esperados de demo en DatabaseSeeder (datos siempre falsos).
• Tests: 26 unitarios de BudgetCalculatorService (prorrateo semanal, doble conteo, umbrales 80/100, próximo mes, aislamiento) y 36 de feature con CRUD, validación, mass assignment y aislamiento entre hogares (403).

Corregido

• Los componentes form-input y form-select ignoraban el prop id (lo fijaban a name), de modo que el modal de edición de categorías de la Épica 3 no podía rellenarse y la página generaba id duplicados. Ahora aceptan id (y step).
• Scroll horizontal en móvil en todas las pantallas: <main> es un flex item sin min-width: 0, así que no podía encogerse por debajo del ancho intrínseco de su contenido (hasta 101 px de desbordamiento en el panel a 375 px). Verificado a 360, 375, 414, 768, 1280 y 1440 px.
• Los importes truncados en las tarjetas KPI del panel ocultaban dígitos. Ahora usan tipografía fluida (.money-figure) en vez de text-truncate: en una app de finanzas un número a medias es peor que uno pequeño.
• La línea de categoría/cuenta/fecha de "Últimos movimientos" perdía la fecha en móvil por truncamiento; ahora envuelve.

Notas

• El cálculo aún no descuenta gastos recurrentes, deuda ni ahorro programado: esos términos existen en el resultado con valor 0.0 y los rellenarán las épicas 5, 6 y 7 sin cambiar la fórmula ni la UI (ADR-0014). El "puedes gastar" de hoy es, por tanto, optimista respecto al definitivo.

[0.3.0] - 2026-08-14 — Cuentas, ingresos y gastos

Añadido

• Cuentas financieras (efectivo, ahorros, corriente,…) con CRUD completo y saldo persistido y recomputado en cada escritura vía AccountBalanceService (ADR-0012).
• Ingresos y gastos en tablas separadas (ADR-0001), con dinero en DECIMAL(15,2) (ADR-0006), Form Requests y Policies por hogar; MovementService actualiza automáticamente el saldo de la cuenta afectada.
• Enums de dominio: AccountType, CategoryType y PaymentMethod.
• Categorías: catálogo global precargado (CategorySeeder) + categorías personalizadas por hogar, gestionadas en una única pantalla.
• Vista unificada Movimientos con filtros por cuenta, categoría, tipo y rango de fechas (MovementSummaryService).
• Dashboard del mes con Chart.js: totales de ingresos/gastos, gasto por categoría y tendencia mensual.
• Componente Blade form-select reutilizable para los formularios.
• Factories y seeders de datos demo (siempre falsos) y tests: Feature por recurso (incluye aislamiento entre hogares) y unitarios de MovementSummaryService.

[0.2.0] - 2026-08-12 — Hogares, familias y miembros

Añadido

• Multi-tenancy por hogar (ADR-0005): tablas households, household_user (roles owner/member) y household_invitations, con aislamiento por household_id en todas las consultas.
• CRUD completo de hogares con HouseholdPolicy.
• Hogar personal auto-creado al registrarse y concepto de hogar activo en sesión con selector en la barra superior (ADR-0011).
• Sistema de invitaciones por email: token aleatorio de 64 caracteres almacenado hasheado (sha256), expiración configurable, aceptación por enlace público y revocación por el owner (ADR-0003).
• Gestión de miembros desde la pantalla del hogar (expulsar, con reglas para el owner).
• HouseholdService con la lógica de dominio (crear, actualizar, invitar, aceptar, revocar, expulsar), sin dependencias HTTP para reutilizarla en la futura app móvil (ADR-0010).
• Helpers globales de hogar activo.
• Tests de hogares, invitaciones y hogar activo, incluyendo aislamiento entre hogares (403 ante manipulación de IDs).

[0.1.0] - 2026-08-11 — Fundación y configuración

Añadido

• Base operativa del repositorio: CLAUDE.md, AGENTS.md, documentación completa en docs/ (arquitectura, modelo de datos, seguridad, despliegue, convenciones, ADR y roadmap) y la planificación Scrum en scrum/epics/.
• Agentes y skills de Claude Code para el flujo de trabajo: implement-epic, security-checklist, epic-implementer, laravel-reviewer y security-auditor.
• Autenticación completa a medida sin Breeze (ADR-0009): registro, inicio y cierre de sesión, y recuperación de contraseña, con validación en español (lang/es/), rate limiting en login/registro y Form Requests dedicados.
• Layout responsive con Bootstrap 5: navbar, sidebar móvil, footer, mensajes flash y componentes Blade reutilizables (form-input).
• Dashboard inicial y pantalla de bienvenida orientada al producto.
• Configuración del producto para Colombia (COP, timezone America/Bogota, locale es) centralizada en config/finlia.php.
• Tests PHPUnit de autenticación (registro, sesión, reset) y del dashboard.

Cambiado

• Tailwind 4 reemplazado por Bootstrap 5 vía Vite/npm (ADR-0004); eliminada la welcome.blade.php por defecto de Laravel.
• Renombrado del proyecto Finami → Finlia en configuración, README y documentación.
• Rediseño del front: estética glassmorphism, modo claro/oscuro con preferencia persistida y enfoque mobile-first.
• Sesiones, colas y caché con driver database para compatibilidad con hosting compartido (ADR-0008).
• Registrado el plan de API REST para la app móvil (futura) junto al ADR-0010: la lógica de dominio vive en Services sin dependencias HTTP.