feat(admin-frontend): 补齐活跃筛选与支付快照能力

新增用户管理“活跃状态”高级筛选，并在后端支持
activity_status 复合规则，支持按活跃与非活跃筛选用户。

补齐订单支付成功快照落库与后台展示，保存支付渠道、
支付方法、实付金额和支付 IP，并在订单详情中优先展示。

同时增强节点页在线/离线筛选与批量删除、仪表盘快捷入口，
并修复已关闭工单再次回复后自动重开的统一语义。

附带同步测试、迁移、CI 工作流命名及知识库记录

.helloagents/plan/202604250002_admin-frontend-dashboard-shortcuts/.status.json

@@ -0,0 +1,11 @@
+{
+  "status": "completed",
+  "completed": 5,
+  "failed": 0,
+  "pending": 0,
+  "total": 5,
+  "done": 5,
+  "percent": 100,
+  "current": "dashboard 快捷入口增强、工单/订单落地筛选与构建验证已完成",
+  "updated_at": "2026-04-25 00:15:43"
+}

.helloagents/plan/202604250002_admin-frontend-dashboard-shortcuts/contract.json

@@ -0,0 +1,52 @@
+{
+  "updatedAt": "2026-04-24T16:02:00.000Z",
+  "version": 1,
+  "source": "R2",
+  "originCommand": "design",
+  "verifyMode": "review-first",
+  "reviewerFocus": [
+    "仪表盘可点击指标卡是否只覆盖已有明确落点的工作台",
+    "工单页与订单页的路由查询同步是否不会破坏既有筛选逻辑",
+    "可点击卡片是否具备清晰的 hover 与 focus 提示，而不是隐形跳转"
+  ],
+  "testerFocus": [
+    "点击待处理工单卡应进入工单工作台",
+    "点击待处理佣金卡应进入订单工作台并默认落在真实待确认佣金视图",
+    "点击总用户卡应进入用户工作台",
+    "admin-frontend 执行 npm run build 应通过"
+  ],
+  "ui": {
+    "required": true,
+    "designContract": true,
+    "sourcePriority": [
+      "plan.md",
+      ".helloagents/DESIGN.md",
+      "hello-ui"
+    ],
+    "styleAdvisor": {
+      "required": false,
+      "reason": "",
+      "focus": []
+    },
+    "visualValidation": {
+      "required": false,
+      "reason": "",
+      "screens": [
+        "#/dashboard metrics grid",
+        "#/tickets dashboard-entry notice",
+        "#/subscriptions/orders commission workbench"
+      ],
+      "states": [
+        "metric card hover/focus",
+        "dashboard source info notice",
+        "commission workbench preset"
+      ]
+    }
+  },
+  "advisor": {
+    "required": false,
+    "reason": "",
+    "focus": [],
+    "preferredSources": []
+  }
+}

.helloagents/plan/202604250002_admin-frontend-dashboard-shortcuts/proposal.md

