Migrate Travel workspace confirmation to dynamic route

[MelvinBot]

Explanation of Change

This migrates the Travel workspace confirmation route from the legacy static backTo-based pattern to the new dynamic route pattern, following the migrate-to-dynamic-route skill.

Why: dynamic routes derive their back destination from the active route at navigation time (via createDynamicRoute / useDynamicBackPath) instead of threading a backTo query param through the route, which is the direction the navigation system is moving for these flows.

What changed for TRAVEL_WORKSPACE_CONFIRMATION:

• src/ROUTES.ts — removed the static ROUTES.TRAVEL_WORKSPACE_CONFIRMATION (with its getUrlWithBackToParam builder) and added a DYNAMIC_ROUTES.TRAVEL_WORKSPACE_CONFIRMATION entry with path: 'workspace-confirmation' and entryScreens: [SCREENS.TRAVEL.DYNAMIC_UPGRADE].
• src/SCREENS.ts — renamed TRAVEL.WORKSPACE_CONFIRMATION → TRAVEL.DYNAMIC_WORKSPACE_CONFIRMATION (Dynamic_Travel_WorkspaceConfirmation).
• src/libs/Navigation/linkingConfig/config.ts — point the screen at DYNAMIC_ROUTES.TRAVEL_WORKSPACE_CONFIRMATION.path.
• src/libs/Navigation/types.ts — the screen param list entry is now undefined (no more backTo).
• src/libs/Navigation/AppNavigator/ModalStackNavigators/index.tsx — bind the screen to the renamed page component.
• src/pages/Travel/WorkspaceConfirmationForTravelPage.tsx → renamed to DynamicWorkspaceConfirmationForTravelPage.tsx; it now derives backPath with useDynamicBackPath instead of reading a backTo route prop.
• src/pages/Travel/DynamicTravelUpgrade.tsx — navigates via createDynamicRoute(DYNAMIC_ROUTES.TRAVEL_WORKSPACE_CONFIRMATION.path).
• config/eslint/eslint.seatbelt.tsv — moved the grandfathered no-unsafe-type-assertion entry to the renamed file path and decremented the ROUTES.ts getUrlWithBackToParam count by 1.

Scope note — remaining routes deferred

Issue #83867 lists 5 routes. Only TRAVEL_WORKSPACE_CONFIRMATION is migrated here because it is the only one that composes cleanly (no route params, single entry screen). The other 4 need follow-up work and are intentionally left out of this PR:

• TRAVEL_TRIP_SUMMARY and TRAVEL_TRIP_DETAILS (r/:reportID/trip/...): the reportID/transactionID are trip-specific and are not the entry screen's report, so the path does not compose as entry + suffix. These do not fit the dynamic-route pattern without further design.
• TRAVEL_WORKSPACE_ADDRESS and TRAVEL_VERIFY_ACCOUNT: carry a policyID/domain that collides with the DYNAMIC_DOMAIN_SELECTOR query param, and VERIFY_ACCOUNT participates in the OTP setTravelProvisioningNextStep stored-route chain — both require a path-param approach (like the TCS migration) and more careful handling.

Fixed Issues

$ #83867
PROPOSAL:

Tests

// TODO: The human co-author must fill out the tests you ran before marking this PR as "ready for review"
// Please describe what tests you performed that validates your changed worked.

• Verify that no errors appear in the JS console

Offline tests

// TODO: The human co-author must fill out the offline tests.

QA Steps

// TODO: The human co-author must fill out the QA tests you ran before marking this PR as "ready for review".

• Verify that no errors appear in the JS console

PR Author Checklist

• I linked the correct issue in the ### Fixed Issues section above
• I wrote clear testing steps that cover the changes made in this PR
• I followed proper code patterns (see Reviewing the code)
• I verified there are no console errors

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

[MelvinBot]

I created this PR from an upstream branch since I don't have push access to your fork.

To take ownership of this branch and be able to push updates, run:

git remote add upstream https://github.com/Expensify/App.git
git fetch upstream claude-migrateTravelWorkspaceConfirmationDynamicRoute
git checkout -b claude-migrateTravelWorkspaceConfirmationDynamicRoute upstream/claude-migrateTravelWorkspaceConfirmationDynamicRoute
git push -u origin claude-migrateTravelWorkspaceConfirmationDynamicRoute

Then you can close this PR and open a new one from your fork.

[codecov]

Codecov Report

✅ Changes either increased or maintained existing code coverage, great job!

