When introducing or changing configuration options, treat the canonical config defaults and override policy as the single source of truth across runtime and provisioning. Apply this standard: 1) Register every new (or newly-documented) key in the canonical `DEFAULT_CONFIG` used by the loader—do not rely on `*.example` files to define runtime behavior. 2) Verify merge semantics with regression tests: - Absent blocks/keys are filled from `DEFAULT_CONFIG`. - Explicit user values in `config.yaml` must survive the merge unchanged. 3) Keep `cli-config.yaml.example` (and any public docs/comments) synchronized with `DEFAULT_CONFIG`. 4) For any install/build/enablement logic (e.g., installing optional toolsets), consult the same final user override mechanism used at runtime (e.g., `agent.disabled_toolsets`) and “soft-skip” consistently rather than reinstalling disabled components. Minimal pattern for (1)-(2): ```py # hermes_cli/config.py DEFAULT_CONFIG = { "agent": { "claude_agent_sdk": { "streaming": False, "allow_metered_key": False, "append_file": "", }, }, } # tests should assert: # - deep-merge fills missing blocks/keys from DEFAULT_CONFIG # - explicit user values in config.yaml remain unchanged # - loader output matches canonical defaults exactly ``` For (4), ensure provisioning stages mirror runtime policy (e.g., read disabled toolsets from the existing config.yaml and skip the install step with a clear skipped reason when the toolset is disabled).