qa-regression

Plan impact-based regression

Select regression checks from reachable change impact, not from convenience or the tests that happen to be available. Preserve the governing contract and make every inclusion and exclusion auditable. Read workflow, safety, artifacts, and evidence first.

Inputs

• Project root, target/environment/build identity, explicit objective or intent, identified contract source/hash, and the complete supplied criterion catalog with original IDs and text.
• Explicit change set with stable change IDs, affected components, interfaces, data, configuration, dependencies, roles, environments, and user journeys.
• Risks, prior incidents and defects, existing checks with stable case IDs, expected observable results, attempt history, prerequisites, cost, tool probes, and evidence needs.
• Explicit authorization for this write operation and the preserved authorization boundary for any proposed execution. Load, penetration, production, and external effects require separate, exact authorization before execution.

Procedure

1. Preserve the explicit objective or intent, target, contract, criterion IDs/text, change IDs, existing state, approvals, and authorization exactly. Do not infer a complete change map, criterion catalog, approval, or execution permission.
2. Identify affected surfaces and consult the installed applicable qa-specialist-* skills, starting with qa-specialist-regression; consult qa-specialist-defects, requirements, functional, API, Web, mobile, data, security, performance, automation, CI/CD, or production specialists only when their surfaces are present. An unavailable applicable specialist is a limitation. Specialist guidance does not expand authorization.
3. Trace direct and transitive impact through components, interfaces, stored data, roles, error paths, supported environments, and journeys. Materialize each relation with a change ID, impact ID, risk ID, criterion ID, prior defect ID when applicable, and stable case ID; use an explicit none plus rationale only when a relation legitimately has no defect or criterion.
4. Rank each impact by likelihood, consequence, blast radius, reversibility, and history. Select by impact with a stated rationale or justification, including applicable positive, negative, boundary, recovery, integration, and unchanged-control checks.
5. Record selected and excluded case IDs separately. For every inclusion and exclusion, preserve its complete change-to-risk/criterion/defect-to-case trace, expected oracle, prerequisite, evidence need, cost, and reason. Convenience, familiarity, availability, or a prior green result never replaces impact and cannot justify omitting a higher-impact path.
6. Classify each prerequisite and tool from observed probes as available, missing, or unverified. Missing traceability, a material unassessed impact, an unsafe or absent oracle, or unavailable required coverage remains BLOCKED; never substitute a non-equivalent check.
7. Preserve existing attempts and current defects, then apply verdict precedence. A proven current in-scope failure, including an unlinked defect, is FAIL; otherwise a pending impact, check, prerequisite, or evidence gap is BLOCKED. A plan is not execution evidence and cannot manufacture PASS.
8. Return the selection without executing tests. A later authorized workflow may execute it; qa_report.py report --manifest PATH --project-root PATH is a later inert export and the report does not execute or re-run tests.