fix: 调试发布run

2026-07-22 11:44:48 +08:00
parent b06623d0ce
commit 6c3eb6e45f
41 changed files with 1289 additions and 206 deletions
@@ -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.