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").

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.)