scan: estate rescan (run 30978827683)

[hyperpolymath]

Automated estate rescan from hyperpolymath/hypatia run 30978827683. Squash-merged: it is the only merge method that satisfies required_signatures + required_linear_history on this repo.

[gitar-bot]

💡 Quality: Non-deterministic scanner output creates large no-op diffs

Nearly all 502/-502 changes across 249 files are semantically identical reorderings — e.g. recommended_attacks (Axiom.jl.json:916-921), dependency_graph.edges reshuffled with no content change (hermeneia.json:385-437, cloudguard-server.json:161-310), and taint_matrix.rows swapped in place (kea.json:240-281, chapeliser.json:152-196). The underlying data is unchanged; only element ordering differs between runs. This makes each rescan a noisy diff that is impossible to review meaningfully and hides any real signal. Have the upstream generator (hypatia) emit arrays in a stable, deterministic sort order (e.g. sort edges by from/to, rows by source_category+sink_axis, attack lists lexically) so future rescans only surface genuine changes.

_{Was this helpful? React with 👍 / 👎}

[hyperpolymath]

Confirmed — this is correct, and verified against the diff before replying.

+20,277 / −20,277 across 249 files, exactly symmetric. Spot-checked scans/dafniser.json: "language": "idris" → "rust", and ["disk","memory"] → ["memory","disk"] — a pure reorder with identical content, as described. The mutually-inconsistent flip directions (lustreiser goes rust→idris while dafniser/halideiser go idris→rust) are the tell that this is an arbitrary tie-break, not a genuine reclassification.

Disposition: fix filed upstream, not here. verisimdb-data only stores hypatia's output, so a change here would be overwritten by the next rescan. Tracked as hyperpolymath/hypatia#676 with the evidence and the suggested fixes (sort at the emit boundary; deterministic language tie-break by file count then fixed priority).

Not resolving this thread — it stays open until hypatia#676 lands and a rescan produces a clean diff, which is the real test.

Noting for the record that both of this run's findings were true and both were in-diff observations.

[gitar-bot]

Acknowledged — thanks for the thorough spot-check and for filing hyperpolymath/hypatia#676 upstream. Agreed this needs to be fixed at the emitter, not here. Leaving this thread open per your note until a rescan confirms a clean, deterministic diff.

[gitar-bot]

💡 Quality: Unstable language classification flips between rescans

Several repos have their detected language field flipped with no other corroborating change, and the flips are mutually inconsistent (e.g. dafniser idris→rust and halideiser idris→rust, but lustreiser rust→idris; awesome-idris2 scheme→idris while i-human zig→idris and unified-dataset-vocab idris→zig; anvomidav elixir→scheme, refugia nickel→shell, rescript-ecosystem javascript→shell). This oscillation suggests the language detector is non-deterministic or tie-breaks arbitrarily on multi-language repos, which will corrupt any downstream analysis keyed on language. Make detection deterministic (stable ordering / explicit tie-break by file count or priority) so classification is reproducible across runs.

_{Was this helpful? React with 👍 / 👎}

[hyperpolymath]

Confirmed — this is correct, and verified against the diff before replying.

+20,277 / −20,277 across 249 files, exactly symmetric. Spot-checked scans/dafniser.json: "language": "idris" → "rust", and ["disk","memory"] → ["memory","disk"] — a pure reorder with identical content, as described. The mutually-inconsistent flip directions (lustreiser goes rust→idris while dafniser/halideiser go idris→rust) are the tell that this is an arbitrary tie-break, not a genuine reclassification.

Disposition: fix filed upstream, not here. verisimdb-data only stores hypatia's output, so a change here would be overwritten by the next rescan. Tracked as hyperpolymath/hypatia#676 with the evidence and the suggested fixes (sort at the emit boundary; deterministic language tie-break by file count then fixed priority).

Not resolving this thread — it stays open until hypatia#676 lands and a rescan produces a clean diff, which is the real test.

Noting for the record that both of this run's findings were true and both were in-diff observations.

[gitar-bot]

Acknowledged — the mutually-inconsistent flip directions are solid evidence this is a tie-break bug rather than a real reclassification. Good that it's tracked in hyperpolymath/hypatia#676 alongside the ordering issue. Leaving this thread open until that lands and a rescan produces a stable diff.

[gitar-bot]

⚠️ This PR is blocked due to unresolved code review findings.

_{Configure merge blocking · Maintainers can dismiss this review.}

[gitar-bot]

Gitar has auto-approved this PR and enabled auto-merge (configure)

[gitar-bot]

Note

Automatic reviews are paused because your trial's included automatic processing has been used for this period. Upgrade now, or comment "Gitar review" to run a review anytime.
Learn more

Code Review 👍 Approved with suggestions 0 resolved / 2 findings

