Sprint 5. Etapa 1.

OBSERVATIONS.md

@@ -1,9 +1,9 @@
-# OBSERVATIONS — Sprint 4
+# OBSERVATIONS — Sprint 5
 
 > 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.
 >
-> **Sprint 2 cerrado el 2026-05-20.** Ver cierre en `methodology/CASE_STUDIES/inq-roi-sprint-2.md`.
+> **Sprint 4 cerrado el 2026-06-18.** Observaciones archivadas — ítems migrados a BACKLOG.md y TECH_DEBT.md.
 
 ---
 
@@ -18,29 +18,13 @@
 
 ## Hallazgos activos
 
-### [DEFERRED-BACKLOG] Compartir proceso — implementación real diferida hasta primer guest
-
-**Etapa:** 5 (UI placeholder), decisión confirmada post-Etapa 7B
-**Estado actual:** `setShared()` en `process-repo.ts` es no-op con comentario explicativo. El botón "Compartir con equipo" en LibraryPage muestra toast de confirmación pero no escribe en `process_access`. Todos los usuarios actuales son `platform_admin` y ven todo por bypass de RLS — el sharing no tiene efecto observable hoy.
-**Schema listo:** tabla `process_access (process_id, grantee_type, grantee_id, permission)` + `user_groups` + `group_memberships` + RLS policies que ya usan `process_access` para usuarios no-admin.
-**Trigger para implementar:** cuando se agregue el primer usuario `guest` (cliente externo o consultor externo) a la plataforma.
-**Pendiente al implementar:** (1) UX de selección — ¿compartir con usuario específico, grupo, o "todo el equipo"? (2) implementación real de `setShared()` con escritura en `process_access`, (3) UI de gestión de grupos.
+*(vacío al inicio del sprint)*
 
 ---
 
 ## Hallazgos resueltos durante el sprint
 
-### [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)
+*(vacío)*
 
 ---