Improve default tool configuration and expose all supported parameters in the config file

[SizzleUnrlsd]

Labels

enhancement
configuration
tooling
documentation

Problem

The tool currently relies on a base/default configuration that is either too limited, incomplete, or not fully aligned with the actual set of supported runtime/analysis parameters.

At the moment:

• the default configuration does not reflect the full capabilities of the tool
• some parameters are only configurable through CLI flags or internal defaults
• the config file does not serve as a complete source of truth for users
• this makes onboarding, reproducibility, and maintenance harder

A user should be able to inspect a single configuration file and understand all supported options, their defaults, and their expected behavior.

Goal

Rework the base configuration of the tool and extend the configuration file so that all supported parameters are explicitly declared there.

The config file should become the canonical place to define tool behavior.

Expected changes

1. Update the default/base configuration

• review the current built-in defaults
• make the base configuration coherent, complete, and production-friendly
• ensure the defaults are safe and predictable

2. Add all tool parameters to the configuration file

• expose every supported parameter in the config schema/file
• avoid hidden or hardcoded options when possible
• make CLI/config mapping explicit

Examples of parameters to expose:

• analysis mode
• enabled/disabled checks
• include/exclude paths
• output format
• verbosity / log level
• limits / thresholds
• reporting options
• debug options
• performance-related toggles
• feature flags
• runtime instrumentation options
• stack / memory / bounds related settings
• filters and selection rules

3. Define clear semantics for each parameter

For every config entry, document:

• name
• type
• default value
• allowed values
• description
• impact on the tool behavior

4. Align config parsing with the schema

• ensure the parser accepts all documented parameters
• reject invalid or unknown values clearly
• provide useful diagnostics on malformed config files

5. Keep CLI and config behavior consistent

• define precedence rules between CLI arguments and config values
• document override behavior
• ensure there is no ambiguity between default values and explicit user values

Suggested implementation

• introduce or update a central config structure/schema
• move scattered defaults into a single configuration layer
• add serialization examples for the default config file
• update loader/validator logic accordingly
• add tests for parsing, validation, and fallback behavior

Acceptance criteria

• all supported tool parameters are present in the config file
• the default config is complete and usable out of the box
• undocumented hidden parameters are removed or explicitly exposed
• invalid config entries produce clear diagnostics
• CLI/config precedence is documented and tested
• documentation includes an example full configuration file

Deliverables

• updated default configuration
• extended config schema/file with all parameters
• parser/validator updates
• tests covering valid and invalid configurations
• documentation for each config entry
• a full example config file

Why this matters

This change will improve:

• usability
• discoverability
• reproducibility
• maintainability
• integration in CI/CD and automated workflows

Possible follow-up

• add a generate-default-config command
• add schema versioning
• add JSON schema / YAML schema validation support
• add comments or generated reference documentation from the config schema