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

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.