# Task 06: representative package cohorts

## Purpose

Measure generality without allowing one package to define the architecture.

## Selection method

Choose small packages first, pin exact versions and hashes, and record why each
adds a new capability. Select at least one from each applicable cohort:

1. pure wheel control case;
2. setuptools C extension without external target libraries;
3. generated C/Cython extension;
4. Rust/PyO3 extension;
5. extension using a separately built native target library;
6. package requiring a visible cross-compilation patch;
7. pyproject/PEP 517 backend not already covered;
8. scientific-stack stress case, eventually including NumPy.

Do not count existing probes as real-package cohort evidence, but retain them as
reduced regression tests.

## Compatibility report

For every attempted package, record exactly one status:

- `supported-generic`;
- `supported-recipe`;
- `blocked-platform-capability`;
- `blocked-toolchain`;
- `not-yet-attempted`.

Record build command, source hash, wheel hash, ABI ID, test behavior, peak size
or memory when material, and the earliest unsupported assumption on failure.

## Exit gate

At least five independent real packages across four native/build shapes pass
runtime behavior tests, and failures produce reusable classifications instead
of package-specific branches.