Skip to main content

Configuration overview

ZAR reads configuration from two places:
  1. A .zar.yml file in your repository root — version-controlled, reviewed in PRs, lives with the code.
  2. The dashboard / database — per-repo settings you toggle at app.zarlabs.tech.
Some settings exist in both; some only in one. This page explains who wins when they disagree, and which setting belongs where.

Precedence: dashboard wins

When a setting can be configured in both places and is explicitly set in the dashboard, the dashboard value wins. If the dashboard leaves it unset, ZAR falls back to .zar.yml, and then to the built-in default.
dashboard value (if set)  ▶  .zar.yml value (if set)  ▶  built-in default
Example: your .zar.yml says trigger: daily but the dashboard has trigger mode set to on_significant_change. ZAR uses on_significant_change. If the dashboard trigger were left unset, ZAR would use daily from .zar.yml.

What goes where

Settable in .zar.yml (and most also in the dashboard)

These describe how docs should be produced and are natural to version with the repo:
SettingAlso in dashboard?
trigger (trigger mode)Yes
batch_hoursYes
threshold (confidence)Yes (as min_confidence)
target_branchYes
pr_sizeYes
style_guideYes
notify_slackNo (.zar.yml only)
Full schema and an example: .zar.yml reference.

Dashboard / database only

These are operational toggles and safety switches, kept out of the repo so a PR can’t silently flip them:
SettingWhat it does
auto_commit_enabledAllow ZAR to commit doc updates (also needs the DOCAGENT_WRITE_COMMITS env var).
ci_gate_enabledBlock merges when docs look stale.
required_doc_freshnessThe CI gate threshold.
dry_runReport only — never commit, never block.
debug_modeVerbose logs plus an extra “Debug Info” comment.
use_updates_branchCommit to a dedicated zar-updates/… branch vs. the PR head.
disable_prStop ZAR from opening docs PRs or committing.
comment_enabledPost the status comment on PRs.
cross_repo_enabled, docs_repo, docs_repo_path, docs_repo_branchCross-repo docs.
The complete table of every setting, with types, defaults, and ranges, is in the Settings reference.

New-repository defaults

When ZAR first sees a repository, it starts conservative:
SettingDefault
trigger_modeon_significant_change
batch_hours24
pr_sizesmall
target_branchmain
min_confidence0.6
auto_commit_enabledfalse
ci_gate_enabledfalse
dry_runfalse
use_updates_branchtrue
So out of the box: ZAR watches main, acts only on significant changes, opens small PRs, and never commits or blocks.
  1. Leave everything at defaults and open a few PRs to see ZAR’s suggestions.
  2. Add a .zar.yml with a style_guide so edits match your voice.
  3. When you trust the output, enable the CI gate — start in dry-run to preview.
  4. Only after that, consider auto-commit.

Next steps