labre-web/PRODUCT.md

# Product

<!-- impeccable:product-schema 1 -->

## Platform

web

## Users

- **Alumno**: estudiante UABC (correo `@uabc.edu.mx`) que solicita préstamo de material del laboratorio para una clase o proyecto. Usa el sistema predominantemente desde el celular — navega el catálogo por categoría, solicita material indicando motivo, y da seguimiento a sus préstamos activos/historial.
- **Admin**: encargado del laboratorio que gestiona solicitudes (aprobar/rechazar/marcar devuelto), mantiene el inventario (materiales/categorías) y consulta reportes/estadísticas. Usa el sistema predominantemente desde escritorio (tablas), con vistas mobile en tarjetas.

Ambos roles son cross-device aunque cada uno tiene un dispositivo primario distinto.

## Product Purpose

Antes de este sistema, el préstamo de material era enteramente manual: petición en papel → captura en una bitácora de Excel → vaciado manual de esa bitácora en reportes finales. El sistema unifica ese flujo en un solo lugar con estado en tiempo real (pendiente → aprobado/rechazado → devuelto), control de stock automático y export de reportes, eliminando la triple captura y su riesgo de errores de transcripción y pérdida de trazabilidad.

Éxito = que el laboratorio deje de depender de papel/Excel para el ciclo completo de préstamo, con historial y reportes confiables generados directamente del sistema.

## Positioning

Herramienta interna de un solo laboratorio (Laboratorio de Sistemas Computacionales, UABC) — no un producto multi-tenant ni una plantilla pensada para otros departamentos. Su ventaja no es competir con otro software: es reemplazar tres capturas manuales redundantes (papel, bitácora Excel, reporte final) por un único flujo trazable con control de acceso institucional (Google OAuth restringido a `@uabc.edu.mx`).

## Operating Context

- Login exclusivo con Google, restringido al dominio institucional `@uabc.edu.mx` (verificado en middleware de aplicación, no en Supabase Auth global — la instancia de Supabase es compartida con otro proyecto).
- Ciclo del préstamo: `pendiente → aprobado → devuelto` (con `rechazado` como salida alterna desde pendiente). El estado `activo` del enum de DB está reservado pero no se usa en el flujo actual — `aprobado` cumple ese rol.
- El stock (`cantidad_disponible`) se ajusta automáticamente vía triggers de base de datos según las transiciones de estado, no en código de aplicación.
- Todo cambio de estado queda en `audit_log` para trazabilidad — esto reemplaza la bitácora en papel/Excel.
- Reportes con filtros (fecha, material, alumno, estado) y export CSV nativo, para cerrar el ciclo que antes terminaba en Excel manual.

## Capabilities and Constraints

- Backend: Supabase self-hosted compartido con otro proyecto (schema `prestamos` aislado de `public`). No se despliega infraestructura nueva de Supabase.
- Auth restringida a `@uabc.edu.mx` en dos capas: trigger en `auth.users` (rechaza altas fuera de dominio) + verificación en middleware de Astro.
- Alta de administradores es manual (Supabase Studio/psql) — no hay flujo de auto-promoción a admin en la UI.
- Hosting propio (buglabs) vía Docker + adapter `@astrojs/node`, detrás de Cloudflare Tunnel.
- v1 sin reglas duras de límite de préstamo o duración — el admin decide caso por caso.

## Brand Commitments

- Paleta institucional UABC bajo regla 60/30/10: primario `#00723F` (verde), secundario `#DD971A` (dorado), superficie `#F4F7F5`, texto `#2D3748`, error `#C53030`.
- Tipografía: Inter Variable.
- La identidad visual usa un glifo propio de producto (`BrandMark`, una ficha/etiqueta con perforación — evoca la ficha de préstamo física) como wordmark gráfico y favicon; no es ni pretende ser el escudo/sello oficial de UABC o del laboratorio. **Existe un logo institucional oficial** pendiente de integrar — el usuario lo proporcionará como asset; hasta entonces no inventar ni aproximar ese escudo.
- Admin es desktop-first, alumno es mobile-first; ambos cross-device. Minimalista, con animaciones ligeras (`motion-safe`).

## Evidence on Hand

- Sin logo oficial entregado todavía (ver Brand Commitments) — no fabricar uno.
- Sin contenido de marketing, testimonios, casos de estudio o cifras de uso real — es una herramienta operativa interna, no una superficie de persuasión.
- El código en `src/` y el schema en `supabase/migrations/0001_init.sql` son la fuente de verdad del modelo de datos y flujos ya implementados.

## Product Principles

1. Un solo flujo digital reemplaza la triple captura manual (papel → Excel → reporte) — cualquier fricción nueva que reintroduzca captura duplicada es una regresión.
2. Estado y stock son siempre reflejo de la base de datos (triggers), nunca de lógica optimista en el cliente — la UI refleja, no decide.
3. Alumno mobile-first, admin desktop-first, ambos cross-device — ninguna vista puede degradarse a inusable en el dispositivo no primario.
4. Acceso gated por dominio institucional en dos capas — cualquier superficie nueva hereda esa verificación, no la reimplementa.
5. Sin dependencias ni infraestructura nuevas salvo pedido explícito — el servidor y el Supabase son compartidos con otro sistema (genqbar).

## Accessibility & Inclusion

WCAG AA no negociable (compromiso establecido en la Fase 2 de diseño). Sin necesidades de accesibilidad específicas de usuarios reales reportadas hasta ahora.