refactor: rename project to bootagent

[Paulkm2006]

Summary

Rename project fron OneAgent to BootAgent to avoid trademark infringement risk.

Verification

• Tests were added or updated for behavior changes, or the reason they are unnecessary is explained.
• Relevant Go, frontend, documentation, and release-compliance checks pass locally.
• UI changes include screenshots or a short recording, or this change has no UI impact.

Change checklist

• No API key, token, private configuration, or sensitive path is present in code, logs, screenshots, fixtures, or issue links.
• No Wails DTO or service changed, or frontend/bindings, frontend/src/backend/wails.ts, and handwritten API types were synchronized.
• No documented user-visible behavior changed, or README.md and README_ZH.md were updated together.
• No distributed dependency or third-party mark was added, or NOTICE was updated.
• Public documentation is in English; AGENTS.md and docs/internal/ remain in Chinese.

[yujiezhang-ops]

在 158504d 上审了一遍。重命名的机械部分质量很高：编译、go vet、Go 全部测试、前端 365 个测试全过；internal/cmd/build 下除迁移代码本身外没有任何残留的 oneagent 引用；bundle ID、build/config.yml、Windows manifest、updater 仓库名都同步改了。

有两处涉及用户数据丢失的问题建议合并前修，以及一个必须与合并同时完成的时序依赖。下面每条都是在这个分支上写测试跑出来的。

P0 — 迁移会永久删除用户数据

internal/app/migration.go:30 的复制清单是 9 项白名单，而 :44 的 os.RemoveAll(legacy) 删掉整个 .oneagent。差集里有代码仍在读取的路径。

我用 grep 枚举了代码实际访问的 .bootagent 子路径，与清单比对，缺口如下：

未迁移但代码会读	后果
settings.json	镜像选择、备份保留数（#174 刚加的）静默重置为默认
env	环境变量配置丢失
backup/	配置被覆盖后唯一的恢复途径
skill-backups/	Skill 卸载的恢复途径
logs/	故障排查记录

实测（临时目录，非真实 home）：

LOST: settings.json did not survive migration
LOST: env did not survive migration
LOST: backup/keep.json did not survive migration
LOST: skill-backups/s1/meta.json did not survive migration
LOST: logs/install.log did not survive migration
legacy dir was deleted, so anything not copied is gone permanently

其中 backup/ 的丢失我认为最该修：它是覆盖配置后唯一能找回原样的地方，而 #174 刚刚把备份统一挪到这个托管目录下。两个改动叠加的结果是「新引入了保留策略，然后改名时把整个备份历史删了」。

runtimes 的删除是有意的 —— migration_test.go:47 明确断言它不被复制，提示语也说明要重装。但「不迁移」和「删掉」是两件事：用户会丢掉数百 MB 已装好的 Node.js / uv 并被迫重新下载。

这已经在真实机器上发生过。 我在本机编译运行了这个分支的应用，迁移真实执行：~/.oneagent/ 原有 49 个条目，迁移后 ~/.bootagent/ 只剩 7 个，runtimes 已不存在。这不是推演。

建议：

1. 把白名单改成「复制整个目录、排除 runtimes」，这样新增的状态文件不会因为忘记登记而丢失 —— 白名单机制本身就注定会随功能增加而失配，settings.json 就是第一个例证（它是 feat: adjustable backup retention policy #174 引入的，比迁移代码晚）。
2. 把 os.RemoveAll(legacy) 换成重命名为 .oneagent-migrated-<时间戳>。迁移是不可逆操作，保留原目录的成本只是磁盘占用，而代价不对称。

P1 — localStorage 迁移边遍历边删除,丢一半数据

frontend/src/storageMigration.ts:13 的第二个循环用递增下标遍历 localStorage,却在循环体内 removeItem。删掉下标 i 的键之后,后面的键整体前移一位,下一轮 i+1 就跳过了一个。我用一个模拟 localStorage 跑了文件里的原始逻辑,5 个 oneagent:launch-directory:* 键只迁移了 3 个:

