# Changelog Registro de cambios relevantes de **Credify GO!**. Formato basado en [Keep a Changelog](https://keepachangelog.com/es-ES/1.1.0/). > 🧵 **Este archivo es el "hilo" del proyecto.** Cualquier agente de IA o dev que > retome el trabajo desde otra máquina debe leerlo junto con [`CLAUDE.md`](CLAUDE.md) > para entender el estado actual y lo que se ha hecho. Los `#NN` enlazan a PRs/Issues en GitHub. ## [Sin publicar] ### Pendiente — TODO (ver Issues) - [ ] [#58](https://github.com/jdredondo/credify/issues/58) — Backups: el **dump diario local con retención ya existe en prod** (cron 03:15, `/home/credifygo/bin/db-backup.sh`, retención 14 días, verificación `gzip -t`, instalado 2026-06-16). **Falta la copia offsite** — hoy los dumps viven en la misma VM. Requiere credenciales de almacenamiento externo (Azure Blob / S3 / etc.). - [ ] **Test flaky** — algunos tests fallan según el orden de ejecución por estado compartido en la BD de dev (visto en `PaymentMaterializerTest` — `QueryException` en la suite completa, pero **pasa aislado** 11/11 —, `DelinquencyMetricsService`, `CreditParentChildTest`, `ExtendWithInterestOperationTest`, y `SnapshotDashboardMetricsTest` —este usa `assertDatabaseCount('dashboard_snapshots', 1)` sobre la tabla completa, así que filas de snapshots de otras empresas persistidas en la BD dev lo rompen; **pasa en CI (BD limpia) y aislado**). Aislar el estado compartido o usar una BD de test dedicada. - [ ] **Migrar `text-slate-*` crudo → tokens en la PWA** (deriva del [#43](https://github.com/jdredondo/credify/issues/43), Fase 3). El rediseño de dashboards ya usa tokens/`.pwa-card`; queda barrer el resto de vistas que aún usan `text-slate-*` inline para eliminar la deriva de color. Limpieza de bajo riesgo, no bloqueante. > ✅ **Resuelto recientemente:** [#43](https://github.com/jdredondo/credify/issues/43) (UI/UX modo oscuro iOS-26 + dashboards modernos) **cerrado** — Fase B completa y desplegada: rediseño de los 3 dashboards (Approach C) + fix de modo oscuro, Fase 2 (utilidad mensual, desglose por cobrador, sparkline), snapshots para trends de stock, y el badge de rol de `ProfileView`; solo queda la migración `text-slate-*`→tokens (arriba). [#59](https://github.com/jdredondo/credify/issues/59) (ruido de notificaciones Filament — silenciado, ver `2026-06-19`) y [#60](https://github.com/jdredondo/credify/issues/60) (app-password de Bitbucket **revocado** en bitbucket.org; la VM ya estaba limpia). **#99** (`concurrently` 9→10) **cerrado**: v10 exige Node ≥22 (dev/prod en Node 20) y es dev-only; añadido a la lista `ignore` (majors) de `.github/dependabot.yml` — se retomará al migrar a Node 22. ### Cambiado - **`installments.balance_due` pasa a llamarse `principal_balance_after`, y el campo homónimo de la API a `remaining_amount`.** El nombre viejo describía justo lo contrario de lo que guarda: no es lo que falta por cobrar de la cuota, sino el saldo de **capital que le queda al crédito después** de esa cuota — una columna de tabla de amortización. En un crédito de $500.000 a 10 cuotas, la primera (ya pagada, $70.000) la tiene en $450.000. El nombre invitaba al error y el error llegó a producción: tres widgets la mostraban como "Monto a Cobrar" / "Monto" / "Monto Pendiente", inflando el total del día 2,8x y ordenando mal la lista de prioridades del cobrador (corregido en #253). El código ya llevaba avisos sobre ella en dos servicios de métricas, pero un aviso dentro de un servicio no protege a quien escribe un widget. **Había además una segunda colisión, más sutil:** el endpoint de sincronización enviaba un campo llamado `balance_due` que llevaba **otra cosa** — `remaining_amount`, lo que sí falta por cobrar. El mismo nombre significaba dos cosas distintas según de qué lado del cable se mirara; ahora cada uno se llama como lo que es. La PWA lee el nombre viejo como respaldo para las filas que quedaron en IndexedDB antes del despliegue y aún no se han vuelto a sincronizar. La red de seguridad que impide exponer la columna como monto en un widget vigila ahora **los dos** nombres, porque el viejo puede reaparecer copiando código de una rama anterior. Migración reversible, verificada en los dos sentidos. ### Añadido - **Archivar créditos: sacarlos de la ruta del cobrador sin cerrarlos (pedido por el dueño).** Hay créditos cuyo desenlace todavía no está decidido y que mientras tanto ensucian la cartera del cobrador. Archivar los esconde usando el estado `archived` que el modelo ya tenía pero que ninguna acción aplicaba. **No toca ningún registro financiero**: no borra el desembolso, no condona, no reescribe cuotas. Lo que sí implica —y por eso la confirmación lo dice con el número delante, *"salen $X de la cartera"*— es que `archived` pertenece a `CLOSED_STATES`, así que el saldo sale de "por cobrar", el patrimonio del panel baja en esa cantidad y no se le pueden registrar pagos. **Desarchivar recalcula el estado desde las cuotas** en vez de restaurar el anterior: mientras estuvo archivado el tiempo siguió corriendo, así que un crédito que se archivó al día puede volver en mora. Los archivados tienen **pestaña propia** y no se mezclan entre los cerrados, porque son una decisión pendiente y hay que poder encontrarlos. La acción queda reservada a admin y super_admin: mueve plata fuera de la cartera, no es decisión de campo. **`credify:verify-equity` sigue contando el capital archivado**: archivar retira el crédito de la cartera *operativa*, pero la deuda sigue siendo un activo — sin esto, archivar abriría una brecha en la conciliación del tamaño exacto de su saldo y el control nocturno empezaría a fallar por una operación legítima. Dos defectos encontrados por los tests durante el desarrollo: el grupo "Administrar" se ocultaba en los créditos cerrados con pagos, dejando **desarchivar fuera de alcance** (se podía archivar sin vuelta atrás), y faltaban los casos nuevos en los cuatro `match` exhaustivos de `CreditAuditEvent`. **Sin migraciones.** ### Corregido - **El envío directo de cobros y visitas deja de ser más débil que el lote que lo respalda.** Desde PWA-002 el teléfono manda cada cobro primero a `POST /api/pwa/payments` y el lote reenvía con la misma clave si no hubo respuesta, pero el directo no aplicaba dos reglas del lote. **Clave retenida:** un POST directo atrasado (el teléfono ya se había rendido y el lote había retenido la fila) se aplicaba igual, saltándose la revisión; ahora el directo busca la clave también en `held_payments` y devuelve el retenido (`held: true`, sin `payment`) en vez de aplicarlo, y la pantalla avisa que quedó en revisión. **Cobro igual el mismo día (decidido al revisar PWA-002: preguntar):** el lote retenía como "posible duplicado" un cobro con el mismo monto, el mismo día y el mismo crédito que otro ya registrado; el directo lo aplicaba en silencio, y desde PWA-002 era justo el caso del cobrador que repite un cobro tras "No se pudo confirmar con el servidor" (sale con otra clave). Ahora el directo responde 409 con el pago que ya está y la pantalla de pago pregunta "Ya hay un pago de $X hoy a las HH:MM. ¿Es un cobro distinto?" **sin soltar la fila**: "Sí" la reenvía con la misma clave y `confirm_duplicate`, que queda en la fila y el lote respeta (solo para los pagos iguales capturados antes que ese cobro); "No" la borra; sin respuesta (salir de la pantalla, la app cerrada) la fila sube sola al vencer la pregunta y el lote la retiene para el admin. Nada se pierde. La regla vive en un solo lugar (`PaymentSyncService::sameDayDuplicate()`). Un teléfono con el bundle anterior recibe el 409 como error, con un mensaje que dice cómo seguir. **Visita en carrera:** dos envíos con la misma clave chocaban en el índice único y el segundo respondía 500; ahora devuelve la visita existente como duplicado, como el lote. Spec `docs/superpowers/specs/2026-10-01-directo-como-el-lote-design.md`. **Sin migraciones.** - **Una versión nueva de la PWA ya no recarga la app en pleno envío, ni saca al cobrador de la sesión sin preguntar.** Tras un deploy, la app se recargaba sola en cuanto volvía a primer plano, hiciera lo que hiciera. Una recarga durante la espera del GPS (hasta 6 s antes de armar el cobro) perdía el toque: la fila todavía no estaba en IndexedDB. Y como el token vive solo en memoria, toda recarga obligaba a volver a entrar, algo que con señal débil puede no salir. Quitar el `updateSW(true)` de `main.js` no alcanzaba: el SW hacía `skipWaiting()` en `install` y el plugin recargaba solo en el `clients.claim()`. Retrasar solo la recarga tampoco: el SW nuevo borra los chunks de la versión vieja y la siguiente navegación terminaba en otra recarga por `router.onError`. Ahora el SW nuevo **espera** en `waiting` mientras el viejo sigue sirviendo su precache completo, y `services/actualizacion.js` decide: se aplica sola solo en el login sin token (recién abierta, tras un 401 o el vencimiento de 24 h, al cerrar sesión) y si es la única ventana de la app (`skipWaiting` cambia la versión para todas, y otra pestaña puede tener una sesión: el SW lo comprueba). Con sesión viva aparece "Hay una versión nueva · Actualizar" (en `PwaHeader` y en Inicio), que exige señal: perderla anula lo pedido, porque después habría que volver a entrar. En los dos casos, nunca con algo en curso: un envío (`enviarOEncolar` y el submit de cobro, "No paga", gasto, crédito, socio, cliente y login, con la espera del GPS incluida), anular un pago, aprobar o rechazar un gasto, reordenar la ruta, guardar ajustes, una ronda de sincronización, el login a medio escribir, o un cierre de sesión mientras vacía la caché (borra el token antes). Cada envío sigue contando 8 s después de terminar, para que el recibo o el aviso de "puede que sí haya quedado" se alcancen a leer: quien no los ve lo vuelve a registrar. La recarga la decide `controllerchange`, no el plugin, que no recargaba una página que arrancó sin SW. Una versión que ya esperaba al cargar la página (la carga completa tras un 401) se avisa antes de que el plugin entregue la registración; se aplica cuando llega, en vez de descartarse. E2E nuevo `actualizacion-sw.spec.js` (un login, con el SW habilitado solo ahí): simula deploys reescribiendo `public/pwa-sw.js`, porque Playwright no intercepta la descarga del script del SW. Falla con el código anterior, y también si se quita el envoltorio de la pantalla de pago, los 8 s de reposo, la retención del login, la espera de la registración, la condición de ventana única, la de ruta de login o la anulación al perder la señal. De paso, `registration.update()` sin señal ya no manda un rechazo no atrapado a Sentry en cada vuelta a primer plano. **Al desplegar:** solo frontend, y fuera del horario de cobro una última vez: los teléfonos con el bundle anterior todavía recargan sin guardia al recibir esta versión. - **El gasto y la visita "No paga" guardan lo mismo vayan por el envío directo o por el lote.** Desde PWA-002 la misma fila de la cola sale primero por `POST /api/pwa/expenses` o `/api/pwa/visits` y, si la respuesta se pierde, la vuelve a mandar el lote con la misma clave; pero los dos caminos no seguían las mismas reglas. **Modo simplificado:** el directo convertía solo si la empresa tenía el modo prendido *hoy*; el lote, por el flag del ítem (PWA-010). Un teléfono con los ajustes viejos en caché que mandaba "50" con el flag después de que la empresa apagó el modo guardaba $50 por un camino y $50.000 por el otro. Ahora el gasto y la promesa de pago del directo convierten por el flag con `SimplifiedAmount::toReal`, que además redondea igual que el lote, y leen el flag igual que él (`"true"` u `"on"` en texto daban 422 solo en el directo). **Fechas:** el directo rechazaba un gasto o una visita con fecha de mañana y una promesa para ayer, que el lote acepta por la zona horaria del teléfono; con un 422 el teléfono suelta la fila como rechazada de verdad. Ahora tienen un día de margen (más de un día sigue frenado en el directo, que solo recibe filas recién capturadas). La promesa de $0 también pasa, como en el lote. El gasto directo guarda `metadata.source = pwa_direct` (el lote guarda `pwa_sync`), para saber por cuál entró. Test nuevo `DirectoYLoteMismasReglasTest`, que manda el mismo payload por los dos caminos y compara las dos filas guardadas enteras (salvo id, clave, fechas de registro y `metadata`); el test que afirmaba lo contrario (`test_expense_does_not_convert_when_master_off`) ahora afirma la regla del lote. **Sin migraciones.** - **La visita "No paga" y el gasto avisan si ya hay uno esperando señal, y "Mis gastos" muestra los que siguen en el teléfono (seguimiento de PWA-002).** Con PWA-002 una visita o un gasto cuya respuesta se pierde queda en la cola y sube después, pero solo la pantalla de pago avisaba lo que ya estaba en la cola. Un cobrador que salió a mitad del envío y volvía podía registrar la misma visita o el mismo gasto otra vez, con otra clave, que el servidor no puede reconocer como el mismo; y el gasto de un admin se aprueba solo. Ahora el modal "No paga" avisa por crédito y el formulario de gasto avisa de todos los gastos propios en la cola, con las mismas reglas que el aviso de cobros: cuentan también los que se están enviando, los que agotaron reintentos se avisan aparte y nada bloquea. Los tres avisos dicen la fecha cuando lo guardado no es de hoy, y el monto real aunque se haya escrito en modo simplificado. "Mis gastos" lista arriba los gastos propios de la cola con la marca "En el teléfono, sin subir", fuera del total. No muestra como "sin subir" el que el servidor ya tiene: `/api/pwa/expenses/mine` devuelve la `idempotency_key` y la clave los empareja. Cuando el motor sube uno, la lista se recarga, y hasta que la lista lo trae sigue a la vista con "Ya subió", aunque la recarga falle. Las categorías de lo que está en la cola usan las etiquetas del servidor, guardadas en el teléfono, para que el gasto no cambie de nombre al subir. Si la lista del servidor no carga, dice "No se pudieron cargar los gastos que ya subieron." en vez de "Sin gastos en este período". Limitación conocida: el emparejamiento solo ve el período elegido, así que un gasto con la respuesta perdida y fecha anterior se ve como "sin subir" hasta la siguiente ronda. Sin migraciones. Pasos nuevos en `senal-debil.spec.js`, dentro de su único login; uno fija las unidades con una fila en modo simplificado, porque el demo arranca sin él. - **Con señal débil, un cobro, una visita "No paga" o un gasto ya no se pierden, y un crédito o un movimiento de socio ya no se duplican al reintentar (PWA-002).** En la calle lo normal es una señal que el teléfono da por buena y que no llega al servidor. La app solo usaba la cola cuando el teléfono se declaraba sin conexión: el cobro esperaba hasta 30 s, mostraba un error y no quedaba en ninguna parte; si el cobrador insistía desde otra pantalla salía con otra clave y, si el primero sí había llegado, se cobraba dos veces. Ahora cobro, visita y gasto se guardan en la cola **antes** de salir, con la misma clave con que se envían, y solo se sueltan cuando el servidor responde: si no responde en 10 s quedan guardados y los sube el motor de PWA-001; si el primer envío sí había llegado, el servidor lo reconoce por la clave. Una marca en la fila evita que el motor mande lo que la pantalla está enviando y vence sola si la app muere a mitad; tras un envío directo exitoso se sube el resto de la cola. Si IndexedDB no puede guardar, con señal se envía directo como antes. La pantalla de pago abre desde la caché del teléfono si el servidor no contesta en 8 s (antes esperaba 30 s y decía "Crédito no encontrado"), avisa si ya hay un cobro de ese crédito esperando señal y no deja volver a tocar "Confirmar" mientras sale. El GPS se pide al abrir y se espera como mucho 6 s. "No quedó registrado" solo se dice cuando es seguro (sin señal y sin dónde guardarlo); en la duda, la app avisa que pudo haber quedado. El gasto con conexión, que ignoraba la clave, ahora deduplica y se crea y aprueba en una sola transacción. Crédito y movimiento de socio, que no van a la cola, llevan una clave nueva (`idempotency_key` con índice único por empresa en `credits`, `capital_contributions` y `partner_withdrawals`): el teléfono la guarda por usuario hasta que el servidor confirma —hasta el fin del día, aunque se cierre la app— y el reintento devuelve el original, con un aviso de sus valores, en vez de crear otro crédito con otro desembolso. El chequeo de duplicado va antes del límite del plan y del saldo del socio, y se repite antes de rechazar, para que ni el reintento ni una carrera se rechacen por su propio efecto. Migración reversible; la base del teléfono no cambia de versión. E2E nuevo `senal-debil.spec.js` (un solo login), y la suite E2E corre con la zona horaria de Bogotá. - **La cola offline por fin sube, y ningún cobro capturado en campo se pierde (PWA-001, auditoría 2026-09-24).** Ningún pago, visita ni gasto guardado sin señal había llegado nunca al servidor: en producción había 0 ítems venidos de la cola en toda la historia. La sincronización consultaba `where('permanent_error').equals(true)` e IndexedDB no admite booleanos como clave, así que la promesa rechazaba siempre, aun con la cola vacía; en pagos además dejaba `syncing` trabado hasta recargar. Reproducido con Dexie 4.4.4 en Chromium y WebKit. **Teléfono:** Dexie v8 quita esos índices y sella en lo ya encolado quién lo capturó; un solo motor reemplaza las tres copias (lotes de 50/100, un fallo de red no penaliza, una fila mala no traba la ronda, un 403 del lote entero no castiga la cola), y la cola sube al entrar, al volver a primer plano, al volver la señal y cada 3 minutos. Cambiar de usuario ya no borra la cola del anterior: se sube a su nombre (PWA-011). La pantalla de errores lee de IndexedDB, muestra solo lo del usuario de la sesión, está enlazada desde el indicador, Inicio y Pagos de hoy, cambia "Descartar" por "Enviar a revisión" en pagos y ya no se queda en blanco por el locale `es_CO` (PWA-008). Los fallos de la cola llegan a Sentry, con transporte offline. **Servidor:** cada lote decide ítem por ítem (una fila mala ya no devuelve 422 al lote entero) y cada resultado trae su `index`. **Principio nuevo:** un cobro se aplica o queda **retenido** en `held_payments`, sin tocar saldos, si llegó con más de 7 días, tiene fecha futura, apunta a un crédito que cambió o sin cuotas pendientes, supera el saldo, parece un duplicado (mismo monto el mismo día; o, si pasó más de 24 h en la cola, un pago igual a ±7 días cargado después de capturarlo), lo capturó otro usuario del teléfono o el cobrador lo mandó a revisión. El admin lo aprueba o rechaza en **Cobros en revisión** (Filament), con pista de posibles duplicados (también en la confirmación de aprobar); aprobar bloquea el crédito, registra el pago con la fecha, la clave y el cobrador originales, y nunca crea dos pagos. Gastos y promesas escritos en modo simplificado ya no llegan mil veces menores (PWA-010): la empresa 1 tiene ×1000. Tampoco los cobros que `PaymentView` encoló crudos del 2026-02-05 al 2026-03-09: el motor manda el flag y el servidor los convierte (`App\Support\SimplifiedAmount`). La migración de `held_payments` se niega a revertirse si la tabla tiene filas. Los errores del lote se reportan sin los valores del cobro (`App\Support\SafeReport`). De paso, `MultiTenantScope` usa `getAttribute/setAttribute` y se quitan **21 supresiones** del baseline de PHPStan. **Al desplegar:** los teléfonos subirán lo atascado; lo de más de 7 días aparecerá en la bandeja para revisarlo con el admin. - **El listado de créditos vuelve a la posición donde estaba, y cada crédito muestra la dirección del cliente (reportado por el cobrador).** Al abrir un crédito y volver atrás, el listado aparecía desde el principio: el cobrador tenía que volver a bajar hasta donde estaba. El router ya devolvía `savedPosition`, pero no alcanza — la vista se re-monta y vuelve a pedir los créditos, así que cuando se restaura el scroll la lista todavía está vacía y no hay a dónde bajar. Ahora la posición se recuerda **solo al entrar a un crédito** y se restaura cuando la lista ya está pintada; salir por la barra inferior la olvida, porque volver a "Créditos" desde el menú debe mostrar el principio. Cambiar de filtro también la descarta. **Dirección:** viajaba en cobros y en el snapshot offline, pero el listado de créditos era el único que no la mandaba. Se añade a `formatCreditForList` (con `client.addresses` en el eager load, si no serían N consultas) y a la caché offline, y se pinta en `CreditCard` con el mismo tratamiento que la card de cobros — así aparece en todos los listados que usan esa card. De paso, `Credit::client()` declara su genérico: sin él PHPStan veía `BelongsTo` y no reconocía los accessors de `Client`, lo que permitió **eliminar 87 líneas de supresión del baseline** en diez archivos que llevaban tiempo sin verificarse de verdad. - **Cerrar sesión en la PWA borraba los pagos registrados sin señal.** `logout()` hacía `db.clearAll()`, que arrasa `pendingPayments`/`pendingVisits`/`pendingExpenses` junto con la caché. Un cobrador que cerraba sesión con pagos en cola los perdía: esa fila no existe en ningún otro lado — es plata ya cobrada al cliente. Ahora hay dos caminos: `endSession()` termina la sesión sin tocar IndexedDB (sesión caída) y `logout()` limpia **solo la caché de lectura**, conservando la cola. Esta se descarta únicamente si en el dispositivo entra un usuario distinto, porque el servidor atribuye cada pago según el token de quien sincroniza; el aviso de la vista ahora lo explica en vez de amenazar con perderlos. (Ya no: desde el arreglo de la cola offline, PWA-001, la cola del usuario anterior no se descarta nunca; se sube a su nombre y sus cobros quedan en revisión.) **Corrección a lo reportado en la auditoría:** la rama de 401 de `fetchUser()` NO estaba perdiendo datos en producción — solo corre al montar la app y sale temprano sin token en memoria, y el interceptor redirige antes de que el `clearAll()` alcance a ejecutarse. Era una mina latente; el daño real estaba en el cierre voluntario. - **Dos dispositivos distintos compartían nombre de token y se expulsaban entre sí.** El nombre era `PWA-`: en producción el cobrador y el dueño tenían exactamente la misma cadena (dos iPhone con el mismo iOS), así que la revocación «un token por dispositivo» de #254 cerraba la sesión del otro — y ese cierre involuntario se combinaba con el bug anterior. Pasa a usar el `device_id` que la PWA ya generaba, persistía y enviaba, y que `registerDevice()` ya usaba: el login se había quedado atrás. Los tokens del esquema viejo se descartan en el primer inicio de sesión de cada usuario. `generateDeviceId()` pasa a `crypto.randomUUID()` con respaldo. - **Quedaban dos rutas de sincronización con reglas distintas.** `syncInitialData()` (auth.js) seguía usando `bulkPut` crudo porque la purga de #251 solo cambió `syncData()`: la sincronización del login no purgaba, así que un crédito fuera de alcance seguía visible hasta el siguiente sync de fondo. Ambas pasan ahora por `applySyncSnapshot`. (Ya no: desde el arreglo de la cola offline, PWA-001, `syncInitialData()` no existe; el login sube la cola con `syncAll()` y después descarga con `syncData()`.) - **`credify:verify-equity` no podía detectar un aporte de capital duplicado.** El error infla los **dos** lados del puente por igual —sube el capital aportado y sube la caja— así que la brecha seguía dando cero: con los $1.500.000 registrados dos veces en producción la conciliación cuadraba perfecta. Se añaden dos señales que el puente no puede ver: mismo monto en la misma fecha, y capital que entra sin socio vinculado en `capital_contributions`. Contra la copia de producción ambas marcan el ingreso #483. ### Eliminado - **`app/Repositories/` completo.** `PaymentRepository` no tenía un solo llamador en producción (el único uso era un test reciente); `InstallmentRepository`, encontrado al verificarlo, está igual. Código muerto que además había que mantener al día con cada cambio de semántica de pagos. ### Añadido - **Playwright entra al CI** como job aparte, solo chromium. El login de la PWA está limitado a 5/min por IP+identificador y en CI todo sale de una sola IP: añadir el proyecto `mobile` duplicaría los inicios de sesión y haría fallar la suite por 429, no por un bug. Cubre lo que ningún test de PHP puede ver — el comportamiento de IndexedDB en un navegador real, en particular la purga del snapshot de sync, que **borra filas del dispositivo del cobrador**. Dos specs nuevos: uno fija el invariante de que una sesión caída no toca la cola (pasa también con el código viejo: es invariante, no regresión) y otro que sí tiene dientes, y falla con el `clearAll()` del cierre voluntario. - **Anular un pago restaba el monto dos veces de los cobros reportados (hallazgos 4, 6 y 7 de la auditoría).** `PaymentReverser` deja DOS filas: la original con `voided = 1` y un asiento compensatorio de monto **negativo** que **no** queda marcado como anulado. Filtrar solo por `voided = false` excluía la original *y encima* sumaba el negativo. En producción subestimaba los cobros: junio −$284.667, julio −$132.000, agosto −$190.000 ($606.667 acumulado, 0,2% sobre $278M, pero hasta 1% de un mes puntual). La caja nunca se vio afectada —al anular se borra el ingreso—, el daño vivía solo en las sumas sobre `payments`. Tres sitios ya lo excluían a mano (`CreditController`, `SyncController`, `CreditRules`, este último tras el bug #387 que dejaba el crédito en solo lectura después de anular su único pago); ahora hay **una sola definición**, `Payment::scopeCollections()`, exigiendo los dos marcadores (`payment_method != 'reversal'` y `original_payment_id IS NULL`, que en producción coinciden exactamente), aplicada en los **25 sitios** que miden dinero cobrado —incluidos `PaymentRepository` y `CashFlowComparisonChart`, que el barrido inicial no había encontrado— y en `Credit::latestPayment()`, donde al anular el último pago el "último pago del cliente" pasaba a ser un monto negativo. La vista de auditoría de Filament sigue mostrando ambas filas a propósito. **Higiene de accesos:** la PWA creaba un token por inicio de sesión y nunca borraba el anterior (un solo cobrador acumuló **495 credenciales válidas simultáneas**; la tabla llegó a 1.411 filas, 826 ya expiradas, para una empresa de 3 usuarios); ahora el login revoca el token previo del mismo dispositivo y se programa `sanctum:prune-expired` semanal. **Conciliación de patrimonio:** nuevo comando **`credify:verify-equity`** —hermano de `credify:verify-interest`— que concilia el patrimonio por dos caminos independientes y falla si la brecha supera la tolerancia; modela con nombre las tres causas que en la auditoría la explicaban ($380.000 de interés capitalizado al refinanciar, $200.000 de **capital** condonado bajo una categoría que el enum trata como si nunca tocara el capital, y $60.000 de sobrepago que es saldo a favor del cliente y no patrimonio). De paso se anotan los genéricos de `Credit::payments/collector` y `Payment::installments`, lo que permitió **reducir el baseline de PHPStan de 261 a 251 entradas** (20 inserciones contra 80 eliminaciones). **Sin migraciones.** - **Los widgets de cobro mostraban el saldo de amortización en vez del monto a cobrar (detectado en auditoría, afectaba la operación diaria).** `installments.balance_due` es el saldo de **capital que le queda al crédito después** de esa cuota — una columna de la tabla de amortización que no tiene relación con lo que el cliente paga ese día. Tres widgets la exponían cruda: `InstallmentsDueTodayTable` como **"Monto a Cobrar"** (y además **ordenaba la lista del día por ella**), `OverdueInstallmentsTable` como "Monto" y `CollectorDueInstallmentsTable` como "Monto Pendiente". En producción el total del día aparecía como **$2.772.942 cuando lo real era $1.002.200** (2,8x), a un cliente que debía $68.200 le mostraba $540.000, y la cifra era incorrecta en **1.054 de 1.055** cuotas pendientes. Peor que el monto: como el widget del supervisor ordenaba por esa columna, la lista de prioridades de cobro salía ordenada por el tamaño del crédito en vez de por lo que hay que recaudar. Los tres pasan a `Installment::remaining_amount` (`total_amount - amount_paid`, acotado a 0 — el accessor ya existía), con ordenamiento por SQL para no perderlo. El código **ya conocía la trampa** (`PortfolioMetricsService` la documenta: *"Sumar balance_due de todas las cuotas produce un número sin significado financiero"*), pero la advertencia vivía en un servicio de métricas y los widgets nunca se enteraron. Se añade una **red de seguridad**: un test recorre `app/Filament/Widgets/` y falla si algún widget vuelve a exponer `balance_due` como columna de dinero. **Sin migraciones.** ### Cambiado - **Acceso demo por captura de lead + credenciales por correo (se elimina el login passwordless).** El acceso passwordless `GET /demo/{role}` era un hueco de seguridad (cualquiera con la URL entraba, sin capturar datos). Se reemplaza por una **página dedicada `/demo`** (`noindex`, rate-limit) que explica la demo y **captura el lead** (nombre/correo/WhatsApp/negocio → `Lead` con `source=demo_request`, visible en Filament → Leads) y le **envía por correo** las credenciales de los 3 usuarios demo (Dueño/Supervisor/Cobrador) + enlaces a la app (`/pwa/login`) y al panel (`/admin`). El prospecto **inicia sesión normal** — sin auto-login. Las 3 contraseñas son **fijas compartidas, cifradas en reposo** (tabla `demo_credentials`, cast `encrypted`) y **se rotan en cada `reset-demo` nightly** (credenciales filtradas expiran en ≤24 h); `setup-demo` las fija si faltan (no las rota en cada deploy). Correo (`DemoCredentialsMail`) **en cola** y **agnóstico del proveedor** (por `.env`; recomendado Resend). **Se elimina** `DemoAccessController`, la ruta `/demo/{role}`, la vista `demo-enter`, el bootstrap por `sessionStorage` (`main.js`/`stores/auth.js`) y `PwaAuthResponse::issueToken`. Los CTAs "Probar demo" de la landing pasan a enlazar `/demo`. **Dependencia de despliegue:** el envío real requiere configurar el proveedor de correo + verificar el dominio (SPF/DKIM); hasta entonces `MAIL_MAILER=log`. Ver `docs/superpowers/specs/2026-08-07-demo-lead-access-design.md`. - **Trial reemplazado por una empresa demo compartida (menos carga, cero pileup de empresas).** En vez de que cada prospecto se auto-registre creando su propia empresa (`/registro`, retirado), hay **una única empresa demo** (flag `is_demo` en `companies`, invariante: exactamente 1) en plan Profesional con suscripción permanente y **3 usuarios demo fijos**. La landing pasó de "Empieza gratis" a **"Probar demo"** con selector de rol → login **passwordless acotado** (`GET /demo/{dueno|supervisor|cobrador}` → solo loguea usuarios de la empresa `is_demo`) → PWA; los CTAs de precios pasan a **"Solicitar cuenta"** (lead) y el onboarding real es manual. **Reset seguro** de los datos demo: comando `credify:reset-demo` (agendado **nightly 04:00 `--force`** + intra-día cada 3 h **si cualquier métrica de uso ≥ 90 %**) que borra **solo** lo tenant de la empresa demo — guards: exactamente-1-demo, filtro `company_id` explícito + `withoutGlobalScopes()` (el scope multi-tenant está OFF en consola), **allowlist** de tablas, y **preserva** empresa/suscripción/usuarios/settings — y re-siembra un dataset realista (`DemoDataSeeder`: ~20 clientes + 18 créditos en varios estados vía el flujo real de créditos). Provisión idempotente con `credify:setup-demo` — que ahora **también siembra el dataset de ejemplo si la demo está vacía** (con `--no-seed` para omitirlo), de modo que una demo recién provisionada nunca se vea en ceros; el seeder **enlaza al supervisor con el cobrador** (`supervisor_collector`) para que también la vista de supervisor muestre equipo y métricas (antes salía "sin cobradores"); y **siembra el capital inicial de 2 socios** (~$20M vía el flujo real de aportes, `PartnerInvestmentService`) para que la caja arranque **positiva** — sin el aporte, los 18 desembolsos dejaban la caja en negativo. El "wipe" de tenant se extrajo a `ResetDemoCompany::wipeTenantData()` (reusado por los tests demo para partir de una demo vacía aunque la BD compartida ya la tenga poblada). Cubierto con tests, incluido el guard **"el reset nunca toca una empresa real"**. **Copy veraz:** se eliminó **toda** mención de "prueba gratis 14 días" del sitio (landing `welcome.blade.php`, bot `sales-bot.blade.php` y el `Offer` de JSON-LD) — como ya no hay trial auto-servido, el único gancho gratis es la **demo** (sin registro ni tarjeta, con datos de ejemplo) y la cuenta real se **solicita** y se activa manualmente al coordinar el pago. Ver `docs/superpowers/specs/2026-08-01-demo-company-design.md`. - **Los créditos ahora tienen un código secuencial por empresa (001, 002, …) en vez del `id` global.** Antes el "código" visible del crédito era el PK global (`Crédito #{id}`), así que el primer crédito de una empresa podía salir como #500. Ahora cada empresa numera su propio talonario desde 001: nueva columna `company_credit_number` con índice único `(company_id, company_credit_number)`, asignada al crear vía un **hook `creating` del modelo `Credit`** (cubre TODOS los paths de creación —nuevo/refinanciar/renovar/reestructurar/clonar— con `lockForUpdate` para serializar concurrentes; el índice único es la red de seguridad). **Backfill cronológico** de los créditos existentes (por empresa, en orden de creación; los anulados conservan su número, sin renumerar). El código formateado (`Credit::code`, `str_pad` a 3 dígitos) se expone en la API + IndexedDB (con degradación offline) y se muestra en la PWA (detalle, pago, cliente, recibo, historial). **En el panel Filament el crédito se identifica por su Código en todas partes**: tabla de créditos (columna "ID" cruda → oculta como "ID interno" toggleable; el "Código" queda como identificador visible), lista de créditos del Cliente, encabezado y notificaciones de la vista de crédito (crear/duplicar/extender/condonar/eliminar), el selector de crédito en Gastos y las referencias en la tabla de Pagos/anulación. El id interno solo se conserva donde es una referencia técnica (sección "Información técnica" colapsada, columnas ocultas) o una FK/argumento de servicio. Anotación `@property-read string $code` en el modelo para el tipado. El `id` interno, rutas y FKs **no cambian**. Tests: asignación correlativa por empresa, independencia entre empresas y backfill cronológico. Ver `docs/superpowers/specs/2026-08-01-credit-numbering-design.md`. - **Entrada simplificada: un solo toggle maestro + ampliada a gastos, socios y promesa de pago.** El "modo simplificado" (capturar montos sin ceros, `1500`→`$1.500.000`) ahora depende **solo del toggle maestro** — se eliminaron los toggles por área "En créditos"/"En pagos" de Ajustes; el gating backend (`CompanyFinancialSettings::isSimplifiedInputEnabled()`) pasó a ser **master-only** (la columna `simplified_input_contexts` queda inerte, sin migración). Y se **aplica** también en **Registrar Gasto**, **Transacción de Socio** y el **Monto Prometido** de la visita "no paga hoy" (patrón de crédito: el form envía el monto crudo + `is_simplified_amount`, el backend convierte con `convertSimplifiedToReal()`; sin doble multiplicación; soporte offline). Componente `SimplifiedAmountInput` ampliado a los contextos `expense/partner/promise` y gateado por el maestro. Tests backend nuevos (`SimplifiedInputExpandTest`, 6/17). **Nota:** la página Filament de ajustes aún expone un control por contexto que ahora es inerte (follow-up de back-office). Ver `docs/superpowers/specs/2026-08-01-simplified-input-expand-design.md`. - **Follow-ups de UX de la PWA tras el QA del fix de overlays (#225).** Tres ajustes menores: **FAB como superficie única de acciones** — se elimina el componente `QuickActionRow` (y sus arrays `primaryActions`/`moreActions`) de los 3 homes (admin/supervisor/cobrador), que duplicaba las acciones ya cubiertas por el FAB y las tabs; **entrada a Ajustes de empresa en el Perfil** (visible solo para `admin`, vía `authStore.isAdmin`) — la ruta `/pwa/company-settings` quedaba huérfana sin ningún punto de entrada en la UI; y se **documenta que el recibo de pago (`PaymentReceipt.vue`) es claro por diseño** — es un documento imprimible/compartible con el cliente (`@media print`), no debe migrarse a modo oscuro. Solo PWA, sin cambios de backend. Ver `docs/superpowers/specs/2026-08-01-pwa-ux-followups-design.md`. - **Rediseño de la landing (`welcome.blade.php`) a tema completamente oscuro.** Paleta unificada al **emerald** de marca (fuera teal/cyan — 81 utilidades + 8 gradientes/aurora), **hero con titular dominante** (64px en desktop) y el cluster de mockups reducido a **2 cards** (Recaudo del día + Alerta de mora, blancas sobre el fondo oscuro). Y **tema oscuro en TODA la landing**: el cuerpo (secciones, tarjetas → glass oscuro, nav) pasó de claro a oscuro, **eliminando la transición murky hero→cuerpo** (que se veía mal) y unificando el look con la app. Solo diseño — sin cambios de copy, estructura ni backend. **Fix de rendimiento móvil:** las auroras `blur-[120px]` animadas ya no cargan en móvil (`hidden md:block`) — el `.hero-dark` ya trae los glows radiales baratos —, resolviendo el fondo negro de 2-3 s al scrollear. Motivado por un clon (`credifyapp.com`): se toma la *dirección* (sobriedad + verde oscuro) corrida a nuestro emerald, con nuestros propios assets/producto. Verificado en vivo (build + preview). Ver `docs/superpowers/specs/2026-07-30-landing-elevation-design.md`. *(SEO queda como track aparte.)* ### Añadido - **Documentación de usuario del panel de salud del negocio** (`docs/reportes/salud-negocio.md`, publicada en el sitio público de docs). Explica **tarjeta por tarjeta** qué es cada cifra y cómo se calcula: patrimonio, caja (y por qué un desembolso la baja sin ser un gasto), utilidad neta, interés cobrado (con el ejemplo de la imputación interés-primero), margen, rendimiento mensual, el criterio PAR de la barra vigente/vencida, el aviso ámbar de "crece mientras la caja baja o la mora sube", la meta y la tasa de cobro del día, y el "van N de M días" del ritmo. Documenta explícitamente el **contrato anti-ceros** en lenguaje de usuario (número normal / "sin datos suficientes" / ámbar con aviso) y responde **"¿por qué mi margen sale casi del 100%?"** distinguiendo los dos casos posibles (gastos aún no cargados vs. gastos que se llevan fuera de Credify). Se añaden al glosario `Caja`, `Interés cobrado`, `Margen`, `Patrimonio`, `Rendimiento mensual`, `Saldo por cobrar` y `Utilidad neta`, y se enlaza la página desde el índice de Reportes con su fila en la tabla de permisos (solo admin). **Sin cifras reales del negocio**: el sitio de docs es público, así que todos los ejemplos usan montos ilustrativos. - **Dashboard de salud del negocio para el dueño (PWA + Filament).** El panel mostraba **"Utilidad mes: $0"** porque esa métrica busca ingresos con categoría `loan_payment_interest`, que **ningún servicio escribe**: los 2.272 pagos de la empresa real se registran con la categoría genérica `payment`, sin separar capital de interés. Ahora la rentabilidad se **deriva del ledger de cuotas** con imputación *interés-primero* sobre `payment_installment` (`InterestAttributionService`), y `BusinessMetricsService` compone utilidad neta, margen, rendimiento y flujo de caja por periodo (rolling 30 días contra los 30 previos), con **exclusión explícita de `payment` y `loan_payment_interest`** para no contar dos veces. Anclado a datos reales con el nuevo comando **`credify:verify-interest`**: dos caminos independientes dan **$50.060.363,91** con brecha $0,00. **Trampa encontrada y evitada:** la columna `expenses.affects_profit` está mal poblada en producción (**$84M de desembolsos** y **$10,6M de retiros de utilidad** marcados en 1) — usarla habría dado una utilidad histórica de **−$45M** en vez de **$49,5M**; la regla decide por el enum `ExpenseCategory` y excluye además los retiros, que son reparto y no costo de generar la utilidad. El panel se reordena a **patrimonio y caja → rentabilidad → cartera y riesgo → ritmo**, toda métrica viaja con un **contrato anti-ceros** (`ok`/`no_data`/`unreliable`: sin costos cargados, utilidad *y* margen se marcan `unreliable` en vez de presumir un 98% sano), y se corrigen dos engaños del panel viejo: la **meta del día del dueño** (siempre en 0 porque el backend solo la mandaba al cobrador) y la **polaridad** de "por cobrar" (se pintaba verde aunque la caja cayera y la mora subiera; ahora es `watch`). Sale a la luz lo que ya se calculaba y nadie mostraba: **tasa de cobro del día, cuotas vencidas y cobradores activos**; el sparkline del dueño pasa de 7 a 30 días. Las dos superficies leen del **mismo servicio** (verificado: ambas dan $5.360.158 / +13,1% / 98,2%). De paso se completó `ExpenseCategory::ADMIN_EXPENSE` en los 5 `match` que lo omitían —uno se llama en **cada guardado de gasto**— y se eliminó su excepción del baseline de PHPStan. **Sin migraciones.** Ver `docs/superpowers/specs/2026-09-08-dashboard-salud-negocio-design.md`. - **Analítica de producto con PostHog (PWA Vue, Fase 1).** `posthog-js` integrado en la PWA: helper `resources/js/pwa/analytics.js` (init/identify/capture/reset, todo no-op sin key) + init en `main.js` + `identify`/`login`/`reset` en el store de auth. Región **US** (`us.i.posthog.com`). Mide: **pageviews del SPA** (`capture_pageview: 'history_change'`) + **`identify`** por `user.id` con `role` + `company_id` (cohortes/funnels) + evento `login`; `reset()` en logout. **PII de fintech blindada:** **autocapture OFF** (no captura texto de elementos), **Session Replay OFF**, `person_profiles: 'identified_only'`, `mask_personal_data_properties`, e `identify` **solo** con id/rol/empresa — nunca email/teléfono/documento/nombre. Guardado por `VITE_POSTHOG_KEY` (Project API Key `phc_`, **pública**, horneada en el bundle → sin ella es no-op). **Verificado en vivo:** tras login, los eventos llegan a `us.i.posthog.com/i/v0/e/`. Feature flags/funnels quedan disponibles. **Nota de build:** el bundle de prod necesita `VITE_POSTHOG_KEY` (y `VITE_SENTRY_DSN`) en el entorno de build, o esas integraciones quedan desactivadas. **Fase 2:** eventos de negocio (crédito creado, pago registrado) cuando se definan. - **Tests E2E de la PWA con Playwright (Fase 1: smoke, local).** Se añade el harness de Playwright (`@playwright/test`, `playwright.config.js`, `tests/e2e/`) para probar la PWA Vue de punta a punta — hasta ahora **sin tests JS automatizados** (solo verificación manual). **Fase 1 (smoke):** la pantalla de login renderiza, y el login de los **3 roles** (dueño/supervisor/cobrador) llega al home — en `chromium` Desktop **+ un proyecto Mobile** (Pixel 5), con guard que falla ante **excepciones JS no capturadas** (`pageerror`). El `webServer` levanta `php artisan serve` sobre los assets buildeados; `serviceWorkers: 'block'` evita que el SW precacheado interfiera; los tests corren contra la **empresa demo** (desechable, sembrada). Login estable vía nuevo comando **`credify:e2e-prepare`** (blindado a `local`/`testing`) que fija una contraseña conocida en los usuarios demo — las contraseñas demo reales son aleatorias y rotan a diario. Script `npm run test:e2e`. El CI actual salta la descarga de navegadores (`PLAYWRIGHT_SKIP_BROWSER_DOWNLOAD`); los E2E **no** corren aún en CI. **Requisito local (una vez):** `sudo npx playwright install-deps chromium`. **Fase 2 (pendiente):** flujos de escritura (crear cliente/crédito, registrar/anular pago) + job de E2E en CI. Ver `docs/superpowers/plans/2026-08-13-cloudflare-sentry.md` (Sentry) y este harness. - **Observabilidad con Sentry (errores backend Laravel + frontend PWA Vue).** Se integra Sentry para capturar excepciones del backend y errores JS de la PWA en producción, con stack traces, release por commit y entorno. Backend: `sentry/sentry-laravel` enganchado en `bootstrap/app.php` (`Integration::handles($exceptions)`), respetando el `dontReport`/`report` existente. Frontend: `@sentry/vue` inicializado en `resources/js/pwa/main.js` **después** del `app.config.errorHandler` (el SDK lo conserva y encadena), guardado por `VITE_SENTRY_DSN`. **PII de fintech blindada:** `send_default_pii=false` + `sql_bindings=false` (no se capturan cuerpos de request ni parámetros SQL) + un `SentryPiiScrubberServiceProvider` que filtra montos/documentos/teléfonos/credenciales — registrado **en código, NO como `before_send` en `config/sentry.php`** (un closure allí rompería `config:cache`/`optimize` en cada deploy). **Source maps** del frontend se suben a Sentry en build (WSL/CI) **solo si hay `SENTRY_AUTH_TOKEN`** y se borran de `public/build` tras subir (nunca se sirven en prod); sin token no se generan `.map`. Sentry queda **desactivado en la suite** (`SENTRY_LARAVEL_DSN` vacío en `phpunit.xml`). Es el **Track A** de `docs/superpowers/plans/2026-08-13-cloudflare-sentry.md`; el Track B (Cloudflare DNS + WAF/rate-limit) queda como despliegue de infra aparte. **Dependencia de despliegue:** cablear `SENTRY_LARAVEL_DSN` + `SENTRY_ENVIRONMENT=production` en el `.env` de prod (como se hizo con Resend); los source maps legibles del frontend requieren `SENTRY_AUTH_TOKEN` + slugs. - **SEO técnico on-page de la landing (`credifygo.com`).** Open Graph + Twitter Card (share con preview), **canonical**, `robots`/`theme-color`, favicon (el `.ico` estaba vacío → íconos SVG), y **3 bloques JSON-LD** (`Organization`, `SoftwareApplication`, y `FAQPage` con las 5 preguntas → elegible para *rich snippets* de FAQ). Nuevo `public/sitemap.xml` + `robots.txt` referenciándolo. Meta description reescrita keyword-forward (microcrédito, cobranza, Colombia). **Decisión de marca:** se eliminaron los términos **"pagadiario"/"gota a gota"** de toda la página (connotación negativa/ilegal en Colombia) — posicionamiento como software legítimo. **`og:image`**: banner social 1200×630 generado (`public/og-image.png`, dark + emerald, marca + headline). Es el Track 1 de SEO; contenido/keywords y off-page/ads quedan como tracks aparte. - **Analítica Google Analytics 4 en la landing (Track 2 de SEO — medición).** Snippet `gtag.js` (Measurement ID `G-2S01G726KE`) en el `` de `welcome.blade.php` para medir tráfico y conversión de la landing (visitas, origen, ruta a `/registro`). Complementa la verificación del dominio en Google Search Console + envío del `sitemap.xml`. Solo la landing pública por ahora; instrumentar la PWA autenticada queda como decisión aparte (implica datos de uso de usuarios reales). - **Contenido pilar para SEO (Track 3 — posicionamiento).** 5 páginas evergreen que capturan demanda de búsqueda de quien administra un negocio de préstamos/microcrédito y la canalizan al trial (`/registro`): `/software-para-prestamos`, `/software-de-cobranza`, `/gestion-de-cartera`, `/como-administrar-negocio-de-prestamos` y `/control-de-prestamos-excel` (~1.100–1.800 palabras c/u, enlazado interno hub&spoke, ejemplos en COP, sin **"pagadiario"/"gota a gota"**). Se **extrajo el "chrome" de la landing** a un layout Blade compartido de 2 niveles (`layouts/public` = head+GA+`@vite`+`