Entregas e informes

Planificación y seguimiento en FXCode: las tareas tienen fecha de entrega, se agrupan en entregas (hitos como «12» o «fase 9»), cada proyecto tiene un informe de estado y el cliente ve cómo van sus solicitudes y la entrega actual, y verifica el trabajo antes de cerrarlo.

Fecha de entrega

Cada tarea puede tener fecha de entrega (dueDate). Es un día, sin hora: se guarda a las 00:00 UTC, así que «vence el 30» es el 30 en cualquier zona horaria.

• Web: selector de fecha en el detalle de la tarea. En la lista y en la tarjeta del Kanban un chip muestra la fecha, marcada como vencida (el día ya pasó y la tarea no está terminada) o próxima (vence hoy o en los 3 días siguientes). Las terminadas llevan el chip neutro.
• Filtro ?due= en GET /tasks, en la barra de filtros y en las vistas guardadas:

Valor	Tareas
overdue	Sin terminar, con fecha anterior a hoy
week	Sin terminar, con fecha de hoy a dentro de 7 días
none	Sin fecha

fxc tasks create -t "Checkout en un paso" --project-id <id> --due 2026-11-30
fxc tasks update <taskId> --due none          # la borra
fxc tasks list --project-id <id> --due overdue

En el API: manda "dueDate": "2026-11-30" (o null / "" para borrarla); vuelve como "2026-11-30T00:00:00.000Z". La importación también acepta dueDate.

Entregas

Una entrega (Release) es de un proyecto y agrupa las tareas que salen juntas.

Campo	Qué es
name	Único en el proyecto: «12», «fase 9», «1.4.0»
targetDate	Día objetivo (opcional)
status	PLANNED (planificada) → IN_PROGRESS (en curso) → DELIVERED (entregada; fecha deliveredAt)
description	De qué va (Markdown)

• Asignar tareas con el selector de entrega del detalle, con las acciones en lote, con fxc tasks update <id> --release <id|nombre> o con releaseId en el API. Una entrega solo admite tareas de su proyecto; mover una tarea a otro proyecto la saca de su entrega. Borrar una entrega deja sus tareas sin entrega.
• Enlazar por versión: si una tarea tiene version y existe una entrega que se llama igual (sin mayúsculas), el detalle sugiere enlazarla, y la vista de la entrega ofrece «N tareas con versión «12» — Enlazarlas» (POST /releases/:id/link-version). La importación enlaza por nombre sola.
• Vista de la entrega (pestaña Entregas del proyecto): avance (% de tareas terminadas; ideas y archivadas no cuentan), desglose por estado y prioridad, y las tareas pendientes y terminadas.
• La entrega actual de un proyecto es la en curso con la fecha objetivo más próxima; si no hay ninguna en curso, la próxima planificada. Una entregada nunca es la actual.

Generar changelog

El botón Generar changelog (POST /releases/:id/changelog, fxc releases changelog) crea el changelog del proyecto con las tareas terminadas de la entrega, reutilizando el módulo de changelogs:

• La versión es el nombre de la entrega (o version si la pasas). Las tareas quedan enlazadas al changelog y la entrega lo recuerda.
• Con IA configurada en el servidor (GOOGLE_GENERATIVE_AI_API_KEY) redacta el texto para el cliente; si no (o si la IA falla) deja un borrador con la lista: novedades y correcciones. Con ai: false / --no-ai siempre sale el borrador.
• Si la entrega no tiene tareas terminadas → 400.
• Si ya existe un changelog borrador de esa versión, se rehace (200); si ya está publicado, no se toca (409).

Después lo revisas y lo envías al cliente como siempre.

Informe de estado del proyecto

GET /projects/:id/report (solo equipo), la pestaña Informe del proyecto y fxc projects report <id> devuelven:

• Avance global: tareas terminadas / total (sin ideas ni archivadas).
• Desglose por estado, prioridad, entrega (con el avance de cada una; también las vacías y «sin entrega») y asignado.
• Vencidas (con los días de retraso) y las que vencen pronto.
• Bloqueadas: sin terminar y bloqueadas por otra sin terminar.
• Terminadas en los últimos 7 y 30 días (por completedAt) y las más recientes.
• Solicitudes de clientes abiertas, y cuántas esperan la revisión del cliente.

