[tyreseluo]

What

从独立仓库 OctoBuddy 引入原生编码应用，钉在 9d6f0d8：

• 双环：外环把请求拆成切片（任务卡：Goal / Files / Facts / Done when），inner 并行实现，宿主跑检查、提交并验收；切片带 wave 依赖时前一波全部验收后才放行。
• Agent：Claude Code、Codex、pi 和 octos 都可作外环/inner，OctoBuddy 自带各 agent 的受测版本。
• 形态：模块编入，桌面 shell 默认启用，手机 shell 不编。

注册内容（native-apps.json）

• sandbox：network: any、可起进程；存储：每 account 一份 agent 工作区。
• 给系统的 agent 工具四个：octobuddy.status（读）、octobuddy.send / octobuddy.report / octobuddy.request（每次经人确认），并授权 terminal.run。
• 每项授权的用途、约束、拿掉会怎样：docs/native-apps/octobuddy.zh-CN.md（English），README 的 agent 表链接过去。其中写明：OctoBuddy 在各平台都是模块，sandbox 只作用于进程启动，所以目前它跑在 shell 进程里、没有 OS 沙箱约束，与 Rinx、App Hub 相同。

顺带的小能力

• tools/native_apps.py：原生 app 可声明显示名 name（可选、非空、≤40 字符、无首尾空格），NativeApp 生成 name: Option<&'static str>。
• approvals::sheet::app_label 优先用它，确认单上显示「OctoBuddy」（此前会是「Octobuddy」）。

相对第一版的修正（评审）

• 生成器少逗号：生成的 pub name: Option<&'static str> 缺逗号，crates/shell/src/native_apps.rs:57 语法错误。已修并重新生成；新测试 test_the_generated_rust_parses（生成的结构体字段都以逗号结尾，并用 rustfmt 整份解析），去掉逗号时它会失败。
• sandbox/tests.rs 手写的 NativeApp 没补新字段，shell 的测试编译不过。已补。
• 两份 App Hub：OctoBuddy 原先钉 App Hub 58c3c8a，lock 里出现两份 octosense-app-policy，过不了 setup.py --cargo 的「一个 App Hub」检查。OctoBuddy 已改钉本仓 main 的 App Hub（2e57689）及其依赖的 makepad（32d6415）。
• rebase 到最新 main（7acfbf3），生成内容全部由 native_apps.py 重新生成。
• 「实机运行正常」不成立：那次运行用的是本机带未提交修改的 .sources/makepad，与提交的代码不一致。下面的验证全部在全新检出里重做（新 worktree，.sources 由 tools/setup.py 按锁文件准备，只含审过的 runtime-patches）。

Verification（全新检出，e0550c7）

• python3 tools/native_apps.py --check ✅
• python3 -m unittest discover -s tools -p 'test_*.py'：124 通过 ✅
• python3 tools/setup.py --check --cargo ✅（一个 Makepad、一个 App Hub、一个 octos）
• cargo check --locked -p octosense（桌面，默认 features，含 app-octobuddy）✅
• cargo test --locked -p octosense-shell --lib -- approvals sandbox native_apps apps::：102 通过 ✅（含新增的 a_native_apps_declared_name_is_what_its_sheets_say）
• 实际运行：同一检出 cargo build --locked -p octosense，OCTOSENSE_HOME=<临时目录> MAKEPAD_WM_TEST_APP=octobuddy ./target/debug/octosense：OctoBuddy 在 shell 内以模块打开，菜单栏是「Ask OctoBuddy」。全新目录里未同意过 agent 时日志是 did not take its assistant service（首次使用的同意流程，module_host.rs 在 create 之前撤回）；带 developer-profile 时是 octobuddy (i1g1) took its assistant service
• OctoBuddy 自己的 CI（9d6f0d8）✅，其中新增的 e2e_tests::dual_loop_plans_two_slices_runs_inner_then_checks_commits_and_accepts 用 stub octos 在 GitHub runner 上跑通「计划 → inner 改文件 → 检查 → 提交 → 审查 → 波次放行」

后续

OctoBuddy 侧演进只动它自己仓库；这边升级 = 改 native-apps.json 的 rev 再跑 python3 tools/native_apps.py。main 已有 kernel: "coding" 端口（ADR 0003），OctoBuddy 的 inner 能否改用它、不再自带 octos serve，另开 PR 讨论。

在 PR head 复现（84a6b23）

