ShaoHua
6.3 KiB
6.3 KiB
Hua.Todo 产品需求文档 (PRD) v1.2.0
1. 项目概述
在 v1.1.0 版本成功实现 MAUI + WebView 跨平台架构的基础上，v1.2.0 版本将以“MAUI 入口保持不动 + Linux 新增 Avalonia 入口”的方式落地 Linux 支持（继续使用 WebView 承载 Vue 前端），并在此基础上探索 Avalonia 对其他终端的支持情况；若验证效果良好，后续版本将推进各终端入口统一切换到 Avalonia。
2. 核心目标
- 完善平台覆盖：正式支持 Linux 平台。
- 增强任务组织：引入搜索。
- 云同步（基础可用）：支持用户级任务数据同步与“可控落盘”（在不信任终端场景下可禁止落盘）。
3. 功能需求
3.1 平台支持：Linux 官方支持
- 客户端框架迁移：保持原 MAUI 项目不动，实现 Avalonia 对 Linux 端支持，并探索 Avalonia 对 Android 和其他平台的支持。
- 终端入口策略（v1.2.0）：
- 保持 MAUI 入口不动：Windows/macOS/iOS/Android 继续沿用现有 MAUI 入口与 WebView 方案，保证迭代稳定性。
- Linux 使用 Avalonia 作为入口：新增 Avalonia 桌面端宿主作为 Linux 入口，继续用 WebView 承载同一套 Vue 前端，并复用既有“本地 API ↔ 前端”的交互协议。
- 评估全端切换可行性：在完成 Linux 入口落地后，评估 Avalonia 在 Windows/macOS（以及后续 Android 等）的稳定性、WebView 兼容性与打包成本；若效果良好，后续版本将各终端入口统一切换到 Avalonia。
- 适配性：确保 WebView 在 Linux 环境下的正常渲染与交互。
- 打包部署：提供 Linux 平台的打包脚本（如 .deb 或 .tar.gz）。
3.2 任务检索 (Search)
- 关键词搜索：在主界面顶部增加搜索框，支持按任务标题模糊匹配。
3.3 云同步（基础可用）
3.3.1 服务端地址配置（用户手动指定）
- 用户手动指定服务端地址：首次启用同步时，用户需要手动填写服务端地址（例如
https://example.com），并允许后续在设置中修改。 - 地址有效性提示：客户端需对地址格式做基础校验，并在保存时提示可达性/证书异常等风险信息。
3.3.2 权限与二次认证（RBAC + 二次认证）
- RBAC 权限模型：服务端必须提供基于角色/权限的访问控制（Role-Based Access Control），以支持后续按功能、数据域进行授权。
- 二次认证：对高风险操作（例如启用/关闭同步、切换账号、调整“是否允许落盘”等安全相关配置）应支持二次认证机制（例如二次口令/一次性验证码等），具体实现以服务端能力为准。
3.3.3 基于用户的数据隔离
- 用户级数据隔离：服务端必须按用户隔离任务数据，任何同步、检索与配置读取都必须绑定当前登录用户上下文。
- 最小权限原则：客户端仅请求完成任务同步所需的最小权限范围，避免默认授予不必要的数据访问能力。
3.3.4 同步工作流（登录后获取任务 + 可控落盘）
- 登录后拉取任务：用户登录成功后，客户端从服务端获取该用户的任务信息并更新到前端展示。
- 服务端配置驱动的落盘策略：客户端需读取服务端针对该用户（或该会话/终端）的安全配置，决定任务信息是否允许落盘到本地存储。
- 不信任终端禁止落盘：当服务端标记“终端不可信/不允许落盘”时，客户端只能在内存中持有任务信息；退出应用后不保留任务数据。
4. 技术实现要点
4.1 Linux 适配
v1.1.0 起客户端使用 MAUI WebView 承载 Vue 前端；在 v1.2.0 中，保持现有 MAUI 入口不动，同时为 Linux 新增 Avalonia 桌面端入口，并继续以 WebView 承载同一套 Vue 前端。后续将基于 Linux 端落地经验评估 Avalonia 对 Windows/macOS（以及后续 Android 等）的覆盖与稳定性，满足条件后推进全端入口统一。
4.1.1 Linux 解决方案（Avalonia 入口 + WebView 承载 Vue）
- 入口与架构：Linux 端新增 Avalonia 桌面宿主作为应用入口；加载同一套 Vue 前端，并保持与现有 MAUI 端一致的“前端调用本地 API”协议与数据模型，确保业务逻辑与 UI 复用。
- WebView 方案：选用可在 Avalonia/Linux 运行的 WebView 控件承载前端（以 WebKitGTK/Chromium 系为候选实现），统一约束：支持基础导航/本地资源加载、JS ↔ Native 双向通信、DevTools（至少开发环境可用）。
- 发行版与依赖策略：定义最低支持范围（例如 Ubuntu LTS 系列作为基线），并将 WebView 运行时依赖纳入打包交付（避免用户手动安装大量依赖导致不可用）。
- 输入法/字体/DPI：提供默认 CJK 字体与渲染配置，验证 IME、缩放、Wayland/X11 关键组合；遇到环境差异时以“可配置 + 明确降级”保证可用性。
- 快捷键策略：全局快捷键在 Linux 上采用“尽力而为”的可插拔实现；在 Wayland 等受限环境下自动降级为应用内快捷键，并在设置中提供可配置与提示。
- 交付形式：优先提供一种“自包含”的交付产物（例如 AppImage/Flatpak 之一）作为官方安装方式，同时保留
.deb/.tar.gz作为补充分发形式（以脚本产出为准）。
5. 版本规划
5.1 v1.2.0 目标
- Linux 平台完整支持与打包脚本。
- 搜索框（关键词检索）。
- 云同步（基础可用：用户手动配置服务端地址、RBAC + 二次认证、用户级数据隔离、服务端配置驱动的可控落盘）。
5.2 后续版本规划
- v1.3.0：数据导入导出（JSON）、统计图表（任务完成趋势、时间分配分析）。
- v1.4.0：高级过滤（优先级/时间段）与更丰富的视图（如看板/日历）。
6. 风险评估
- Linux 碎片化：不同发行版下 WebView 的依赖库可能不一致。
- 凭据与合规：第三方服务鉴权方式差异大，且必须保证凭据安全存储与最小化权限。
- 终端可信度与数据落盘：若需支持“不信任终端不落盘”，需要明确“可信度判定与配置下发”的服务端策略，并保证客户端在无落盘场景下的可用性与体验。