omv-criticlisted

# omv-critic Challenge the finding before report submission. ## Invocation ```text /omv-critic <id> ``` ## Workflow 1. Read `.omv/findings/<id>.yaml` using `contracts/evidence.v1.yaml` as the local schema reference. 2. If present, read `.omv/threatmaps/<id>.yaml` using `contracts/threat-map.v1.yaml` as the local schema reference. 3. If present, read `.omv/verifications/<id>.yaml` using `contracts/verification.v1.yaml` as the local schema reference. 4. Run or inspect `omv findings validate <id>` and `omv verification validate <id>` when the sidecar exists. 5. Evaluate argument quality separately from structural validation. 6. Evaluate acceptance precedent (below) — evidence quality and acceptance odds are different axes. 7. Output `reject_risk: low|medium|high` and a recommended `researcher_goal`. 8. For medium or high risk, list 3-5 likely CNA or maintainer rejection reasons and concrete strengthening actions. ## Review Focus - novelty and duplicate risk - acceptance precedent (see below) - affected version proof - source -> sink -> guard clarity - local observed result quality - CVSS and impact overclaiming - disclosure readiness If `reject_risk: high`, do not recommend `/omv-report` yet. ## Acceptance-Precedent Method Ask three questions the machine gates cannot: 1. **Class precedent in this ecosystem**: has this CNA/database accepted this vulnerability class for library packages before (e.g. code execution in a parser when input is attacker-controlled in r