phi started as an npm-only behavioral scanner. It's becoming a supply-chain firewall that doesn't care which registry produced the bytes. This page is the overview; per-version release notes live in CHANGELOG.md.
shipped released, on GitHub Releases, runnable today
in progress actively being worked on
next up committed direction, queued behind the in-progress item
horizon direction we're going, not committed to dates
out of scope explicit boundary — phi will not become this
Mid-install interruption can no longer corrupt your package.json. Bad packages can no longer crash a scan run. Friendlier first-run experience on Windows.
phi audit fix [--apply | --force] — proposes safe fixes for typosquats, vulnerable versions, and deprecated packages. Preview by default; you opt in to applying. Scan progress now renders consistently across every shell we ship to.
Two new behavioral detectors targeting recent threat patterns (credential exfiltration flow + Linux system tampering), plus deprecation guidance for packages with safer successors.
phi self-update brings phi current with one command. Verifies the new binary against published checksums before swapping.
phi create bootstraps React, Next, Express, Fastify, or Nest projects — with the scaffolder itself audited first. --force escape hatch for packages you know you trust despite a flagged verdict.
The install-time interception pipeline: 13 detectors, OSV vulnerability layer, lifecycle scripts off by default, lockfile + audit report, cross-platform binaries.
Cleans up the install experience on first run. Same binary, signed.
Same install-time interception pipeline, applied to go.mod instead of package.json. Existing Go tooling flags vulnerabilities once a CVE has been filed; phi will catch the patterns themselves.
Directional, not committed to dates. Order is rough priority.
Live scan as you edit your manifest.
First-class GitHub Action, GitLab CI templates, drop-in for the major platforms.
Railway, Render, Vercel, Fly.io, and similar build pipelines recognizing phi.lock as a first-class lockfile — so deploys use phi's verified install path the same way they use package-lock.json today. (Partnership conversation, not a phi-side feature.)
Opt-in per package; results feed the same risk score.
Strict trust model — signed plugins only.
phi will not become these things. Listing them here so the boundary is explicit.
phi is install-time only. Once code is in node_modules/ and your app runs it, that's the application's concern — use container limits, gVisor, or an EDR for that.
phi.lock is a complete, integrity-verified lockfile — phi can be your only package manager, in CI, in Docker, in production. But if you'd rather keep package-lock.json / yarn.lock / pnpm-lock.yaml alongside for tooling that expects them, phi leaves them alone. Drop-in, not rip-out.
No daemon. No phone-home. Ever. Decisions happen on your machine, with your data, full stop.
phi stays free and open-source. Commercial offerings would be separate products built on top — never behind a paywall on the install path itself.