Add exact RSpec file selection

[aspix2k]

Purpose

Run only affected RSpec files or stable example groups when their project-code dependencies are proven completely.

Acceptance criteria

• Define a stable native selection unit for explicitly supported RSpec versions.
• Record complete local production-file loads per unit and detect discovery or dependency drift.
• Apply native selectors only inside the owning gem.
• spec helper, shared examples, autoloading, dynamic require, resources, generated files and configuration changes run the full gem suite.
• Selected, skipped, failed and cancelled runs cannot replace a complete baseline.
• Public fixtures prove exact execution and fail-closed fallback.

Decision rule

No heuristic require graph may suppress specs; unsupported semantics remain gem-level.

[aspix2k]

Decision

Keep RSpec at gem-level bundle exec rspec <gem paths> selection.

Evidence

RSpec 3.13 has a stable native spec-file selector and a public formatter protocol, but it does not expose a complete causal spec-file-to-production-code relation:

• Runner#run calls setup, which loads every selected spec file, before run_specs starts the reporter and formatter lifecycle.
• A top-level require, helper or arbitrary Ruby statement in a later-loaded spec can mutate global state and affect examples from an earlier-loaded spec. Load origin therefore does not prove the affected spec-file set.
• CRuby TracePoint(:script_compiled) can observe require, load and eval, but it reports where code was compiled, not every example whose behavior that code changed.
• Sound attribution of any top-level or suite-level load must therefore attach it to every spec file. For normal RSpec suites this reduces exact selection to the full gem.
• One fresh process per spec file changes suite semantics: it repeats Bundler/RSpec boot and before(:suite) / after(:suite), removes inter-file state and still cannot prove the dependencies of the real full-suite process. Its cost is also O(spec-file count).

The counterexample is deterministic: a_spec.rb reads shared global state; later-loaded b_spec.rb requires patch.rb, whose top-level code mutates that state. A complete full baseline and isolated per-file runs can all pass. After changing only patch.rb, selecting b_spec.rb passes while the full suite fails in a_spec.rb. Any map that selects fewer than all files is therefore unsound for ordinary RSpec semantics.

The native file filter is not the missing primitive; complete dependency evidence is. Affected will continue to run the affected gem in the existing single IDE Run session. Revisit if RSpec exposes process-faithful per-file dependency isolation or causal execution attribution.