test-testslisted

Empirical test-suite strength audit. Launch the audit workflow — do **not** probe the suite inline. The workflow returns a structured report; relay it and save it to a file. The audit temporarily mutates production code to check that tests fail, inside its own git worktrees when the suite can run there, or in the live tree under a backup/restore protocol when it cannot — either way every edit is reverted and integrity-checked. Nothing is ever committed, no test is written, nothing is installed. ## Run the workflow 1. Parse `$ARGUMENTS` as `[low|medium|high|ultra] [path]`. Both optional. A leading `low` | `medium` | `high` | `ultra` token is the **level**; everything after it is the target path (default: the repo root — resolve a free-form description to a directory or fall back to the root). If no level token is given, ask with `AskUserQuestion` (header "Level"): - `low` — the highest-churn components, a few mutants each. Quick signal. - `medium` (recommended) — all components (capped), plus no-op and delay probes and the two audit-wide probes (coverage-truth, unit isolation). The standard audit. - `high` — the deepest dials, plus an adversarial pass that refutes equivalent mutants. The trustworthy-numbers audit. `ultra` is accepted so one depth token means the same thing across the audit workflows, but this audit has no rung above `high` — its cost is the suite's own runtime, not a refutation pass — so `ultra` runs the `high` dial