v0.10.1 — a shared cache no longer vouches for changes its key never saw

A shared cache could replay a test that a change had broken

A test file is served from a remote object when an object exists under its content key k. That key is built from the fingerprint, the test file's hash and the hashes of the files the test executed.

Some tests are selected for other reasons: a watch pattern (including the residue fallback), or the Laravel Migration, Blade or Sibling rules. For those, the thing that triggered the selection is none of the inputs above. A watched data file the test reads is not a file it executed, so changing it left k as it was. The object still matched, and the run printed

✓ 0 executed (0 affected, 0 uncached) · 36 replayed (5 from remote)

on a suite that plain PHPUnit fails. Without a remote, the same change executes and fails correctly. The bug only affected teams sharing a cache.

What changed

• A test file is served from the remote only when every reason it was selected is one that k covers: PhpEdge or TestFile. The allowed reasons are an explicit list, so a rule added in future makes the test execute until someone decides k covers it. The check applies both to the CLI pipeline and to the in-process path.
• --explain and --dry-run used to list only what remained after the remote had served its share, so the rule looked as if it had never fired. They now show the whole selection with each file's reason, and mark the files a remote object stands in for with [served from remote].

Content keys, fingerprints and the remote layout are unchanged. No cache is invalidated, and objects already published keep serving the selections they always could.