迭代19-21收尾: 指示灯自适应探测（R-022/R-023）+ 列设置拖拽排序（R-024）+ Tab设置间隙线统一（R-025）+ 需求池归档（R-014/15/16/17/19 → 已完成）

2026-09-10 14:04:51 +08:00
parent 8782aa9c50
commit 3dfa39b8bf
29 changed files with 1216 additions and 72 deletions
@@ -0,0 +1,36 @@
+# 需求：R-023 MCP 状态灯自适应探测（MCP 服务恢复后自动回绿）· 讨论中
+
+> 登记：2026-09-09 ｜ 来源：老师反馈（R-022 之后实测 MCP 灯同样不自动恢复）｜ 状态：**讨论中（AI 提议定稿，待老师确认）**
+> 归属：迭代 19-指示灯状态自适应探测 ｜ 实现状态：已实现（待验收）
+
+## 症状（老师反馈，2026-09-09）
+
+QMT 健康灯修复后复查发现：会话头部 MCP 指示灯也存在同样的「状态不自动恢复」——
+MCP 服务（QMT Bridge /mcp）启动/恢复后，MCP 灯停留在上次失败态，不会自动回绿。
+
+## 根因
+
+QmtMcpManager 的**状态缓存只在 挂载 / 配置切换 / 手动探测（点击「检测 MCP」）时刷新**，无任何定时回路；
+sync-status 端点每 10s 读的只是这份缓存。dsh-mcp-client 自带的 reconnect 只恢复**真实连接**
+（fiber 层），并不刷新插件自己的状态缓存——所以「连接恢复了、灯还是红的」。
+
+## 方案（AI 提议，与 R-022 同模式，owner = QmtMcpManager）
+
+**结果驱动自适应探测**（对齐 QmtHealthMonitor）：
+
+- connected → 每 5 分钟探测一次（稳态，低开销）；
+- 非 connected（error/异常）→ **每 10 秒快速重试**——MCP 服务恢复后灯 ≤20s 自动回绿；
+- 无激活连接（url 为空）不探测不调度；dispose() 后停止调度；
+- 探测仍走 SDK 独立只读握手（Client connect → initialize + tools/list），与 dsh-mcp-client 自管连接互不干扰。
+
+**边界（不做）**：不接管/不替代 dsh-mcp-client 的重连（那是真实连接层，保持现状 Q5）；
+不新增配置项（间隔为常量，测试经构造参数注入）；前端/API 零改动（getStatus 读缓存语义不变）。
+
+## 决策记录
+
+| 项 | 结论 | 讨论 |
+|---|---|---|
+| 非连接态重试间隔 | 10s | 与前端 sync-status 10s 轮询、R-022 QMT 灯一致；MCP 探测最坏挂 8s 超时，快失败场景成本可忽略 |
+| 已连接稳态间隔 | 5 分钟 | 与 R-022 一致；MCP 握手比重（initialize+tools/list），健康态不空转 |
+| 调度停止条件 | 无激活连接 / dispose / unmount | 无 url 时探测早退置 disabled 并取消定时器，避免空转 |
+| 并发防护 | _probing 去重（同 QmtHealthMonitor._inFlight） | 定时器与手动/热切换探测可能撞车 |