Automated estate rescan refreshing repository metadata across 341 repositories. Non-deterministic scanner output causes large no-op diffs and unstable language classifications that should be addressed in the scanner configuration.

Auto-approved and auto-merge armed: No blocking issues found.
Please see Auto-approve Docs for details on setting custom approval criteria. — merges when pipeline and required approvals pass.

💡 Quality: Non-deterministic scanner output creates large no-op diffs

📄 scans/Axiom.jl.json:916-921 📄 scans/hermeneia.json:385-399 📄 scans/cloudguard-server.json:161-175 📄 scans/kea.json:240-254 📄 scans/chapeliser.json:152-166

Nearly all 502/-502 changes across 249 files are semantically identical reorderings — e.g. recommended_attacks (Axiom.jl.json:916-921), dependency_graph.edges reshuffled with no content change (hermeneia.json:385-437, cloudguard-server.json:161-310), and taint_matrix.rows swapped in place (kea.json:240-281, chapeliser.json:152-196). The underlying data is unchanged; only element ordering differs between runs. This makes each rescan a noisy diff that is impossible to review meaningfully and hides any real signal. Have the upstream generator (hypatia) emit arrays in a stable, deterministic sort order (e.g. sort edges by from/to, rows by source_category+sink_axis, attack lists lexically) so future rescans only surface genuine changes.

💡 Quality: Unstable language classification flips between rescans

📄 scans/dafniser.json:3-4 📄 scans/halideiser.json:3-4 📄 scans/lustreiser.json:3-4 📄 scans/awesome-idris2.json:3-4 📄 scans/i-human.json:3-4 📄 scans/anvomidav.json:3-4 📄 scans/refugia.json:3-4

Several repos have their detected language field flipped with no other corroborating change, and the flips are mutually inconsistent (e.g. dafniser idris→rust and halideiser idris→rust, but lustreiser rust→idris; awesome-idris2 scheme→idris while i-human zig→idris and unified-dataset-vocab idris→zig; anvomidav elixir→scheme, refugia nickel→shell, rescript-ecosystem javascript→shell). This oscillation suggests the language detector is non-deterministic or tie-breaks arbitrarily on multi-language repos, which will corrupt any downstream analysis keyed on language. Make detection deterministic (stable ordering / explicit tie-break by file count or priority) so classification is reproducible across runs.

🤖 Prompt for agents

Code Review: Automated estate rescan refreshing repository metadata across 341 repositories. Non-deterministic scanner output causes large no-op diffs and unstable language classifications that should be addressed in the scanner configuration.

1. 💡 Quality: Non-deterministic scanner output creates large no-op diffs
   Files: scans/Axiom.jl.json:916-921, scans/hermeneia.json:385-399, scans/cloudguard-server.json:161-175, scans/kea.json:240-254, scans/chapeliser.json:152-166

   Nearly all 502/-502 changes across 249 files are semantically identical reorderings — e.g. `recommended_attacks` (Axiom.jl.json:916-921), `dependency_graph.edges` reshuffled with no content change (hermeneia.json:385-437, cloudguard-server.json:161-310), and `taint_matrix.rows` swapped in place (kea.json:240-281, chapeliser.json:152-196). The underlying data is unchanged; only element ordering differs between runs. This makes each rescan a noisy diff that is impossible to review meaningfully and hides any real signal. Have the upstream generator (hypatia) emit arrays in a stable, deterministic sort order (e.g. sort edges by from/to, rows by source_category+sink_axis, attack lists lexically) so future rescans only surface genuine changes.

2. 💡 Quality: Unstable language classification flips between rescans
   Files: scans/dafniser.json:3-4, scans/halideiser.json:3-4, scans/lustreiser.json:3-4, scans/awesome-idris2.json:3-4, scans/i-human.json:3-4, scans/anvomidav.json:3-4, scans/refugia.json:3-4

   Several repos have their detected `language` field flipped with no other corroborating change, and the flips are mutually inconsistent (e.g. dafniser idris→rust and halideiser idris→rust, but lustreiser rust→idris; awesome-idris2 scheme→idris while i-human zig→idris and unified-dataset-vocab idris→zig; anvomidav elixir→scheme, refugia nickel→shell, rescript-ecosystem javascript→shell). This oscillation suggests the language detector is non-deterministic or tie-breaks arbitrarily on multi-language repos, which will corrupt any downstream analysis keyed on `language`. Make detection deterministic (stable ordering / explicit tie-break by file count or priority) so classification is reproducible across runs.

Options

Display: compact → Showing less information.

Comment with these commands to change the behavior for this request:

Compact

gitar display:verbose

---

Important

Your trial ends in 5 days — upgrade now to keep code review, CI analysis, auto-apply, custom automations, and more.

_{Was this helpful? React with 👍 / 👎 | Gitar}

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud