feat(e2e): API upgrade integration — all domains migrated to @gusto/embedded-api-v-2025-11-15

[jeffredodd]

Summary

Integration branch that combines:

• PR feat(e2e): scenario schema + driven E2E infrastructure #1829 (e2e/infrastructure) — scenario schema + driven E2E infrastructure, plus the API upgrade work (install @gusto/embedded-api-v-2025-11-15@0.0.1 alongside the old package; migrate ApiProvider / contexts / hooks / Common / Base / mocks / build script; bulk-swap component imports across all domains; apply schema-breaking fixes for autoPilot -> autoPayroll, paymentType enum lowercasing, and useDataView<T> generics)
• PR feat: payroll domain — scenarios + spec rewrites #1830 (e2e/payroll-domain) — Payroll scenario specs
• PR feat(e2e): employee domain — scenarios + spec rewrites #1832 (e2e/employee-domain) — Employee scenario specs
• PR feat(e2e): contractor domain — scenarios + spec rewrites #1833 (e2e/contractor-domain) — Contractor scenario specs
• PR feat(e2e): time-off domain — scenario + spec rewrite #1834 (e2e/timeoff-domain) — Time off scenario specs
• PR feat(e2e): dismissal domain — scenario + spec rewrite #1835 (e2e/dismissal-domain) — Dismissal scenario specs
• PR feat(e2e): company domain — scenario + spec rewrite #1836 (e2e/company-domain) — Company scenario specs
• New: information-requests flow registered in e2e/main.tsx + MSW-backed Playwright spec at e2e/tests/information-requests/information-requests-flow.spec.ts
• Fix: deriveEndpointInventory.ts regex literals (escaped slashes the earlier sed swap missed) — script now reports the expected 75 blocks / 9 flows

Why this branch

Per-domain stacking on top of an upgraded infra branch doesn't actually isolate regression: any domain still importing the old package can't read context from the migrated ApiProvider. Validating the upgrade requires the entire union of changes running together. This branch is that union, with all 2,593 unit tests passing and the build emitting the same endpoint-inventory shape as the reference upgrade PR (#1814).

Test plan

• npm install succeeds with both packages installed
• npm run test -- --run — 2,593 passing, 1 expected fail
• npm run build succeeds; endpoints:derive reports 75 blocks / 9 flows
• CI: full Playwright suite passes (Payroll, Company, Employee, Contractor, Time Off, Dismissal, Information Requests)
• Manual spot-check in Storybook: PayrollOverview, RecoveryCasesList, PayScheduleList, DeductionsList, InformationRequestList
• E2E run against the new API version (when local env is available)

Notes

• The old @gusto/embedded-api@0.13.0 is still installed alongside the new package; a follow-up cleanup PR removes it once this lands.
• CHANGELOG entries intentionally not retroactively renamed; only forward-looking docs and source were updated.

Made with Cursor

[jeffredodd]

Changes below this comment are for the API upgrade to 11-15-2025

[boostsecurity-io-ai]

⚠️  1 New Security Finding

The latest commit contains 1 new security finding.

Findings Note: 1 finding is displayed as an inline comment.

Not a finding? Ignore it by adding a comment on the line with just the word noboost.

Scanner: boostsecurity - Semgrep

[boostsecurity-io-ai]

CWE-918: Server-Side Request Forgery (SSRF)
Original Rule ID: rules_lgpl_javascript_ssrf_rule-node-ssrf

Details

The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.

This rule detected user-controlled URLs being passed to Node.js HTTP client
libraries including axios.get(), axios.post(), fetch(), http.get(),
http.request(), needle(), request(), urllib.request(),
superagent.get(), bent(), got.get(), net.connect(), and
socket.io-client.io(). When user input controls the destination URL of HTTP
requests without validation, Server-Side Request Forgery (SSRF) vulnerabilities
arise. SSRF allows attackers to force the server to make requests to internal
systems, cloud metadata endpoints (such as 169.254.169.254), or other
unauthorized destinations. This can expose internal APIs, databases,
administrative panels, or enable network scanning and pivoting attacks that
bypass firewall rules and network segmentation.
 📘 Learn More

AI Remediation

An allowlist check and protocol validation were added before performing the fetch request to ensure that only trusted origins and HTTP/HTTPS schemes are permitted, preventing user-controlled SSRF (Server-Side Request Forgery) attacks. This addresses the vulnerability by blocking requests to unauthorized or potentially malicious destinations.

At line 69, do the following changes:

   companyId: string,
 ): Promise<boolean> {
   try {
+    // SSRF protection: Allowlist hostnames and validate scheme before requesting
+    const allowedOrigins = [
+      'https://gws-flows.example.com',
+      'http://localhost:3000',
+    ];
+    const url = new URL(`${gwsFlowsBase}/fe_sdk/${flowToken}/v1/companies/${companyId}/locations`);
+    if (!allowedOrigins.some(origin => url.origin === origin)) {
+      throw new Error('Disallowed SSRF destination');
+    }
+    if (!['http:', 'https:'].includes(url.protocol)) {
+      throw new Error('Invalid protocol for SSRF protection');
+    }
     const response = await fetch(
-      `${gwsFlowsBase}/fe_sdk/${flowToken}/v1/companies/${companyId}/locations`,
+      url.toString(),
       { signal: AbortSignal.timeout(5000) },
     )
     return response.ok

[gusto-fresh-eyes]

Fresh Eyes Review

Found 8 issues in this PR.

PR Description Issues

• Minor | [fresh_eyes]: description-check: Description claims '2,593 passing, 1 expected fail' but does not explain what the expected failure is or link to a tracking issue for it. Reviewers cannot distinguish an intentional skip from a regression without this context.

Info (4)

• description-check: PR modifies 110 files which is well above the 500-line threshold for large PRs. The description explains why this must be a single integration branch (API upgrade requires all domains to migrate together), which is reasonable, but reviewers should be aware of the scope.
• 🔵 Info | [fresh_eyes]: logic-errors | build/deriveEndpointInventory.ts:L503-L506
blockDirToName is a Map<string, string> that overwrites when multiple blocks share the same componentDir (last one wins). The map is passed to deriveFlowBlocks but never actually read inside that function (it uses dirToBlocks instead). Unused parameter — no runtime impact currently, but the overwrite behavior is a latent bug if this map is referenced in the future.
• 🔵 Info | error-handling | e2e/main.tsx:L191
  Floating promise: startApp() is called without a .catch() handler. If MSW worker initialization throws (e.g., service worker registration fails), the error will be an unhandled promise rejection with no visible feedback in the test harness.
• 🔵 Info | [fresh_eyes]: code-duplication | e2e/tests/payroll/regular-payroll.spec.ts:L51-L52
  Blocker-detection regex already drifting: 5 payroll specs use /blocker|action.*required|complete.*setup/i but this file uses /blocker|action.*required|complete.*setup|view.*blocker/i (extra alternative). If the blocker surface text changes, 6 specs need updating independently. Consider extracting a shared locator constant like PAYROLL_BLOCKER_SURFACE_PATTERN.

Download findings.json — drag the file into Claude or use /add to propose fixes

---

^{Please 👍🏽 👎🏽 if you found this useful. Generated by Fresh Eyes Reviewer. Get help in #ai-code-reviews}