|
|
# Plan somero de cierre de rama — 25-10-18
|
|
|
|
|
|
Objetivo
|
|
|
- Cerrar esta rama asegurando funcionalidad clave, fiabilidad percibida y coherencia de UX, para mergear con main con confianza.
|
|
|
|
|
|
Criterios generales de “listo”
|
|
|
- No romper flujos existentes.
|
|
|
- Feedback claro en interacciones sin cambio visual evidente.
|
|
|
- Estado de UI estable (sin saltos de scroll ni pérdidas de colapso).
|
|
|
- Cobertura mínima en tests para los cambios críticos.
|
|
|
|
|
|
Bloque 1: Bloqueantes para merge (función y confianza)
|
|
|
1) Feeds de calendario (multiusuario)
|
|
|
- Hipótesis: la UI no recibe token en no-admin o no refresca tras rotar; posible gating de backend por rol/sesión.
|
|
|
- Señales de listo:
|
|
|
- No-admin ve/usa su URL tras rotar; .ics responde 200 con contenido válido.
|
|
|
- Rotar invalida el token anterior (URL vieja deja de servir).
|
|
|
- Tests cubren 2 no-admin y 1 admin.
|
|
|
|
|
|
2) Copiar y Rotar (feedback)
|
|
|
- Hipótesis: botones funcionan de forma intermitente y sin feedback; usar toasts existentes.
|
|
|
- Señales de listo:
|
|
|
- Copiar: “URL copiada” o “No se pudo copiar” según resultado.
|
|
|
- Rotar: “Feed de calendario rotado” y la UI actualiza la URL inmediatamente.
|
|
|
- Fallback si Clipboard falla.
|
|
|
|
|
|
3) Estado de colapso y scroll al completar tareas
|
|
|
- Hipótesis: rerender global resetea colapso y reposiciona scroll.
|
|
|
- Señales de listo:
|
|
|
- Completar/descompletar no altera colapso ni posición de scroll.
|
|
|
- Colapso persiste por groupId (localStorage) y tras refresh.
|
|
|
|
|
|
4) Validación: no permitir tareas sin descripción
|
|
|
- Señales de listo:
|
|
|
- Front bloquea envío vacío con mensaje claro.
|
|
|
- API devuelve 400 con error entendible.
|
|
|
|
|
|
5) Modo oscuro en página intermedia de acceso
|
|
|
- Señales de listo:
|
|
|
- Respeta prefers-color-scheme y/o preferencia guardada.
|
|
|
- Sin parpadeo ni estilos rotos.
|
|
|
|
|
|
Bloque 2: Refinamientos UX de bajo riesgo
|
|
|
1) Mensajes para “clics silenciosos”
|
|
|
- Criterio: usar toast solo cuando no hay cambio visible inmediato (copiar, rotar, acciones async).
|
|
|
- Señales de listo: catálogo simple de interacciones con su feedback (info/success/error).
|
|
|
|
|
|
2) Bloquear acciones alrededor durante edición
|
|
|
- Señales de listo:
|
|
|
- Estado “editing” deshabilita acciones peligrosas cercanas (aria-disabled).
|
|
|
- Salir de edición restaura interactividad sin perder foco ni contenido.
|
|
|
|
|
|
3) Animaciones sutiles (colapsar/expandir)
|
|
|
- Señales de listo:
|
|
|
- Transiciones 150–200 ms; respetar prefers-reduced-motion.
|
|
|
- Sin jank en listas largas.
|
|
|
|
|
|
Bloque 3: Navegación y coherencia visual (mini exploración)
|
|
|
1) Unificar tabs entre desktop y mobile (top siempre)
|
|
|
- Idea: tabs arriba en ambos; mini barra superior con sesión y logout.
|
|
|
- Señales de listo:
|
|
|
- Variante elegida (wireframe simple).
|
|
|
- Tokens de densidad definidos (tipografía/espaciado) y patrón de iconografía coherente.
|
|
|
|
|
|
2) Personalidad y densidad
|
|
|
- Pistas rápidas:
|
|
|
- Tipografías y espaciado más compactos en listas.
|
|
|
- Uso consistente del color de grupo.
|
|
|
- Etiquetas concisas e iconos de apoyo.
|
|
|
- Señales de listo: 2 pantallas “antes/después” aprobadas, cambios acotados a tokens/variables.
|
|
|
|
|
|
Bloque 4: Integridad de datos y ciclo de vida
|
|
|
1) Eliminación de grupo
|
|
|
- Propuesta: borrado duro con ON DELETE CASCADE para tareas, asignaciones y tokens; invalidar feeds asociados.
|
|
|
- Señales de listo:
|
|
|
- Contrato decidido y documentado.
|
|
|
- Constraints y tests que demuestran que tareas y feeds desaparecen de UI y endpoints.
|
|
|
|
|
|
2) Crear tareas desde la web (post-merge, MVP)
|
|
|
- Alcance mínimo: descripción obligatoria, fecha opcional, grupo opcional, auto-asignación.
|
|
|
- Señales de listo: validaciones consistentes con el bot.
|
|
|
|
|
|
Riesgos y verificaciones rápidas
|
|
|
- Sesión/locals.userId inconsistentes en no-admin → verificar endpoints de rotar/listar tokens.
|
|
|
- Invalidez de tokens viejos tras rotar → asegurar revocación real y no solo visual.
|
|
|
- Re-renders que destruyen estado local → preservar claves de lista, actualizaciones puntuales.
|
|
|
|
|
|
Métricas y tests mínimos
|
|
|
- Tests web para: rotar token personal en no-admin (200 .ics), copiar con éxito (toast), completar tarea sin perder estado.
|
|
|
- Unit tests: validación de descripción en API.
|
|
|
- Smoke: modo oscuro en página intermedia.
|
|
|
|
|
|
Siguientes pasos inmediatos (quick wins)
|
|
|
- Añadir toasts a Copiar/Rotar y verificar copyToClipboard con fallback.
|
|
|
- Persistir colapso por groupId en localStorage y restaurar en montaje.
|
|
|
- Revisar flujo de tokens ICS con dos usuarios no-admin y un admin (rotar → validar .ics nuevo y caducidad del viejo).
|
|
|
|
|
|
Notas
|
|
|
- La navegación unificada y la “personalidad visual” se abordan después de merge si crecen en alcance.
|
|
|
- Priorizar siempre claridad y facilidad de uso sobre adorno; la forma sigue a la función.
|