rigortype 0.4.2 → 0.4.3

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: a812e377e347e70448e42c33e6f4fe79152d40851b999609e9e5fdd98dc5a5a0
-  data.tar.gz: 285b195c8058fa30063c5ad40ac6718cd59a3f1d79bb79ccac32184093dba5b0
+  metadata.gz: b20cef50f4d076f1afefb8c20563cd21a95a56b01bf4db3257371adfe7c64d5d
+  data.tar.gz: 9c4f5f8825106ece96fb2ac00dc1ad4ef43f302368f1a12f87521c725530b924
 SHA512:
-  metadata.gz: 148890acd58affcbc6eb81afe948d882cf254930ff7ad83635592a065bf038de149865891767318721bdc103e7def6e4c71686b8d40a8ff9b55034c446cf8d32
-  data.tar.gz: e6d458ec387e004c83b8751e5381eda53ec5979433580263ea1586cbb574245875f50a94fce86540badae485d08d20ff73c7e3aea4d80d33c4226af3a4b7f584
+  metadata.gz: 4418a4a75a22d27038d0607caa5a79723470e68f9662da1aec0b79e8056a1b157f78cf85f83cb51f646aa22d2634b0d851bb9f0132a548f5104acdee2372d1d2
+  data.tar.gz: 026710fb13eebddf98776d6a9a3fb8e1738a7cc5fdd77c326afa0adb680c0760462d9e41b4aff57d1c41d1878fc05c41a8658be7b69ed4f265709aa27f6fc825

data/README.md

@@ -232,7 +232,7 @@ rigor docs --list                 # list every bundled page
 
 ## Status
 
-Current release: **`v0.4.2`** (2026-10-11) — on the
+Current release: **`v0.4.3`** (2026-10-15) — on the
 `0.4.x` line, continuing the evaluation era opened by `v0.2.0`, the first
 publicly-announced (general / evaluation) release. The line publishes
 an enumerated [compatibility surface](docs/compatibility.md) as a

data/docs/handbook/11-sig-gen.md

@@ -188,11 +188,11 @@ changes which calls the signature accepts:
 $ rigor sig-gen --diff lib/c.rb
 --- lib/c.rb: C#m
 - def m: (Integer x) -> untyped
-+ def m: (Integer x) -> nil
++ def m: (Integer x) -> Float
 
 --- lib/c.rb: C#n
 - def n: (?) -> untyped
-+ def n: (?) -> nil
++ def n: (?) -> Float
 ```
 
 The `-` line is the declaration the proposal replaces. A method
@@ -523,9 +523,16 @@ Neither does a declaration the body proves as a literal.
 -> String` whose body is the string `"bot"`: the declared
 type is your abstraction over that body, and pinning the
 literal would rewrite a contract every sibling class shares.
-A method no `.rbs` declares is unaffected — the literal is
-still the strictest thing the body proves, and that is what
-gets written.
+A declared `untyped` that you wrote in `sig/` is treated
+the same way for a value literal: an Integer, String or
+Symbol the body proves is widened to its class (`-> 1`
+becomes `-> Integer`, `-> ("S" | nil)` becomes
+`-> (String | nil)`), while `nil`, `true`, `false` and a
+computed `Float` are proposed as they are. An `untyped` that
+only the inline reader synthesizes for a `def` you did not
+annotate keeps the literal, as does a method no `.rbs`
+declares — the literal is still the strictest thing the body
+proves, and that is what gets written.
 
 A comment rather than a `%a{…}` annotation, for three
 reasons: it stays out of the `rigor:v1:` directive namespace

data/docs/manual/02-cli-reference.md

@@ -36,7 +36,7 @@ the `paths:` list from the configuration file.
 | `--explain` | Surface fail-soft fallback events as `info` diagnostics. |
 | `--no-cache` | Skip the persistent cache for this run. With `--incremental` it is a cold full analysis: the incremental snapshot and the run-result cache are neither read nor written, so the next plain `--incremental` run still uses the snapshot it had before. |
 | `--incremental` | Re-analyse only the files changed since the last run plus the files that depend on them, serving the rest from a cross-process disk snapshot (ADR-46). Diagnostics are identical to a full run; a config / gem / version change (or a file added or removed) transparently forces a full re-analysis. A run with nothing changed is answered from the cache without starting the analyzer. See [Caching](12-caching.md). |
