QA Report: feat: update default URLs to use portless subdomains (PR #42)

[sortakool]

QA Report

PR: #42 — feat: update default URLs to use portless subdomains
Branch: feat/update-default-urls-portless-subdomains
Date: 2026-02-25
Verdict: ✅ PASS

All 7 Gherkin scenarios passed (13 individual test cases, 0 failures, 0 errors). Run duration: 608ms, 1 worker, 0 retries.

Gherkin Scenarios

Scenario	Result
Scenario 1: API CORS origin default is the portless web subdomain (AC #1)	✅ PASS
Scenario 2: Web API base URL default is the portless API subdomain (AC #2)	✅ PASS
Scenario 3: process.env.FRONTEND_URL override still works in API CORS config (AC #3)	✅ PASS
Scenario 4: process.env.NEXT_PUBLIC_API_URL override still works in web API client (AC #4)	✅ PASS
Scenario 5: No references to localhost:3000 remain in application source code (AC #5a)	✅ PASS
Scenario 6: No references to localhost:4000 remain in application source code (AC #5b)	✅ PASS
Scenario 7: Web app can successfully call the API health endpoint via portless (AC #6)	✅ PASS

Individual Test Breakdown

#	Test Name	Duration	Result
1	Scenario 1 › Given the file "apps/api/src/index.ts" exists	2ms	✅ PASS
2	Scenario 1 › Then the CORS origin fallback should be "http://virtual-agent.localhost:1355"	2ms	✅ PASS
3	Scenario 2 › Given the file "apps/web/src/lib/api.ts" exists	0ms	✅ PASS
4	Scenario 2 › Then the API base URL fallback should be "http://api.virtual-agent.localhost:1355"	0ms	✅ PASS
5	Scenario 3 › The CORS origin should read from "process.env.FRONTEND_URL"	0ms	✅ PASS
6	Scenario 3 › The CORS origin should fall back to portless URL when env var is not set	0ms	✅ PASS
7	Scenario 4 › The API base URL should read from "process.env.NEXT_PUBLIC_API_URL"	0ms	✅ PASS
8	Scenario 4 › The API base URL should fall back to portless URL when env var is not set	0ms	✅ PASS
9	Scenario 5 › Given the directory "apps" exists	0ms	✅ PASS
10	Scenario 5 › Then no file under "apps" should contain the string "localhost:3000"	11ms	✅ PASS
11	Scenario 6 › Given the directory "apps" exists	0ms	✅ PASS
12	Scenario 6 › Then no file under "apps" should contain the string "localhost:4000"	6ms	✅ PASS
13	Scenario 7 › API health endpoint returns 200 with {"status":"ok"} via portless subdomain	35ms	✅ PASS

Failures

None. All 13 tests passed on the first attempt (0 retries configured).

Screenshots

None captured. Playwright config uses screenshot: "only-on-failure" and all tests passed, so no screenshots were generated.

Notes

• Runtime Verification (Scenario 7): Makes a live HTTP request to http://api.virtual-agent.localhost:1355/health and asserts 200 + {"status":"ok"}. Proves end-to-end portless proxy routing works correctly.
• Static Analysis (Scenarios 1–6): Verifies exact fallback strings in source and confirms no legacy localhost:3000/localhost:4000 references remain under apps/.
• Pre-existing -- bug in dev scripts (Out of Scope): The bun run --filter '*' dev failure (/bin/sh: --: command not found) is a pre-existing bug tracked in Issue Update dev scripts in apps to use portless for port assignment #34 / PR feat: update dev scripts in apps to use portless for port assignment #40, not introduced by PR feat: update default URLs to use portless subdomains #42.
• CORS not verified at runtime: Minor gap — no cross-origin request test with Origin header. Acceptable for a string-replacement PR.
• No browser-level tests: All tests are filesystem assertions or raw HTTP calls. Appropriate since changes are URL config updates, not UI changes.

Full Playwright output

Running 13 tests using 1 worker
✓   1 .attractor/qa-report/gherkin.spec.ts:40:7 › Scenario 1: API CORS origin default is the portless web subdomain › Given the file "apps/api/src/index.ts" exists (2ms)

✓   2 .attractor/qa-report/gherkin.spec.ts:44:7 › Scenario 1: API CORS origin default is the portless web subdomain › Then the CORS origin fallback should be "http://virtual-agent.localhost:1355" (2ms)

✓   3 .attractor/qa-report/gherkin.spec.ts:55:7 › Scenario 2: Web API base URL default is the portless API subdomain › Given the file "apps/web/src/lib/api.ts" exists (0ms)

✓   4 .attractor/qa-report/gherkin.spec.ts:59:7 › Scenario 2: Web API base URL default is the portless API subdomain › Then the API base URL fallback should be "http://api.virtual-agent.localhost:1355" (0ms)

✓   5 .attractor/qa-report/gherkin.spec.ts:70:7 › Scenario 3: process.env.FRONTEND_URL override still works in the API CORS config › The CORS origin should read from "process.env.FRONTEND_URL" (0ms)

✓   6 .attractor/qa-report/gherkin.spec.ts:75:7 › Scenario 3: process.env.FRONTEND_URL override still works in the API CORS config › The CORS origin should fall back to "http://virtual-agent.localhost:1355" when the env var is not set (0ms)

✓   7 .attractor/qa-report/gherkin.spec.ts:88:7 › Scenario 4: process.env.NEXT_PUBLIC_API_URL override still works in the web API client › The API base URL should read from "process.env.NEXT_PUBLIC_API_URL" (0ms)

✓   8 .attractor/qa-report/gherkin.spec.ts:93:7 › Scenario 4: process.env.NEXT_PUBLIC_API_URL override still works in the web API client › The API base URL should fall back to "http://api.virtual-agent.localhost:1355" when the env var is not set (0ms)

✓   9 .attractor/qa-report/gherkin.spec.ts:106:7 › Scenario 5: No references to localhost:3000 remain in application source code › Given the directory "apps" exists (0ms)

✓  10 .attractor/qa-report/gherkin.spec.ts:110:7 › Scenario 5: No references to localhost:3000 remain in application source code › Then no file under "apps" should contain the string "localhost:3000" (11ms)

✓  11 .attractor/qa-report/gherkin.spec.ts:125:7 › Scenario 6: No references to localhost:4000 remain in application source code › Given the directory "apps" exists (0ms)

✓  12 .attractor/qa-report/gherkin.spec.ts:129:7 › Scenario 6: No references to localhost:4000 remain in application source code › Then no file under "apps" should contain the string "localhost:4000" (6ms)

✓  13 .attractor/qa-report/gherkin.spec.ts:144:7 › Scenario 7: Web app can successfully call the API health endpoint when both run via portless › When the web app makes a request to the API health endpoint at "http://api.virtual-agent.localhost:1355/health" Then the response status should be 200 and the body should contain '{"status":"ok"}' (35ms)
13 passed (608ms)