@@ -0,0 +1,99 @@
+# 变更提案: admin-frontend-dashboard-shortcuts
+
+## 元信息
+```yaml
+类型: 体验增强
+方案类型: implementation
+优先级: P2
+状态: 已完成
+创建: 2026-04-25
+```
+
+---
+
+## 1. 需求
+
+### 背景
+用户希望 `admin-frontend` 仪表盘中的“待处理工单”可以一键进入工单页，不再从左侧菜单二次跳转；同时希望把其他已有明确去向的高频数据卡也补成更顺手的快捷入口。
+
+### 目标
+- 让仪表盘顶部指标卡中“待处理工单”支持点击直达工单工作台。
+- 为其他已有明确工作台承接的指标补充快捷入口，减少运营后台的重复导航。
+- 保持现有 Apple 风格后台语气，只做低噪音、可发现、可键盘操作的交互增强。
+
+### 约束条件
+```yaml
+范围约束: 仅改动 admin-frontend，保持现有页面结构和路由体系
+技术约束: 不新增后端接口，仅复用现有前端路由、查询参数与工作台筛选能力
+交互约束: 快捷入口必须保留 hover/focus 可见反馈，避免把普通统计卡误做成无提示的隐形按钮
+验证约束: 以 admin-frontend 构建通过为本轮硬验证
+```
+
+### 验收标准
+- [ ] 仪表盘“待处理工单”卡点击后可直接进入 `#/tickets`
+- [ ] 仪表盘“待处理佣金”卡点击后可直接进入订单工作台，并默认落在真实待确认佣金视图
+- [ ] 仪表盘“总用户”卡可直接进入用户工作台
+- [ ] 可点击指标卡具有明确的快捷入口提示和可见 focus / hover 反馈
+- [ ] 工单页与订单页能识别“从仪表盘进入”的上下文，并给出低干扰提示
+- [ ] `admin-frontend` 执行构建验证通过
+- [ ] `.helloagents` 方案包、模块文档与 CHANGELOG 已同步
+
+---
+
+## 2. 方案
+
+### 核心思路
+把仪表盘顶部指标卡从“纯展示”升级为“展示 + 跳转入口”的复合卡片，但只开放那些已有明确落点的卡片，避免为了可点击而过度链接。
+
+### 实施策略
+1. 在 `DashboardView.vue` 中为具备落点的指标卡增加 action 元数据。
+2. 指标卡渲染层改成“普通卡 / 可点击卡”双态结构：可点击卡使用按钮语义、快捷提示文案与焦点反馈。
+3. `TicketsView.vue` 读取 dashboard 来源查询参数，在顶部给出“已从仪表盘进入”的提示。
+4. `OrdersView.vue` 扩展路由查询同步逻辑，让 dashboard 快捷入口可以直接落在“真实待确认佣金”工作台。
+5. 保持本轮范围在前端增量增强，不重构现有页面信息架构。
+
+### 影响范围
+- `admin-frontend/src/views/dashboard/DashboardView.vue`
+- `admin-frontend/src/views/tickets/TicketsView.vue`
+- `admin-frontend/src/views/subscriptions/OrdersView.vue`
+
+### 风险评估
+- 风险较低，主要在于新增的路由查询同步不能误伤原有筛选流程。
+- 用户工作台快捷入口若没有清晰提示，可能造成“统计卡误触”；因此必须补齐视觉提示和键盘焦点态。
+
+---
+
+## 3. 成果设计
+
+### 目的与受众
+面向运营后台管理员，在高频巡检和处理待办时减少侧边栏往返切换。
+
+### 美学方向
+延续当前 Apple 化后台：白色/浅灰指标卡为主，使用单一蓝色强调“可操作性”，避免把指标区做成高噪音按钮墙。
+
+### 记忆点
+“能点的指标卡，一眼就知道下一步会把你带去哪里。”
+
+### 视觉要素
+- 配色: 保持现有黑白主场，仅对快捷入口提示与 focus 态使用 `#0071e3`
+- 布局: 不新增额外操作栏，只在卡片底部补轻量快捷提示
+- 动效: hover / active 做轻微抬升与边框响应，focus-visible 保持明确外圈
+- 氛围: 维持低噪音运营面板，不引入多余图标装饰和营销式 CTA
+
+---
+
+## 4. 技术决策
+
+### admin-frontend-dashboard-shortcuts#D001: 只把已有明确承接页的指标卡做成快捷入口
+**日期**: 2026-04-25
+**状态**: ✅采纳
+**背景**: 用户明确要求“方便的更改也都加上”，但本轮仍需保持范围克制。
+**决策**: 仅开放“待处理工单 / 待处理佣金 / 总用户”三类已有明确工作台承接的指标卡。
+**理由**: 这些卡片都有明确落点，不需要新增后端能力，也不会让首页跳转语义变得含混。
+
+### admin-frontend-dashboard-shortcuts#D002: 使用路由查询参数同步仪表盘入口上下文
+**日期**: 2026-04-25
+**状态**: ✅采纳
+**背景**: 快捷入口需要让落地页进入目标视图，而不是只做普通跳转。
+**决策**: 通过 `source` / `focus` / `workbench` 查询参数驱动工单页和订单页的初始提示与筛选状态。
+**理由**: 复用现有路由体系即可完成上下文传递，改动集中、风险可控，也方便后续继续扩展其他快捷入口。

