Skip to content

Point a repeat at the change's own copy and name the copies it left untouched - #58

Merged
tauanbinato merged 1 commit into
mainfrom
feat/55-cross-file
Oct 4, 2026
Merged

tauanbinato merged 1 commit into
mainfrom
feat/55-cross-file

Conversation

@tauanbinato

Copy link
Copy Markdown
Contributor

What and why

Closes #55

Decided by the user (2026-10-03, on #55): "outside the change" means lines. A copy is untouched when the change did not touch its lines. The finding sits at the change's own copy, and untouched copies never hold a turn. Searching unchanged files stays out of scope, and the default gate is unchanged.

  • In a check of changed lines (--base, or an agent's turn), a shared-logic finding whose change touched only some copies now sits at the first copy the change touched, in that copy's file. Before, it sat at the first copy by path, which could be one the change never touched.
  • The message names each untouched copy and says whether its file is one the change edits. The next step says to fix the change's copy, or to mark the finding later --note "#issue" when sharing the logic would rewrite the untouched copies.
  • The JSON report lists the untouched copies under untouched (a location plus file_changed).
  • The fingerprint stays the one the repeat has in a check of whole files, so a baseline accepts the finding in both. What fails the gate is unchanged. The hook holds a turn only for the change's own copy, until it is fixed or marked.
  • No model, prompt or threshold change; the requests are byte-for-byte the same. The rule version for shared logic goes from 23 to 24 and COMPOSITION from v13 to v14. Neither is part of the answer cache key, so nothing is asked again.
  • No jevgate.toml key was added (the issue left one optional), so jevgate.schema.json is unchanged.
b.rs:2 review maintainability/shared-logic: `load_team` (b.rs:2), which this change touched, may repeat logic that copies it left untouched also hold: `load_user` (a.rs:2, in a file this change edits). Next: Fix this change's copy, such as by reusing an untouched one; if sharing the logic would rewrite the untouched copies, mark the finding `later --note "#issue"`

How it was checked

  • src/units/tests/changed.rs:

    • A group of three where the change touches one copy: the finding moves to that copy's file and line, and names the two untouched copies (file_changed: true). A check of whole files gives the same fingerprint at the first copy.
    • The same group with every copy touched is reported as before.
    • A copy in an explicit --context file is named as being in a file outside this change.
  • src/hook/tests/mod.rs: in a turn that edits one copy, the end-of-turn block points at that copy and names the untouched one. Once the finding is marked later --note "#192", the turn ends.

  • tests/cli/changes.rs: the binary, with a mock provider:

    • a diff touching one copy of a pair moves the finding to that copy and fills untouched;
    • a diff touching both copies leaves the finding as it was found, with no untouched.
  • cargo fmt --check, cargo clippy --locked --all-targets -- -D warnings and cargo test --locked pass (889 unit, 83 CLI, 3 lint-policy tests)

  • cargo +1.90.0 check --locked was not run: 1.90 is not installed here, and CI runs it

  • CHANGELOG.md has a line under Unreleased

JevGate gate (jevgate check --base origin/main --rule all --include-tests): passed.

Fixed: the files' "strongest first, then status" code had copies in compose, grouping and the new move. They now share strongest_first and reorder. The anchoring step runs inside compose_files.

Dismissed one at a time with baseline mark --note:

  • src/units/tests/changed.rs:7 file-organization, wrong: every test in the file checks what a --base check judges.
  • tests/cli/changes.rs:5 file-organization, later: as on main, the file mixes --base, --config and GitHub format tests. The old entry got the same note.
  • src/units/compose/mod.rs:672 finding, intended: as on main; this PR only adds the new empty field.
  • src/evaluate.rs:297 Session::evaluate, intended: as on main; only the compose_files call changed.
  • src/units/compose/comments.rs:44 comment_findings, intended: as on main; this PR only adds the new empty field.
  • src/units/grouping.rs:30 shared-logic, wrong: a two-line loop that calls the shared reorder.
  • src/hook/tests/mod.rs:371 shared-logic, intended: the binary's unit tests and the CLI test crate cannot share a fixture.
  • src/units/plan/mod.rs:196 shared-logic, wrong: one lines.touch call on different spans.

…ntouched

In a check of changed lines, and in an agent's turn, a shared-logic
finding whose change touched only some copies now sits at the first copy
the change touched, in that copy's file, and names each untouched copy
and whether its file is one the change edits. Its next step is to fix
the change's copy, or mark the finding `later --note "#issue"` when
sharing the logic would rewrite the untouched copies. The JSON report
lists them under `untouched`. The fingerprint stays the one the repeat
has in a check of whole files, so baselines still accept it, and what
fails the gate is unchanged; the hook holds a turn only for the change's
own copy.

A file's findings are reordered and its status recomputed by one helper
after grouping and after moving.
@tauanbinato
tauanbinato marked this pull request as ready for review October 4, 2026 02:32
@tauanbinato
tauanbinato merged commit a59fe90 into main Oct 4, 2026
12 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Flag cross-file shared-logic findings so a change fixes only its own copy

1 participant