diff --git a/ISSUE_DRAFT_feishu_unstable.md b/ISSUE_DRAFT_feishu_unstable.md
new file mode 100644
index 00000000..dc5de38d
--- /dev/null
+++ b/ISSUE_DRAFT_feishu_unstable.md
@@ -0,0 +1,39 @@
+# Issue 标题
+fix: 飞书群会话在模型鉴权/上游不可用时表现为间歇无响应，缺少明确错误反馈
+
+## 问题描述
+在飞书群聊场景中，Bot 已连接（WebSocket 正常）但对话会出现“时有时无、像断续工作”。
+结合日志可见：会话过程中存在模型侧 401/503 等错误，最终用户体感为 Bot 不稳定。
+
+当前问题不一定是飞书连接本身断开，而是模型调用失败时缺乏清晰、统一的失败提示与重试反馈，导致被误认为“飞书 Bot 不工作”。
+
+## 复现步骤
+1. 配置飞书群 Bot 并确保连接成功
+2. 在群里连续发送请求（尤其是长任务）
+3. 当上游模型出现 401（鉴权）或 503（暂时不可用）时，观察群内响应
+
+## 期望行为
+- 模型调用失败时给出明确可读错误（例如：鉴权失败/上游暂时不可用）
+- 对可重试场景进行有限重试，并在群内告知重试状态
+- 避免表现为“无响应”
+
+## 实际行为
+- 群内消息有时长时间无反馈或断续反馈
+- 用户难以区分是飞书链路问题还是模型侧问题
+
+## 环境信息
+- OS: Windows
+- ClawPanel: （请补充版本）
+- OpenClaw: （请补充版本）
+- 渠道: Feishu 群 Bot
+
+## 日志线索（关键）
+- 飞书连接已建立（ws connected）
+- 同时出现模型调用 401/503
+- 出现会话中断/超时体感
+
+## 建议方向
+1. 在飞书消息处理链路增加模型错误分类映射（401/429/5xx）
+2. 输出统一的用户可见错误文案
+3. 对 503/超时增加指数退避重试（有限次数）
+4. 在日志中增加 requestId 与 channel messageId 关联，便于排障
diff --git a/PR_DRAFT_gateway_guardian_windows.md b/PR_DRAFT_gateway_guardian_windows.md
new file mode 100644
index 00000000..630d00eb
--- /dev/null
+++ b/PR_DRAFT_gateway_guardian_windows.md
@@ -0,0 +1,44 @@
+# PR 标题
+fix: 修复 Windows 下 Gateway 运行态误判导致重复拉起
+
+## 问题描述
+在 Windows 环境中，`check_service_status` 的判定依赖两步：
+1. 端口连通（TCP）
+2. 通过 `netstat + 进程命令行` 识别到合法 Gateway PID
+
+当前逻辑在「端口已通，但命令行读取失败/受限」时会返回 `(false, None)`，被上层守护误判为 Gateway 未运行，进而触发自动拉起。结果是：
+- 重复启动日志（`Hidden-start Gateway on Windows`）
+- 端口冲突（18789 已占用）
+- 会话链路抖动，表现为“任务做一下停一下”
+
+## 修复方案
+修改 `src-tauri/src/commands/service.rs` 中 Windows 平台 `check_service_status`：
+- **端口可达即判定 `running=true`**
+- PID 识别仅作为增强信息（可为空）
+- 保留端口不通时清理 `LAST_KNOWN_GATEWAY_PID` 的逻辑
+
+核心改动：
+- 旧逻辑：端口通但 PID 识别失败 => `(false, None)`
+- 新逻辑：端口通但 PID 识别失败 => `(true, None)`
+
+## 影响范围
+- 平台：Windows
+- 模块：Gateway 服务状态检测 / 守护自动拉起
+- 受影响功能：
+  - Gateway 状态显示
+  - 自动重启策略触发频率
+  - 长任务连续执行稳定性
+
+## 测试建议
+1. **基础稳定性**
+   - 启动 Gateway 后观察 `~/.openclaw/logs/gateway.log` 5 分钟
+   - 不应再出现周期性重复 `Hidden-start Gateway on Windows`
+2. **状态检测回归**
+   - 服务页应稳定显示运行，不在运行/停止之间抖动
+3. **任务连续执行**
+   - 触发一个需要多轮执行的 Agent 任务，确认不会中途“停一下”
+4. **手动停止验证**
+   - 手动 stop 后应能正确识别为停止，不会误判运行
+
+## 风险评估
+当 18789 被“非 Gateway 进程”占用时，也会被识别为 running。该风险在现有启动流程中已有端口占用检查兜底（启动前拒绝占用端口），本次改动优先解决 Windows 下误判导致的重复拉起主问题。
diff --git a/src-tauri/src/commands/service.rs b/src-tauri/src/commands/service.rs
index e4e9aff2..c61bc573 100644
--- a/src-tauri/src/commands/service.rs
+++ b/src-tauri/src/commands/service.rs
@@ -944,14 +944,14 @@ mod platform {
             return (false, None);
         }
 
-        // 端口通了，获取真实 PID
+        // 端口通了，PID 识别仅作为增强信息
         if let Some(pid) = get_gateway_pid_by_port(port) {
             let mut known = LAST_KNOWN_GATEWAY_PID.lock().unwrap();
             *known = Some(pid);
             (true, Some(pid))
         } else {
-            // 端口通但找不到合法 Gateway PID → 可能是其他进程占用了端口
-            (false, None)
+            // 关键修复：避免因命令行查询失败误判为“未运行”并触发重复拉起
+            (true, None)
         }
     }