Kaserita
POS + página de inicio + páginas legales de SmartdeskApps. React 18, Vite, Tailwind y Supabase. Se despliega en Vercel desde main en https://kaserita.smartdeskapps.com. La tienda virtual (KaseritaDelivery) es otro repositorio: Kaserita_Delivery.
Desarrollo
npm install
npm run dev # servidor local
npm test # pruebas (Vitest) de la lógica en src/lib
npm run build # build de producción en dist/
La lógica de negocio que se puede probar sola (arqueo de caja, combos, descuentos, validaciones, dashboard, turnos, errores) vive en src/lib/ con su *.test.js. La app principal está en src/main.jsx, el panel de superadmin en src/PanelAdmin.jsx.
Despliegue
- Cada push a
main despliega en Vercel. El comando de build es npm test && npm run build: si una prueba o el build falla, no se despliega y sigue la versión anterior.
- GitHub Actions (
.github/workflows/ci.yml) corre lo mismo en cada push y pull request.
- Después de un cambio importante (arranque, cobro, turno, caja) se repite el recorrido de
PRUEBA_MANUAL.md en la Bodega Demo.
- Las claves de Supabase usadas en el navegador son la URL y la clave publicable; la seguridad la dan las políticas RLS, no el secreto de la clave.
Base de datos (Supabase)
Los cambios de base de datos son archivos .sql en la raíz que se ejecutan a mano en el SQL Editor de Supabase. No hay migraciones automáticas. Casi todos son aditivos (crean tablas o funciones).
| Archivo | Para qué |
|---|
schema.sql, rls_*.sql, seguridad_*.sql | Esquema base y políticas de seguridad por negocio |
errores_app.sql | Registro de errores de la app (ver abajo) |
indices_llaves_foraneas.sql | Índices en llaves foráneas (aviso del asesor de rendimiento de Supabase). Aplicado el 2026-10-27 |
probar_aislamiento_entre_negocios.sql | Prueba (con ROLLBACK) de que un dueño no ve datos de otro negocio. Requiere dos negocios de prueba reales |
revocar_privilegios_anon.sql | Opcional: quita permisos de tabla al rol anon (segunda capa de seguridad) |
Monitoreo de errores
Los errores no controlados del navegador (y las pantallas que se rompen al dibujarse) se guardan en la tabla errores_app y se ven en el panel de superadmin → pestaña Errores, agrupados con su conteo. También llegan ahí los fallos que la app le muestra a la persona (abrir turno, cobrar, registrar pagos, sincronizar ventas sin conexión): el lugar va entre corchetes al inicio, por ejemplo [abrir turno] 42501 …. Se ignoran los errores por falta de internet y por sesión vencida, y no se reportan más de 10 por sesión. No hay servicios externos. No se guardan correos, números largos ni IP. Para activarlo, ejecutar errores_app.sql una vez. Revisar la pestaña después de cada despliegue y cuando un cliente reporte un problema.
Revertir un problema (rollback)
| Qué falla | Cómo revertir |
|---|
| Un commit rompió algo | git revert <commit> y git push. Vercel vuelve a desplegar solo (~2 min) |
| Un despliegue salió mal | Vercel → Deployments → el anterior → Promote to Production (~1 min) |
| Build o pruebas fallan | No hace falta nada: Vercel conserva la versión anterior |
revocar_privilegios_anon.sql rompió un flujo | grant select, insert, update, delete on public.<tabla> to anon; en la tabla afectada |
| Otro SQL ya ejecutado | No tiene rollback automático: usar el backup de Supabase |
Señal para revertir primero y diagnosticar después: /registro o el login del POS falla, o las ventas no se guardan.
Operación
- Los cobros se registran a mano en el panel de superadmin (Yape o enlace de pago de Izipay).
- Una caja abierta por más de 24 horas muestra un aviso para cerrarla.
- Texto de la interfaz en español, tuteo, "negocio" y "Tienda Virtual".
