The problem
A production deploy goes out and, for a subset of users, the app quietly talks to staging because one base URL was never switched. Nothing looks wrong. Data writes to the wrong place for days. No visual or functional test will ever see this, because the page works, it just works against the wrong backend.
The idea
A customs check on outbound traffic. Every request gets inspected, and anything headed somewhere it should not go gets stopped at the gate.
What you will catch
- An assertion that no request hit staging, localhost or a debug host
- A release gate that fails the build on a misrouted environment
How it works
Every request URL is in the captured network log, including third party and background calls. You assert that none of them match the hosts that should never appear in production.
Run it now
kane-cli --tui
# then paste this objective:
Go to https://practicesoftwaretesting.com and browse a product category.
Assert: no network request was made to a staging, localhost or debug URL.Or one line, for CI or sharing
kane-cli run "Go to https://practicesoftwaretesting.com and browse a product category.
Assert: no network request was made to a staging, localhost or debug URL." --agentWhat prints
Example run. Your numbers will vary by site, build and run. The PASS / FAIL and the zeros are the stable result, the raw timings and counts are illustrative.
▶ navigate + browse category ok ▶ assert no staging/localhost calls 0 found ✓ PASS RESULT PASS exit 0 ~1m ~9 to 15 credits
Adapt it to your app
Go to <your production build> and complete <a representative flow>.
Assert: no network request was made to "staging", "localhost" or "<your debug host>".Why it works
The check reads request hosts from the captured log, so it catches calls the UI never surfaces, including third party scripts and background requests.
What it unlocks
A one line production release gate. Wire it into CI so a misrouted environment fails the build instead of reaching users.
