Deps Vet, Hex package audit ledger

Review a Hex package version, run Phase 1 supply-chain rules against it, prompt the user for a verdict, append the result to hex_vet.exs (project-root audit ledger). Vetted versions get downgraded to INFO on subsequent /phx:deps-audit runs.

Run this AFTER /phx:deps-audit to clear findings. Run this BEFORE merging a mix.lock PR to certify new versions.

Usage

/phx:deps-vet phoenix 1.7.21      # vet a single package version
/phx:deps-vet --seed              # import curated baseline seed (~30 pkgs)
/phx:deps-vet --list              # show existing ledger entries
/phx:deps-vet --check             # cross-check mix.lock vs ledger

Iron Laws

1. NEVER auto-approve. Every entry MUST come from an AskUserQuestion confirmation. Drive-by trust ruins the ledger's value.
2. Lock wins on disagreement. If mix.lock has version X and the ledger vets X-1, emit INFO and treat X as unvetted. Don't silently trust the older entry.
3. Ledger lives at project root. hex_vet.exs is a first-class security artifact, visible in PR review. Don't move it into .claude/.
4. Round-trip via inspect/2. When appending, read the file with Code.eval_file/1, mutate the map, and write back via inspect(term, pretty: true, limit: :infinity). Hand-rolled string appends drift over time.
5. Always show findings before prompting. The user must see what's being vetted. No silent :safe_to_deploy defaults.
6. Confirmation counts are COMPUTED, never estimated. Any number in an AskUserQuestion (criteria split, new/overwrite/no-op) MUST be derived from the loaded data before prompting, e.g. Enum.frequencies_by(seed.audits, & &1.criteria). Eyeballing the file and approving on wrong numbers corrupts the consent.

Execution flow

Step 1: Locate or seed hex_vet.exs