# Spec Delta

## Purpose

Provide durable sparepart identities and accurate availability for Inventory, checkout, and future Maintenance consumers.

## ADDED Requirements

### Requirement: Searchable sparepart catalogue
Authenticated users SHALL read active parts with group, kind, manufacturer, unit, minimum stock, and physical, quarantined, and available quantities. Search SHALL match name, product ID, and part number; group and availability filters SHALL compose with pagination.

#### Scenario: Filter and paginate
- **WHEN** a user searches within a group and availability status
- **THEN** rows and total count use identical filters and stable ordering with an ID tie-breaker

### Requirement: Derived availability and summary
Available stock SHALL equal physical minus quarantined. Zero available SHALL be OUT_OF_STOCK; positive available below minimum SHALL be LOW_STOCK; otherwise IN_STOCK. Summary SHALL count all active SKUs and alerts independently of the current page.

#### Scenario: Zero minimum with no stock
- **WHEN** a part has zero available quantity and minimum zero
- **THEN** it is OUT_OF_STOCK and included in the alert count

### Requirement: Controlled master writes
ADMIN/SUPERVISOR SHALL create and update master metadata. Product IDs SHALL be unique under documented case-insensitive normalization; part numbers SHALL NOT be globally unique. Quantity fields SHALL be non-negative integers. Master edits SHALL NOT overwrite balances. Public DTOs SHALL omit financial fields.

#### Scenario: Duplicate product ID
- **WHEN** an authorized user creates a product ID differing only in case from an existing reserved ID
- **THEN** the API returns 409 without partial master or stock writes

#### Scenario: Stock entered during creation
- **WHEN** a part is created with positive initial stock
- **THEN** master, balance, posted receipt, and audit commit together or all roll back

### Requirement: Single-room operations
Stock operations SHALL select the internal room automatically and SHALL NOT require a client location or rack input. Existing consumer files SHALL remain unchanged unless separately authorized. Any database change needed for consumer compatibility SHALL be presented for confirmation before implementation.

#### Scenario: Checkout without location
- **WHEN** a valid checkout omits location and rack
- **THEN** the server resolves the room balance without asking the user to choose a location

### Requirement: Historical identity protection
Archived masters SHALL remain readable in referenced history and SHALL be excluded from new checkout. A unit change after posted movements SHALL be rejected to preserve quantity meaning.

#### Scenario: Unit edited after usage
- **WHEN** a part with posted movements is changed from Pcs to Set
- **THEN** the API returns a state conflict and retains the original unit