# 03 Project Memberships, Teams, and Permission Model

## Goal

Implement the first version of project-scoped authorization with direct user permissions, team inheritance, and the base entities needed for future expansion.

## Requirements

- Introduce project-scoped permissions for:
    - `create`
    - `view`
    - `edit`
    - `delete`
- Allow project permissions to be assigned directly to users.
- Introduce teams as first-class entities.
- Allow teams to receive project permissions.
- Allow users to belong to teams.
- Evaluate effective permissions as the union of:
    - direct user permissions
    - team-inherited permissions
- Keep application-level admin access separate from project-scoped permissions.

## Acceptance Criteria

- A user with direct project permission can perform the matching action.
- A user without direct permission but with a team that grants the permission can perform the matching action.
- A user without direct or inherited permission cannot perform the matching project action.
- Admin access remains application-wide and does not depend on project membership.

## Out of Scope

- Complex organization hierarchies
- Per-field permissions
- Temporary permissions or expiry rules