.helloagents/plan/202604250002_admin-frontend-dashboard-shortcuts/tasks.md

@@ -0,0 +1,45 @@
+# 任务清单: admin-frontend-dashboard-shortcuts
+
+> **@status:** completed | 2026-04-25 00:15
+
+```yaml
+@feature: admin-frontend-dashboard-shortcuts
+@created: 2026-04-25
+@status: completed
+@mode: R2
+```
+
+## 进度概览
+
+| 完成 | 失败 | 跳过 | 总数 |
+|------|------|------|------|
+| 5 | 0 | 0 | 5 |
+
+---
+
+## 任务列表
+
+- [√] 1. 梳理仪表盘可安全开放的快捷入口范围，并为指标卡补 action 元数据
+- [√] 2. 实现仪表盘指标卡的可点击态、提示文案与键盘可达交互
+- [√] 3. 扩展工单页与订单页的 dashboard 来源识别和落地筛选逻辑
+- [√] 4. 回归检查用户工作台跳转与现有筛选逻辑，避免快捷入口破坏原有行为
+- [√] 5. 执行 `admin-frontend` 构建验证，并同步 `.helloagents` 记录
+
+---
+
+## 执行日志
+
+| 时间 | 任务 | 状态 | 备注 |
+|------|------|------|------|
+| 2026-04-25 00:02 | 方案设计 | completed | 确认本轮采用 dashboard 快捷入口增强包，落点限定为工单 / 佣金订单 / 用户工作台 |
+| 2026-04-25 00:07 | 指标卡扩展 | completed | 为待处理工单、待处理佣金、总用户补 action 元数据与快捷入口提示 |
+| 2026-04-25 00:09 | 仪表盘交互 | completed | 指标卡切换为普通卡 / 可点击卡双态，补齐 hover 与 focus-visible 反馈 |
+| 2026-04-25 00:11 | 落地页联动 | completed | 工单页与订单页新增 dashboard 来源提示，并同步 opening / pending workbench 预设 |
+| 2026-04-25 00:15 | 构建验证 | completed | `admin-frontend` 执行 `npm run build` 通过，并补做本地 preview HTTP 检查 |
+
+---
+
+## 执行备注
+
+- 本轮不新增后端接口；若现有筛选能力无法承接，则退回普通工作台跳转，不强行扩展业务范围。
+- 本地未接入截图型浏览器工具，本轮 UI 验收采用 `npm run build` + `npm run preview` HTTP 探活 + 代码级视觉审查的降级策略。

.helloagents/plan/202604250006_ticket-closed-reply-reopen/.status.json

@@ -0,0 +1,11 @@
+{
+  "status": "in_progress",
+  "completed": 4,
+  "failed": 1,
+  "pending": 0,
+  "total": 5,
+  "done": 5,
+  "percent": 100,
+  "current": "代码修复与前端构建已完成，等待具备 PHP/Composer 的环境补跑后端验证",
+  "updated_at": "2026-04-25 00:15:50"
+}

.helloagents/plan/202604250006_ticket-closed-reply-reopen/contract.json

