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

- **2026-08-16/17: mecánica visual reemplazada (MotherDuck), colores de identidad UABC conservados.** El sistema de diseño adoptó la mecánica neobrutalista de un brief externo fijado por el usuario (estilo MotherDuck: "crayon-coded terminal on cream paper" — tipografía mono, radio 2px, sombra dura única, canvas crema) — ver `DESIGN.md` para los tokens completos. La primera pasada también reemplazó los colores de acción por la paleta literal del brief (azul/naranja); el usuario corrigió esto el 2026-08-17: **la paleta institucional UABC (verde `#00723F` primario, dorado `#DD971A` secundario) es la identidad de color activa**, llevada dentro del lenguaje visual nuevo — no reemplazada por él. Verde institucional es lo bastante oscuro para requerir texto blanco (no carbón) en los rellenos, a diferencia del azul claro del brief original.
- Paleta activa: canvas crema `#f4efea`, superficie blanca `#ffffff`, tinta carbón `#383838` (nunca negro puro), acción primaria verde institucional `#00723F` (texto blanco), acento secundario dorado UABC `#DD971A` (texto carbón), 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.