Problem
When CodeQL query packs are upgraded or custom queries are added/changed, the resulting SARIF upload can cause alert churn: previously dismissed alerts reappear as new open alerts because the replacement query produces different partialFingerprints, even though it detects the same vulnerability at the same code location. There is no tooling to:
- Capture the full alert lifecycle state (open, dismissed, fixed) along with dismissal metadata before a query change
- Detect when new/changed queries overlap with already-dismissed alerts at the same code locations
- Batch-dismiss the churned alerts post-upload while preserving the original dismissal rationale
The GitHub Code Scanning SARIF upload API does not support specifying alert state inline — dismissed state can only be applied per-alert via the PATCH /repos/{owner}/{repo}/code-scanning/alerts/{alert_number} endpoint after upload.
Desired State
The gh-ql-mcp-client CLI should provide three commands that compose into a pipeline for managing Code Scanning alert lifecycle across query changes:
code-scanning report
Produce a JSON snapshot of all analyses and alerts (across all states) for a repository. Must preserve dismissal metadata (reason, comment, who, when) so downstream phases can detect churn. Output: <owner>_<repo>.cs-report.json.
code-scanning assess
Consume the report and detect overlapping alerts across different rules at the same file:line. Flag churn risk where an open alert overlaps a previously dismissed alert from a semantically equivalent query. Produce keep/review/discard recommendations per alert. Output: <owner>_<repo>.cs-assess.json.
code-scanning apply
Consume the assess report and execute the recommended alert state changes via the GitHub API. Must support --dry-run for previewing changes, --accept-all-changes for batch authorization, and --accept-change-for-rule for per-rule authorization. Output: <owner>_<repo>.cs-apply.json.
Context
Problem
When CodeQL query packs are upgraded or custom queries are added/changed, the resulting SARIF upload can cause alert churn: previously dismissed alerts reappear as new open alerts because the replacement query produces different
partialFingerprints, even though it detects the same vulnerability at the same code location. There is no tooling to:The GitHub Code Scanning SARIF upload API does not support specifying alert state inline — dismissed state can only be applied per-alert via the
PATCH /repos/{owner}/{repo}/code-scanning/alerts/{alert_number}endpoint after upload.Desired State
The
gh-ql-mcp-clientCLI should provide three commands that compose into a pipeline for managing Code Scanning alert lifecycle across query changes:code-scanning reportProduce a JSON snapshot of all analyses and alerts (across all states) for a repository. Must preserve dismissal metadata (reason, comment, who, when) so downstream phases can detect churn. Output:
<owner>_<repo>.cs-report.json.code-scanning assessConsume the report and detect overlapping alerts across different rules at the same file:line. Flag churn risk where an open alert overlaps a previously dismissed alert from a semantically equivalent query. Produce keep/review/discard recommendations per alert. Output:
<owner>_<repo>.cs-assess.json.code-scanning applyConsume the assess report and execute the recommended alert state changes via the GitHub API. Must support
--dry-runfor previewing changes,--accept-all-changesfor batch authorization, and--accept-change-for-rulefor per-rule authorization. Output:<owner>_<repo>.cs-apply.json.Context
ql-mcp-clientin Go as aghCLI extension for Code Scanning SARIF management #207sarif_diff_by_commits) #215 (sarif_diff_by_commits),ql-mcp-clientPhase 3(B): Code Scanning lifecycle, SARIF enhancements, andghextension packaging #218 (Phase 3B)partialFingerprintsis the server-side correlation mechanism; fingerprint divergence between old and new queries is the root cause of alert churn