The coverage item from the punch list, done data-first: bun test --coverage (exposed as a test:coverage script) reports 88.2% mean line coverage across 140 source files — considerably healthier than the audit's "no coverage measurement exists" note implied — and pointed at exactly three files with 0% function coverage: modules the suite never once invoked.
| File | Why it matters | Now pinned |
|---|---|---|
src/utils/pantry-parser.ts | wired into the package scanner — a regression means pantry.lock silently vanishes from the dashboard | extraction, entries missing name/version, no-packages lock, malformed JSON → null |
src/security/loader.ts | the front door of every buddy security audit (audit() starts with it); the six rules are tested against hand-built fixtures, so a discovery bug would fail every real audit while every test stayed green | yml+yaml discovered, everything else ignored, subdirectories not traversed (GitHub loads only top-level files), workflow-less repo → [] |
src/analysis/analyzers/github-actions.ts | the wrapper review actually calls around the tested rules | error→major severity mapping, whole-repo audit filtered to changed files only, files: [] short-circuits without auditing |
bun test: 2249 pass / 0 fail (+12); typecheck and pickier green.
Remaining from the deep list after this: the worst partially-covered files (registry-client, github-provider, buddy.ts at 32–56% lines) are big-integration territory, and the dogfood-published-package blind spot is a security-vs-coverage design call worth discussing before touching.
🤖 Generated with Claude Code