fix(mutation-testing): tooling.md names --since for StrykerJS and Stryker4s; neither has it

[kyle-sexton]

plugins/mutation-testing/skills/principles/reference/tooling.md lists --since as the
diff-scoping flag for StrykerJS and for Stryker4s. Neither tool has that flag.

Found while scoping an unrelated question against primary sources for #2680. Pre-existing, not
introduced by any open PR.

Why it matters

plugins/mutation-testing/skills/audit/SKILL.md (Phase 2, the diff-scoped generation step) tells the
run to delegate scoping to the configured tool using the flags this table names. So the table is not
reference trivia — it is the instruction an agent follows. A wrong flag produces a tool error, and
the likely recovery is the failure mode this plugin exists to prevent: the run quietly falls back to
whole-project mutation, which is orders of magnitude more expensive, or reports a scoping failure as
"no mutants".

What is wrong

• StrykerJS — no --since. The diff-scoping option is --incremental (with
  --incrementalFile). Verified by enumerating the CLI options on the current docs site.
• Stryker4s — no --since either; the table's entry for it is wrong.

What is correct in the same table, verified in the same pass

• Stryker.NET — --since is real.
• Infection — --git-diff-lines, --git-diff-base, --git-diff-filter are real.

So the defect is two rows, not the table.

Suggested fix

Correct the two rows and add the verification date, since these are upstream-owned flags that drift.
Worth checking whether anything else in the plugin composes a command from this table.

Sourcing

Docs-site, single-source, from a scoping pass that stated its tiers explicitly and separated
double-verified claims from single-source and repo-source ones. Re-verify against the current docs
before acting — that is the discipline these rows failed in the first place.

Related

• feat(mutation-testing): persist survivors as a conforming findings file behind a flag #2680 / PR feat(mutation-testing): persist survivors as a conforming findings file behind a flag #2715 — where this surfaced. Deliberately NOT widened into that PR; it is unrelated to
  the persist path and touching it there would mix an upstream-drift fix into a contract change.

[kyle-sexton]

Second correction for the same file — add a regime column

Found while verifying #2680's restoration-gate work. Same file, same re-verification pass, so folding
it in here rather than opening a third front.

The gap

plugins/mutation-testing/skills/audit/SKILL.md Phase 0 now resolves which restoration regime a
run is in, and instructs: "Read the project's own config for it — the out-of-tree default of most
tools is user-changeable, so the tool's reputation is not the answer."

That instruction is correct and deliberately refuses to assume the default. But it is unactionable
against a concrete tool, because nothing in the plugin says which config key encodes the regime.
An agent holding a stryker.conf.json has no instruction telling it the key is inPlace.

tooling.md's table is currently (ecosystem, tool, diff-scoping flag, covered-code metric name) —
there is no regime or setting column.

Why it needs its own column rather than prose

There are two distinct branches, and collapsing them is the likely error:

• A setting to read — e.g. StrykerJS's inPlace. The agent must read the project's config,
  because the default is user-changeable.
• Nothing to read — tools with no in-place option at all. For these the out-of-tree regime is a
  constant, not a check, and instructing an agent to "read the config" sends it looking for a key
  that does not exist.

SKILL.md already carries that distinction ("Where a tool has no in-place option at all, that
precondition is a constant rather than a check"); the table is where the per-tool answer belongs.

Suggested shape

Add a column naming the setting per tool, or none — fixed out-of-tree. Keep it factual and
per-tool; the skill itself deliberately names no tool and keys its regimes on capability, which
is why the per-tool facts belong here and not there.

Re-verification, carried from the scoping pass

These are upstream-owned and were not re-fetched since the pass that produced them. Re-verify
each rather than importing the values below:

1. StrykerJS inPlace default — https://stryker-mutator.io/docs/stryker-js/configuration/.
   Highest value: if this ever flips, the Phase 0 precondition becomes the load-bearing gate rather
   than a backstop.
2. Stryker4s — no in-place option — https://stryker-mutator.io/docs/stryker4s/configuration/.
   A negative established by enumerating the options list. Negatives decay silently — an added
   option announces itself nowhere. Re-enumerate rather than spot-check.
3. Infection — no in-place mode. Same decay class, and mechanism-backed rather than doc-backed,
   so no page would contradict it if it changed. Keep the tier label rather than upgrading it.
4. PIT — https://pitest.org/faq/. The one row licensed to state a documented guarantee
   ("held in memory and never written to disk"), so it should be the freshest.
5. mutmut — the schemata boundary is 3.0.0; ≤2.x writes the user's files in place.

Do not blend the evidence tiers into one sentence. PIT is a documented guarantee, Stryker4s is a
negative by enumeration, and Infection is repo-source with no documented promise anywhere. One
sentence covering all three silently promotes the weakest to the strongest — which is the same defect
this file already has in a different form.

Related

• The --since corrections in this issue's original body (StrykerJS is --incremental; Stryker4s
  has no diff-scoping flag).
• feat(mutation-testing): persist survivors as a conforming findings file behind a flag #2680 / PR feat(mutation-testing): persist survivors as a conforming findings file behind a flag #2715 — deliberately not widened to include either correction.