chore: 开源项目基础设施全面完善

新增配置文件:
- .editorconfig — 跨编辑器代码风格统一
- .gitattributes — 行尾符 CRLF 规范化
- .prettierrc + .prettierignore — 前端代码格式化
- .markdownlint.json — Markdown 格式规范
- commitlint.config.js — Conventional Commits 强制校验

新增 GitHub 社区文件:
- .github/dependabot.yml — 依赖自动更新 (npm + Cargo + Actions)
- .github/CODEOWNERS — 自动 PR 审查分配
- .github/FUNDING.yml — 开源赞助入口

新增文档:
- ROADMAP.md — v5.1/v5.2/v6.0 路线图
- SUPPORT.md — 帮助与支持指南
- docs/screenshots/ — 截图目录就位

新增 Git Hooks:
- .husky/pre-commit — lint-staged 自动格式化+修复
- .husky/commit-msg — commitlint 校验提交消息

CI 强化 (.github/workflows/ci.yml):
- 新增 Prettier 格式检查步骤
- 新增 cargo fmt --check 步骤
- 新增 Vitest 覆盖率生成 + Codecov 上报

修复:
- index.html 标题 v4.0 → v5.0
- PathEditDialog set-state-in-effect 改用 useRef prevOpen 守卫
- use-app-actions.test.tsx 缺失 @vitest-environment jsdom
- 所有 TS/TSX 文件 Prettier 格式化统一

配置更新:
- vitest.config.ts — v8 覆盖率 + 阈值门禁 (60%/70%)
- package.json — format/format:check/test:coverage/prepare 脚本 + lint-staged
- .gitignore — 新增 coverage/sync-conflict/playwright-report
- README.md — 新增 coverage + platform 徽章 + 截图区域

docs/REMAINING-ISSUES.md

@@ -0,0 +1,36 @@
+# 未修复问题清单
+
+> 从 v5.1 全面代码审查中筛选，暂不修复，留待后续评估。
+
+---
+
+## 1. CLI main.rs 单体文件 (639 行)
+
+**严重级别**: LOW  
+**文件**: `cli/src/main.rs`
+
+**问题**: 所有 18 条 CLI 命令集中在一个文件中。
+
+**建议**: 当前规模尚可维护，等到命令数超过 25 条或文件超过 1000 行时再拆分为 `commands/` 子模块。
+
+---
+
+## 2. GUI 命令层零测试
+
+**严重级别**: LOW  
+**文件**: `gui/src/commands/*.rs` (8 个文件)
+
+**问题**: GUI 命令层是纯薄包装，无独立测试。
+
+**建议**: 不值得投入 — 命令正确性由编译器类型系统保证，运行期由 57 个 core 测试 + E2E 覆盖。
+
+---
+
+## 已修复（本批次）
+
+- ~~disabled.rs 测试写入真实文件~~ → `#[cfg(test)]` 条件编译重定向到 `std::env::temp_dir()`
+- ~~profiles.rs 同款问题~~ → 同上
+
+---
+
+_更新于: 2026-05-30 | 审查批次: v5.1 代码审查_

docs/code-and-architecture-review.md