En la web hay gráficos sencillos y un botón Exportar Markdown (descargar o copiar). La CLI imprime un resumen, --md el Markdown y --json el informe tal cual; la herramienta MCP project_report devuelve cualquiera de los dos (format: json | markdown).

fxc projects report <projectId>
fxc projects report <projectId> --md > informe.md

Avance en el portal del cliente

En su portal, por proyecto, el cliente ve (GET /projects/:id/client-progress, abierto también a clientes):

• El avance de sus solicitudes: total, abiertas, listas para revisar, por estado.
• La entrega actual: nombre, fecha objetivo y % hecho, y los títulos de las solicitudes de clientes que salen en ella.

Solo devuelve cuentas: los títulos de las tareas internas que no están vinculadas a una solicitud nunca aparecen. La conversación de cada solicitud sigue en los dos sentidos, con adjuntos, como antes. La seguridad la valida el API: un CLIENT no puede abrir entregas, el informe ni las tareas (403).

Verificación del cliente («Lista para revisar»)

«En revisión» funciona como la comprobación del cliente antes de cerrar una solicitud:

1. Una tarea vinculada a la solicitud de un cliente pasa al estado de revisión del proyecto: el elegido en los ajustes de ramas del proyecto (reviewStatusId) o, si no se eligió, el estado que se llama «En revisión» / «In review».
2. La solicitud muestra al cliente Lista para revisar (clientStatus: READY_FOR_REVIEW) y su autor recibe un correo en su idioma. Como todos los avisos de solicitudes, solo se envía cuando cambia lo que ve el cliente.
3. El cliente decide, en la web, con la CLI o con su asistente:
   • Aceptar: la tarea pasa al estado «verificado» del proyecto (clientVerifiedStatusId) o, si no hay, al primer estado terminado; queda fechada como terminada y sale de la cola. La solicitud queda Hecha con verifiedAt. Un comentario opcional entra en la conversación.
   • Pedir cambios, con un comentario obligatorio: la tarea vuelve al primer estado animado («Working») o, si no hay, al primer estado pendiente, y queda la primera de la cola. El comentario entra en la conversación de la solicitud y en los comentarios de la tarea. La solicitud vuelve a En curso.
4. Al cliente no le llega un correo sobre su propia decisión; al equipo sí (ADMIN_EMAIL). Las demás solicitudes vinculadas a la misma tarea la siguen y sus autores reciben el aviso de siempre.

POST /client-requests/:id/verify
{ "decision": "accept" }
{ "decision": "request_changes", "comment": "Faltan las fechas en el Excel" }

• 409 si la solicitud no está lista para revisar (su tarea no está en el estado de revisión).
• 400 si pides cambios sin comentario.

El estado «verificado» se configura en los ajustes de ramas del proyecto (PATCH /projects/:id/branch-settings { "clientVerifiedStatusId": "<statusId>" }; null = el primer estado terminado).

fxc requests verify <requestId> --accept --comment "¡Perfecto!"
fxc requests verify <requestId> --changes "Faltan las fechas en el Excel"

Con el MCP, el cliente (o el equipo en su nombre) usa verify_request con decision: accept | request_changes y comment, y project_progress para ver el avance.

CLI y MCP

fxc releases list --project <id>
fxc releases create --project <id> --name 12 --target 2026-11-30 --status in_progress --description "Pagos y checkout"
fxc releases show 12 --project <id>
fxc releases update 12 --project <id> --status delivered
fxc releases link-version 12 --project <id>
fxc releases changelog 12 --project <id> [--version 1.2.0] [--no-ai]
fxc releases delete 12 --project <id>

fxc tasks update <taskId> --release 12 --due 2026-11-30
fxc tasks list --project-id <id> --release none --due week

Las entregas se nombran por id o por nombre (con el proyecto). Herramientas MCP: list_releases, get_release, create_release, update_release, link_release_version, generate_release_changelog, project_report; create_task / update_task aceptan dueDate y release, y list_tasks filtra por due y release. En el MCP remoto, verify_request y project_progress están también para clientes. Ver CLI y MCP.