Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/J0S3-LEON/pf_pruebasAseguramientoCalid_SDD/llms.txt

Use this file to discover all available pages before exploring further.

MindFlow’s Task Module gives each student a private workspace for their academic workload. Every task is owned by the authenticated student — the JWT in the request identifies the owner, and the service enforces that ownership on every operation. Attempting to read, update, or delete a task that belongs to another student returns 403 Forbidden without revealing whether the task exists. Tasks are never permanently removed from the database; deletion is always logical, preserving the audit trail of any micro-objectives that were generated during EMA sessions.

​
Student-scoped task CRUD

All task operations extract the studentId from the verified JWT payload attached to request.user by the global JwtAuthGuard. The service then filters every database query by that studentId, so students can only ever see and modify their own data.

Create

POST /api/v1/tasks — creates a new task with a name, optional description, and an ISO 8601 deadline.

List

GET /api/v1/tasks — returns all active (non-deleted) tasks sorted by deadline ascending, with their active micro-objectives included.

Update

PATCH /api/v1/tasks/:taskId — partially updates a task. All fields are optional; only the provided fields are changed.

Soft delete

DELETE /api/v1/tasks/:taskId — sets is_deleted = true on the task and is_audit_only = true on all linked micro-objectives.

​
Creating a task

Send a POST request to /api/v1/tasks with the task details. The name and deadline fields are required. Request body
FieldTypeRequiredRules
namestring✅ YesNon-empty, maximum 255 characters
descriptionstringNoOptional free-text description
deadlinestring✅ YesISO 8601 UTC timestamp (e.g. "2025-08-01T23:59:00Z")
// Create a new academic task
const response = await fetch("https://api.mindflow.app/api/v1/tasks", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${token}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    name: "Submit research essay",
    description: "Write a 3,000-word analysis of cognitive load theory.",
    deadline: "2025-08-01T23:59:00Z",
  }),
});

const { data } = await response.json();
// 201 → { id: "uuid", studentId: "...", name: "Submit research essay", ... }

​
Listing tasks

GET /api/v1/tasks returns all active tasks for the authenticated student, sorted by deadline in ascending order. Each task object includes its active micro-objectives (those with isAuditOnly = false). 
// Fetch the student's active tasks
const response = await fetch("https://api.mindflow.app/api/v1/tasks", {
  headers: { "Authorization": `Bearer ${token}` },
});

const { data } = await response.json();
// data is Task[] sorted by deadline ASC

​
Updating a task

PATCH /api/v1/tasks/:taskId applies a partial update. Only the fields included in the request body are changed; all other fields are left unchanged. 
// Update the deadline of an existing task
const response = await fetch(
  `https://api.mindflow.app/api/v1/tasks/${taskId}`,
  {
    method: "PATCH",
    headers: {
      "Authorization": `Bearer ${token}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      deadline: "2025-08-05T18:00:00Z",
    }),
  }
);

​
Soft delete

DELETE /api/v1/tasks/:taskId marks the task as deleted without removing any data. Both operations happen atomically inside a database transaction:
  1. is_deleted = true is set on the task record.
  2. is_audit_only = true is set on all associated micro-objectives.
The endpoint returns 204 No Content on success.
Hard-delete is not supported. Deletion in MindFlow is always logical (is_deleted = true). Deleted tasks no longer appear in the active task list or the dashboard, but their micro-objectives remain in the database as an audit record and are never removed. This design ensures that fatigue history and decomposition data remain intact even after a task is deleted.

​
Micro-objectives sub-resource

Micro-objectives are generated automatically by the Task Decomposer when a student’s fatigue score is ≥ 4. They are accessible through the task sub-resource endpoints below.

​
List micro-objectives

GET /api/v1/tasks/:taskId/micro-objectives
Returns all active micro-objectives (isAuditOnly = false) for the specified task, ordered by creation time ascending. Returns 403 if the task belongs to another student, 404 if the task does not exist.

​
Mark a micro-objective complete

PATCH /api/v1/tasks/:taskId/micro-objectives/:moId
Send { "isCompleted": true } in the request body to mark a micro-objective as done. The dashboard reflects this change within 2 seconds. 
// Mark a micro-objective as completed
const response = await fetch(
  `https://api.mindflow.app/api/v1/tasks/${taskId}/micro-objectives/${moId}`,
  {
    method: "PATCH",
    headers: {
      "Authorization": `Bearer ${token}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({ isCompleted: true }),
  }
);

const { data } = await response.json();
// 200 → updated MicroObjective object

​
Ownership and access control

The Task Service verifies ownership on every mutating operation. If the studentId extracted from the JWT does not match the studentId stored on the task record, the service throws a ForbiddenException and the API Gateway responds with 403 Forbidden — without disclosing that the task exists for another student.

​
Validation errors

The global ValidationPipe enforces the DTO rules before the request reaches the service layer. Validation failures return 422 Unprocessable Entity with a field-level error message.
ConditionStatus
name is missing or empty422 Unprocessable Entity
deadline is not a valid ISO 8601 string422 Unprocessable Entity
name exceeds 255 characters422 Unprocessable Entity
Task belongs to a different student403 Forbidden
Task ID does not exist404 Not Found

Build docs developers (and LLMs) love

Get started for freeTalk to us