@@ -0,0 +1,79 @@
+# PathEditor v5.0 代码与架构审查报告
+
+## 1. 项目概览
+
+PathEditor v5.0 是一个功能完善的 Windows 系统环境变量 (PATH) 编辑器，支持 GUI 与 CLI 双模式。
+技术栈选型现代化且合理：
+
+- **后端 / 核心逻辑**：Rust (Cargo Workspace)
+- **GUI 框架**：Tauri 2.x
+- **前端**：React 19 + TypeScript + Zustand
+
+整体项目结构清晰，职责划分明确，严格遵循了前后端分离与核心逻辑无平台依赖的设计原则。
+
+## 2. 架构设计审查
+
+### 2.1 Cargo Workspace 三层架构
+
+项目采用了经典的 Cargo Workspace 模式，分为三层：
+
+- `core`: 纯 Rust 库 crate，包含所有的核心业务逻辑（注册表读写、备份、配置文件管理、路径验证与清理等）。该层**完全不依赖** Tauri 或 CLI 库，极大地提高了代码的复用性和可测试性。
+- `gui`: Tauri 桌面应用。仅作为薄包装层（Thin Wrapper），通过 `#[tauri::command]` 将 `core` 的功能暴露为 IPC 接口供前端调用。
+- `cli`: 命令行工具层。依赖 `core` 和 `clap` 库，直接提供命令行交互能力。
+
+**审查结论**：架构设计非常优秀。核心逻辑解耦彻底，无论是 GUI 还是 CLI 都能复用同一套安全、经过测试的核心代码。
+
+### 2.2 IPC 通信与状态同步
+
+前端与 Rust 后端通过 Tauri IPC 进行通信。
+
+- 所有的错误处理均通过 `Result<T, String>` 返回，前端通过 `Promise` 捕获并处理，用户体验良好。
+- 针对非事务性的双写操作（如同时保存系统和用户 PATH），前端 `app-store.ts` 中使用了 `Promise.allSettled`。当发生部分成功（Partial Success）时，能正确捕获并重新加载注册表状态，避免了前端内存状态与后端注册表状态的漂移（State Drift）。
+
+## 3. 后端代码审查 (Rust)
+
+### 3.1 核心逻辑 (`core`)
+
+- **安全性与健壮性**：
+  - 在 `registry.rs` 中，严格检查了路径字符串的 Null 字节，以及 32767 个字符的 Windows 注册表长度上限，防止缓冲区溢出或写入失败。
+  - 使用了安全的 `winreg` 库进行注册表操作。
+- **FFI 调用**：
+  - 在 `system.rs` 中调用 Windows API（如 `ExpandEnvironmentStringsW` 和 `SendMessageTimeoutW`）时，对 `unsafe` 代码块进行了详尽的 SAFETY 注释。
+  - 能够妥善处理 UTF-16 编码和解码，保留非法码点避免丢失路径信息，细节处理非常到位。
+
+### 3.2 命令行工具 (`cli`)
+
+- **原子性与并发安全**：
+  - 在 CLI 的 `verify_and_save` 逻辑中，写入前会重新读取注册表并与原始状态对比。如果不一致，则拒绝写入并报错退出。这有效地防止了并发情况下的配置覆盖问题。
+- **用户体验**：
+  - 命令设计符合直觉，支持 `--dry-run` 预览以及 JSON 格式输出，方便与其他脚本集成。
+
+## 4. 前端代码审查 (React + TypeScript)
+
+### 4.1 状态管理 (`app-store.ts`)
+
+- 使用 `Zustand` 进行全局状态管理，状态树设计合理，避免了 React Context 可能带来的不必要重渲染。
+- 实现了完善的 `UndoRedoManager`，将每一步操作抽象为 `OperationType`，支持撤销/重做功能，这对于编辑器类应用来说是核心体验的加分项。
+- `isSaving` 状态守卫有效防止了用户双击保存按钮引发的并发竞争。
+
+### 4.2 UI 与逻辑分离
+
+- 业务逻辑抽象到 `src/core` 目录下（如 `path-manager.ts`, `validation.ts`），UI 组件仅负责渲染和事件绑定。
+- `useAppActions.ts` 钩子巧妙地将组件层与 Store 状态操作解耦，使得组件代码极其整洁。
+
+## 5. 改进建议 (Recommendations)
+
+虽然当前代码质量已经很高，但仍有以下几个方面可以进一步优化：
+
+1. **Rust FFI 维护性**：
+   当前 `system.rs` 中手动声明了 `extern "system"` 函数。建议引入 `windows-rs` 或 `windows-sys` 库，这能提供微软官方维护的安全的 API 绑定，减少手动编写 FFI 签名带来的维护成本和潜在错误。
+2. **GUI 保存的并发安全 (Race Condition)**：
+   CLI 已经实现了保存前的二次状态比对（`verify_and_save`），但在 `gui/src/commands/registry.rs` 中，直接调用了 `save_system_paths`。如果在用户打开 GUI 修改期间，另一个进程修改了注册表，GUI 保存时可能会覆盖该修改。建议在 GUI 的 IPC 保存接口中，也引入类似 CLI 的版本校验（例如传入 `expected_original_paths` 进行比对）。
+3. **前端单元测试覆盖**：
+   核心逻辑如 `undo-redo.ts` 和 `path-manager.ts` 纯函数特性明显，建议在 `tests/unit/` 下增加对这些文件的边界用例测试，确保复杂编辑操作下状态不崩溃。
+4. **长列表性能**：
+   如果 PATH 环境变量条目非常多（虽然实际场景中一般在 100 条以内），React 渲染完整列表可能会有微小延迟。当前规模下无影响，但若未来考虑显示大量工具链路径扫描结果，可引入虚拟列表（Virtual List）。
+
+## 总结
+
+PathEditor v5.0 的代码库是一个优秀的 Rust + Tauri + React 实践范例。它具有清晰的三层架构、严格的类型和边界检查、以及良好的错误处理机制，整体架构稳健且易于长期维护。

docs/screenshots/.gitkeep

@@ -0,0 +1 @@
+# 截图目录