## ADDED Requirements

### Requirement: Paged active device list
The system SHALL provide `GET /api/device-assets` with validated `page` and `size` parameters and optional `deviceName`, `userPersonId`, `userUsageStatus`, and `assetRelationStatus` filters. It MUST return only rows whose `delete_time` is `0`, ordered by descending ID, in the existing `records`, `total`, `page`, and `size` pagination shape.

#### Scenario: Filtered active-device page
- **WHEN** a user requests page 1 with `deviceName` and an approved status filter
- **THEN** the response contains only matching non-deleted device records and their pagination metadata

### Requirement: Readable device response and company-person lookup
The system SHALL return each device's ID, device name, two image access URLs when present, `userPersonId`, resolved `userPersonName`, both status fields, and creation and update times. It MUST NOT return `deleteTime` or a physical file path. The system SHALL provide a read-only company-person lookup endpoint that returns active matching person IDs and names for the device form.

#### Scenario: Missing or deleted device user
- **WHEN** a device has no user person or its referenced person is not active
- **THEN** the device record retains `userPersonId` when present and returns a null user-person name without failing the page

### Requirement: Device creation and update
The system SHALL provide multipart `POST /api/device-assets` and `PUT /api/device-assets/{id}` endpoints. Creation and update MUST require a nonblank device name, reject duplicate active device names, accept only the approved status values, and require an active company person when `userPersonId` is supplied. Update MUST preserve an existing image when no replacement or explicit removal is supplied.

#### Scenario: Create a device with valid approved values
- **WHEN** a user submits a unique device name, optional active user person, and approved usage and relation statuses
- **THEN** the system creates an active device record with creation and update timestamps and returns its readable response

#### Scenario: Reject invalid status or duplicate name
- **WHEN** a user submits an unsupported status value or a device name already used by an active device
- **THEN** the system rejects the request without writing a new or changed device row

### Requirement: Device image attachment handling
The system SHALL accept at most two optional device images, one for each attachment slot. Each file MUST be JPG, PNG, or GIF, MUST be decodable as that image type, and MUST not exceed 20 MB. The system MUST store original files under a configurable local root and expose them only through an opaque application file URL; it MUST NOT return local disk paths or create separate thumbnail files.

#### Scenario: Display image by browser-sized preview
- **WHEN** a device response contains an image access URL
- **THEN** the client can load the original image through the controlled URL and render it in a fixed-size preview without requesting a separately generated thumbnail

#### Scenario: Replace or remove an image while editing
- **WHEN** a user updates one image slot with a valid replacement or an explicit remove flag
- **THEN** the system respectively records the new opaque identifier or clears that slot while leaving the other slot unchanged

### Requirement: Reference-protected device deletion
The system SHALL provide `DELETE /api/device-assets/{id}` as a soft delete. Before deletion it MUST check active phone, enterprise WeChat, WeChat, and Douyin assets for the target device ID. If any active reference exists, it MUST reject deletion and identify the referencing asset types; otherwise it MUST update `delete_time` and `update_time` without physically deleting stored image files.

#### Scenario: Reject deletion of a referenced device
- **WHEN** an active phone or account asset references the requested device ID
- **THEN** the system returns a readable failure and the device remains active

#### Scenario: Soft-delete an unreferenced device
- **WHEN** no active supported asset references the requested device ID
- **THEN** the system marks the device deleted and it no longer appears in the device list
