Symptom (QA 6.1)
In the Opportunities table, selecting a commitment via its checkbox sometimes reorders the visible rows. The selected commitments stay selected, but the table re-sorts on selection, which is disorienting.
Why it's a bug
Selection should not affect ordering. Users are mid-flow trying to compare commitments; the table shifting under them breaks that flow.
Hypothesis
The selection state is being fed back into a sort comparator (e.g. selected rows bubble to the top, or the table re-renders with a different stable-sort tiebreaker that the comparator forgets). Find the sort path in frontend/src/recommendations.ts (or wherever the table is rendered) and confirm selection state is excluded from the sort key.
Acceptance criteria
- Toggling a checkbox does NOT change row order.
- The currently-applied sort column (Monthly Savings, etc.) remains the ordering basis.
- A regression test toggles two checkboxes across a multi-row fixture and asserts row order is identical before/after.
Source
QA exploratory testing, 2026-05-27. Recording referenced in the spreadsheet.
Symptom (QA 6.1)
In the Opportunities table, selecting a commitment via its checkbox sometimes reorders the visible rows. The selected commitments stay selected, but the table re-sorts on selection, which is disorienting.
Why it's a bug
Selection should not affect ordering. Users are mid-flow trying to compare commitments; the table shifting under them breaks that flow.
Hypothesis
The selection state is being fed back into a sort comparator (e.g. selected rows bubble to the top, or the table re-renders with a different stable-sort tiebreaker that the comparator forgets). Find the sort path in
frontend/src/recommendations.ts(or wherever the table is rendered) and confirm selection state is excluded from the sort key.Acceptance criteria
Source
QA exploratory testing, 2026-05-27. Recording referenced in the spreadsheet.