[dduugg]

CodeOwnership.validate! stages the regenerated .github/CODEOWNERS only when it is told not to.

The bug

validate! is documented to stage the regenerated file by default and to leave it unstaged with stage_changes: false (lib/code_ownership.rb:184-192, README.md:189). The CLI's --skip-stage maps to stage_changes: false (lib/code_ownership/cli.rb:52 and :85). Both are inverted:

Call	Documented	Before this PR
validate!, bin/codeownership validate	staged	not staged
validate!(stage_changes: false), bin/codeownership validate --skip-stage	not staged	staged

Root cause

1. lib/code_ownership.rb:235 called ::RustCodeOwners.generate_and_validate(files, !stage_changes), so the second argument meant "skip staging", as sorbet/rbi/manual.rbi:12 declared: def generate_and_validate(files, skip_stage).
2. The extension received it as skip_stage and passed it unchanged as the third argument of codeowners-rs's runner::generate_and_validate (ext/code_ownership/src/lib.rs:88-91).
3. In codeowners-rs that parameter is git_stage, which means "stage it" (src/runner/api.rs:30 and src/runner.rs:199-232 at v0.5.0, the tag ext/code_ownership/Cargo.toml pins).

codeowners-rs added git_stage in rubyatscale/codeowners-rs#65, and v0.2.7, which the extension pinned when it landed in #126, already had it. So the inversion is as old as the extension. Nothing ever failed: codeowners-rs discards the result of its git add (let _ = Command::new("git").arg("add")...output()), and the CLI specs stub validate! and only check the arguments it receives.

The fix

validate! now passes stage_changes straight through, and the extension's parameter and the RBI's are renamed git_stage, matching codeowners-rs, so the flag means "stage it" at every layer. The flip at the extension boundary is what hid this bug, so the fix removes it rather than adding a second negation.

The extension's behavior is unchanged; only its parameter name is. So:

• lib/code_ownership/code_ownership.bundle needs no rebuild. The fix works with the bundle as committed.
• The six spec before blocks that call RustCodeOwners.generate_and_validate(nil, false) to write a CODEOWNERS file keep their meaning: false still doesn't stage.

Specs

• .validate! when the project is a git repository. Runs git init in the spec's temp project, then checks git diff --cached --name-only after validate! (expects .github/CODEOWNERS) and after validate!(stage_changes: false) (expects nothing, with the file written). Both examples fail without the fix: the first gets [], the second [".github/CODEOWNERS"]. git runs with the temp project as its working directory and needs no identity, since nothing is committed. The context first clears the variables git rev-parse --local-env-vars lists, because hooks and linked worktrees export GIT_DIR and GIT_INDEX_FILE, which would otherwise aim git, including the extension's git add, at the repository running the suite.
• .validate! when a package.yml is "", "# no keys yet\n" or "---\n". Each must read as a package with no owner: validate! must not raise, which it does when a package.yml fails to parse, and for_file(..., from_codeowners: false) must return the file's annotated team without printing anything. On a parse failure for_file only prints the error and falls back to the annotation, so the spec checks stderr too. This guards the upgrade to a codeowners-rs release with Replace serde_yaml with serde-saphyr to drop unsafe-libyaml codeowners-rs#142, which moves YAML parsing to serde-saphyr. serde-saphyr's unreleased 2.1.0 no longer reads a null document as an empty struct (serde-saphyr#233, fixed by Fix null deserialization for collection targets bourumir-wyngs/serde-saphyr#240), so that PR reads package.yml as an Option to keep an empty file meaning no owner. The spec passes on v0.5.0 and on that PR's head. With serde-saphyr 2.1.0 patched in, it fails if package.yml is read as a plain struct. It passes stage_changes: false because staging is not what it tests.

Verification

Ruby 4.0.7, Rust 1.98.1, git 2.54, macOS arm64. rake compile overwrites the tracked bundle, so each run checked which extension $LOADED_FEATURES actually loaded.

• bundle exec rake (CI's compile and spec step): 101 examples, 0 failures, 1 pending, with the freshly built extension loaded. On main (8ac6a59): 96 examples, 0 failures, 1 pending. The five new examples are the two staging ones and the three package.yml ones.
• bundle exec rspec against the tracked bundle as committed, with no compile: 101 examples, 0 failures, 1 pending.
• With the one-line Ruby fix reverted: the two staging examples fail.
• With GIT_DIR and GIT_INDEX_FILE pointing at a separate repository, as in a hook, the staging examples pass and that repository's index is unchanged.
• With an unparsable package.yml (owner: [) added to the empty-file cases, its for_file check fails, so the spec would catch a file that stops parsing.
• Built against Replace serde_yaml with serde-saphyr to drop unsafe-libyaml codeowners-rs#142's head (1721171) through a temporary cargo patch, the empty-file examples pass.
• bundle exec srb tc: no errors. RuboCop, which CI doesn't run: no new offenses. The one Style/RegexpLiteral at spec/lib/code_ownership_spec.rb:600 is already on main.
• After the suite, git diff --cached --name-only is empty and git status --porcelain lists at most lib/code_ownership/code_ownership.bundle, which rake compile can overwrite with a dev build. The specs create and stage nothing.

Behavior change

Once released, bin/codeownership validate and CodeOwnership.validate! stage .github/CODEOWNERS by default again, as documented and as the Ruby implementation did before #126, and --skip-stage or stage_changes: false no longer stages it. A CI step that runs validate and then git diff --exit-code to catch a stale CODEOWNERS will stop seeing the change, because it is staged; such a step should pass --skip-stage or compare against HEAD.

No version bump is included, so merging releases nothing.

• I bumped the gem version (or don't need to) 💎