A map from mutant ids to their generated line ranges in a rendered metamutant, and a list of every place the generated code names a mutant id.

Mutare.Transform writes the metamutant; this is what Mutare.Poison reads back. It is built lazily (from_source/2), by Mutare.Poison on a failed compile, only for the file(s) the error names — not eagerly during the scan, where re-parsing every rendered metamutant was the scan's dominant cost yet is read only when a compile actually fails (rare — built-in mutators are compile-safe). Poison memoizes it within one recovery so a file faulting on several lines is walked once.

The one exception is verify_invariants: true (mix mutare --verify-invariants): the transform then builds a manifest for every file it renders and compares its :mentions with the mutants it recorded, raising Mutare.InvariantError on a mismatch.

Mutare.Poison uses each mutant's generated ranges — the metamutant line spans of the code that exists only because of that mutant, so a compile error's line maps back to the corresponding mutant id.

(Coverage is recorded separately: the metamutant self-records coverage at runtime — see Mutare.Coverage.Recorder — keyed by mutant id directly, so there is no metamutant {module, line} location to precompute.)

Why ranges, not a single line

Poison recovery used to match a compile error's line against the start line of a selector clause body only. That missed every poison whose bad code isn't on that exact line:

• lifted mutations — a guard/head-pattern mutant's code appears in a generated defp <base>(mutare_active, …) when mutare_active === <id> … clause, not in the dispatcher (which only forwards). The error points into that gated clause, away from the dispatcher;
• multiline bodies — an in-place mutant whose body spans several lines can fault on any of them, not just the first;
• structural errors — the compiler sometimes points at the surrounding case rather than a clause body.

So we record, per mutant, the full line ranges of its generated code:

• each selector clause body (<id> -> <mutated>) — catches in-place mutants, including multiline bodies;
• each lifted mutant clause (gated when mutare_active === <id>) — catches a guard/head-pattern poison, whose code is outside the dispatcher. A clause shared by several guard mutants (one when alternative each) gives every alternative to its own mutant, and the whole clause — head patterns and the one shared body — to all of them;
• the whole selector case, attributed to all the mutant ids it hosts — the coarse fallback for a structural error that points at the case itself.

ids_at_line/2 resolves an error line by narrowest containing range: a line inside a specific clause/def range maps to that one mutant; only when nothing narrower contains it does the whole-case fallback fire (dropping every mutant the case hosts — a bounded over-drop that still recovers the build, never the old "couldn't map it → abort").

Clean copies

A clean region (Mutare.Transform.CleanRegion) keeps a function's uninstrumented source beside the instrumented code. That copy belongs to no mutant, and the transform copies any source without asking whether it survives the copy, so the copy's lines are recorded too, under the region's identity — the id interval its guard carries (:clean, clean_span/0). blame_at_line/2 weighs both kinds by the same narrowest-range rule, and poison recovery drops a blamed region as it drops a blamed mutant. A lifted group's clean clauses sit outside their dispatcher, under the name CleanRegion.read/2 reports; each such definition is a span of that region.

Ranges are in metamutant line space, which only exists after rendering, so the manifest is built by re-parsing the rendered metamutant and ranging its generated nodes with Sourceror.get_range/1, recognising selectors via Mutare.Metamutant.subject?/2. A selector inside a function body reads the file's dispatch variable rather than :persistent_term directly, and a lifted or tupled mutant clause is gated on it (<var> === <id>) — so that name must be supplied to the reader. It is per file (:mutare_active, or a salted variant when the source already uses that identifier), chosen by the transform and handed out with the metamutant (Mutare.Transform.Result.dispatch_var, Mutare.Schema's :dispatch_vars); from_source/2 takes it alongside the source.

The re-parse uses Elixir's own Code.string_to_quoted! (with :token_metadata

• :columns), not Sourceror.parse_string!. get_range/1 only needs that token metadata (:line/:column/:closing/:end/:end_of_expression), which the stdlib parser already produces; what Sourceror.parse_string! adds is a comment-merging pass that is quadratic on a large metamutant (a lifted 1.8 MB file re-parses in ~0.6 s here, versus minutes for Sourceror) and that the manifest never reads. A :literal_encoder reproduces Sourceror's {:__block__, meta, [literal]} wrapping so the recognisers — already tolerant of both shapes — accept the resulting nodes; the two parses yield identical ranges. (Sourceror is still the renderer; only this readback parse changed.)