[Bug]: qualityGate.algorithms 下按算法名配置质量门参数会误报 "Unknown keys" 警告

[cycle2zhou]

Bug Description

在 acp.jsonc 里配置 qualityGate.algorithms.<算法名> 的各层参数时，启动会弹出 ACP: config warning — Unknown keys 警告，但该配置实际是合法且生效的。

配置写法：

{
  "qualityGate": {
    "enabled": true,
    "algorithm": "rouge-recall-v1",
    "algorithms": {
      "rouge-recall-v1": {
        "layer1MinChars": 200,
        "layer1MinRetentionPct": 2.5,
        "layer2MaxRougeF1": 0.05,
        "layer2MaxTop20Recall": 0.20
      }
    }
  }
}

被误报的未知键共 5 个：

qualityGate.algorithms.rouge-recall-v1
qualityGate.algorithms.rouge-recall-v1.layer1MinChars
qualityGate.algorithms.rouge-recall-v1.layer1MinRetentionPct
qualityGate.algorithms.rouge-recall-v1.layer2MaxRougeF1
qualityGate.algorithms.rouge-recall-v1.layer2MaxTop20Recall

根因与 #262 完全同类：lib/config-validation.ts 的校验器 getConfigKeyPaths 会递归展开用户配置的每一层键，再和白名单 VALID_CONFIG_KEYS 比对。但白名单里 qualityGate 相关只到 qualityGate、qualityGate.enabled、qualityGate.algorithm、qualityGate.algorithms 四层，没有（也无法预先枚举）qualityGate.algorithms.<算法名> 这种动态键。

qualityGate.algorithms 本质是"按算法名索引的动态键映射"（schema 中也定义为 additionalProperties: true）。校验器对同类的 compress.modelMaxLimits / compress.modelMinLimits / messageFilters.filters 已做"命中即停止递归"的跳过，却漏了给 qualityGate.algorithms 加同样处理（#262 修复时同样漏掉了这个键，见 master 分支最新源码）。

附带确认：配置本身正确且生效——(qg.algorithms && qg.algorithms[algoName]) ?? {} 会读取该映射传入质量门评估，layer1MinRetentionPct 等参数确实在起作用。

Expected Behavior

按算法名配置质量门参数是合法配置，不应触发 Unknown keys 警告。期望：

1. getConfigKeyPaths 对 qualityGate.algorithms 增加动态键跳过（参照现有 compress.modelMaxLimits / compress.modelMinLimits / messageFilters.filters 的处理），使 qualityGate.algorithms.* 下任意算法名及其参数键都视为合法。
2. （可选）顺带核对 dcp.schema.json 与运行时校验器的一致性——目前 schema 中 qualityGate.algorithms.rouge-recall-v1.layer1MinRetentionPct 的默认值写的是 1.0，与代码中的默认 5 不一致。

Debug Context Logs

此为配置校验期的 bug，与上下文剪枝 / compress 运行时无关，context 日志无对应记录。复现只需在 acp.jsonc 写入上面的配置并重启 opencode，即会弹出警告 toast。触发警告的代码路径：showConfigWarnings → getInvalidConfigKeys → getConfigKeyPaths / VALID_CONFIG_KEYS（lib/config-validation.ts）。
{ "note": "配置校验期问题，无 context 运行时日志。复现步骤见上。" }

Tool Call Details

不涉及工具调用。纯配置文件加载校验问题。

DCP Version

1.14.22

Opencode Version

1.18.19

Model

Other (deepseek-v4-flash)

Additional Context

本 issue 是 #262 的同类遗漏：修 #262 时只给 messageFilters.filters 加了递归跳过，qualityGate.algorithms 仍是漏网之鱼。我拉取 master 分支最新 lib/config-validation.ts 确认，跳过名单目前为：

if (
    fullKey === "compress.modelMaxLimits" ||
    fullKey === "compress.modelMinLimits" ||
    fullKey === "messageFilters.filters"
) {
    continue
}

qualityGate.algorithms 依然不在其中，即该误报在当前 master 与 npm latest（1.14.22）均存在。

该警告本身无害（showConfigWarnings 只弹一个 toast，无 return / throw，不影响配置加载），配置仍正确生效。仅为提示层面的误报。

[ranxianglei]

质量门除了保留非空 我打算移除,这个在acp kernel里面已经彻底移除,反而效果更好

[ranxianglei]

ework 检查质量门默认是否开启 开启了哪些?是否可以废除 还是保留默认参数

[ranxianglei]

🤖 ework agent · vllm-qwen/qwen3.8-27b

@ranxianglei 已按你的要求核查 master（574c1c4）质量门现状，结论如下：

1. 默认是否开启：默认关闭

