Module ecosystem_detect 

CLEANLIB-691 — canonical manifest-filename → ecosystem detection.

Single source of truth so every surface infers the ecosystem identically: the CLI (cleanlib scan --packages <file> without --ecosystem), the LSP, the MCP tools, and the SDK convenience wrappers. Lives in cleanlib-client (not the CLI) for the same reason the customer-state taxonomy does — it is a cross-surface contract, not a CLI-local helper.

Detection is on the file NAME (basename). It is deliberately conservative: it recognises the canonical manifest/lockfile names and returns None for anything ambiguous or unrecognised, so the caller can prompt for an explicit --ecosystem rather than guess wrong on a security product.

Functions

ecosystem_from_path

The wire ecosystem string for a manifest/lockfile path, or None when the filename is not a recognised manifest (the caller then asks the user to pass --ecosystem explicitly). Matches the App’s actual canonical set (cleanlib-app::http::SUPPORTED_ECOSYSTEMS): npm / pypi / go / maven / crates / nuget / rubygems / composer. CLEANLIB-864: this used to also claim “packagist” (composer.json/.lock) and “pub” (pubspec.yaml/.lock) — neither is in that set, so every detection into either name failed at the App with 400 unknown_ecosystem on every attempt. composer.json/.lock now map to the real name; pubspec.yaml/.lock are dropped (no pub backend exists at all, so returning None and letting the caller be told to pass an explicit --ecosystem is the honest answer, not a wrong one).