rebase 到当前 main（b9d66d0），仍是一个提交。全部在全新 worktree 里做，.sources 由 python3 tools/setup.py --no-hub 按锁文件准备（只含审过的 runtime-patches）；检查照 .github/workflows/desktop.yml 逐条跑。这一节取代上面 e0550c7 的 Verification。

冲突怎么解的

• tools/native_apps.py、tools/test_native_apps.py：以 main 现有版本为底（新增的 updater app、wasm-functions / craft-engines 默认 feature），再加回 name 字段的校验、生成和测试。
• Cargo.toml、desktop/Cargo.toml、crates/shell/Cargo.toml、crates/shell/src/native_apps.rs、crates/ai-host/src/native_agents.rs：都是生成文件，不手改——取 main 的版本，再由 python3 tools/native_apps.py 重新生成（表里有 main 的 updater 条目和 Sheets 的 agent 块，每个条目都有 name）。
• Cargo.lock：取 main 的，cargo metadata 只加 OctoBuddy 一项（+17 行），其他包不动。

OctoBuddy 的 pin 改为 1e5e0fd（过渡）

main 的 App Hub 已到 3863591、makepad 到 d653bc4。原 pin 9d6f0d8 钉的是 App Hub 2e57689：cargo check 照样通过，但 lock 里会有两份 octosense-app-policy，python3 tools/setup.py --check --cargo 报 More than one App Hub source（makepad 和本仓的 crate 由根 [patch] 统一到一份，App Hub 没法这样统一）。OctoBuddy build/deps-octosense-main 分支上的 1e5e0fd 改钉 App Hub 3863591、makepad d653bc4、本仓 b9d66d0。这是过渡 pin，2026-10-12 已换成 OctoBuddy 的 v0.3.0（见下一节）。

命令与结果（本机 macOS arm64，84a6b23）

• python3 tools/native_apps.py --check：every generated place matches native-apps.json ✅
• python3 -m unittest discover -s tools -p 'test_*.py'：155 通过 ✅
• python3 tools/setup.py --check --cargo ✅（一个 Makepad、一个 App Hub、一个 octos、一个 Rinx）
• cargo check --locked -p octosense（默认 features，含 app-octobuddy）✅
• cargo check --locked -p octosense --features mobile-apps ✅
• cargo check --locked -p octosense -p octosense-reference -p octosense-appcard --features mobile-apps,app-appcard ✅
• bash ../tools/check-shell-graph.sh -p octosense：4 组 features × target 全部 ok，one octos ✅
• python3 desktop/packaging/make_icons.py --check（75 个图标）✅；python3 -m unittest discover -s desktop/scripts -p 'test_package.py'：25 通过、1 跳过 ✅；「One copy of every shell source」无重复 ✅
• cargo test --locked -p octosense-updater-ui --lib：8 通过 ✅；cargo check --locked -p octosense-updater-ui --example updates ✅
• cargo test --locked -p octosense-shell --lib -- approvals sandbox native_apps apps::：104 通过 ✅（含 a_native_apps_declared_name_is_what_its_sheets_say）
• 编译警告只有 main 自己的（crates/shell/src/wasm_service.rs、crates/wasm-host 里 fetch_update 的弃用警告），这个 PR 没有新增
• 实际运行：同一检出 cargo build --locked -p octosense，OCTOSENSE_HOME=<临时目录> MAKEPAD_WM_TEST_APP=octobuddy ./target/debug/octosense：日志有 wm: modules linked: [..., "octobuddy", ...] 和 wm: launched octobuddy as client 1 (in-process, octobuddy)；全新目录里没同意过 agent，所以是 did not take its assistant service（与上面相同）

「少逗号」这类错误怎么防住

test_the_generated_rust_parses 现在不靠 rustfmt 也查：结构体字段（ pub name: …）和每个 NativeApp { … } 条目里的字段（ name: …）都必须以逗号结尾；机器上有 rustfmt 时再整份解析。CI 的工具链若没装 rustfmt，整份解析会跳过，逗号检查照跑。验证过：分别去掉生成器里结构体那一行和条目那一行的逗号，在 PATH 里没有 rustfmt 时这条测试都失败。Desktop workflow 本来就跑 tools 的 unittest、native_apps.py --check 和上面三条 cargo check，生成器测试和 shell 编译都在 CI 里。

CI：这是 fork 来的 PR，新 head 上的 workflow（Desktop、Phone、Embedded browser、Platform accounts、WebAssembly on Windows）都是 action_required，要维护者批准后才跑。

