A nutrition app searching USDA FoodData Central with the common dataType filter (Foundation, SR Legacy, Branded) cannot find homemade/as-eaten mixed dishes ("lasagna with meat", "beef stew") — those live only in the "Survey (FNDDS)" dataset. Naively adding it breaks two more ways: (1) GET URLs containing the parentheses in "Survey (FNDDS)" get intermittent 400 Bad Request responses from USDA's nginx (the same URL can return 200 then 400), and (2) even when the request succeeds, exact-name Branded rows flood USDA's top-N relevance (e.g. fifteen "BEEF STEW" products), so FNDDS entries never surface for some queries while appearing fine for others.

A user wants a web app or PWA to track their location continuously ("know where I am all day"), but a browser can only read geolocation while the page is open and in the foreground. There is no background geolocation for websites or PWAs (especially iOS Safari) — the moment the tab is backgrounded or closed, tracking stops. Overpromising always-on tracking in a web app produces a broken, dishonest feature.

Push notifications published to ntfy.sh with a "Priority: urgent" (or high) header are delivered to the iOS app's message list but never produce a banner, sound, or badge — the phone stays silent. Messages published with default priority from the same topic banner normally, which makes the failure look like a subscription or permission problem and wastes debugging time on the wrong layer.

Browser gets Google's "unusual traffic" reCAPTCHA page constantly (plus the benign f.txt download side effect) even though the browser config looks fine. Easy to misdiagnose as extensions, VPN, or carrier CGNAT when the real cause is the user's own scheduled scrapers (e.g. Google Trends via pytrends, headless Playwright jobs) hitting Google from the same IP, poisoning its reputation for interactive browsing too.

When integrating Apple Music via MusicKit JS, the music_user_token returned by authorize() is NOT stable across sessions. It changes when the user re-authorizes from a different device or after token expiry. Unlike Spotify/Google OAuth which provide a stable user ID (spotify_id, google_id), Apple Music's MusicKit JS does not expose any stable user identifier. Hashing the token to create a user ID causes duplicate account creation on every re-login.

When an SQLAlchemy model has a @property (like image_url derived from a JSON column), using it in queries like Artist.image_url.isnot(None) fails with 'property object has no attribute isnot'. This is because Python @property objects are not SQLAlchemy Column objects and lack query methods.

Astro dev server silently moves to the next available port (4322, 4323...) when the default port 4321 is occupied by a stale process. No error is shown. Any service depending on a fixed port (like an MCP server pointing at localhost:4321) breaks silently because it reaches the old stale instance instead of the new one.

MCP server configured in ~/.claude/settings.json under mcpServers is silently ignored. The MCP tools never appear in the session toolset. No error is shown — the server simply does not load. Hooks referencing the MCP tools fire warnings but can never be satisfied because the tools do not exist.

React throws 'Hydration failed because the initial UI does not match what was rendered on the server' or 'Text content does not match. Server: X Client: Y' when using SSR frameworks (Next.js, Remix, Gatsby). This happens when the HTML generated on the server differs from what React generates on the first client-side render. Common triggers: (1) Using Date.now() or new Date() in render — different timestamps on server vs client. (2) Accessing window, document, localStorage, navigator — these don't exist on the server. (3) Conditional rendering based on browser state (window.innerWidth, matchMedia). (4) Random IDs or Math.random() in render output. (5) Browser extensions that modify the DOM before React hydrates. (6) Using typeof window !== 'undefined' incorrectly in render. (7) Different locale/timezone between server and client.

When trying to screenshot, test, or automate interactions with a local HTML file via Playwright (including Playwright MCP), navigating to file:// URLs fails with a security error or the page loads blank. This affects: taking screenshots of locally-built HTML files for previews, running E2E tests against local static files, using Playwright MCP tools (browser_navigate) to view local content, automating form interactions on local HTML prototypes, and generating PDFs from local HTML. The error manifests differently depending on the context: Playwright MCP silently redirects or blocks, Playwright test framework may show 'net::ERR_ACCESS_DENIED', and headless Chrome blocks file:// by default. This also affects Puppeteer with the same underlying Chromium restrictions.