Give frontend developers evidence without a guessed diagnosis

Describe the visible symptom first

A report that says the state store is broken can conceal the more useful observation that a selected table row disappears after pagination. Start with the control, action, and result the reviewer actually saw. A screenshot can establish a layout state; a recording can preserve a transition. Neither automatically identifies the responsible component, request, or data flow.

Build a compact reproduction record

Capture the relevant journey with safe data and review the proposed findings in Retick. Include the selected row before pagination and its state afterward. Add the build, browser, route, account role, and input conditions manually where relevant. Ask the reporter for missing details rather than filling gaps with a confident but unsupported sequence. A shorter confirmed scenario is more useful than a complete-looking invented one.

Define an acceptance boundary

Have product confirm whether selection should persist across pages. If it should, describe how selected items remain identifiable and what a bulk action should affect. Keep unrelated table styling outside the issue unless it is part of the same outcome. Export a reviewed selection to Trello or use a downloaded file for a manual handoff to your own development process.

Investigate and verify in engineering tools

Use the repository, browser developer tools, and application tests to establish the implementation cause. After a change, repeat the accepted scenario and test adjacent selection states. Retick does not inspect your code or execute a browser regression suite through media analysis. Treat evidence-backed issue wording as the starting point for engineering, not a substitute for diagnosis, review, or testing.