Found via end-to-end smoke test, not flagged by either bot review:
`--set bmm.future_thing=x` was persisted to config.toml on install #1
but silently dropped on the next quick-update reinstall, even though
the per-module _bmad/bmm/config.yaml retained it. The central
manifest's schema-strict partition stripped it because
collectModuleConfigQuick (the quick-update helper) never populated
setOverrideKeys for carried-forward unknown keys, and quickUpdate's
installConfig didn't thread setOverrideKeys into the install call.
This is the same bug class as the round-1 fix to collectModuleConfig
(CodeRabbit major #3155145084) but for the quick-update code path,
which has a separate collection helper.
Fix:
- Add OfficialModules._trackUnknownKeysAsOverrides(moduleName, schema)
helper that walks collectedConfig[moduleName] and adds any non-schema
key to setOverrideKeys[moduleName]. Without a schema, every key is
treated as unknown (safe fallback for modules with no module.yaml).
- Call it from all four return paths in collectModuleConfigQuick:
no-schema, parse-failed, hasNoConfig+subheader, silent+no-new-keys,
and the regular end-of-method.
- Mirror ui.collectModuleConfigs's setOverrideKeys conversion in
installer.quickUpdate so the Set→array round-trip lands in
Config.build, and writeCentralConfig sees the exemption list.
Tests: +4 cases — collectModuleConfigQuick carry-forward of unknown
key, declared-key non-tracking under quick-update, and
_trackUnknownKeysAsOverrides no-schema fallback. Total 351 passing.
E2E smoke verified: --set <unknown>=x survives install→quick-update,
install→regular-update, and install→quick-update→regular-update with
a new --set added.
8ab1de8501