testing-changes

# Testing a change Run what the change affects. CI runs the full suite on three platforms for every pull request, so the local job is fast feedback, not a second gate. The per-commit checks are in [`pnpm/CONTRIBUTING.md`](../../../pnpm/CONTRIBUTING.md#automated-checks). ## Rust (`pnpm/`, `pnpr/`) Run `cargo` and `just` from the repository root; the Rust workspace lives there, not inside `pnpm/`. Run `just test-affected`. It decides three things for you: it selects every `pnpr-*` crate together, it refuses to scope a change that reaches files every crate compiles against and points at `just ready` instead, and it runs the smoke profile in place of dependents it did not select. It prints what it selected and what it left out; `--help` lists its flags. What it cannot decide is which end-to-end tests exercise *your* change. Smoke gives breadth across areas, not depth in the one you touched, so for a user-visible change add the suite modules for that area: ```sh just test-affected -- -p pnpm-cli -E 'test(catalog::)' ``` Each file under `crates/cli/tests/suite/` is a module of one test target, so `test(<file_stem>::)` selects that file's tests. For anything narrower, `node pnpm/scripts/run-rust-tests.mjs` takes the same arguments `cargo nextest run` does — `-p <crate>` for one crate, `-E 'test(<name>)'` for one test. Prefer `-p` over a `package()` filterset: `-p` restricts what cargo builds, a filterset only selects among binaries that were built anyway. ### Gotchas that m...