chore: update gitignore and add GUI renovation guide

Author: Haaaiawd

.gitignore

@@ -12,6 +12,7 @@ docs/
 # Rust / Cargo #
 ###############
 target/
+target_*/
 **/*.rs.bk
 Cargo.lock.bk
 
@@ -49,4 +50,16 @@ logs/
 .env
 .env.*
 .env.local
-*.local.yaml
+*.local.yaml
+
+########################
+# Temporary / Junk     #
+########################
+debug_*/
+tmp/
+temp/
+nul
+*.tmp
+*.bak
+implementation_plan.md
+task.md

Cargo.lock

@@ -30,6 +30,7 @@ tauri-build = { version = "2.0.0", features = [] }
 winres = "0.1"
 
 [dependencies]
+service = { path = "./service" }
 serde = { version = "1.0", features = ["derive"] }
 serde_json = "1.0"
 serde_yaml = "0.9"

Cargo.toml

@@ -0,0 +1,38 @@
+# PromptKey Deep Teardown & Recovery Report
+
+## 1. 核心问题扫描 (Problem Audit)
+
+在实现 **PromptWheel** 的过程中，系统出现了严重的失稳，主要表现为：
+1. **Service 启动即崩溃**：日志显示 `os error 2`。
+2. **GUI 启动 Sidecar 失败**：出现 `os error 50`。
+3. **构建流程锁死**：`cargo build` 频繁提示“拒绝访问”。
+
+## 2. 深度拆解分析 (Architectural Root Causes)
+
+### A. 命名管道服务端误用 (The IPC Socket Bug)
+- **现象**：Service 无法创建 `promptkey_inject` 管道。
+- **原因**：在将异步代码同步化的过程中，代码错误地使用了 `std::fs::OpenOptions`。在 Windows 上，`std::fs` 只能作为管道客户端，尝试打开一个不存在的管道服务端会导致 `os error 2` 或崩溃。
+- **影响**：后端注入功能彻底瘫痪，服务线程陷入死循环或退出。
+
+### B. Sidecar 加载链路脆弱 (Path Resolution Fragility)
+- **现象**：GUI 报 `os error 50` (不支持该操作)。
+- **原因**：`resolve_service_exe_path` 返回的是相对路径，且在 `Command::spawn` 时没有进行绝对路径转换。当 GUI 和 CWD 不一致时，路径失效。此外，`CREATE_NO_WINDOW` 标志在路径失效或二进制文件损坏时会抛出混淆的系统错误。
+- **影响**：GUI 无法可靠地拉起后端引擎。
+
+### C. 僵尸进程与构建冲突 (Zombie Process Interference)
+- **现象**：构建报错 `Access Denied`。
+- **原因**：之前的 Service 进程虽然逻辑崩溃，但句柄未释放，导致产生的 `.exe` 文件被锁定。连续的增量构建尝试在文件锁争用下失败。
+
+## 3. 修复方案 (The Recovery Strategy)
+
+1. **重构 IPC 服务端**：放弃原生 Win32 API 调用（易错），改用 `tokio` 的命名管道服务端，但在 Service 内部通过专用线程运行本地运行时。这保证了**服务端能力**的同时维持了主循环的**同步简洁性**。
+2. **绝对化路径管理**：在 GUI 中引入 `std::fs::canonicalize`，确保传递给系统的命令路径永远是**绝对路径**。
+3. **环境深度清理**：通过强制任务管理器级的 `taskkill`，扫除所有残留的 `promptkey` 和 `service` 实例。
+
+## 4. 当前状态与后续建议
+
+- **状态**：Service 编译已通过。GUI 正在进行最后的 Link 阶段。
+- **建议**：
+  - 启动时务必确认没有旧版图标留在托盘。
+  - 使用 `Ctrl + Alt + Q` 作为轮盘唤起热键，避免与常用软件冲突。
+  - 定期清理 `target` 目录以保持构建产物的纯净。

DEEP_TEARDOWN_REPORT.md

