Repository navigation
setup: 配置诊断与 fail-closed 回滚，不新增第二条配置入口 #498
Description
结论
给 /openpi-setup 补 versioned 配置加载 fail-closed、apply-failure 回滚 / preview-then-commit、unknown-field 警告。学习 @narumitw/pi-statusline 与 docs/design/PI_CONFIGURATION_ECOSYSTEM_RESEARCH.md 的保存语义。不新增第二条配置入口，不做第二套 Footer，不做成 SuPi 式 Marketplace。
/openpi-setup 仍是唯一用户可见的配置变更入口。doctor / status 留在无参数 /openpi-setup。Pi 继续拥有 install / update / uninstall。本轮未安装、未运行社区包。
事实
冻结身份（last-seen 2026-09-08）：
| 包 | 版本 / 日期 | 来源 |
|---|---|---|
@narumitw/pi-statusline |
npm 0.50.0（2026-08-29） | https://www.npmjs.com/package/@narumitw/pi-statusline · https://github.com/narumiruna/pi-extensions |
公开 README / 源码声明的保存语义（未在本轮执行）：
- unknown 字段 warning，非法已知字段阻止保存；
- 临时文件 + rename；
- live preview 只在确认后落盘；
- 运行时 apply 失败时恢复旧文件与旧状态。
配置生态研究（2026-07-29）已经写过：当前 loader 对读取 / JSON 错误静默回退默认值，缺 document version、来源诊断、apply-failure 回滚。那份研究建议保持单一自然语言入口，先补生命周期，再考虑 project scope / 专用 TUI。
#39 是「agent 提议、用户按键确认」的闸门，不是本 Issue 的 diagnostics / rollback。SuPi 声明式 settings registry 是所有权未定的 Ideas，不要并进本 Issue。
推断
静默把损坏配置变成 defaults，会把用户意图藏起来，也让 doctor 无法区分「没有文件」和「读失败」。unknown field 若直接丢弃，同样会藏意图。这是运行时不变量，不是模型判断。
建议
- versioned config load fail-closed：缺文件才无警告 defaults；malformed / IO error 保留原文件并阻止写入，直到修复或显式 reset。
- apply-failure rollback 或 preview-then-commit。
- unknown fields 警告并保留；若丢弃会藏用户意图，则禁止静默丢弃。
- 不新增
/footer-settings、/permission-settings等扩展专用命令。 - 无参数
/openpi-setup继续承担 status / doctor。
任何新的模型可见配置工具必须是 episode-scoped（现有 configure_my_pi_setup 模式），并写入 child 分类；默认 parent-only。
未知
- 现有
setup-config.ts自 2026-07-29 研究以来，哪些 fail-closed / lock 语义已经补上（本 Issue 实现前应对当前源码再核一次）。 - SuPi registry 是否值得作为后续扩展贡献面：另开 Ideas，不阻塞本 Issue。
验收
- versioned config load fail-closed
- apply-failure rollback / preview-then-commit
- unknown fields warned，不因静默丢弃而藏用户意图
- 不新增扩展专用 setup 命令
- doctor / status 仍在无参数
/openpi-setup内 - 不引入第二套 Footer 或 statusline 依赖
关联
- setup 闸门缺一档：允许 agent 提议一轮 setup，由用户按键确认 #39（确认闸门；互补，不是本 Issue）
docs/design/PI_CONFIGURATION_ECOSYSTEM_RESEARCH.md- OpenPI 产品哲学：Build for Model Leverage #299 / Capability Shape and Harness Value：什么时候该用 Primitive、Skill、Subagent 或 Workflow？ #314
- 研究记录（本 checkout，未提交）：
docs/research/PI_COMMUNITY_PLUGIN_SURVEY_2026-09-08.md
Activity
tt-a1i commentedon Sep 8, 2026
2026-09-08 目录第二轮：只读能力清单可以当诊断对照，不新开 inspect 产品。
pi-inspectnpm 0.5.0：tools / commands / skills / 注入的 system prompt@narumitw/pi-toolnpm 0.3.1：/tool浏览激活状态、schema、prompt guidelines本 Issue 仍是 setup 诊断与 fail-closed 回滚，不新增第二条配置入口。本轮未安装、未运行。
tt-a1i commentedon Sep 9, 2026
2026-09-09 源码对照（OpenPI checkout
a9b40f0044ee59c360a6077c1c0bdbdbd30da10b/ 0.4.0；origin/main0d17f4577fe31315fe6c95370d251bdb4e2413cf/ 0.8.1）。未pi install，未跑 Session。 分类器复算是bun -e导入本树capabilitiesRequestedByPrompt+requestsCapabilityGateway（树上没有名为classify()的导出）。无参
/openpi-setup在本树上不是 status dump。它走buildInteractiveSetupPrompt+pi.sendUserMessage（extensions/setup/index.ts:590–593）。Pi 0.84.1sendUserMessage仍进prompt()，所以before_agent_start看见的是整段包装。复算：delegate+workflow+background，且 gateway（OpenPI capabilities示例句）/openpi-setup switch footer to powerline包装 →workflow（从句workflow agent_type）switch footer to powerline→[]包装全文与逐从句命中：
docs/research/EXPERIMENT_SETUP_WRAP_CLASSIFIER_2026-09-09.md（本地 draft）。origin/main的分类器是同一 blobf7da1d54。origin 包装仍含Subagents/Workflows/run in the background/OpenPI capabilities/workflow agent_type；对 origin 文案跑同一函数，结果相同。origin 不再开火，是因为768f81e（fix(setup): make episode closure observable）改成sendMessageopenpi-setup-request+triggerTurn，跳过prompt()/ 分类器。这不是分类器修复。leftover 不是「升到 0.8.1」。 0.8.1 没有改分类器，也没有把包装去热。停火的最小机制是投递缝
sendUserMessage→sendMessage+triggerTurn。本树 Pi 0.84.1 已经有这条 API。768f81e缠着 episode 队列 / writer 所有权 /tool_call门，不是干净 cherry-pick。本 checkout 不是 origin 的祖先。本 Issue 继续做 load 诊断、unknown 保留、apply 回滚、无参数 doctor。不要把验收扩成包装器重写或 sendMessage 迁移。不要第二条 setup 命令。不要按当前 diff 合并 #357。#39 不重开。
同胞：
docs/research/EXPERIMENT_INPUT_TRANSFORM_2026-09-09.md（投递总表）、docs/research/EXPERIMENT_SETUP_CONFIG_2026-09-09.md（本 Issue 原验收）。6iKUN6 commentedon Sep 15, 2026
我来认领这个 Issue，接下来会跟进实现。