25 lines
1.1 KiB
Markdown
25 lines
1.1 KiB
Markdown
## Why
|
|
|
|
The dedicated SCUM Run can register successfully, but a failed or draft server has no visible Platform action that submits its existing deployment definition. Operators therefore see an idle Run startup log and cannot advance the installation workflow.
|
|
|
|
## What Changes
|
|
|
|
- Add an explicit Deploy / Retry deploy control to the server detail actions for draft and failed servers.
|
|
- Submit the existing protected deployment definition through the existing authenticated deployment API, using the current config version and a fresh idempotency key.
|
|
- Present the queued deployment result in the normal operation feedback and refresh the server/job view.
|
|
|
|
## Capabilities
|
|
|
|
### New Capabilities
|
|
|
|
- `server-deployment-trigger`: Operator-facing dispatch of an already-configured draft or failed server deployment after its dedicated Run registers.
|
|
|
|
### Modified Capabilities
|
|
|
|
- None.
|
|
|
|
## Impact
|
|
|
|
- Affects `platform_web/pages/ServerDetailPage.tsx` and its focused UI tests.
|
|
- Reuses the existing `POST /api/v1/server-instances/{id}/deploy` contract; no new server API, remote access, credentials, or host data are introduced.
|