When handling configuration from CLI/UI (e.g., --set, channel flags, migration prompts), treat user-provided values as explicit assertions that must (a) be seeded into the same data pipeline that prompts/templates use, (b) survive any schema-strict filtering only because the user asserted them, and (c) not be overwritten later by default/template/prompt logic.
Apply this checklist:
--yes/skip paths see them as already-set.result (no prompt), allow overrides to flow through the result-template rendering (don’t warn as “unknown” or stomp raw values).--pin, --next, --channel) skip upgrade/prompt logic and aren’t overwritten by recorded manifest state.this.bmadFolderName), and don’t set runtime-breaking env options (e.g., invalid NODE_OPTIONS flags for the supported Node version).Example pattern (seeding + filtering prompts):
const declaredKeys = new Set(configKeysFromSchema(itemOrModule));
const overrides = cliOverrides[moduleName] ?? {};
const seededKeys = new Set();
const unknown = [];
for (const [k,v] of Object.entries(overrides)) {
if (declaredKeys.has(k)) seededKeys.add(k);
else unknown.push(k);
}
// Seed answers so prompt/template/default logic won’t overwrite.
let allAnswers = { ...staticAnswers };
for (const k of seededKeys) allAnswers[`${moduleName}_${k}`] = overrides[k];
// Remove corresponding questions so interactive flow doesn’t reprompt.
questions = questions.filter(q => !seededKeys.has(q.name.replace(`${moduleName}_`, '')));
// Track seededKeys so schema-strict partition keeps them.
setOverrideKeys[moduleName] = [...(setOverrideKeys[moduleName] ?? []), ...seededKeys];