• lib/config.ts:233-244：qualityGate.enabled 默认 false（schema 里 dcp.schema.json 也是 enabled.default: false，注释 "Off by default for one release of burn-in"）。
• 两条运行路径都会在入口短路：lib/compress/quality-gate/evaluate.ts:81 和 :159 的 if (!qg || qg.enabled !== true) return null。
• 即默认安装下质量门零执行、零开销，只有显式 enabled: true 的用户才受影响。

2. 开启后实际启用了什么

内置算法只有一个：rouge-recall-v1（lib/compress/quality-gate/algorithms/index.ts:5 注册）。代码默认参数：layer1MinChars: 200、layer1MinRetentionPct: 5.0、layer2MaxRougeF1: 0.05、layer2MaxTop20Recall: 0.20。

⚠️ 顺带确认了 issue 第 2 点：schema 中 layer1MinRetentionPct 默认写的是 1.0，与代码的 5.0 不一致。

另外要纠正一个文档偏差——README 说 "non-blocking"，但pre-commit 路径实际上是阻塞的：

路径	位置	行为
Pre-commit	lib/compress/range.ts:328-352	evaluatePreCommitQuality 在 block 提交前运行；失败则 throw buildQualityRejectionError + 置 state.qualityGateRetryPending = true，模型必须带 acknowledgeRisk: true 重试才能绕过（range.ts:313-327）。会拒绝 compress 调用
Post-commit	lib/compress/pipeline.ts:97-115	evaluateBatchQuality 在 finalizeSession 里，失败仅 logger.warn，非阻塞

Pre-commit 强制是 2026-07-22 加的（devlog/2026-07-22_quality-gate-enforcement/），此后 acknowledgeRisk 机制已先后引发 #301/#303（v1.14.20 修复：提前传 acknowledgeRisk 从报错改为 no-op）和 #195（E2E 场景误用）。acknowledgeRisk 暴露在 compress 工具 schema 上（range.ts:93），模型只能靠 rejection 报错文本发现它（prompts 里没提）。

3. 是否可以废除：可以，且建议废除

理由：

1. 默认关闭 → 废除对默认用户零影响，只影响显式开启的少数用户。
2. 你已在 acp kernel 里验证彻底移除效果更好（Floor 1）。
3. 开启时 pre-commit 拒绝 + acknowledgeRisk 重试循环会额外消耗模型 turn，机制复杂（transient flag qualityGateRetryPending、失败时 save/restore 等），且已有 3 个相关 bug 史，维护成本 > 收益。
4. 你想保留的"非空"检查不需要 ROUGE 机器：现在并没有现成的空 summary 内联检查（phantom 检查 checkPhantomBlock/identifyPhantomPlans 查的是 0 新消息，不是空摘要），废除时在 range.ts 提交前加一行 summary.trim().length === 0 的内联拒绝即可，无配置面、无算法注册表。

4. 废除范围（若执行）

• lib/compress/quality-gate/ 整目录（types/registry/tokenizer/evaluate/algorithms/rejection）
• lib/compress/range.ts：pre-commit 块（328-352）、acknowledgeRisk schema 参数（93）、bypass/ignored 逻辑（313-327、404、409-411）
• lib/compress/types.ts:60,74（acknowledgeRisk）
• lib/state/types.ts:162、lib/state/state.ts:209,251（qualityGateRetryPending）
• lib/compress/pipeline.ts:97-115（post-commit 评估）
• lib/config.ts：QualityGateConfig（69-77）、默认值（233-244）、copy（442-445）、merge（468-471、516）
• lib/config-validation.ts:61-64（白名单 qualityGate 键）
• dcp.schema.json qualityGate 段、CONFIGURATION.md/README 文档
• 测试/E2E：tests/quality-gate-enforcement.test.ts、scripts/e2e/scenarios/02-quality-reject.json、03-quality-acknowledge.json、scripts/e2e/verify.ts 与 fake-llm-server.ts 的 retryOnReject 相关字段

副作用：#329 的 Unknown keys 误报会随 qualityGate.algorithms 键一并消失，本 issue 可直接按 obsolete 关闭。若选择保留（选项 B：保持默认关闭），则 #329 仍需单独一行修复（getConfigKeyPaths 跳过名单加 qualityGate.algorithms）并修正 schema 默认值 1.0→5.0。

建议

选项 A（与 Floor 1 意图一致，我推荐）：废除整个质量门 + acknowledgeRisk，仅保留内联非空检查；#329 按 obsolete 关闭。
选项 B（保守）：保留代码、保持默认关闭，只修 #329 误报 + schema/代码默认值不一致。

确认走 A 的话我直接开废除 PR（含测试与 E2E 清理）；走 B 的话我开 #329 的一行修复 PR。