Function security_list 

pub fn security_list(
    layers: Vec<FindingsLayer>,
    limit: usize,
) -> ToolSecurityList

Build the tool-surface security list document from a project’s live layers.

limit bounds the findings per layer, not across the document. That is the deliberate choice: a document-wide bound spends its whole budget on the first layer in key order and hands back semgrep: 0 findings for a layer it never reached — which reads as “semgrep found nothing” and is the exact defect this module exists to prevent, one level down. The worst case is therefore limit × live layers, and a live layer is one per analyzer per checkout, so it is small and knowable rather than unbounded.

Why the page is ordered by severity and the store’s listing is not

rto_graph::Store::findings_layers returns findings ordered by key, which is right for a full listing and wrong for a truncated one: it would drop findings by alphabetical luck, and a critical whose advisory id sorts late would vanish behind an informational one. The page is therefore sorted by severity, descending, with the store’s key order preserved within each level (the sort is stable). One caveat, stated because it decides what gets dropped first: Severity::Other — a level no shipped adapter emits, kept verbatim for a future analyzer’s vocabulary — orders after info, so an unrecognised severity is truncated first. truncated and omitted are what keep that visible instead of silent.