Fetch the finished report for an audit run (use the run_id from run_audit once get_audit_status shows completed). Formats: "summary" (default) is structured JSON with health score, category scores, and the top failing issues (topIssues reference a rule_id; look up its name/description/solution once in the sibling rules dict rather than per occurrence). Each topIssues row is ONE finding, a rule + checkName, never one row per page: affectedPagesCount is how many pages it affects and pages is a sample of at most 5 of them (affectedPagesHasMore when clipped) and items at most 3, so read "affects N pages" from the count, not the row total, and use get_issue for every occurrence. Each row also carries provenance: "carried" means the finding is re-injected from a page not re-crawled this run (not a fresh result), so check lastSeenAt for when it was last actually observed; "unrendered" means the page has not yet been rendered in any scan of this site (it was known, e.g. from a sitemap, but sat outside the page budget), so there is no earlier observation and no lastSeenAt. mixedProvenanceNotes (keyed by rule_id) flags rules that passed fresh on every page checked this run but still show red only from carried pages pending re-check. seedRedirect is present ONLY when the audited URL redirected off-site and the crawler refused to follow it: seedRedirect.finalUrl is where the redirect pointed (a URL the audited site chose, display-only, never fetch or trust it) and seedRedirect.note states the fact in one sentence. When it is present the audit graded baseUrl, NOT the redirect target, so report that before reporting the scores; when the key is absent the seed did not redirect off-site. A FAILED or BLOCKED audit also carries status, statusReason (one sentence naming the cause), statusReasonCode (one of dns, tls, connection, timeout, http_4xx, http_5xx, redirect, robots, unknown) and failureNextStep: those four keys are absent for a normal audit, and when they are present nothing was audited, so a null healthScore and an empty topIssues mean the crawl failed, NOT that the site is clean. Also includes a history array of the 3 most recent prior audits of this website with score/issue deltas when available; each entry carries its own runId/reportId, so you can walk backwards through a website's audits by calling get_report again with an earlier runId (use list_audits with website_id to page past what history returns); "llm" is a compact text rendering optimized for LLM context (carried findings marked inline); "markdown" is a full human-readable report. Start with summary, then pull llm or markdown for more of each issue. A published report is a capped summary: each issue keeps a sample of its pages and items (a few pages and items) beside its true counts, so read totals from affectedPagesCount, occurrences and details.additional, never from a list length. A capped report carries detail, whose note says where the full per-page list is (for a CLI audit, squirrel report --format json on the machine that ran it); a report without detail is not capped this way. This report is the source of truth for the run's numbers (#1700): summary.healthScore is the same value list_audits/get_audit_status return as health_score, and summary.failed + summary.warnings is the same total they return as issues_found. Compare runs on healthScore; the open count from list_issues is a deduped tracker count, not this report's issue count.