Files with missing lines	Coverage Δ
src/SCREENS.ts	100.00% <ø> (ø)
...rc/components/ReportActionItem/TripDetailsView.tsx	56.00% <ø> (ø)
src/libs/Navigation/linkingConfig/config.ts	83.33% <ø> (+6.41%)	⬆️
src/pages/Travel/DynamicDomainSelectorPage.tsx	0.00% <ø> (ø)
src/pages/Travel/DynamicTravelUpgrade.tsx	0.00% <ø> (ø)
src/components/BookTravelButton.tsx	2.35% <0.00%> (ø)
...avel/DynamicWorkspaceConfirmationForTravelPage.tsx	0.00% <0.00%> (ø)
...es/Travel/DynamicWorkspaceAddressForTravelPage.tsx	0.00% <0.00%> (ø)
.../home/UpcomingTravelSection/UpcomingTravelItem.tsx	0.00% <0.00%> (ø)
src/pages/Travel/DynamicVerifyAccountPage.tsx	0.00% <0.00%> (ø)
... and 5 more
... and 61 files with indirect coverage changes

[MelvinBot]

I analyzed the checks on this PR — there's no failing check that requires a code fix.

The only red check is PR Author Checklist / checklist, which is a human task, not a CI gate. It fails for two reasons, neither fixable by a code push:

• The author-only Tests / Offline tests / QA Steps sections in the PR body are still unchecked // TODO placeholders — these must be filled out by the human co-author before marking the PR "Ready for review".
• The job couldn't verify MelvinBot's engineering membership (Could not verify engineering membership for MelvinBot), which is expected for a bot author.

Every real code-quality gate is green: typecheck (tsc), all 8 test jobs, Storybook, ESLint, Prettier, build, React Compiler, knip, and unused-styles all pass.

Note on local typecheck-tsgo (not a CI gate)

Running the faster, stricter typecheck-tsgo locally surfaces 10 TS2300: Duplicate identifier errors in src/libs/API/types.ts:1110-1116 (duplicated UPDATE_FINANCIAL_FORCE_* command entries). These are:

• Pre-existing on main — byte-identical at the same line numbers on main and this branch, and this PR does not touch API/types.ts.
• Not caught by the CI gate — CI validates with tsc (npm run typecheck), which passed. tsgo is documented as stricter than tsc.

So they are unrelated to this PR and out of scope here. They look like a leftover duplicate block worth cleaning up separately on main.

Bottom line: nothing to fix on this PR from a CI standpoint. The author just needs to complete the checklist sections in the PR body. (The two *-perf-tests checks are still running; they're non-blocking informational comparisons and a route rename won't meaningfully affect them.)

[huult]

@MelvinBot Please cherry-pick all commits from the 83867-migrate branch into this PR: https://github.com/huult/App/tree/83867-migrate

[MelvinBot]

🤖 Cherry-picked both commits from huult/App@83867-migrate onto this PR branch, preserving huult's authorship:

• e43d80b — migrate TRAVEL_WORKSPACE_ADDRESS
• c164b65 — migrate TRAVEL_VERIFY_ACCOUNT

Together with the existing TRAVEL_WORKSPACE_CONFIRMATION work, this now migrates 3 of the 5 routes from #83867.

Conflicts resolved

