用 TaskBelay 推进Notepad-- macOS 原生迁移
把一个 Qt 编辑器迁移到 macOS 原生组件，需要协调功能取舍、技术实现和反复验证。Notepad-- 使用 Codex 与 TaskBelay 配合推进：Codex 负责分析与实现，TaskBelay 把计划、进度和检查结果留在同一任务中。
先把计划说清楚，再把每一步接起来。
从需求确认到测试返工，TaskBelay 让约定、当前进度与接下来的工作保持连贯。
作者自用案例 · 根据开发过程编辑整理
01 / 目标与分工
目标明确，分工清楚。
- 用户
- 提出需求、确认计划与取舍，检查最终功能。
- Codex
- 分析代码、提出方案、实现功能、执行检查并提交结果。
- TaskBelay
- 保存任务状态与约定，核对范围和验证安排，按提交结果推进阶段。
- 开发目标
- 把 Notepad-- 迁移到 Apple 原生组件，目标兼容 macOS 15，采用 macOS 27 可用能力，并减少低版本动效。
- 明确取舍
- 保留约定范围内的已有功能；不使用 Qt、Scintilla，不实现对比功能和旧 Qt 插件兼容。
- 实际产物
- AppKit、SwiftUI、NSTextView/TextKit 原生工程，需求与实施文档，以及本地 Universal DMG。
02 / 开发过程
从一个想法，到可执行的工作。
明确范围、确认计划、处理返工、核对进展。把大任务拆成能理解、能继续的每一步。
需求与职责
先把目标说清楚，开发才有方向
目标很明确：让 Notepad-- 成为真正的 macOS 原生应用，同时保留日常编辑所需的能力。讨论很快从“用什么技术”落到了更具体的问题：哪些功能必须保留，哪些内容明确不做。
- TaskBelay 如何参与
- 把确认后的需求和排除项留在任务中，让后续设计、实现与复查围绕同一份约定展开。
- 推进结果
- 技术方向和功能范围明确下来，计划可以围绕具体目标展开。
展开过程：技术与功能怎样取舍
- 选择原生路线
- 采用 AppKit、SwiftUI 与系统文本编辑组件，不再依赖 Qt 或 Scintilla。窗口、菜单、文档操作与编辑体验都围绕 macOS 重新实现。
- 守住功能范围
- 保留多文档、搜索替换、列编辑、高亮折叠、编码转换与恢复等约定能力；排除对比功能和旧插件兼容，大文件与十六进制继续只读。
- 提前约定兼容方式
- 最低支持目标设为 macOS 15，新系统采用可用的新能力，旧系统减少动效。现有 Qt 工程保留，原生版本独立开发。
拆解实施计划
先确认完整计划，再进入实现
Codex 将原生迁移整理成 10 项工作和 12 项验收要求，覆盖工程、编辑器、搜索、工具与验证。TaskBelay 保存计划并等待确认；用户回复“开始”后，任务进入实现阶段。
- TaskBelay 如何参与
- 把计划与确认状态保存在一起，让后续工作围绕已同意的范围展开。
- 推进结果
- 用户确认的是已经保存的计划；后续实现可以回到这份计划核对。
展开任务操作
这次任务中的计划确认与阶段切换。
- 草稿保存后
TASKS · COMPLETE_TASKS允许读取与整理计划，等待确认。
- 用户回复
开始确认后提交同一份计划。
- TaskBelay 返回
IMPLEMENT · COMPLETE_IMPLEMENTATION当前允许的行为开始包含修改产品文件。
展开过程：工作与验收怎样对应
- 先对照，再迁移
- 先梳理原版真正具备的功能，为保留能力建立对应关系，再安排工程、编辑器、搜索和工具等实现工作。
- 改动位置清楚
- 新增独立原生工程与配套文档，列出预计修改的文件范围，旧 Qt 源码保持不动。
- 检查跟着功能走
- 把中文输入、多光标撤销、安全保存和恢复等关键行为列入验证，初始安排 20 次自动检查命令。没有实机环境的兼容性项目单独记录。
测试与修复
遇到失败，修复与复测接着走
保存状态和 UI 检查发现问题后，Codex 提交失败原因，TaskBelay 将任务带回实现阶段。修正文档通知和启动参数后，再次提交实现并复测。需要用户处理的系统提示也留在当前任务中，处理后接着推进。
- TaskBelay 如何参与
- 记录失败并切回需要修复的阶段。TaskBelay 接收检查结果；定位问题和修复代码由 Codex 执行。
- 推进结果
- 从修复代码到重跑检查，再到更新安装包，每一步都能回到同一任务查看。
一次补充验证的安排
- 原额度已用完
- 20 次
- 补充明确的检查
- +4 次
修复已经改变了源码，还需要重新跑原生回归、构建并检查安装包，才能确认这次修改的结果。
- 完整原生测试
- 当前 Release 构建
- DMG 打包
- DMG 校验
这是第一次追加检查。整份迁移记录共保存 8 次额度调整，自动命令额度从 20 增至 37；每次都附有原因和待执行的检查。
20 → 24 → 28 → 29 → 30 → 31 → 32 → 36 → 37
展开任务操作
这次任务中的计划确认与阶段切换。
- 提交失败结果
taskbelay_submit_test记录失败原因，选择返回实现。
- 记录中的阶段变化
TEST → IMPLEMENT下一步重新包含产品文件修改。
- 修复后的下一步
IMPLEMENT → TEST提交修复，按当前内容继续检查。
展开过程：两次失败如何处理
- 文件存好了，界面却没更新
- 保存后的内容完整，但侧栏仍显示旧文件名和“未保存”标记。排查后修正了文档状态的通知方式，让列表随保存结果更新。
- 测试没跑通，先找阻断原因
- 一个测试参数被误当成文件名，触发对话框，挡住查找和撤销操作。调整测试启动设置后，重新运行相关流程。
- 修复与交付保持一致
- 修复后重新运行 UI、文档与编辑检查，再按最新源码构建和校验 Universal 安装包。
核对进展
回到最初的计划，明确接下来做什么
原生工程和安装包产出后，用户与 Codex 再次对照实施计划和原版功能。跨文档搜索、批量操作、语言样式等能力被逐项核对，后续需要补齐的工作有了具体内容。
- TaskBelay 如何参与
- 保留最初的约定和开发过程，为逐项核对功能提供参照。
- 推进结果
- 已经实现的能力与后续工作更加清楚，下一步可以围绕具体功能展开。
展开过程：如何核对功能
- 对照搜索场景
- 围绕单个文档与全部已打开文档，分别核对查找和替换能力。
- 细化批量操作
- 把多组替换规则、规则导入导出和批量重命名分别列出，逐项检查。
- 明确继续完善的内容
- 将语言样式、摘要工具与本地化纳入后续功能完善，保持与原计划的对应关系。
03 / 成果与收获
工作在推进，过程始终清楚。
长任务中的三个帮助
- 开工前，把功能、文件范围和检查安排放在一起确认。
- 返工时，带着失败原因和已有进度继续处理。
- 追加检查时，说明具体用途，让每次验证有明确目标。
已经落地的成果
- AppKit、SwiftUI 与系统文本组件组成的原生工程。
- 文档读写、编辑、搜索与恢复等核心功能。
- 可回看的需求与实施计划，以及本地 Universal DMG 安装包。
原生工程与 Universal 安装包已产出
原生工程和核心功能已经落地。完整功能迁移与兼容性验收，是接下来继续完善的重点。
从界面操作到安装包，逐项检查。
- 3 / 3UI 复测
三项 UI 流程通过
- 9 / 9相关回归
文档与编辑相关检查
- DMG安装包校验
Universal 安装包校验通过
UI、文档与编辑检查在本机环境执行，安装包按当前源码重新构建。
04 / 体验打磨
从原生工程，继续打磨日常体验。
原生应用建立后，项目继续完善中英文界面，让设置、菜单与系统面板使用同一种语言。
后续开发 · Codex 直接实现
中英文切换，让界面语言保持一致
在设置中选择简体中文或 English，重启后应用菜单、设置和系统文件面板使用所选语言。双语改造通过了 43 项单元测试、5 项 UI 测试，并完成双架构 Release 构建。
05 / 下载任务摘要
把这次开发的关键过程带走。
带走这次原生迁移的计划安排、测试修复与验证过程，作为你组织下一个长任务的参考。
根据作者开发经历整理，保留关键决策和操作过程。
下载任务摘要06 / 开始你的任务
从你自己的一个长任务开始。
在熟悉的编程工具里提出需求，用 TaskBelay 整理计划、确认范围，再沿着保存的进度持续推进。