The mutant schema for a whole project: every in-scope source transformed into its metamutant, with globally-unique mutant ids threaded across files.

This is what the runner compiles once and the report reads from. Files that have no mutation sites, or that fail to parse, are left out of :metamutants (their originals are used as-is) but never crash the build — a single unparseable file should not sink the run. A failure after a clean parse (transform or render) is a bug in this tool, not bad input, and is left to crash: see render_one/5.

Two-phase build (from_files/4)

Mutant ids are baked into each metamutant's selector clauses, so a naive per-file render can't run concurrently — file i's :start_id is file i-1's next_id. The build decouples id assignment from rendering in two passes, both run in throwaway worker processes so each file's heavy, short-lived ASTs (the emitted tree, Sourceror's render buffers) die with their worker instead of accumulating in the scan's long-lived heap, where they made every GC scan the growing live set and inflated a big file's transform several-fold (see NOTES "Scan is transform-bound"):

1. Count (count_files/3) — Mutare.Transform.count_string/2 per file, in parallel. It runs the same analyze → plan → emit pipeline but skips the dominant final render, returning just each file's mutant count. The count is drift-proof: it comes from the same id-claiming path emission uses, so it equals the matching render's next_id - start_id by construction.
2. Render (render_files/3) — prefix-sum the counts so each sited file knows its globally-unique :start_id up front, then Mutare.Transform.transform_string/2 each file (with that :start_id and the run's :skip_ids) in parallel. render_one/5 re-checks the count against the rendered next_id and fails loudly on any drift, since id stability across files depends on the two passes agreeing.

The two passes agree only because the pipeline they share — parse, use-expansion, resolution, and every mutator — is a deterministic function of the source and opts; it runs once per pass, so a nondeterministic custom mutator or extension expand_use/3 surfaces as that render_one/5 drift crash rather than a silent id overlap. from_files/4 also dedups its input by relative path, so a file passed twice is rendered once, under one id range — never two overlapping ones.

Both passes preserve exact :start_id threading (the prefix sum reproduces the old sequential thread) and the let-it-crash contract: a worker classifies an unparseable source as a skipped file but re-raises any other exception, with its original type and stacktrace, in the parent — so a tool bug still surfaces faithfully across the process hop, not as an opaque Task exit.

Each sited file's :start_id is recorded under :start_ids — the origin of the file's id range before :only_lines/:max_mutants narrow :sites. A report-time re-render (render_opts/3) reads it from there, never from the visible sites: under --line the smallest surviving id is not the file's first mutant, and a re-render started from it would hand every id another site's code.

We store each file's rendered metamutant source (under :metamutants) but not a precomputed Mutare.Manifest: the manifest (generated line ranges, for mapping a compile error back to a mutant) is read only on a failed compile, so Mutare.Poison builds it lazily from the metamutant for the offending file(s). Building it eagerly here was the scan's dominant cost — a full Sourceror.parse_string! of a ~40k-line metamutant takes minutes — and was thrown away on every healthy run.