Reports and sharing
Reports overview
Understand the canonical audit, improvement, pentest, history, and summary surfaces.
What report surfaces exist
Guard keeps several report surfaces because they answer different questions. An audit report explains one health area at one repository revision. An improvement report explains what candidate was revalidated, what provider artifacts were created or reused, and what verification succeeded or failed. An Auto-pentest report names the exact tested website, confirmed findings, limitations, and provider outcome.
Project Activity is a cross-repository index of recorded audit, Autofix, and pentest runs. A repository executive summary synthesizes the latest completed published audits into a separate, shareable narrative.
Audit reports
An audit report should start with its main answer, then show target revision, scope, score and criteria, concrete findings, evidence, limitations, and prioritized next steps. The score is a compact signal; the criteria and evidence explain it. Audit history preserves earlier completed runs instead of rewriting them when the branch advances.
Improvement and pentest reports
Improvement reports separate current-state classification from provider outcome. Issue-only, issue plus review request, existing work, already resolved, needs-human-review, and verification-failed outcomes are all meaningful. A PR/MR link proves only that a proposal exists.
Auto-pentest reports add an active-target boundary. They must identify the exact linked website, distinguish the primary risk action from an optional safe fix, keep all confirmed findings visible, and state when access, authorization, or non-destructive testing constraints limited coverage.
Activity and history
Activity helps locate a run across the project. Audit bar height and color encode score; Autofix and pentest bars are fixed-height event markers. From a run you can open the available report and inspect its own revision and artifacts. Individual audit and Autofix history pages provide a narrower chronology for one repository action.
Repository summaries
A repository summary is generated from latest completed audit reports that are published and have run at least once. It records source runs, score availability, commit coverage, recommendations, and limitations. It can expose that the source audits span multiple commits or omit a score instead of pretending the inputs are one perfectly synchronized snapshot.
Reports are evidence, not authority
Reports do not merge changes, certify compliance, grant testing permission, or replace repository owners. A public link changes who can read selected result surfaces; it does not change Fleet execution history or provider state. Use Read run results before acting, and Share and revoke results before publishing.
Enji Guard