5.4 KiB
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