Rediseño impeccable: brand mark, páginas 403/404, DESIGN.md + PRODUCT.md

Rediseño hecho en sesión aparte con el skill impeccable. Se registran
las especificaciones y ajustes visuales al sistema ya en producción.

Añade:
- BrandMark.astro con el escudo/logo del laboratorio.
- Favicon actualizado (svg + ico).
- Páginas propias 403 y 404 consistentes con el sistema visual.
- DESIGN.md y PRODUCT.md documentando decisiones.
- .impeccable/design.json con el design system tokenizado.

Ajusta componentes existentes (modales, autocomplete, layout, login,
solicitudes, mis-préstamos, middleware) para alinearse a los tokens
del design system.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

PRODUCT.md

@@ -0,0 +1,65 @@
+# 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.