Review

Traced the full path in reporter.rs / util.rs — solid, well-targeted fix. The diagnosis in the description is accurate: collect_summary explicitly return HashMap::new() when find_root(...).to_file_path() is None, and otherwise always inserts the "" entry, so summary.get("") is the exact and only failure mode. The fix targets the right line.

Correctness

• Change 1 (let Some(root_stats) = summary.get("") else { return }) — correct and complete. This is the real fix and handles the only path that produces a missing "" entry. ✓
• Change 2 (.max().unwrap() → .unwrap_or(0)) — harmless but effectively dead code. entries filters summary to file_text.is_some(); the "" root entry has file_text: None (excluded), while every leaf node inserted per report carries file_text: Some(..). We only reach this line when the map is non-empty, which requires find_root to have succeeded, which requires non-empty file_reports — so there's always ≥1 leaf entry and .max() never returns None. Reasonable defense-in-depth (and node_max = 0 then gets .max("All files".len()) so the table still renders), but it's unreachable given Change 1. Worth a one-line comment saying so, otherwise it reads as "what case is this protecting against?"
• The unwrap()s left in collect_summary (report.url.to_file_path().unwrap(), strip_prefix(&root).unwrap()) are still fine — they only run after find_root produced a usable file-path root. Correctly untouched.

Test coverage

• The regression test is hermetic and clever: a https://example.com/main.ts URL makes to_file_path() fail, driving collect_summary to the empty-map branch without a real multi-drive Windows setup. Traced it: find_root → Some("https://example.com/") → .to_file_path().ok() → None → empty map → get("") is None → early return. Genuinely reproduces the panic on main and passes with the fix. ✓
• Gap: because the test hits the early return, it exercises only Change 1. Change 2's .unwrap_or(0) is never reached (and per above likely can't be). Acceptable, just noting.

Suggestions (all minor, non-blocking)

• UX: silently printing nothing means a user who ran deno coverage and expected a summary gets no output and no explanation. Consider a log::warn! like "Skipping coverage summary: reports span multiple file-system roots" (on stderr, so parsed stdout stays clean) so the missing table isn't mysterious.
• Comment on Change 2 noting it's defensive/unreachable given the get("") guard, so future readers don't puzzle over which input triggers it.
• Optional deeper fix (out of scope): the root cause is find_root's character-wise prefix in util.rs, which is fragile — it can slice a URL mid-path-segment, not just at drive boundaries. A path-segment-aware common root (or per-drive grouping) would make the summary work across drives rather than be skipped. Reasonable to defer, but worth a tracking note.

Verdict

LGTM. Small, correctly-targeted, well-explained panic fix with a genuine regression test. Only asks are a clarifying comment on the (unreachable) second guard and ideally a user-facing message instead of silent no-output — neither blocking.

Pushed 3644e5d addressing the two review nits:

• Added a log::warn! ("Skipping coverage summary: reports span multiple file-system roots") so the missing summary table isn't silent and unexplained.
• Documented that the adjacent .unwrap_or(0) is defense-in-depth — entries is always non-empty once the "" root entry is present.

cargo test -p deno --lib summary_reporter_does_not_panic passes, clippy and rustfmt clean. Should be ready to land.