Ask
When ci-failure ingestion files a scan failure (grype/trivy --fail-on high gate), parse the scanner's findings table out of the job log and render it as a structured list in the issue body, instead of embedding only the raw log. For each fixable finding include: package, installed version, fixed-in version, severity, and — when the scanner reports it — the file/binary path the finding sits on.
Why
The solver (any solver — a coder, or a human) currently gets a raw job log and has to reverse-engineer what actually failed. The elixir-gate scan (misospace/llmkube-images #407) is the worst case: the real fix needed knowing the blocking finding was a Go binary at /usr/bin/pebble and that the npm findings lived in npm's bundled node_modules — both of which are in the scanner output but buried in raw log noise. A parsed, located findings list turns "here's 400 lines of log" into "here are the fixable HIGH findings and where they live," which is the difference between guessing and acting. This is the cheapest, always-positive slice of #988 and is independent of the lane/routing work.
Where
src/lib/ci-failure-ingestion.ts — the body is assembled in buildIssueDraft. Add a scan-findings parser (grype/trivy table → structured findings) gated on the failure being a scan/vuln class, and render it above the raw excerpt. Keep the raw excerpt (it still carries non-scan failures and context).
Acceptance
- A scan-gate failure issue body contains a findings table/list with package, installed, fixed-in, severity, and location when available.
- Non-scan failures are unchanged (still get the raw excerpt).
- The findings parse is covered by a unit test using a real grype table fixture.
- No change to
computeFailureSignature (dedup) or the recovery-close path.
Part of #988 (the always-safe, coder-actionable slice). Does not depend on the frontier-lane / build-scan-feedback work.
Ask
When ci-failure ingestion files a scan failure (grype/trivy
--fail-on highgate), parse the scanner's findings table out of the job log and render it as a structured list in the issue body, instead of embedding only the raw log. For each fixable finding include: package, installed version, fixed-in version, severity, and — when the scanner reports it — the file/binary path the finding sits on.Why
The solver (any solver — a coder, or a human) currently gets a raw job log and has to reverse-engineer what actually failed. The elixir-gate scan (misospace/llmkube-images #407) is the worst case: the real fix needed knowing the blocking finding was a Go binary at
/usr/bin/pebbleand that the npm findings lived in npm's bundlednode_modules— both of which are in the scanner output but buried in raw log noise. A parsed, located findings list turns "here's 400 lines of log" into "here are the fixable HIGH findings and where they live," which is the difference between guessing and acting. This is the cheapest, always-positive slice of #988 and is independent of the lane/routing work.Where
src/lib/ci-failure-ingestion.ts— the body is assembled inbuildIssueDraft. Add a scan-findings parser (grype/trivy table → structured findings) gated on the failure being a scan/vuln class, and render it above the raw excerpt. Keep the raw excerpt (it still carries non-scan failures and context).Acceptance
computeFailureSignature(dedup) or the recovery-close path.Part of #988 (the always-safe, coder-actionable slice). Does not depend on the frontier-lane / build-scan-feedback work.