sc-report — Report Assembly (Pipeline Stage 6, Final)

Turns verified results into a report an auditor would sign. The editorial rule is the whole point: only PoC-backed confirmed findings appear as findings. Everything uncertain is demoted to a clearly labeled appendix. A report that claims only what it proved — and shows what it ruled out — is what earns trust and keeps the false-positive rate visibly near zero.

When to Use

• After sc-verify; the orchestrator (sc-audit) calls this last.
• User says: "write the report", "summarize the findings", "produce the audit doc".

Announce

Begin with: "I'm using the sc-report skill to assemble the final audit report..."

Workflow

1. Assemble (deterministic)

python skills/sc-report/scripts/assemble_report.py <audit_dir> --name "<Protocol>"

Reads verify/*.json verdicts, hypotheses/*.json, project-map.json, and the manifest; computes a final severity for each confirmed finding; and writes:

• .audit/report/report.json — structured report.
• .audit/report/report.md — a complete draft (executive summary, scope, findings, appendices A–D).

2. Severity = impact × likelihood

The script applies the matrix (see reference.md). impact comes from the target invariant's criticality / the hypothesis severity_hint; likelihood from the verification — a confirmed PoC is high-likelihood, so confirmed severity tracks impact. Sanity-check each: does the assigned severity match the real-world blast radius? Adjust in report.json and re-render if a finding is mis-weighted.

3. Polish the prose (LLM)

The draft's numbers and structure are correct; improve the writing:

• Executive summary: 3–6 sentences a protocol lead can act on — what was reviewed, what's confirmed and how bad, what needs their input. Lead with risk, not process.
• Each finding: make the description and exploit path read clearly for a developer; ensure the recommendation is specific to THIS code (not the generic template), referencing the exact function and fix.
• Open items: phrase as concrete questions for the team. Keep every PoC reference and the proof excerpt — they are the report's backbone.

4. Verify the proof links resolve

For each confirmed finding, confirm the prosecutor.artifact path exists (verify/poc/H-*.t.sol or verify/diff/H-*_candidate.py) and that the cited example numbers match the stored verify/H-*_diff.json / forge output. A finding whose proof a reader can't reproduce is not done.

5. Quality gate (see checklist.md) and deliver

Confirm: no unproven claim in the findings section; every confirmed finding has a working PoC link, a target invariant, a severity, and a specific recommendation; the dismissed appendix shows the refutations; the coverage table is present.

What goes where (editorial policy)

Why this matters for false positives

• Confirmed-only findings: the headline number is trustworthy because each entry survived a PoC. No "possible"/"might" in the findings.
• The dismissed appendix is a feature: showing what was investigated and refuted (with the proof) is the clearest evidence of a high-precision process — and it doubles as a reviewer's map of what not to re-check.
• Coverage table prevents false confidence: it states plainly which invariants were exercised and which were not.

Handoff

The report is the pipeline's deliverable. Report to the user: confirmed counts by severity, open items needing their input, and the invariant coverage. Point them to .audit/report/report.md.