fix: align scanner dedup rules with GitHub state_reason semantics

Author: Copilot

.github/workflows/duplicate-code-detector.md

@@ -157,7 +157,7 @@ Before filing new issues, check BOTH open AND closed issues:
 1. Search for issues with `[Duplicate Code]` prefix using the GitHub toolset with `state: all` (or equivalent `is:open` + `is:closed`)
 2. Also search for issues with labels `code-quality` or `refactoring` that describe duplication using `state: all` (or equivalent `is:open` + `is:closed`)
 3. Skip any finding that already has an open tracking issue
-4. For matching closed issues: **auto-skip only when closure reason is "not planned" / "won't fix"**. If closed as completed/fixed and the finding still reproduces, reopen the prior issue or file a new one with fresh evidence and a link to the prior issue.
+4. For matching closed issues, check the GitHub `state_reason`: **auto-skip only when `state_reason` is `not_planned`** (often shown as "won't fix" / "not planned"). If `state_reason` is `completed` and the finding still reproduces, reopen the prior issue or file a new one with fresh evidence and a link to the prior issue.
 
 ## Phase 6: Prioritize and Report Findings
 
@@ -214,7 +214,7 @@ Low / Medium / High
 - **Be specific**: Always include file paths and line numbers in the evidence section
 - **Be actionable**: Each issue should have a clear, implementable suggestion
 - **Avoid noise**: Only file issues for genuine duplication with real maintenance impact — not cosmetic similarities
-- **No duplicates**: Check existing issues with `state: all`; only treat closed issues as terminal when they were closed as "not planned" / "won't fix"
+- **No duplicates**: Check existing issues with `state: all`; only treat closed issues as terminal when `state_reason` is `not_planned`
 - **Security awareness**: Flag duplicated security-critical logic (domain validation, ACL rules, capability management) with higher urgency
 - **Cap at 5 issues**: File at most 5 issues per run to avoid flooding the tracker
 

.github/workflows/export-audit.md

@@ -211,7 +211,7 @@ Before creating new issues, check BOTH open AND closed issues:
 1. Search for issues with `[Export Audit]` prefix mentioning the same symbol or file using `state: all` (or equivalent `is:open` + `is:closed`)
 2. Search for issues with the `code-quality` label mentioning the same symbol or file using `state: all` (or equivalent `is:open` + `is:closed`)
 3. Skip any finding that already has an open tracking issue
-4. For matching closed issues: **auto-skip only when closure reason is "not planned" / "won't fix"**. If closed as completed/fixed and the finding still reproduces, reopen the prior issue or file a new one with fresh evidence and a link to the prior issue.
+4. For matching closed issues, check the GitHub `state_reason`: **auto-skip only when `state_reason` is `not_planned`** (often shown as "won't fix" / "not planned"). If `state_reason` is `completed` and the finding still reproduces, reopen the prior issue or file a new one with fresh evidence and a link to the prior issue.
 
 ## Phase 7: Prioritize and File Issues
 
@@ -266,7 +266,7 @@ Unused export / Naming inconsistency / Circular dependency / Import path issue
 
 - **Verify before filing**: Confirm that the export is truly unused by checking all import sites, including test files and any barrel exports (`index.ts`)
 - **Be precise**: Include the exact symbol name, file path, and line number in the evidence
-- **No duplicates**: Always check existing issues with `state: all`; only treat closed issues as terminal when they were closed as "not planned" / "won't fix"
+- **No duplicates**: Always check existing issues with `state: all`; only treat closed issues as terminal when `state_reason` is `not_planned`
 - **Batch related findings**: If multiple unused exports are in the same file, file a single issue listing all of them
 - **Cap at 5 issues**: File at most 5 issues per run to avoid noise
 

.github/workflows/refactoring-scanner.md

@@ -186,7 +186,7 @@ Before creating new issues, check BOTH open AND closed issues:
 1. Search for issues with `[Refactoring]` prefix mentioning the same file using `state: all` (or equivalent `is:open` + `is:closed`)
 2. Search for issues with labels `code-quality` or `refactoring` mentioning the same file using `state: all` (or equivalent `is:open` + `is:closed`)
 3. Skip any finding that already has an open tracking issue
-4. For matching closed issues: **auto-skip only when closure reason is "not planned" / "won't fix"**. If closed as completed/fixed and the finding still reproduces, reopen the prior issue or file a new one with fresh evidence and a link to the prior issue.
+4. For matching closed issues, check the GitHub `state_reason`: **auto-skip only when `state_reason` is `not_planned`** (often shown as "won't fix" / "not planned"). If `state_reason` is `completed` and the finding still reproduces, reopen the prior issue or file a new one with fresh evidence and a link to the prior issue.
 
 ## Phase 6: Prioritize and File Issues
 
@@ -253,7 +253,7 @@ Low / Medium / High
 
 - **Evidence-based**: Every issue must cite specific line counts, function names, or code patterns
 - **Actionable**: Propose a concrete split/extraction, not just "this is too big"
-- **No duplication**: Always check existing issues with `state: all`; only treat closed issues as terminal when they were closed as "not planned" / "won't fix"
+- **No duplication**: Always check existing issues with `state: all`; only treat closed issues as terminal when `state_reason` is `not_planned`
 - **Security awareness**: Files containing security-critical logic (iptables, Squid config, domain validation) should be flagged with higher urgency
 - **Be realistic**: Suggest splits that keep related logic together — don't over-fragment
 - **Cap at 5 issues**: File at most 5 issues per run