taskbot/docs/plan-web-fases.md

Plan de trabajo — Web (SvelteKit) orientado a móvil y acciones de tareas

Contexto y objetivos

• Reforzar la utilidad móvil, mostrar grupos y responsables correctamente, y simplificar acciones prioritarias (completar/undo) manteniendo seguridad (gating) alineada con el backend.
• Mantener el diseño sin truncar descripciones; ofrecer orden por fecha o por grupo; y mostrar TODAS las abiertas en /app/groups.
• Evitar regresiones, con cambios iterativos y fácilmente revertibles.

Decisiones globales

• No truncar descripciones en TaskItem; envolver en varias líneas. Acciones secundarias se desplazan a una segunda línea/menú contextual en móvil.
• “Completar” se promueve como acción principal (checkbox/botón destacado). Incluir “Deshacer completar” con ventana configurable (24h por defecto).
• “Mis tareas” tendrá dos secciones:
  1. Asignadas a mí (todas abiertas).
  2. Sin responsable de mis grupos (todas abiertas).
• “Grupos” mostrará secciones por grupo, con TODAS las tareas abiertas, expandibles/colapsables, y con toggle “Unassigned first”.
• Búsqueda por texto desaparece de la UI (se reserva a futuro si fuese necesaria).
• Orden conmutado por el usuario: Fecha (due asc, NULL al final) | Grupo (agrupación por grupo y dentro por fecha).
• Seguridad: endurecer PATCH de tareas sin grupo para exigir ser responsable (y opcionalmente creador si el esquema lo permite).
• Ventana de uncomplete (deshacer completar): configurable por variable de entorno UNCOMPLETE_WINDOW_MIN (1440 por defecto).

Medición de impacto y riesgos

• N+1 inicial en /app (al agregar “sin responsable” de todos los grupos) tolerable en MVP, mitigado luego con endpoint “overview”.
• Posible crecimiento de DOM en /app/groups: se mitiga con secciones colapsables.
• Cambios de gating en PATCH requieren revisar casos edge (tareas personales sin asignados previos).

Archivos ya disponibles para edición (confirmados)

• UI:
  • apps/web/src/lib/ui/layout/AppShell.svelte
  • apps/web/src/lib/ui/data/TaskItem.svelte
  • apps/web/src/lib/ui/data/GroupCard.svelte
  • apps/web/src/routes/app/+page.svelte
  • apps/web/src/routes/app/+page.server.ts
  • apps/web/src/routes/app/groups/+page.svelte
  • apps/web/src/routes/app/groups/+page.server.ts
• API:
  • apps/web/src/routes/api/me/tasks/+server.ts
  • apps/web/src/routes/api/me/groups/+server.ts
  • apps/web/src/routes/api/groups/[id]/tasks/+server.ts
  • apps/web/src/routes/api/tasks/[id]/+server.ts (PATCH)
  • apps/web/src/routes/api/tasks/[id]/claim/+server.ts
  • apps/web/src/routes/api/tasks/[id]/unassign/+server.ts
  • apps/web/src/routes/api/tasks/[id]/complete/+server.ts
• Infra web:
  • apps/web/src/lib/server/env.ts
  • apps/web/src/lib/server/db.ts
• Núcleo:
  • src/db.ts

Archivos que solicitaremos añadir al chat cuando toque editar

