# Spec Delta

## Purpose

Provide shared, persistent Pilot Plant categories, equipment, and components with consistent searchable condition summaries.

## ADDED Requirements

### Requirement: Persistent hierarchy
The system SHALL represent categories as plant units, equipment as root assets, and sub-items as children of equipment in the same unit. Every record SHALL have a stable server ID and generated immutable code. Third-level nesting, cycles, and children of archived parents SHALL be rejected.

#### Scenario: Create sub-item
- **WHEN** an authorized user adds a sub-item to active equipment
- **THEN** the server derives its unit and level from the parent and returns a persistent ID
- **AND** another session can read that same record

### Requirement: Protected metadata edits
Authenticated users SHALL read assets. Only ADMIN/SUPERVISOR SHALL create or edit master metadata. Names SHALL be trimmed, nonempty, at most 150 characters, and unique under the database's name comparison within their unit or parent scope. Edits SHALL reject stale versions with 409 and forbidden identity, hierarchy, or audit fields with 422.

#### Scenario: Concurrent duplicate and stale edit
- **WHEN** two requests create the same equipment name within one unit
- **THEN** exactly one succeeds and the other receives 409
- **WHEN** an edit uses an outdated record version
- **THEN** no changes are persisted and the API returns 409

#### Scenario: Viewer mutation
- **WHEN** VIEWER or TECHNICIAN attempts to rename equipment
- **THEN** the server returns 403 even if the request bypasses the UI

### Requirement: Searchable paginated navigation
Lists SHALL follow core API pagination and omit archived units/assets. Unit and equipment search SHALL match unit, equipment, or sub-item names. Condition filtering SHALL apply to equipment; matching units SHALL appear once. Empty units SHALL match ALL or UNKNOWN. The condition chart SHALL summarize all visible active equipment across units, independently of table search and filters.

#### Scenario: Search child name
- **WHEN** a user searches for a matching sub-item name
- **THEN** its equipment and containing unit are discoverable without loading every report into the browser

### Requirement: Consistent condition projection
Equipment SHALL be NOTED when it or its active children have reports in OPEN, ACCEPTED, or IN_REPAIR; otherwise UNKNOWN when it has no active children, and CLEAN otherwise. CLEAN SHALL mean no active reports, not verified healthy. Counts and UI indicators SHALL use this definition. Maintenance timing SHALL be separate from condition.

#### Scenario: Accepted report remains active
- **WHEN** an OPEN report is accepted into a Work Order
- **THEN** the affected equipment remains NOTED until the report is resolved or dismissed

#### Scenario: No child records
- **WHEN** equipment has no active child and no active report
- **THEN** its chart bucket, badge, and signal indicate UNKNOWN rather than healthy

### Requirement: Server-authoritative client data
The frontend SHALL use server DTOs and stable IDs for edits and reports, preserving Indonesian content and English machine codes. Network failures SHALL NOT be presented as successful saves or replaced with demo data. Existing IndexedDB records SHALL NOT be automatically imported or deleted.

#### Scenario: Failed save
- **WHEN** the API rejects an edit
- **THEN** the user sees the failure, retains recoverable form input, and does not see a success notification