@@ -0,0 +1,43 @@
+{
+  "updatedAt": "2026-04-24T16:06:00.000Z",
+  "version": 1,
+  "source": "R2",
+  "originCommand": "design",
+  "verifyMode": "review-first",
+  "reviewerFocus": [
+    "工单再次回复后的 reopen 语义是否统一落在 TicketService，不再依赖单端特判",
+    "管理端关闭态发送交互是否放开且未破坏现有 Apple 风格工单工作台结构",
+    "用户端是否通过既有 /user/ticket/reply 链路打通，而非引入新的接口分叉"
+  ],
+  "testerFocus": [
+    "用户侧 closed ticket reply 后是否会自动变回开启状态",
+    "管理端 TicketWorkspaceDialog 在 closed ticket 下是否可发送并刷新状态",
+    "admin-frontend 构建与后端目标测试是否通过"
+  ],
+  "ui": {
+    "required": true,
+    "designContract": true,
+    "sourcePriority": [
+      "proposal.md",
+      ".helloagents/DESIGN.md",
+      "hello-ui"
+    ],
+    "styleAdvisor": {
+      "required": false,
+      "reason": "",
+      "focus": []
+    },
+    "visualValidation": {
+      "required": false,
+      "reason": "本轮以行为修复为主，未进行大规模视觉改版；代码级自检即可。",
+      "screens": [],
+      "states": []
+    }
+  },
+  "advisor": {
+    "required": false,
+    "reason": "",
+    "focus": [],
+    "preferredSources": []
+  }
+}

.helloagents/plan/202604250006_ticket-closed-reply-reopen/proposal.md

