## ADDED Requirements

### Requirement: Platform persists plugin runtime profiles
The platform SHALL decode, validate, store, and return safe plugin runtime profiles covering server discovery, lifecycle, dependencies and install plans, log sources, transports, and client-manager declarations.

#### Scenario: Manifest registration survives reload
- **WHEN** an operator registers a valid plugin manifest with runtime profiles and the durable store is reopened
- **THEN** the installed plugin retains the same validated runtime-profile contract

#### Scenario: Unsafe runtime declaration is rejected
- **WHEN** a manifest runtime profile includes a raw host path, direct socket, credential, secret value, or arbitrary shell content
- **THEN** registration fails without persisting the unsafe declaration

### Requirement: Server selects a declared runtime profile
Each server runtime binding SHALL select a lifecycle profile declared by its installed plugin and SHALL derive required logical keys from that profile and its referenced runtime declarations.

#### Scenario: Valid profile selection
- **WHEN** an authorized operator selects a declared lifecycle profile for a server
- **THEN** the platform stores the server, plugin, profile, mode, derived required keys, and readiness state

#### Scenario: Undeclared profile is rejected
- **WHEN** a caller selects a profile key or logical binding key not declared by the server's plugin
- **THEN** the platform rejects the request without changing the stored binding

### Requirement: Runtime bindings are durable and authorized
The platform SHALL persist runtime bindings in memory, file, and MySQL-backed repository contracts and SHALL authorize server-scoped reads and owner/admin-scoped changes.

#### Scenario: Binding survives durable reload
- **WHEN** a valid binding is written through a durable store and the store is reopened
- **THEN** the selected profile and readiness metadata remain available for that server

#### Scenario: Unauthorized binding update
- **WHEN** a user who is neither platform admin nor server owner attempts to change a server binding
- **THEN** the platform denies the update and leaves the binding unchanged

### Requirement: Binding projections do not disclose runtime details
Runtime binding responses SHALL expose only profile metadata, declared logical keys, configured/secret flags, missing keys, status, and timestamps; they MUST NOT expose stored values, raw host paths, direct sockets, credentials, DSNs, or internal secret-storage locations.

#### Scenario: Secret reference is configured
- **WHEN** a stored logical binding uses a secret reference
- **THEN** the API reports that the logical key is configured and secret-backed without returning the reference value

#### Scenario: Missing logical binding is reviewed
- **WHEN** a required logical key is absent
- **THEN** the API and web console display the logical key and a safe configuration reason without storage details

### Requirement: Actions require a complete runtime binding
The platform SHALL gate lifecycle and runtime-dependent actions on the presence of a valid, complete runtime binding for the server's current plugin and selected profile.

#### Scenario: No binding is not complete
- **WHEN** a server has no runtime binding
- **THEN** lifecycle and runtime-dependent actions are disabled or rejected with a safe profile-not-configured reason

#### Scenario: Missing binding blocks dispatch
- **WHEN** a selected profile has one or more missing required logical keys
- **THEN** the platform does not dispatch the requested action and reports only the missing logical keys

#### Scenario: Complete binding permits normal validation
- **WHEN** the selected profile has all required logical keys configured
- **THEN** action handling proceeds to existing permission, endpoint capability, state, and idempotency checks

### Requirement: Server creation submits a real profile and bindings
The server creation workflow SHALL require a declared runtime profile and SHALL persist validated initial bindings before dispatching the install job.

#### Scenario: Complete create request
- **WHEN** an operator submits a server, declared profile, and all required logical bindings
- **THEN** the platform persists the server and binding and queues the install job with the selected profile context

#### Scenario: Incomplete create request
- **WHEN** a create request omits a required logical binding
- **THEN** the platform rejects creation before dispatch and identifies only the missing logical key

### Requirement: Operators can review and amend bindings
The management console SHALL derive profile choices and logical binding inputs from plugin declarations and SHALL provide a server-detail workflow to review or amend the selected profile and binding completeness.

#### Scenario: Create form submits selected contract
- **WHEN** an operator selects a plugin and profile and completes declared logical fields
- **THEN** the web client submits the actual profile key and binding map in the create workflow request

#### Scenario: Detail workflow updates bindings safely
- **WHEN** an authorized operator changes a stopped or draft server's profile or logical bindings
- **THEN** the console saves through the runtime-binding API and refreshes the redacted readiness projection

#### Scenario: UI does not render sensitive runtime data
- **WHEN** a binding response is rendered in create or detail workflows
- **THEN** the UI contains no secret value, raw path, socket, DSN, or internal storage reference