-| `--verify-incremental` | Acceptance gate: run the incremental analyzer against a full `--no-cache` run and assert the diagnostics are byte-identical, then exit (0 on match, 1 with the differing diagnostics on mismatch). Used in CI to guarantee `--incremental` never serves a stale result. |
+| `--verify-incremental` | Acceptance gate: run the incremental analyzer against a full `--no-cache` run and assert the diagnostics agree as a set and in the same order, then exit (0 on match, 1 on mismatch: the differing diagnostics for a set mismatch, or the first index where the order diverges for a same-set, different-order mismatch). Used in CI to guarantee `--incremental` never serves a stale result. |
 | `--clear-cache` | Delete the cache directory before running. |
 | `--cache-stats` | Print the on-disk cache inventory when finished — on stdout under `--format text`, on stderr under every other format, so machine-readable output stays a parseable document. `--clear-cache`'s and `--verify-incremental`'s notes follow the same rule. |
 | `--[no-]stats` | Print a run summary (files, classes, memory, wall time) to stderr. Default on. |
@@ -171,6 +171,24 @@ the two builds against each other — but if you are chasing a
 disagreement between a probe and a `check` run, comparing
 against `rigor check --no-cache` removes that variable.
 
+## `rigor lens`
+
+Map the declarations of one or more files with their types and
+type provenance (experimental). See
+[Inspecting inferred types](05-inspecting-types.md).
+
+```sh
+rigor lens [--format=text|json] [--config=PATH] [--workers=N] FILE...
+```
+
+A lens runs the same incremental analysis as
+`rigor check --incremental` and reads and writes its cache.
+`--workers` applies to a cold run. `--format=json` writes one
+`lens/v0` document ([specification](../internal-spec/lens.md)).
+Exit `0` when at least one file has a result, `1` when none
+does, `64` on a usage error; diagnostics in the code never
+change the exit status.
+
 ## `rigor trace`
 
 Replay HOW the engine typed a file, step by step, as a

data/docs/manual/03-configuration.md

@@ -19,8 +19,10 @@ To *layer* configs rather than replace, a config file can name
 a base with `includes:` (recursive). `--config=PATH` bypasses
 discovery entirely.
 
-All relative paths in a config file resolve against that
-file's own directory.
+Relative paths in a config file resolve against that file's own directory, with three exceptions:
+`bundler.bundle_path:`, `bundler.lockfile:` and `rbs_collection.lockfile:` resolve against the working directory
+`rigor` runs from. They match only when you run `rigor` from the directory that holds the config file, which is
+the usual case; with `--config path/to/.rigor.yml` from elsewhere, give these three as absolute paths.
 A leading `~/` (or a bare `~`) in a path setting expands to your home directory; `~name` is an ordinary
 directory called `~name`, not another user's home. This covers `paths:`, `signature_paths:`, `test_paths:`,
 `pre_eval:`, `plugins_io.allowed_paths:`, `includes:`, `bundler.bundle_path:`, `bundler.lockfile:` and
