当前快照更能证明“配置治理方式”，难以完整证明“根级构建体系”
在当前可见源码中，settings、permission rules、managed settings、MCP config、plugin cache 这些都很清楚；反而根级构建脚本和测试结构不可见。所以这页重点解释“已经确认的治理机制”和“必须保留不确定性的地方”。
本页回答什么问题
- 配置是如何组织、校验和合并的？
- 权限规则和 settings 有什么特殊处理顺序？
- MCP 配置合并背后的优先级和去重策略是什么？
- 当前快照能证明哪些质量机制，不能证明哪些？
settings 系统
src/utils/settings/settings.ts 与 src/utils/settings/types.ts 构成统一 settings 层。它不是简单读配置文件，而是支持多 source、缓存、managed settings base file + drop-ins、schema 校验和某些字段的预处理。
- 已确认：大量字段通过 Zod schema 约束。
- 已确认：支持多种 settings source 与缓存策略。
- 已确认：permission rules 在正式 schema 校验前就存在预过滤逻辑，说明作者知道旧格式/非法规则很常见且需要兼容处理。
运行时配置模型
src/utils/config.ts 中的 GlobalConfig 与 ProjectConfig 表明配置不仅服务启动，还承载运行态信息，例如最近会话指标、MCP server 状态、worktree session、remote control 模式等。这让“配置”和“状态”在某些区域发生重叠，也解释了为什么配置层会变得比普通 CLI 更重。
MCP 配置优先级
src/services/mcp/config.ts 的 getAllMcpConfigs() 暗示了一条非平凡合并链：既要处理企业/托管 settings，又要处理本地与手动服务器，还要对 claude.ai connector 做去重。这个实现说明 MCP 对产品来说不是“附加插件”，而是和权限、账户、托管配置都有关联的一等能力通道。
feature gates 与环境分岔
feature('...') 是当前可见代码中最常见的环境分岔机制。它既像构建期开关，也像产品能力矩阵。这带来两个后果：一是单份源码可以承载多种发行形态，二是阅读任何模块都必须同时问“它在什么形态下才会被启用”。
当前能确认的质量机制
- Schema 校验：settings、permissions、plugins、MCP 配置都有明确 schema 或等价验证路径。
- 迁移：
src/migrations/*说明历史兼容被认真维护。 - 遥测与诊断：startup profiler、query profiler、session tracing、analytics 日志大量存在。
- 清理与恢复：cleanup registry、graceful shutdown、terminal 恢复、worktree 状态恢复都清晰可见。
关于构建、测试与 CI 的谨慎结论
尽管如此，从代码痕迹仍可确认一些工程约束：
- Bun feature gates 明确存在。
- React Compiler 转换痕迹存在于部分文件。
- 代码中出现 Biome / ESLint 风格规则注释，说明静态检查工具很可能参与过开发流程。