serfaandClaude Opus 5
7567aa4e75
A page to present this to a client. Left column is the real app in the phone frame — live, swipeable, the same deck and the same data, not a screenshot. Right column is what somebody needs in order to judge it: how to get in, what it does, what it is built on. Credentials, both sides - A one-sided demo of a two-sided marketplace shows half a product, so the panel carries a customer AND a tradesperson, each with a copy button. Reading a phone number off a screen into a form while a client watches is a small humiliation; mistyping one is a worse one. - dev-login grows from one pinned number to a named DEMO_ACCOUNTS list. The three guards are unchanged — not production, explicitly enabled, and the number must be on the list. Both accounts map to seeded users that already own jobs, conversations and a completed booking, so the screens have something in them rather than five empty states. - The page SAYS SO when sign-in is unavailable rather than letting somebody discover it mid-meeting. A fixed passcode is a login bypass and must never ship live; the honest fix for demoing against production is a real account and a real SMS, not a fourth flag. Content lives in arrays at the top of demo-panel, so adding a feature or swapping a dependency is one line and the layout is untouched. Four labelled placeholder slots — roadmap, pricing, metrics, case study — reserve the space and make it obvious what belongs where. A deliberate exception to DESIGN.md §1.0 and §4, which ban desktop layouts and marketing pages, and it is noted as one in the file. This is a frame around the running app for a laptop, not a product screen; the app inside is untouched and still mobile-only. Below `lg` the panel stacks under the phone, because a client who opens the link on their own phone should still be able to read it. Verified: both demo accounts complete the real OTP path end to end. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>