CodessaCodessa
Documentation
docs/configuration-hierarchy

Configuration Hierarchy

A repository's review behavior can come from three places. Codessa checks them in order, field by field, so a .codessa.yml file doesn't have to set everything to take effect.

01

How precedence works

For every individual setting — tone, severity threshold, each analysis focus flag — Codessa looks top to bottom until it finds a value.

1

.codessa.yml

Wins when set

Committed to the repository

Any field set here wins, no matter what the dashboard says. It lives with the code and travels with the branch, which makes it the most specific place to configure a repo.

not set? fall back
2

Dashboard Settings

Fills the gaps

Set per repository in Codessa

Used for any field .codessa.yml leaves out. Handy for a quick baseline without maintaining a config file at all.

not set? fall back
3

Built-in defaults

Final fallback

Shipped with Codessa

Used when a field isn't set in .codessa.yml or the dashboard. Every repository always ends up with a complete, working configuration.

02

Field-by-field example

Say a repository has a partial .codessa.yml and some dashboard settings. Here's what actually gets used:

Field.codessa.ymlDashboardEffective value
tone—strict
strictdashboard
severity_thresholdbalancedstrict
balanced.codessa.yml
analysis_focus.securitytruefalse
true.codessa.yml
language——
endefault

This is why a .codessa.yml file only needs to contain the fields you actually want to lock in — everything else still falls through to the dashboard, then to Codessa's defaults.

Was this page helpful?