# Workspace Rules – Access & Invitation Policy

- End-user accounts (Role.USER) do NOT have access to the application.
- When a Role.USER account is created, they are added to the database only. No invitation is sent; they are not expected to set a password or sign in.
- Login attempts by Role.USER must be rejected with a generic: "Invalid credentials".
- Invitations and password reset links apply ONLY to admin roles (Role.ADMIN, Role.MANAGER).
- Server endpoints that expose application functionality (users, todos, search, etc.) must require authentication and be restricted to Role.ADMIN and Role.MANAGER.
- UI should not surface invitation actions for Role.USER accounts.

Rationale: Admins/Managers use the app to manage and track end users. Normal users may exist in the system, but they do not interact with the app.

# Team Visibility & Manager Assignment Rules

- Managers can see all Admin accounts. Admins can see other Admins in listings but cannot reassign managers.
- Managers can view Todos assigned to themselves or to Admins that belong to them (i.e., users where `managerId` equals the Manager's `id`).
- Admins can only view Todos assigned to themselves.
- Only Managers can assign or reassign Admins to a Manager. The UI exposes a Manager picker in `components/features/admins/AdminModal.tsx` only when the current user is a Manager and the target role is Admin.
- Backend enforcement:
  - `POST /api/users` and `PUT /api/users/:id` accept `managerId` only for Admin users, and only when the requester is a Manager. When omitted during Admin creation, it defaults to the requesting Manager.
  - `GET /api/todos` and `GET /api/todos/user/:userId` restrict results server-side using requester role: Admin → own Todos; Manager → own Todos + Todos for their Admin team.
  - `GET /api/search` and `GET /api/search/quick` restrict Todo results with the same server-side visibility.

# Role Rename Plan (SUPER_ADMIN → MANAGER)

- Development-only plan: we will destroy the current database and replace `SUPER_ADMIN` with `MANAGER`.
- Prisma schema already defines `enum Role { MANAGER ADMIN USER }`.
- Migration options:
  1) Fast reset (recommended in dev): `npx prisma migrate reset --force` (applies all migrations and runs seed). This drops and recreates the DB with `MANAGER` only.
  2) In-place enum transform (PostgreSQL): create a migration with SQL that maps `SUPER_ADMIN` rows to `MANAGER` and replaces the enum type.
- Invitation policy remains: End users (Role.USER) do not receive invitations; invitations/password reset links only apply to Admin and Manager roles.
