Currently, the apps/web/app/services directory contains a mixture of service functions, often organized only by API feature but without a consistent, typed, or scalable structure.
We need to refactor all existing services inside apps/web/app/services into a clean and consistent Object-Oriented Programming (OOP) structure.
In order to improve code maintainability, reusability, and developer experience, we need to refactor these services into strongly typed, Object-Oriented classes following a clear and modern architecture.

This is part of a global initiative to professionalize and modularize Ever Teams codebase.

Task Objectives

You are responsible for:

1. Refactor All Services into Classes and move them in apps/web/core/services

• Convert each service file into a dedicated TypeScript class.

• Each class must extend the base class APIService already available in the project (packages/services/src/api.service.ts) which you can even modify and improve if needed

• Respect Single Responsibility Principle (SRP):
  Each service should cover one domain (ex: authentication, tasks, projects).

2. Conventions to Respect

• The new files must use the naming convention:
  xxx.service.ts (e.g., task.service.ts, auth.service.ts).

• Each service class must have a name following PascalCase:
  e.g., TaskService, AuthService, ProjectService.

• Code must be fully typed: avoid any any except when absolutely necessary.

• Use async/await syntax for all service methods.

• Properly export each service for import elsewhere.

3. Adjust All Dependent Code

• Where old function-based services were used (hooks, components, pages,...), update imports and adapt usage to instantiate and call methods on the new service classes.

• Ensure that no functionality is broken after migration.

4. Folder Structure

After refactoring, the organization should be for example

apps/web/core/services/
  ├── client/
  │   ├── api/
  │   │   ├── auth/
  │   │   │   ├── auth.service.ts
  │   │   │   └── index.ts
  │   │   ├── task/
  │   │   │   ├── task.service.ts
  │   │   │   └── index.ts
  │   │   ├── project/
  │   │   │   ├── project.service.ts
  │   │   │   └── index.ts
  │   │   └── ...
  └── server/
      └── (same principle for server requests)

Each folder groups the related domain services.

Implementation Recommendations

• Start by one service (e.g., auth) to validate the pattern before proceeding.

• Favor small commits domain by domain for easier review.

• Keep PRs focused and atomic (1 service domain = 1 PR if possible).

Constraints

• No business logic should leak into services.

• No components, hooks or pages should manage their own API logic anymore.

• Services must be pure API orchestration layers.