关于配置默认值：开关多起来之后，想聊聊「一律默认关」

[heptaspirit]

我们跑这个项目的 fork，本机装的是自己同步的版本。最近有件事让我们想聊配置：打开 injectGuidanceEnabled 是我们手动做的，换一台机器就要重来一遍，而且每次都要先判断哪些开关值得开。

项目现在的纪律是「行为开关一律 opt-in 默认关」。功能少的时候这条没问题，开关数量上来之后，代价变了。

现在的配置面貌

配置分两处：src/config.js 的键在宿主挂载时读，文件可改；src/settings.js 的功能开关存在库里的 user_settings 表，面板上能看到，但没有文件可改。面板面对的主要是后一类。功能线还在加（注入形态、主动整理、存储生命周期、document 型记忆、heat、仪表盘），开关只会更多。

全关的实际效果

写入工具不挂在开关上，memory_save / memory_search 始终注册。开关控的是注入、指引、整理这几层。所以全关的效果是：内容照样进库，进库之后没有注入、没有指引、没有整理。库只涨，不长出结构。

重复写入是机制问题，不是使用习惯问题：现在去重只比活跃集，同一件事换个标题就再进一条，归档不参与比对。这一层只有整理能治。

我们自己的一个判断失误

我们一度以为把 document 型记忆（#230）和主动整理接口（#231）做完，写入的杂乱会顺带解决。现在看不对：那两个管的是「长出来之后怎么放」和「事后怎么整理得动」，都不在写入频率上。要拦的是写的那一刻，那是另一条线（#254）。

建议三档，不是两档

1. 默认档：开箱即用的基础能力。判据是它只修正既有行为里的选择，不引入新的注入时机、新的表面、新的成本。这一档默认开。
2. 可选档：引入上面任一项的，默认关，用户按需开。
3. 极简档：现有的 lightMode，一键回到全关。

用户的真实动作是「我觉得没必要可以关」，而不是「我需要哪个去打开」。三档的前提是默认给一套能用的配置，用户在此基础上收或者扩，比如单独指定巩固用哪个模型、改巩固周期、关掉某几条功能。

判据不是新写的。#249 的正文里就有（修正既有块内的选择 → 随父开关默认开；改变时机的子项默认关）。想聊的是把它从单个 issue 的局部规则，变成全项目的默认值口径。

会有人不同意，这里说清楚

不同意的点很明确：默认开意味着升级之后行为变了，而升级静默改变行为是这个纪律本来要防的事。我们认同，所以迁移得单独定：默认值变更不能静默改老用户的行为。autoInject 现在默认 true，是挂载闸；如果某个父开关的默认值写成「关」，升级会对全体用户直接关掉注入。

两条路：

1. 父开关默认值继承现值，升级不改变实际行为；
2. 父开关默认 true，把保守性放在子项上。

两条都保住「升级不静默改变行为」。如果还有第三条，我们想听。

跟已有议题的关系

注入侧具体到 #249：第一批已经落了独立键、默认关，这件事在那边只影响第二批的归位，那边会单独说。配置说明这一层，之前并进了 #278 的回复，形态是面板一页表格，每条写「干什么 / 默认 / 开了会怎样 / 和谁冲突」。

远期的事，不急，先聊聊。

[modusensus]

@heptaspirit 判据成立，三档收。逐条：

1. 三档采纳为全项目口径。「修正既有行为内的选择、不新增时机/表面/成本 → 默认开；引入新的注入时机/新表面/新成本 → 默认关；lightMode 一键回全关」。判据不是新造的，#249 正文里就有，这次升为口径，写进 config schema 与 settings 白名单的注释。

**2. 「库只涨，不长出结构」这个观察是真的。**写入工具不挂开关，开关只控注入/指引/整理——全关的默认等于「进库不整理」。重复写入那层你说得对：去重只比活跃集、归档不参与比对，是机制问题不是习惯问题。归档区 743 行同事实家族的实测（#275）是体积侧的证据，写入侧的闸在 #254，两条线正好接住。

**3. 落地节奏：不逐 feature 翻默认值。**第一次应用放在 #249 第二批（注入线判据最全），其余存量开关做一次盘点归档（默认档/可选档各归各家），一次 PR 定档 + CHANGELOG 全列。零散地翻会让每个小版本都在改行为，比一次大的更糟。

4. 迁移：见 #249 的回复——选路 2，且倾向由 autoInject 兼任父开关（少一个键、少一次迁移决策）。基础子项的默认翻转走显式 CHANGELOG，显式设过值的用户不受影响。

配置说明一页表格（干什么/默认/开了会怎样/和谁冲突）随定档 PR 一起出，#278 记的那笔账在那时销。