直接交给 Cursor 的执行提示词

建议以 next-flutter/ 为 Cursor 工作区，并附加以下文档。若以整个仓库为工作区，也要显式附加 Flutter 规则，不要依赖嵌套规则自动发现。

本文件是后续编码任务的提示词模板。本次交付只是开发指导文档，没有创建 Flutter 应用。

1. 首次启动

复制以下内容：

请在本仓库 next-flutter/ 中开发独立的 MooTool Next Flutter 桌面产品。

先完整读取：
- next-flutter/docs/cursor-development-guide.md
- next-flutter/docs/feature-parity.md
- next-flutter/docs/acceptance.md
- next-flutter/.cursor/rules/flutter-product.mdc

目标是布局、样式、功能和操作语义尽量与 next/ 当前 Electron 版一致，
并按主指南改善现代桌面 UI、可访问性和响应式，不是简单做 26 个菜单占位。

Java、Electron、Tauri、macOS Native、Flutter 均为独立产品线。
允许重复代码及独立演进；Flutter 必须独立源码、依赖、构建、版本、
安装名、应用 ID、数据、Vault、凭据、更新及卸载。
不能复用其他产品运行时，不能建立跨产品源码导入或共享活动数据库/Vault。

检查 git status，保留已有修改。记录当前提交与 next/package.json 版本，
阅读当前 Workbench、ToolPage、global.css 最后覆盖规则、toolRegistry 和测试。
注意旧截图已过时：当前工具为沉浸式、设置在主工作区，随手记支持列编辑，
图片有转 SVG。基线是首页加 25 个工具，共 26 个入口。

从 P0 执行，接着实现 P1 与 P2 的可运行纵向闭环：
1. 初始化独立 Flutter 桌面工程、固定工具链/依赖/产品 ID/数据路径。
2. 尽早做编辑器 IME/列编辑/undo、多窗口状态转移、已有 PDF 拆合、
   动态 proto 的真实样例，形成 ADR。不要用仅生成 PDF 的库冒充拆合，
   不要用静态生成的 Protobuf message 冒充运行时 schema。
3. 建立壳、主题、三语言、导航/搜索/设置和会话基础。
4. 做真实 JSON 格式化、保存、历史、Vault、查找及分离/收回和重启恢复。

这次优先交付 P0–P2，不表示删除 P3–P7。
每次交付完整用户流程、实际检查结果和截图，更新功能/验收状态及下一步。
平台暂不可验证时如实记录，继续当前环境可完成的实现。
普通选型和可逆工程工作自行决定；不要反复停在规划或请求确认。
不要自动发布 Release、安装覆盖真实应用、修改系统 Hosts/环境或用户真实数据。
涉及这些外部动作时先准备具体可审查结果；后续已有明确授权则按授权执行。

若希望 Cursor 连续推进全部阶段，将“这次优先交付 P0–P2”替换为：

按 P0–P7 连续推进全部开发，每阶段更新证据。不要把首个可运行原型
当成最终完成；持续处理功能清单中的未开始、开发中和待验收条目。
遇到必须由用户决定的问题时列出具体影响，同时继续不依赖该决定的工作。

2. 单工具开发

继续实现 <Tool ID / F编号>。
先读 Flutter 主指南、该工具功能规格，以及 next/ 对应页面、算法、
契约、主进程服务和测试。不要只看截图。

先列当前已实现、缺失和差异，再完成一个端到端流程：
输入/选择 → 实际操作 → 结果 → 保存/复制/导出 → 切页/重启恢复。
保留源工具布局、Tab 和主要按钮顺序，按 Flutter token 改善细节。
复杂语义用固定样本和真实文件验证，不用 mock 或简单正则替代完整能力。

完成后执行适用检查、真实界面操作、明暗/窄窗口截图，
更新 next-flutter/docs/acceptance.md 和本轮 evidence。
最终报告改了什么、实际验证了什么、仍缺什么、下一步是什么。

3. 断点续接

继续 MooTool Next Flutter 开发。先查看 git status、开发主指南、
feature-parity、acceptance 和最近 docs/evidence。
以代码和实际证据判断进度，不重新初始化已有工程，不覆盖其他人的修改。

找出最早未完成阶段的关键未闭环任务，继续实现并验证。
如果已有部分页面，不重做 UI 壳；优先补齐实际功能、数据持久化、
编辑器和窗口状态。保持独立产品边界，允许重复代码。

新增功能后同步细粒度状态，所有通过都引用实际运行结果。
不能把未运行的 Windows/Linux、系统提权或安装器测试写成通过。

4. 视觉与功能审查

审查 next-flutter 与冻结的 next/ Electron 基线。
按 feature-parity 的 26 个入口和 acceptance 逐项检查，
特别检查当前沉浸布局、设置页、列编辑、图片附件连续粘贴、
SVG、JSONPath、动态 Protobuf、真实 PDF 拆合、多窗口无损转移。

分别报告：
- 功能缺失/语义错误；
- 布局或操作心智偏离；
- Flutter 现代 UI 的一致性/可访问性问题；
- 数据、独立构建和安装更新隔离问题；
- 未执行测试或过度宣称完成。

对可直接修复的问题继续修复并验证。不要只写泛泛评价，
不要以旧截图的大标题和外边距否定当前沉浸布局。
完成记录须包含实际文件位置、复现步骤、预期/实际和验证结果。

5. 每轮交付报告格式

本轮完成：
对应功能/阶段：
具体实现文件：
实际测试命令与结果：
运行平台/架构/数据 profile：
截图与证据路径：
与 Electron 的明确差异：
未验证/失败/尚未实现：
下一轮首要动作：

不得把预计耗时、插件能力、Electron 已有测试或本规划中的检查项，当作 Flutter 本轮实际结果。