Ecosystem coverage and rollout

Package Ninja should be described in layers, not as a single yes-or-no support claim.

Different ecosystems can be:

• first-class in the top-level install/setup workflow
• first-class in the top-level restore/add workflow
• supported by the runtime policy and proxy layer
• supported by hosted registry search and package-risk intelligence
• planned, but not yet production-ready

That distinction matters because a security tool should not overclaim what it governs.

Current support tiers

Ecosystem family	Top-level governed workflow verbs	Runtime policy + proxy adapter	Hosted search / risk intelligence	Current posture
npm / pnpm / yarn / bun	restore, add, dev, test, publish, fix	Yes	Yes	Production-facing primary workflow
PyPI family (pip, pip3, uv, poetry, pipenv)	restore, tooling-aware add/remove, test, fix	Yes	Yes	Production restore/test path; top-level add/remove is enabled for uv, Poetry, and Pipenv projects and intentionally rejected for requirements-only/editable roots; governed fix supports direct safe-version upgrades in uv, Poetry, and Pipenv projects
Cargo	restore, add, dev, test, fix	Yes	Yes	Production restore/add/test path plus a safe default dev flow when a runnable binary target exists; governed fix supports direct safe-version upgrades
Go modules	restore, add, dev, test, fix	Yes	Partial	Production restore/add/test path plus a safe root-level dev flow when the project exposes package main; hosted search parity is still incomplete and governed fix supports direct safe-version upgrades
NuGet / dotnet	restore, add, dev, test, fix	Yes	Yes	Production restore/add/test path plus a safe default dev flow when the workspace resolves to a single runnable project; governed fix supports direct safe-version upgrades
Maven / Gradle	restore, test, fix	Yes	Yes	Production restore/test path; governed fix can auto-apply direct safe-version upgrades when pom.xml or literal Gradle dependency declarations can be rewritten safely, while add remains manifest-backed
Composer	restore, add, test, fix	Yes	Yes	Production restore/add/test path when a default test entrypoint exists; governed fix supports direct safe-version upgrades

What Package Ninja can honestly say today

The strongest truthful framing today is:

• Package Ninja already has a multi-ecosystem policy and runtime foundation.
• package-ninja restore, supported package-ninja add/remove, and package-ninja test now give the current production adapter set shared governed entry points where a safe default exists.
• package-ninja plan --json previews those same workflow decisions before execution.
• package-ninja install remains a compatibility alias so existing workflows do not break while the contract shifts to explicit restore/add semantics.
• package-ninja fix now supports direct safe-version remediation for npm-family, PyPI (uv, Poetry, and Pipenv projects), Cargo, Go modules, NuGet, Composer, and narrow Maven/Gradle manifest patterns when the incident carries a verified upgrade target.
• package-ninja dev now has safe default routing for npm-family workspaces, Cargo binary targets, Go package main roots, and single runnable .NET projects.
• PyPI artifact downloads for the main proxied archive formats now stay on the governed runtime path and receive artifact inspection before delivery.
• Cargo sparse-index download configuration and proxied crate downloads now stay on the governed runtime path and receive artifact inspection before delivery.
• Go module zip downloads now stay on the governed runtime path and receive artifact inspection before delivery.
• NuGet service-index responses and proxied .nupkg downloads now stay on the governed runtime path and receive artifact inspection before delivery.
• Proxied JVM archive downloads now stay on the governed runtime path and receive artifact inspection before delivery.
• JVM/native-heavy archive inspection now also surfaces embedded native binary signals, triages suspicious native payload strings, and blocks suspicious process-execution patterns in inspectable source and compiled package contents.
• Composer repository metadata and proxied dist archives now stay on the governed runtime path and receive artifact inspection before delivery.
• package-ninja run -- <native command> and project shims provide the shared governed path for native package-manager commands.
• JavaScript still has the richest convenience verbs overall, especially for publish, so non-JavaScript ecosystems should not be marketed as having complete workflow-verb parity yet.

What must be true before a new ecosystem is called supported

Every new ecosystem should pass the same production-grade checklist:

1. Project detection works reliably.
2. Manifest parsing is stable and version-stripping is correct.
3. Action inference happens before package-manager side effects.
4. Local proxy or config injection does not mutate the developer machine globally.
5. Audit events normalize ecosystem, package names, verdicts, and remediation data.
6. Risk intelligence maps the ecosystem into the same advisory and threat model.
7. Policy UI can target the ecosystem explicitly.
8. Public docs describe the ecosystem truthfully.
9. Abuse, bypass, and offline behavior are tested.
10. Marketing copy only claims the support tier that actually exists.

The current release path now also runs an ecosystem smoke suite plus runtime enforcement tests, so supported project fixtures and governed artifact-path behavior are both exercised before release.

Recommended rollout order

The cleanest path is to finish what already exists in the runtime before expanding into many more families.

Phase 1: Complete current partial families

These already have strong architectural footing and should be brought to parity first:

• PyPI
• Cargo
• Go modules
• NuGet
• Maven / Gradle
• Composer

The main work is not inventing new policy logic. It is productizing what already exists across CLI, docs, policy UI, audit visibility, and hosted search/risk surfaces.

The current restore/test milestone is complete for these families, and add is now explicit where the ecosystem has a safe governed default. The next parity pass should focus on deeper remediation and publish semantics beyond the universal run -- <native command> model, especially for broader Python manifest variants and JVM projects that still rely on inherited or property-backed dependency versions.

Phase 2: Add high-value new families

After current partial families reach parity, the next best candidates are:

• RubyGems / Bundler
• Swift Package Manager
• Conda
• Paket
• Deno import governance

These ecosystems are valuable enough to justify first-class work, but they need proper protocol and workflow analysis before shipping.

Phase 3: Expand into specialized or lower-priority ecosystems

These should be added only after the higher-value families have the same production-grade rollout quality:

• Conan / vcpkg
• CocoaPods / Carthage
• Hex / Rebar3
• CPAN
• LuaRocks
• Cabal / Stack
• OPAM
• CRAN / Bioconductor
• Pub
• Julia Pkg
• Nimble
• Zig
• Fortran FPM

Legacy and deprioritized surfaces

Some names matter mostly for migration or customer discovery, not for early first-class rollout:

• Bower
• PEAR
• Glide / Dep / Govendor
• Hunter / CPM.cmake
• JSPM

Why the rollout should stay disciplined

Security tooling loses credibility when support means "we can parse a file" in one place and "we can fully govern the workflow" in another.

The right standard is:

• one clear support matrix
• one acceptance checklist
• one truthful marketing layer
• one production-grade rollout pattern for every ecosystem