Is your feature request related to a problem? Please describe.
Yeah. If you run Strix against the same target more than once (after partial fixes, or on a schedule), it re-discovers and re-reports vulnerabilities that were already found in an earlier scan. There's no way to tell a fresh run "here's what we already know about, don't spend budget rediscovering it."
Right now the only workaround is stuffing known findings into --instruction/--instruction-file as free text. That's just a prompt hint the agents can ignore, not an enforced filter.
Describe the solution you'd like
We already have most of what's needed for this. check_duplicate() in strix/report/dedupe.py does LLM-based fuzzy comparison against a list of prior report dicts. It just never gets handed findings from a different run's directory.
- New flag, something like
--baseline-run RUN_NAME, pointing at a prior run under strix_runs/.
- On startup, load that run's
vulnerabilities.json and feed it into the same corpus check_duplicate already checks against.
- Need to decide how a match should surface: drop it entirely, or keep it in the output tagged as "unresolved since
<baseline-run>" so nothing just disappears silently. I'd lean toward the second option.
- Tests along the same lines as
tests/test_dedupe_model.py.
Describe alternatives you've considered
Auto-detecting "the last run against this target" instead of an explicit flag. More convenient, but it needs target-matching logic across every run.json in strix_runs/, and that's its own can of worms (renamed targets, multiple targets per run, etc). Figured the explicit flag is the safer first step, and auto-detection could be a follow-up once that proves out.
Additional context
Checked existing issues/PRs first (baseline, known findings, previous scan, re-report, duplicate across runs, regression testing, etc). Closest matches are #29/#205/#206 (resume/continue a scan) and #627 (same-run dedup bypass bug), but both work within a single run, not across separate runs.
Is your feature request related to a problem? Please describe.
Yeah. If you run Strix against the same target more than once (after partial fixes, or on a schedule), it re-discovers and re-reports vulnerabilities that were already found in an earlier scan. There's no way to tell a fresh run "here's what we already know about, don't spend budget rediscovering it."
Right now the only workaround is stuffing known findings into
--instruction/--instruction-fileas free text. That's just a prompt hint the agents can ignore, not an enforced filter.Describe the solution you'd like
We already have most of what's needed for this.
check_duplicate()instrix/report/dedupe.pydoes LLM-based fuzzy comparison against a list of prior report dicts. It just never gets handed findings from a different run's directory.--baseline-run RUN_NAME, pointing at a prior run understrix_runs/.vulnerabilities.jsonand feed it into the same corpuscheck_duplicatealready checks against.<baseline-run>" so nothing just disappears silently. I'd lean toward the second option.tests/test_dedupe_model.py.Describe alternatives you've considered
Auto-detecting "the last run against this target" instead of an explicit flag. More convenient, but it needs target-matching logic across every
run.jsoninstrix_runs/, and that's its own can of worms (renamed targets, multiple targets per run, etc). Figured the explicit flag is the safer first step, and auto-detection could be a follow-up once that proves out.Additional context
Checked existing issues/PRs first (baseline, known findings, previous scan, re-report, duplicate across runs, regression testing, etc). Closest matches are #29/#205/#206 (resume/continue a scan) and #627 (same-run dedup bypass bug), but both work within a single run, not across separate runs.