The mutant schema for a whole project: every in-scope source transformed into its metamutant, with globally-unique report ids and stable per-file runtime ids.

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/3.

Two-phase build (from_files/4)

Report ids reserve contiguous ranges in file order — file i's :start_id is file i-1's next_id. Emitted selectors instead use local integers under the root-relative file namespace (Mutare.RuntimeId). An unrelated file's candidate-count change therefore leaves this file's metamutant byte-identical, provided its source, transform inputs, and effective emission selection stay the same. A global cap can change that selection even with unchanged options.

The build determines report ranges and global selection before 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/4) — Mutare.Transform.count_report/2 per file, in parallel. It runs the same analyze → plan → emit pipeline but skips the dominant final render, returning each file's mutant count and, for a line selection, the matching local ids (without rendering site diffs) — plus the facts the end-of-build diagnostics read (matched configuration entries, the comment-directive container, degraded uses), collected here because this is the one pass that parses every file: nothing later re-parses. 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 is given its globally-unique :start_id up front, then Mutare.Transform.transform_string/2 each file (with that :start_id and the file's :runtime_namespace, and the run's report-space :skip_ids and statically selected :emit_ids) in parallel. Every candidate reserves its id and records its diagnostic site, but only selected candidates emit branches. render_one/3 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/3 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.

The slice is checked the same way. A --line / --max-mutants run narrows twice — emission in render_jobs/2, the reported sites at the end of from_files/4 — so from_files/4 compares the finished site ids against the ids it selected for emission and raises on any difference: a reported site whose mutant never reached the metamutant would run the suite unmutated and be scored a survivor.

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) and the dispatch variable its generated code reads (under :dispatch_vars, beside :start_ids; Mutare.Transform.Result.dispatch_var) 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.