The saved-trips search, then saved searches, then tabs
The trip planner’s saved-trips page: a search box, filter chips, a sort menu and a pager each add to one search as the user acts, and the list page runs it as SQL with numbered parameters. Each level starts from the previous level’s finished code, so you can begin at any of them.
A teammate’s pull request moves the search to SearchSessions: every part of the page sends its change with the tab it came from, and the list page asks for a tab’s results. It keeps one TripSearch for every tab, “to save making one per tab”, and starts a fresh one after each run, “so one search cannot leak into the next”. QA reports that results in one tab sometimes include another tab’s filters, and that refining a search forgets what was already chosen. You are reviewing the pull request.
Users see trips they did not ask for, in a list that says it is filtered. Every refinement starts over, and a search the planner rejects (a page with no order) throws away the user’s choices instead of letting them fix it.
Reproduce Tab A filters kind overnight, tab B filters place Harbor, then A runs and B runs. A should find overnight trips and B Harbor trips. Today A’s query has both filters and B’s has none.
Acceptance criteria Each tab’s search holds only that tab’s choices, however the tabs’ changes interleave. A tab’s choices stay between runs, so a refined search keeps its earlier filters, and a rejected run leaves the draft to repair. Closing a tab forgets its search; a tab that has chosen nothing finds every trip. TripSearch’s rules still hold in every tab: clause order, numbering, a page needs that tab’s own order. Notes Each run prints the tab’s query, as show writes it, or “rejected (reason)”; a case’s runs are joined by “ || ”. Keep SearchSessions’ name and its methods’ names and signatures; the checker makes one per case and sends it every tab’s steps in turn.