Allow forced server deletion

2026-08-04 15:03:49 +08:00
parent 96a1939f32
commit cf9af14eaf
17 changed files with 236 additions and 24 deletions
@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-08-04
@@ -0,0 +1,33 @@
+## Context
+
+Server deletion is currently a password-confirmed soft delete, but active states (`running` and `installing`) are always rejected. That protects against orphaning live runtime work, but it also traps operators when the platform state is stale, the run endpoint is gone, or a lifecycle job cannot complete.
+
+The platform/run boundary matters here: platform can mark metadata deleted, but it must not invent game-specific stop behavior or directly manage host processes outside plugin-owned lifecycle jobs.
+
+## Goals / Non-Goals
+
+**Goals:**
+- Let an owner or platform administrator force-delete a running or installing instance when they explicitly accept the operational risk.
+- Keep password confirmation mandatory for normal and forced deletion.
+- Preserve soft-delete history and current list filtering behavior.
+- Make forced deletion visible and deliberate in the UI.
+
+**Non-Goals:**
+- Hard-deleting server metadata or historical records.
+- Killing, stopping, or cleaning up a remote process as part of delete.
+- Adding run-side force-kill behavior, game-specific cleanup, or deployment target changes.
+- Allowing non-owners or non-admins to delete servers.
+
+## Decisions
+
+- Extend the existing `DELETE /api/v1/server-instances/{id}` JSON body with `force` and `confirmation` fields. The existing route keeps one destructive API surface, while older clients still get the default safe rejection for running/installing instances.
+- Require `force: true` plus a fixed confirmation phrase for running or installing instances. This separates accidental password-only deletion from intentional cleanup of stuck active instances.
+- Keep backend enforcement in `DeleteServerInstanceForSession`. The frontend can guide the operator, but the service must remain the source of truth.
+- Treat forced deletion as metadata-only. The server state becomes `deleted`; run jobs, logs, artifacts, and audit history remain visible through existing historical paths where supported.
+- Show force confirmation only when the selected instance is running or installing, and keep the delete entry in the existing compact server-card action menu.
+
+## Risks / Trade-offs
+
+- [Risk] A forced delete can hide a server whose process is still alive. -> Mitigation: confirmation copy states that delete is metadata-only and does not stop the process.
+- [Risk] Operators may use force instead of stopping cleanly. -> Mitigation: normal delete remains the default for stopped/ready/failed servers; active states require explicit force confirmation.
+- [Risk] Existing clients may omit the new fields. -> Mitigation: the backend keeps the current rejection unless force confirmation is present.
@@ -0,0 +1,24 @@
+## Why
+
+Operators need a way to remove server instances that are stuck in `running` or `installing` state when the runtime can no longer be stopped cleanly. The current delete safety rule blocks those instances forever, which leaves stale servers in the active management console.
+
+## What Changes
+
+- Add an explicit forced delete path to the existing server deletion flow.
+- Preserve owner/platform-admin authorization and current-password confirmation for all server deletion.
+- Require an additional force confirmation when deleting a running or installing instance.
+- Keep deletion as a soft delete that marks the server instance `deleted` and preserves history.
+- Make the UI expose forced deletion only through the existing destructive password confirmation dialog.
+
+## Capabilities
+
+### New Capabilities
+- `server-deletion`: server instance soft deletion, including authorization, password confirmation, and explicit forced deletion of active/stuck instances.
+
+### Modified Capabilities
+
+## Impact
+
+- `platform/` delete DTO, API handler docs, service validation, and tests.
+- `platform_web/` delete request types, client-side delete dialog, error/confirmation copy, and tests.
+- No changes to run executor ownership, plugin lifecycle execution, or hard-delete persistence.
@@ -0,0 +1,49 @@
+## ADDED Requirements
+
+### Requirement: Authorized server deletion
+The system SHALL allow a server instance to be deleted only when the authenticated user is the instance owner or a platform administrator.
+
+#### Scenario: Owner deletes a server
+- **WHEN** the instance owner submits a delete request for their server
+- **THEN** the system SHALL accept the request if all other delete checks pass
+
+#### Scenario: Non-owner cannot delete
+- **WHEN** an authenticated user who is neither the owner nor a platform administrator submits a delete request
+- **THEN** the system SHALL reject the request with forbidden access
+
+### Requirement: Password confirmation for deletion
+The system SHALL require the authenticated user to provide their current account password with every server delete request and SHALL reject the request if the password is missing or does not match the current session user.
+
+#### Scenario: Password mismatch
+- **WHEN** the authenticated user submits the delete request with an incorrect password
+- **THEN** the system SHALL reject the request with forbidden access
+
+#### Scenario: Password required
+- **WHEN** the authenticated user submits the delete request without a password
+- **THEN** the system SHALL reject the request as invalid input or forbidden access
+
+### Requirement: Forced active server deletion
+The system SHALL reject deletion for a running or installing server instance by default, but SHALL allow the same soft deletion when the authenticated owner or platform administrator also submits an explicit forced-delete confirmation.
+
+#### Scenario: Running server delete without force is rejected
+- **WHEN** a delete request targets a running server instance without forced-delete confirmation
+- **THEN** the system SHALL reject the request and keep the server instance intact
+
+#### Scenario: Installing server delete without force is rejected
+- **WHEN** a delete request targets an installing server instance without forced-delete confirmation
+- **THEN** the system SHALL reject the request and keep the server instance intact
+
+#### Scenario: Running server force delete marks deleted state
+- **WHEN** a valid delete request targets a running server instance with forced-delete confirmation
+- **THEN** the system SHALL mark the server instance as deleted while preserving historical records
+
+#### Scenario: Installing server force delete marks deleted state
+- **WHEN** a valid delete request targets an installing server instance with forced-delete confirmation
+- **THEN** the system SHALL mark the server instance as deleted while preserving historical records
+
+### Requirement: Soft server removal state
+The system SHALL mark deleted server instances with the deleted state and preserve historical records rather than hard-deleting metadata.
+
+#### Scenario: Successful deletion marks deleted state
+- **WHEN** a valid delete request targets a stopped, ready, failed, or force-confirmed active server instance
+- **THEN** the system SHALL mark the server instance as deleted and preserve history
@@ -0,0 +1,15 @@
+## 1. Backend Force Delete
+
+- [x] 1.1 Add force-delete fields to server deletion DTO/domain request and route handling.
+- [x] 1.2 Update service deletion validation so running/installing servers require explicit force confirmation.
+- [x] 1.3 Add backend service/API tests for forced running and installing deletion plus default rejection.
+
+## 2. Frontend Confirmation
+
+- [x] 2.1 Extend the server deletion request type and API usage with force confirmation fields.
+- [x] 2.2 Update the server list delete dialog to show active-state force warning and confirmation input.
+- [x] 2.3 Update frontend tests for forced delete payloads and copy.
+
+## 3. Verification
+
+- [x] 3.1 Run OpenSpec strict validation, structure check, and focused backend/frontend tests.