• Documentación: docs/operations.md (para documentar UNCOMPLETE_WINDOW_MIN y notas UX).
• Tests: tests/web/* y tests/unit/* (para cubrir uncomplete y cambios de gating).
• (Opcional) Migraciones: src/db/migrations/* si llegamos a necesitar created_by en gating de PATCH.

Fase 1 — UX base en páginas y TaskItem (sin backend nuevo) — Estado: Completada Objetivos

• /app: añadir sección “Sin responsable de mis grupos”, quitar búsqueda, añadir conmutador de orden (Fecha | Grupo).
• /app/groups: mostrar TODAS las tareas por grupo en secciones expandibles/colapsables; toggle “Unassigned first”.
• TaskItem: mostrar chip de grupo; mantener descripción sin truncar; reorganizar acciones para móvil. Archivos a editar
• apps/web/src/routes/app/+page.server.ts
  • Cargar /api/me/tasks (open, asignadas a mí).
  • Cargar /api/me/groups; para cada grupo, solicitar /api/groups/:id/tasks?onlyUnassigned=true&limit=0 y reunir la lista “unassigned”.
  • Construir map {groupId → groupName} para la UI.
  • Gestionar query param order=due|group.
• apps/web/src/routes/app/+page.svelte
  • Renderizar dos secciones (asignadas y sin responsable). Añadir conmutador de orden. Eliminar campo de búsqueda.
• apps/web/src/routes/app/groups/+page.server.ts
  • En vez de previews, cargar /api/groups/:id/tasks?limit=0 para cada grupo (todas abiertas).
  • Permitir query unassignedFirst=true (por grupo o global).
• apps/web/src/routes/app/groups/+page.svelte
  • Reemplazar cuadrícula de GroupCard por secciones por grupo (cabecera con +/– para colapsar).
  • Dentro de cada sección, lista de TaskItem reutilizando las mismas acciones.
• apps/web/src/lib/ui/data/TaskItem.svelte
  • Mostrar chip con el nombre del grupo si group_id != null; “Personal” si no tiene grupo (usar map pasado desde el server o prop groupName).
  • Promover “Completar” visualmente (sin cambiar aún la API).
• apps/web/src/lib/ui/data/GroupCard.svelte
  • Mantener para posibles resúmenes; la página de grupos dejará de usarla de forma principal. Decisiones
• Orden “por grupo” inicialmente puede agruparse en cliente para el agregado “sin responsable”; “asignadas” ya vienen por fecha. En fases posteriores, endpoint overview dará orden estable en servidor.

Fase 2 — Backend: Uncomplete (24h configurable) + seguridad de PATCH — Estado: Completada Objetivos

• Añadir POST /api/tasks/:id/uncomplete (idempotente) con gating simétrico a /complete y ventana configurable.
• Endurecer PATCH /api/tasks/:id para tareas sin group_id: exigir que el usuario sea asignado (y, si luego confirmamos schema, permitir también si created_by = usuario). Archivos a editar/crear
• apps/web/src/lib/server/env.ts
  • Añadir export const UNCOMPLETE_WINDOW_MIN = ... (leer de env, default 1440). Exponer helper uncompleteWindowMs si conviene.
• apps/web/src/routes/api/tasks/[id]/uncomplete/+server.ts (nuevo)
  • Validar sesión, id, existencia de tarea.
  • Gating:
    • Con group_id: miembro activo de grupo allowed.
    • Sin group_id: debe estar asignado a la tarea.
  • Validar ventana: completed=1 y completed_at >= now - UNCOMPLETE_WINDOW_MIN.
  • UPDATE: completed=0, completed_at=NULL (y opcional completed_by=NULL).
  • Respuesta: status ('updated'|'already'|'not_found'|'forbidden'), tarea resultante.
• apps/web/src/routes/api/tasks/[id]/+server.ts (PATCH)
  • Añadir chequeo cuando group_id IS NULL: exigir que exista asignación del user sobre la tarea (alineado con complete/unassign).
• UI
  • apps/web/src/lib/ui/data/TaskItem.svelte — añadir acción “Deshacer completar” (usando el nuevo endpoint) y toast con feedback.
  • apps/web/src/routes/app/+page.svelte — en la sección “Completadas (24 h)” añadir botón “Deshacer completar”. Documentación y configuración (solicitaremos permiso para editar)
• docs/operations.md — documentar UNCOMPLETE_WINDOW_MIN (minutos; default 1440), semántica e idempotencia.

Fase 3 — Navegación móvil (barra de pestañas) y jerarquía de acciones — Estado: Completada Objetivos

• Evitar que el header rebose en móvil. Añadir barra inferior con iconos (tabs) para Tareas, Grupos, Integraciones (calendario), Preferencias (alarma). Reducir peso visual de “Integraciones” en móvil.
• Consolidar “Completar” como acción primaria (checkbox/botón destacado); otras acciones (Reclamar/Soltar/Editar/Fecha) en segunda línea o menú contextual. Archivos a editar/crear
• apps/web/src/lib/ui/layout/AppShell.svelte
  • Añadir barra inferior sticky (solo en viewport ≤768px), con safe-area, iconos (SVG inline o emojis inicialmente), aria-labels y foco accesible.
  • Mantener header para desktop.
• (Opcional) apps/web/src/lib/ui/icons/* (nuevos)
  • CalendarIcon.svelte, AlarmIcon.svelte, TasksIcon.svelte, GroupsIcon.svelte (si prefieres SVGs en vez de emojis).
• apps/web/src/lib/ui/data/TaskItem.svelte
  • Ajustar layout mobile-first: acciones secundarias y espaciado compacto.

Resultado (implementado)

• En móvil (≤768px):
  • Header de desktop oculto; tabbar inferior con 5 pestañas: Tareas (✅), Grupos (👥), Recordatorios (⏰), Calendarios (📅) y Salir (🚪, POST).
  • Barra superior mínima con título dinámico (“Tareas”, “Grupos”, “Recordatorios”, “Calendarios”), altura 24px y safe-area superior.
  • Iconografía con emojis; icono + texto hasta 768px y solo icono en ≤480px.
  • Safe-area inferior respetado y offset de Toast ajustado para no solapar la tabbar.
• En desktop (>768px):
  • Header visible con navegación renombrada/reordenada: Tareas / Grupos / Recordatorios / Calendarios.
• Accesibilidad:
  • aria-labels en pestañas y logout, estado activo visible, orden de tabulación coherente.
• TaskItem:
  • “Completar/Deshacer” promovido como acción primaria; acciones secundarias (Reclamar/Soltar, Editar, Fecha) en segunda línea compacta en móvil.
  • Descripciones sin truncar, manteniendo legibilidad.
• Integración:
  • Cambios aplicados en AppShell y Toast, evitando solapes y reservando espacio en main.

Fase 4 — Optimización: endpoint “overview” y orden en servidor — Estado: Completada Objetivos

• Evitar N peticiones en /app para el bloque “sin responsable”.
• Servir orden “por grupo” ya resuelto en servidor. Archivos a crear/editar
• apps/web/src/routes/api/me/tasks/overview/+server.ts (nuevo)
  • Respuesta: { assigned: Task[], unassigned: Task[] } (open).
  • Params: order=due|group_then_due (por defecto due).
  • Cada Task incluye: id, description, due_date, group_id, group_name, display_code, assignees[].
  • Gating: igual que /api/me/tasks.
• apps/web/src/routes/api/me/tasks/+server.ts
  • (Opcional) Añadir order=group_then_due y group_name via JOIN; mantener compatibilidad con tests existentes.
• apps/web/src/routes/app/+page.server.ts
  • Consumir overview para reducir llamadas y aplicar el orden de servidor.

Resultado (implementado)

• Endpoint GET /api/me/tasks/overview creado.
• Devuelve assigned y unassigned (abiertas) con order=due|group_then_due (mapeo desde la UI: group → group_then_due).
• En cada tarea: id, description, due_date, group_id, group_name (null en personales), display_code, assignees[] (vacío en unassigned).
• Gating aplicado: assigned según /api/me/tasks; unassigned solo de grupos allowed con membresía activa del usuario; exclusión de personales en unassigned.
• /app/+page.server.ts consume overview para “sin responsable” y elimina el N+1; se mantiene /api/me/tasks para “Mis tareas (abiertas)” con su paginación actual.
• Respuestas con cache-control: no-store.

Fase 5 — Responsables: conteo, marca “tú” y popover con wa.me — Estado: Completada Objetivos

• Mostrar de forma compacta cuántas personas están asignadas; marcar si el usuario actual está entre ellas; listar números y permitir mensaje directo (wa.me) bajo demanda. Archivos a editar/crear
• apps/web/src/lib/ui/data/TaskItem.svelte
  • Badge “Responsables: n” + “tú” si corresponde; al pulsar, abrir popover/modal con lista.
• apps/web/src/lib/ui/feedback/Popover.svelte (nuevo) o reutilizar un modal ligero existente
  • Accesibilidad: rol="dialog", focus trap, cierre con ESC.
• (Opcional) apps/web/src/lib/utils/phone.ts (nuevo)
  • Helpers para abreviar números y construir URL segura wa.me.

Resultado (implementado)

• TaskItem: badge con conteo e indicador “tú”; en ausencia de responsables se muestra botón deshabilitado con icono 🙅.
• Popover accesible (rol="dialog", focus trap, cierre con ESC, restauración de foco) y compatible con SSR.
• Enlaces directos a WhatsApp usando wa.me/<dígitos>, con normalización de números.
• Unificación de UI en escritorio y móvil.
• No se requirieron cambios de backend; los endpoints ya devolvían assignees[].

Fase 6 — Pulido y peso visual de “Integraciones” — Estado: Completada Objetivos (cumplidos)

• Mantener “Integraciones” (renombrada a “Calendarios”) accesible pero con menor jerarquía en móvil.
• Ajustar densidad, estados vacíos y recordar colapsado por grupo en localStorage.

Decisiones aplicadas y resultado

• Etiqueta y jerarquía:
  • La pestaña se renombra a “Calendarios” en navegación de escritorio y tabbar móvil; títulos y aria-labels actualizados.
  • Atenuación en móvil cuando inactiva; estado activo mantiene color primario y foco visible.
• Safe-areas y solapes:
  • Offsets en main y Toast para no solapar con la tabbar; sticky de topbar móvil verificado.
• Estados vacíos:
  • Opción B aplicada: mensajes con pista de acción (“Crea o reclama…” / “Crea una nueva o invita…”).
• Persistencia de colapsado por usuario en /app/groups:
  • Clave localStorage: groupsCollapsed:v1:{userId}.
  • Por defecto: abiertos los grupos con al menos una tarea abierta; colapsados los que no tienen tareas abiertas.
  • Limpieza de IDs obsoletos; restauración en onMount, SSR-safe (sin parpadeos apreciables).
• Accesibilidad:
  • Foco visible en tabs; uso de
    /

    con estado coherente con aria-expanded implícito.

Archivos editados

• apps/web/src/lib/ui/layout/AppShell.svelte (renombrado a “Calendarios”, atenuación móvil, offsets).
• apps/web/src/routes/app/groups/+page.svelte (persistencia de colapsado por usuario + defaults basados en tareas).
• apps/web/src/routes/app/+page.svelte (textos de estados vacíos opción B).
• apps/web/src/lib/ui/feedback/Toast.svelte (offset móvil contra tabbar).

Criterios de aceptación (OK)

• /app muestra dos secciones con todas las tareas requeridas; sin truncar descripciones; orden conmutado.
• /app/groups muestra todas las tareas abiertas por grupo; secciones colapsables; “Unassigned first” operativo.
• Completar y Deshacer completar funcionan desde ambas páginas; ventana de 24h configurable; gating correcto.
• PATCH no permite editar tareas sin grupo si no eres responsable (o creador, si se habilita).
• Navegación móvil no rebosa; barra inferior accesible.
• Asignados: conteo visible, “tú” resaltado y lista en popover con wa.me.

Fase 7 — Densidad y acciones en una sola fila (TaskItem) — Estado: Completada Objetivos

• Compactar la fila de acciones de TaskItem:
  • Convertir el botón/indicador de responsables en “icono + número” sin texto (“personas asignadas” → solo icono + contador), manteniendo aria-label y tooltip accesibles.
  • Ubicar en la misma fila: Responsables (icono+conteo), Reclamar/Soltar, Editar, Fecha.
• Reducir padding vertical excesivo para ganar densidad, manteniendo objetivos de accesibilidad (área táctil ≈44px y foco visible).

Plan de trabajo

1. TaskItem.svelte
   • Sustituir texto “Responsables: n” por icono + n; aria-label dinámico (“n responsables; tú incluido/excluido”).
   • Reorganizar contenedor de acciones para una sola fila en móvil y desktop; permitir wrap en pantallas muy pequeñas si es necesario.
   • Ajustar tamaños (icon-size 16–18px) y gaps a 6–8px.
2. Estilos globales y utilidades
   • Revisar variables de espacio en tokens.css/base.css; reducir ligeramente los márgenes/paddings verticales de:
     • Listas de tareas (ul.list > li o contenedor del TaskItem).
     • Card.svelte (padding vertical).
     • AppShell .main en móvil (si procede).
   • Mantener contraste y focus-visible.
3. QA
   • Verificar que en ≤480px no haya desbordes; que los tooltips/aria sean correctos; y targets táctiles respeten accesibilidad.

Archivos a editar

• apps/web/src/lib/ui/data/TaskItem.svelte (layout de acciones, icono+conteo).
• apps/web/src/lib/styles/base.css (ajustes finos de paddings/gaps).
• apps/web/src/lib/styles/tokens.css (si se decide ajustar variables globales de spacing).
• apps/web/src/lib/ui/layout/Card.svelte (si requiere reducir padding vertical interno).

Criterios de aceptación

• TaskItem muestra todas las acciones en una sola fila en móvil estándar (≥360px) sin saltos.
• El indicador de responsables conserva accesibilidad (aria-label/tooltip) y se entiende su semántica.
• La densidad aumenta perceptiblemente sin comprometer legibilidad ni foco.

Fase 8 — Orden por fecha o por grupo (corrección y alineación) — Estado: Completada Objetivos

• Alinear el comportamiento de “Orden: Fecha | Grupo” con expectativas:
  • Fecha: due_date asc; NULL al final; estable por id.
  • Grupo: agrupar por grupo (Personal al final); dentro de cada grupo ordenar por due_date asc; NULL al final.
• Que el orden seleccionado afecte coherentemente a las secciones relevantes (asignadas y/o sin responsable), evitando inconsistencias entre cliente y servidor.

Plan de trabajo

1. Auditoría actual
   • Revisar apps/web/src/routes/app/+page.server.ts y el consumo de /api/me/tasks/overview.
   • Revisar apps/web/src/routes/app/+page.svelte (groupByGroup/sortByDue) para evitar doble orden contradictorio.
2. Backend
   • apps/web/src/routes/api/me/tasks/overview/+server.ts: asegurar order=due|group_then_due y aplicar NULLS LAST consistente.
   • Añadir tests que validen el orden en ambos modos.
3. UI
   • apps/web/src/routes/app/+page.server.ts: pasar order al backend y confiar en su orden siempre que sea posible.
   • apps/web/src/routes/app/+page.svelte: limitar orden en cliente a casos estrictamente necesarios; evitar reordenar lo ya ordenado por servidor.
4. QA y tests
   • Casos con due_date iguales, NULLs, mezcla de grupos, y tareas personales.

Archivos a editar

• apps/web/src/routes/api/me/tasks/overview/+server.ts
• apps/web/src/routes/app/+page.server.ts
• apps/web/src/routes/app/+page.svelte
• tests/web/* (añadir/ajustar tests de orden)

Criterios de aceptación

• El cambio de orden se refleja de forma predecible y consistente en toda la página /app.
• Tests cubren due_date NULL, empates y orden de grupos (Personal al final).

Resultado (implementado)

• Backend autoritativo: /api/me/tasks y /api/me/tasks/overview aceptan order=due|group_then_due.
• Modo Fecha: due_date ASC con NULL al final; desempate estable por id.
• Modo Grupo: grupos A→Z con “Personal” al final; dentro de cada grupo due_date ASC con NULL al final; desempate por id.
• Gating consistente aplicado en ambos endpoints.
• UI /app:
  • Pasa el parámetro de orden al backend para ambas secciones.
  • Evita reordenar en cliente; solo agrupa visualmente “Sin responsable” cuando order=group.
  • “Mis tareas (abiertas)” respeta el orden recibido (sin agrupar).

Pendiente (futuro opcional)

• Añadir pruebas automatizadas de orden para /api/me/tasks y /api/me/tasks/overview (casos con NULL y empates).
• Si se desea, agrupar visualmente por grupo en “Mis tareas (abiertas)” cuando order=group (solo encabezados; sin alterar el orden).
• Considerar índices adicionales si el dataset crece (p. ej., índices por due_date y group_id) para acelerar ORDER BY.

Fase 9 — Semilla de desarrollo enriquecida — Estado: Completada Objetivos

• Disponer de una BD de desarrollo amplia para probar casos reales:
  • Grupos con y sin tareas; tareas personales; varias tareas sin responsable; tareas con múltiples responsables; tareas completadas recientemente y antiguas; due_dates en pasado/presente/sin fecha.
  • Varios usuarios para validar “tú” y múltiples assignees.

Plan de trabajo

1. Semilla
   • apps/web/src/lib/server/dev-seed.ts: ampliar dataset con:
     • 3–4 usuarios (incluido el por defecto).
     • 4–5 grupos; al menos 1 sin tareas, 1 con muchas tareas, 1 mixto.
     • 25–40 tareas variadas (diferentes due, estados, grupos/personales).
     • Relaciones de asignación múltiples en algunas tareas.
   • Asegurar idempotencia y que no se sobreescriba si ya hay datos.
2. Helpers de test (si procede)
   • tests/web/helpers/db.ts: exponer utilidades para crear fixtures específicas.
3. Documentación
   • Añadir nota en docs/operations.md sobre cómo regenerar BD local y variables relacionadas.

Archivos a editar

• apps/web/src/lib/server/dev-seed.ts
• tests/web/helpers/db.ts (si se añaden utilidades)
• docs/operations.md (documentación de uso de seed)

Criterios de aceptación

• Entorno dev listo tras bootstrap: datos variados y suficientes para probar todas las vistas/secciones.
• Tests pueden apoyarse en fixtures reproducibles.

Resultado (implementado)

• Semilla enriquecida que crea ~30–35 tareas, 5 grupos (allowed/pending), usuarios múltiples y membresías coherentes; incluye tareas personales, sin/uno/múltiples responsables y completadas recientes/antiguas con due variado.
• Idempotente: se ejecuta solo si la tabla tasks está vacía y con DEV_AUTOSEED_DB='true' en desarrollo; usa DEV_DEFAULT_USER numérico cuando está definido.
• Documentación actualizada en docs/operations.md con instrucciones para activar y regenerar la base de datos de desarrollo.

Fase 10 — Completar tarea sin responsable: auto-asignación al completador — Estado: Completada Objetivos

• Resolver el edge case: al completar una tarea sin responsables, debe aparecer en “Completadas (24h)” del usuario y permitir “Deshacer”.
• Mantener gating y trazabilidad coherentes.

Plan de trabajo

1. Backend
   • apps/web/src/routes/api/tasks/[id]/complete/+server.ts:
     • Si la tarea no tiene responsables, añadir (de forma atómica) una asignación al usuario que completa antes de marcar completed=1.
     • Registrar completed_by (si existe) o equivalente.
   • apps/web/src/routes/api/tasks/[id]/uncomplete/+server.ts:
     • Mantener ventana; permitir deshacer si el usuario es responsable (lo será por la auto-asignación) o fue quien completó.
   • apps/web/src/routes/api/me/tasks/overview/+server.ts y/o consultas de “recent”:
     • Asegurar que la consulta de recientes recoge estas tareas asignadas durante el complete.
2. UI
   • apps/web/src/lib/ui/data/TaskItem.svelte:
     • Mensaje de feedback claro al completar una tarea que no tenía responsables (p.ej., “Te has asignado y completado la tarea”).
3. Tests
   • Flujo: tarea sin responsables → complete → aparece en completadas → uncomplete permitido dentro de ventana.

Archivos a editar

• apps/web/src/routes/api/tasks/[id]/complete/+server.ts
• apps/web/src/routes/api/tasks/[id]/uncomplete/+server.ts
• apps/web/src/routes/api/me/tasks/overview/+server.ts (si la consulta de recientes depende de esto)
• apps/web/src/lib/ui/data/TaskItem.svelte (feedback UI)
• tests/web/* (casos de integración)

Resultado (implementado)

• Auto-asignación atómica al completar tareas de grupo sin responsables; se registra completed_by.
• Listado “Completadas (24 h)” incluye estas tareas gracias a la auto-asignación.
• Uncomplete permitido dentro de la ventana configurada, manteniendo la asignación creada.
• Tests de integración añadidos: complete-autoassign-recent, uncomplete-window y carrera de complete (con dos usuarios).

Criterios de aceptación

• Completar una tarea sin responsables la vincula al usuario y aparece inmediatamente en “Completadas (24h)”.
• “Deshacer completar” funciona para ese caso dentro de la ventana configurada.

Notas de implementación y buenas prácticas

• Mantener cabeceras cache-control: no-store en endpoints de listas/acciones.
• Reutilizar el gating ya presente en claim/unassign/complete; factorizar si conviene (pero sin sobre-ingeniería).
• Idempotencia en endpoints de mutación (claim, unassign, complete, uncomplete).
• Evitar dependencias externas para UI; usar SVG inline o emojis como placeholder.
• Accesibilidad: aria-label en iconos, focus visible, roles correctos en popovers/diálogos.

Siguientes pasos

1. Implementar Fase 1 (UI base) con los archivos listados.
2. Implementar Fase 2 (uncomplete + PATCH gating).
3. Validar en móvil; luego abordar Fase 3 (tabs inferiores).
4. Optimizar con overview (Fase 4) y cerrar UX de responsables (Fase 5).
5. Pulido y documentación (Fase 6).

Anexo — Ajustes opcionales futuros (Fase 4)

• Parámetro include=assigned|unassigned|both en /api/me/tasks/overview (por defecto unassigned) para reducir coste cuando solo se necesite una parte.
• Paginación en overview (assigned y/o unassigned) con parámetros page/limit independientes.
• Índices de rendimiento sugeridos (si el dataset crece):
  • CREATE INDEX IF NOT EXISTS idx_tasks_group ON tasks(group_id);
  • CREATE INDEX IF NOT EXISTS idx_tasks_due_open ON tasks(due_date) WHERE COALESCE(completed, 0) = 0;
• Cacheabilidad opcional con ETag/If-None-Match si se añade una versión por usuario; mantener no-store por defecto.