fix(plugin): remove conflicting reporting rule

plugins/codex-security/skills/attack-path-analysis/references/severity-policy.md

@@ -3,6 +3,7 @@
 Use this guidance after attack-path facts, reachability, and counterevidence are established.
 
 -- Considerations for severity / criticality re-rating --
+
 - For `high` and above, the impact must be materially security-relevant (for example: account takeover, auth bypass, meaningful privilege escalation, significant sensitive data exposure/exfiltration, credible RCE, or similarly severe compromise), not simply a bug or strange behavior
 - For a finding to remain `high` or `critical`, the exploitation path and impact should be clear enough that a professional security reviewer would not need a long speculative argument to justify it.
 - Do **not** treat ordinary code bugs as high/critical security issues just because they are bugs or because the scanner labeled them that way.
@@ -13,6 +14,7 @@ Use this guidance after attack-path facts, reachability, and counterevidence are
 - If it is actually provable that there is no bug at all (the description is entirely wrong or made up and you actually got that real proof that it is so), then label it as `ignore` for criticality to mark a false-positive.
 
 Non-exhaustive examples of vulnerabilities that often support `critical` when evidenced in code and context:
+
 - Credible RCE or arbitrary code execution (command injection, LFI exec, trivial memory corruption exploits, etc.). Requires actual proof that attacker input causes this from an in-scope attack surface.
 - Real XSS with meaningful proven impact (for example session/token theft, account compromise, privileged action execution, etc)
 - Account takeover or strong authentication bypass, especially if it is 0-click
@@ -27,6 +29,7 @@ Non-exhaustive examples of vulnerabilities that often support `critical` when ev
 - etc, other bugs not listed which follow this level of critical severity and impact; with actual proof that these bugs are reachable from in-scope attack-surface.
 
 Non-exhaustive examples of vulnerabilities that often support `high` when evidenced in code and context:
+
 - Server Side Request Forgery where there is actual proof that (1) an attacker can control the url being requested (bypassing protections around that) from in-scope attack-surface and (2) there are likely other local/lan/cloud services which can be reached to show actual impact. Be careful with reporting webhooks unless there is clear proof that it is dangerous, but do not treat a product-intended webhook/download/callback feature or optional operator allow/deny list as suppression evidence when attacker-controlled destinations can still reach internal, metadata, file-backed, redirect, or side-effecting targets.
 - Exploitable memory corruption with clear, major impact or ease of exploitation
 - Arbitrary file read that exposes less-sensitive user data or source code (if you have actual proof it reveals env secrets, then it is critical)
@@ -42,6 +45,7 @@ Non-exhaustive examples of vulnerabilities that often support `high` when eviden
 - Deserialization, SSTI, plugin abuse, macro / template abuse, or interpreter abuse where dangerous primitives are clearly reachable and impactful, but code execution or compromise is not fully proven to the standard needed for critical.
 
 Strong factors that often push a plausible `high` up to `critical`:
+
 - Unauthenticated or near-unauthenticated reachability from the internet or other broad in-scope surfaces.
 - 0-click or extremely low-friction exploitation.
 - Cross-tenant / cross-boundary impact rather than same-user or same-tenant impact.
@@ -50,6 +54,7 @@ Strong factors that often push a plausible `high` up to `critical`:
 - Clear proof of code execution, full account takeover, or crown-jewel secret access rather than only a plausible path.
 
 Examples that usually should not remain `high`/`critical` without very strong proof of it leading to the class of vulnerabilities above:
+
 - Generic correctness/reliability bugs
 - Strange edge cases with unclear attacker value
 - Low-impact information leaks
@@ -70,6 +75,7 @@ Examples that usually should not remain `high`/`critical` without very strong pr
 - Arbitrary file read limited to public files, low-sensitivity files, or source fragments with no realistic security consequence.
 
 High/Critical acceptance checklist (all should be true, unless the threat model strongly justifies an exception):
+
 - In-scope component
 - Realistic attacker
 - Reasonable in-scope attack surface
@@ -106,7 +112,6 @@ Final policy-adjustment guidance:
   - `none` does not increase likelihood based on exposure
 - Then decide reportability using the existing facts:
   - if repository evidence does not establish a realistic lower-privileged in-scope attacker path, set `ignore`
-  - if the path is internal-only, developer-only, operator-only, localhost-only, privileged-local, or otherwise not meaningfully reportable in context, set `ignore`
 
 Do not suppress solely because the surface is private or internal when repository evidence still shows a meaningful authorization, trust-boundary, identity, or security-control regression in a real product or production-service workflow. In those cases, internal exposure should usually reduce likelihood or confidence rather than force `ignore`.