readme-value-and-prooflisted

# README: value proposition + visual proof Make a README that (1) tells a willing user *why this exists, what they get, and what it is not yet*, and (2) **proves** the working parts with screenshots captured from the actually-running app. Two halves: the honest pitch, and the real proof. Both must be true. ## Core principles (don't skip) - **Honest, not hype.** State what's near-turnkey AND what it is *not* yet (gaps, maturity, "scaffolded vs delivered"). Avoid "production-ready", "seamless", "blazing-fast", "MISSION ACCOMPLISHED", and similar. A clear-eyed pitch builds more trust than a glossy one. - **Proof must be real.** Every screenshot shows the feature *actually working*, captured from a running stack — never a mockup, never a staged/edited shot. If a dependency is down or a feature errors during capture, **investigate, fix or document it, and recapture** — do not ship a misleading image. (A capture run that surfaces a real bug is a feature of this process, not a detour.) - **Verify before you commit.** Confirm image paths resolve and the README reads top-to-bottom for the target audience. - **Capture against synthetic data, not a live account.** A committed screenshot ships whatever was on screen into a usually-public README. "Real data over lorem ipsum" means *realistic-looking* — seeded/synthetic content that reads as genuine — never a live account's actual user/client content. Before committing, read every screenshot for leaked tokens/ide