Releases and reports

Planning and follow-up in FXCode: tasks get a due date, they’re grouped into releases (milestones such as “12” or “phase 9”), each project has a status report, and the client sees how their requests and the current release are going, and verifies the work before it’s closed.

Due dates

Every task can have a due date (dueDate). It’s a day, without time: it’s stored at 00:00 UTC, so “due on the 30th” is the 30th in any time zone.

• Web: date picker in the task detail. In the list and on the Kanban card a chip shows the date, marked as overdue (the day has passed and the task isn’t finished) or soon (due today or in the next 3 days). Finished tasks show a neutral chip.
• Filter ?due= in GET /tasks, in the filters bar and in saved views:

Value	Tasks
overdue	Unfinished, due before today
week	Unfinished, due from today to 7 days from now
none	No due date

fxc tasks create -t "Checkout in one step" --project-id <id> --due 2026-11-30
fxc tasks update <taskId> --due none          # clears it
fxc tasks list --project-id <id> --due overdue

In the API: send "dueDate": "2026-11-30" (or null / "" to clear it); it comes back as "2026-11-30T00:00:00.000Z". The import accepts dueDate too.

Releases

A release (Release) belongs to a project and groups the tasks that ship together.

Field	What it is
name	Unique within the project: “12”, “phase 9”, “1.4.0”
targetDate	Target day (optional)
status	PLANNED → IN_PROGRESS → DELIVERED (moving to delivered stamps deliveredAt)
description	What it’s about (Markdown)

• Assign tasks with the release selector in the task detail, with bulk actions, with fxc tasks update <id> --release <id|name> or with releaseId in the API. A release can only hold tasks from its own project; moving a task to another project removes it from its release. Deleting a release leaves its tasks without one.
• Link by version: if a task has a version and a release with that same name exists (ignoring case), the task detail suggests linking it, and the release view offers “N tasks with version «12» — Link them” (POST /releases/:id/link-version). The import links by name automatically.
• Release view (Releases tab of the project): progress (% of finished tasks, ideas and archived tasks don’t count), breakdown by status and priority, and the pending and finished tasks.
• The current release of a project is the in-progress one with the nearest target date; if none is in progress, the next planned one. Delivered releases are never current.

Generate changelog

The Generate changelog button (POST /releases/:id/changelog, fxc releases changelog) creates the project’s changelog with the finished tasks of the release, reusing the changelogs module:

• The version is the release name (or version if you pass one). Tasks get linked to the changelog and the release remembers it.
• With AI configured on the server (GOOGLE_GENERATIVE_AI_API_KEY), it writes the text for the client; otherwise (or if the AI fails) it leaves a draft with the list: new features and fixes. Pass ai: false / --no-ai to always get the draft.
• If the release has no finished tasks → 400.
• If a draft changelog for that version already exists, it’s regenerated (200); if it’s already published, it’s not touched (409).

From there you review it and send it to the client as usual.

Project status report

GET /projects/:id/report (team only), the Report tab of the project and fxc projects report <id> return:

• Overall progress: finished / total tasks (no ideas, no archived).
• Breakdown by status, priority, release (with each one’s progress; also empty releases and “no release”) and assignee.
• Overdue (with days late) and due soon.
• Blocked: unfinished tasks blocked by another unfinished task.
• Finished in the last 7 and 30 days (by completedAt) and the most recent ones.
• Open client requests, and how many are ready for the client to review.

On the web there are simple charts and an Export Markdown button (download or copy). The CLI prints a summary, --md the Markdown and --json the raw report; the MCP tool project_report returns either (format: json | markdown).

fxc projects report <projectId>
fxc projects report <projectId> --md --lang en > report.md

Progress in the client portal

In their portal, per project, the client sees (GET /projects/:id/client-progress, also open to clients):

• The progress of their requests: total, open, ready to review, by status.
• The current release: name, target date and % done, plus the titles of the client requests that ship in it.

It only returns counts: titles of internal tasks that aren’t linked to a client request never appear. The conversation on each request stays two-way, with attachments, as before. Security is enforced by the API: a CLIENT can’t open releases, the report or tasks (403).

Client verification (“Ready to review”)

“In review” works as the client’s check before closing a request:

1. A task linked to a client request moves to the project’s review status: the one chosen in the project’s branch settings (reviewStatusId) or, if none was chosen, the status named “En revisión” / “In review”.
2. The request shows the client Ready to review (clientStatus: READY_FOR_REVIEW) and its author gets an email in their language. As with every request notice, it’s only sent when what the client sees changes.
3. The client decides, on the web, with the CLI or with their assistant:
   • Accept: the task moves to the project’s “verified” status (clientVerifiedStatusId) or, if not set, to the first finished status; it’s dated as completed and leaves the queue. The request becomes Done with verifiedAt. An optional comment goes into the conversation.
   • Request changes, with a required comment: the task goes back to the first animated status (“Working”) or, if there’s none, to the first pending one, and it’s placed first in the queue. The comment goes into the request’s conversation and into the task’s comments. The request goes back to In progress.
4. The client gets no email about their own decision; the team is notified (ADMIN_EMAIL). Other requests linked to the same task follow it and their authors are notified as usual.

POST /client-requests/:id/verify
{ "decision": "accept" }
{ "decision": "request_changes", "comment": "The dates are missing from the Excel" }

• 409 if the request isn’t ready to review (its task isn’t in the review status).
• 400 if you request changes without a comment.

The “verified” status is configured in the project’s branch settings (PATCH /projects/:id/branch-settings { "clientVerifiedStatusId": "<statusId>" }, null = the first finished status).

fxc requests verify <requestId> --accept --comment "Perfect!"
fxc requests verify <requestId> --changes "The dates are missing from the Excel"

With the MCP, the client (or the team on their behalf) uses verify_request with decision: accept | request_changes and comment, and project_progress to see the progress.

CLI and MCP

fxc releases list --project <id>
fxc releases create --project <id> --name 12 --target 2026-11-30 --status in_progress --description "Payments and 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

Releases are referenced by id or by name (with the project). MCP tools: list_releases, get_release, create_release, update_release, link_release_version, generate_release_changelog, project_report; create_task / update_task accept dueDate and release, and list_tasks filters by due and release. On the remote MCP, verify_request and project_progress are available to clients too. See CLI and MCP.