Bóveda Personal — App Socio Fondo Solidario Casino Puerto Varas

PWA (Progressive Web App) para socios del Fondo Solidario de Propina del Casino de Puerto Varas. Permite a cada socio consultar su balance, historial de recaudaciones, anticipos, estadísticas y comunicarse con el equipo administrativo.

---

Tabla de Contenidos

1. Resumen del Sistema
2. Arquitectura
3. Estructura de Archivos
4. Frontend
   • Paleta de Colores (Tailwind)
   • Secciones / Tabs
   • Componentes Clave
5. Backend — Google Apps Script
   • Endpoints GAS
   • Hojas de Cálculo (Google Sheets)
6. Service Worker y Caché PWA
7. Despliegue
8. Flujo de Desarrollo
9. Historial de Cambios

---

Resumen del Sistema

Campo	Valor
Nombre de la App	Bóveda Personal
Short name (PWA)	Bóveda
Versión actual	V19 (interna)
Idioma	Español
Orientación	Portrait
Color tema	#001723 (azul marino oscuro)
Framework CSS	Tailwind CSS CDN v3 (plugins: forms, container-queries)
Fuentes	Inter (cuerpo), Manrope (titulares), Material Symbols Outlined (íconos)

---

Arquitectura

┌─────────────────────────────────────────────────────┐
│                  Dispositivo del Socio               │
│  PWA instalada (standalone, portrait)                │
│  ┌──────────────────────────────────────────────┐   │
│  │  index.html  →  app.css  +  app.js           │   │
│  │  Service Worker (sw.js) — cache v12          │   │
│  └────────────────┬─────────────────────────────┘   │
└───────────────────┼─────────────────────────────────┘
                    │ fetch (interceptado por supabase-api.js)
         ┌──────────┴──────────┐
         │                     │
  ┌──────▼──────┐       ┌──────▼──────┐
  │  Supabase   │       │  Supabase   │
  │  Socios     │       │  Recaud.    │
  │  (teemahk…) │       │  (lpulmj…)  │
  └─────────────┘       └─────────────┘

Dos proyectos Supabase independientes:

• Proyecto socios (teemahksasdougehrcly) — socios, anticipos, extras, saldos, chat, conexiones
• Proyecto recaudaciones (lpulmjzboogixbdxxayo) — recaudaciones diarias, divisores, notas

La integración usa un interceptor window.fetch en supabase-api.js que redirige transparentemente las llamadas GAS hacia Supabase sin modificar app.js.

---

Estructura de Archivos

propi.solicitada/
├── index.html          # HTML puro (878 líneas) — estructura de la app
├── app.css             # CSS + configuración de estilos (270 líneas)
├── app.js              # JavaScript completo de la app (2435 líneas)
├── supabase-api.js     # Interceptor fetch → Supabase (nuevo)
├── originalindex.html  # Copia completa en un solo archivo (auto-generada)
├── build.sh            # Script que reconstruye originalindex.html
├── sw.js               # Service Worker — caché v12, network-first
├── manifest.json       # Manifiesto PWA
├── vercel.json         # Cabeceras HTTP para despliegue en Vercel
├── gas/
│   └── code.gs         # Google Apps Script completo (referencia histórica)
├── migration/
│   └── migrate_to_supabase.gs  # Instrucciones de migración (referencia)
├── img/
│   ├── icon-192x192.png
│   └── icon-512x512.png
└── .claude/
    └── settings.json   # Hooks Claude Code (auto-rebuild originalindex.html)

Separación HTML / CSS / JS

El archivo de trabajo principal es index.html + app.css + app.js. originalindex.html se regenera automáticamente con ./build.sh cada vez que se edita cualquiera de los tres archivos separados (via hook de Claude Code en .claude/settings.json).

---

Frontend

Paleta de Colores (Tailwind)

Token	Color	Uso
lm-bg	#f8f9fa	Fondo general de la app
lm-card	#ffffff	Tarjetas y superficies
lm-border	#e1e3e4	Bordes
lm-primary	#001723	Color principal (azul marino)
lm-primary-mid	#002d40	Hover de primario
lm-accent	#264b5f	Acento secundario
lm-secondary	#006a62	Verde (éxito / ganancias)
lm-red	#ba1a1a	Rojo (descuentos / anticipos)
lm-muted	#72787d	Texto secundario
lm-subtle	#f3f4f5	Fondos sutiles
wa-bg	#e5ddd5	Fondo chat WhatsApp-style
wa-mine	#d9fdd3	Burbuja mensaje propio

Secciones / Tabs

ID	Ícono	Descripción
tab-home	account_balance_wallet	Balance — monto a cobrar, remanente, valor punto por noche, resumen contable, últimos movimientos, calendario
tab-history	receipt_long	Historial — dos sub-vistas: Rendimientos (detalle diario) y Anticipos Anteriores (histórico con filtros)
tab-stats	bar_chart	Estadísticas — gráficos del período activo
tab-chat	chat	Mensajes — chat Soporte (admin) y Equipo (entre socios)
tab-perfil	badge	Perfil — datos del socio, años, puntos de antigüedad

Componentes Clave

Header

<header class="px-5 pt-safe-top py-3.5 flex items-center justify-between shrink-0 glass z-20">

• pt-safe-top: clase personalizada = calc(env(safe-area-inset-top) + 0.875rem) → respeta notch/Dynamic Island en iPhone
• glass: fondo semi-transparente con backdrop-filter: blur(24px)

Hero Card (Balance)

