Library Maintenance: should a fixed finding stop that file being checked again?

[PapaBearDoes]

While testing the naming fixes in #1881 on my own library I hit something in Library Maintenance that I think is a design question more than a bug:

repair_create_finding skips a new finding when one already exists for the same job, type and entity (or file path) in any status. The comment above it says that's on purpose, so a re-scan never brings back a dismissed or fixed finding. For dismissed ones that makes sense to me. For findings that were fixed, it has a side effect: once a fix is approved, that job never looks at that file again.

Two places that bit me with Naming Conformance:

1. A wrong fix can't be corrected by a re-scan. Before fix(video): naming templates followed on import and rename #1881, a show whose title carries its year (Treasure Island (2026)) was renamed to Treasure Island (2026) (2026) - S01E01.... With the fix deployed, a re-scan found nothing for those files, because their old resolved findings were still there. They only came back after I cleared every Naming Conformance finding.
2. Clear Findings follows the status filter. With the filter on Pending it leaves resolved and dismissed rows alone, so clearing from that view doesn't help. Setting the filter to All before clearing does, but it also wipes every dismissal, which then has to be redone.

The same would apply after a template change: files fixed under the old template are never flagged against the new one.

A couple of shapes I can think of:

• A resolved finding blocks only while the file is still where the fix left it. Naming Conformance keys its findings on scope:item_id:file_id and stores no file path, so the key survives any rename. If a resolved finding only counted as a duplicate while the file's current path matched its expected_path, a file that drifts again would be found. The catch is that a finding marked resolved by hand, with no fix, would come back on the next scan.
• A "re-check resolved" action per job, which drops that job's resolved findings (keeping dismissals) and runs a scan. Smaller change, and it leaves the default behavior exactly as it is.

Is the current behavior what you want for fixed findings?

[Nezreka]

good catch, and no XD fixed shouldn't mean never checked again. that rule was inherited from how the video side copied the old music dedup, and the music side had already moved on from it.

got a fix up in #1888, porting the rule music already uses:

• dismissed = silent forever. nothing brings it back, and nothing in this touches dismissals
• resolved = quiet for 7 days (long enough for a fix that's still landing, like a rename waiting on a server rescan), then a scan that still sees the problem raises a fresh finding
• if the expected path changed since the fix — template edit, or a naming fix like fix(video): naming templates followed on import and rename #1881 — it re-raises straight away. so your Treasure Island (2026) (2026) files get picked up on the next scan against the new rule, no clearing findings needed
• your hand-resolved catch: yeah, one of those comes back after the 7 days if the file is still wrong. that's deliberate — resolved means "i fixed it" and the scan checks the work. dismiss is the "leave me alone" one

went with your expected_path shape over the re-check button, so there's nothing new to remember to press and the default scan just does the right thing.

thanks for testing #1881 against your own library and writing this up properly. the two cases made it easy to pin down. still reviewing the pr now but will push to dev soon