@@ -0,0 +1,86 @@
+# 变更提案: ticket-closed-reply-reopen
+
+## 元信息
+```yaml
+类型: 缺陷修复
+方案类型: implementation
+优先级: P1
+状态: 进行中
+创建: 2026-04-25
+```
+
+---
+
+## 1. 需求
+
+### 背景
+用户要求在 `admin-frontend` 的工单工作台中允许“已关闭工单再次回复”，并明确选择“前后台统一”方案：无论管理员还是用户，只要对已关闭工单再次回复，就自动把该工单重新开启。当前代码中，`V1/User/TicketController::reply()` 会直接拒绝 closed ticket；`TicketService::reply()` 也没有把工单状态改回开启；同时管理端 `TicketWorkspaceDialog.vue` 还会在 closed 状态禁用发送按钮。
+
+### 目标
+- 打通用户端与管理端的统一规则：已关闭工单再次回复后自动重开。
+- 保持现有 `/ticket/reply` 与 `/ticket/close` 接口不变，只修正回复链路的业务语义。
+- 管理端 `#/tickets` 保持现有 Apple 风格后台工作台，只做必要交互修复，不引入新的视觉系统分叉。
+
+### 约束条件
+```yaml
+范围约束: 仅修复工单再次回复与自动重开链路，不扩展其他客服、通知或工单字段
+技术约束: Laravel 后端继续复用现有 TicketService；管理端继续使用 Vue3 + TypeScript + Element Plus
+兼容约束: 用户端主题源码不在仓内，仅有编译产物 bundle，因此优先通过后端语义修复保证用户侧链路可用
+业务约束: 仍需保留 ticket_must_wait_reply 限制，避免同一角色连续刷消息破坏既有等待规则
+视觉约束: 管理端交互保持 .helloagents/DESIGN.md 的 Apple 风格后台，不做大改版
+```
+
+### 验收标准
+- [ ] 用户侧对已关闭工单调用回复接口时不再收到 “The ticket is closed and cannot be replied”，且回复后工单状态自动回到开启。
+- [ ] 管理端 `#/tickets` 中已关闭工单仍可进入工作台发送回复，回复成功后状态刷新为开启中的工单。
+- [ ] 回复后 `reply_status` 与 `last_reply_user_id` 仍保持当前系统既有语义，`ticket_must_wait_reply` 规则不回归。
+- [ ] 至少补齐 1 个针对工单自动重开语义的自动化测试。
+- [ ] `admin-frontend` 构建验证通过；后端目标测试通过。
+
+---
+
+## 2. 方案
+
+### 技术方案
+1. 以 `TicketService::reply()` 为单一真相源补齐“回复即自动重开”的状态回写，确保用户端、管理端、Telegram 插件管理员回复等所有复用该服务的链路统一生效。
+2. 移除 `V1/User/TicketController::reply()` 中“closed ticket 直接拒绝”的硬拦截，让用户端能走到统一服务逻辑；保留参数校验和 `ticket_must_wait_reply` 限制。
+3. 调整管理端 `TicketWorkspaceDialog.vue` 的关闭态发送限制：closed ticket 允许继续输入并发送；关闭按钮仍只在开启态显示。
+4. 基于当前仓内可维护代码补齐自动化测试，重点覆盖“回复 closed ticket 会自动 reopen”的核心业务语义；如果用户主题 bundle 不存在额外前端禁用，则不对 minified 用户端产物做无谓 patch。
+
+### 影响范围
+- 后端：`app/Services/TicketService.php`、`app/Http/Controllers/V1/User/TicketController.php`
+- 管理端：`admin-frontend/src/views/tickets/TicketWorkspaceDialog.vue`
+- 测试：`tests/Unit` 或 `tests/Feature`
+- 文档：`.helloagents/context.md`、`.helloagents/modules/admin-frontend.md`、`.helloagents/CHANGELOG.md`
+
+### 风险评估
+| 风险 | 等级 | 应对 |
+|------|------|------|
+| 统一在服务层自动 reopen 可能影响管理员插件回复链路 | 中 | 只在“reply 成功后”把 status 设回开启，保持 reply_status/last_reply_user_id 语义不变，并补测试验证 |
+| 用户主题只有编译 bundle，若前端本身禁用 closed reply，后端修复仍不足 | 中 | 已先排查 bundle，当前回复页未发现 closed 态本地禁用；若实施后验证发现仍受限，再最小化补丁 bundle |
+| 管理端放开发送后，状态徽章与列表刷新可能不同步 | 低 | 回复成功后继续复用现有 `refreshWorkspace()` 与 `updated` 刷新链路 |
+
+---
+
+## 3. 技术决策
+
+### ticket-closed-reply-reopen#D001: 自动重开规则下沉到 TicketService::reply()
+**日期**: 2026-04-25  
+**状态**: ✅采纳  
+**背景**: 用户、管理员和插件管理员回复都复用工单服务，但当前 reopen 语义分散且缺失。  
+**决策**: 在 `TicketService::reply()` 内统一把成功回复后的工单状态改为 `STATUS_OPENING`。  
+**理由**: 这是所有回复链路共享的唯一稳定汇合点，能避免只修某个 controller 导致语义不一致。
+
+### ticket-closed-reply-reopen#D002: 用户端优先通过后端语义修复打通，不直接改 minified bundle
+**日期**: 2026-04-25  
+**状态**: ✅采纳  
+**背景**: 仓内不存在用户主题源代码，只保留 `theme/Xboard/assets/umi.js` 编译产物。  
+**决策**: 先确认用户端详情页没有本地禁用 closed reply，再仅通过后端修复放开用户端；只有验证发现前端仍阻塞时才补 bundle。  
+**理由**: 降低对 minified 产物的高风险修改，优先用可维护的后端真相源完成统一业务规则。
+
+### ticket-closed-reply-reopen#D003: 管理端仅修复交互门禁，不改变现有页面结构
+**日期**: 2026-04-25  
+**状态**: ✅采纳  
+**背景**: 当前工单工作台已经符合项目既定 Apple 风格后台基线，本轮是行为修复不是页面重做。  
+**决策**: 放开发送按钮的 closed 态禁用，并继续保留现有 hero / 工作台 / 对话区布局。  
+**理由**: 最小化视觉影响，避免为了一个业务修复引入额外 UI 回归。

.helloagents/plan/202604250006_ticket-closed-reply-reopen/tasks.md

