Some checks failed
/ Deploy to Cloudflare Pages (push) Has been cancelled
Tier 1 — Automatizado Build: ✅ limpio Lint: ✅ limpio en archivos nuevos de Sprint 4 (separé resource-types.ts de resource-display.tsx para sacar 2 warnings de Fast Refresh; quedan 0 errores/warnings nuevos). Quedó 1 error preexistente en ReportPage.tsx (no tocado desde Sprint 3, fuera de scope) y ~102 warnings no-explicit-any preexistentes en tests viejos. Tests unitarios: ✅ 521/521 verdes Tests E2E: ⚠️ 43-44/48 verdes (varía levemente entre corridas) — detalle abajo Auditoría inicial vs. estado final Antes: 39/39 specs (100%) fallaban — ROJO-AUTH puro, todos por #bpmn-file-input nunca apareciendo (esperaban el flujo pre-Sprint-4 directamente en /). Decisión tomada (con tu input): Opción A — sesión real. Creaste el usuario martin.bernal@inquality.com.py; yo verifiqué que no tenía fila en public.users y se la inserté con platform_role='platform_admin'. Implementé tests/e2e/setup/auth-setup.ts como globalSetup de Playwright: hace signInWithPassword, inyecta la sesión real en localStorage con el formato exacto que usa supabase-js v2, y genera tests/e2e/setup/auth-state.json (gitignored) en cada corrida. Fix adicional necesario: todos los specs navegaban a / esperando el input de archivo ahí — ahora vive en /import. Corregí los 18 page.goto('/') → /import, incluyendo reescribir el flujo obsoleto de prod-smoke.spec.ts (esperaba una landing pre-auth que ya no existe). Resultado: 33→43-44 specs pasan. Quedan 5-6 ROJO-OTRO, con dos causas raíz identificadas (no relacionadas con auth, fuera del mandato de esta etapa que pide no reescribir lógica de tests): Botón "Guardar" en ActivityPanel queda deshabilitado (3 specs de PDF) — encontré algo extraño: el texto del botón dice "Guardar cambios" (que solo se renderiza si isDirty=true) pero Playwright lo sigue viendo disabled. Esto contradice la lógica simple de disabled={!isDirty} en el componente — sospecho un bug real de re-render en producción, pero diagnosticarlo a fondo requiere debugging en vivo. Recomiendo abrir esto como bug dedicado en un sprint futuro. 2 specs usan IndexedDB/Dexie directamente (export-pdf.spec.ts, validate-dod-etapa4.spec.ts) — Dexie se eliminó completamente en Etapa 4. Estos tests necesitan reescritura para inyectar datos vía Supabase en vez de IndexedDB — eso sí es "reescribir lógica de tests", explícitamente fuera de este alcance. Los resultados varían levemente entre corridas porque Playwright corre specs en paralelo bajo la misma cuenta de test compartida — puede haber interferencia de datos entre specs concurrentes. Sugiero como mejora futura (no implementada ahora): --workers=1 para diagnóstico determinístico. Entregables nuevos tests/e2e/setup/auth-setup.ts — global setup con sesión real tests/e2e/sprint-4-smoke.spec.ts — 9 tests (4 sin auth: login, redirects de /, /workspace, /recursos; 5 con auth: biblioteca sin 500, sin 406 en simulations, catálogo carga, avatar visible, import navega a workspace) docs/CHECKLIST_ENTREGA.md — las 4 tiers completas .env.test (gitignored) + .env.example documentado .gitignore actualizado (.env.test, auth-state.json) Polish Textos de OwnershipBadge y "Compartir con equipo" ya estaban en español — sin cambios. Tooltip "Disponible próximamente" para "Compartir con equipo": no lo agregué, tal como pedía el propio brief, consultarte antes. ¿Lo querés?
72 lines
3.8 KiB
Markdown
72 lines
3.8 KiB
Markdown
# 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.
|
|
>
|
|
> **Sprint 2 cerrado el 2026-05-20.** Ver cierre en `methodology/CASE_STUDIES/inq-roi-sprint-2.md`.
|
|
|
|
---
|
|
|
|
## Convención de etiquetas
|
|
|
|
- `[CURRENT-SPRINT]` — Se resuelve en este sprint
|
|
- `[DEFERRED-TECH-DEBT]` — Se va a TECH_DEBT.md al cerrar el sprint
|
|
- `[DEFERRED-BACKLOG]` — Se va a BACKLOG.md al cerrar el sprint
|
|
- `[RESOLVED]` — Resuelto durante el sprint, archivar al cierre
|
|
|
|
---
|
|
|
|
## 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.
|
|
|
|
---
|
|
|
|
## 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)
|
|
|
|
---
|
|
|
|
## Hallazgos diferidos (promocionar al cerrar sprint)
|
|
|
|
*(vacío)*
|
|
|
|
---
|
|
|
|
## Notas operativas
|
|
|
|
- Los hallazgos resueltos quedan acá hasta el cierre del sprint. Al cerrar, se archiva o purga.
|
|
- Los hallazgos sin resolver se promocionan a `TECH_DEBT.md` o `BACKLOG.md` según corresponda.
|
|
- Este archivo NO contiene roadmap futuro ni deuda histórica — solo hallazgos del sprint en curso.
|
|
|
|
---
|
|
|
|
## Cierre del sprint (checklist)
|
|
|
|
Cuando el sprint cierre, ejecutar:
|
|
|
|
```
|
|
[ ] Verificar que todos los items [CURRENT-SPRINT] están RESOLVED
|
|
[ ] Mover items [DEFERRED-TECH-DEBT] a TECH_DEBT.md (si no están ya)
|
|
[ ] Mover items [DEFERRED-BACKLOG] a BACKLOG.md (si no están ya)
|
|
[ ] Archivar o purgar este archivo
|
|
[ ] Crear OBSERVATIONS.md vacío para el sprint siguiente
|
|
```
|