The client was calling GET ${baseUrl}/flags/kill-switch which does
not exist on platform-service. The actual kill-switch endpoint lives
under /settings/kill-switch in the settings module (public, no auth
required). The bug was silently masked by the client's fail-open
behavior on non-OK responses, but it produced a 404 on every page
load for every consumer (NoteLett, MindLyst, ChronoMind, FlowMonk,
NomGap, PeakPulse, JarvisJr, LysnrAI, ActionTrail, EffoRise, Local
Memory GPT).
Discovery: running the deployed NoteLett docker stack against the
sibling platform-service, every page load triggered:
GET http://localhost:4003/api/flags/kill-switch?platform=web → 404
Confirmed by curl-ing both endpoints directly:
/api/flags/kill-switch → {"message":"Route GET:/api/flags/kill-switch not found"}
/api/settings/kill-switch → {"enabled":true,"disabled":false,"message":""}
Also adds the productId as a query param. The server route accepts
productId from the query string OR an x-product-id header — sending
both is harmless and improves debuggability when grepping logs.
Updated JSDoc and the corresponding test assertion. Test count
unchanged (6 passed).
Verified:
pnpm --filter @bytelyst/kill-switch-client test → 6/6 passed
pnpm --filter @bytelyst/kill-switch-client build → ok
curl /api/settings/kill-switch?productId=notelett → 200 with payload
7e08cce95f