# Spec Delta

## Purpose

Manage attributed maintenance work from Pilot Plant reports and warehouse quarantine through shared technician execution and auditable completion.

## ADDED Requirements

### Requirement: Approval boundaries
Implementation SHALL obtain explicit approval before modifying existing frontend behavior or database design. The proposal SHALL distinguish confirmed scope from proposed policy; creating planning artifacts SHALL NOT authorize implementation.

#### Scenario: Existing status control changes
- **WHEN** implementation would replace the existing status selector
- **THEN** the user is shown the concrete change and reason and must approve before that component is modified

### Requirement: Work order reads
Authenticated users SHALL read paginated work orders and detail with target identity, source, priority, reporter, lifecycle timestamps, resolution and attributed status history. Search and source/type/status/priority filters SHALL have deterministic ordering. Summary counts SHALL reflect matching records independently of page size. Assignment controls and technician filters SHALL NOT be required.

#### Scenario: Open filtered queue
- **WHEN** a user filters warehouse orders by priority
- **THEN** the list and summary use those filters and expose server pagination

### Requirement: Proposed role policy
Active TECHNICIAN users SHALL start, record and complete eligible work without assignment; privileged users SHALL also execute work. Actors SHALL come from authenticated identity and remain in history. Subject to policy approval, ADMIN/SUPERVISOR SHALL create and cancel work and VIEWER SHALL be read-only. New work SHALL NOT require technician assignment.

#### Scenario: Shared technician execution
- **WHEN** an active technician starts an eligible unassigned order and another completes it
- **THEN** both actions are permitted by lifecycle rules and each actor is recorded separately

### Requirement: Target integrity
Pilot Plant work SHALL reference exactly one active Equipment or Item at creation. Warehouse work SHALL reference an existing quarantine case instead of a checkout or free-text target. Accepted damage reports SHALL preserve their existing unique WO and original reporter.

#### Scenario: Accepted report appears in Maintenance
- **WHEN** a supervisor accepts a Pilot Plant report
- **THEN** its existing generated order appears in the unified queue without creating a duplicate

### Requirement: Controlled lifecycle
Subject to policy approval, work SHALL move OPEN to IN_PROGRESS to COMPLETED, or from an active state to CANCELLED. Completion SHALL require resolution; cancellation SHALL require a reason. Terlambat and Terjadwal SHALL be derived presentation states, not writable lifecycle values. Terminal records SHALL retain history.

#### Scenario: Overdue work remains in progress
- **WHEN** IN_PROGRESS work passes its due time
- **THEN** it remains IN_PROGRESS with an overdue indicator

#### Scenario: Concurrent completion and cancellation
- **WHEN** competing actions target the same active order
- **THEN** only one transition commits and stale input returns a conflict

### Requirement: Report synchronization
Linked Pilot Plant reports SHALL become IN_REPAIR on work start and RESOLVED on successful completion. Cancellation SHALL leave the report ACCEPTED and linked to the same WO. Other active reports on the target SHALL remain unresolved.

#### Scenario: One of several faults is repaired
- **WHEN** one linked order completes
- **THEN** only its report resolves and other active reports still affect target condition

### Requirement: Atomic and retry-safe actions
Each action SHALL commit work changes, required history, related report changes and audit together. Identical committed retries SHALL not create duplicate work or history. Stale edits SHALL be rejected rather than overwrite another user's changes.

#### Scenario: Audit write fails
- **WHEN** a required audit write fails during completion
- **THEN** work and related report remain unchanged