#[non_exhaustive]pub struct Report {
pub corpus: Option<&'static str>,
pub files: u64,
pub lines: u64,
pub parse_errors: u64,
pub records: BTreeMap<String, (Coverage, Tally)>,
pub blocks: BTreeMap<(String, Coverage), u64>,
pub tools: BTreeMap<String, u64>,
pub notes: BTreeMap<String, u64>,
}Expand description
The full audit result.
Fields (Non-exhaustive)§
This struct is marked as non-exhaustive
Struct { .. } syntax; cannot be matched against without a wildcard ..; and struct update syntax will not work.corpus: Option<&'static str>Which corpus this is.
files: u64Files scanned.
lines: u64Lines parsed.
parse_errors: u64Lines that failed to deserialize even into the typed schema.
records: BTreeMap<String, (Coverage, Tally)>Per record/payload discriminant: (coverage, tally). Keyed by a readable
path like response_item/custom_tool_call.
blocks: BTreeMap<(String, Coverage), u64>Content block discriminants seen, with counts SPLIT by the coverage
each instance actually got (N1, Fable-5 review). Keyed by
(tag, coverage) rather than tag alone: D5 made image coverage
PER-INSTANCE (a base64/url source is Normalized, a Files-API/
file source is Dropped), so a single tag -> (Coverage, count)
entry — last-write-wins on Coverage — silently collapsed a mixed
corpus’s genuinely-Dropped instances into whatever coverage the
LAST-seen instance of that tag happened to have, over- or
under-claiming fidelity depending on file order. Splitting the bucket
keeps every instance’s actual coverage and never collapses counts.
tools: BTreeMap<String, u64>Tool names seen, with counts.
notes: BTreeMap<String, u64>Structural notes discovered while scanning (e.g. sidechain lines).