剩余未迁移: oneagent:launch-directory:b, oneagent:launch-directory:d
成功迁移: bootagent:launch-directory:a, c, e
这个键是按 agentId 存的"记住启动目录",所以配了多个 Agent 的用户升级后会有大约一半的启动目录消失。它在后续每次启动时还会再迁移一批,所以能自愈,但用户在升级后第一次打开时看到的是设置丢了。

修法是倒序遍历,或者先把要迁移的 key 收集完再改:

for (let i = localStorage.length - 1; i >= 0; i -= 1) {
顺带一个根因:storageMigration.ts 没有对应的测试文件,这是那 365 个测试没能抓到它的原因。这个文件是一次性迁移逻辑,只有一次执行机会,值得配一个测试。

P1 — 其他 Agent 配置里的旧 provider 键不迁移

migrateCodexProvider 只处理 Codex 的 config.toml。但 OpenCode / Kilo / ZCode 的配置里同样嵌着 provider 键，internal/config/write.go:127 和 :313 现在写的是 bootagent。

用真实的 OpenCode 配置副本实测（密钥已脱敏）：

provider keys after rewrite: [oneagent bootagent]
active model field: "bootagent/m1"
DUPLICATE: 2 provider blocks, stale one retains its API key

功能不会坏 —— model 字段正确切到了 bootagent/。但旧的 oneagent 块原样留下，且带着完整的明文 API Key，没有任何路径会清理它。用户在 OpenCode 的服务商列表里会看到两个重复项，其中一个失效但仍持有凭据。

考虑到项目对「不落敏感数据」的承诺，一个永久滞留、无人管理、含明文 Key 的配置块值得一并处理。

Codex 的替换本身是安全的：它只匹配 model_providers.oneagent 和 model_provider = "oneagent"，我确认了不会误伤 [projects."/path/to/OneAgent"] 这类路径 —— 我本机的 Codex 配置里就有这样一行，实测未被破坏。

时序依赖 — 仓库必须同时改名

MaimoryLab/OneAgent  → 存在
MaimoryLab/BootAgent → 404

而 cmd/bootagent-desktop/main_wails.go:30 已经指向 MaimoryLab/BootAgent。合并后如果仓库没有同时改名，自动更新会直接失效（provider 初始化失败，configureUpdater 返回 nil，更新入口静默消失）。

反方向也要注意：已发布的老版本指向 MaimoryLab/OneAgent，GitHub 改名会保留重定向，所以老用户仍能收到更新 —— 前提是不要把旧仓库名释放或占用。

Bundle ID 从 com.maimorylab.oneagent 改成 com.maimorylab.bootagent，macOS 会视为不同应用：老版本不会被就地替换，用户会同时拥有两个 app，且授予旧 bundle 的系统权限（TCC）不继承。这是改名的固有代价，但值得在发布说明里讲清楚，并考虑让新版本在检测到旧 app 时提示删除。

一个好消息：secrets 是文件存储、不经 keychain（我确认 internal/ 下没有任何 keychain 调用），所以 bundle ID 变更不会锁死用户的 API Key。

测试覆盖

migration_test.go 存在且质量不错 —— 断言了 legacy 目录被删除、runtimes 未被复制、Codex provider 被改写。这说明迁移的语义是被认真设计过的。

但它的 fixture 里没有 settings.json、env、backup/、skill-backups/，所以这些路径的丢失既没被断言保留、也没被断言删除，属于覆盖盲区。把它们加进 fixture，测试立刻会暴露 P0。

建议补两个测试：一个断言「代码会读的每个子路径都在迁移后存在」（可以从常量派生而不是硬编码列表，这样新增状态文件时会自动失败），一个断言「非 Codex 的 Agent 配置里没有滞留的 oneagent provider」。

---

机械替换这部分我没找到问题，250 个文件的一致性是到位的。上面两条都集中在迁移语义上，改动量都不大。