@@ -64,7 +66,7 @@ cache:
 | --- | --- | --- | --- |
 | `target_ruby` | String | `"4.0"` | The lowest Ruby version *your* project runs on — `"X.Y"`, `"X.Y.Z"`, or `"latest"`. Independent of the Ruby Rigor itself runs on. Every value selects the syntax Rigor parses. A version you set explicitly also turns on the Ruby-deprecation rules for that version ([`call.deprecated-ruby2-keywords`](04-diagnostics.md#rule-call-deprecated-ruby2-keywords) from `"4.1"`); the default and `"latest"` never do, which is why `rigor init` writes the key commented out. |
 | `paths` | Array | `["lib"]` | Directories or files to analyse. |
-| `exclude` | Array | `[]` | Glob patterns to skip. `vendor/bundle`, `.bundle`, and `node_modules` are always excluded. |
+| `exclude` | Array | `[]` | Glob patterns to skip. A relative pattern is matched against the file's path relative to the directory of the config file in use (the working directory when no config file is used), so it excludes the same files whether the path came from `paths:` or from a command-line argument, and it never matches on a directory above that base (a file outside it is seen as `../…`, so `../shared/lib/gen/**` reaches a sibling directory that `paths:` names). A leading `./` is ignored, and a pattern starting with `.` (such as `.*`) also matches files outside the base, which appear as `../…`. A symlink to a file is matched only under its own name: the realpath pass resolves directories, not files. `*` and `**` also cross `/`, so `lib/*.rb` matches nested files too. An absolute pattern is matched against the absolute path. Patterns from an `includes:` file resolve against the top-level config's directory, not the included file's. `vendor/bundle`, `.bundle`, and `node_modules` are always excluded. |
 | `test_paths` | Array | `nil` | The project's test roots: the directories (or files) holding its tests. Relative entries resolve against the config file's directory. Unset auto-detects whichever of `spec/` and `test/` exist; `[]` declares none. `rigor sig-gen --params=observed` reads call sites there to type parameters, and names on stderr a declared root that does not exist. Test roots are not analysed unless `paths:` also lists them, and changing them invalidates no cache. |
 | `includes` | Array | `[]` | Other config files to layer underneath this one. |
 | `fold_platform_specific_paths` | Boolean | `false` | Resolve Ruby-version-conditional load paths when discovering sources. |
@@ -76,7 +78,7 @@ cache:
 | --- | --- | --- | --- |
 | `libraries` | Array | `[]` | Standard-library / gem names whose bundled RBS to load. |
 | `signature_paths` | Array | `nil` | Extra directories of `.rbs` files. Relative entries resolve against the config file's directory. |
-| `pre_eval` | Array | `[]` | Files (or globs) walked before per-file analysis, to register project monkey-patches and publish their top-level constants project-wide. |
+| `pre_eval` | Array | `[]` | Files (or globs) walked before per-file analysis, to register project monkey-patches and publish their top-level constants project-wide. The walker does not follow `require` / `require_relative`, so list the files in load order: a method declared in two files takes the last-listed one, and a file that requires a later-listed one is still read in list order. |
 | `plugins` | Array | `[]` | Plugins to activate — see [Using plugins](07-plugins.md). |
 
 ### Signature generation

data/docs/manual/05-inspecting-types.md

@@ -89,6 +89,14 @@ array. Line queries add `line_enumerations` metadata with the
 shown and total expression counts. An exact position is the same
 query the editor integration answers on hover.
 
+Inside a `rescue` or `ensure` clause, `type-of` and hover can
+disagree with `rigor check`. `check` reads a variable that the
+`begin` body assigns as untyped there, because the clause may run
+after the body raised partway through. `type-of` shows the value
+the variable had before the `begin`. In
+`conn = nil; begin; conn = open_conn; work; rescue; conn.close; end`,
+`type-of` reports `conn` as `nil` and `check` reports nothing.
+
 ## `rigor trace` — watch the inference happen
 
 Where `annotate` and `type-of` show the *answer*, `rigor trace
@@ -110,11 +118,53 @@ typer visits; the default keeps only the three teachable event
 kinds. The JSON stream is stable enough to build course
 material or figures from.
 
+## `rigor lens` — a file's declarations and where their types come from
+
+`rigor lens` lists every class, module, method and attribute a
+file declares, with the type each one has and where that type
+came from: `sig/`, an inline `#:` / `@rbs` comment, a plugin, a
+library, or Rigor's inference from the body. It is experimental:
+the command and its `lens/v0` JSON may still change.
+
+```sh
+rigor lens lib/shop.rb                    # text, for reading
+rigor lens --format=json lib/*.rb         # one JSON document
+```
+
+```text
+lib/shop.rb  xxh3-64:845f7426b6acfe12  (2 omitted)
+  4:7c90  class Shop
+  8:e37e  Shop#label: (::Integer n) -> ::String  [contract inline]
+  14:ce93  Shop#total: () -> Integer  [single_site inferred]
+  16:182b  Shop#fetch  [contested; also lib/legacy_shop.rb:2]
+  omitted constant Shop::LIMIT (line 5)
+```
+
+The answer is the one `rigor check` reaches. A lens runs the
+same incremental analysis as `rigor check --incremental` and
+shares its cache, so the first run costs a full check and later
+runs reuse it. The diagnostics it reports for a file are the
+ones `check` reports.
+
+- A method Ruby could take from more than one definition (the
+  same method defined in two files) is `contested`. Rigor does
+  not guess which one runs, so it prints no signature for it.
+- A declaration this version does not model yet (a constant, an
+  `alias`, a `define_method`) is listed as omitted, never
+  dropped.
+- `LINE:HASH` is an anchor: it changes when the declaration or
+  the type comments above it change, and not when prose
+  comments do.
+
+The JSON document is specified in
+[the lens output contract](../internal-spec/lens.md).
+
 ## Which to reach for
 
 | You want… | Use |
 | --- | --- |
 | One expression's type, from the shell | `rigor type-of` |
+| A file's declarations, their types and where each came from | `rigor lens` |
 | Every line of a file surveyed | `rigor annotate` |
 | The derivation replayed step by step | `rigor trace` |
 | A type printed mid-analysis, in context | `dump_type` |

data/docs/manual/12-caching.md

@@ -184,7 +184,8 @@ file, which other files its analysis read from, so it knows
 exactly which files an edit can affect. A continuous-integration
 gate, `rigor check --verify-incremental`, asserts this on every
 build: it runs the incremental analyzer and a full analysis and
-fails if they disagree on a single diagnostic.
+fails if they disagree on a single diagnostic, or list the same
+diagnostics in a different order.
 
 Rigor is also precise about *what* an edit changed. Re-checking a
 file that many others depend on — a base class, a widely-used
@@ -259,6 +260,22 @@ version change does, or `--clear-cache`. So the shortcut can stay
 off indefinitely; run `rigor check --incremental --clear-cache`
 once to turn it back on.
 
+
+A warm `--incremental` run says on stderr how far the edit spread,
+for example `rigor: --incremental warm — re-analysed 3 of 1295 files
+(1 changed), reused the rest`. The first count is the files the
+recheck re-analysed, out of M, the analysed set: every project file
+the run covers, or only the subset under a path argument such as
+`rigor check --incremental lib`. The re-analysed files are M minus
+those served from the snapshot. They include files that a change
+reached without editing them, such as a file whose inferred
+parameter types moved (ADR-67), not only the edited files and their
+dependents. The parenthesis lists `changed`, and `added` or
+`removed` when there are some. View templates from a plugin are not
+in M. The recheck re-runs every template on every warm run, so they
+are counted after the file clause, as `plus 2 view templates`. An
+unchanged run reads `re-analysed 0 of 1295 files, reused all`.
+
 `--incremental` is most useful for fast local re-checks and CI
 on a changed branch.
 

data/docs/manual/14-rails-quickstart.md

@@ -185,8 +185,8 @@ paths:
   - lib
 
 exclude:
-  - vendor
-  - tmp
+  - "vendor/**"
+  - "tmp/**"
 
 plugins:
   # Rails core

data/docs/manual/18-removing-dead-code.md

@@ -116,8 +116,9 @@ gap in coverage rather than a finding about your code.
 rigor unused --entry-point='lib/cli.rb' --entry-point='lib/workers/**/*.rb'
 ```
 
-Repeatable. Each glob is matched against every declaration's path, and
-roots every declaration in a matching file.
+Repeatable. Each glob is matched against every declaration's path as
+written, relative to the project root, and relative to the directory
+you run in, and roots every declaration in a matching file.
 
 **File-level references**, free. Code that runs on load — an
 initializer naming a class, a `.rake` task — roots what it names. This
@@ -162,9 +163,12 @@ section held 22 policy classes whose only remaining caller was
 `spec/policies/`. Those 22 were not adjudicated, so treat the section
 as high-signal rather than high-yield; the yield is unmeasured.
 
-"Test code" is decided by path, relative to the directory you run `rigor unused` in (run it from the
-project root): `spec/` and `test/` anywhere below it, `*_spec.rb` and `*_test.rb`, and the end-to-end
-trees `qa/`, `e2e/` and `features/` at that root. Tooling directories such as
+"Test code" is decided by path, relative to the project root: the directory of the `.rigor.yml` in
+use, or the directory you run `rigor unused` in when there is none or when the config sits below it
+(`--config=ci/rigor.yml` from the project root). Running it from a subdirectory with `--config` reads
+the same project, and references are read from the directory you run it in as well. A file counts
+as test code when its path as written below either directory says so. The test paths are `spec/` and `test/` anywhere below the root,
+`*_spec.rb` and `*_test.rb`, and the end-to-end trees `qa/`, `e2e/` and `features/` at the root. Tooling directories such as
 `rubocop/`, `keeps/`, `tooling/` and `scripts/` count as production, so a class used only by them is
 rooted rather than listed: deleting it would break the tooling.
 
@@ -257,10 +261,13 @@ can only bound the namespace, so everything under `Foo` is demoted;
 `"V#{version}"` is the start of a name, so `V1`, `V2_0` and everything
 under them are. `const_get` looks the name up from its receiver, so
 `const_get("V#{version}")` inside `class Migration` demotes
-`Migration::V1` — and the top-level `V*` names as well, unless the call
-passes `false` as its second argument. A name built into a local
-variable first (`name = "V#{version}"; const_get(name)`) is read the
-same way. A
+`Migration::V1` — and the `V*` names under `Migration`'s superclasses
+and mixins and at the top level as well, unless the call passes `false`
+as its second argument. A literal `const_get("Handler")` is a reference
+looked up in the same order, so it names `Migration::Handler` when
+that exists rather than a top-level `Handler`. A name built into a
+local variable first (`name = "V#{version}"; const_get(name)`) is read
+the same way. A
 class name appearing as a string in a `.yml`, `.json` or template file
 demotes the same way — weaker evidence than a constant reference, and
 neither proof of use nor grounds to call it dead.

data/lib/rigor/analysis/check_rules/rule_ids.rb

@@ -156,6 +156,13 @@ module Rigor
       # first segment appears here as KNOWN and stays silent: these ids are legitimate suppression /
       # `severity_overrides:` vocabulary the light rule-id table cannot enumerate (plugins load dynamically;
       # aggregator ids live in the engine-heavy runner), so under-warning is the FP-safe direction.
+      # The `pre-eval.*` ids (ADR-17 WD6) the bare family wildcard `pre-eval` expands to. Emitted by the
+      # `pre_eval:` pre-pass, outside the CheckRules catalogue, so the family cannot ride `RULE_FAMILIES`
+      # (which also drives the catalogue and the config audit over `ALL_RULES`).
+      PRE_EVAL_RULES = %w[
+        pre-eval.parse-error pre-eval.file-not-found pre-eval.duplicate-declaration
+      ].freeze
+
       NON_CHECK_DIAGNOSTIC_FAMILIES = %w[rbs_extended dynamic rbs pre-eval plugin plugin_trust].freeze
 
       # Bare (dot-less) diagnostic ids the engine emits outside the catalogue (see the `rule:` literals in

data/lib/rigor/analysis/check_rules.rb

@@ -87,6 +87,7 @@ module Rigor
       def self.resolve_rule_token(token)
         return nil if token == "all"
         return [LEGACY_RULE_ALIASES.fetch(token)] if LEGACY_RULE_ALIASES.key?(token)
+        return PRE_EVAL_RULES if token == "pre-eval"
         return ALL_RULES.select { |r| r.start_with?("#{token}.") } if RULE_FAMILIES.include?(token)
 
         ALL_RULES.include?(token) ? [token] : []
@@ -654,7 +655,7 @@ module Rigor
       # `dynamic.*`, `rbs.*`, `pre-eval.*`, and any `plugin.`-prefixed id — plugins load dynamically, so
       # their rule vocabulary cannot be enumerated here and under-warning is the FP-safe direction).
       def known_suppression_token?(token)
-        return true if token == "all"
+        return true if %w[all pre-eval].include?(token)
         return true if ALL_RULES.include?(token) || LEGACY_RULE_ALIASES.key?(token) ||
                        RULE_FAMILIES.include?(token) || NON_CHECK_DIAGNOSTIC_IDS.include?(token)
 
@@ -863,29 +864,23 @@ module Rigor
 
         # Is a refinement of `call_node`'s method name into `class_name` (or an ancestor) in effect at the call?
         # Issue #1120 asks it for a method the class lacks. The two argument rules ask
-        # {#refined_redefinition_in_effect?} instead (issue #1740), and this only for a class-object receiver.
-        # Typing the call from the refine body is #1664.
-        # A refinement answers instance-side receivers only: a refined singleton (`refine X.singleton_class`) names
-        # no constant target, so nothing records it. Issue #1673 — the answer is derived from the file's in-effect
-        # refinements ({Inference::InEffectRefinements}), the list the typer reads, with each `using` expanded
-        # through its module's includes (issue #1671).
+        # {#refined_redefinition_in_effect?} instead (issue #1740). Typing the call from the refine body is #1664.
+        # Issue #1752 — a class-object receiver (`kind` `:singleton`) is reached by a refinement of any class or module
+        # on its lookup: `Class`, `Module`, `Object`, `Kernel`, `BasicObject`, or a module it extends. A refined
+        # singleton class (`refine X.singleton_class`) names no constant target, so its rows are class-unknown, which
+        # reach every receiver. Issue #1673 — the answer is derived from the file's in-effect refinements
+        # ({Inference::InEffectRefinements}), the list the typer reads, with each `using` expanded through its
+        # module's includes (issue #1671).
         #
         # ADR-121 WD7 — a module in effect whose refinements Rigor cannot read
         # ({Inference::InEffectRefinements.opaque_module?}: a gem's, one from outside the analysed paths, one with an
         # unreadable `refine`) may refine any class, a class object's included, so the call declines whatever its
-        # receiver. Issue #1796; both argument rules ask this predicate too.
+        # receiver. Issue #1796.
         def refined_method_in_effect?(class_name, call_node, scope, kind, lexical_sites)
           return false if lexical_sites.nil?
           return true if opaque_refinement_in_effect?(call_node, scope, lexical_sites)
 
-          modules =
-            if kind == :instance
-              Inference::InEffectRefinements.refining_modules(scope, class_name, call_node.name)
-            else
-              # ADR-121 WD7 — a row whose class the walk could not name (`refine(k)` with `k` a singleton class)
-              # reaches a class object too.
-              Inference::InEffectRefinements.class_unknown_refining_modules(scope, call_node.name)
-            end
+          modules = Inference::InEffectRefinements.refining_modules(scope, class_name, call_node.name, kind)
           !modules.nil? &&
             lexical_sites.refinements.refinement_active?(call_node.location.start_offset, modules,
                                                          scope.declared_refinements) do |name|
@@ -902,8 +897,8 @@ module Rigor
         #
         # A call with nothing in effect is checked. Otherwise it reports only from positive knowledge: the list
         # carries no unknown marker and no opaque module, and {Inference::RefinedDispatch::OwnMethod} proves the
-        # receiver's own definer answers first. A class-object receiver keeps {#refined_method_in_effect?}'s
-        # answer: its singleton-side levels are not walked yet.
+        # receiver's own definer answers first. Issue #1752 — a class-object receiver (`kind` `:singleton`) walks its
+        # singleton levels: `Integer.sqrt(1, 2)` under `refine Object do def sqrt(a, b)` runs `Integer.sqrt` and raises.
         def refined_redefinition_in_effect?(class_name, call_node, scope, kind, lexical_sites)
           return false if lexical_sites.nil?
 
@@ -911,9 +906,8 @@ module Rigor
           return false if list.empty?
           return true if list.include?(Inference::InEffectRefinements::UNKNOWN)
           return true if opaque_refinement_in_effect?(call_node, scope, lexical_sites)
-          return refined_method_in_effect?(class_name, call_node, scope, kind, lexical_sites) unless kind == :instance
 
-          !Inference::RefinedDispatch::OwnMethod.answers?(scope, class_name, call_node.name, list)
+          !Inference::RefinedDispatch::OwnMethod.answers?(scope, class_name, call_node.name, list, kind: kind)
         end
 
         # The in-effect list at the call as the typer reads it: the lexical activations, each `using` expanded,
@@ -2093,7 +2087,13 @@ module Rigor
         # arm restores the polarity without touching the shared helper:
         # `String | nil` keeps firing, and so does `Dynamic | String | nil` —
         # the nameless arm stays permissive inside the all-arms check, which is
-        # only about the arms' method surface.
+        # only about the arms' method surface. That union no longer arises from
+        # a merge re-joining the narrowed edges of one untyped local, which
+        # binds it back to `Dynamic[top]` (issue #1840,
+        # `Inference::UntypedRejoin`); it still does when the program writes
+        # the `nil` (`x = nil if c`) and no `nil?` edge strips it before the
+        # re-joining merge, or when the arms are not a narrowing of one
+        # untyped value.
         def union_has_nameable_non_nil_arm?(union, scope)
           union.members.any? do |m|
             next false if nil_member?(m)
@@ -2195,7 +2195,8 @@ module Rigor
         # ADR-121 WD7 — a refinement in effect (or one Rigor cannot read) may define the name on one arm's class.
         def refined_on_some_arm?(members, call_node, scope, lexical_sites)
           members.any? do |member|
-            refined_method_in_effect?(concrete_class_name(member), call_node, scope, :instance, lexical_sites)
+            kind = member.is_a?(Type::Singleton) ? :singleton : :instance
+            refined_method_in_effect?(concrete_class_name(member), call_node, scope, kind, lexical_sites)
           end
         end
 

data/lib/rigor/analysis/effects_cache_probe.rb

@@ -80,7 +80,7 @@ module Rigor
       private
 
       def effects_descriptor(paths)
-        files = PathExpansion.ruby_files(paths, @configuration.exclude_patterns)
+        files = PathExpansion.ruby_files(paths, @configuration.exclude_patterns, base: @configuration.exclude_base)
         base = RunCacheKey.descriptor(
           configuration: @configuration, files: files, explain: false,
           rbs_config_entries: RunCacheKey.libraries_config_entries(@configuration)

data/lib/rigor/analysis/incremental_run_slot.rb

@@ -42,8 +42,8 @@ module Rigor
     # plugin's identity and the engine's (key slots), so a project whose plugins claim template globs is served
     # too. The ADR-87 probe misses on one: the plain slot's key carries the `template-units` slot.
     #
-    # `explain:` is always false: the session's runners never set it (#1533), and the CLI declines the probe under
-    # `--explain`.
+    # `explain:` is always false: the session writes no slot for an `--explain` run (#1533), and the CLI declines
+    # the probe under `--explain`.
     module IncrementalRunSlot
       module_function
 
@@ -115,7 +115,7 @@ module Rigor
       def serve(configuration:, cache_root:, paths:)
         return nil if configuration.effects_enabled?
 
-        files = PathExpansion.ruby_files(paths, configuration.exclude_patterns)
+        files = PathExpansion.ruby_files(paths, configuration.exclude_patterns, base: configuration.exclude_base)
         slot_key = key(configuration: configuration, target: Target.new(files: files, roots: paths))
         return nil if slot_key.nil?