pin 移到 OctoBuddy v0.3.0（95dff53）

OctoBuddy 的 pin 从过渡的 1e5e0fd 移到 v0.3.0 的提交 f714871。依赖与 1e5e0fd 相同（App Hub 3863591、makepad d653bc4、本仓 b9d66d0）。改动只有 native-apps.json 的 rev、生成器同步的 Cargo.toml，以及 Cargo.lock 里 OctoBuddy 一项（版本 0.2.2 → 0.3.0 和 rev），其他包不动。仍是一个提交。

v0.3.0 相对 1e5e0fd 加的是 OctoBuddy 内部的东西（声明核对、验收闸、操作回执与读回、资料隔离、验收单、各环的实时状态、跟进 App Hub 审核意见），给系统的四个 agent 工具和授权都没变；octobuddy.status 的返回多了 as_of、各环的 state / waiting_on / last_heard_secs_ago 和会话的 acceptance。

在 95dff53 重跑（本机 macOS arm64）：

• python3 tools/native_apps.py --check：every generated place matches native-apps.json ✅
• python3 -m unittest discover -s tools -p 'test_*.py'：155 通过 ✅
• python3 tools/setup.py --check --cargo ✅
• cargo check --locked -p octosense ✅；--features mobile-apps ✅；-p octosense -p octosense-reference -p octosense-appcard --features mobile-apps,app-appcard ✅
• cargo test --locked -p octosense-shell --lib -- approvals sandbox native_apps apps::：104 通过 ✅
• 实际运行：用同一份代码（OctoBuddy 以本地路径替换）构建的 octosense 正常启动，日志 wm: modules linked: [..., "octobuddy", ...]

升级到 OctoSense main ffd5e48，pin 移到 OctoBuddy f5cc3b1（d1956f4）

rebase 到当前 main（ffd5e488，比上一版多 136 个提交），无冲突，仍是一个提交。OctoBuddy 的 pin 从 v0.3.0（f714871）移到 f5cc3b1：包含 v0.3.1 的全部内容、之后界面复验的修复，以及把 OctoBuddy 依赖的本仓 crate 升到 ffd5e488（App Hub 3863591、makepad d653bc4 与 main 所钉一致，不变）。

改动只有 native-apps.json 的 rev、生成器同步的 Cargo.toml，以及 Cargo.lock：OctoBuddy 一项（0.3.0 → 0.3.1 和 rev），加上 OctoBuddy 新带进来的三个包 disktree-core（tobi/disktree，MIT，磁盘地图插件用）、sysinfo、trash；其他包不动。给系统的四个 agent 工具、授权和沙箱声明都没变。

在 d1956f4 重跑（本机 macOS arm64，全新 worktree，.sources 由 python3 tools/setup.py 按锁文件准备）：

• python3 tools/native_apps.py --check → every generated place matches native-apps.json ✅
• python3 -m unittest discover -s tools -p 'test_*.py' → Ran 155 tests, OK ✅
• python3 tools/setup.py --check --cargo → 退出码 0（一份 makepad、一份 App Hub、一份 octos）✅
• cargo check --locked -p octosense ✅；--features mobile-apps ✅；-p octosense -p octosense-reference -p octosense-appcard --features mobile-apps,app-appcard ✅
• cargo test --locked -p octosense-updater-ui --lib：9 通过 ✅；cargo check --locked -p octosense-updater-ui --example updates ✅
• cargo test --locked -p octosense-shell --lib -- approvals sandbox native_apps apps::：104 通过 ✅

pin 移到 OctoBuddy v0.3.2（fa25e8f）

OctoBuddy 的 pin 从 f5cc3b1 移到 v0.3.2 的提交 668765c（相对 f5cc3b1 只改了版本号和文档）。仍基于 main ffd5e488，仍是一个提交。改动只有 native-apps.json 的 rev、生成器同步的 Cargo.toml，以及 Cargo.lock 里 OctoBuddy 一项（0.3.1 → 0.3.2 和 rev）；cargo metadata --locked 通过，其他包不动。

在 fa25e8f 重跑（本机 macOS arm64，全新 worktree）：native_apps.py --check ✅；tools 155 个测试 OK ✅；setup.py --check --cargo 退出码 0 ✅；cargo check --locked -p octosense ✅、--features mobile-apps ✅、-p octosense -p octosense-reference -p octosense-appcard --features mobile-apps,app-appcard ✅；updater-ui 9 个测试 ✅、--example updates ✅；octosense-shell 104 个测试 ✅。