Demo key priority inverted, /demo-status kill switch, integration depth docs
Three threads around launching the public demo at mike.casemark.dev. The first fixes a fundamental flaw in the demo key resolution: the shared key was taking priority over personal keys, making it impossible for users to save their own. The second adds a `/demo-status` endpoint and a client-side gate that swaps the app for a landing page without a redeploy. The third documents what Case.dev services are actually wired vs. candidates for later.
The key priority fix is a two-line change in getEffectiveCaseApiKey(). The old order was: check demo key first, then user key. The new order is: check user key first, then demo key as fallback. The same commit removes the guards in saveCaseApiKey() and clearCaseApiKey() that threw errors in demo mode, so users can now save or clear a personal Case.dev key while Demo Mode is enabled. Clearing cleanly falls back to the shared demo key.
/demo-status returns { enabled, hosted_demo_configured, disabled_landing, budget_usd }. The disabled_landing field is true when MIKE_DEMO_CASE_API_KEY is configured but MIKE_DEMO_MODE=false. The frontend HostedDemoGate component polls this and swaps the entire app surface for a lightweight "demo paused" page when disabled_landing is true. Setting that env var in Vercel pauses the demo without touching code or triggering a redeploy.
The integration depth README section maps Case.dev primitives to their status: LLMs, Vault, Matters, Skills, and Legal Research are wired. Format/SuperDoc, Agents, Memory, Search, and Privilege Detection are labeled future candidates. The backend integration seams are called out explicitly: caseClient.ts, storage.ts, llm/index.ts, chatTools.ts, caseMatters.ts, and the routes modules.
Spotted something wrong? Or know the PR text has fresher detail than the writeup above?