Use Rules that explain the risk, evidence, and fix. as a decision directory.
Review security, dependency, and code-health rules with concrete examples, detection boundaries, remediation guidance, and reproducible local commands. Open the page that matches the concrete decision in front of you, verify its evidence and limits, then continue to the relevant implementation or proof page.
- Scope: Review security, dependency, and code-health rules with concrete examples, detection boundaries, remediation guidance, and reproducible local commands.
- Evidence: Inspect the unsafe pattern, safer alternative, rule identifier, severity, confidence, detection scope, common false positives, and reproducible scan command.
- Boundary: A rule detects a defined code pattern, not every possible exploit path; reviewers still need context, configuration, and tests for the affected system.
Choose a page by the evidence you need.
For Rules that explain the risk, evidence, and fix., do not choose from a name alone. Match the page to the repository, reviewer, output, and enforcement point that will determine whether the workflow is useful.
Decision pointWhat to inspect
ScopeReview security, dependency, and code-health rules with concrete examples, detection boundaries, remediation guidance, and reproducible local commands.
EvidenceInspect the unsafe pattern, safer alternative, rule identifier, severity, confidence, detection scope, common false positives, and reproducible scan command.
BoundaryA rule detects a defined code pattern, not every possible exploit path; reviewers still need context, configuration, and tests for the affected system.
Questions about Rules that explain the risk, evidence, and fix.
For Rules that explain the risk, evidence, and fix., these answers define what the directory covers, how to validate a page, and where human judgment remains necessary.
What does the Rules that explain the risk, evidence, and fix. directory cover?
It covers Review security, dependency, and code-health rules with concrete examples, detection boundaries, remediation guidance, and reproducible local commands. Each child page owns a narrower task or evaluation so readers can avoid mixing unrelated decisions.
What should I verify before acting on a Rules that explain the risk, evidence, and fix. page?
Verify the concrete evidence first: Inspect the unsafe pattern, safer alternative, rule identifier, severity, confidence, detection scope, common false positives, and reproducible scan command.
What should I not infer from the Rules that explain the risk, evidence, and fix. directory?
Do not infer more than the stated boundary: A rule detects a defined code pattern, not every possible exploit path; reviewers still need context, configuration, and tests for the affected system.
Continue with implementation evidence.
For Rules that explain the risk, evidence, and fix., use these routes to inspect a real artifact, confirm the product boundary, or implement the workflow described in this directory.