## ADDED Requirements

### Requirement: Server definitions can be saved before Run is available
The system SHALL allow an authorized server manager to create and edit a draft server definition without a Run endpoint binding. The system MUST NOT dispatch a lifecycle job for an unbound draft.

#### Scenario: Create an unbound draft
- **WHEN** an authorized user saves a server definition without selecting a Run endpoint
- **THEN** the system stores it in `draft` state and returns no install job

#### Scenario: Deploy a draft after Run registration
- **WHEN** an authorized user binds a draft to a compatible online Run endpoint and requests deployment
- **THEN** the system validates the deployment definition and queues the requested lifecycle job

### Requirement: Deployment modes support real self-hosted layouts
The system SHALL support `guided-install`, `existing-server`, and `custom-command` deployment modes. An operator MAY provide an absolute server root and working directory for all modes and lifecycle command definitions for custom-command mode.

#### Scenario: Adopt an existing Python virtual-environment server
- **WHEN** an operator saves existing-server or custom-command mode with an absolute working directory and a Python virtual-environment startup command
- **THEN** the system stores the protected execution input and does not require the server directory to be adjacent to Run

### Requirement: Protected execution inputs are not exposed by read APIs
The system SHALL treat supplied host paths and command text as protected execution inputs. List, detail, job, audit, log, and plugin bridge read responses MUST expose only configured state, deployment mode, and safe fingerprints or summaries.

#### Scenario: Read a configured custom deployment
- **WHEN** an authorized user reads a server deployment definition after saving a path and command
- **THEN** the response indicates the protected fields are configured without returning their values

### Requirement: Deployment requires an execution-capable Run only when dispatching
The system SHALL require an online compatible Run endpoint only for preflight, install, start, stop, or status dispatch. The system MUST reject dispatch when the assigned Run does not declare the versioned deployment-plan capability.

#### Scenario: Attempt deployment with incompatible Run
- **WHEN** an operator requests deployment against a Run that lacks deployment-plan support
- **THEN** the system returns a safe compatibility reason and does not queue an executable lifecycle job

### Requirement: Lifecycle status explains waiting and execution phases
The system SHALL surface whether a deployment job is queued, claimed, in preflight, installing, configuring, starting, or performing a health check. Safe Run failures MUST remain attached to the job and server state.

#### Scenario: Run has not claimed deployment
- **WHEN** a deployment job remains queued
- **THEN** the server UI identifies it as waiting for Run claim rather than reporting installation progress