[Feature]: Task Model + Basic CRUD API for Tasks Module

[ruhelamahi7-code]

Before submitting

• I have searched existing issues and discussions to make sure this idea is not already covered.
• I have read the contribution guidelines.

Problem statement

The server/modules/tasks/ module is scaffolded (per the README roadmap) but currently empty. There's no Task model or API to create, read, update, or delete tasks, which blocks any task management functionality on the frontend.

Proposed solution

Implement the foundational layer only, following the existing module pattern (see server/modules/user/ or server/modules/codeforces/):
Task Mongoose model with core fields: title, description, category, priority, status, deadline, createdAt, updatedAt, linked to User by userId
routes.js, controller.js, service.js, repository.js, validation.js for the module
Endpoints:
POST /api/tasks — create a task
GET /api/tasks — list current user's tasks
GET /api/tasks/:id — get single task
PUT /api/tasks/:id — update task
DELETE /api/tasks/:id — delete task
Zod validation schemas for request bodies
Protected by existing authMiddleware

Alternative solutions considered

Building the full task system (AI suggestions, Kanban, calendar, streaks) in one PR — rejected as too large for a single reviewable PR; better delivered incrementally.

Use case or motivation

Unblocks the Tasks Module roadmap item and gives the frontend a real API to build the Tasks UI against, incrementally.

References or mockups

Existing pattern: server/modules/user/ (routes → controller → service → repository → validation)

Additional context

Happy to follow up with status/statistics endpoints and frontend TasksPage as separate issues once this lands, to keep each PR reviewable.

[ruhelamahi7-code]

Hi @kunalverma2512, I'd like to work on this.
I've already contributed to CodeLens (GitHub Integration Info Page, Codeforces Integration Info Page, and the reusable Coming Soon modal), so I'm familiar with the module pattern (routes → controller → service → repository → validation) used across auth, user, codeforces, and github.
I'll follow the same structure for the tasks module, scoped to just the model + basic CRUD (create/read/update/delete) as described above.
Could you assign this to me? I'll also confirm the exact Task schema fields with you before starting, in case you have specific ones in mind.

[kunalverma2512]

Hi @ruhelamahi7-code
I was occupied with some work and now codelens have CI/CD checks

firstly thanks for noticing again codelens and I see this is a new suggestion for a feature and I would prefer a communication behind this in out matrix community before allowing it

since its a new feature so i need a in depth knowledge that whats it basically and how its going to interact with current Codelens foundation and whether it will get connected to existing codes and how ?
I need a broader view

Again thanks and waiting for your response

[kunalverma2512]

Hi @kunalverma2512, I'd like to work on this. I've already contributed to CodeLens (GitHub Integration Info Page, Codeforces Integration Info Page, and the reusable Coming Soon modal), so I'm familiar with the module pattern (routes → controller → service → repository → validation) used across auth, user, codeforces, and github. I'll follow the same structure for the tasks module, scoped to just the model + basic CRUD (create/read/update/delete) as described above. Could you assign this to me? I'll also confirm the exact Task schema fields with you before starting, in case you have specific ones in mind.

@ruhelamahi7-code, this looks good overall. One small suggestion:I recommend not mentioning the work you've done previously in this comment. Since the focus is on this issue, bringing up past work doesn't add much value and can make the discussion a bit longer than necessary. It's usually better to keep the assignment request concise and centered on the task itself.

[ruhelamahi7-code]

@kunalverma2512 Totally fair, happy to give a broader view before this gets assigned.
How it fits into the existing foundation:
Task will be a new Mongoose model, referencing User via userId (same pattern as how other user-owned data is linked in the codebase) — it doesn't modify the User model itself.
The module will sit at server/modules/tasks/ (currently scaffolded but empty) and mirror the exact structure already used in server/modules/codeforces/ and server/modules/github/: routes.js → controller.js → service.js → repository.js → validation.js.
Routes will be protected by the existing authMiddleware, same as other authenticated routes — no new auth logic needed.
Validation will use Zod schemas, consistent with how other modules validate input.
This PR is backend-only: model + 5 CRUD endpoints (POST/GET/PUT/DELETE /api/tasks, GET /api/tasks/:id). It does not touch any existing routes, models, or frontend code — so there's no risk of breaking current functionality.

I've shared the broader picture in the Matrix development channel as requested. Let me know if you need any more detail before assigning — happy to clarify further.

[kunalverma2512]

@ruhelamahi7-code Replied on Matrix