# Product ## 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 - **2026-08-16: identidad visual reemplazada por decisión explícita del usuario.** La paleta institucional UABC verde/dorada (60/30/10) fue retirada del sistema de diseño; se conserva únicamente como posible insumo para una futura marca oficial si el usuario la reintroduce. El sistema actual sigue un brief externo fijado por el usuario (estilo MotherDuck: "crayon-coded terminal on cream paper", neobrutalista) — ver `DESIGN.md` para los tokens completos y su justificación de por qué cada valor se adaptó a una herramienta operativa en vez de un sitio de marketing. - Paleta activa: canvas crema `#f4efea`, superficie blanca `#ffffff`, tinta carbón `#383838` (nunca negro puro), acción primaria azul cielo `#6fc2ff`, acento secundario naranja `#ff9538`, positivo/disponible menta `#38c1b0`, peligro coral `#f38e84` (texto `#a83224` para contraste AA). - Tipografía: JetBrains Mono Variable (sustituto abierto de Aeonik Mono, la fuente con licencia que nombra el brief original), monoespaciada en todo el sistema, tracking 0.02em. - Radios de esquina: 2px en todo — sin píldoras, sin círculos, sin `rounded-full`. Sombra dura única `-6px 6px 0 0` en tinta carbón sobre elementos elevados; superficies densas/repetidas quedan planas con borde. - 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. La estructura de layout (sidebar/dock) no cambió — solo su piel visual. ## 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.