Use evidence-backed actions, explained priorities and later-scan verification context.
Read recommended next actions
Open Recommended actions on a scan. Expand an action for its findings, source location or dependency, priority reasons, engine guidance and verification steps. Follow its finding links to inspect the evidence before changing anything.
Each group containing an actionable finding receives an action: shared remediation for a confirmed group or investigation for a potential group. Each remaining BLOCK or WARN finding receives its own action; legacy findings without a stored decision are actionable at MEDIUM severity or higher. INFO-only groups receive no action. Each recorded coverage gap receives a restore-coverage action. The original engine fix text is shown with its scan date.
Why an action appears first
Priority tiers P1–P4 and rank use stored finding decisions, release verdict, severity, proven path, reachability, confidence, regression and coverage gaps. Explanations also surface corroboration and relaxed-policy overrides. Related-finding count breaks ties; it is not a business-impact estimate. An open action over a stored BLOCK leads other open actions. Closed actions follow open ones while retaining their tier.
Example: a blocking dependency group leads a non-blocking investigation. Review every advisory and choose a change your team can validate. Potential function-level relationships invite investigation, not a blanket fix. Fendix neither estimates effort nor automatically edits code or opens customer PRs.
Follow implementation with evidence
Linked Issues supply existing triage context. Assignment or a Jira ticket can indicate in progress. Manually marking an issue fixed means reported fixed, not verified. An unexpired risk acceptance or a false-positive disposition is not a technical fix.
Verification considers the newest later completed scan of the target. A stable or moved match means still detected. A possible match or inadequate evidence means inconclusive. A conclusive absence means no longer detected. Verified requires engine re-test verification for every active member’s linked issue; a closed ticket alone is insufficient. Existing engine verification can establish this state even without a later completed scan, but later contradictory evidence overrides it.
A newer running or failed scan is shown as context but supplies no completed verification. Re-scan with comparable settings and required analyzers. If coverage is incomplete, restore it before drawing absence conclusions. Read the existing CLI verification workflow for targeted re-tests.