Merivia · trip repair · feature change
Proposal — not yet builtTapping Find a place hands the traveller three dots and a locked screen. This turns it into a window you can watch, close, and run three of at once — with a nudge when each one lands. Both versions are running further down this page; tap them.
The symptom · working mock of today
The trip lists what needs you. You tap Find a place on Rome — and Florence and Venice go grey at the same moment, because the app only tracks one request at a time. The button becomes three dots. That is the entire feedback.
Behind the scenes the search really is running, and it survives you closing the app. None of that is visible.
Tap Find a place on any city. Watch what the other two do.
The change · working mock of what gets built
This is the thing itself, not a picture of it — the same window, the same live text, the same tray. Start Rome, then start Florence while Rome is still going. Close the window mid-search and come back to it.
Start Rome. While it runs, close the window and start Florence. Then Venice. Nothing waits on anything else.
Orientation
Four places along the bottom, plus the screens a trip opens into. The change touches one panel and adds one new surface; everything else is untouched.
Trips tab
Inside a trip changing here
Work window new
Today tab
Chat tab
Wallet tab
The chat tab already streams text as the model writes it. The trip side throws that away and waits for the finished answer. This change borrows behaviour that already works and puts it where the waiting actually happens.
Side by side
No words, no progress, no idea whether it is searching or stuck.
Starting Rome greys out Florence and Venice.
The app remembers exactly one request. A second one leaves the first answer with nowhere to come back to.
Lock the phone and you find out whenever you next open the app.
The work does keep running — but people wait on the screen rather than trusting it.
Headed Finding a place in Rome, 12–15 May, with the scout's own words arriving as it searches.
Each row's button reflects only its own city.
A small bar shows how many are going; tapping it reopens any of them.
A notification names the city. Come back later and the tray still holds anything unread.
Each result attaches to the city that asked for it.
Before — one lane, two held at the signal
After — three lanes, each finishing on its own
Honest limits
Acceptance
| Check | Passes when | Part |
|---|---|---|
| Three within ten seconds | Rome, Florence and Venice all start, all finish, each shortlist lands against the right city | core |
| No cross-locking | Starting one city never disables another city's button | core |
| Close and return | Closing mid-search then reopening shows the same text, still moving | core |
| Leave the trip entirely | Browsing other parts of the app and coming back finds the searches intact | core |
| Locked phone | Locking during a search still has the answer waiting on return | core |
| Notification lands | Where the platform allows it, finishing sends a notification naming the city; tapping opens that shortlist | second half |
| Nothing unread is lost | Two finish while away; both are still listed on return | core |
Your call
Choose one and copy the line — pasting it into the terminal is the whole handoff. Or ignore this and just say what you want; the page is here to make the choice concrete, not to be the only way to answer.
Standing practice
A before-and-after page, written the way a traveller would describe the change rather than the way it is built — and the page shows exactly what gets built. Not a description of the screen, not a picture of it: the screen itself, running, with the same words and the same behaviour that will ship. If it cannot be operated on the page, it is not specified well enough to build.
The page also ends where the work starts: pick an option, copy the line, paste it in the terminal. The argument happens on a page rather than in a branch, and the decision comes back as one sentence.