pixi Rich Platform Specifiers

pixi is a Rust package manager from prefix.dev on the conda ecosystem. A workspace lists target platforms as conda subdirs (such as linux-64) and describes machines separately as system requirements telling the solver which virtual packages to assume. That model cannot express the most common GPU setup: the same subdir locked twice, once with CUDA and once without. The agent adds rich platforms, matching the upstream change. Each platform now carries its own virtual packages, which reaches manifest parsing, environment resolution, the lock file's platform records, host selection at install time and a new command. Bare-platform workspaces and existing lock files behave as before.

Each platform entry may now be an inline table with a subdir, an optional name, and virtual-package keys layered over the subdir's defaults. Features select platforms by name, each environment is solved and locked once per platform, and the lock file stays fresh across renames but not across a changed subdir or virtual package. Old system requirements keep working but cannot mix with rich entries, and install picks the first platform the host can run. A new pixi workspace platform command (add, edit, list, remove) manages entries and keeps the lock in sync. Existing commands accept platform names, synthesized names are pinned, and existing tests must still pass.

The offline sandbox (4 CPUs, 8 GB, 8 hours) holds a full-history pixi checkout, Rust 1.94.0 with every crate cached offline, a prebuilt debug binary with compiled unit tests, and Python 3.12 with integration-test dependencies. Example workspaces demonstrate the feature. Generated workspaces and reference build are held out.

The committed HEAD is built in a separate environment; existing integration tests and test data may not be edited. Unit tests and offline Python integration tests passing on both starter and upstream builds must still pass. The binary runs on workspaces over a local channel whose packages depend on virtual packages, so locked versions reveal what each solve assumed. Cases include upstream feature tests plus five generated families: duplicate-subdir solving, system-requirements compatibility, lock staleness, CLI sequences and host selection, each compared against the upstream build. Every family must reach 90%.