Both commits were based on an older main (before this PR's WORKSPACE_CONFIRMATION → dynamic migration), so they conflicted on the same Travel route blocks in src/ROUTES.ts, src/SCREENS.ts, src/libs/Navigation/types.ts, src/libs/Navigation/linkingConfig/config.ts, and ModalStackNavigators/index.tsx. The migrations are independent (different routes), so I kept this PR's DYNAMIC_WORKSPACE_CONFIRMATION changes and layered the WORKSPACE_ADDRESS / VERIFY_ACCOUNT migrations on top.

One follow-up commit I added (1cc381b)

The cherry-picked code introduced a new no-unsafe-type-assertion lint error that isn't in huult's branch's seatbelt, so it would have failed CI. I updated config/eslint/eslint.seatbelt.tsv:

• Decremented ROUTES.ts getUrlWithBackToParam count 127 → 125 (two static routes removed).
• Grandfathered the no-unsafe-type-assertion in DynamicWorkspaceAddressForTravelPage.tsx (the Navigation.getActiveRoute() as Route cast on line 39 — needed to store the current URL for post-OTP return; createDynamicRoute can't be used there as it would double the path). This matches the existing grandfathered assertions on the sibling DynamicWorkspaceConfirmationForTravelPage.tsx.

Verification

• typecheck-tsgo: no errors in any migrated file (only pre-existing unrelated react-map-gl / API/types.ts errors).
• lint on all changed files: passes.
• prettier: all changed files already formatted.

The two remaining routes from #83867 (TRAVEL_TRIP_SUMMARY, TRAVEL_TRIP_DETAILS) are still deferred per the PR description. Please fill out the Tests/QA sections and verify the flows before marking ready for review.

[huult]

@MelvinBot I just pushed a new commit (aa0c8fa). Please cherry-pick it into this PR.

[MelvinBot]

🤖 Cherry-picked aa0c8fa9bea6b6b508129339581485a108cd5557 into this PR.

This migrates TRAVEL_TRIP_SUMMARY and TRAVEL_TRIP_DETAILS to the dynamic-route pattern (the last 2 of the 5 routes in #83867).

What I did:

• Cherry-picked the commit, preserving huult's authorship.
• Resolved a conflict in src/ROUTES.ts (the only conflicting file): added both dynamic TRAVEL_TRIP_SUMMARY/TRAVEL_TRIP_DETAILS entries to DYNAMIC_ROUTES, and removed the old static blocks. The conflict arose because this PR had already migrated TRAVEL_WORKSPACE_CONFIRMATION in the same regions — both migrations are now preserved.
• Healed config/eslint/eslint.seatbelt.tsv (getUrlWithBackToParam count 125 → 123, since the 2 removed static routes dropped those deprecated usages) in a separate commit.

Checks:

• typecheck-tsgo: no new errors in the migrated files (only pre-existing, unrelated errors: missing react-map-gl types and duplicate identifiers in src/libs/API/types.ts).
• Lint (scripts/lint.sh): passed clean for all changed files.
• Prettier: src/ROUTES.ts conforms.

[huult]

@MelvinBot Please analyze this PR and generate test steps to verify the changes.

[MelvinBot]

🧪 Test steps to verify the changes

This PR migrates the remaining Travel routes from legacy static backTo-param routes to dynamic routes (issue #83867). Back navigation is now derived via useDynamicBackPath(...) instead of a backTo param, so the focus of testing is: (a) each screen still opens from every entry point, (b) the back button returns to the screen the user came from, and (c) deep links still resolve. The migrated screens are: Trip Summary, Trip Details, Workspace Confirmation, Workspace Address, and Verify Account.

ℹ️ Use a Travel-enabled account. Some flows require the IS_TRAVEL_VERIFIED beta to be off and a workspace without a saved address to fully exercise the verify-account / workspace-address path.

1. Trip Summary & Trip Details (read-only trip screens)

1. Open a chat/report that contains a travel reservation (a booked trip with multiple reservations).
2. In the expense/transaction view, tap the trip suitcase menu item (MoneyRequestView):
   • If the trip has more than one reservation → the Trip Summary screen opens (testID DynamicTripSummaryPage).
   • If it has a single reservation → the Trip Details screen opens directly (testID DynamicTripDetailsPage).
3. From Trip Summary, tap a reservation row → Trip Details opens.
4. On both screens, tap the back button and confirm you return to the originating report/expense view (not the LHN or a blank page).
5. From the Upcoming Travel section (home), tap an upcoming reservation → Trip Details opens, and back returns to the home view.
6. ✅ Verify there are no console errors and the screens are not stuck on the "not found" page.

2. Workspace Confirmation

1. Trigger the travel upgrade flow so the Travel Upgrade page is shown (DynamicTravelUpgrade).
2. Proceed to create a workspace → the Workspace Confirmation screen opens (testID DynamicWorkspaceConfirmationForTravelPage).
3. Tap back and confirm you return to the Travel Upgrade page (this back target is now derived, not passed as backTo).
4. Complete the confirmation and verify the workspace is created and the flow proceeds normally.

3. Verify Account & Workspace Address (provisioning flow)

This is the key regression area — these two screens previously round-tripped a backTo param through OTP validation.

1. As a user that is not yet validated (and with the IS_TRAVEL_VERIFIED beta off), tap Book Travel (BookTravelButton) from My Trips / Workspace Travel / Search.
2. Confirm the Verify Account screen opens. Enter the magic code to validate.
3. After validation, confirm you are routed to the correct next step:
   • If the workspace has no address → Workspace Address screen opens.
   • If it already has an address → the Terms (TCS) screen opens.
4. On the Workspace Address screen, submit a company address and confirm the flow continues (and, if you were unvalidated when submitting, that it re-routes through Verify Account and back).
5. Tap back on both Verify Account and Workspace Address and confirm you land on the previous screen in the flow, not a dead end.
6. Repeat the entry via the Domain Selector page (DynamicDomainSelectorPage) and confirm the same routing behavior.

4. Deep links (route paths changed)

Paste each URL directly into the browser address bar (replace placeholders) and confirm the correct screen loads:

• workspace-confirmation
• workspace-address/<domain>/<policyID>
• verify-account/<domain>/<policyID>
• r/<reportID>/trip/<transactionID> → Trip Summary
• r/<reportID>/trip/<transactionID>/<pnr>/<sequenceIndex> → Trip Details

Confirm each resolves to the right screen and the back button behaves sensibly (does not crash / does not loop).

5. Regression sweep

• ✅ No TypeScript or console errors when navigating any of the above.
• ✅ Back navigation never lands on a blank screen or the wrong page.
• ✅ Existing non-travel navigation is unaffected.

---

🤖 Generated by MelvinBot. These are suggested verification steps — the human-owned Tests/QA sections of the PR body should still be completed by the author/reviewer.

[huult]

@MelvinBot Please create mock Onyx data that I can paste into the console to test the TRAVEL_TRIP_SUMMARY case.

[MelvinBot]

Here's console-pasteable mock Onyx data for testing the TRAVEL_TRIP_SUMMARY case (DynamicTripSummaryPage).

How the page reads data

DynamicTripSummaryPage.tsx reads two Onyx keys and derives the reservations from them:

const [report] = useOnyx(`${ONYXKEYS.COLLECTION.REPORT}${route.params.reportID}`);
const [transaction] = useOnyx(`${ONYXKEYS.COLLECTION.TRANSACTION}${getNonEmptyStringOnyxID(route.params.transactionID)}`);
const reservationsData = TripReservationUtils.getReservationsFromTripReport(report, transaction ? [transaction] : []);

Because the mock report has no tripData.payload, getReservationsFromTripReport falls through to reading transaction.receipt.reservationList, so the reservations live on the transaction.

Mock data — paste into the browser console

const reportID = '8201746391052837';
const transactionID = '4925108637451029';

Onyx.merge(`report_${reportID}`, {
    reportID,
    reportName: 'Trip to New York',
    type: 'chat',
    chatType: 'trip-room',
});

Onyx.merge(`transactions_${transactionID}`, {
    transactionID,
    reportID,
    receipt: {
        reservationList: [
            {
                reservationID: 'RES-FLIGHT-001',
                type: 'flight',
                start: {
                    date: '2026-07-01T08:30:00',
                    longName: 'San Francisco International Airport',
                    shortName: 'SFO',
                    cityName: 'San Francisco',
                },
                end: {
                    date: '2026-07-01T17:00:00',
                    longName: 'John F. Kennedy International Airport',
                    shortName: 'JFK',
                    cityName: 'New York',
                },
                company: {longName: 'Delta Air Lines', shortName: 'DL'},
                confirmations: [{name: 'John Doe', value: 'ABC123'}],
                route: {airlineCode: 'DL', number: '1234', class: 'Economy'},
                numPassengers: 1,
                duration: 18000,
            },
            {
                reservationID: 'RES-HOTEL-001',
                type: 'hotel',
                start: {date: '2026-07-01T15:00:00', address: '123 Market St, New York, NY'},
                end: {date: '2026-07-05T11:00:00', address: '123 Market St, New York, NY'},
                confirmations: [{name: 'John Doe', value: 'HTL-998877'}],
                numberOfRooms: 1,
                roomClass: 'King Suite',
            },
        ],
    },
});

Then navigate to:

/r/8201746391052837/trip/4925108637451029

(TRAVEL_TRIP_SUMMARY is a dynamic route — trip/:transactionID appended to the REPORT entry screen r/:reportID, per ROUTES.ts.)

⚠️ Important caveat for web testing

The page wraps its content in a FullPageNotFoundView with:

shouldShow={reservationsData.length === 0 || !CONFIG.IS_HYBRID_APP}

On standalone web CONFIG.IS_HYBRID_APP is false, so !CONFIG.IS_HYBRID_APP is true and the page will always render the "Not found" view — even with valid mock data. To actually see the reservations render on web, temporarily relax that condition locally, e.g.:

shouldShow={reservationsData.length === 0}

In HybridApp builds (IS_HYBRID_APP === true) the mock data above renders the reservations directly with no code change.