labre-web/PRODUCT.md

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/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.