@@ -0,0 +1,45 @@
+# 任务清单: ticket-closed-reply-reopen
+
+> **@status:** in_progress | 2026-04-25 00:15
+
+```yaml
+@feature: ticket-closed-reply-reopen
+@created: 2026-04-25
+@status: in_progress
+@mode: R2
+```
+
+## 进度概览
+
+| 完成 | 失败 | 跳过 | 总数 |
+|------|------|------|------|
+| 4 | 1 | 0 | 5 |
+
+---
+
+## 任务列表
+
+- [√] 1. 冻结工单回复/关闭链路的根因与实施边界，确认用户端由后端语义修复打通 | depends_on: []
+- [√] 2. 修复后端工单回复逻辑：关闭态允许回复且回复成功后自动重开 | depends_on: [1]
+- [√] 3. 修复管理端工单工作台：关闭态允许继续发送并复用现有刷新链路 | depends_on: [2]
+- [√] 4. 补齐自动化测试，覆盖“closed ticket reply -> reopen”核心语义 | depends_on: [2]
+- [X] 5. 运行后端/前端验证并同步知识库记录 | depends_on: [2, 3, 4]
+
+---
+
+## 执行日志
+
+| 时间 | 任务 | 状态 | 备注 |
+|------|------|------|------|
+| 2026-04-25 00:06 | 方案包初始化 | completed | 已确认本轮采用“前后台统一”方案，根因定位到 V1 用户控制器拦截、TicketService 未自动 reopen、管理端发送按钮禁用 |
+| 2026-04-25 00:10 | 实现完成 | completed | 已下沉 TicketService 自动重开语义，移除用户侧 closed reply 拦截，并放开管理端关闭态发送交互 |
+| 2026-04-25 00:12 | 构建验证 | completed | `admin-frontend` 执行 `npm run build` 通过，最新产物已写入 `public/assets/admin` 子模块 |
+| 2026-04-25 00:15 | 后端验证受阻 | failed | 当前终端无 `php` / `composer` / `docker`，无法继续执行 PHP 语法检查与新增单元测试，只能保留测试文件与代码级审查结果 |
+
+---
+
+## 执行备注
+
+- 用户主题仓内仅保留 `theme/Xboard/assets/umi.js` 编译产物；当前已确认回复详情页没有明显的 closed 态本地禁用，优先通过后端语义修复打通用户侧。
+- 本轮不改动工单关闭接口、工单自动关闭定时任务和流量日志对话框。
+- 任务 5 标记失败仅因本机缺少 PHP / Composer / Docker 运行时；前端构建和知识库同步已完成，但后端自动验证仍待补跑。

.helloagents/plan/202604250015_admin-frontend-node-status-filter-batch-delete/.status.json

@@ -0,0 +1,11 @@
+{
+  "status": "completed",
+  "completed": 4,
+  "failed": 0,
+  "pending": 0,
+  "total": 4,
+  "done": 4,
+  "percent": 100,
+  "current": "节点页在线/离线筛选与批量删除已完成，等待用户验收",
+  "updated_at": "2026-04-25 00:15:00"
+}

.helloagents/plan/202604250015_admin-frontend-node-status-filter-batch-delete/contract.json

@@ -0,0 +1,46 @@
+{
+  "updatedAt": "2026-04-24T16:15:00.000Z",
+  "version": 1,
+  "source": "R2",
+  "originCommand": "design",
+  "verifyMode": "test-first",
+  "reviewerFocus": [],
+  "testerFocus": [
+    "节点页状态筛选是否支持全部节点、在线节点、离线节点三种口径",
+    "离线筛选是否仅包含显式 offline 节点，不混入待同步或已停用节点",
+    "批量删除是否真实调用 /server/manage/batchDelete，并在成功后清空勾选与刷新列表",
+    "admin-frontend 执行 npm run build 应通过"
+  ],
+  "ui": {
+    "required": true,
+    "designContract": true,
+    "sourcePriority": [
+      "plan.md",
+      ".helloagents/DESIGN.md",
+      "hello-ui"
+    ],
+    "styleAdvisor": {
+      "required": false,
+      "reason": "",
+      "focus": []
+    },
+    "visualValidation": {
+      "required": false,
+      "reason": "",
+      "screens": [
+        "#/nodes toolbar filters",
+        "#/nodes selection summary"
+      ],
+      "states": [
+        "status filter online/offline",
+        "selected nodes batch delete action"
+      ]
+    }
+  },
+  "advisor": {
+    "required": false,
+    "reason": "",
+    "focus": [],
+    "preferredSources": []
+  }
+}

