# Worker Registration

## Overview

Worker Registration creates a `Worker` — the HR identity record — as a 1:1 extension of an existing `user-management` User. The User owns login identity (email, display name, authentication); the Worker owns period-invariant HR identity, currently a stable `workerCode` that survives login or employee-code changes. Registering a Worker is the prerequisite for everything else in the platform: without a Worker, a person cannot hold an employment, occupy a post, punch time, or request leave.

This separation lets "a User who is not a Worker" (an external partner with a login) and "a Worker without ongoing login needs" both be represented, avoiding the legacy mistake of one `Employee` table mixing login, HR attributes, and role (ADR-002, reframed by ADR-016).

## Business Purpose

- Establish a stable person identity that persists across hire, termination, and re-hire, so history is never fragmented (issue #7 Single Global Person Record)
- Keep login identity (user-management) and HR identity (workforce) separate, each with its own lifecycle
- Provide a `workerCode` that HR and payroll can reference even when the underlying login changes

## Process Flow

```mermaid
flowchart TD
    A[Admin initiates Worker registration for a User] --> B{User exists in user-management?}
    B -- No --> E[Reject: USER_NOT_FOUND]
    B -- Yes --> C{User already has a Worker?}
    C -- Yes --> F[Reject: WORKER_ALREADY_EXISTS]
    C -- No --> D{workerCode unique?}
    D -- No --> G[Reject: WORKER_CODE_TAKEN]
    D -- Yes --> H[Create Worker linked 1:1 to User]
    H --> I[Worker available for employment, assignment, time, leave]
```

## Scenario Patterns

- **First-time registration**: a new hire's User is created in user-management, then a Worker is registered referencing it; employment and assignment follow (see [Employment Management](employment-management.md), [Organizational Assignment](organizational-assignment.md))
- **Re-hire**: a former employee's Worker already exists — registration is skipped and a new WorkerEmployment is opened instead (same person, new employment)
- **User without a Worker**: an external partner keeps a User for login but never becomes a Worker; downstream attendance commands reject with a workforce "no worker" error
- **Attribute correction**: worker code is corrected via update without deleting the Worker or its history

## Test Cases

- registering a Worker for an existing User with a unique worker code succeeds and links 1:1
- registering a Worker for a non-existent User is rejected
- registering a second Worker for a User that already has one is rejected
- registering a Worker with a worker code already in use is rejected
- a Worker is never hard-deleted while employments or downstream records reference it

## Reference Links

- Data-model design research (Worker / Position / Job separation, Single Global Person Record): https://github.com/tailor-sandbox/Omakase-ERP-attendance/issues/7
- Enterprise gap analysis (current attendance lacks person/assignment separation): https://github.com/tailor-sandbox/Omakase-ERP-attendance/issues/9