# Worker

## Description

Worker represents a **person** in the workforce — the stable, identity-level record that persists across every hire, termination, transfer, and re-hire (the "Single Global Person Record" pattern; KING OF TIME's `employeeKey`; issue #7). A Worker is a 1:1 HR extension of a `user-management` User: the User owns login identity (email, display name, authentication), while the Worker owns HR identity and the immutable personal attributes that employment and leave rules depend on.

Worker holds only attributes that do **not** vary by employment period — currently just a stable `workerCode` that survives employee-code reassignment. Time-varying attributes (employment type, work type, organizational assignment) are **not** on Worker; they live on effective-dated `WorkerEmployment` and `Assignment` so that history is preserved (ADR-013, ADR-016). (`birthDate` and `gender` were dropped in issue #39: they were stored but read by nothing — the menstrual-leave gender gate was never wired — so they can be re-introduced when an actual consumer is built.)

Examples: a full-time employee, a re-hired former employee (same Worker, new WorkerEmployment), a board member who is also a Worker.

## Domain Model Definitions

### Model type

Standard

### Command Definitions

Command docs are out of scope for this design phase (ADR-011). Anticipated commands:

- createWorker — register a Worker for an existing user-management User
- updateWorker — correct mutable personal attributes (e.g. worker code); does not delete history

### Query Definitions

- getWorker — retrieve a Worker by id
- getWorkerByUser — resolve the Worker for a given user-management User id
- listWorkers — paginated list of Workers (PaginationInput / buildPaginatedResult conventions)
### Models

- Worker

### Invariants

- Every Worker references exactly one user-management User; `userId` is required and unique (a User has at most one Worker)
- `workerCode` is a stable, human-facing identifier that is unique across Workers and independent of the User's login identity — it must not change when a login email or display name changes
- Personal attributes on Worker are period-invariant: anything that varies by employment period must be modeled on WorkerEmployment or Assignment, not here
- A Worker is preserved for historical integrity; it is not hard-deleted while any WorkerEmployment, Assignment, or downstream time/leave record references it

### Relationships

- **Belongs to User** (user-management): `userId` references the login identity owner (1:1)
- **Has many WorkerEmployment**: one Worker may hold multiple employment relationships over time and across legal entities (re-hire, secondment, concurrent employment)
- **Referenced by AppointmentHistory**: appointment (order) events reference the Worker whose assignment changed
- **Referenced downstream (via Assignment)**: time-tracking, scheduling, and leave-management resolve "whose" through an Assignment that ultimately belongs to this Worker