.helloagents/plan/202604250015_admin-frontend-node-status-filter-batch-delete/proposal.md

@@ -0,0 +1,83 @@
+# 变更提案: admin-frontend-node-status-filter-batch-delete
+
+## 元信息
+```yaml
+类型: 功能增强
+方案类型: implementation
+优先级: P1
+状态: 待执行
+创建: 2026-04-25
+```
+
+---
+
+## 1. 需求
+
+### 背景
+`admin-frontend` 的 `#/nodes` 已具备关键词搜索、类型 / 权限组 / 父子节点筛选、跨分页勾选与批量修改能力，但当前还缺少“按在线 / 离线状态快速筛选”的运营入口，也没有针对已勾选节点的批量删除动作。用户希望继续沿用 Apple 化后台工作台结构，在节点管理页补齐这两个高频运营动作。
+
+### 目标
+- 在节点管理页工具条补充“在线节点 / 离线节点”状态筛选。
+- 按本轮确认口径，仅把显式“离线”节点纳入“离线节点”筛选；`待同步 / 已停用` 不归入离线筛选结果。
+- 为已勾选节点补齐批量删除入口，并接通真实 `server/manage/batchDelete` 后端链路。
+
+### 约束条件
+```yaml
+范围约束: 本轮只增强节点管理页筛选与批量操作，不扩展新的节点详情、状态面板或更多批量动作
+技术约束: 继续使用 Vue3 + TypeScript + Element Plus，不新增第三方依赖
+视觉约束: 保持当前“黑色 hero + 白色工作台 + 低噪音工具条”Apple 风格后台基线，不引入厚重危险卡片或额外弹窗层级
+业务约束: 在线 / 离线判定继续以后端 `available_status` 与现有 `getNodeStatusMeta()` 为真相源；批量删除使用现成 `server/manage/batchDelete`
+确认约束: “离线节点”仅筛 `getNodeStatusMeta().dotClass === 'offline'` 的节点，`pending / disabled` 继续只出现在“全部节点”
+```
+
+### 验收标准
+- [ ] 节点页工具条新增状态筛选，并支持“全部节点 / 在线节点 / 离线节点”切换。
+- [ ] “离线节点”筛选结果只包含显式离线节点，不包含 `待同步 / 已停用`。
+- [ ] 已勾选节点时可触发批量删除，并在确认后真实调用 `server/manage/batchDelete`。
+- [ ] 批量删除成功后会清空勾选、刷新列表，并给出明确成功 / 失败反馈。
+- [ ] 节点页文案、提示与底部说明同步覆盖新增筛选和批量删除能力。
+- [ ] `admin-frontend` 执行 `npm run build` 通过。
+
+---
+
+## 2. 方案
+
+### 页面结构
+1. 工具条在现有“类型 / 权限组 / 节点关系”筛选之后新增“状态”筛选，下拉项固定为“全部节点 / 在线节点 / 离线节点”。
+2. 批量删除不额外引入新弹窗入口层级，而是与现有“批量修改”一起留在节点工作台主操作流中，只在已勾选节点时启用。
+3. 选择摘要条继续承担“当前已勾选多少节点”的上下文提示，并补充危险操作入口，避免在无勾选态暴露无效删除动作。
+
+### 前端实现策略
+1. 在 `src/utils/nodes.ts` 中新增状态筛选类型与过滤逻辑，保持节点状态口径统一由工具层维护。
+2. 在 `src/api/admin.ts` 中新增 `batchDeleteNodes()`，统一封装 `server/manage/batchDelete`。
+3. 在 `src/views/nodes/NodesView.vue` 中：
+   - 新增状态筛选状态与 `hasActiveFilters` 判断
+   - 将状态筛选接入 `filterNodes()`
+   - 增加批量删除确认、提交、清空勾选与刷新流程
+   - 同步更新 hero 文案、工具条按钮与选择摘要区
+4. 尽量维持现有样式骨架，只做最小 UI 增量，避免破坏节点页当前 Apple 化后台节奏。
+
+### 风险评估
+| 风险 | 等级 | 应对 |
+|------|------|------|
+| “离线”语义与 `待同步 / 已停用` 容易混淆 | 中 | 过滤逻辑只认 `offline` dotClass，并在方案与实现中固定该口径 |
+| 批量删除属于不可恢复操作，误触风险较高 | 高 | 仅在已勾选节点时启用，并在提交前二次确认删除数量与不可恢复性 |
+| 跨分页勾选后删除可能留下过期选中状态 | 中 | 删除成功后统一 `clearSelection()` 并重载节点数据，避免残留选中 ID |
+
+---
+
+## 3. 技术决策
+
+### admin-frontend-node-status-filter-batch-delete#D001: 离线筛选只匹配显式 offline 状态
+**日期**: 2026-04-25
+**状态**: ✅采纳
+**背景**: 用户已在评估阶段明确选择“离线节点不包含待同步/已停用”。
+**决策**: `statusFilter='offline'` 时仅保留 `getNodeStatusMeta(node).dotClass === 'offline'` 的节点。
+**理由**: 能保持离线筛选语义清晰，避免把待同步或停用节点混入故障排查视图。
+
+### admin-frontend-node-status-filter-batch-delete#D002: 批量删除复用主工作台选择摘要，不新增独立批量操作弹窗
+**日期**: 2026-04-25
+**状态**: ✅采纳
+**背景**: 当前节点工作台已具备跨分页勾选与选择摘要区，用户只要求补齐批量删除，不要求重做批量操作体系。
+**决策**: 批量删除入口放在现有勾选摘要区 / 工具条动作流中，通过确认框完成最后确认。
+**理由**: 改动最小、上下文最清晰，也更符合 Apple 风格后台“主表格内完成高频动作”的设计基线。

