87 lines
5.4 KiB
Markdown
87 lines
5.4 KiB
Markdown
## 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
|