## Purpose

Generate useful in-app notifications from actual operational events with explicit recipients and bounded repetition, excluding calibration.

## ADDED Requirements

### Requirement: Operational recipients
The system SHALL notify active ADMIN and SUPERVISOR accounts for pending checkout approval and low stock. It SHALL notify active ADMIN, SUPERVISOR and TECHNICIAN accounts for urgent, overdue and due preventive work orders. Public requester identities SHALL NOT be treated as account recipients.

#### Scenario: Public checkout pending
- **WHEN** a public checkout enters pending approval
- **THEN** active ADMIN and SUPERVISOR users receive one approval notification and the anonymous requester receives no personal inbox entry

#### Scenario: Auto-approved checkout
- **WHEN** an authorized supervisor or admin checkout is approved immediately
- **THEN** no pending-approval notification is generated

### Requirement: Urgent work order event
The system SHALL generate an urgent notification once per non-calibration work order when created urgent or first changed to urgent, for both pilot-plant and quarantine maintenance targets.

#### Scenario: Quarantine urgent order
- **WHEN** a quarantine work order becomes urgent twice
- **THEN** eligible recipients receive only one urgent notification for that order

### Requirement: Scheduled maintenance reminders
The system SHALL check released active non-calibration work orders for overdue timestamps and generated preventive orders due on the current local date. Each kind SHALL occur at most once per work order and due timestamp. Terminal orders and calendar projections SHALL NOT produce reminders.

#### Scenario: Due versus overdue
- **WHEN** a generated preventive order is due today but has not passed its due timestamp
- **THEN** a due reminder can be generated; once its due timestamp has passed, the check generates only the overdue kind

#### Scenario: Completed before check
- **WHEN** a work order is terminal before the reminder eligibility check commits
- **THEN** no new reminder is generated for it

### Requirement: Low-stock notification policy
The system SHALL consider available stock equal to physical stock minus quarantine. Zero available stock or stock below minimum SHALL qualify for a low-stock notification, at most once per part per configured local date. Both stock/threshold changes and scheduled checks SHALL evaluate this condition.

#### Scenario: Repeated checks and next day
- **WHEN** a part stays below minimum across repeated checks and into the next local date
- **THEN** at most one alert is generated on each date regardless of retries or same-day recovery and depletion

#### Scenario: Checkout and quarantine affect availability
- **WHEN** checkout approval or quarantine changes make available stock zero or below minimum
- **THEN** the condition is evaluated even if that operation uses a separate stock update path

### Requirement: Atomic deduplicated generation
The system SHALL persist event notifications and recipients atomically with transactional source events, expose only committed events, and prevent duplicates under retries and concurrent generation. Regenerating an event SHALL NOT restore a recipient-deleted entry. Scheduled checks SHALL be repeatable and observable.

#### Scenario: Concurrent publisher attempts
- **WHEN** two attempts generate the same event identity
- **THEN** at most one notification with its complete recipient set exists

#### Scenario: Transaction rollback
- **WHEN** the source transaction or notification persistence fails
- **THEN** neither the domain change nor its notification is committed

### Requirement: Excluded notification sources
The system SHALL NOT generate calibration, technician-assignment or fictitious synchronization notifications, or send emails in this feature. Inbox polling SHALL NOT generate business notifications. Automatic generation SHALL use active recipients at event time without historical recipient backfill.

#### Scenario: Calibration reaches due date
- **WHEN** a calibration work order passes its due timestamp
- **THEN** this feature generates neither a due nor an overdue notification for it