mastermind-test-impact

Mastermind Test Impact

Use deterministic candidates to prioritize feedback. Never treat them as proof that omitted tests are unnecessary.

Workflow

1. Choose the same trusted baseline and fresh index used for change analysis. Run mastermind status first. Stop on index_stale unless re-indexing is authorized; never infer candidates from a stale graph.

2. Run mastermind impact --since REF --format json, or call mmcg_test_impact for the exact test projection.

3. Reject a response that omits either the focused_tests_do_not_replace_full_gate or test_candidates_are_static_and_do_not_prove_execution_or_assertion_coverage caveat.

4. Group candidates in this order:

   • direct: a changed test symbol at depth 0 or a graph-linked test at depth 1;
   • transitive: a graph-linked test at greater depth;
   • heuristic: a same-component candidate identified by a test filename or explicit test attribute, without graph evidence linking it to the change in this response.

5. For each test, retain file, symbol, line, depth, confidence, changed-symbol seeds, and structured evidence. Preserve same_component_test_attribute for inline attribute matches and same_component_test_filename for test-like paths. An attribute identifies a test candidate, not coverage of the change. Explain collisions or weak language edges.

6. Run focused tests from high to low confidence for fast feedback, then run every project-required phase/final gate.

Do not invent framework commands. Discover them from repository configuration and the task spec. Do not call a heuristic candidate “covered”. If graph and heuristic work were skipped with work_limit, report that no classified candidates are available. A separately labeled fallback may widen by changed modules and repository-owned test commands, but it is not direct, transitive, or heuristic response evidence. Always retain the full gate.