Skip to content

Release 2.1.17 (2026-06-08)

Bug fixes

  • compare ruleset required checks by set, not list order (#1509) The ruleset 'rules' field was compared with a plain list '!=' in _diff_dataclass. GitHub assigns no meaning to the order of rules within a ruleset or of contexts within a required_status_checks rule, so a pure reordering produced a spurious 'NON-COMPLIANT' diff whose delta showed extra (0) / missing (0).

Route the rules leaf comparison through a new set-based canonicalization (_canonicalize_rules / _values_differ): sort the outer rule list and each rule's required_status_checks list before comparing. A genuinely added or removed required check always differs; a reordering never does. This keeps detection consistent with the format_rules_delta presentation, which already keys on (context, integration_id).

CI

  • add build-only docs verification job to ci.yml (#1508)

Features

  • resolve validation command from target repo's vergil.toml (#1510)
  • feat(config): add [validation].container-command to vergil.toml schema

Add an optional [validation] section with a container-command key (default "vrg-validate") plus a validation_container_command() resolver. This lets a repo declare the in-container validation entry point its dev image needs, read at execution time from the repo root. Refs #1433.

  • feat(container-run): resolve validation command from target repo's vergil.toml

vrg-container-run now rewrites a vrg-validate invocation using the target repo's [validation].container-command override, resolved from the mounted repo root. The fleet-wide vrg-container-run -- vrg-validate keeps working everywhere; repos needing different activation (here, the self-repo's uv run vrg-validate) are picked up at execution time regardless of which CLAUDE.md the invoking session loaded. Declare the self-repo override in vergil.toml. Ref #1433.

  • docs(claude-md): clarify self-repo validation uses the [validation] override

The Validation note no longer contradicts the canonical vrg-container-run -- vrg-validate headline. It now explains that this repo declares a [validation] override in vergil.toml so the bare command transparently expands to uv run vrg-validate, and that the override lives in vergil.toml (not just CLAUDE.md) so cross-repo agents resolve it regardless of which CLAUDE.md they loaded. Ref #1430.

  • resolve vergil.toml from main, then develop, then local (#1512)
  • fix(github-repo-config): give actionable error when remote vergil.toml fetch returns 404

The contents API resolves vergil.toml against the repo's default branch. When the file is absent there (e.g. default is still 'main' but vergil.toml only lives on 'develop'), the 404 propagated as an unhandled GitHubAPIError traceback. Catch the 404 in _fetch_remote_config and raise an actionable RuntimeError that names the repo, explains the default-branch cause, and points to --config; main now emits it via emit_error and exits 1 with no traceback. Non-404 API errors still propagate unchanged.

  • feat(github-repo-config): resolve vergil.toml from main, then develop, then local working copy

Previously the remote config was fetched only from the default branch; during bootstrap (default still 'main' while vergil.toml lives on 'develop') that 404'd. Resolve canonically from 'main', fall back to 'develop', then to the working-directory copy when the cwd is a checkout of the target repo. This makes bootstrapping ergonomic — edit vergil.toml and run apply from the repo root before the file has landed on any canonical branch. The local fallback is safe under the trust model: agents may write vergil.toml but only a human runs apply and owns that action, and the fallback is gated on cwd matching the target repo so a --repo override never applies an unrelated local config. When the file is absent everywhere, exit with an actionable error (no traceback). Non-404 API errors still propagate unchanged.

  • test(github-repo-config): assert error substance, not emit_error prefix, in remote-config failure test

The test asserted 'ERROR:' in stderr, which only holds in interactive mode; under CI emit_error emits the GitHub Actions annotation format ('::error ::...'), so the test passed locally but failed on all three unit-test matrix jobs. Assert on the actionable message substance (--config) and the absence of a traceback instead, which is environment-agnostic.