• Tarjeta oscura con gradiente #001723 → #002d40 → #264b5f
• Muestra el monto principal formateado en pesos chilenos
• Dos tarjetas secundarias debajo:
  • Remanente (#remateTag): sobrante del período anterior
  • Valor punto por noche (#globalPtsTag): valor unitario del punto en el período

Bottom Nav

<nav id="bottomNav" class="fixed bottom-0 w-full z-[60] pb-safe-bottom">

• pb-safe-bottom: clase personalizada = env(safe-area-inset-bottom) → respeta home indicator iPhone

Toast Notifications

• Posición: top: calc(env(safe-area-inset-top) + 16px) → aparece debajo del notch
• Animación con cubic-bezier(0.34, 1.56, 0.64, 1)

Anticipos Anteriores (dentro de tab-history)

Toggle entre dos vistas: Rendimientos | Anticipos Anteriores

La vista de anticipos incluye:

• Filtro por año (pastillas, aparece si hay ≥ 2 años)
• Filtro por mes (pastillas, aparece al seleccionar un año con ≥ 2 meses)
• Acordeón por período: cada período es una tarjeta colapsable con total y detalle de registros

Funciones JS relacionadas:

switchHistView(view)           // alterna Rendimientos / Anticipos Anteriores
loadHistorialAnticipos()       // fetch con lazy-load (solo carga una vez)
buildFiltroAnios(data)         // construye pastillas de año
buildFiltroMeses(anio, data)   // construye pastillas de mes según año activo
filtrarAnticipos(anio)         // filtra por año + resetea filtro de mes
filtrarAnticiposMes(mes)       // filtra por mes sobre los datos del año activo
togglePeriodo(id)              // expande/colapsa un acordeón de período
renderHistorialAnticipos(data) // renderiza la lista de acordeones
_extraerAnio(periodo)          // extrae año con regex /\b(20\d{2})\b/
_extraerMes(periodo)           // extrae mes de nombres como "Cierre 2025-03" o "Marzo 2025"

Login / Autenticación

• PIN de 4 dígitos por socio
• Cierre automático por inactividad (15 min)
• Recuperación de PIN via RUT
• Dispositivo vinculado mediante ID Socio + RUT + PIN en primer uso

Guía de Ayuda (helpModal)

• Array helpSlides con 11 slides (actualizado en cada feature relevante)
• Cada slide: { icon, color, title, body, preview } donde preview es HTML con mockup visual
• Accesible desde botón ? en el header
• Se muestra automáticamente la primera vez que el socio abre la app

---

Backend — Google Apps Script

El GAS completo de referencia está en gas/code.gs. Los cambios exclusivos de esta app se describen abajo.

Endpoints GAS

SCRIPT_URL_SOCIOS (doGet + doPost)

Action	Método	Descripción
getSocios	GET	Lista todos los socios
getDatosSocio	GET	Datos de un socio específico
getAllDataDesdeSheets	POST	Datos completos de anticipos, extras, notas del socio
getSaldosAnteriores	GET	Saldos anteriores del período
getSaldosCierre	GET	Saldos de cierre / remanentes
getDiasPartTime	GET	Días trabajados (socios Part-Time)
getNotes	GET	Notas del período (mensajes admin)
pingConexion	POST	Heartbeat cada 2 min — deja constancia de la conexión en Supabase
logoutConexion	POST	Registra el cierre de sesión y borra UltimaConexion
getHistorialConexiones	GET	Historial de conexiones del socio
addNote / deleteNote	POST	CRUD de notas admin
registrarBatchAnticipos	POST	Registra múltiples anticipos
registrarBatchExtras	POST	Registra movimientos extra
actualizarAnticipo	POST	Modifica un anticipo existente
reiniciarAnticipos / reiniciarExtras	POST	Borra anticipos/extras del período
borrarMovimiento	POST	Elimina un movimiento por UUID
registrarSaldoAnterior	POST	Guarda saldo anterior para el próximo período
guardarDiasPartTime / guardarBatchDiasPartTime	POST	Guarda días Part-Time
guardarCierreIndividual	POST	Guarda cierre de un socio

SCRIPT_URL_RECAUDACIONES (doGet)

Action	Descripción
get	Datos de recaudación diaria del período activo
getNotes	Notas de recaudaciones
ping	Verificación de conexión

Hojas de Cálculo (Google Sheets)

Constante GAS	Nombre de hoja	Columnas principales
HOJA_SOCIOS	Socios	ID, Nombre, Apellido, FechaIngreso, Area, TipoContrato, UltimaConexion
HOJA_ANTICIPOS	Anticipos	ID Socio, Nombre Completo, Fecha Anticipo, Monto, Estado, UUID, Responsable, AreaResponsable
HOJA_EXTRAS	MovimientosExtras	ID Socio, Nombre, Fecha, Tipo, Monto, Detalle/Nota, Estado, UUID
HOJA_SALDOS	SaldosAnteriores	ID Socio, Nombre, MontoSaldo, UltimaActualizacion
HOJA_DIAS_PT	DiasPartTime	ID Socio, Nombre, DiasJSON
HOJA_SALDOS_CIERRE	SaldosCierreMes	ID Socio, Nombre, MontoRemanente, FechaCierre
HOJA_CHAT_SOCIAL	MensajesApp	Mensajería entre socios
HOJA_ANTICIPOS_HISTORIAL	AnticiposGuardados	Anticipos de períodos cerrados (cols: ID, ?, Fecha, Monto, FechaCierre, ?, Responsable)
HOJA_HISTORIAL_CONEXIONES	HistorialConexiones	Log de conexiones por socio
HOJA_AUDITORIA	AuditoriaLogs	Auditoría de todas las acciones
HOJA_CREDENCIALES	Credenciales	PINs y credenciales de socios
HOJA_RETIROS_ANTICIPOS	RetirosAnticipos	Retiros de anticipos registrados
HOJA_MATERIALES	RecaudacionMateriales	Materiales de recaudación
—	Anticipos_*	Hojas dinámicas por período (ej: Anticipos_2025-Enero) para historial completo

---

Service Worker y Caché PWA

Archivo: sw.js — versión boveda-personal-v14

Estrategia:

• Archivos propios (index.html, app.css, app.js, manifest.json, imágenes) → Network-first (siempre intenta red, fallback a caché)
• Llamadas a script.google.com (GAS) → Always network, nunca caché, fallback a JSON de error
• CDNs externos (fonts, Tailwind) → No interceptar

Actualizaciones:

• skipWaiting() en install → el nuevo SW se activa de inmediato
• clients.claim() en activate → toma control de todas las pestañas abiertas
• Banner de "Nueva versión disponible" → showUpdateBanner() en el front; el usuario acepta y el SW envía SKIP_WAITING
• Chequeo automático de actualización en visibilitychange (cada vez que la app vuelve al frente)

Archivos cacheados:

index.html · app.css · app.js · manifest.json
img/icon-192x192.png · img/icon-512x512.png

Headers especiales (vercel.json):

• sw.js → Cache-Control: no-cache, no-store, must-revalidate (el service worker nunca se sirve desde caché del servidor)
• Service-Worker-Allowed: /

---

Despliegue

La app se despliega en Vercel directamente desde este repositorio GitHub (33Javier33/propi.solicitada), rama main.

Rama principal: main
Rama de desarrollo Claude Code: claude/sheets-to-supabase-migration-i1dlcm (migración Supabase)

Para actualizar la app en producción: hacer push a main. Vercel detecta el push y redistribuye automáticamente.

Reinstalación del PWA en iPhone (tras cambios de CSS/JS): El service worker usa network-first, por lo que los cambios se aplican en la siguiente apertura con conexión. Si el SW no se actualiza, desinstalar la app del home screen y volver a agregarla.

---

Flujo de Desarrollo

Archivos a editar

Tarea	Archivo
Estructura HTML, modales, layout	index.html
Estilos, CSS variables, clases custom	app.css
Lógica JS, funciones, llamadas GAS	app.js
Adaptador Supabase / interceptor fetch	supabase-api.js
Backend / lógica Google Sheets (referencia)	gas/code.gs
Caché PWA	sw.js (incrementar CACHE_NAME al cambiar archivos)

Build automático

Al editar index.html, app.css o app.js dentro de Claude Code, el hook en .claude/settings.json ejecuta automáticamente ./build.sh, que regenera originalindex.html (versión completa en un solo archivo).

Para ejecutar manualmente:

./build.sh

Convención de versiones — Service Worker

Cada vez que se publican cambios en archivos del front-end, incrementar el número de versión en sw.js:

const CACHE_NAME = 'boveda-personal-v14'; // ← incrementar

Commit y push

git add -p                    # revisar cambios antes de agregar
git commit -m "descripción"
git push -u origin main

Importante: Cada vez que se implementa un cambio relevante en la app, actualizar la sección Historial de Cambios en este README.

---

Historial de Cambios

2026-10-25 — La fecha de «Reportar recaudación» ya no se adelanta de noche (SW v198)

El "hoy" del campo de fecha se calculaba con toISOString(), que da la fecha en UTC — tres o cuatro horas adelante de Chile. A partir de las 20:00 o 21:00 el modal se abría con el día siguiente, y en un casino que trabaja de noche eso es casi todos los turnos.

Medido con el reloj puesto a las 22:30 del 3 de septiembre en horario de Chile: la forma vieja decía 2026-09-04; la nueva dice 2026-09-03.

Además, la fecha se queda donde la dejen mientras la app esté abierta: si se corrige una vez, el siguiente reporte se abre en esa misma fecha en vez de volver a hoy. Abrir el modal tocando un día faltante sigue mandando sobre todo lo demás — esa fecha es explícita y gana.

2026-10-20 — Acerca de: el cargo de Encargado queda con fecha de término (SW v197)

El texto decía que desde el 15 de noviembre de 2025 «cumple el rol de Encargado del Fondo Solidario de Propina», sin término. El cargo va hasta el 15 de noviembre de 2026; después continúa como socio del fondo y a cargo de esta plataforma.

Redactado para que sea cierto hoy y después, sin tener que volver a tocarlo cuando llegue la fecha:

Colaborador del Casino de Puerto Varas desde 2013, actualmente ejerce como Croupier. Encargado del Fondo Solidario de Propina desde el 15 de noviembre de 2025 hasta el 15 de noviembre de 2026, velando por los derechos económicos de todos los socios. Seguirá como socio del fondo y a cargo del desarrollo y la mantención de esta plataforma.

También: el nombre pasa de «Carlos» a «Carlos P. Nauto», y se retira la línea «Encargado Fondo Solidario · Desde 15/11/2025» que iba bajo él — decía lo mismo sin el término y quedaba contradiciendo al párrafo.

2026-10-18 — «SUBE PUNTOS» del comprobante: día 15 y respetando el override (SW v196)

Comparando el comprobante de esta app con el recibo de socios-comicion apareció que los dos decían mal esa línea, de formas distintas. El grueso del error estaba en la administración (usaba el mes de la primera entrega en vez del del aniversario), pero acá había dos detalles:

• El día salía del ingreso: «10 JUN» para quien entró un día 10. El aumento anual cae siempre el día 15.
• No respetaba el override: a un socio con la fecha de inicio de puntos puesta a mano por la administración le mostraba igual el mes de ingreso.

Nuevo _subePuntosLabel(), que aplica la misma regla que reglaPuntosFechas en socios-comicion: día 15 del mes de ingreso, o del mes del override si lo hay. Las tres apps dicen ahora lo mismo, verificado corriendo sus implementaciones reales sobre los mismos socios.

2026-10-16 — El ID ya no se lee en la pantalla de ingreso (SW v195)

La pantalla de ingreso mostraba el ID completo: ID: SOC-1764786246858. Ese dato se ve antes de autenticarse —cualquiera que tome el teléfono lo lee— y junto con el PIN es la credencial de entrada. Ahora va tapado: ID: SOC-************.

Se conserva el prefijo (SOC-) para que el socio reconozca que es el suyo, y el resto en asteriscos. La cantidad es fija a propósito: calcarla al largo real delataría cuántos dígitos tiene.

Dentro de la app, ya autenticado, el ID se sigue viendo en el perfil — el socio necesita poder leerlo para dárselo a la administración.

8 comprobaciones más en test_saldo_oculto.js (50 en total): que no quede ningún dígito, que dos IDs de largo distinto se tapen igual, que un ID sin prefijo también se tape, y que sin ID no se invente nada.

2026-10-16 — El número de la tarjeta es el ID del login, y el candado también lo tapa (SW v194)

Dos cosas que quedaron pendientes del candado:

1. El número mostraba un recorte del ID, no el ID. Se le quitaban las letras y se tomaban los últimos cuatro dígitos: un ID como SOC-001 quedaba en 001, que no se reconoce como el de nadie. Ahora va el ID completo con el que el socio entra, en el último grupo: •••• •••• •••• SOC-001. Para un ID numérico corto el resultado se ve igual que antes, pero ahora es el dato real y no una coincidencia.

2. Con el candado puesto el número seguía legible. Quedaba el balance tapado y el ID del socio a la vista en la misma tarjeta — justo lo que el candado busca evitar. Ahora se tapa también, con su propia máscara (•••• •••• •••• ••••) y no con la del monto: _ponerMonto() acepta una máscara por elemento, así que cada cosa se tapa con lo que le corresponde.

test_saldo_oculto.js sube a 42 comprobaciones: que el número sea el ID, que un ID con letras se muestre entero, que el candado lo tape sin dejar ver los dígitos, que use su máscara y no la del monto, y que al destapar vuelva.

2026-10-16 — Candado del saldo: tapar el balance con un ojito (SW v193)

Como en las apps del banco: un ojito en la tarjeta tapa el balance para que no quede a la vista de cualquiera que mire la pantalla, y lo vuelve a mostrar. La elección se guarda, así que al cerrar y volver a abrir la app sigue como la dejaste.

Con el candado puesto se tapan todos los montos personales —el balance de la tarjeta, el de arriba, el remanente y los del panel premium— con $ ••••••. No se tapan los puntos ni el valor punto por noche: no son plata de nadie en particular.

Se tapa al escribir, no después. Si el monto real se pintara y se ocultara en un segundo paso, alcanzaría a verse en cada refresco. _ponerMonto() guarda el valor real en data-real y pinta la máscara o el monto según el candado, así que el número nunca pasa por la pantalla. La prueba lo vigila con un MutationObserver sobre el nodo durante un refresco completo: el monto real no aparece ni una vez.

Dos detalles que podrían haber salido mal:

• La tarjeta y el panel premium se copian el monto entre sí. Si copiaran el texto visible, se copiarían la máscara y al destapar quedarían con •••• pegado. Ahora leen el valor real, no lo que está en pantalla.
• El comprobante que el socio descarga NO se tapa. Tapar la pantalla es para que no la miren de reojo; el documento tiene que traer sus cifras igual.

test_saldo_oculto.js: 31 comprobaciones — tapar, destapar, que persista tras recargar la app entera, que el refresco no filtre el monto, y que el comprobante siga completo.

2026-10-16 — «Total Puntos» y «Pts Planta» no seguían a socios-comicion (SW v192)

La causa, en una línea: el shim mapeaba fecha_inicio_puntos al nombre FechaInicioLiquidacion, que no lo leía nadie, mientras el cálculo buscaba FechaInicioPuntos, que nadie escribía. El campo llegaba a la app y se perdía en silencio.

Un campo escrito y nunca leído, y otro leído y nunca escrito. Sin error en consola, sin dato vacío a la vista: simplemente el override de la fecha de inicio de puntos no se aplicaba, así que a los socios con fecha movida a mano se les contaban puntos desde la fecha equivocada —o se les contaban cuando todavía no correspondía— y los dos números no cuadraban con los de la administración.

Se nota ahora porque hace dos versiones se arregló que esa fecha se pudiera guardar en socios-comicion (antes el volcado de la planilla la pisaba). Recién cuando empezó a haber overrides reales quedó a la vista que esta app los ignoraba.

El arreglo. getSocios entrega FechaInicioPuntos, el nombre que usan socios-comicion y diario.propi. Se conserva FechaInicioLiquidacion como alias, y el lado que lee acepta los dos: los socios guardados en la caché local por versiones anteriores solo traen el nombre viejo, y sin el alias los puntos seguirían saliendo mal hasta que la caché se renovara.

De paso, los años de antigüedad del propio socio salían del ingreso aunque tuviera override. Nuevo _aniosDeSocio() los resuelve en un solo lugar, igual que procesarSocioDesdeGoogle en la administración.

Verificación. test_puntos_propi.js levanta las dos apps y corre sus implementaciones reales —procesarSocioDesdeGoogle y _recCalcTotalPuntos— sobre los mismos socios, exigiendo que coincidan. Los casos que separan a las dos: override hacia atrás, override a futuro (aún no le corren puntos), override igual al ingreso (es un eco, no una excepción), recién ingresado sin cumplir el mes, y Gastos Comisión. 21 comprobaciones, incluida la de la caché vieja.

Una diferencia que se deja a propósito: en Gastos Comisión la administración registra 0 años porque la antigüedad no les mueve los puntos (siempre 1), pero la app del socio le muestra su antigüedad real. Son dos cosas distintas y las dos están bien; la prueba lo fija explícitamente para que nadie lo «corrija» después.

2026-10-15 — El socio que ya cobró queda en $0, igual que en la administración (SW v191)

El problema. Cuando la administración le cerraba el mes a un socio y éste retiraba su plata, la app le seguía mostrando el monto completo, como si aún tuviera que recibirlo. La recaudación del período sigue cargada —no se archiva— así que el balance se volvía a calcular entero.

La regla, la misma que ahora aplica socios-comicion:

Estado del cierre	Qué ve el socio
Cobrado	Balance en $0 — parte el mes nuevo solo con su saldo anterior (el remanente del cierre)
En sobre	El monto se mantiene: la plata es suya y lo está esperando. Solo se le avisa que el mes ya se cerró y que pase a retirarlo

Esa distinción importa: poner en $0 al socio que todavía no retira le escondería plata que es suya.

Cómo lo sabe. Nueva acción getCierresMes en supabase-api.js, que lee la tabla cierres_mes del proyecto de socios — la misma que escribe la administración al cerrar. Mientras la fila exista, ese mes está liquidado. Se vacía al archivar el período, que es cuando empieza el mes siguiente, así que el socio vuelve a acumular solo. No hizo falta ninguna tabla nueva.

El aviso. Sobre la tarjeta de balance, para que ver $0 no parezca que la app perdió sus datos:

✅ Tu mes ya fue pagado — Se cerró el 14 de octubre y ya retiraste $95.000. Por eso tu balance parte en $0: lo que ves abajo es tu saldo para el mes nuevo.

El comprobante sigue sirviendo. Antes se bloqueaba con «los datos aún no han cargado» justo cuando el balance quedaba en 0 — o sea, exactamente después de cobrar. Ahora, si hay cierre, imprime lo que se liquidó (mismo criterio que el recibo del admin), no los ceros del mes nuevo.

Si no se puede leer el cierre, el monto no reaparece. Una lectura caída conserva el último cierre conocido. Sin esto, un corte de red le devolvería al socio un monto que ya cobró — que es justo el error que se está corrigiendo.

test_propi_cierre.js: 25 comprobaciones sobre los tres estados (sin cierre, en sobre, cobrado), el comprobante, que la recaudación quede intacta, y el caso de la lectura caída.

2026-10-14 — Formato en los mensajes: negrita, subrayado y listas (SW v190)

La app ya sabía mostrar mensajes con formato: notaHTML() los pinta saneados con la misma lista blanca que usa socios-comicion en sus Notas. Lo que faltaba era poder escribirlos — el cuadro mandaba innerText y el formato se perdía al enviar.

Nueva barra de formato, con los mismos nueve botones que socios-comicion:

B · I · U	negrita, cursiva, subrayado
⯇ ≡ ⯈	alinear a la izquierda, centrar, a la derecha
•— · 1.	lista con viñetas, lista numerada
✕	quitar formato

Se abre con el botón Aa, que va dentro de la burbuja de escritura: un cuarto botón redondo afuera dejaba el campo muy angosto en un teléfono. Queda cerrada por omisión — sobre el teclado hay poco espacio y la mayoría de los mensajes no llevan formato. La barra se desliza en horizontal en vez de apilarse, para no empujar el teclado.

Detalles que importan:

• Lo que se manda es exactamente lo que se va a mostrar. getChatText() devuelve el HTML pasado por sanearNota(), la misma función con la que se pinta. Nada que no sobreviva al saneado llega a viajar.
• Sin formato de por medio, el mensaje sigue siendo texto plano. Un «Hola, ¿cómo están?» no se convierte en HTML, así que los mensajes de siempre no cambian en nada.
• Editar no aplana el formato. Si el mensaje traía negritas, vuelve al editor con ellas; antes se metía como texto plano y corregir una palabra borraba el formato del resto.
• Pegar entra siempre como texto plano, para que no se cuele el formato de Word o de una página.
• Los botones se marcan según dónde esté el cursor, como en Word.
• Solo etiquetas y espacios cuenta como vacío, para que la validación de «escribe algo o adjunta una foto» siga sirviendo.

Los tres modos del chat (Administración, Social y Privado) ya pintaban con notaHTML(), así que el formato se ve en los tres. Y como la lista blanca es idéntica a la de socios-comicion (B,STRONG,I,EM,U,BR,P,DIV,SPAN,UL,OL,LI,A), lo que se redacta acá se ve igual allá y al revés.

test_chat_formato.js: 43 comprobaciones, incluidas las de saneado (script, img con onerror, enlaces javascript:, estilos no permitidos).

2026-10-13 — Se retira el balance clásico y el comprobante sube al header (SW v189)

Dos cambios que van juntos:

1. El balance se muestra siempre como tarjeta. Hasta ahora convivían dos vistas —la clásica (#pmBalanceCard) y la tarjeta— con un botón para saltar de una a otra. Desde que la tarjeta tiene ocho versiones para elegir en Configuración, la clásica sobraba. Se retiró el bloque, se quitaron los botones de cambio de vista y la tarjeta queda limpia, sin nada encima.

2. El comprobante sube al header. El botón de descargar comprobante vivía escondido dentro de la tarjeta. Ahora está arriba, junto a la campana, la ayuda y el botón de salir, con las mismas clases que ellos para que se vea igual.

En su lugar se quitó la píldora con el área (● mesas), porque era el mismo dato dos veces: el área ya sale justo debajo del saludo, en «mesas · Casino Puerto Varas» (#pmRolTxt), que es la que se queda.

Un error que la prueba destapó. Al dejar la tarjeta siempre visible, _aplicarBalanceEstilo pasó a llamar siempre a _refrescarTarjeta, y esa lee currentUser.ID. Antes solo corría al elegir la vista «tarjeta», así que nunca se topaba con currentUser en nulo; ahora corre también al cargar la app antes de entrar, y reventaba en el arranque. Lleva su guarda, y la prueba cubre ese caso.

Archivos: index.html, app.js, originalindex.html, sw.js, version.js.

2026-10-12 — «Total Puntos» y «Pts Planta» de Recaudación del Día no cuadraban (SW v188)

Los dos números que salen al abrir Recaudación del Día no coincidían con el panel de Gestión de Socios de socios-comicion ni con la franja de diario.propi.

La causa: una tercera copia de la regla, con la versión vieja. _recCalcTotalPuntos rehacía por su cuenta el cálculo de cuándo empiezan los puntos, y lo hacía mal:

	Cuándo empieza a contar un socio
socios-comicion y diario.propi	El primer día 15 en o después de cumplir el primer mes
Recaudación del Día (lo que hacía)	El día 15 del mes de ingreso

Con el Ejemplo A de la política —ingresa el 4 de septiembre— este botón le contaba puntos desde el 15 de septiembre y las otras dos apps desde el 15 de octubre. Sobre la nómina de prueba daba 123 / 83 donde las otras dos daban 119 / 79.

Lo llamativo es que esta app ya tenía la regla correcta en _aniosPuntos; el agregado simplemente no la usaba. La causa de fondo era que el cálculo de la primera entrega estaba enterrado dentro de _aniosPuntos, así que quien necesitaba ese dato lo rehacía. Ahora está suelto en _primeraEntregaPuntos() y las dos funciones lo comparten.

De paso se corrigió que fecha_inicio_puntos manda solo cuando difiere de la fecha de ingreso: si viene igual no es una excepción manual, es un eco del ingreso.

Después del cambio: las tres apps dan lo mismo en 293.460 combinaciones de fecha de ingreso, área y puntaje guardado.

Se barrieron los tres repos buscando una cuarta copia de la regla. No hay: los únicos new Date(año, mes, 15) que quedan en el cálculo de puntos están en la rama del override manual, donde sí corresponde. El resto de los «día 15» del código son el cálculo del período 15→14, que es otra cosa.

Archivos: app.js, index.html, originalindex.html, sw.js, version.js.

2026-10-12 — Ocho versiones para la tarjeta del balance (SW v187)

La tarjeta no seguía ningún tema: daba igual que la app estuviera en claro, oscuro o rosa, siempre era el mismo azul petróleo. Los colores estaban escritos a mano en el HTML, y había incluso una regla en app.css que la forzaba a blanco para que el tema no la tocara.

Ahora se elige entre ocho diseños, todos conservando «Fondo Solidario · Casino Puerto Varas»:

Diseño	Cómo es
Medianoche	La de siempre: azul petróleo con chip dorado. Sigue siendo la que viene puesta
Ónix	Negro con chip dorado
Océano	Azul profundo con chip celeste
Esmeralda	Verde oscuro con chip menta
Vino	Burdeos con chip rosado
Pasto	Verde oliva con chip lima
Lavanda	Violeta con chip lila
Platino	Clara, plateada, con texto azul noche y chip dorado viejo

Se elige en Configuración → Versión de la tarjeta, con una miniatura de cada una. Va aparte del tema de la app, a propósito: el tema viste la app y la tarjeta es la tarjeta, así que se puede tener la app en oscuro y la tarjeta en Platino. Se guarda en ese dispositivo, como el tema.

Cómo está hecho. Todo el color sale de --tj-base, que es el color del texto en RGB suelto; los grises de la tarjeta son ese mismo color con transparencia. Así, una tarjeta clara solo cambia esa variable y toda la jerarquía se da vuelta sola — es lo que hace posible Platino sin duplicar ni una regla.

Las transparencias no son a ojo. Se midieron contra el tope más claro del degradado de cada diseño, que es el caso peor. Con las que tenía la tarjeta original, «Casino Puerto Varas» daba 4,34:1 en Medianoche y habría dado 3,83:1 en Pasto, bajo el mínimo de 4,5. Subidas, el peor de los ocho diseños queda en 5,37:1.

Dos cosas que se arreglaron de paso: la tarjeta original ya venía con ese contraste flojo, y los nombres del selector usaban al principio variables de socios-comicion (--rf-suave, --rf-bd) que en esta app no existen, así que caían a un gris ilegible sobre fondo oscuro. Ahora llevan su variante explícita para data-theme="oscuro", que cubre de una vez a Oscuro, Negro y todos los temas con tinte.

Archivos: app.css, app.js, index.html, originalindex.html, sw.js, version.js.

2026-10-10 — Solución de superposición en la sección Mensajes (SW v186)

• Corrección de z-index: En la sección Mensajes (tab-chat), la capa fija del chat tenía un z-index: 40 mientras que el <header> superior de la aplicación tenía un z-index: 20. Esto provocaba que la sección de mensajes cubriera los botones del encabezado (incluido el botón para cerrar sesión logout()), impidiendo cerrar la app o interactuar con el header estando en la pestaña Mensajes. Se elevó la clase del header a z-50, de modo que queda correctamente posicionado sobre el chat (z-40) y debajo de la barra de navegación inferior (z-60).
• Service Worker: Se incrementó la versión a boveda-personal-v186 en sw.js, version.js e index.html.

Archivos: index.html, sw.js, version.js, README.md, originalindex.html (regenerado).

2026-10-10 — Corrección de atributo src en fotoGrandeImg e incremento a SW v185

• Corrección de HTML: Se reemplazó el atributo src="" vacío en la etiqueta <img id="fotoGrandeImg"> de index.html por un data URI SVG transparente placeholder (data:image/svg+xml,...). Esto evita peticiones HTTP redundantes a la raíz al cargar el documento y resuelve la advertencia/error detectado por las herramientas de validación HTML.
• Service Worker: Se incrementó la versión a boveda-personal-v185 en sw.js, version.js e index.html para asegurar que los navegadores y PWA actualicen sus recursos cacheados.

Archivos: index.html, sw.js, version.js, README.md, originalindex.html (regenerado).

2026-10-08 — Cuatro fondos nuevos: dos azules y dos verde pasto (SW v184)

En Configuración → Tema de la app había doce fondos. Ahora hay dieciséis:

Fondo	Cómo es
Cielo ☁️	Azul de día: fondo celeste muy suave, textos en azul marino.
Océano 🌊	Azul de noche, más azul que el Oscuro de fábrica (que tira a gris).
Pasto 🌱	Verde pasto de verdad: tira a amarillo, no a azul como Menta.
Campo 🌳	El Pasto de noche: el mismo verde lima, pero sobre fondo oscuro.

Funcionan como los que ya estaban: se eligen con un toque, se guardan en ese teléfono, tiñen la barra de arriba del celular y vuelven puestos al abrir la app, sin el parpadeo a blanco.

Cielo y Pasto son temas claros completos; Océano y Campo se montan sobre la base oscura con un tinte (data-tinte), igual que Esmeralda, Grafito, Vino e Índigo.

Un detalle de color: en Pasto el acento es verde oliva #4d7c0f y no el lima #65a30d — sobre el lima, el texto blanco de las pastillas daba 3,1:1 y no se leía; con el oliva da 5,1:1. En Cielo pasa lo mismo: el acento es #2563eb y no #3b82f6.

Archivos: app.css, app.js, index.html, sw.js.

2026-10-07 — Los años de antigüedad, con la misma regla que la comisión (SW v183)

Acá los años se contaban por el día exacto de ingreso: quien entró un 23 de octubre sumaba un año el 23 de octubre. En la app de la comisión el aumento cae el 15 del mes de ingreso. Durante esas dos semanas el socio veía un número distinto al que tenía la comisión.

Ahora el cálculo es el mismo en las dos apps, siguiendo la política: los primeros puntos llegan el primer día 15 al cumplir un mes de contrato, y suben cada 15 del mes de ingreso.

Afecta lo que se muestra cuando la base no trae un valor guardado de puntos; si el socio ya tiene puntos cargados, ese número sigue mandando, igual que antes.

Verificación: las mismas 32 comprobaciones compartidas con socios-comicion, más el perfil del socio mostrando los puntos que corresponden.

Archivos: app.js, index.html, sw.js, version.js, originalindex.html (regenerado).

2026-10-04 — El socio de Bóveda veía mal sus puntos (SW v182)

La regla: todos parten en 4 puntos y suman +2 por año cumplido hasta el tope de su área. Bóveda es la única excepción: parte en 2, tope 10.

La fórmula estaba escrita tres veces en app.js y dos de ellas no tenían la regla de Bóveda: al socio de bóveda su propio perfil le calculaba el base 4. Con 2 años de antigüedad le mostraba 8 puntos donde le corresponden 6.

Además, el área se comparaba con tildes en uno de esos lugares ('bóveda' !== 'boveda'), lo que también dejaba fuera a Máquinas y Técnicos de su tope de 12.

Ahora las tres salen de un solo sitio, _reglaPuntosArea, que compara el área sin tildes ni espacios y dice lo mismo que reglaPuntosArea de socios-comicion.

Esto solo afecta lo que se MUESTRA cuando la base no trae un valor guardado. Si el socio tiene puntos cargados en Supabase, ese número sigue mandando, igual que antes — y si ese número está mal, se corrige desde la app de la comisión, que ahora avisa de los casos así.

Verificación: 32 comprobaciones compartidas con socios-comicion — base y tope de cada área escrita con tilde, sin tilde, en mayúsculas y con espacios; la serie año por año; que Bóveda sea la única que parte en 2; y que el perfil del socio de bóveda con 2 años muestre 6 y no 8.

Archivos: app.js, index.html, sw.js, version.js, originalindex.html (regenerado).

2026-10-04 — Las ausencias seguidas se ven como un tramo (SW v181)

Si el socio faltó varios días seguidos —una licencia, por ejemplo—, en Ver Calendario → Ausencias del período aparecían como una tarjeta suelta por día. Con una licencia de 19 días había que sumar de cabeza para saber cuánto se dejó de percibir.

Ahora los días seguidos del mismo motivo son UNA tarjeta: Del 16 de septiembre al 20 de septiembre · Licencia Médica · 5 días · −$100.000. Tocándola se abre y muestra día por día cuánto fue cada uno, con el total al final.

Mismo criterio que en la app de la comisión: seguidos y del mismo motivo. Una licencia pegada a un permiso son dos tramos, no uno; y una ausencia de un día solo se sigue viendo como una tarjeta normal, sin flecha.

El motivo ahora viaja con el día, así la tarjeta puede decir de qué fue la ausencia — antes solo se veía la fecha y el monto.

Los totales de arriba no cambiaron: siguen contando los días reales del período (8 días, no 3 tarjetas) y el monto completo.

El Part-Time queda exactamente igual: sus días trabajados siguen uno por tarjeta, en verde y sumando.

Verificación: 19 comprobaciones — que 8 días queden en 3 tarjetas; que el permiso pegado vaya aparte; que el día suelto no se pliegue; abrir, cerrar y la flecha; que el detalle liste sus 5 días con el total al final; que los contadores de arriba sigan con los días reales; el Part-Time intacto; y la lista vacía sin romperse.

Nota honesta sobre el contraste: en este entorno no se puede medir, porque las clases de color de la app (text-lm-*, bg-lm-*) vienen del CDN de Tailwind, que está bloqueado. Lo que sí se verificó es que el bloque nuevo no trae ningún color escrito a mano: usa las mismas clases que las tarjetas que ya estaban en esa lista.

Archivos: app.js, index.html, sw.js, version.js, originalindex.html (regenerado).

2026-09-29 — La guía ahora explica el QR y el RUT (SW v180)

La guía de bienvenida pasa de 23 a 24 diapositivas.

Nueva: «Entrar con el QR de la administración». Explica escanear con la cámara, que pregunta a qué app entrar —esta o el Diario—, que el mismo código sirve una vez en cada una, y que los datos llegan puestos y solo hay que crear el PIN. Con la advertencia clara: quien tenga ese código puede entrar como tú, no lo reenvíes, y vence a los 3 días.

Actualizada: «¿Por qué me pidieron el RUT?». Desde v179 el RUT se compara con el que la administración tenga registrada. La diapositiva decía solo para qué sirve; ahora avisa que tiene que ser el tuyo, explica que eso es lo que impide que otra persona vincule tu cuenta sabiendo solo tu ID, y dice qué hacer si no coincide: pedir el QR de acceso.

Verificación: 12 comprobaciones — que la guía abra y el contador diga 24, que la diapositiva del QR se pueda abrir y su texto se pinte, y que los avisos de seguridad estén en el texto.

Archivos: app.js, sw.js, version.js, originalindex.html (regenerado).

2026-09-28 — Entrar con el QR que emite la administración (SW v179)

El QR que se genera en socios-comicion abre esta app con los datos del socio ya puestos. Al escanearlo pregunta a qué app quiere entrar —esta o diario.propi— y sigue desde ahí.

• El QR no trae los datos, trae un código opaco (?qr=<32 hex>) que se canjea contra Supabase. Así caduca, se puede anular, y ni el nombre ni el RUT viajan en la URL.
• Lo que ya está en la ficha llega puesto y de solo lectura (el ID siempre; el RUT cuando lo tiene). Lo que falta se pide, y se guarda de vuelta en la ficha. De 67 socios, 46 no tienen RUT y 50 no tienen correo, así que pedirlos es el caso normal: el QR va completando la base sola.
• La función de Supabase que guarda solo rellena campos vacíos: si el socio se equivoca al tipear, no puede pisar un dato que la administración ya cargó.
• Si el código está vencido, ya usado o no existe, lo dice y deja el ingreso normal disponible; no queda la pantalla a medio rellenar.

Un problema que apareció al probarlo, y que habría roto justo el caso que importa: en la primera visita el Service Worker se instala, toma el control y la página se recarga sola (index.html, controllerchange). El código ya había salido de la URL, así que esa recarga se lo llevaba — y la primera visita es exactamente la del socio que estrena la app con su QR. Ahora el código se guarda en sessionStorage en cuanto se lee y de ahí se recupera tras la recarga; se olvida en cuanto se canjea, para no reintentar un código ya usado. sessionStorage es el lugar correcto: sobrevive la recarga y muere al cerrar la pestaña.

Además, la vinculación ahora compara el RUT. Antes handleSetup buscaba al socio solo por ID y del RUT validaba únicamente el formato, nunca lo comparaba con el guardado (app.js 241 y 247). Como los IDs son adivinables (SOC-…), con un ID válido cualquiera podía vincularse como ese socio y crearle el PIN. Ahora, si el socio tiene RUT en su ficha, tiene que coincidir. Si no lo tiene no hay contra qué comparar, así que se acepta y queda registrado — es el caso de la mayoría, y el QR es el camino para ir completándolos.

Verificación: 19 comprobaciones del escaneo (elección de app, que el código salga de la URL antes de canjear nada, socio sin datos vs. socio completo, correo inválido rechazado, que lo completado se mande con el código, código vencido) y 6 del RUT: con un RUT ajeno no vincula y lo dice; con el suyo sí; y si su ficha no tiene RUT, se acepta el que escriba.

Archivos: qr-entrada.js (nuevo), app.js, index.html, sw.js, version.js, vercel.json, originalindex.html (regenerado).

2026-09-28 — El navegador pedía actualizar la contraseña en cada acción (SW v178)

• Síntoma: el navegador preguntaba «¿Actualizar la contraseña?» en cada acción —agregar un billete en el arqueo, abrir un modal, cualquier cosa—, no solo al entrar.
• Causa: al entrar bien, el campo del PIN nunca se vaciaba. Quedaba en el HTML con el PIN adentro, escondido dentro del overlay del login. El gestor de contraseñas del navegador re-evalúa los campos type="password" ante cualquier cambio de la página y, como ya tenía una credencial guardada para el sitio, salía a ofrecer actualizarla una y otra vez. El autocomplete="off" que ya tenía no sirve para esto: los gestores lo ignoran para el aviso de guardar.
• Arreglo: al entrar, el campo se vacía y deja de ser type="password"; al cerrar sesión vuelve a serlo, que es cuando de verdad se usa. Mientras usas la app no queda ningún campo de contraseña en la página, así que el navegador no tiene nada que ofrecer.
• Los otros 7 PIN de la app —configuración, cambio de clave, firma de certificados, borrar un desglose, clave de recuperación— pasaron a ser texto enmascarado con CSS (.campo-secreto). Se ven igual de ocultos, pero el navegador no los confunde con la clave del sitio. El único type="password" que queda es el del login, que es el que corresponde.
• Se revisó la misma falla en las otras apps: diario.propi y propi.solicitada la tenían igual y quedaron arregladas. Horarios no la tiene, porque usa teclado numérico en vez de un campo.
• Verificación: 9 comprobaciones — antes de entrar hay un campo de contraseña, ya dentro hay cero, el PIN queda vacío, los 7 campos internos son texto y se ven ocultos, y al cerrar sesión el login vuelve a ser contraseña.

2026-09-25 — Comprobación previa al despliegue

• Esta app no estaba afectada: fue la única que siguió desplegando, porque no tenía la clave inválida que rompió a las otras dos.
• Se agregó igual revisar-despliegue.py, que comprueba que vercel.json solo use claves que Vercel acepta y que todo archivo local que carga el HTML tenga no-caché o ?v=.

2026-09-25 — Por qué el número no cambiaba: el archivo nunca llegaba (SW v177)

• El arreglo de ayer nunca llegó a los teléfonos. version.js no estaba en la lista de no-caché de vercel.json y además se publicó dos veces con la misma dirección (?v=1): el navegador se quedó con la copia del primer día —la que tenía el error de mostrar la versión en espera— y nunca volvió a pedir el archivo. Por eso el número no cambiaba.
• Dos correcciones, porque hacía falta cada una: se agregó version.js a las reglas de no-caché (la cabecera sola no alcanza, porque no se aplica a una copia que el navegador ya considera fresca) y se cambió la dirección a ?v=3, que es lo que la obliga a pedirla de nuevo.
• Auditoría de TODO lo que carga cada app contra sus reglas de caché. Aparecieron más archivos sin protección, que se agregaron: manifest2.json, index2.html y sw2.js en socios-comicion; manifest.json, version.js, /icons/ e /img/ en propi.solicitada. Resultado ahora: 53 recursos revisados en las cuatro apps, 0 sin protección.
• Se comprobó además que los cuatro Service Workers piden a la red antes que a su propia caché, así que ninguno puede quedarse sirviendo un archivo viejo estando en línea.

2026-09-25 — La versión, sobre el logotipo — y mostrando la correcta (SW v176)

• El número va ahora SOBRE el logotipo, en una chapita justo bajo el dibujo. Primero quedó encima de la esquina y tapaba la «e» de «Interactive»; se bajó para que se lea como parte del logo sin pisarlo.
• Corregido un error de la versión anterior de este dato. Leía las cachés desde la página y se quedaba con la más alta. En socios-comicion y propi.solicitada la versión nueva se instala pero queda en espera hasta que se aprieta «Actualizar», así que conviven dos cachés: el número mostraba la que todavía no estaba corriendo. Justo la sensación de «no se actualizó» al revés.
• Ahora se le pregunta al Service Worker que controla la página —cada uno responde con su propia caché—, que es el único dato que no se puede confundir.
• Tres respaldos, en orden: si el Service Worker es anterior a este cambio y no sabe responder, se usa la caché más vieja presente, que es la que manda en ese caso; si no hay ninguna, el número del código. Nunca se muestra un número más alto que el que está corriendo.
• Verificación: 11 comprobaciones — las cuatro apps muestran su versión, el número queda sobre el logo, el caso de la versión en espera (muestra la que controla, no la que espera), la primera visita sin Service Worker, y el Service Worker viejo que no responde (muestra la vieja, no miente).
• Archivos: version.js, index.html, app.css, sw.js.

2026-09-25 — La versión, junto a la marca (SW v175)

• El número no está escrito a mano: se lee de la caché que el Service Worker tiene activa en este celular. Esa es la diferencia que importa — lo que ves es la versión que de verdad estás usando, no la que dice el código. Si el celular todavía te sirve la anterior, el número te lo dice.
• Va junto a la marca: en la ficha «Acerca de» bajo el logotipo, en la línea de «Carlos P. Nauto Interactive® · 2026» y al pie del login. El módulo pinta todo elemento con la clase app-version, así que sumar el dato en otro lugar es poner un <span class="app-version">.
• Un solo origen para el número. Antes estaba escrito a mano en el HTML y además en el nombre de la caché del Service Worker: dos lugares que podían discrepar. Ahora manda el Service Worker.
• Casos cubiertos: sin Service Worker (primera visita, incógnito) cae al número del código en vez de dejar un hueco; con la caché vieja y la nueva conviviendo muestra la más alta, que es la que va a quedar; y filtra por el prefijo de su propia app. Se repinta solo al activarse el Service Worker, sin recargar.
• Es el mismo módulo que en socios-comicion, Horarios y diario.propi: las cuatro apps muestran su versión igual.
• Archivos: version.js (nuevo), index.html, sw.js.

2026-09-18 — Telegram eliminado por completo (SW v174)

• Se retira la integración con Telegram de las 3 apps. No queda código que envíe ni reciba datos por esa vía.
• Lo más importante estaba acá, en el front. pingConexion y logoutConexion ya escribían en Supabase, pero además reenviaban la llamada al GAS (_origFetch / _origBeacon) solo para que el script mandara el aviso al chat. Eso significaba que cada conexión, cada latido cada 2 minutos y cada cierre de sesión de cada socio salían del navegador hacia un servidor externo. Ese reenvío se eliminó.
• Medido antes y después con el mismo arnés de pruebas: antes, pingConexion + logoutConexion + el sendBeacon de cierre producían 3 salidas a la red; ahora producen 0, y el registro en Supabase se mantiene igual.
• En gas/code.gs se quitó el token, el chat_id, las funciones de envío, el webhook de entrada (doTelegramWebhook y su despacho en doPost), los 8 comandos de consulta y los 9 avisos automáticos.
• No se pierde nada visible. Lo que ve el administrador en su centro de actividad lo escribe logActividad() en la tabla conexiones_log de Supabase, que nunca pasó por Telegram — incluida la desconexión.
• Archivos: supabase-api.js, app.js, gas/code.gs, README.md.

⚠️ Pendiente fuera del repositorio: el token del bot estaba escrito en gas/code.gs y quedó en el historial de git. Hay que revocarlo en @BotFather — borrar el archivo no lo invalida. Ver el detalle en el README de diario.propi.

2026-09-17 — El logotipo de marca, a un tamaño discreto (SW v173)

• El logo ocupaba demasiado espacio y resultaba hostil a la vista. La causa es que cpn-marca.png es casi cuadrado (520×480): el ancho se paga casi entero en alto. En la ficha «Acerca de» medía 250 px de ancho por 231 px de alto — el logo era casi toda la ficha.
• Escala nueva, idéntica en las 3 apps: ficha «Acerca de» 250 → 118 px (≈109 de alto), firma al pie del login 120 → 68 px (≈63 de alto). El pie lleva opacity: .85 para que se lea como firma y no compita con el formulario.
• Se dejan de usar medidas escritas a mano en el HTML. Ahora son clases (.marca-logo-panel, .marca-logo-foot) en app.css, con los mismos valores que las otras dos apps, para que el tamaño no se vuelva a desincronizar.
• Archivos: app.css, index.html. No cambia el archivo del logo ni sus colores — solo el tamaño.

2026-09-16 — Las notas guardan quién las escribió: ID y nombre completo (SW v172)

• Una nota escrita desde acá llegaba a la app de administración con solo el nombre de pila y sin foto. Hay seis pares de socios que comparten nombre —Carlos Perez / Carlos Gomez, Sergio Bachmann / Sergio Duran, Yessica Araya / Yessica Vargas, Patricia Miralles / Patricia Cardenas, Camila Poffald / Camila Oyarzun— así que con «Carlos» no había forma de saber quién la escribió.
• Dos causas, las dos acá:
  • Se enviaba autor: currentUser.Nombre — el nombre de pila. Ahora va el nombre completo.
  • Se enviaba el socId, pero addNote no lo guardaba en notas_recaudacion. Ahora sí (la columna se agregó en la base, nueva y opcional).
• El chat de Administración tampoco podía mostrar la foto: getNotes devolvía socId: null fijo, así que el avatar nunca encontraba al socio. Corregido.
• Con esto, en la app de administración cada nota muestra la foto y el nombre y apellido de quien la escribió, y acá los mensajes del canal de Administración muestran el avatar correcto.
• Archivos: app.js (_nombreCompleto, envío de la nota), supabase-api.js (addNote, getNotes). originalindex.html regenerado. SW boveda-personal-v172, versión visible 172.

2026-09-16 — Quién escribe: foto y nombre en los chats, y la foto en el menú (SW v171)

• En los chats ahora se ve quién escribe. Antes solo el chat Equipo buscaba la foto del socio; en el de Administración los socios salían con una inicial anónima, aunque tuvieran foto. Ahora la foto se busca en los tres chats, por el socId del mensaje.
• Los mensajes propios también se identifican. El socio no aparecía en sus propios mensajes —ni nombre ni foto—, así que en una conversación no quedaba constancia de quién dijo qué. Ahora su mensaje lleva su foto (o inicial) y su nombre, igual que los de los demás.
• Un solo lugar decide el avatar (avatarSocioHTML): foto si el socio la subió, inicial de color si no. Antes cada chat lo resolvía por su cuenta y se veían distintos. Solo 3 de 67 socios tienen foto, así que la inicial sigue siendo el caso normal y se mantiene tal cual.
• La foto también en la barra de menú. El botón Perfil muestra la foto del socio en lugar del ícono. Si no tiene foto, queda el ícono de siempre — no se inventa nada.
• Verificado en navegador con las tres situaciones: socio con foto, socio sin foto (inicial de color) y mensaje propio. Los tres se ven alineados y del mismo tamaño.
• Archivos: app.js (avatarSocioHTML, fotoDeSocio, _aplicarFotoPerfil), app.css (.wa-autor-yo, .nav-foto), index.html (botón Perfil). originalindex.html regenerado. SW boveda-personal-v171, versión visible 171.

2026-09-16 — Las notas de Administración se ven con su formato (SW v170)

• Las notas que manda Administración ahora pueden traer negrita, cursiva, subrayado, alineación y listas. La app escapaba todo el HTML, así que una nota con formato se habría visto con las etiquetas a la vista; ahora la interpreta.
• Una nota centrada se ve centrada. El contenedor de la burbuja no impone su propia alineación: la manda la nota. Con eso, un aviso con el título al centro y partes en negrita llega igual que como se escribió.
• Se sanea antes de mostrar. El texto no se inyecta tal cual: pasa por un filtro que deja solo b, strong, i, em, u, br, p, div, span, ul, ol, li, a y los estilos text-align, font-weight, font-style, text-decoration. Los enlaces solo http/https, y con rel="noopener noreferrer". Todo lo demás se convierte en texto. Probado con <script>, onclick, enlaces javascript:, <iframe>, <img onerror> y estilos no permitidos: ninguno sobrevive.
• Las notas antiguas no cambian. Se detecta si la nota trae formato o es texto plano; las de siempre siguen pasando por linkify como hasta ahora.
• Aplica a los tres lugares donde se leen notas: el panel de avisos, el chat de administración y los mensajes privados.
• Archivos: app.js (notaTraeFormato, sanearNota, notaHTML), app.css (.nota-cuerpo). originalindex.html regenerado. SW boveda-personal-v170, versión visible 170.

2026-09-15 — Logotipo original recortado y recoloreado (SW v169)

• Se revierte el redibujo. El pedido era cambiar el color, no el dibujo. Vuelve el arte original, con su forma exacta, y lo único que cambia es el color.
• Cómo se recortó el fondo. El archivo de origen es una foto de una maqueta (el escudo sobre metal cepillado con degradado). Lo que funcionó fue un top-hat: se estima el fondo como el mínimo local en una ventana más ancha que el trazo más grueso del logo y se conserva lo que sobresale. Tres ajustes hicieron falta: usar croma absoluto en vez de saturación relativa (si no, queda un halo gris), bajar el umbral de luminancia porque el texto plateado no es tan claro como parece (p90 = 116) y quedaba semitransparente, y descartar los reflejos pegados al borde exigiendo que todo píxel esté cerca de uno opaco.
• El color: mismos tonos del original pero más saturados y menos claros, porque el neón se lava sobre fondo blanco. En los temas oscuros se avivan con filter: brightness(1.45) saturate(1.05).
• Archivos: img/marca/cpn-marca.png (520×480, 219 KB, fondo transparente). Se borran los SVG del intento anterior.
• Mediana 3×3 sobre el alfa: el texto plateado sale del JPEG con motas sueltas en el borde y se veía sucio al lado de «Nauto», que es de color. Se probó además un cierre morfológico para rellenar la «C» y se descartó: engorda las letras y cierra el ojo de la «a».
• Verificado a 240/190/120 px sobre blanco, gris claro y azul oscuro, y en las pantallas reales en tema claro y oscuro.
• originalindex.html regenerado con build.sh. SW boveda-personal-v169, versión visible 169.
• Archivos: index.html, app.css, sw.js, img/marca/, originalindex.html.

2026-09-14 — Marca nueva: Carlos P. Nauto Interactive (SW v165)

• Se reemplaza el logotipo (img/carlospn-logo.png) por el nuevo y «CarlosPN Interactive» pasa a «Carlos P. Nauto Interactive» en sus 5 menciones: el modal Acerca de, el pie del login, la línea de derechos reservados, el crédito de la barra inferior y el pie de los comprobantes que se imprimen (app.js).
• El archivo mantiene el mismo nombre, así que las referencias siguen sirviendo; cache-bust a ?v=2026.
• El logotipo nuevo es transparente (el anterior tenía fondo blanco). La clase .marca-logo —mix-blend-mode: multiply en claro, invert(1) hue-rotate(180deg) + screen en oscuro— funciona igual con un PNG transparente: no hubo que tocar app.css.
• Verificado en navegador en tema claro y oscuro.
• originalindex.html regenerado con build.sh. SW boveda-personal-v165, versión visible 165.
• Archivos: index.html, app.js, sw.js, img/carlospn-logo.png, originalindex.html.

2026-09-08 — El aviso nombra el día que falta (SW v164)

• Cuando falta un solo día, el título ahora lo dice con nombre y fecha: «Falta agregar la recaudación del Lunes, 7 de septiembre». Antes decía solo «Falta la recaudación de 1 día» y había que mirar el chip para saber cuál era.
• Con varios días sigue mostrando el conteo — «Faltan agregar 3 días de recaudación» — y el detalle en los chips.
• El texto de apoyo se ajusta al singular: «Ese día no tiene ninguna recaudación ingresada».
• El aviso no habla de montos: solo dice qué día falta por ingresar.
• Archivos: app.js (_notaFaltantesHTML). SW v164 (visible v164).

2026-09-08 — El aviso de recaudación se pinta antes que todo lo demás (SW v163)

• El síntoma: el balance, los accesos rápidos y el resumen contable se veían bien, pero el aviso de días sin recaudación no aparecía — justo el hueco entre la tarjeta de balance y "Accesos Rápidos".
• Por qué: el aviso se calculaba en medio de refresh(), después de pintar el balance y la lista de movimientos. Todo lo que va antes se ve; si algo falla en ese tramo, la función se corta ahí y el aviso nunca se pinta, sin ningún error visible en pantalla. Encaja exactamente con lo que se veía.
• Fix 1 — se pinta primero. Se extrajo a _pintarFaltantesHome() y se llama apenas llegan los datos, antes del balance y de los movimientos. Va dentro de un try/catch, así que ni siquiera un error propio lo impide.
• Fix 2 — el render de movimientos ya no puede tumbar el resto. Ese tramo quedó protegido: si una fila viene con datos raros, se registra en consola y refresh() sigue con el historial y el resto de la pantalla, en vez de cortarse a la mitad.
• No se tocó el cálculo: sigue la ventana de 45 días hacia atrás, sin avisar cuando aún no hay datos.
• Archivos: app.js (_pintarFaltantesHome, refresh). SW v163 (visible v163).

2026-09-08 — Se revierte el recorte al período en el aviso de recaudación (SW v162)

• La v161 limitó el aviso al período actual, y eso rompía el caso real: estando en septiembre faltaba el jueves 30-07, un día de un período ya cerrado, y con ese recorte habría dejado de avisarse.
• Un día sin recaudación hay que saberlo aunque el período esté cerrado, porque igual se puede ingresar. Vuelve la ventana de 45 días hacia atrás desde ayer.
• Se conservan las mejoras de la v161: el título dice «Falta la recaudación de N días», no avisa mientras no haya datos cargados, y nunca revisa antes del primer día que trajo la consulta.
• Verificado reproduciendo el caso de la captura (falta el 30/07 estando en septiembre → sí lo muestra) más cinco escenarios más.
• Archivos: app.js (_calcularDiasFaltantes). SW v162 (visible v162).

2026-09-08 — El aviso de recaudación faltante dice qué falta (SW v161)

• El título pasó de «Ingreso faltante» a «Falta la recaudación de 1 día» (o de N días), que dice de una lo que pasa. El texto explica que son días del período sin ningún monto ingresado.
• Ventana acotada al período actual (del 15 en adelante) en vez de 45 días hacia atrás, que podía cruzar el corte de mes y mostrar días de un período ya cerrado.
• Nunca revisa antes del primer día cargado, para no marcar como faltantes días que sí tienen recaudación pero no vinieron en la consulta; y no avisa si aún no hay datos, para que al abrir la app no aparezca el período entero como faltante.
• Los días siguen siendo tocables para ingresar el monto de ese día.
• Verificado sobre siete escenarios (sin datos, falta ayer, falta un día del medio, dos días, todo al día, lista que arranca a mitad de período e historial largo).
• Archivos: app.js (_calcularDiasFaltantes, _notaFaltantesHTML). SW v161 (visible v161).

2026-09-05 — El retiro de caja de una colecta no toca el balance del socio (SW v160)

• Acompaña a socios-comicion v91, que agregó el egreso de la colecta: el registro de que el dinero juntado salió de la caja cuando se le entrega al beneficiado. Ese registro viaja como un extra de tipo DONACION_ENTREGA.
• Fix preventivo: _esDonacion() aceptaba cualquier tipo que contuviera donacion, así que habría tomado también el nuevo DONACION_ENTREGA y descontado del balance el monto completo del retiro. Ahora exige que contenga donacion y no extern ni entrega, igual que en socios-comicion.
• El registro se guarda con un socio_id ficticio, así que ningún socio lo lee; el ajuste es la segunda barrera para que nunca llegue al balance de nadie.
• Archivos: app.js (_esDonacion). SW v160 (visible v160).

2026-09-05 — Los aportes de personas ajenas al fondo no descuentan a nadie (SW v159)

• Acompaña a socios-comicion v81, que ahora permite sumar a una colecta a personas que no son socios (con nombre, procedencia y monto). Esos aportes suman al total juntado pero no tienen saldo del cual descontar.
• Fix preventivo: _esDonacion() detectaba cualquier tipo que contuviera donacion, así que habría tomado también el tipo nuevo DONACION_EXTERNA y descontado un aporte que no le corresponde a ningún socio. Ahora exige que el tipo contenga donacion y no extern, igual que en socios-comicion.
• Los aportes externos se guardan con un socio_id ficticio, así que ningún socio los lee; el ajuste es una segunda barrera para que un error de tipeo en el tipo no llegue nunca al balance de nadie.
• Archivos: app.js (_esDonacion). SW v159 (visible v159).

2026-08-02 — El motivo de la donación se lee completo (SW v158)

• La fila de movimientos usaba truncate / text-overflow: ellipsis, así que un motivo largo se cortaba con puntos suspensivos y el socio no alcanzaba a leer a qué correspondía el descuento. Ahora, solo en las filas de donación, el texto hace salto de línea y se muestra completo.
• La fila se alinea arriba (align-items: flex-start) cuando el motivo ocupa varias líneas, para que el icono y el monto no queden flotando al medio.
• Se aplicó en las dos vistas: la clásica y la premium (dashboard oscuro).
• Las filas de anticipo mantienen el recorte de una línea como estaban — el cambio no las toca.
• Archivos: app.js (render de movimientos). SW v158 (visible v158).

2026-08-02 — Donaciones: el aporte a una colecta se descuenta del balance (SW v157)

Acompaña a la sección 💝 Donaciones de socios-comicion (v70): cuando un socio necesita ayuda, la administración abre una colecta y registra cuánto aporta cada socio.

• El aporte se descuenta del balance a recibir, con el mismo criterio que socios-comicion: saldoBruto = (propina + saldo anterior) − (anticipos + descuentos + donaciones).
• Aparece en "Últimos movimientos" con icono propio (🤝 rosado en vez de la flecha roja) y el motivo de la colecta como descripción — ej. "💝 Ayuda a Juan Pérez por licencia médica" —, para que el socio sepa de inmediato a qué corresponde el descuento.
• No cuenta como pedido. El contador "Llevas N pedidos · te restan X · máximo 8" sigue contando solo anticipos: aportar a una colecta no le consume un anticipo al socio.
• Detección por contenido y sin tildes (_esDonacion), igual que en socios-comicion, para que ninguna variante del tipo (DONACION, Donación, donacion) quede fuera en una app y dentro en la otra.
• Verificado con una simulación de los dos cálculos sobre 7 escenarios y 10 variantes del tipo: dan el mismo saldo en ambas apps.
• Archivos: app.js (_esDonacion, _motivoDonacion, saldoBruto, lista de movimientos). SW v157 (visible v157).

2026-08-02 — Mis Documentos: cualquier tipo de archivo, con su icono (SW v156)

Acompaña al cambio de socios-comicion (v69), que ahora permite enviar Word, Excel y cualquier archivo al socio. Sin esto, un Excel enviado por la administración aparecía en la app del socio con icono de imagen y sin indicar de qué se trataba.

• Icono y tipo por archivo: 📄 PDF · 📝 Word · 📊 Excel · 📽️ PowerPoint · 🗜️ Comprimido · 🖼️ Imagen · 🎬 Video · 🎵 Audio · 📃 Texto · 📎 otros. La fila muestra tipo · tamaño, con el tamaño en MB cuando corresponde (antes siempre KB).
• Botón según el archivo: Ver para lo que el navegador muestra y Abrir para Word/Excel/PowerPoint, que se descargan para abrirse con su programa.
• El socio también puede adjuntar cualquier archivo (antes solo PDF o imagen), para que las dos puntas queden parejas.
• MIME deducido de la extensión (DOC_MIME_POR_EXT, _docMime): los navegadores dejan file.type vacío en los formatos de Office con macros (.xlsm, .docm, .pptm) y el archivo se subía como binario genérico.
• Límite por archivo: 15 MB (sin cambios).
• Archivos: index.html (selector y texto), app.js (DOC_MIME_POR_EXT, _docMime, _docTipo, _docTamano, renderDocumentos, subirDocumento). SW v156 (visible v156).

2026-08-02 — Las ausencias se descuentan igual que en socios-comicion (SW v155)

Al revisar el borrado de ausencias en socios-comicion se compararon los dos cálculos y aparecieron dos diferencias que hacían que el mismo socio, con los mismos datos, viera un saldo distinto en cada app. Se unificó el criterio con el de socios-comicion (js/anticipos.js).

• Ausencias repetidas el mismo día: propi descontaba el valor punto una vez por registro, así que dos ausencias cargadas para la misma fecha restaban doble y el saldo quedaba más bajo. socios-comicion usa un Set de fechas y descuenta una sola vez. Ahora propi también.
• Variantes del tipo: propi exigía que el tipo fuera exactamente AUSENCIA; socios-comicion acepta cualquier tipo que contenga "ausencia" (sin distinguir mayúsculas). Un registro como Ausencia Justificada descontaba en la administración pero no en la app del socio, que mostraba un saldo más alto. Ahora las dos usan la misma regla.
• Se agregó el helper _ausenciasFechas(extras) y lo usan tanto el cálculo del saldo como el historial y el calendario, para que no vuelvan a separarse.
• Verificado con una simulación de los dos cálculos sobre 7 escenarios (sin ausencias, una, duplicada, tipo con variante, fecha con hora, día sin valor punto, y ausencia borrada): coinciden en todos.
• Archivos: app.js (_ausenciasFechas, cálculo de puntoGlobalTotal, ausenciasSet). SW v155 (visible v155).

2026-08-02 — Solicitar Egreso: campos obligatorios y desglose cuadrado (SW v154)

• Monto solicitado y Encargado pasan a ser obligatorios — ambos marcados en rojo con (obligatorio). Antes el encargado decía (opcional).
• Desglose del dinero: sigue siendo opcional. Se puede enviar la solicitud sin anotar ni un billete.
• Pero si se completa, tiene que cuadrar: si el desglose suma distinto al monto solicitado, la solicitud no se envía. El aviso ámbar dentro de la tarjeta indica cuánto falta o sobra y agrega "Corrígelo o deja el desglose en blanco para poder enviar".
• Al faltar un dato, el botón lo nombra (Falta el monto solicitado / Falta indicar el encargado / El desglose no cuadra con el monto) y la pantalla se desplaza al campo con el problema y lo enfoca.
• Casillas en cero cuentan como "sin desglose", así que no bloquean el envío.
• Archivos: index.html (etiquetas), app.js (enviarEgreso, aviso de _egrTotalBilletes). SW v154 (visible v154).

2026-08-02 — Fix: en "Encargado" aparecía uno solo en vez de los tres (SW v153)

• Causa: rpc_responsables_lista() leía únicamente la tabla responsable_creds, que contiene solo a los responsables con PIN personal configurado. La lista real y completa la administra socios-comicion y vive en config_sistema bajo la clave responsables (JSON [{ini, area}]), con los tres: N.M (S.J), P.M (S.J), C.P (S.J).
• Fix (cliente): _cargarEncargados() ahora consulta las dos fuentes en paralelo y las fusiona eliminando duplicados por ini|area, ordenadas alfabéticamente. Si una de las dos falla, se usa la otra; nunca se pide el PIN.
• Fix (servidor, pendiente de aplicar): se dejó sql/rpc_responsables_lista.sql en el repo de socios-comicion con la RPC corregida — hace la misma fusión dentro de la base y es SECURITY DEFINER, para que la app no necesite leer config_sistema cuando la Fase 1b cierre el SELECT anónimo sobre esa tabla.
• Archivos: app.js (_cargarEncargados). SW v153 (visible v153).

2026-08-02 — Solicitar Egreso: el desglose del dinero queda ordenado y legible (SW v152)

• El bloque "Detalle del dinero recibido" se rediseñó como tabla de tres columnas: Valor · Cant. · Subtotal, con encabezado fijo, para que cada número quede debajo de su título.
• Se separó en dos grupos: 💵 Billetes ($20.000 a $1.000) y 🪙 Monedas ($500 a $10). Antes eran 9 casillas en dos columnas, con la etiqueta lejos de su casilla y una fila suelta al final.
• Subtotal por fila: al escribir una cantidad, la fila muestra a la derecha cuánto suma ese valor (3 en $20.000 → $60.000). Las filas en cero quedan con un guion atenuado.
• Total dentro de la misma tarjeta (antes flotaba suelto a la derecha), en verde si coincide con el monto solicitado y en ámbar si no, con una línea que dice cuánto falta o cuánto sobra.
• Contraste: se ajustaron los colores a los tokens que los temas oscuros ya reconvierten y los separadores pasaron a rgba, así el bloque se lee bien en los 12 temas.
• Archivos: index.html (contenedor), app.js (EGR_GRUPOS, _egrRenderBilletes, _egrTotalBilletes). SW v152 (visible v152).

2026-08-02 — Solicitar Egreso: detalle del dinero recibido, billete por billete (SW v151)

• Se agregó al modal Solicitar Egreso un bloque "Detalle del dinero recibido" (opcional): una grilla con las denominaciones ($20.000, $10.000, $5.000, $2.000, $1.000, $500, $100, $50, $10) donde el socio anota cuántos billetes o monedas de cada valor le entregaron.
• Total en vivo: debajo de la grilla se muestra Total desglose: $X. Si el total coincide con el monto solicitado se marca en verde (coincide ✓); si no coincide, en ámbar (no coincide con el monto). Es solo un aviso, no bloquea el envío.
• Guardado resiliente: se intenta guardar en la columna billetes (jsonb) de solicitudes_egreso; si esa columna aún no existe en la base, el desglose se anexa a la nota (Desglose: 3×$20.000, 1×$10.000) junto con el encargado, para no perder el dato.
• socios-comicion muestra el desglose en la tarjeta de egresos pendientes (💵 3×$20.000 · 1×$10.000 = $70.000), con aviso si la suma no cuadra con lo solicitado.
• Archivos: index.html (bloque de billetes), app.js (EGR_DENOMS, _egrRenderBilletes, _egrTotalBilletes, _egrLeerBilletes), supabase-api.js (guardado). SW v151 (visible v151).

2026-08-02 — Solicitar Egreso: monto, detalle y encargado (SW v150)

• El modal ahora tiene los tres datos en orden: Monto solicitado → Detalle (opcional) → Encargado que te entregó el egreso (opcional).
• El encargado se elige de una lista desplegable que se obtiene del servidor mediante rpc_responsables_lista() — la RPC que no expone los PIN —, con opción "Otro / no aparece en la lista" que habilita un campo libre. La lista queda en caché para que el modal abra al instante.
• Guardado resiliente: se intenta guardar en la columna encargado de solicitudes_egreso; si esa columna aún no existe en la base, el dato se anexa a la nota (Encargado: X) para no perderlo.
• socios-comicion muestra el dato en la tarjeta de egresos pendientes (👤 Entregado por).
• Archivos: index.html (campos), app.js (_cargarEncargados, envío), supabase-api.js (guardado). SW v150 (visible v150).

2026-08-02 — Con la huella activa, el PIN queda oculto (SW v149)

• Antes: se mostraban las dos opciones a la vez (PIN y huella), lo que sobraba si el socio ya activó la huella.
• Ahora: si la huella está activa, el login muestra solo "Ingresar con huella"; el campo de PIN y su botón quedan ocultos.
• Respaldo automático: si la huella falla o se cancela, aparece el PIN al instante con el aviso "Huella no reconocida — ingresa con tu PIN". También hay un enlace discreto "Usar PIN en vez de la huella" por si lo prefiere.
• Si la huella no está activa (o el dispositivo no la soporta), todo sigue igual que antes: solo el PIN.
• Archivos: index.html (#bloquePIN, #btnIngresarPIN, #btnUsarPIN), app.js (_bioRefrescarUI, mostrarIngresoPIN). SW v149 (visible v149).

2026-08-02 — Acceso por huella / rostro (WebAuthn) (SW v148)

• Qué se hizo: el socio puede entrar con la huella o el rostro de su teléfono, sin escribir el PIN. Se activa en Ajustes → "Activar acceso por huella" (solo aparece si el dispositivo lo permite) y luego el login muestra el botón "Ingresar con huella".
• Cómo: API estándar WebAuthn (navigator.credentials) con autenticador de plataforma y userVerification: 'required'. La biometría la valida el propio teléfono; la app solo guarda el identificador de la credencial (no la huella).
• Sin guardar el PIN: el ingreso post-verificación se extrajo a _completarIngreso(auth), usado tanto por el PIN como por la huella. No se almacena el PIN en ninguna parte para habilitar esto.
• Requisitos y resguardos: requiere HTTPS y biometría configurada en el equipo; si falta, la opción no se muestra. El PIN sigue funcionando siempre como alternativa. Se puede desactivar desde Ajustes. La credencial es por dispositivo (cada teléfono se activa por separado).
• Archivos: index.html (botón en login + fila en Ajustes), app.js (módulo WebAuthn, _completarIngreso, _bioRefrescarUI). SW v148 (visible v148).

2026-08-02 — Fix: el re-ingreso no quedaba registrado + evento de cierre de sesión (SW v147)

• Causa: el anti-duplicado de 1 minuto vivía en memoria y la app no recarga al cerrar sesión, así que si el socio volvía a entrar enseguida, su nueva conexión se omitía y no aparecía en socios-comicion.
• Fix: al cerrar sesión se limpia el anti-duplicado (logActividadReset) y la ventana bajó a 15s. Además ahora se registra el evento 'desconectado' (cierre de sesión) y se libera la presencia.
• Archivos: supabase-api.js, app.js. SW v147 (visible v147).

2026-08-02 — Registro de actividad para socios-comicion (SW v146)

• La app ahora deja constancia (con fecha y hora) de dos momentos, para que la administración los vea en socios-comicion: (1) cuando el socio se conecta a la app, y (2) cuando entra a "Recaudación del Día".
• Se escribe en la tabla conexiones_log mediante logActividad(evento, nombre, socioId, detalle), con anti-duplicado de 1 minuto por evento para no llenar el registro.
• Archivos: supabase-api.js (logActividad), app.js (login + apertura del modal). SW v146 (visible v146).

2026-08-02 — Fix: el mismo socio aparecía DOS veces en la lista de presencia (SW v145)

• Causa: la misma persona llega por dos vías (el canal en vivo, con clave aleatoria de sesión, y la tabla rec_presencia, con clave app:socio). Como las claves eran distintas, el filtro de duplicados no la reconocía y la mostraba dos veces.
• Fix: se deduplica por una identidad estable (app + socio_id, o el nombre si no hay id). El aviso de "quién recién entró" usa la misma identidad.
• Archivos: supabase-api.js. SW v145 (visible v145).

2026-08-02 — Fix: el filtro de "no verse a sí mismo" ocultaba al socio de la otra app (SW v144)

• Causa: en la operación real el mismo socio_id puede estar en las dos apps (misma cuenta en propi y en diario). El filtro ocultaba cualquier presencia con mi mismo ID, así que borraba justo la línea de "(Diario)" que se quería ver.
• Fix: ahora se oculta solo mi propia línea de ESTA app (mi sesión). Si el mismo socio está en otra app, sí se muestra. Se restaura la lista dentro del modal tal como estaba.
• Archivos: supabase-api.js. SW v144 (visible v144).

2026-08-02 — Fix: el socio se veía a sí mismo en el modal (SW v143)

• Síntoma: en el modal aparecía el propio socio ("CarlosJPerezN … (Bóveda Personal)") junto al socio real de diario.
• Causa: cada carga de la app creaba una fila NUEVA de presencia (id aleatorio). La fila de una sesión anterior del mismo teléfono seguía viva y, al no tener el socio_id (versión previa), el filtro no la reconocía como propia.
• Fix: el id de la fila ahora es fijo por socio + app (app:socio_id), así al recargar se sobreescribe la misma fila y nunca quedan duplicados. Además, red de seguridad para filas antiguas: mismo nombre en la misma app = soy yo. Se limpiaron las filas viejas de la tabla.
• Archivos: supabase-api.js. SW v143 (visible v143).

2026-08-01 — Presencia: no verse a sí mismo + aviso arriba y temporal (SW v142)

• No verse a sí mismo: la presencia ahora viaja con el socio_id. Si el mismo socio tiene propi.solicitada y diario.propi abiertas a la vez, no se muestra a sí mismo (antes aparecía como si fuera otra persona). Columna nueva socio_id en rec_presencia.
• Aviso flotante arriba y temporal: el banner pasó de abajo a arriba, y ahora solo avisa cuando alguien recién entra, desapareciendo solo a los 6s (antes quedaba fijo abajo).
• La lista permanente sigue dentro del modal, debajo de "Ingresar Recaudación" (sin cambios: quedó como estaba).
• Archivos: supabase-api.js, app.js. SW v142 (visible v142).

2026-08-01 — Fix REAL de presencia: se perdía al salir de pantalla / cambiar de panel (SW v141)

• Diagnóstico: el modal de propi.solicitada sí funcionaba (verificado: mostró una presencia de prueba insertada en la tabla). El fallo estaba en el emisor: diario.propi dejaba de anunciarse.
• Causa 1: diario solo marcaba presencia estando en el panel "Agregar"; al mirar Historial/Notas desaparecía, aunque el socio siguiera trabajando en recaudaciones. Fix: estar dentro de diario.propi ya cuenta como estar en recaudaciones (el tipo se muestra solo si está en "Agregar").
• Causa 2: el evento pagehide borraba la fila de presencia al apagar la pantalla o cambiar de app — la dinámica normal de la operación. Fix: ya no se borra en segundo plano; al volver al frente se re-marca y re-lee al instante. Ventana de vigencia ampliada de 45s a 3 minutos.
• socios-comicion además se anuncia al entrar a su pestaña Recaudación.
• Archivos: supabase-api.js. SW v141 (visible v141 en la barra inferior y en "Acerca de").

2026-08-01 — Versión visible en la barra inferior (SW v140)

• El crédito de la barra inferior ahora incluye la versión de la app: "CarlosPN Interactive® · 2026 · v140" (= versión del SW). "Acerca de" sincronizado (140). Permite verificar de un vistazo si el dispositivo tomó la última versión.
• Se verificó en la tabla rec_presencia que ambos dispositivos ya transmiten presencia con la versión nueva (filas de "Diario" y "Bóveda Personal").

2026-08-01 — Presencia GARANTIZADA: respaldo por base de datos (tabla rec_presencia) (SW v139)

• Por qué: la presencia por canal realtime seguía sin verse en algunos escenarios (dispositivos con versión desigual, websocket caído). Se elimina esa dependencia.
• Cómo: además del canal en vivo, cada app escribe su presencia en la tabla rec_presencia (proyecto REC) al entrar al módulo de recaudación, con latido cada 20s, y todas las apps la leen cada 5s y pintan la unión (canal + tabla, dedupe por key). Al salir se borra la fila; pagehide intenta borrarla; filas >45s se ignoran y >1h se limpian oportunistamente. Verificado con inserción/lectura real como rol anon.
• Resultado: el nombre del socio aparece siempre (peor caso ~5s de retraso), en el modal de propi y en los banners de las 3 apps.
• Archivos: supabase-api.js. Tabla nueva rec_presencia (REC). SW v139 (visible 139).

2026-08-01 — Presencia: pintado inmediato en el modal + refuerzos (SW v138)

• El modal "Ingresar Recaudación" ahora pinta al instante (al abrirse) quién está en recaudaciones en las otras apps, con encabezado "👥 Ahora mismo en recaudaciones:" — antes esperaba el próximo evento de presencia.
• Refuerzos anti-pérdida: listeners join/leave además de sync, repintado de respaldo cada 4s, y render al confirmar la suscripción. window.recPresRender expuesto.
• Archivos: supabase-api.js, app.js. SW v138 (visible 138).

2026-08-01 — Fix: la presencia en recaudación no aparecía (track antes de suscribir) (SW v137)

• Síntoma: en propi.solicitada no aparecía nadie aunque un socio estuviera ingresando en diario.propi (y viceversa).
• Causa: la marca de presencia (ch.track) se enviaba antes de que el canal rec-presencia terminara de suscribirse; en ese estado el track se pierde en silencio. En diario era sistemático: su panel "Agregar" es el inicial, así que el track salía justo al entrar (canal aún conectándose) y nunca llegaba.
• Fix (en las 3 apps): subscribe(status) con callback — la presencia pendiente se (re)marca cuando el canal confirma SUBSCRIBED y también en cada reconexión (al volver del segundo plano). recPresEntrar/Tipo/Salir solo trackean con el canal listo; si no, queda pendiente y se envía al suscribir.
• Archivos: supabase-api.js. SW v137 (versión visible 137).

2026-08-01 — Fix: el número de versión visible ("Acerca de") estaba congelado en 19 (SW v136)

• Causa: el modal "Acerca de" mostraba "Versión 19" fijo; se venía bumpeando solo el CACHE_NAME del SW y ese número visible quedó desincronizado (parecía que "no se actualizaba la versión").
• Fix: se puso la versión visible en sincronía con el SW → ahora muestra "Versión 136 · 2026" (= boveda-personal-v136). De aquí en adelante, ambos se suben juntos en cada release.
• Archivos: index.html (versión en "Acerca de"), sw.js. SW v136.

2026-08-01 — Vuelve el banner "Actualizar" (reescrito para no quedar pegado) (SW v135)

• Qué se hizo: vuelve el banner "Nueva versión disponible" con botón Actualizar, pero reescrito para que nunca se quede pegado.
• Cómo no se pega: (1) solo aparece cuando hay un SW nuevo en espera (reg.waiting/updatefound→installed); (2) sin cuenta regresiva automática (eso era lo que dejaba el "actualizando" colgado); (3) al tocar Actualizar, aplica y recarga UNA sola vez garantizada (por controllerchange o respaldo de 1.5s), con guardia _swReloaded. Tras recargar ya no hay worker en espera → el banner no reaparece.
• El SW vuelve a no hacer skipWaiting() en install (queda en espera para poder ofrecer el banner); solo activa al recibir SKIP_WAITING del botón.
• Nota de transición: al venir de la versión silenciosa, puede requerir un cierre/apertura para quedar en la versión con banner.
• Archivos: index.html (banner + registro SW), sw.js (install sin skipWaiting). SW v135.

2026-08-01 — Presencia: nombres dentro del modal + etiqueta "Bóveda Personal" (SW v134)

• Dentro del modal: el modal "Ingresar Recaudación" ahora muestra un aviso verde con quién más está en recaudaciones (nombre + tipo + app), tanto de propi.solicitada como de diario.propi, actualizado en vivo (#recPresenciaModal).
• Etiqueta: la app se identifica como "Bóveda Personal" en lugar de "Propi" en los avisos de presencia (las otras apps ya la muestran así).
• Archivos: supabase-api.js (APP = 'Bóveda Personal'; el banner también pinta dentro del modal), index.html (contenedor #recPresenciaModal). SW v134.

2026-08-01 — Presencia en recaudación en tiempo real entre apps (SW v133)

• Qué se hizo: cuando un socio abre el modal "Recaudación del Día", las otras apps (propi.solicitada, diario.propi y socios-comicion) muestran un aviso en tiempo real: 🟢 [Nombre] está en recaudaciones · [tipo] (app). Y cuando alguien agrega un dato, aparece un toast 📊 [Nombre] agregó a recaudaciones ([tipo]).
• Cómo: módulo de Supabase Realtime Presence en un canal compartido rec-presencia (proyecto REC). recPresEntrar/Tipo/Salir (track presencia al abrir/cambiar tipo/cerrar el modal) y recPresAgrego (broadcast al guardar). Banner y toast autocontenidos. Wire: abrirModalRec/selRecTipo/cerrarModalRec/enviarRec + recPresIniciar en initApp.
• Archivos: supabase-api.js (módulo de presencia), app.js (wire). SW v133.

2026-07-26 — Tema: red de seguridad para que la selección persista siempre (SW v132)

• Refuerzo del fix v131: además de corregir el init del <head>, ahora app.js re-aplica el tema guardado al cargar usando aplicarTema(_temaActual()) (fuente única y autoritativa). Así el tema persiste aunque el init rápido del <head> fuera de una versión previa. Se verificó que nada borra propi_tema y que el indicador de botón activo existe.
• Archivos: app.js. SW v132.

2026-07-26 — Fix: no se guardaban los temas nuevos (grafito/vino/índigo) (SW v131)

• Causa: el script de init temprano del <head> (que aplica el tema antes de renderizar para evitar parpadeo) tenía una lista de temas válidos desactualizada — no incluía grafito/vino/índigo. Al recargar, esos temas eran rechazados y volvía a "claro" → parecía que no se guardaba la selección.
• Fix: se actualizó ese init para que coincida con app.js (mismos _TEMAS/_TEMA_TINTE/_TEMA_COLOR): valida los 12 temas, aplica data-tinte para esmeralda/grafito/vino/índigo y data-negro para negro, y usa el color de barra correcto.
• Archivos: index.html (init de tema en <head>). SW v131.

2026-07-26 — Fix: banner de actualización que no desaparecía → actualización silenciosa (SW v130)

• Síntoma: el banner "Nueva versión disponible" no desaparecía tras tocar "Actualizar" ni al terminar la cuenta regresiva (mismo patrón que se había quitado en diario.propi: ciclo controllerchange→reload + worker en "waiting" que reaparece).
• Fix: se elimina el banner y toda su lógica (countdown, botón, recarga forzada). Ahora la actualización es silenciosa: el SW nuevo hace skipWaiting() en install y toma el control solo (clients.claim); la versión nueva se aplica al reabrir la app. Sin banner, nada que se quede pegado.
• Archivos: index.html (registro SW minimal, se quita banner HTML+JS), sw.js (skipWaiting() en install). SW v130.

2026-07-26 — Fix: aviso "Ingreso faltante" no resaltaba en temas pastel (rosa, etc.) (SW v129)

• Causa: en temas claros pastel (rosa #fff1f6, menta, durazno…) el aviso usaba un crema muy pálido (#fffbeb) casi idéntico al fondo → la tarjeta no se distinguía.
• Fix: la variante clara ahora usa un ámbar más marcado (fondo #fef3c7, borde #f59e0b, texto #7c2d12) + sombra suave, para que resalte sobre cualquier fondo claro. La variante oscura se mantiene.
• Archivos: app.js (_notaFaltantesHTML). SW v129.

2026-07-26 — Aviso "Ingreso faltante": recordatorio de fin de turno (SW v128)

• Se agregó al final de la tarjeta un recordatorio: "Cuando termine el turno, consulta los montos e ingrésalos." (con ícono de reloj, color adaptado al tema).
• Archivos: app.js (_notaFaltantesHTML). SW v128.

2026-07-26 — Fix: aviso "Ingreso faltante" ilegible en tema claro (SW v127)

• Causa: se había fijado el aviso del home a la variante oscura siempre (creyendo que el home premium era oscuro fijo), pero el home premium sí sigue el tema (fondo claro en temas claros). Así el texto dorado claro quedaba ilegible sobre fondo claro.
• Fix: el aviso (home y historial premium) ahora usa _temaEsOscuro(): claro sobre fondo claro (texto café oscuro) y oscuro sobre fondo oscuro (texto dorado). Legible en ambos.
• Archivos: app.js. SW v127.

2026-07-26 — Estadísticas: gráfico legible en temas oscuros + detalle más claro (SW v126)

• Gráfico: usaba colores fijos (línea #001723 casi negra, grilla #e7e8e9 clara) que en temas oscuros eran invisibles. Ahora el renderStatsChart toma los colores del tema (variables CSS --lm-primary/accent/border/muted), así se ve bien en claro y en todos los oscuros. También la leyenda de "Proyección" usa el acento del tema.
• Detalle del período: se agregó una leyenda explicativa arriba de la tabla — Real = ganancia ya registrada, Proyectado = estimación de los días que faltan (promedio), Sin recaudación = ese día no hubo ingreso.
• Archivos: app.js (colores del gráfico por variables de tema), index.html (leyenda del detalle + swatch de proyección theme-aware). SW v126.

2026-07-26 — 3 temas oscuros nuevos + preview de sonido robusto (SW v125)

• Temas oscuros nuevos: Grafito (gris carbón neutro), Vino (borgoña cálido) e Índigo (violeta profundo). Se suman a Oscuro/Negro/Esmeralda. Reutilizan la base data-theme="oscuro" + un data-tinte, y definen sus variables --lm-*/--pm-* para que el dashboard premium también se re-tinte. Heredan --pm-text claro del tema oscuro → buen contraste (texto claro sobre fondo oscuro).
• Contraste: se refuerza que el nombre en los botones de tema quede claro en temas oscuros.
• Preview de sonido: al tocar un sonido en Ajustes ahora suena de forma fiable — se hace resume() del AudioContext (que en móvil arranca "suspended") antes de reproducir, así se escucha la muestra al seleccionar.
• Archivos: app.js (temas + _temaEsOscuro + reproducirSonidoNotif con resume), app.css (tintes grafito/vino/indigo + regla de contraste), index.html (3 botones de tema). SW v125.

2026-07-26 — Aviso "Ingreso faltante": tocar el día para ingresar el dato (SW v124)

• Qué se hizo: en el aviso, cada día faltante ahora es un botón tocable: al tocarlo abre el modal de "Ingresar Recaudación" con esa fecha ya puesta, invitando a completar el dato si se conoce ("Si conoces el dato, toca el día para ingresarlo").
• Cómo: abrirModalRec(fecha) acepta una fecha opcional (valida YYYY-MM-DD, si no, usa hoy); los chips del aviso llaman abrirModalRec('YYYY-MM-DD').
• Archivos: app.js (abrirModalRec con fecha, chips tocables en _notaFaltantesHTML). SW v124.

2026-07-26 — Aviso "Ingreso faltante" pasa debajo de la tarjeta de balance (SW v123)

• Por qué: lo principal para el socio es el saldo; el aviso arriba de todo tapaba esa jerarquía.
• Qué se hizo: el aviso se movió al homePremium justo debajo de la tarjeta de balance (antes de "Accesos Rápidos"). Como ese layout tiene fondo oscuro fijo, el aviso del home usa siempre la variante oscura. El historial clásico sigue adaptándose al tema.
• Archivos: index.html (contenedor movido dentro de homePremium), app.js (aviso home oscuro fijo). SW v123.

2026-07-26 — Fix color del aviso "Ingreso faltante" en temas oscuros (SW v122)

• Síntoma: en la pantalla principal, con tema oscuro/negro/esmeralda, el aviso "Ingreso faltante" salía en crema muy claro y resaltaba feo.
• Fix: el aviso ahora detecta el tema (_temaEsOscuro: oscuro/negro/esmeralda) y usa la variante oscura (ámbar translúcido + texto dorado) en el home y en el historial clásico. En temas claros mantiene el ámbar claro. La vista premium ya usaba la variante oscura.
• Archivos: app.js (_temaEsOscuro, aviso adaptativo). SW v122.

2026-07-26 — Aviso de "ingreso faltante" + día de la semana en el historial (SW v121)

• Días faltantes: se detectan los días sin ingreso (recaudación) entre la fecha más antigua con ingreso y ayer, y se muestra una nota "Ingreso faltante" con los días (chip con día de semana + fecha). Aparece en el historial (clásico y premium) y en la pantalla principal (arriba del balance). Si no falta ninguno, no se muestra nada. Rango acotado a los últimos 45 días para no escanear de más.
• Día de la semana: cada entrada del historial ahora muestra el día (ej: "Jueves · 30-07-2026") en clásico y premium.
• Cómo: helpers _diaSemana, _calcularDiasFaltantes, _notaFaltantesHTML; contenedor #faltantesAvisoHome en tab-home. Se recalcula en cada refresh().
• Archivos: index.html (contenedor del aviso en home), app.js (helpers + inyección en historial/home + día de semana). SW v121.

2026-07-26 — Selector de sonido de notificación (Configuración de app) (SW v120)

• Qué se hizo: en Configuración de app se agregó "Sonido de notificación": el usuario elige entre Campanita, Ding, Pop, Doble bip, Marimba o Silencio. Suena al recibir un mensaje con la app abierta; toca una opción para escucharla; se guarda por dispositivo (localStorage: propi_sonido_notif).
• Cómo: los sonidos se sintetizan con Web Audio (osciladores) — no dependen de archivos ni del CDN externo (antes usaba assets.mixkit.co, que podía no sonar sin conexión). showToast ahora llama reproducirSonidoNotif().
• Límite (aclarado en la UI): el sonido de las notificaciones con la app cerrada lo controla el teléfono (Ajustes → Notificaciones), la web no puede cambiarlo.
• Archivos: index.html (tarjeta + #sonidoNotifOpciones), app.js (motor de audio, selector, reemplaza el Audio de mixkit). SW v120.

2026-07-26 — "Anticipos Anteriores" (premium): colapsable + filtro por año y mes (SW v119)

• Qué se hizo: la vista premium de Anticipos Anteriores ahora agrupa por período en tarjetas colapsables (acordeón, arrancan cerradas mostrando solo mes/año, cantidad y total; se expanden al tocar) y suma dos filtros: por año y por mes/fecha (se ocultan si solo hay un valor).
• Detalles: filtros nuevos pmFiltrarAntAnio/pmFiltrarAntMes sobre _histAnticiposData, acordeón pmTogglePeriodo, chips de filtro en estilo oscuro. Reutiliza _extraerAnio/_extraerMes/_fmtPeriodoLabel. La versión clásica ya tenía estos filtros; ahora la premium también.
• Archivos: index.html (barras de filtro en pmHistAntView), app.js (pmRenderAntAnt colapsable + lógica de filtros). SW v119.

2026-07-26 — "Anticipos Anteriores" lee SOLO de Supabase; Sheets es respaldo (SW v118)

• Por qué: el historial mezclaba dos orígenes (Supabase + Sheets/GAS), y esa mezcla era la raíz de las fechas/montos repetidos.
• Qué se hizo: getHistorialCompletoSocio ahora se arma únicamente con Supabase (anticipos_historial = archivado + anticipos = activo). Sheets/GAS pasa a ser solo respaldo: solo se usa si Supabase no tiene NINGÚN registro para el socio (datos aún no migrados). Se mantiene la dedup por fecha+monto por si un anticipo quedó en activo y archivado a la vez.
• Archivos: supabase-api.js. SW v118.

2026-07-26 — Fix: fechas/montos repetidos en "Anticipos Anteriores" (SW v117)

• Síntoma: en el historial → Anticipos Anteriores, una misma fecha (y monto) aparecía varias veces.
• Causa: getHistorialCompletoSocio junta 3 fuentes (archivado anticipos_historial + activo anticipos + GAS). Deduplicaba GAS contra el archivado, pero no los activos contra el archivado, así que un anticipo que quedó en ambas tablas se mostraba dos veces (fecha+monto repetidos), inflando también el total del período.
• Fix: deduplicación final por fecha+monto sobre las tres fuentes antes de agrupar por mes; se conserva el responsable si alguna fuente lo trae. Corrige tanto la lista como el total del período.
• Archivos: supabase-api.js. SW v117.

2026-07-26 — "Mis Documentos" vuelve a Perfil como opción propia (SW v116)

• Qué se hizo: se movió "Mis Documentos" desde Configuración de app a Perfil, como una opción (fila con ícono folder y chevron) debajo de la tarjeta de datos.
• Comportamiento: al tocar la opción se abre un modal "Mis Documentos" con el botón Subir documento y la lista de archivos (mismos IDs docFileInput/docUploadBtn/docsLista, así que subir/listar/borrar funciona igual). La lista se refresca al abrir.
• Archivos: index.html (opción en Perfil + documentosModal; se quita el bloque de Configuración), app.js (abrirDocumentosModal/cerrarDocumentosModal). SW v116.

2026-07-26 — "Ajustes" pasa a ser una sección de la barra: "Configuración de app" (SW v115)

• Qué se hizo: el engranaje ⚙️ que abría un modal desde Perfil se retiró; todo su contenido (cambiar nombre, notificaciones, tema, forma de foto del login, acceso al Diario, Mis Documentos) ahora vive en una sección propia de la barra inferior llamada "Configuración de app" (ícono settings, pestaña tab-config).
• Por qué: más accesible y visible que un modal escondido en Perfil; queda al mismo nivel que Balance, Historial, Stats, Mensajes y Perfil.
• Detalles: la barra ahora tiene 6 pestañas (se ajustó el ancho con flex-1 para que quepan). Se conservan abrirAjustesModal/cerrarAjustesModal como compatibilidad (la primera ahora navega a la pestaña, la segunda es no-op). Los IDs internos no cambiaron, así que tema/notificaciones/documentos siguen sincronizándose igual desde renderPerfil().
• Archivos: index.html (mueve el bloque a tab-config, nuevo botón de nav), app.js (abrirAjustesModal→switchTab('tab-config')). SW v115.

2026-07-24 — Fix definitivo: freeze de ~30s y datos que desaparecen al volver a la app (SW v114)

• Síntoma: al salir sin cerrar la app y volver, los datos desaparecían y tardaban 30s o más en cargar.
• Causa 1 (freeze 30s): dos consultas del balance no tenían timeout — getSocios y getDiasPartTime. Al reanudar en el móvil la conexión queda "dormida" y el primer fetch se cuelga hasta el timeout de red del sistema (~30s); como iban dentro del Promise.all del balance, congelaban todo el refresh. Fix: ambas ahora usan _conTimeout (8s) → nada bloquea más de 8s.
• Causa 2 (datos desaparecen): cuando una consulta hacía timeout devolvía datos vacíos, y el front repintaba el balance en $0 / "Sin movimientos". Fix: las respuestas por timeout se marcan _stale, y refresh() conserva los últimos datos buenos (_lastGood) en vez de pintar la pantalla en blanco → la data se queda visible y se actualiza sola.
• Causa 3 (refrescos apilados): refresh() no tenía guardia; al volver, el evento de visibilitychange + el intervalo de 20s + el realtime disparaban varios refrescos a la vez. Fix: guardia de reentrada con coalescing (si ya hay uno corriendo, se marca pendiente y se ejecuta uno solo de seguimiento).
• Archivos: supabase-api.js (timeouts + marca _stale en get, getAllDataDesdeSheets, getDiasPartTime, getSocios), app.js (refresh con guardia + _lastGood). SW v114.

2026-07-20 — Fix: carga lenta (~30s) al volver a la app (SW v113)

• Causa: al reanudar la app, si una consulta a Supabase venía vacía o la conexión quedaba "dormida", el interceptor esperaba al GAS (arranque en frío ~30s) y bloqueaba todo el Promise.all del balance → la app parecía pegada.
• Fix: helper _conTimeout que limita cada llamada: las consultas Supabase del balance (getAllDataDesdeSheets, getSaldosAnteriores, get de recaudaciones) y sus respaldos al GAS ahora tienen timeout (6–8s). En el caso normal Supabase responde al instante; si algo se demora, la app sigue con lo que hay y se actualiza en segundo plano — nunca se congela 30s.
• Archivos: supabase-api.js. SW v113.

2026-07-20 — Fix: el logo se volvía blanco al tocar la raya (SW v112)

• Causa: el gesto de deslizar aplicaba un transform al sheet del modal; eso, junto al mix-blend-mode del logo, rompía la composición y volvía el logo (y su zona) blanco en tema oscuro. El isolation:isolate agregado en v111 lo empeoraba.
• Fix: se quitó el transform del sheet y el isolation. Ahora tocar la raya cierra y deslizarla hacia abajo también (detección de gesto sin animar el sheet), así el logo nunca se rompe y sigue fundiéndose con el tema como antes.
• Archivos: index.html (sin isolation en #aboutSheet/#loginOverlay), app.js (_initAboutSwipe sin transform). SW v112.

2026-07-20 — Fusión del logo a prueba de fallos (isolation) (SW v111)

• El logo (.marca-logo) usa mix-blend-mode para fundirse con el tema. En algunos dispositivos, con el backdrop-blur del modal, la fusión no resolvía bien y el logo podía "perderse". Se agregó isolation:isolate al sheet del modal Acerca de y al login, para que el logo se funda de forma confiable contra el fondo de la tarjeta en todos los temas. (El logo no se había quitado; solo se blindó su fusión.)
• Archivos: index.html (#aboutSheet, #loginOverlay). SW v111.

2026-07-20 — Modal "Acerca de": la raya (asa) ahora cierra (tocar o deslizar) (SW v110)

• La barra/asa del modal "Acerca de" no tenía función. Ahora al tocarla se cierra y al deslizarla hacia abajo también (con animación). Además, tocar el fondo oscuro fuera de la tarjeta cierra el modal.
• Archivos: index.html (#aboutHandleZone con onclick + #aboutSheet), app.js (_initAboutSwipe con gestos touch). SW v110.

2026-07-20 — Marca (logo CarlosPN) al pie del login (SW v109)

• Se agregó el logo de marca (carlospn-logo.png, clase .marca-logo que se funde con el tema) al pie de la pantalla de login, con la línea "© 2026 · Todos los derechos reservados". No interfiere con el ingreso (pointer-events:none).
• Archivos: index.html (bloque marca en #loginOverlay). SW v109.

2026-07-20 — Guía de instalación en el login (Android / iPhone) (SW v108)

• En la pantalla de login hay un botón "¿Cómo instalar la app?" que abre una guía con pasos para Android (Chrome) y iPhone (Safari). En Android, si el navegador lo permite, aparece un botón "⬇️ Instalar ahora" (captura beforeinstallprompt).
• Primera vez: si la app no está instalada (no corre como PWA) y no se vio antes la guía, se muestra automáticamente antes de ingresar el PIN, para asegurar que la instalen. Si ya está instalada o ya la vieron, no se auto-muestra; el botón queda siempre disponible.
• Archivos: index.html (botón + #installGuideModal), app.js (abrirGuiaInstalar, _instalarPWA, _maybeMostrarGuiaInstalar, beforeinstallprompt). SW v108.

2026-07-20 — Solo versión nueva (premium): se retira la clásica + migración con efecto (SW v107)

• La app usa solo la versión nueva (premium). _homeVersionGuardada() siempre devuelve premium y el selector "Versión de inicio" en Ajustes quedó oculto (la clásica se retira).
• Migración única: a los socios que tenían la clásica les aparece un modal "Nueva versión disponible"; al tocar "✨ Activar nueva versión" cambian a la tarjeta nueva (balance estilo tarjeta) y a toda la versión premium, con un efecto de transición (.pm-switch-fx). Se marca propi_premium_migrado para no repetirlo. Quienes ya estaban en premium pasan directo, sin modal.
• Archivos: index.html (modal #nuevaVersionModal, selector de versión oculto), app.js (_maybeMigrarPremium, _activarNuevaVersion, _homeVersionGuardada/setHomeVersion forzados a premium), app.css (animación pmSwitchFx). SW v107.

2026-07-20 — Banner "Activar notificaciones" en la pantalla principal (SW v106)

• Aparece un banner automático (abajo, sobre la nav) invitando a activar las notificaciones, solo si el socio aún no decidió (permiso default) y no lo pospuso. Botón "Activar" → pide el permiso y, al aceptar, queda suscrito automáticamente (llama a activarNotificaciones). Botón "Ahora no" lo pospone 3 días.
• Se oculta solo cuando el permiso ya fue concedido o bloqueado. (El botón de Ajustes sigue disponible para activar/desactivar manualmente.)
• Archivos: index.html (#notifPrompt), app.js (_maybeShowNotifPrompt, _notifPromptActivar, _notifPromptCerrar; se refresca desde _pushRefrescarEstado). SW v106.

2026-07-19 — Puntos Bóveda: base 2 en la fórmula de respaldo (SW v105)

• Alineación con socios-comicion: la fórmula de respaldo de puntos (usada solo cuando el puntaje del socio aún no está guardado) ahora usa base 2 para Bóveda (antes 4), +2 por año, tope 10. No afecta a socios con puntaje guardado.
• Archivos: app.js. SW v105.

2026-07-19 — Fix logo de marca: fusión correcta (el PNG tiene fondo BLANCO) (SW v104)

• Corrección del intento anterior: el PNG del logo tiene fondo blanco (no negro), por eso en temas oscuros quedaba una "caja" blanca. Ahora: temas claros mix-blend-mode: multiply (el blanco se vuelve transparente, el logo azul marino se ve); temas oscuros (oscuro/negro/esmeralda) filter: invert(1) hue-rotate(180deg) + mix-blend-mode: screen (el blanco → negro → transparente, y el diseño queda claro y visible). Verificado numéricamente: el fondo se funde exacto con el color del tema y el logo queda como marca de agua.
• Archivos: app.css (regla .marca-logo). SW v104.

2026-07-19 — Logo de marca: se funde con el fondo como marca de agua (SW v103)

• (Intento con supuesto equivocado de fondo negro — corregido en v104.)
• Archivos: app.css (regla .marca-logo). SW v103.

2026-07-19 — Temas: tema Negro ahora ennegrece TODAS las tarjetas + nuevos temas (SW v102)

• Fix tema Negro: antes solo cambiaba el fondo; las tarjetas (clásicas, premium e inline) se quedaban azul-grisáceas del tema oscuro porque --lm-card y las variables premium (--pm-card, etc.) no se sobreescribían y algunas reglas de negro quedaban pisadas por las de oscuro. Ahora un bloque al final de app.css (gana por orden de fuente) pone todas las tarjetas negras (#141414) con borde y texto de contraste. También se corrigió el contraste de las tarjetas ámbar/verde de días PT en temas oscuros (texto más claro).
• Temas nuevos con contraste: Esmeralda (verde oscuro, base oscuro + data-tinte), Menta (verde-agua claro) y Durazno (cálido claro). Total: 9 temas.
• Archivos: app.css (overrides de negro + 3 temas nuevos + contraste PT oscuro), app.js (_TEMAS, _TEMA_TINTE, aplicarTema maneja data-tinte), index.html (botones de tema + script anti-parpadeo actualizado). SW v102.

2026-07-19 — Días PT: notificar a las DOS apps al marcar un día (Edge Function push-notify v5)

• Al marcar un día, ahora se notifica por push a ambas aplicaciones: al administrador (socios-comicion) "Día Part-Time por confirmar" y al socio (propi.solicitada) "Día enviado — en proceso" confirmándole que su turno quedó registrado y está en espera de validación. Antes solo se avisaba al administrador.
• El trigger de BD ahora dispara con INSERT o UPDATE a PENDIENTE, así también avisa cuando un socio vuelve a marcar un día que le habían rechazado (sin generar avisos de más al confirmar/rechazar, gracias a la cláusula WHEN NEW.estado='PENDIENTE').
• Backend: Edge Function push-notify v5 (helper push() reutilizable, doble envío para dias_pt_solicitados), trigger trg_notify_push_dia_pt (INSERT OR UPDATE). Requiere que el socio tenga las notificaciones activadas en su app.

2026-07-19 — Días PT: total estimado del valor punto por noche en la tarjeta (SW v101)

• La tarjeta "Por confirmar" (clásica y premium) ahora muestra también "Valor punto x noche (est.)" = el VP acumulado de los días confirmados + el VP de los días por confirmar. Así el socio ve el total estimado del valor punto por noche, además del monto.
• Archivos: index.html (#ptConfTotalVPCl / #ptConfTotalVPPm), app.js (renderPTConfirmarCard suma VP confirmado + pendiente). SW v101.

2026-07-19 — Días PT: mostrar el "VP por noche" en cada día por confirmar (SW v100)

• En el detalle "Por confirmar" del calendario, cada día ahora muestra su VP por noche (valor de 1 punto esa noche, según la recaudación del día), igual que los días ya confirmados. Si aún no hay recaudación cargada para ese día, indica "sin recaudación aún".
• Archivos: app.js (línea VP en el detalle de días pendientes). SW v100.

2026-07-19 — Días PT: "Total estimado" también en la tarjeta de inicio (SW v99)

• La tarjeta "Por confirmar" de la pantalla principal (clásica y premium) ahora muestra además el Total estimado = lo ya confirmado (días en planilla) + lo que está por confirmar. Así el socio ve de una sola vez todo lo que obtendrá, sin abrir el calendario.
• Archivos: index.html (#ptConfTotalEstCl / #ptConfTotalEstPm), app.js (renderPTConfirmarCard calcula el total). SW v99.

2026-07-19 — Días PT: tarjeta "Por confirmar" en pantalla principal + calendario minimizable (SW v98)

• Tarjeta "Por confirmar" en la pantalla principal (clásica y premium): el socio Part-Time ve, sin abrir el calendario, cuánto ganará cuando la comisión valide los días que marcó (monto + N días). Al tocarla abre el calendario.
• Calendario minimizable: botón "Minimizar calendario / Mostrar calendario" que colapsa la cuadrícula para dejar más espacio al detalle de abajo (el modal quedaba muy apretado en pantallas chicas). Se compactaron márgenes y tarjetas del encabezado del modal.
• Archivos: index.html (#ptConfirmarCardClasica, #ptConfirmarCardPm, botón #calMinBtn, #calGridWrap), app.js (renderPTConfirmarCard, toggleCalMinimize). SW v98.

2026-07-19 — Días PT: mostrar monto estimado en el calendario (SW v97)

• En el calendario del socio Part-Time se agregó un resumen "Por confirmar" + "Total estimado": el socio ve cuánto ganaría con los días que marcó (aún por validar) y el total proyectado del período (confirmado + por confirmar).
• El valor de cada día marcado se calcula en vivo con la recaudación de ese día × sus puntos (si aún no hay recaudación cargada, usa el valor guardado al marcar). Aplica tanto al resumen como al detalle "Por confirmar".
• Archivos: index.html (bloque #calPTResumen), app.js (_ptValorDia, cálculo del resumen). SW v97.

2026-07-19 — Autogestión de días trabajados Part-Time (SW v96)

• Los socios Part-Time ahora pueden marcar sus días trabajados tocando el día en su calendario ("Turnos Realizados"). El día queda "por confirmar" en un color ámbar distinto y muestra el valor estimado que ganarían (~$…, calculado con la recaudación de ese día × sus puntos).
• Al marcar un día se crea una solicitud PENDIENTE en la tabla dias_pt_solicitados (proyecto socios). La administración recibe una notificación push ("Día Part-Time por confirmar") aunque tenga la app cerrada.
• Cuando el encargado valida el día en socios-comicion, éste pasa a la planilla real (dias_pt) y en la app del socio cambia de ámbar a verde (confirmado) con su valor definitivo. Si lo rechaza, el socio ve el motivo y puede volver a marcarlo.
• El socio puede quitar un día que aún esté por confirmar (solo mientras esté PENDIENTE). No se permite marcar días futuros ni días ya confirmados.
• Realtime: el calendario del socio se actualiza solo cuando la comisión confirma/rechaza (suscripción a dias_pt_solicitados y dias_pt).
• Archivos: supabase-api.js (acciones marcarDiaPT, desmarcarDiaPT, misDiasPTSolicitados + realtime), app.js (calendario interactivo, togglePTDia, cargarDiasPTSolicitados, detalle "por confirmar"/"rechazados"), app.css (estilos .pt-pendiente / .pt-rechazado), index.html (hint del calendario). Backend: tabla dias_pt_solicitados + trigger push, edge function push-notify v4. SW v96.

2026-07-16 — El socio puede cancelar su solicitud de egreso pendiente (SW v95)

• Se agregó un botón "Cancelar solicitud" en la tarjeta de egreso pendiente (en ambas versiones, clásica y premium). Sirve para cuando el socio la hizo por error o se arrepiente.
• Nueva acción cancelarEgreso (Supabase): borra solo las solicitudes con estado PENDIENTE del socio (nunca las ya procesadas) y avisa a socios-comicion por realtime, así deja de aparecer en el panel de administración.
• Archivos: supabase-api.js (acción cancelarEgreso), app.js (botón + cancelarEgreso()). SW v95.

2026-07-16 — Congruencia versión Premium: Resumen Contable (Saldo Anterior) y egreso pendiente (SW v94)

• Problema: en la versión Premium/Dashboard no aparecían el Resumen Contable (con "Saldo Anterior") ni el estado de la solicitud de egreso pendiente — solo estaban en la versión Clásica.
• Fix: se agregaron al dashboard premium los contenedores #pmDetallesContables (Resumen Contable con estilo oscuro) y #pmEgresoEstadoBox (egreso pendiente). El JS ahora llena ambas versiones (clásica y premium) con la misma información: Total Bruto, Saldo Anterior, Descuentos/Anticipos, y la tarjeta de egreso pendiente.
• Archivos: index.html (contenedores premium), app.js (renderEgresoEstado y resumen contable llenan premium). SW v94.

2026-07-16 — Ayuda: menú índice seleccionable que salta directo a cada tema (SW v93)

• La guía de ayuda ahora tiene un botón "Temas" (menú índice) arriba a la izquierda: abre una lista seleccionable de los 23 temas (ícono + título + número). Al tocar uno salta directo a esa ayuda (como en socios-comicion). El botón cambia a "Volver" para regresar al contenido.
• Contenido actualizado con lo último: la ayuda de Temas ahora menciona los 6 estilos (incluido el nuevo Negro OLED) y que el logo se adapta al tema; la ayuda de Recaudación del Día menciona el botón "Abrir Diario de Recaudación".
• Archivos: index.html (botón Temas, contenedores #helpIndex/#helpContent/#helpNav), app.js (helpToggleIndex, helpRenderIndex, helpIndexGoTo + textos actualizados). SW v93.

2026-07-16 — Botón "Abrir Diario de Recaudación" en el modal Recaudación del Día (SW v92)

• Se agregó un botón dentro del modal Ingresar Recaudación que abre diario.propi (https://diario-propi.vercel.app/) en una pestaña nueva, para acceder al diario completo de recaudaciones desde la app del socio.
• Archivos: index.html. SW v92.

2026-07-16 — Tema "Negro" (OLED) + logo de marca que se mimetiza con el tema (SW v91)

• Nuevo tema "Negro" en Perfil → Ajustes → Tema de la app (además de Oscuro/noche). Se aplica como el tema Oscuro + atributo data-negro que empuja los fondos a negro puro (OLED), reutilizando todo el restyle oscuro sin duplicar CSS.
• Logo de marca adaptativo: el logo del modal Acerca de ahora se mimetiza con el fondo del tema. En temas claros su fondo blanco se funde (mix-blend-mode:multiply); en Oscuro/Negro se invierte (invert + hue-rotate) para que el fondo del logo se vuelva oscuro (mimetizado) y el diseño quede claro y visible.
• Se corrigió también el script pre-render de tema (antes solo aceptaba claro/oscuro/rosa; ahora los 6 temas, evitando parpadeo con aqua/lavanda/negro).
• Archivos: app.css (tema negro + logo), app.js (aplicarTema, _TEMAS, _TEMA_COLOR), index.html (botón, script pre-render, clase marca-logo). SW v91.

2026-07-16 — Login: botón "Contactar Comisión" chico arriba (ya no tapa "Activar Dispositivo") (SW v90)

• Problema: el botón "Contactar a La Comisión Propina" (#loginCTA) estaba absolute bottom-8 ocupando todo el ancho abajo, y se interponía con el botón "Activar Dispositivo" del setup.
• Fix: ahora es un botón pequeño tipo pill arriba-centro (con safe-area), texto corto "Contactar Comisión", ícono de WhatsApp reducido. No ocupa toda la pantalla ni tapa el formulario.
• Archivos: index.html. SW v90.

2026-07-16 — Logo de marca "CarlosPN Interactive" en el modal Acerca de (SW v89)

• Se agregó el logo oficial (img/carlospn-logo.png) arriba de la marca en el modal Acerca de, reemplazando el ícono code placeholder. Debajo queda el subtítulo "Sistema Profesional de Gestión · 2026".
• Archivos: index.html, img/carlospn-logo.png (nuevo). SW v89.

2026-07-16 — Fix: anticipos anteriores AÚN repetían fechas — dedup por registro (SW v88)

• La agrupación por mes no bastaba: si un mismo anticipo venía de GAS y de Supabase con etiquetas de período distintas, seguía apareciendo dos veces.
• Fix definitivo: ahora se deduplica por registro (fecha+monto): Supabase es la fuente de verdad y de GAS solo se agregan los anticipos que no estén ya en Supabase. No se deduplica dentro de una misma fuente, así que no se pierden dos anticipos iguales legítimos del mismo día.
• Además, los registros con período nulo se agrupan por el mes real derivado de la fecha (regla 15→14), y cada grupo se ordena por fecha.
• Archivos: supabase-api.js (getHistorialCompletoSocio). SW v88.

2026-07-16 — Fix: anticipos anteriores repetían fechas/meses (SW v87)

• Bug: tras leer el histórico de GAS y Supabase, un mismo mes podía aparecer duplicado porque venía con nombres distintos ("Julio 2026" en GAS vs "CIERRE_JULIO_DE 2026" en Supabase), repitiendo las fechas.
• Fix: ahora los períodos se agrupan por mes canónico (año-mes) y cada mes usa una sola fuente (Supabase reemplaza el mes completo si lo tiene; GAS solo para meses que Supabase no tenga). Se evita duplicar sin riesgo de sub-contar (no se hace dedup por registro, que podría borrar dos anticipos iguales del mismo día).
• Archivos: supabase-api.js (getHistorialCompletoSocio). SW v87.

2026-07-16 — Fix: los anticipos anteriores del mes no aparecían (SW v86)

• Bug: los anticipos anteriores del socio no mostraban los períodos recién archivados (ej. el mes en curso). Causa: getHistorialCompletoSocio leía el histórico solo desde GAS, pero el archivado actual (al marcar Cobrado o al cerrar el mes en socios-comicion) se guarda en la tabla Supabase anticipos_historial, no en GAS.
• Fix: ahora también se lee anticipos_historial de Supabase y se fusiona con lo de GAS (evitando duplicar períodos que ya vengan de GAS).
• Extra: las etiquetas de período se muestran legibles (_fmtPeriodoLabel): "CIERRE_JULIO_DE 2026", "JULIO_2026" o "2026-06-15" → "Julio 2026".
• Archivos: supabase-api.js (lectura de anticipos_historial), app.js (_fmtPeriodoLabel en las 2 vistas de anticipos anteriores). SW v86.

2026-07-09 — Contador de pedidos descriptivo (SW v85)

• El contador de Últimos Movimientos ahora dice "Llevas N pedidos · te restan X · máximo 8" (antes "N / 8"). El número que resta se pinta verde/ámbar/rojo según cuánto queda. Clásico y Dashboard.

2026-07-09 — Contador de movimientos "N / 8" en Últimos Movimientos (SW v84)

• Junto al título "Últimos Movimientos" (Balance) se agregó un contador con la cantidad de movimientos del período y el máximo (por defecto 8), formato "5 / 8". Aplica a la versión clásica y a la Dashboard.
• Cambia de color al llegar/pasar el máximo: ámbar si iguala 8, rojo si lo supera.
• El máximo está en la constante MOVS_MAX (app.js) — fácil de ajustar.
• Archivos: index.html (badges #anticiposCount / #pmMovsCount), app.js (actualiza los contadores con merged.length). SW v84.

2026-07-09 — Notas destacadas: "Destacado para: …" visible para todos en Soporte (SW v83)

• Antes, en el chat Soporte de propi solo el socio destacado veía algo ("⭐ PARA TI"); el resto veía la nota sin ninguna marca de destacado. Ahora todos ven un badge "⭐ Destacado para: [nombres]" en la nota (resuelve IDs → nombres con allSocios), y el socio destacado sigue viendo "⭐ PARA TI" + anillo dorado.
• Nota: la nota destacada se guarda y muestra correctamente en Supabase (notas_recaudacion.destacados). Solo aparece en Soporte (que es donde viven las notas admin), no en Equipo/Admin (son otros sistemas de mensajes).
• Archivos: app.js (badge "Destacado para" en render del chat Soporte). SW v83.

2026-07-09 — Fix deploy: vercel.json con rutas exactas (los cambios no se reflejaban) (SW v82)

• Causa probable: el vercel.json usaba un source con grupo/alternación "/(index.html|app.js|app.css|supabase-api.js|originalindex.html)". Ese patrón puede fallar la validación de Vercel y romper el deploy, dejando la app servida en la última versión buena (por eso desde ~v78 los cambios no se reflejaban en el dispositivo).
• Fix: se reescribió vercel.json con una regla por archivo con ruta exacta (/index.html, /app.js, /app.css, /supabase-api.js, /), 100% válidas para Vercel. Mismo arreglo en diario.propi. (socios-comicion ya usaba /js/(.*), patrón válido, y sí desplegaba.)
• Al corregir el deploy, todas las versiones acumuladas (v78–v82) quedan disponibles. SW v82.

2026-07-09 — Acceso al Diario de Recaudación desde Ajustes (SW v81)

• En Perfil → ⚙️ Ajustes se agregó un acceso "Diario de Recaudación" que abre diario.propi en una pestaña nueva (https://diario-propi.vercel.app/).
• Nota: la URL está hardcodeada en index.html (marcada con comentario) — ajustar si el dominio de despliegue es distinto.
• Archivos: index.html (enlace en el modal de Ajustes). SW v81.

2026-07-09 — Notas destacadas: "⭐ Para ti" en el chat Soporte (SW v80)

• Cuando la administración crea una nota destacada para un socio (desde socios-comicion), a ese socio le aparece en el chat Soporte con un anillo dorado y la etiqueta ⭐ PARA TI, para que no se le pase.
• Se lee de notas_recaudacion.destacados (IDs de socio); si el currentUser.ID está en la lista, se resalta la burbuja.
• Archivos: supabase-api.js (getNotes REC devuelve destacados), app.js (resaltado en el render del chat ADMIN/Soporte). SW v80.

2026-07-09 — Scroll Dashboard a prueba de balas: espaciador al final (SW v79)

• Refuerzo del fix de scroll de la versión Dashboard: además del padding inferior con env(safe-area-inset-bottom), se agregó un div espaciador (90px + área segura) al final de #homePremium (tras "Últimos Movimientos") y de #historyPremium. Así el último ítem (ej. el primer anticipo con su fecha) nunca queda tapado por la barra inferior en ningún teléfono, incluso en casos límite de flex/scroll.
• Archivos: index.html (espaciadores). SW v79.

2026-07-09 — Vercel: no-cache para HTML/JS core (destraba versiones viejas) (SW v78)

• Causa: dispositivos quedaban "pegados" en una versión vieja porque el navegador/CDN servía copias cacheadas de index.html/app.js/app.css/supabase-api.js, y el updater viejo no lograba refrescarlas.
• Fix: se ampliaron los headers en vercel.json para servir esos archivos core (y /) con Cache-Control: no-cache, must-revalidate (antes solo sw.js). Así el navegador revalida siempre y baja la versión nueva en la próxima apertura, sin necesidad de recarga forzada.
• Esto, junto al fix de scroll (v77, que sí está aplicado en el código pero no había llegado a los dispositivos), resuelve el problema del scroll una vez que baje la versión.
• Archivos: vercel.json. SW v78.

2026-07-09 — Fix scroll versión Dashboard + guía de ayuda actualizada (SW v77)

• Fix scroll en versión Dashboard: en #homePremium y #historyPremium se cambió min-height:calc(100vh - 120px) (el 100vh varía en iPhone/Android y descuadraba el scroll) por min-height:100%, y el padding inferior pasó a calc(110px + env(safe-area-inset-bottom)). Así el contenido siempre llega al final y libra la barra inferior en todos los modelos (iPhone con notch, Redmi, etc.).
• Guía de ayuda actualizada: se agregaron slides para Versión de inicio (Clásica/Dashboard), Correo electrónico y Personalizar el ingreso (ojito del PIN + forma de la foto); y el slide de Temas ahora menciona los 5 temas (Claro/Oscuro/Rosa/Aqua/Lavanda) y el botón ⚙️ Ajustes.
• Archivos: index.html (padding/min-height premium + novedades del banner), app.js (helpSlides). SW v77.

2026-07-09 — Fix robusto de actualización: banner + recarga garantizada (SW v76)

• Recarga garantizada al activar el SW nuevo: se cambió a un patrón estándar con guardia — cuando el SW nuevo toma control (controllerchange) la app recarga UNA vez para aplicar la versión (sin recargar en la instalación inicial). Antes dependía de una bandera (_updateApplying) que podía no dispararse.
• Detección más amplia: ahora también se sigue el SW que ya está installing al cargar (no solo waiting), así el banner aparece en más casos. Red de seguridad: si controllerchange no dispara en 2.5 s, recarga igual.
• Contenido siempre fresco: en el Service Worker los archivos core (html/js/css y navegaciones) se piden con cache:'no-store', así el navegador/CDN no puede servir una copia vieja → la versión nueva baja de verdad.
• Nota: como con los fixes anteriores, esto recién toma efecto tras cargar esta versión una vez.
• Archivos: index.html (_seguirWorker, controllerchange con guardia, _aplicarActualizacion), sw.js (fetch no-store para core). SW v76.

2026-07-09 — Correo del socio: se solicita al ingresar, se guarda en Supabase y se muestra en el perfil (SW v75)

• Al ingresar a la app, si el socio no tiene correo, aparece un aviso: "Se solicita agregar tu correo electrónico para completar tu información" (modal #correoModal, ~3s después de entrar; espera si el modal de RUT/ayuda está abierto).
• El correo se guarda en Supabase (nueva columna socios.correo, acción guardarCorreoSocio en supabase-api.js, con auditoría). El mapeo getSocios ahora incluye Correo.
• Se muestra en Perfil → Información Laboral (fila "Correo" ✉️). La fila es tocable para agregar/editar el correo manualmente (abre el mismo modal). Validación de formato de email.
• Archivos: supabase-api.js (guardarCorreoSocio + Correo en getSocios), index.html (#correoModal + fila Correo en el perfil), app.js (checkCorreoRequired, openCorreoModal, submitCorreo, poblar #perfilCorreo). Migración Supabase: add_correo_to_socios. SW v75.

2026-07-09 — Forma de la foto movida a Ajustes + foto de login más grande (SW v74)

• El selector "Forma de la foto" se movió del login a Perfil → ⚙️ Ajustes (junto a Tema y Versión de inicio). Cambia la forma del avatar del login (Círculo/Redondeado/Cuadrado/Hexágono) y se guarda por dispositivo. El resaltado del chip activo se sincroniza al abrir el perfil.
• La foto del login se hizo más grande (de 80px a 128px, w-20→w-32), con el ícono/placeholder acorde.
• El ojito para ver el PIN se mantiene en el login (es un botón del propio campo).
• Archivos: index.html (selector movido al modal, avatar login w-32), app.js (_aplicarLoginShape en renderPerfil). SW v74.

2026-07-09 — Login: ojito para ver el PIN + elegir forma de la foto (SW v73)

• Ojito (ver PIN): se agregó un botón 👁 en los campos de PIN (acceso rápido #fastPIN y "Crear PIN" #setupPIN) para mostrar/ocultar el PIN. Alterna type password/text y el ícono visibility/visibility_off.
• Forma de la foto del login: en el acceso rápido se agregó un selector "Forma de la foto" con 4 opciones — Círculo, Redondeado, Cuadrado, Hexágono. Se aplica al avatar del login y se guarda por dispositivo (propi_login_shape).
• Archivos: index.html (ojitos + selector de forma), app.css (.login-shape-btn), app.js (togglePinVisible, setLoginAvatarShape, _aplicarLoginShape). SW v73.

2026-07-09 — Dashboard: ahora SÍ sigue el tema (claro/oscuro/rosa/aqua/lavanda) (SW v72)

• Antes el Dashboard forzaba una paleta oscura fija y elegir un tema casi no cambiaba nada. Ahora el layout Dashboard sigue completamente el tema de color: con temas claros se ve claro, con Oscuro se ve oscuro, y con Rosa/Aqua/Lavanda toma esos colores.
• Se implementó con variables --pm-* (fondo, tarjeta, texto, acento, verde, rojo, borde) definidas por tema, y reglas .pm-layout [style*=...] que mapean los colores fijos del layout premium a esas variables. Las secciones con skin (Estadísticas/Mensajes/Perfil) ahora siguen el tema por su cuenta (se quitó el forzado oscuro data-premium).
• Las tarjetas bancarias se mantienen oscuras a propósito (como una tarjeta real), protegidas del mapeo.
• Archivos: app.css (variables --pm-* + mapeo .pm-layout), index.html (clase pm-layout en #homePremium y #historyPremium). SW v72.

2026-07-09 — Dashboard: el acento sigue el tema de color elegido (SW v71)

• Antes, en la versión Dashboard el skin premium tenía una paleta fija y elegir un tema no cambiaba nada. Ahora el acento premium sigue el tema de color (Rosa, Aqua, Lavanda) manteniendo el fondo oscuro.
• Se hace con reglas :root[data-premium][data-premium][data-theme="X"] que cambian las variables de acento (--lm-primary/--lm-accent/--lm-secondary) para las secciones con skin, y overridean los colores de acento fijos del layout premium (#cee6f7 celeste y #6366f1 índigo de los íconos del Perfil) al color del tema. Oscuro y Claro mantienen el acento azul/celeste por defecto.
• Los verdes de montos positivos se mantienen (color semántico de ganancia).
• Archivos: app.css (acento premium por tema). SW v71.

2026-07-09 — Dashboard: tarjeta "Valor Punto" + Mis Puntos dentro de la tarjeta bancaria (SW v70)

• La tarjeta de stat que decía "Mis Puntos" ahora se titula "Valor Punto" y muestra ese valor ($ del punto a hoy) como número grande (verde).
• Mis Puntos se movió dentro de la tarjeta bancaria (vista tarjeta del balance): aparece en la fila inferior, al centro (Titular · Mis Puntos · Miembro desde), en dorado. Aplica a la tarjeta clásica y a la premium.
• Se pobla en _refrescarTarjeta leyendo los puntos del socio (#perfilPuntos). IDs nuevos: tarjetaPuntos / tarjetaPuntosPm.
• Archivos: index.html (tarjeta Valor Punto + columna Mis Puntos en ambas tarjetas bancarias), app.js (_refrescarTarjeta). SW v70.

2026-07-09 — Dashboard: "Mis Puntos" y "Remanente" lado a lado (SW v69)

• En la home de la versión Dashboard, las tarjetas Mis Puntos y Remanente pasaron de estar apiladas (una debajo de otra) a estar lado a lado en dos columnas, ocupando menos espacio. Se rediseñaron como tarjetas compactas verticales (ícono + título arriba, valor grande, y un dato secundario abajo: "Valor punto" / "Pasa al próximo mes"). IDs sin cambios (pmPuntos, pmValorPunto, pmRemanente).
• Archivos: index.html (grid de stats premium a 2 columnas). SW v69.

2026-07-09 — Fix: el banner de actualización no aparecía (chequeo periódico) (SW v68)

• Causa: la app solo chequeaba actualizaciones al cargar y al volver al foco (visibilitychange). Si quedaba abierta en primer plano, nunca se chequeaba → el banner no aparecía y había que recargar a mano (Ctrl+R).
• Fix: el Service Worker ahora se registra con updateViaCache:'none' (nunca cachea sw.js por HTTP) y se agregó un chequeo periódico cada 45 s (reg.update()) mientras la app está abierta. Así el banner aparece solo poco después de publicar una versión.
• Además, al terminar la cuenta regresiva de 15 s el banner ahora recarga para aplicar la versión (la sesión se mantiene por el auto-login), en vez de solo activarse en silencio — así la versión aparece sin acción manual.
• Nota: este arreglo recién toma efecto después de cargar esta versión una vez (la app en ejecución todavía tiene la lógica vieja). De ahí en adelante, las actualizaciones aparecen solas.
• Archivos: index.html (registro SW + setInterval de chequeo + cuenta regresiva recarga). SW v68.

2026-07-09 — Calendario condicional en premium + cambio de tarjeta en ambas versiones (SW v67)

• Calendario: en la versión Dashboard el acceso "Ver Calendario de Turnos" aparecía siempre. Ahora se oculta si no hay días/ausencias que mostrar (globalDiasCalendar.length === 0), igual que en la clásica (para Planta sin ausencias no aparece).
• Efecto de cambio de tarjeta en ambas versiones: el botón 💳 que alterna entre la tarjeta normal y la tarjeta bancaria ahora también está en la versión Dashboard. Se agregó una tarjeta bancaria premium (#pmBalanceTarjeta) y _aplicarBalanceEstilo / _refrescarTarjeta ahora manejan los dos juegos de tarjetas (clásica y premium) con la misma preferencia (propi_balance_estilo).
• Archivos: index.html (#pmBalanceCard, #pmBalanceTarjeta, botón 💳), app.js (_aplicarBalanceEstilo/_refrescarTarjeta para ambas versiones, #pmCalBtn condicional, monto premium en vivo). SW v67.

2026-07-09 — Fix: Perfil y Mensajes no tomaban el skin premium (especificidad) (SW v66)

• Causa: en tema Oscuro, sus convertidores de estilos inline (:root[data-theme="oscuro"] [style*=...]) tenían más especificidad que el skin premium por clase, así que ganaban. Estadísticas cambiaba (usa variables) pero Perfil y Mensajes (usan estilos inline #fff/#001723) se quedaban con los colores del Oscuro.
• Fix: el skin premium pasó de una clase en body a un atributo data-premium en <html>, con selector :root[data-premium][data-premium] … (atributo repetido) para garantizar mayor especificidad que las reglas del tema Oscuro. Ahora Perfil y Mensajes sí toman la paleta premium.
• Archivos: app.css (reglas :root[data-premium][data-premium]), app.js (_aplicarHomeVersion set/removeAttribute data-premium). SW v66.

2026-07-09 — Versión Dashboard: skin premium en toda la app + fix header en Mensajes (SW v65)

• Fix Mensajes: el skin anterior ponía un fondo opaco directo sobre #tab-chat, que tapaba el header (foto, campana, área, ayuda, cerrar) que se ve por el espaciador superior del chat. Ahora el skin se aplica al body (no al chat directo), así el header vuelve a verse.
• Header y barra inferior acordes al tema: al aplicar .premium-skin al body, el header (.glass) y la barra de navegación (#bottomNav) toman las variables premium (--glass-bg / --nav-bg / --nav-border), quedando en el tono oscuro premium.
• Paleta más distinta: el skin ahora usa los tonos del mockup (fondo #0f1419, tarjetas #171c22, verde #3de273) en vez de la paleta oscura estándar, para que se note el cambio respecto al tema Oscuro. Se mantiene el primario azul para no romper el contraste de botones/tarjetas con texto blanco.
• Archivos: app.css (.premium-skin con variables de header/nav + tonos mockup), app.js (_aplicarHomeVersion aplica el skin al body). SW v65.

2026-07-09 — Versión Dashboard: tema premium también en Estadísticas, Mensajes y Perfil (SW v64)

• Se completó la Versión Dashboard aplicando el tema oscuro premium a las secciones Estadísticas, Mensajes y Perfil, reutilizando su mismo layout y cableado (no se duplicó lógica).
• Se hace con una clase .premium-skin que redefine la paleta (variables --lm-*, --color-card, --chat-bg, etc.) y convierte los estilos inline claros a oscuros, sólo en esas tres pestañas y sólo cuando la versión Dashboard está activa. Usa los colores del tema oscuro (probados) para no romper contrastes.
• _aplicarHomeVersion ahora: muestra los layouts premium de inicio/historial y aplica/quita .premium-skin en #tab-stats, #tab-chat, #tab-perfil. Al volver a "Clásica", todo regresa al tema de color elegido.
• Archivos: app.css (.premium-skin), app.js (_aplicarHomeVersion). SW v64.

2026-07-09 — Historial premium: desglose de tipos por día (SW v63)

• La lista de Movimientos del Historial premium ahora muestra, por día, una tarjeta con el desglose de tipos (Mesas, MDA, Bóveda, etc. con su monto), igual que la versión clásica, más la grilla Valor Punto / Mis Pts / Mi Ganancia y la etiqueta del día (Ausencia / Trabajado / No trabajado). Antes solo mostraba una línea por día sin los tipos.
• Archivos: app.js (reconstrucción del bloque premium del historial con tiposHTML), index.html (#pmHistList sin caja, cada día es su propia tarjeta). SW v63.

2026-07-09 — Historial premium: opción "Anticipos Anteriores" (SW v62)

• En la vista Historial de la Versión Dashboard se agregó el toggle Movimientos / Anticipos Anteriores (igual que en la clásica).
• "Anticipos Anteriores" reutiliza la misma carga de datos (loadHistorialAnticipos → getHistorialCompletoSocio) y los muestra en estilo oscuro: cada período como tarjeta con su total y el detalle de registros (fecha, responsable, monto). Se carga la primera vez que se abre.
• Archivos: index.html (toggle + #pmHistMovsView / #pmHistAntView / #pmAntAntList), app.js (pmSwitchHist, pmRenderAntAnt). SW v62.

2026-07-09 — Versión Dashboard: también el Historial en estilo premium (SW v61)

• La Versión Dashboard ahora incluye la sección Historial en estilo oscuro premium (además del inicio). Al activar Dashboard, el Historial muestra: stats (Total Rendimiento, Anticipos Solicitados, Valor Punto a hoy) y una lista de movimientos que combina rendimientos por día (verde) y anticipos (rojo), ordenados por fecha, con contador — todo con datos reales.
• Se envolvió el historial clásico en #historyClasico y se agregó #historyPremium. _aplicarHomeVersion alterna ahora ambas secciones (inicio + historial) a la vez.
• Archivos: index.html (#historyPremium), app.js (poblado de pmHist* en el cálculo, toggle por pares en _aplicarHomeVersion). SW v61.

2026-07-09 — Nueva "Versión de inicio: Dashboard (Premium)" seleccionable (SW v60)

• Se agregó una versión alternativa de la pantalla de inicio/Balance con estética oscura premium (tipo dashboard), manteniendo la clásica. Se elige desde ⚙️ Ajustes → Versión de inicio (Clásica / Dashboard) y se guarda por dispositivo (propi_home_version).
• La versión Dashboard incluye: saludo, tarjeta de balance premium (balance, miembro desde, ID), Accesos Rápidos (Recaudación del Día, Solicitar Egreso, Ver Calendario), stats (Mis Puntos + Valor Punto Hoy, Remanente) y Últimos Movimientos — todo poblado con los datos reales del socio (mismos cálculos que la clásica).
• El home clásico se envolvió en #homeClasico; la nueva vista es #homePremium (oscura, hardcodeada, independiente del tema de color).
• Archivos: index.html (#homePremium, selector en el modal de Ajustes), app.js (setHomeVersion, _aplicarHomeVersion, _refrescarPremium, poblado de pm* en el cálculo del balance), app.css (.homever-btn). SW v60.

2026-07-09 — Barra inferior legible en oscuro + 2 temas nuevos + Balance estilo tarjeta bancaria (SW v59)

• Barra de navegación en modo oscuro: la pestaña activa quedaba casi invisible (usaba #001723 fijo). Ahora usa rgb(var(--lm-primary)), así resalta en todos los temas.
• Dos temas nuevos para probar: Aqua (turquesa 💧) y Lavanda (púrpura 🌿), ambos claros. Se eligen desde ⚙️ Ajustes → Tema. (_TEMAS/_TEMA_COLOR en app.js, bloques de variables en app.css.)
• Balance estilo "tarjeta bancaria" (versión alternativa, se mantiene la clásica): en la pestaña Balance, botón 💳 en la tarjeta para alternar entre la vista clásica y una tarjeta tipo bancaria (chip dorado, monto, número enmascarado con los últimos 4 del ID, titular y "miembro desde"). La preferencia se guarda por dispositivo (propi_balance_estilo). El botón 🔄 en la tarjeta vuelve a la clásica.
• Archivos: app.css (.nav-btn.active, temas aqua/lavanda), index.html (botones de tema, #balanceTarjeta, botón alternar), app.js (toggleBalanceEstilo, _aplicarBalanceEstilo, _refrescarTarjeta, sync del monto). SW v59.

2026-07-09 — Perfil: engranaje ⚙️ arriba abre Ajustes en modal + Antigüedad dentro de Información Laboral (SW v58)

• Ajustes y personalización ya no ocupa espacio en la página: se movió a un engranaje ⚙️ en la esquina superior derecha del Perfil. Al tocarlo abre un modal (hoja inferior) con las 4 opciones: Cambiar nombre, Notificaciones, Tema y Mis Documentos. Reemplaza la barra desplegable anterior.
• Antigüedad y Puntos se integró dentro de Información Laboral: "Años en Casino" 🏅 y "Mis Puntos" ⭐ ahora son filas de esa tarjeta (con el mensaje descriptivo al pie). Se eliminó la tarjeta verde separada.
• Archivos: index.html (engranaje abrirAjustesModal(), #ajustesModal, filas de antigüedad en Info Laboral), app.js (abrirAjustesModal/cerrarAjustesModal; se quitó togglePerfilAjustes), app.css (se quitó la regla de la barra). SW v58.

2026-07-09 — Perfil: RUT en Información Laboral + barra de Ajustes visible en oscuro (SW v57)

• En Perfil → Información Laboral se agregó la fila RUT del socio (huella 🔎). Toma currentUser.Rut y, si no viene, usa el RUT guardado en el login del dispositivo (visor_secure_auth), formateado (12.345.678-9).
• Modo oscuro: la barra ⚙️ Ajustes y personalización perdía contraste (quedaba igual que las tarjetas). Se le dio un fondo/borde propios en oscuro para que resalte como botón. Archivos: app.css (#perfilAjustesBtn en [data-theme="oscuro"]).
• Archivos: index.html (fila RUT), app.js (poblar #perfilRut). SW v57.

2026-07-09 — Perfil: opciones agrupadas en un desplegable "Ajustes y personalización" (SW v56)

• En Perfil, las opciones Cambiar mi nombre, Notificaciones, Tema de la app y Mis Documentos ahora están dentro de un botón desplegable ⚙️ Ajustes y personalización que las muestra/oculta al tocarlo (chevron que rota).
• Deja el Perfil más limpio: por defecto se ve solo la tarjeta del socio + el botón de ajustes; el resto se despliega bajo demanda.
• Archivos: index.html (botón #perfilAjustesBtn + contenedor #perfilAjustesPanel envolviendo los 4 bloques), app.js (togglePerfilAjustes). SW v56.

2026-07-09 — La administración puede enviar documentos al socio (Mis Documentos) (SW v55)

• Ahora los documentos que la administración sube desde socios-comicion (Documentación → por socio) le aparecen al socio en Perfil → Mis Documentos, junto con los que él mismo subió.
• Los documentos enviados por la administración se muestran destacados (fondo lila + etiqueta "📎 Enviado por administración") y el socio no puede eliminarlos (solo puede borrar los que subió él).
• Sin cambios de esquema: se reutiliza la tabla documentos (categoria='socio', socio_id, subido_por). El socio ya filtra por su socio_id, así que el documento aparece automáticamente.
• Archivos: app.js (renderDocumentos: distingue subido_por ≠ 'socio'). SW v55.

2026-07-07 — Campana de notificaciones en el header (SW v53)

• Nueva campana 🔔 en el header (junto al área/ayuda/salir) con un badge del número de mensajes sin leer de los tres canales.
• Al tocarla despliega un menú con los mensajes sin leer (etiqueta del canal: Soporte / Equipo / Admin, autor, texto y hora).
• Al tocar un mensaje lleva al canal correcto: Soporte→Soporte, Admin→Admin, y Equipo→Equipo abriendo la conversación del socio que escribió (o Chat General si era general).
• No leídos = mensajes de otros posteriores a la última vez que abriste ese canal (marcas _rec_last_seen, _social_last_seen, _admin_priv_last_seen; se inicializan a "ahora" la primera vez para no contar el historial).
• Archivos: index.html (campana + menú), app.js (_getUnread, renderNotifBell, toggleNotifMenu, _irAMensaje; enganchado a los ciclos de refresco). SW v53.

2026-07-07 — Fix: no marcar "conectado" en Telegram al volver tras inactividad (SW v52)

• Bug: al volver a la app después de los 15 min de inactividad, el visibilitychange hacía pingConexion() (enviaba "conectado" a Telegram) antes de verificar la inactividad, mostrando una reconexión falsa cuando en realidad la sesión se cerró por inactividad.
• Fix: al volver, primero se verifica la inactividad; si ya expiró, se cierra la sesión sin enviar "conectado". Además logout() ahora envía la desconexión (logoutConexion) antes de limpiar el usuario, para que Telegram refleje el cierre.
• Archivos: app.js (handler visibilitychange + logout). SW v52.

2026-07-07 — Actualización realmente silenciosa + no vuelve al login (SW v51)

• Bug 1 (volvía al login): al aplicar una actualización, la recarga mostraba el login pidiendo el PIN. Ahora checkSecurity auto-entra si la sesión sigue viva (PIN de sesión en sessionStorage), salvo que haya expirado por inactividad (≥15 min). El cierre por inactividad/manual (logout) ahora borra el PIN de sesión, así tras inactividad sí se pide PIN (seguridad intacta).
• Bug 2 (el aviso reaparecía al Actualizar): se quitó la recarga prematura (fallback de 1200 ms) que recargaba antes de que el nuevo SW activara. Ahora el botón "Actualizar" recarga una sola vez vía controllerchange (con red de seguridad a 3.5 s) y no reaparece.
• Auto-update (15 s): ahora es realmente silencioso — activa el nuevo SW en segundo plano sin recargar; se aplica al reabrir la app. La recarga automática por controllerchange solo ocurre si el usuario tocó "Actualizar".
• Archivos: app.js (checkSecurity auto-login + logout limpia sesión), index.html (_actualizarSilencioso, _aplicarActualizacion, controllerchange guardado). SW v51.

2026-07-07 — Equipo: foto del socio en la lista de contactos y el chat (SW v50)

• Al elegir con quién mensajear en Equipo, la lista de contactos ahora muestra la foto de cada socio (antes solo la inicial), y la barra del destinatario muestra su foto al seleccionarlo.
• En las burbujas del chat Equipo, el avatar del emisor muestra su foto (se identifica por socId). Si el socio no tiene foto, se mantiene la inicial.
• Archivos: app.js (renderUsersList, selectSocialTarget, avatar en renderChat). SW v50.

2026-07-07 — Chat: opción de Cámara y Galería al adjuntar foto (SW v49)

• La barra del chat ahora tiene dos botones: 📷 (Tomar foto — cámara) e 🖼️ (Elegir de galería), en vez de un solo botón que abría solo la galería.
• Archivos: index.html (dos inputs con/sin capture + dos botones), app.js (reset de ambos inputs). SW v49.

2026-07-07 — Enviar y ver fotos en el chat (Soporte, Equipo y Admin) (SW v48)

• El socio ahora puede adjuntar una foto (botón 📷 en la barra del chat) y enviarla en cualquier canal: Soporte, Equipo o Admin. Se sube al bucket público avatares (carpeta chat/).
• Las fotos se ven en las burbujas de los tres canales, ampliables al tocarlas. Incluye las fotos que envía la administración desde socios-comicion (Mensajes/Admin) y las notas de Soporte.
• Interceptor: addNote (Soporte→notas_recaudacion, Equipo→chat_mensajes) y sendAdminMsg (mensajes_admin) ahora guardan/leen foto_url; los mapeos de getNotes/getAdminMsgs devuelven foto.
• Archivos: index.html (botón + preview), app.js (adjuntar/subir/enviar/render), supabase-api.js (handlers). SW v48.

2026-07-07 — Ver foto en las notas de Soporte (SW v47)

• Las notas del administrador (chat Soporte) ahora pueden traer una foto: si la nota tiene imagen, se muestra en la burbuja y se amplía al tocarla (lightbox).
• La foto la adjunta la administración desde socios-comicion (sección Notas). Aquí solo se lee la URL (notas_recaudacion.foto_url).
• Archivos: supabase-api.js (mapea foto en getNotes REC), app.js (render de la imagen en el chat). SW v47.

2026-07-07 — Foto de perfil ampliable al tocarla (SW v46)

• Al tocar la foto de perfil (en Perfil, en el header junto al nombre, y en el login) se abre un lightbox que la muestra en grande. Si no hay foto, tocar el avatar del Perfil abre el menú para agregarla (la inicial se mantiene como siempre si no sube foto — opcional).
• Nuevo overlay #fotoGrandeOverlay + verFotoGrande(), cerrarFotoGrande(), tapPerfilAvatar(), _authFoto().
• Archivos: index.html (overlay + onclicks), app.js. SW v46.

2026-07-07 — El botón "Contactar a La Comisión Propina" solo aparece sin cuenta activa (SW v45)

• Cambio de comportamiento: el botón de WhatsApp del login ahora solo se muestra cuando NO hay una cuenta activa vinculada en el dispositivo (usuario nuevo, pantalla "Vincular Cuenta"). Si el socio ya tiene su cuenta (acceso rápido con PIN) o ya ingresó, el botón desaparece.
• Implementación: el CTA (#loginCTA) arranca oculto y _toggleLoginCTA() lo muestra solo si no existe auth.id en visor_secure_auth. Se re-evalúa en checkSecurity, switchToSetup y cancelRecovery.
• Archivos: index.html (id="loginCTA" + oculto por defecto), app.js (_toggleLoginCTA). SW v45.

2026-07-07 — Notificaciones push al teléfono (SW v44)

• Nueva funcionalidad: el socio puede activar notificaciones push desde Perfil → "Activar notificaciones". Recibe avisos en el teléfono aunque la app esté cerrada para: mensajes del administrador y egresos procesados/rechazados (ambos llegan como mensaje del administrador).
• Arquitectura: Web Push (VAPID) + Service Worker. La suscripción del navegador se guarda en la tabla push_subscriptions (proyecto socios). Un trigger en mensajes_admin (pg_net) llama a la Edge Function push-notify, que envía el push con web-push a las suscripciones del socio.
• iPhone: las notificaciones web requieren que el socio agregue la app a la pantalla de inicio (instalarla como PWA) y la abra desde ahí; iOS no permite push en una pestaña de Safari. En Android/Chrome funcionan directo.
• El SW ahora maneja los eventos push (muestra la notificación) y notificationclick (enfoca/abre la app).
• Nueva diapositiva de ayuda explicando cómo activarlas (incluye el caso iPhone).
• Archivos: sw.js (handlers push + v44), app.js (suscripción + botón + helpSlide), supabase-api.js (savePushSub/deletePushSub), index.html (botón en Perfil). Backend: tabla push_subscriptions, Edge Function push-notify, trigger en mensajes_admin. SW v44.

2026-07-07 — Mensajes privados del Administrador (SW v43)

• Nueva funcionalidad: en la pestaña Mensajes se agregó un tercer modo "Admin" 🛡️ con la conversación privada entre el socio y la administración (solo ese socio la ve). El socio puede leer y responder.
• Muestra un punto rojo en la pestaña "Admin" y en el ícono de Mensajes del nav cuando hay un mensaje nuevo del administrador.
• Se implementó como un modo aislado (renderChatPriv/handleSendPriv/refreshAdminPriv) para no tocar la lógica de Soporte/Equipo.
• Los mensajes que envía el responsable desde socios-comicion → 💬 Mensajes aparecen aquí.
• Nueva diapositiva de ayuda explicando la pestaña "Admin".
• Fuente: nueva tabla mensajes_admin (proyecto socios, RLS anon, realtime).
• Archivos: index.html (botón modo + dot), app.js (render/send/refresh privados + helpSlide), supabase-api.js (acciones getAdminMsgs/sendAdminMsg). SW v43.

2026-07-07 — Guía de ayuda: botones "Recaudación del Día" y "Solicitar Egreso" (SW v42)

• Se agregaron 2 diapositivas a la guía (helpSlides), después de "Anticipos y Descuentos":
  1. Registrar la Recaudación del Día — explica el botón morado del Balance: categorías, fecha, monto y divisor opcional.
  2. Solicitar un Egreso (anticipo) — explica el botón celeste: pedir un anticipo con monto y motivo, el estado "pendiente" y cómo termina reflejado en el Balance.
• Cada diapositiva incluye su preview visual acorde al estilo de la guía.
• Archivos: app.js (helpSlides). SW v42.

2026-07-07 — Solicitud de Egreso (anticipo) desde la app (SW v41)

• Nueva funcionalidad: en el Balance, junto a "Recaudación del Día", se agregó el botón "Solicitar Egreso". Abre un modal donde el socio ingresa un monto y un motivo opcional, y envía la solicitud de anticipo de propina.
• La solicitud se guarda como PENDIENTE en la tabla solicitudes_egreso (proyecto socios). En la app queda una tarjeta de estado ("Egreso solicitado · pendiente") mientras la administración no la procese.
• En socios-comicion → Anticipos y Ausencias aparece un aviso con los egresos pendientes; al tocar uno, se abre el socio con el monto pre-cargado para registrar el anticipo. Al registrarlo, la solicitud pasa a PROCESADO (realtime).
• Archivos: index.html (botón + modal + tarjeta estado), app.js (abrirModalEgreso, enviarEgreso, renderEgresoEstado), supabase-api.js (acciones solicitarEgreso y miSolicitudEgreso). Nueva tabla Supabase solicitudes_egreso (RLS anon, realtime). SW v41.

2026-07-07 — Guía de ayuda: nuevas diapositivas de las últimas funciones (SW v40)

• Se agregaron 4 diapositivas a la guía (helpSlides), entre "Perfil" y "Seguridad":
  1. Tu Foto de Perfil — cómo subir foto desde cámara o galería y dónde aparece.
  2. Mis Documentos — Envía tu contrato — adjuntar PDF/imagen (contrato u otros), privados.
  3. ¿Por qué me pidieron el RUT? — explica que sirve para recuperar el PIN y para los certificados; se guarda seguro y no vuelve a pedirse.
  4. Personaliza tu App — Temas — elegir Claro / Oscuro / Rosa, guardado en el dispositivo.
• Cada diapositiva incluye su preview visual acorde al estilo de la guía.
• Archivos: app.js (helpSlides). SW v40.

2026-07-07 — Fix: chat legible en tema Oscuro (SW v39)

• Bug: en tema Oscuro las burbujas del chat conservaban colores fijos (fondo claro y color:inherit), por lo que el texto de los mensajes quedaba casi invisible (letras claras sobre burbuja clara).
• Fix: el chat ahora es theme-aware. El fondo del área de mensajes usa --chat-bg por tema (Claro beige, Rosa rosado, Oscuro #0b141a). En Oscuro se agregaron reglas de alta especificidad (#chatMessages ...) que fuerzan estilo tipo WhatsApp dark: burbujas #202c33/#005c4b, texto #e9edef, autor #53bdeb, hora #8696a0, colas, separador de fecha, banner fijado y barra de entrada.
• Se cuidó la especificidad para que el color del autor/hora no fuera pisado por la regla general del cuerpo del mensaje.
• Archivos: app.css. SW v39.

2026-07-07 — Fix: el chat ya no queda en blanco por fallos transitorios de Supabase (SW v38)

• Bug: los handlers getNotes de supabase-api.js (chat Soporte → notas_recaudacion, chat Equipo → chat_mensajes) hacían const { data } = await ... ignorando el error. Si Supabase fallaba un instante (los proyectos tuvieron pausas/restauraciones recientes), la consulta devolvía error y el handler entregaba [], dejando el chat vacío hasta el siguiente refetch exitoso.
• Fix: ambos handlers ahora (1) reintentan una vez ante error y (2) si aun así falla, devuelven los últimos mensajes leídos con éxito (_lastNotasRec / _lastChatSocial) en vez de vaciar el chat. Un hipo transitorio ya no borra la conversación en pantalla.
• Se verificó en Supabase que los datos existen y son legibles por el rol anon: Soporte 59 mensajes, Equipo 4. El tema (Claro/Oscuro/Rosa) no afecta la carga del chat.
• Archivos: supabase-api.js. SW v38.

2026-07-07 — Temas de la app: Claro / Oscuro / Rosa (SW v37)

• Nueva funcionalidad: el usuario puede personalizar la apariencia de la app desde Perfil → "Tema de la app". Tres opciones: Claro (por defecto, el de siempre), Oscuro y Rosa (tema femenino).
• La elección se guarda como memoria en localStorage (propi_tema) y se aplica automáticamente al abrir la app, en cualquier dispositivo donde se haya elegido.
• Cómo funciona: los colores de Tailwind lm-*/wa-* se convirtieron a variables CSS con canales RGB (rgb(var(--lm-x) / <alpha-value>)), conservando los modificadores de opacidad (bg-lm-primary/10). Cada tema redefine esas variables con :root[data-theme="claro|oscuro|rosa"].
• El tema Oscuro además sobreescribe los estilos inline con color fijo (tarjetas #fff, textos #001723, inputs, divisores) mediante reglas de mayor peso, para que Perfil y modales se vean correctamente en oscuro.
• Se aplica el tema antes del render con un script inline en <head> (evita el parpadeo/FOUC) y se actualiza el theme-color de la barra del navegador según el tema.
• Archivos: index.html (config Tailwind con variables, script early-theme, tarjeta selector en Perfil), app.css (variables :root por tema + overrides de oscuro + estilos del selector), app.js (window.aplicarTema, _temaActual, _sincronizarTemaBtns). SW v37.

2026-07-06 — Aviso de nueva versión arriba + auto-actualización a los 15s (SW v36)

• El aviso de "Nueva versión disponible" ahora aparece arriba (antes abajo, tapado por el teclado), con cuenta regresiva de 15s: si el usuario no toca "Actualizar", se aplica sola.
• Muestra un texto de novedades de la versión (APP_NOVEDADES, editable por release).
• El SW ya no hace skipWaiting automático en install: espera el mensaje SKIP_WAITING (del botón o del temporizador) para activar, así no reinicia sin avisar. Fallback de recarga por si no dispara controllerchange.
• Archivos: index.html (banner arriba + lógica 15s), sw.js (install sin skipWaiting + listener de mensaje). SW v36.

2026-07-06 — Aviso informativo: foto de perfil y documentos (SW v35)

• Al abrir la app aparece una vez (por dispositivo) un modal explicando que desde el Perfil pueden agregar su foto y enviar documentos (como el contrato). Botón "Ir a mi Perfil" que abre la sección.
• Se muestra sin encimarse con otros modales (RUT/ayuda). Flag propi_info_perfil_v1.
• Archivos: index.html (modal), app.js (checkInfoPerfil/cerrarInfoPerfil/irAMiPerfil). SW v35.

2026-07-06 — Foto de perfil también en el login y en el header (SW v34)

• La foto del socio ahora se muestra además en el avatar del header (arriba, junto al nombre) y en el avatar del login (acceso rápido), no solo en el Perfil.
• La foto se guarda en el auth local (visor_secure_auth.foto) para poder mostrarla en la pantalla de ingreso antes de cargar los datos.
• Archivos: index.html (id en avatar del login), app.js (_aplicarFotoPerfil cubre header+login, checkSecurity muestra la foto). SW v34.

2026-07-06 — Foto de perfil: elegir entre cámara o galería (SW v33)

• Al tocar el avatar ahora aparece un menú: Tomar foto (abre la cámara, input con capture=user) o Elegir de galería (input sin capture).
• Archivos: index.html (dos inputs + menú), app.js (abrirMenuFoto/cerrarMenuFoto). SW v33.

2026-07-06 — Foto de perfil del socio (SW v32)

• En el Perfil, el socio puede subir su foto (toca el avatar o el botón de cámara). Se muestra como avatar.
• Se guarda en Supabase Storage (bucket público avatares, ruta socio/<id>.<ext>, con upsert que reemplaza la anterior) y la URL pública queda en socios.foto_url. Se refleja en socios-comicion (Gestión de Socios).
• Acción guardarFotoSocio. Archivos: index.html (avatar+cámara), app.js (subirFotoPerfil/_aplicarFotoPerfil), supabase-api.js (map FotoUrl + handler). SW v32.

2026-07-06 — Mis Documentos: el socio adjunta documentos (SW v31)

• En el Perfil se agregó Mis Documentos: el socio puede subir su contrato u otros archivos (PDF/imagen), verlos y eliminarlos.
• Se almacenan en Supabase Storage (bucket privado documentos, base de socios) con metadatos en la tabla documentos. Visibles/recuperables desde socios-comicion.
• Usa dbSV.storage (subida, URL firmada 1h para ver, borrado). Límite 15 MB por archivo.
• Archivos: index.html (apartado en Perfil), app.js (cargar/subir/ver/borrar). SW v31.

2026-07-06 — Modal para pedir el RUT del socio (SW v30)

• Al abrir la app, si el socio aún no tiene RUT registrado, aparece un modal solicitándolo (placeholder 11.111.111-?), explicando que se usará para informes y certificados. Se pre-llena con el RUT de recuperación local si existe.
• El RUT se valida (RUT chileno) y se guarda en Supabase (columna nueva socios.rut) vía acción guardarRutSocio; queda disponible en socios-comicion (Gestión de Socios y Certificados). El evento queda en auditoría.
• Archivos: index.html (modal), app.js (checkRutRequired/submitRut), supabase-api.js (handler + map Rut). SW v30.

2026-07-05 — Auditoría: registrar quién ingresó la recaudación del día (SW v29)

• Al registrar una recaudación desde la app, ahora se escribe un evento en la auditoría de socios-comicion (tabla auditoria de la base de socios, dbSV), con la acción "Registrar Recaudación".
• Guarda quién la ingresó (registrado_por_nombre / registrado_por_id), tipo, fecha, monto y divisor. Aparece en el historial de auditoría de socios-comicion con origen propi.solicitada.
• El registro es no bloqueante (no afecta el guardado de la recaudación si la auditoría falla).
• Archivo modificado: supabase-api.js. SW incrementado a v29.

2026-07-02 — Modal recaudación: dato de Total Puntos y Pts Planta (SW v28)

• En el modal "Ingresar Recaudación del Día" se agregó un recuadro informativo (solo lectura) con Total Puntos y Pts Planta, el mismo dato que muestra socios-comicion en Gestión de Socios.
• Se calcula desde allSocios con el mismo criterio que socios-comicion: solo socios visibles/activos (regla del día 15 según FechaInicioPuntos), usando el valor de BD (Puntos) si es > 0 o la fórmula por antigüedad/área si no. Sirve como referencia al ingresar el divisor.
• Nueva función _recCalcTotalPuntos() en app.js; se actualiza al abrir el modal.
• SW incrementado a v28 por cambios en app.js e index.html.

2026-07-02 — Fix: el divisor no se guardaba en Supabase al registrar recaudación (SW v27)

• Bug: al ingresar una recaudación del día con divisor, el handler addRecaudacion de supabase-api.js insertaba solo id, fecha, tipo, monto en la tabla recaudaciones e ignoraba por completo b.divisor. El divisor vive en una tabla aparte (divisores, una fila por fecha) que el handler get mergea por fecha, pero nunca se escribía ahí. Por eso el divisor no subía a Supabase ni aparecía en las otras apps (diario.propi, socios-comicion) que leen de la misma tabla.
• Fix: addRecaudacion ahora hace upsert en divisores ({ fecha, valor }, on conflict fecha) cuando llega b.divisor > 0. Las tres apps comparten el mismo proyecto Supabase de recaudaciones, así que el divisor ahora se propaga a todas.
• SW incrementado a v27 por cambio en supabase-api.js.

2026-06-24 — Fix: sin divisor no infla el VP (valor punto) (SW v26)

• Bug: al registrar una recaudación sin divisor, el código usaba || 1 como fallback, dividiendo el monto por 1 y sumando el total completo al VP acumulado del socio, dando cifras elevadas e incorrectas.
• Fix: cambiado || 1 → || 0 con guarda if(d > 0) en los dos lugares donde se calcula VP (balance histórico y detalle de ganancias). Sin divisor, el día no contribuye al VP.
• Fix: condición de envío del divisor al GAS cambiada de > 1 a > 0, permitiendo guardar divisores válidos como 1 ó 1.5 que antes se descartaban.
• SW incrementado a v26 por cambio en app.js.

2026-06-20 — Fix: balance lento — getDiasPartTime dejó de bloquear el Promise.all (SW v24)

• Bug: el fix anterior de días PT hacía Promise.allSettled([Supabase, GAS]) bloqueante. El Promise.all del balance en app.js esperaba al más lento (GAS: 2-5 s) antes de mostrar cualquier dato.
• Fix: getDiasPartTime ahora responde inmediatamente con datos de Supabase. GAS va en background solo en la primera carga de sesión; si detecta socios PT faltantes en Supabase, los guarda en un cache de sesión y dispara un refresh único para actualizar el balance. En cargas posteriores del mismo sesión usa el cache sin volver a llamar GAS.
• SW incrementado a v24 por cambio en supabase-api.js.

2026-06-20 — Fix: socios Part-Time sin días trabajados en el calendario (SW v23)

• Bug: getDiasPartTime en supabase-api.js leía SOLO Supabase. Si la tabla dias_pt no tenía todos los socios PT (porque no habían guardado días desde la nueva app), aparecían con 0 días → sin calendario ni alcance.
• Fix: fetch paralelo GAS + Supabase. GAS es la base (cubre todos los socios PT con su historial completo); Supabase anula GAS solo para socios que actualizaron días desde la app (datos más recientes). El resultado es la unión correcta de ambas fuentes.
• SW incrementado a v23 por cambio en supabase-api.js.

2026-06-19 — Rendimiento: balance instantáneo, migración automática anticipos a Supabase (SW v22)

• getSaldosCierre ya no bloquea el Promise.all del balance: retorna {} inmediato (o caché 24h) y recalcula el balance en background cuando llegan los datos de GAS.
• getAllDataDesdeSheets ahora migra anticipos/extras desde Sheets a Supabase la primera vez que detecta Supabase vacío (_migrarASupabase). A partir de entonces, Supabase es la fuente primaria.
• SW incrementado a v22 para forzar recarga del interceptor actualizado.

2026-06-19 — Fix: anticipos aparecen en Últimos Movimientos (SW v21)

• Bug: supabase-api.js no tenía fallback a GAS cuando la tabla anticipos de Supabase está vacía (anticipos aún en Google Sheets). getAllDataDesdeSheets devolvía datos vacíos y la sección "Últimos Movimientos" quedaba en blanco.
• Fix: si Supabase devuelve 0 anticipos y 0 extras, se llama al GAS original como respaldo. Cuando los anticipos migren a Supabase se usará esa fuente automáticamente.
• SW v21: incrementado por cambio en supabase-api.js.

2026-06-17 — Hardening de seguridad: XSS, autenticación y SRI (SW v20)

• C-1 (CRÍTICA): PIN eliminado de localStorage. Ahora se guarda solo el hash SHA-256 del PIN; el PIN plano va a sessionStorage (se borra al cerrar el navegador). Compatibilidad backward: instalaciones antiguas piden login completo en nueva sesión.
• C-2 (CRÍTICA): Chat renderizado — linkify() ahora escapa HTML entities antes de convertir URLs, bloqueando inyección de HTML/JS en mensajes del chat.
• C-3 (CRÍTICA): onclick del botón editar ya no embebe msgContent en el atributo. Se usa window._chatMsgMap para lookup por ID, eliminando template injection.
• C-4 (CRÍTICA): showDebugToast escapa todos los valores del objeto API antes de insertarlos en innerHTML.
• A-4 (ALTA): linkify() bloquea protocolos javascript: y data: en URLs.
• A-5 (ALTA): document.write() del comprobante PDF escapa nombre, área y contrato del usuario.
• A-1 (ALTA): Supabase JS anclado a versión 2.49.4 con atributo integrity SHA-512 (SRI).
• SW v20.

2026-06-17 — Historial anticipos: GAS único para archivados, elimina duplicados (SW v19)

• Bug: combinar GAS + Supabase duplicaba meses porque GAS usa "MAYO_2026" y Supabase "MAYO 2026".
• Fix: histórico archivado viene solo del GAS (cacheado 1h); Supabase solo provee anticipos activos del mes actual.
• Una sola fuente por tipo de dato → sin conflictos de naming ni duplicados.
• SW v19.

2026-06-17 — Historial anticipos: combinar Supabase + GAS para cubrir meses faltantes (SW v18)

• Bug: Supabase solo tenía meses migrados inicialmente; meses posteriores estaban solo en Sheets.
• El fallback a GAS solo activaba si data.length === 0, así que meses parcialmente migrados quedaban incompletos.
• Fix: getHistorialCompletoSocio ahora combina SIEMPRE Supabase + GAS (cacheado 1h). GAS es la base completa; Supabase sobreescribe los períodos que ya tiene.
• Para completar la migración: correr backfillAnticiposFaltantes() en el GAS editor (migrate_to_supabase.gs).
• SW v18.

2026-06-17 — Migración completa a Supabase: saldos e historial anticipos (SW v17)

• getSaldosAnteriores ahora lee de saldos_socio en Supabase (67 filas, fuente de verdad); GAS solo como fallback si Supabase está vacío.
• getHistorialCompletoSocio ahora lee de anticipos_historial en Supabase (256 filas) + anticipos activos; GAS solo como fallback si no hay datos para el socio.
• Políticas RLS SELECT/INSERT creadas en Supabase para anon key sobre anticipos_historial y saldos_socio.
• SW actualizado a v17.

2026-06-17 — Anticipos Anteriores: historial desde Google Sheets vía GAS (SW v16)

• Bug: la sección "Anticipos Anteriores" siempre aparecía vacía porque leía de anticipos_historial en Supabase, que nunca se pobla (el archivado va a Google Sheets).
• Fix: getHistorialCompletoSocio en supabase-api.js ahora llama al GAS (getHistorialCompletoSocio), que lee todas las hojas Anticipos_* y AnticiposGuardados en Google Sheets.
• Los anticipos activos del período actual siguen leyéndose de Supabase; ambas fuentes se combinan.
• Caché localStorage con TTL 1 hora para el GAS; en cargas posteriores es instantáneo y se refresca en background.
• SW actualizado a v16.

2026-06-17 — Saldo Anterior: caché local + GAS en background (SW v15)

• Fix de rendimiento: getSaldosAnteriores y getSaldosCierre ahora usan caché localStorage (TTL 24h).
• Primera carga: espera el GAS una sola vez. Cargas siguientes: instantáneas desde caché.
• El GAS se refresca en background en cada visita para mantener el dato actualizado.
• SW actualizado a v15 para distribuir el nuevo supabase-api.js.

2026-06-17 — Saldo Anterior sincronizado con socios-comicion

• Bug: getSaldosAnteriores leía de Supabase (saldos_socio) que podía estar desactualizado; getSaldosCierre retornaba vacío.
• Fix: ambas acciones ahora pasan directamente al GAS real (misma fuente que socios-comicion), que lee las hojas "SaldosAnteriores" + "SaldosCierreMes".
• Resultado: "Saldo Anterior" en propi.solicitada = "Saldo Mes Ant." en socios-comicion para el mismo socio.

v19 — Junio 2026

2026-06-15 — Puntos consistentes entre perfil y balance; fallback a fórmula si Supabase tiene 0

• Bug: perfil mostraba 0 pts cuando Supabase tenía puntos=0 (dato incorrecto); balance seguía con fórmula → inconsistentes.
• Fix: ambos (perfil línea 293 y balance línea 545) usan currentUser.Puntos de Supabase solo si es > 0; si no, caen a fórmula.
• Esto garantiza que datos incorrectos en Supabase no rompan la visualización.
• SW actualizado a boveda-personal-v14.

2026-06-15 — Perfil muestra puntos desde Supabase, no recalculados por fórmula

• Bug: el perfil calculaba pts = 4 + (años × 2) localmente, ignorando currentUser.Puntos de Supabase.
• Fix: usa currentUser.Puntos si está definido; solo cae a fórmula si el campo viene vacío (socios sin dato en Supabase).
• SW actualizado a boveda-personal-v14.

2026-06-15 — Cierre por inactividad corregido (primer y segundo plano)

• Bug: el timer solo se activaba al ir al segundo plano; si la app quedaba abierta e inactiva en primer plano nunca cerraba.
• Fix: reemplazado por sistema de timestamp en localStorage (propi_last_active), actualizado en cada click/touch/scroll/key. Un setInterval de 60 s verifica si pasaron 15 min desde la última interacción → cierra sesión. Al volver de segundo plano también verifica inmediatamente.
• SW actualizado a boveda-personal-v14.

2026-06-15 — Estadísticas muestran período anterior si el actual está vacío

• getActivePeriodo(mapVP): nuevo helper que detecta si el período actual (15→14) tiene datos; si no, usa el período anterior.
• renderStats, renderStatsChart, renderStatsTable: todas usan getActivePeriodo en lugar de getPeriodo directo.
• La etiqueta del período muestra "(período cerrado)" cuando se está mostrando datos históricos.
• SW actualizado a boveda-personal-v11.

2026-06-15 — Service Worker v10 + supabase-api.js en caché

• SW actualizado a boveda-personal-v10.
• supabase-api.js agregado a la lista de precaché del SW (era el único archivo clave sin cobertura offline).
• CLAUDE.md actualizado para reflejar versión actual del SW.

2026-06-14 — Anticipos y extras leen desde Supabase; GAS escribe en Supabase server-side

• Problema raíz: Los anticipos registrados en socios-comicion nunca llegaban a Supabase porque el interceptor browser-side fallaba silenciosamente.
• Solución: backend.gs en socios-comicion ahora escribe en Supabase via UrlFetchApp (server-side) después de escribir en Sheets. Funciones afectadas: registrarBatchAnticipos, registrarBatchExtras, borrarMovimientoGlobal, actualizarAnticipo.
• supabase-api.js en propi.solicitada: getAllDataDesdeSheets y getHistorialCompletoSocio ahora leen de Supabase (tablas anticipos, extras, anticipos_historial) en lugar de pasar a GAS.
• Realtime listener activo para INSERT en tabla anticipos — actualiza la UI automáticamente cuando llega un nuevo anticipo.

2026-06-13 — Fix anticipos anteriores: agrupación por período en Supabase

• Problema: La sección "Anticipos Anteriores" no mostraba datos.
• Causa: El handler getHistorialCompletoSocio en supabase-api.js devolvía un array plano, pero renderHistorialAnticipos espera un array agrupado por período ({ periodo, registros } ).
• Fix: El handler ahora agrupa los anticipos por período (derivado del campo periodo en anticipos_historial, o calculado desde fecha para anticipos actuales), ordenado de más reciente a más antiguo.
• Service Worker actualizado a boveda-personal-v8.

2026-06-23 — Campo divisor opcional en modal Ingresar Recaudación

• Agregado campo numérico "Divisor (opcional)" al modal de ingreso de recaudación del día.
• Si se deja en blanco no se envía al GAS; si se completa, se incluye en el payload addRecaudacion.
• Se limpia automáticamente al abrir el modal.

2026-06-13 — Migración backend Google Sheets → Supabase

• Reemplazado el backend de Google Apps Script (GAS) por Supabase como base de datos.
• Nuevo archivo supabase-api.js: interceptor de window.fetch y navigator.sendBeacon que redirige transparentemente todas las llamadas a las URLs GAS hacia dos proyectos Supabase sin modificar app.js.
  • Proyecto socios (teemahksasdougehrcly): tablas socios, anticipos, extras, saldos_socio, dias_pt, chat_mensajes, historial_conexiones, anticipos_historial.
  • Proyecto recaudaciones (lpulmjzboogixbdxxayo): tablas recaudaciones, divisores, notas_recaudacion.
• index.html actualizado para cargar @supabase/supabase-js@2 (CDN jsdelivr) y supabase-api.js antes de app.js.
• Service Worker actualizado a boveda-personal-v7 para forzar recarga del index.html modificado.
• Los scripts GAS originales se mantienen en gas/code.gs como referencia histórica.

2026-06-01 — Corrección Safe Area iPhone

• Problema: En iPhone con notch/Dynamic Island, el header quedaba detrás de la barra de estado.
• Causa: Las clases .pt-safe-top y .pb-safe-bottom estaban referenciadas en el HTML pero nunca definidas en el CSS.
• Fix: Definidas en app.css:
  • .pt-safe-top { padding-top: calc(env(safe-area-inset-top) + 0.875rem) !important }
  • .pb-safe-bottom { padding-bottom: env(safe-area-inset-bottom) !important }
• Agregado html { height: 100% } y body { height: 100% } para cadena de altura correcta en iOS PWA.

2026-06-01 — Separación HTML / CSS / JS

• index.html separado en tres archivos: index.html (878 líneas), app.css (270 líneas), app.js (2435 líneas).
• originalindex.html: copia completa en un solo archivo, auto-generada por build.sh.
• build.sh: script Python que reconstruye originalindex.html desde los tres archivos separados.
• Hook Claude Code (.claude/settings.json): ejecuta build.sh automáticamente al editar cualquiera de los tres archivos.
• sw.js actualizado a boveda-personal-v6 — ahora cachea app.css y app.js.

2026-05-XX — Filtro por Mes en Anticipos Anteriores

• Nuevo filtro de mes en la sección Anticipos Anteriores del Historial.
• Aparece al seleccionar un año específico (si hay ≥ 2 meses con datos).
• Funciones: _extraerMes, buildFiltroMeses, filtrarAnticiposMes.
• filtrarAnticipos actualizado: ahora resetea y reconstruye el filtro de mes al cambiar de año.

2026-05-XX — Actualización Guía de Ayuda (helpSlides)

• Slide "Balance": texto e imagen actualizados — muestra las dos tarjetas separadas (Remanente y Valor punto por noche), ya no menciona "Mis Puntos".
• Slide "Historial": texto actualizado para explicar el toggle Rendimientos / Anticipos Anteriores.
• Nuevo slide: "Anticipos Anteriores" — explica filtros año/mes y acordeón por período.

2026-05-XX — Filtro por Año y Acordeón en Anticipos Anteriores

• Sección Anticipos Anteriores con filtros pill de año y acordeón por período.
• Lazy-load: datos se cargan solo en la primera apertura de la pestaña.
• Cada período es una tarjeta colapsable con monto total y detalle de registros.

2026-05-XX — Nueva Sección Anticipos Anteriores

• Toggle "Rendimientos / Anticipos Anteriores" en el tab Historial.
• Nueva acción GAS: getHistorialCompletoSocio — combina datos de AnticiposGuardados y hojas Anticipos_*.
• GAS logoutConexion actualizado: borra UltimaConexion en la hoja Socios para garantizar notificación Telegram en el próximo login.

2026-05-XX — Tarjetas Remanente y Valor Punto por Noche

• "Mis Puntos" renombrado a "Valor punto por noche".
• Remanente y Valor punto por noche ahora son tarjetas separadas y más grandes debajo del hero de balance (antes eran chips pequeños dentro de la tarjeta).

2026-05-XX — Script GAS en Repositorio

• gas/code.gs: copia completa del script de Google Apps Script como referencia de código fuente.

2026-05-XX — Mejoras Service Worker

• Estrategia network-first para archivos propios.
• Banner de "Nueva versión disponible" con botón de actualización inmediata.
• Chequeo de actualizaciones en visibilitychange.