docs(sprint-5): actualizar OBSERVATIONS/TECH_DEBT/BACKLOG — Etapa 4 documentada, items resueltos marcados, logo PDF corregido
Some checks failed
/ Deploy to Cloudflare Pages (push) Has been cancelled
Some checks failed
/ Deploy to Cloudflare Pages (push) Has been cancelled
This commit is contained in:
13
TECH_DEBT.md
13
TECH_DEBT.md
@@ -47,6 +47,19 @@ en los 3 PDFs. Si hay truncamiento, evaluar:
|
||||
|
||||
## Deuda media — afecta DX o evolución del producto
|
||||
|
||||
### [BACKLOG] `getCurrentUser()` en SupabaseAuthService — sin callers activos
|
||||
**Estado actual:** `SupabaseAuthService.getCurrentUser()` usa `getSession()` directamente (sin timeout, sin processLock workaround). Es la única excepción documentada a la regla — justificada porque necesita el objeto sesión completo, no solo una barrera. Sin callers activos hoy.
|
||||
**Impacto si no se resuelve:** ninguno mientras no tenga callers. Si en el futuro algún flujo llama `getCurrentUser()`, podría colgar el processLock si el servidor no responde.
|
||||
**Solución propuesta:** cuando adquiera callers reales, evaluar si `supabase.auth.getUser()` (token de localStorage, sin lock) es suficiente para ese caso.
|
||||
**Archivos afectados:** `src/auth/SupabaseAuthService.ts` (~línea 27, comentario explicativo presente).
|
||||
**Origen:** OBSERVATIONS Sprint 5 Etapa 1 — ítem prometido que faltaba registrar acá.
|
||||
|
||||
### [BACKLOG] `setTimeout(350)` en ProfileSheet — candidato a limpieza
|
||||
**Estado actual:** `ProfileSheet.handleSave()` difiere `updateUser` 350ms como mitigación de la race condition con Radix. El fix definitivo vive en `src/components/ui/sheet.tsx` (cleanup defensivo de `pointer-events`). El setTimeout es redundante pero inofensivo.
|
||||
**Solución propuesta:** eliminar el `setTimeout`, verificar que el fix en `sheet.tsx` sea suficiente por sí solo.
|
||||
**Archivos afectados:** `src/components/ProfileSheet.tsx`.
|
||||
**Origen:** Sprint 5 Etapa 4G (fix intermedio que quedó al resolverse la causa raíz en 4H).
|
||||
|
||||
### [BACKLOG] E2E specs con Dexie directo — reescribir para Supabase
|
||||
**Estado actual:** `export-pdf.spec.ts` y `validate-dod-etapa4.spec.ts` inyectan datos vía Dexie/IndexedDB directamente. Dexie fue eliminado en Sprint 4 Etapa 4 — estos specs fallan en cualquier entorno donde no exista la DB local del sprint anterior.
|
||||
**Impacto:** 2 specs permanentemente rojos. No bloquean build ni deploy, pero degradan la señal de la suite E2E.
|
||||
|
||||
Reference in New Issue
Block a user