69 lines
5.6 KiB
Markdown
69 lines
5.6 KiB
Markdown
## Context
|
|
|
|
The existing server-create dialog serializes target selection, deployment choice, paths, plugin game fields, runtime binding fields, and custom commands into one form. A server's deployment editor exists only in the detail overview beside many unrelated operational panels. The API already distinguishes drafts, protected deployment inputs, deployment modes, and explicit dispatch; the design problem is the management-console workflow, not a missing host-side capability.
|
|
|
|
The console must preserve its black-mecha / magical-girl shared visual system and must not return protected paths, commands, credentials, or direct Run access to the browser.
|
|
|
|
## Goals / Non-Goals
|
|
|
|
**Goals:**
|
|
|
|
- Make the normal operator flow target-first, mode-second, configuration-third, then review.
|
|
- Provide a single reusable workflow for new definitions and safe edits to drafts or stopped servers.
|
|
- Make draft creation explicit and keep deployment impact, capability issues, and write-only values understandable.
|
|
- Keep changes compatible with existing create, update-deployment, and deploy endpoints.
|
|
|
|
**Non-Goals:**
|
|
|
|
- Changing Run's protected deployment protocol, adding SSH/host browsing, returning protected values, or allowing deployment-definition mutation for an active server.
|
|
- Adding new game plugins, changing plugin manifest semantics, or replacing the console visual language.
|
|
- Implementing a generic shell editor or a path browser in Platform.
|
|
|
|
## Decisions
|
|
|
|
### 1. One controlled workflow owns both creation and deployment edits
|
|
|
|
Introduce a `ServerDeploymentWorkflow` component with `create` and `edit` modes. The page that opens it owns only the lifecycle request: create calls the existing workflow-create endpoint, while edit saves the existing deployment definition and lets the operator explicitly deploy afterward. This removes duplicate form policy without introducing an API abstraction that hides lifecycle actions.
|
|
|
|
The alternative—incrementally rearranging the two current forms—would keep divergent defaults, labels, and field visibility.
|
|
|
|
### 2. Workflow steps follow operator decisions, not storage fields
|
|
|
|
The component has four steps: target (plugin plus Run or explicit draft), deployment method, configuration, and review. Forward navigation validates only fields required by the selected mode. Back navigation preserves typed values. The final review is the only submit point.
|
|
|
|
`guided-install` shows plugin game inputs and an optional “installation directory”; `existing-server` requires an “existing server directory” and explicitly states that it will not reinstall or overwrite game configuration; `custom-command` adds launch data. `workingDirectory` is an advanced custom-command input labelled as an execution directory and defaults logically to `serverRoot` when omitted. This preserves the current protocol distinction without demanding it from normal users.
|
|
|
|
### 3. Draft is a deliberate outcome
|
|
|
|
The target step presents compatible nodes and a separate “save as draft” choice with explanatory copy. It never represents draft creation as an empty selection accidentally left in a select input. A draft review changes the final action to save only; it does not offer a deceptive deployment promise.
|
|
|
|
### 4. Editing is a discoverable operation with safe prefill
|
|
|
|
Server cards and the detail header expose `编辑部署`. Detail opening uses the same workflow. The edit form receives safe deployment view values (mode, configured flags, create inputs, selected endpoint) and starts protected input fields blank with replacement copy. It is disabled for active servers, matching the existing server-side rule.
|
|
|
|
### 5. Review uses only safe, operator-facing summaries
|
|
|
|
The review names the plugin, chosen node/draft outcome, method, game configuration, and configured/replaced protected inputs. It never renders protected values. Plugin profile keys remain internal implementation values; where a choice is necessary, the UI calls it a runtime preset and formats a readable label.
|
|
|
|
### 6. Styling is shared and compact
|
|
|
|
Use `ManagementDialog`, `console-*`, command, form, and theme token primitives, adding only narrowly scoped workflow layout classes in `theme/base.css`. The step indicator is functional state, not page-local decoration; no fixed particles, opaque SaaS cards, or independent color system are introduced.
|
|
|
|
## Risks / Trade-offs
|
|
|
|
- [An edit lacks the original protected values] → Show configured state and make blank fields preserve the stored values; copy states that re-entry replaces the value.
|
|
- [A user mistakes a stopped-server edit for immediate deployment] → Separate “save changes” from the explicit later “deploy” operation and show the consequence in review.
|
|
- [Node compatibility information is incomplete before Run preflight] → Show only known endpoint availability/capability; retain Run preflight as authoritative.
|
|
- [A shared component expands scope] → Limit it to deployment-definition inputs and leave server metadata, game config editor, and runtime operations in their existing sections.
|
|
|
|
## Migration Plan
|
|
|
|
1. Ship the shared frontend workflow behind the existing API contracts.
|
|
2. Preserve all existing definition fields and treat missing working directories as inherited from the server directory for review copy only.
|
|
3. Route card/detail edit actions into the workflow and remove the old duplicate create/deployment forms.
|
|
4. Roll back by restoring the previous page components; persisted deployment definitions and endpoints remain unchanged.
|
|
|
|
## Open Questions
|
|
|
|
- None for the initial workflow: endpoint capability is already authoritatively checked at dispatch and protected input values intentionally cannot be prefilled.
|