.helloagents/plan/202604250015_admin-frontend-node-status-filter-batch-delete/tasks.md

@@ -0,0 +1,43 @@
+# 任务清单: admin-frontend-node-status-filter-batch-delete
+
+> **@status:** completed | 2026-04-25 00:15
+
+```yaml
+@feature: admin-frontend-node-status-filter-batch-delete
+@created: 2026-04-25
+@status: completed
+@mode: R2
+```
+
+## 进度概览
+
+| 完成 | 失败 | 跳过 | 总数 |
+|------|------|------|------|
+| 4 | 0 | 0 | 4 |
+
+---
+
+## 任务列表
+
+- [√] 1. 梳理节点状态筛选口径、批量删除接口与当前节点页交互边界
+- [√] 2. 扩展节点工具层与管理端 API，补齐状态筛选和批量删除封装
+- [√] 3. 调整节点工作台筛选区、选择摘要区与删除确认流程，完成在线/离线筛选与批量删除
+- [√] 4. 执行 `admin-frontend` 构建验证，并同步 `.helloagents` 记录
+
+---
+
+## 执行日志
+
+| 时间 | 任务 | 状态 | 备注 |
+|------|------|------|------|
+| 2026-04-25 00:15 | 方案设计 | completed | 用户确认“离线节点”仅筛显式离线状态，不包含待同步 / 已停用 |
+| 2026-04-25 00:15 | 工具层与 API | completed | 已补齐 `statusFilter` 筛选口径与 `batchDeleteNodes()` 封装 |
+| 2026-04-25 00:15 | 页面实现 | completed | 节点页已新增状态筛选、批量删除按钮、确认提示与选择摘要文案 |
+| 2026-04-25 00:15 | 构建验证与知识库同步 | completed | `admin-frontend` 执行 `npm run build` 通过，并同步 context/modules/CHANGELOG |
+
+---
+
+## 执行备注
+
+- 本轮只增强 `#/nodes` 现有工作台，不改动节点新增 / 编辑协议表单与其他节点子页面。
+- 批量删除属于危险操作，必须保留明确确认文案并在成功后清空跨分页勾选状态。