Boundary discovery while fixing #676 (hypatia-side work landed in e8eebda): the scans/*.json producer that emits dependency_graph.edges, taint_matrix.rows, recommended_attacks and the per-repo language field is not part of the hypatia repository. hypatia only consumes those files (VerisimConnector.fetch_all_scans/0, CrossRepoLearning, PatternRegistry, VCL.FileExecutor, the ArangoDB sync).
So the #676 suggested fix — sort before serialising (edges by from/to, rows by source_category+sink_axis, attack lists lexically; BTreeMap or an explicit sort at the emit boundary) — must land in whichever component writes verisimdb-data's scans/. This issue tracks that producer-side work until its home repo is identified; when it is, transfer this there.
Evidence of the fault (from #676, verified against verisimdb-data#72): a no-change rescan produced +20,277/−20,277 across 249 files, with opposite-direction language flips in one run (idris→rust AND rust→idris), which is the signature of an unstable tie-break / hash-order iteration, not genuine reclassification.
What hypatia already did (e8eebda): the three in-repo readers of language now resolve deterministically through one shared function (count desc → fixed priority → lexical), with a discriminating test that fails on the old Enum.max_by tie-break. That fixes hypatia's own flip contribution but not the array churn in the scan files themselves.
Boundary discovery while fixing #676 (hypatia-side work landed in e8eebda): the
scans/*.jsonproducer that emitsdependency_graph.edges,taint_matrix.rows,recommended_attacksand the per-repolanguagefield is not part of the hypatia repository. hypatia only consumes those files (VerisimConnector.fetch_all_scans/0,CrossRepoLearning,PatternRegistry,VCL.FileExecutor, the ArangoDB sync).So the #676 suggested fix — sort before serialising (edges by from/to, rows by source_category+sink_axis, attack lists lexically; BTreeMap or an explicit sort at the emit boundary) — must land in whichever component writes verisimdb-data's
scans/. This issue tracks that producer-side work until its home repo is identified; when it is, transfer this there.Evidence of the fault (from #676, verified against verisimdb-data#72): a no-change rescan produced +20,277/−20,277 across 249 files, with opposite-direction language flips in one run (
idris→rustANDrust→idris), which is the signature of an unstable tie-break / hash-order iteration, not genuine reclassification.What hypatia already did (e8eebda): the three in-repo readers of
languagenow resolve deterministically through one shared function (count desc → fixed priority → lexical), with a discriminating test that fails on the oldEnum.max_bytie-break. That fixes hypatia's own flip contribution but not the array churn in the scan files themselves.