@@ -0,0 +1,96 @@
+# PromptKey GUI Renovation & Evolution Guide
+
+## 1. 演进总结 (Evolution Summary)
+
+我们从一个基础的 **"CRUD 管理后台"** 进化为了一个 **"现代化桌面生态系统"**。
+
+| 维度 | V1 初始状态 | V2 当前目标状态 | 核心差异 |
+| :--- | :--- | :--- | :--- |
+| **设计语言** | 通用 Admin 风格 (Light Theme, 朴素) | **Zinc/Slate 深色工业风** (匹配 PromptWheel) | 需要引入 `wheel.css` 中的 Zinc 色板变量，保证视觉一致性。 |
+| **数据结构** | 简单的 `name`, `content` | **复杂元数据** (`tags` 数组, `app_scopes`, `version`) | 前端表单需要支持 JSON 序列化和标签输入组件。 |
+| **交互模式** | 基础表单提交 | **富交互** (Tag 芯片, 应用范围选择器) | 需要更高级的 UI 组件来处理复杂字段。 |
+| **定位** | 简单的数据库编辑器 | **Prompt 工程控制台** | 界面需要体现"配置"和"规则"的专业感。 |
+
+---
+
+## 2. 视觉重构规范 (Visual Renovation)
+
+主窗口 (`index.html`) 不需要像轮盘那样完全透明异形，但必须共享 **"PromptKey Design System"**。
+
+### 2.1 共享色板 (Shared Palette)
+请在 `styles.css` 中定义以下核心变量（提取自 `wheel.css`）：
+
+```css
+:root {
+    /* Zinc Scale (Dark Mode Base) */
+    --pk-bg-base: #09090b;       /* Zinc 950 */
+    --pk-bg-surface: #18181b;    /* Zinc 900 */
+    --pk-border: #27272a;        /* Zinc 800 */
+    --pk-text-primary: #fafafa;  /* Zinc 50 */
+    --pk-text-secondary: #a1a1aa;/* Zinc 400 */
+    
+    /* Brand Colors */
+    --pk-accent: #3b82f6;        /* Modern Blue */
+    --pk-danger: #ef4444;
+}
+
+body {
+    background-color: var(--pk-bg-base);
+    color: var(--pk-text-primary);
+    font-family: 'Inter', system-ui, sans-serif;
+}
+```
+
+### 2.2 组件风格
+*   **卡片/面板**：使用 subtle border (`1px solid var(--pk-border)`) 代替沉重的阴影。
+*   **按钮**：扁平化，Hover 时轻微背景色变化，避免 3D/拟物感。
+*   **输入框**：深色背景 (`--pk-bg-surface`)，去边框或仅保留底部边框。
+
+---
+
+## 3. 功能模块改造 (Feature Updates)
+
+根据 `service/src/db.rs` 的最新结构，**"管理提示词" (Prompts Panel)** 需要重大升级。
+
+### 3.1 提示词数据结构变更
+后端 `Prompt` 结构已更新，前端必须同步适配：
+
+| 字段名 | 旧版处理 | **新版需求 (V2)** | 前端改造点 |
+| :--- | :--- | :--- | :--- |
+| `tags` | 文本字符串 | **`Vec<String>` (JSON)** | **Tags Input 组件**：输入回车生成 Tag 芯片，提交时序列化为 `["tag1", "tag2"]`。 |
+| `app_scopes_json` | 无 | **`Option<String>` (JSON)** | **应用范围选择器**：允许用户输入目标 App 名称（如 `notepad.exe`），支持多选。 |
+| `inject_order` | 无 | **`Option<String>`** | **排序权重输入**：允许设置权重 (如 "10")。 |
+| `version` | 无 | **`i32`** | 只读展示，每次编辑自动 +1。 |
+
+### 3.2 新增/编辑模态框 (Modal Renovation)
+现有的简单表单必须重写，布局建议：
+
+*   **Header**: 标题 + 快捷操作。
+*   **Body (双栏布局)**:
+    *   **左栏 (Content)**: 大面积的 `textarea`，支持语法高亮（未来），用于编辑 Prompt 内容。
+    *   **右栏 (Metadata)**:
+        *   **Name**: 提示词名称。
+        *   **Tags**: 交互式 Tag 输入。
+        *   **App Scopes**: "生效应用" (如 `chrome.exe`)。
+        *   **Variables**: 变量定义 (JSON)。
+*   **Footer**: 取消/保存按钮。
+
+---
+
+## 4. 前端助手任务清单 (Tasks for Frontend Assistant)
+
+请将此清单交给前端助手执行：
+
+1.  **样式同步 (`styles.css`)**: 
+    - [ ] 废弃旧的 `theme-light`，全面切换到 **Zinc Dark Theme**。
+    - [ ] 引入 `wheel.css` 中的变量，确保主窗口和轮盘视觉一致。
+2.  **JS 逻辑升级 (`main_simple.js`)**:
+    - [ ] 更新 `fetchPrompts` 和 `savePrompt` 逻辑，处理 Rust 后端新的 JSON 字段 (`tags`, `app_scopes_json`)。
+    - [ ] 如果 `tags` 从后端拿到是 JSON string，前端需要 `JSON.parse()` 转为数组显示。
+3.  **UI 组件开发**:
+    - [ ] 实现一个轻量级的 **Tags Input** (输入文本 -> 回车 -> 生成可删除的 `<span>` 标签)。
+    - [ ] 优化列表页展示：在列表中显示 Tags 芯片，而不仅仅是文本。
+
+---
+
+**核心口号**：让管理后台配得上那个漂亮的轮盘。

GUI_RENOVATION_GUIDE.md

@@ -0,0 +1,129 @@
+# PromptKey 启动与调试指南
+
+## 🚀 正确启动步骤（确保使用最新构建）
+
+### 方案 A：完整重新构建（推荐）
+```bash
+# 1. 先杀掉所有旧进程
+taskkill /F /IM service.exe 2>nul
+taskkill /F /IM promptkey.exe 2>nul
+
+# 2. 重新构建 Service
+cd d:\PROJECTALL\Workflow\PromptKey
+cargo build --release -p service
+
+# 3. 复制到 sidecar（供 GUI 启动用）
+cp target/release/service.exe sidecar/service-x86_64-pc-windows-msvc.exe
+
+# 4. 构建并运行 GUI
+cargo run --release
+```
+
+### 方案 B：快速测试（分开运行，便于看日志）
+```bash
+# Terminal 1: 单独运行 Service（可以看到详细日志）
+cd d:\PROJECTALL\Workflow\PromptKey
+$env:RUST_LOG="info"
+./target/release/service.exe
+
+# Terminal 2: 运行 GUI（注释掉 src/main.rs 中的 ServiceState 启动代码）
+cargo run --release
+```
+
+## 🔍 诊断检查清单
+
+### 1. 确认 Service 版本正确
+运行 Service 后查看日志开头，应该看到：
+```
+[INFO] Configuration loaded successfully
+[WARN] ⚠️ Configured hotkey 'Ctrl+Shift+H' conflicts with Selector Panel. Resetting...
+```
+
+如果看到这个警告，说明配置自愈生效了！
+
+### 2. 确认 IPC 通道建立
+运行 GUI 后查看日志，应该看到：
+```
+[IPC] Starting listener on \\.\pipe\promptkey_selector
+```
+
+### 3. 测试热键
+按下 `Ctrl+Shift+H`，Service 日志应该显示：
+```
+[INFO] Selector hotkey detected (ID=3), sending IPC to GUI
+[INFO] IPC: Sent SHOW_SELECTOR to GUI via \\.\pipe\promptkey_selector
+```
+
+GUI 日志应该显示：
+```
+[IPC] Received: SHOW_SELECTOR
+[IPC] Selector window shown via IPC
+```
+
+## 🐛 如果还是"直接粘贴"
+
+### 问题1：配置冲突未解决
+**症状**：日志显示 `Injection hotkey detected (ID=1 or 2)`
+**原因**：`%APPDATA%\PromptKey\config.yaml` 中 `hotkey: Ctrl+Shift+H`
+**解决**：
+```bash
+# 删除配置文件，强制重新生成
+del "%APPDATA%\PromptKey\config.yaml"
+```
+
+### 问题2：旧 Service 进程未杀干净
+**症状**：重启后行为没变化
+**检查**：
+```bash
+tasklist | findstr service
+```
+**解决**：
+```bash
+taskkill /F /IM service.exe
+```
+
+### 问题3：IPC 通道未建立
+**症状**：日志有 "Failed to send selector IPC" 或 "Failed to open named pipe"
+**原因**：GUI 的 IPC Listener 未启动或崩溃
+**检查**：GUI 日志中搜索 "[IPC]"
+**解决**：确认 `src/ipc_listener.rs` 存在并在 `src/main.rs` 中正确注册
+
+## 📝 当前状态
+
+✅ **已完成**：
+- IPC Listener 已实现（`src/ipc_listener.rs`）
+- 配置自愈已添加（`service/src/main.rs`）
+- Service 二进制已更新（09:08 构建）
+- Sidecar 已更新
+
+⏳ **待验证**：
+- 确认新 Service 进程启动
+- 确认 IPC 通道连接成功
+- 确认 `Ctrl+Shift+H` 触发 Selector
+
+## 🎯 预期行为
+
+正确配置后：
+1. **Ctrl+Alt+Space** → 直接粘贴当前选中的 Prompt（注入模式）
+2. **Ctrl+Shift+H** → 弹出选择面板（新功能）
+
+## 📊 日志级别设置
+
+如果需要更详细的调试日志：
+```bash
+# Service
+$env:RUST_LOG="debug"
+./target/release/service.exe
+
+# GUI (在 .cargo/config.toml 或环境变量)
+$env:RUST_LOG="debug"
+cargo run --release
+```
+
+---
+
+**最后提醒**：每次修改代码后，必须：
+1. 重新 `cargo build --release -p service`
+2. 复制到 `sidecar/`
+3. 杀掉旧 `service.exe` 进程
+4. 重新运行 `cargo run --release`