fix: 调试发布run

openspec/changes/restrict-server-delete-with-password-confirmation/.openspec.yaml

@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-07-21

openspec/changes/restrict-server-delete-with-password-confirmation/design.md

@@ -0,0 +1,35 @@
+## Context
+
+Server deletion currently reuses the archive path and already restricts the action to the instance owner or a platform administrator. What it does not do is re-check the caller's password before removing the server from active use, which leaves a destructive action one click away once a session is active.
+
+## Goals / Non-Goals
+
+**Goals:**
+- Require a password confirmation before server deletion is accepted.
+- Preserve the existing owner/platform-admin authorization rule.
+- Keep the current soft-delete behavior that marks the server instance deleted and preserves history.
+
+**Non-Goals:**
+- Implementing hard delete or permanent record erasure.
+- Changing unrelated server lifecycle permissions.
+- Adding a new authentication system or password reset flow.
+
+## Decisions
+
+- Keep the existing `DELETE /api/v1/server-instances/{id}` route and extend it with a JSON body containing the current password. This avoids inventing a parallel delete endpoint and keeps the UI and API aligned.
+- Verify deletion authorization in the service layer, not only in the frontend. The request must still be rejected even if the browser skips the confirmation UI.
+- Reuse the current session user's stored password hash and existing `verifyPassword` helper. No new credential store or token exchange is needed.
+- Return a generic forbidden response when the password confirmation fails. The UI can present that as a password-confirmation failure without exposing hash or account details.
+- Surface deletion from the server list card's "运行操作" popover in a "危险操作" group instead of placing it inside the detail metadata panel. Runtime actions remain permission-gated, while eligible creators/owners and platform admins can still reach the delete confirmation.
+- Update the user-facing copy from "归档" to "删除" so the destructive intent is clear wherever the action is exposed.
+
+Alternatives considered:
+- Separate confirm endpoint: rejected because it adds another round trip without changing the security model.
+- Query-string password: rejected because sensitive data should not live in the URL.
+- Hard delete: rejected because the platform already models server removal as a deleted state with retained history.
+
+## Risks / Trade-offs
+
+- [Risk] Sending a password in the request body increases sensitivity of the delete call. → The request already runs over authenticated HTTPS; the frontend must avoid persisting the value beyond the dialog.
+- [Risk] The UI and API could drift if one side keeps "archive" wording or if the delete entry reappears in details. → Keep the confirmation dialog and API call site in the list runtime action flow together.
+- [Risk] Password confirmation may feel redundant to power users. → Keep the rule limited to destructive deletion only, not to normal lifecycle operations.

openspec/changes/restrict-server-delete-with-password-confirmation/proposal.md

@@ -0,0 +1,23 @@
+## Why
+
+Server deletion currently trusts role and ownership alone, which is too loose for a destructive action. The UI also lets users trigger deletion without re-entering their password, so a stolen session or stray click can remove a server too easily.
+
+## What Changes
+
+- Require server delete to be explicitly confirmed with the current user password.
+- Allow deletion only for the server creator/owner or a platform administrator.
+- Keep the existing archive/delete flow, but expose the destructive action from the server list runtime actions with an intentional password confirmation.
+- Return a clear authorization or password error when the confirmation fails.
+
+## Capabilities
+
+### New Capabilities
+- `server-deletion`: deletion authorization and password confirmation for server instances.
+
+### Modified Capabilities
+
+## Impact
+
+- `platform/` delete handler, service authorization, and password verification logic.
+- `platform_web/` server list runtime-action delete confirmation dialog and API client request payload.
+- Automated tests covering authorization, password failure, and successful deletion.

openspec/changes/restrict-server-delete-with-password-confirmation/specs/server-deletion/spec.md

@@ -0,0 +1,34 @@
+## 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: Safe server removal state
+The system SHALL continue to reject deletion when the server instance is running or installing, and SHALL otherwise mark the server instance as deleted while preserving historical records.
+
+#### Scenario: Running server cannot be deleted
+- **WHEN** a delete request targets a running server instance
+- **THEN** the system SHALL reject the request and keep the server instance intact
+
+#### Scenario: Successful deletion marks deleted state
+- **WHEN** a valid delete request targets a stopped or ready server instance
+- **THEN** the system SHALL mark the server instance as deleted and return the updated instance

openspec/changes/restrict-server-delete-with-password-confirmation/tasks.md

@@ -0,0 +1,20 @@
+## 1. Backend delete confirmation
+
+- [x] 1.1 Add a server delete request DTO and extend the service/API contract to accept the current session password on delete.
+- [x] 1.2 Verify the current session password in the server deletion flow after owner/admin authorization and keep the existing deleted-state behavior.
+- [x] 1.3 Update API handler docs and backend tests for owner/admin success, password failure, and unsafe-state rejection.
+
+## 2. Frontend delete flow
+
+- [x] 2.1 Update the server detail delete confirmation dialog to collect a password and submit it with the delete request.
+- [x] 2.2 Rename the user-facing action copy from archive to delete where the destructive action is exposed.
+- [x] 2.3 Update the API client, contracts, and frontend tests for the new delete payload and confirmation state.
+
+## 3. Verification
+
+- [x] 3.1 Run the structure check and focused backend/frontend tests for the delete flow.
+
+## 4. Follow-up UI placement
+
+- [x] 4.1 Move the delete confirmation entry from server detail metadata to the server list runtime action popover.
+- [x] 4.2 Update frontend tests and verification for the new delete entry placement.