Problem
Project and user configuration currently use one file per setting under .code-converge/ (for example mode, review-model, and max-cycles). This is difficult to discover, review, and maintain as the configuration surface grows.
Desired outcome
Use one YAML configuration document named config.yaml in each supported .code-converge directory:
<git-root>/.code-converge/config.yaml for project settings;
~/.code-converge/config.yaml for user settings.
Keep the existing source precedence: CLI flags > project YAML > user YAML > environment > built-in defaults.
Acceptance criteria
config.yaml is the only supported file-based settings source in both project and user .code-converge directories.
- It represents every setting currently configured through per-setting value files, including mode, workflow options, stage-specific model/reasoning overrides, review base, and diagnostic session-log settings.
- The documented YAML schema is typed, validated, and rejects unknown keys and invalid values with actionable diagnostics.
code-converge config reports effective values and their existing sources correctly when values come from YAML.
- Existing CLI flags and
CODE_CONVERGE_* environment variables retain their current names and precedence.
- Legacy per-setting files are not read and no migration, fallback, or compatibility behavior is implemented.
- Decide and document the YAML representation for the three prompt settings; a file reference is acceptable if prompt contents should remain separate from configuration.
- Update README and the public CLI/configuration contract with complete project and user examples.
- Add focused precedence, validation, malformed-YAML, unknown-key, and no-legacy-fallback tests.
Scope notes
This is a clean-break change to the public configuration contract and belongs to Feature Flow, not Small Change. It should include a versioning/release decision appropriate for the breaking configuration change.
Problem
Project and user configuration currently use one file per setting under
.code-converge/(for examplemode,review-model, andmax-cycles). This is difficult to discover, review, and maintain as the configuration surface grows.Desired outcome
Use one YAML configuration document named
config.yamlin each supported.code-convergedirectory:<git-root>/.code-converge/config.yamlfor project settings;~/.code-converge/config.yamlfor user settings.Keep the existing source precedence: CLI flags > project YAML > user YAML > environment > built-in defaults.
Acceptance criteria
config.yamlis the only supported file-based settings source in both project and user.code-convergedirectories.code-converge configreports effective values and their existing sources correctly when values come from YAML.CODE_CONVERGE_*environment variables retain their current names and precedence.Scope notes
This is a clean-break change to the public configuration contract and belongs to Feature Flow, not Small Change. It should include a versioning/release decision appropriate for the breaking configuration change.