ConfigInitializer

Keys whose value should always end up as an Array(YAML::Any) so callers can iterate without per-call type checks.

Keys that should be coerced from a legacy "yes" / "no" string into a real Bool when parsed from config.yaml. Every boolean field in default_options must be listed here; otherwise direct comparisons like options["cache_disable"] == true in scan.cr would miss a legacy cache_disable: yes entry and silently leave the flag off.

Keys stored as one comma-separated String, because the CLI flags that feed them accumulate into that shape. A YAML sequence is the natural spelling for a list of globs or tech names — and base: / probe_header: in the same file are sequences — so accept it and join. Untreated, exclude_path: ["*.py"] stringified to Crystal's array inspect (["*.py"]), matched no file and excluded nothing silently; the tech keys at least failed loudly, but with that same inspect string quoted back at the user.

Keys whose value must end up an Int, because every consumer reads them through YAML::Any#as_i. A quoted number (ai_max_token: "4000") parses as a String and blew up at the cast — and the generated template itself models the quoted spelling with concurrency: "…", so that is the shape users copy. The equivalent CLI flags run through positive_int_or_die!; these had neither coercion nor validation. Bounds are checked afterwards in Noir::CliValidation, the shared CLI+config gate.

v0 config-key → v1 config-key map. Applied during read_config so a ~/.config/noir/config.yaml written by v0.x with the old deliver/probe keys still loads under v1 without surprises. Mirrors the LEGACY CLI flag aliases in src/options.cr.

override_path is the value of CLI --config-file PATH. When present, ConfigInitializer reads from that file instead of $NOIR_HOME/config.yaml. This makes --config-file flow through the same path as the default config — defaults < file < CLI — so a base: (or any other key) declared in the user's custom config file is actually applied. Pre-fix the --config-file PATH value was only used by validation and a post-CLI merge inside NoirRunner that re-overwrote everything the CLI had just set.

Default concurrency scales with the host's CPU count, clamped to a safe window. The lower bound of 4 keeps low-core CI runners from serializing on a single worker; the upper bound of 32 keeps channel-synchronisation overhead and (under MT) GC pressure in check on very large boxes. Users who want a specific value still get it via --concurrency N or concurrency: in the config file — those paths overwrite this default.

NOIR_CONCURRENCY lets container/CI pipelines pin the worker count to the pod's CPU allocation without threading a flag through every noir invocation. An explicit --concurrency / config value still wins, since those overwrite this default afterwards.