auth con avatar

OBSERVATIONS.md

@@ -1,4 +1,4 @@
-# OBSERVATIONS — Sprint 3
+# OBSERVATIONS — Sprint 4
 
 > Hallazgos descubiertos durante el sprint actual.
 > Este archivo se vacía al cerrar el sprint: los hallazgos se promocionan a TECH_DEBT.md o BACKLOG.md, o quedan resueltos.
@@ -18,13 +18,23 @@
 
 ## Hallazgos activos
 
-*(vacío — sprint recién abierto)*
+*(vacío)*
 
 ---
 
 ## Hallazgos resueltos durante el sprint
 
-*(vacío)*
+### [RESOLVED] Web Locks API deadlock en supabase-js v2 — biblioteca colgaba indefinidamente
+
+**Etapa:** 5B (deploy Dokploy)
+**Síntoma:** Biblioteca mostraba 0 procesos. Network tab sin llamadas a Supabase después de la primera carga. Import con timeout de 20s. Aparentemente aleatorio — "la primera vez funciona, después no".
+**Diagnóstico inicial (asesor):** Race condition entre inicialización de sesión async y fetch de procesos. Correcto en dirección pero incompleto en causa raíz.
+**Causa raíz real (Claude Code):** `supabase-js` v2 usa `navigator.locks` (Web Locks API) para coordinar refresh de sesión entre pestañas. Un lock atascado de una pestaña cerrada abruptamente bloqueaba para siempre cualquier llamada futura a `getSession()` o queries. El cliente quedaba en espera indefinida del lock — sin error, sin timeout.
+**Fix aplicado:**
+- `src/lib/supabase.ts`: cambiar a `processLock` (coordinación en memoria, sin Web Locks API)
+- Timeouts con error visible y botón "Reintentar" como red de contención
+**Lección para el método:** Síntomas de race condition (funciona la primera vez, no las siguientes) pueden esconder problemas de locks de sistema. Si el network tab no muestra ninguna llamada cuando debería haberlas, sospechar bloqueo a nivel de cliente antes del request, no solo timing de React state.
+**Estado:** RESOLVED — Etapas 5 y 5B con OK formal del director (2026-06-18)
 
 ---