[GH-ISSUE #6338] [Feature] Add a focused comparison report for two compatible analysis runs #3821

New issue

Open

opened 2026-10-31 00:44:23 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-31 00:44:23 +00:00

Owner

Originally created by @jayykernel on GitHub (Oct 22, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/6338

Problem

Analysts often need to understand what changed between two analyses of the same artifact or two versions of an artifact. Comparing full JSON output manually is noisy because ordering, timestamps, and incidental metadata can obscure meaningful changes.

Desired outcome

Provide a comparison view or command for compatible analysis results that summarizes added, removed, and changed findings while retaining links to the source evidence.

Proposed behavior

Require compatible result types and explain when comparison is unsupported.
Classify findings as added, removed, unchanged, or changed using documented matching rules.
Separate semantic changes from presentation-only differences.
Preserve references to the original records in both runs.
Identify incomplete inputs and avoid treating missing results as proof that a finding disappeared.

Acceptance criteria

Tests cover identical inputs, reordered records, added/removed findings, and incomplete results.
Comparison is deterministic.
Incompatible runs fail with a clear explanation rather than producing misleading output.
Original analysis records are not modified.

Scope

The first version can support a limited set of result types with reliable finding identity. It should not infer semantic equivalence where the available data cannot establish it.

Originally created by @jayykernel on GitHub (Oct 22, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/6338 ### Problem Analysts often need to understand what changed between two analyses of the same artifact or two versions of an artifact. Comparing full JSON output manually is noisy because ordering, timestamps, and incidental metadata can obscure meaningful changes. ### Desired outcome Provide a comparison view or command for compatible analysis results that summarizes added, removed, and changed findings while retaining links to the source evidence. ### Proposed behavior - Require compatible result types and explain when comparison is unsupported. - Classify findings as added, removed, unchanged, or changed using documented matching rules. - Separate semantic changes from presentation-only differences. - Preserve references to the original records in both runs. - Identify incomplete inputs and avoid treating missing results as proof that a finding disappeared. ### Acceptance criteria - Tests cover identical inputs, reordered records, added/removed findings, and incomplete results. - Comparison is deterministic. - Incompatible runs fail with a clear explanation rather than producing misleading output. - Original analysis records are not modified. ### Scope The first version can support a limited set of result types with reliable finding identity. It should not infer semantic equivalence where the available data cannot establish it.

bsakaguchi commented

2026-10-31 00:44:23 +00:00

Author

Owner

@XinwangTao commented on GitHub (Oct 25, 2026):

This comparison report would be genuinely useful — diffing full JSON outputs by hand is noisy and hides meaningful deltas. A few concrete suggestions: (1) normalize ordering and timestamps by default and make the ignore-list configurable so incidental metadata never pollutes the diff; (2) keep evidence links on both added and changed findings so reviewers can jump straight to the source; (3) define "changed" carefully (same finding id with altered fields) and surface it distinctly from added/removed, since that is where the real signal lives for version-to-version analysis.

@XinwangTao commented on GitHub (Oct 25, 2026): This comparison report would be genuinely useful — diffing full JSON outputs by hand is noisy and hides meaningful deltas. A few concrete suggestions: (1) normalize ordering and timestamps by default and make the ignore-list configurable so incidental metadata never pollutes the diff; (2) keep evidence links on both added and changed findings so reviewers can jump straight to the source; (3) define "changed" carefully (same finding id with altered fields) and surface it distinctly from added/removed, since that is where the real signal lives for version-to-version analysis.

bsakaguchi referenced this issue

2026-10-31 01:10:28 +00:00

[PR #3821] [MERGED] fix(website): use Noto Sans KR for Korean text #5922

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#3821

No description provided.

Rows
Columns