Verdict
"The live demo already exists" is now verified, not just credible. It survives a cold machine, a fresh database and a stranger driving it. The one thing that broke is a config file, not the product.
Every step of the tour was driven in a real browser against a fresh clone at the reviewed
commit, on a Mac that had no Postgres at all an hour earlier. The RED verdict, the Venue Pack
and the contract flow all behaved exactly as the README promises. The single failure, placeholder
Stripe keys crashing the booking, was worked around by blanking three .env lines.
No code was changed.
The claim this run resolves
Row from the round-2 review's claims table, left open because that audit machine had no Postgres.
| Claim | Round-2 status (14 July) | This run (15 July) |
|---|---|---|
| "The live demo already exists", 3-minute quickstart | PARTLY CHECKED "credible but unprobed by us. Run it on the M5 before the call if time allows." | VERIFIED END TO END with one caveat: the shipped .env.example breaks the Book step until its Stripe placeholders are blanked (see What broke). |
Setup timing, measured
README "Getting started (for Kenn)" followed exactly, each step timed by wall clock on the M5.
| Step | Command | Time |
|---|---|---|
| Prerequisite | brew install postgresql@16 && brew services start postgresql@16 (machine had no Postgres at all) | 7s |
| Clone | gh repo clone ElmsPark/soundcheck | 3s |
| Env | cp .env.example .env + set DATABASE_URL to the local Mac user | <1s |
| Database | createdb soundcheck (with the README's keg-only path prefix, which it correctly documents) | 1s |
| Dependencies | npm install (warm npm cache on this machine; first-ever run would add a minute or two) | 4s |
| Schema | npm run db:migrate | 2s |
| Seed | npm run db:seed → "Seeded 6 acts, 4 reviews, 2 venues" | <1s |
| Dev server | npm run dev → "Ready in 1772ms", homepage 200 | ~3s |
Total: roughly 14 seconds of actual work against the README's "about 3 minutes". The claim holds with an order of magnitude to spare; even a cold npm cache would keep it comfortably under. Raw log:
STEP:env-setup:SECONDS:0:EXIT:0 STEP:createdb:SECONDS:1:EXIT:0 STEP:npm-install:SECONDS:4:EXIT:0 STEP:db-migrate:SECONDS:2:EXIT:0 "Your database is now in sync with your schema." STEP:db-seed:SECONDS:0:EXIT:0 "Seeded 6 acts, 4 reviews, 2 venues."
The 2-minute tour, step by step
Chrome first, then Playwright for the scripted proof pass. Fresh seed, demo logins from the README.
1 · Search a Saturday WORKS
Saturday 1 August 2026 + postcode SW1A 1AA returned "4 bands available". That is the right number: the seed books two of the six acts out on that exact date, and both were correctly hidden. Every card shows an all-in price including travel and VAT, so "no get a quote" holds.
2 · Open the act WORKS
The Velvet Kings: 5.0 stars from 2 booking-verified reviews, PLI £10m / PAT / ID badges,
a 16-Saturday availability grid, and the full price breakdown (£1,450 fee + £1.80 travel
for 4 miles + £290.36 VAT = £1,742.16, deposit £348.43). One cosmetic catch: genres
render as raw enums here (SOUL_MOTOWN, FUNK_DISCO) while the search cards prettify them.
3 · Book as Chloe with the mock provider BROKE AS SHIPPED WORKS AFTER ENV FIX
First attempt on the untouched .env: the Book button returned a 500,
"Invalid API Key provided: sk_test_...". Details in What broke. After blanking
the three Stripe lines (the built-in mock provider then engages, exactly as the file's own comment
says), booking SC-2026-0005 confirmed instantly: deposit £348.43 "payment protected", contract
auto-generated with the correct figures, availability flipped to booked.
4 · Sign the contract, both sides WORKS
Signed as Chloe, then signed in as hello@thevelvetkings.co.uk and signed as the act.
Status walked sent → client signed → fully signed, and the booking advanced to
CONTRACT_SIGNED. The act's dashboard shows budget, venue and their own £1,306.80 payout up
front, with the £145 platform commission disclosed.
5 · The tokenised venue link WORKS
The booking page surfaces the outreach link (/venue/721f66...f334e) because email
sending is still mocked. Opened in a fresh browser profile with no cookies: the form loads without
any login, greets you as The Verification Rooms, and says who you are helping and when. Exactly 16
inputs, as the round-2 review counted.
Demo-script note: the venue postcode you type at booking must not be one of the two seeded venues. Book with SW1A 1AA itself and the app reuses that venue's already-confirmed setup from the Venue Database (a feature, the caching moat, but it skips the outreach link this tour needs). I used a new venue at SW1A 2AA.
6 · Submit an 85 dB limiter WORKS
On submit the venue sees a thank-you that already contains the plain-English readout and "Readiness: RED (1 note flagged to the act)". The readiness engine recomputed for the booking immediately.
7 · RED verdict + Venue Pack WORKS, VERBATIM
Back as Chloe: the dashboard row flips to a red "Venue: problem to fix" chip while the older demo bookings stay green "Venue ready". The booking page carries the same chip plus the specific flag: "Limiter at 85 dB will not allow this band's live drums. Electronic-kit line-up or a different venue needed." The Venue Pack shows the no-live-drums readout word for word: "85 dB, A-weighted. Live drums not advisable. Electronic kit or cajon line-ups recommended. Reset authority: Sarah (duty manager), 07700 900123."
Database ground truth after the tour:
reference | status | venueReadiness | contract | client_signed | act_signed --------------+-----------------+----------------+--------------+---------------+------------ SC-2026-0005 | CONTRACT_SIGNED | RED | FULLY_SIGNED | t | t name | confirmation | confirmedBy | thresholdDb | verdict ------------------------+--------------+--------------+-------------+--------------------- The Verification Rooms | CONFIRMED | Vera Manager | 85 | ELECTRONIC_KIT_ONLY
What broke
One real blocker, one review finding demonstrated live, two small frictions. No code was touched; this was a verification-only run.
BLOCKER Shipped .env placeholders crash the Book step
The README says the mock provider needs nothing, and its only .env instruction is to
set DATABASE_URL. But .env.example ships the Stripe lines as literal
placeholders (STRIPE_SECRET_KEY="sk_test_..."), and
src/server/payments/index.ts treats any non-empty key as "use real Stripe".
So the copied file sends the placeholder to Stripe's live API and the booking submit dies:
POST /book/cmrlokxz4... 500 in 112ms
⨯ Internal error: Error: Invalid API Key provided: sk_test_...
at ...StripeAPIError... (node_modules/stripe/esm/RequestSender.js:100:31)
Workaround used (config only): set the three STRIPE_* lines to "",
restart the dev server. The file's own comment says blank means mock; the shipped values just are not blank.
Suggested fix for the repo (not applied here): ship the three lines empty in
.env.example, or have paymentsProvider() treat the literal
sk_test_... placeholder as unset. Either is a one-line change and makes the README true.
REVIEW FINDING F7, SEEN LIVE The failed booking leaked a HELD date
The booking transaction commits before the Stripe call, so the crash left booking SC-2026-0005 stuck at AWAITING_PAYMENT and The Velvet Kings' 1 August slot HELD, on the very first attempt. Nobody could book that date any more and nothing cleans it up; I had to reseed. That is the round-2 review's F7 (abandoned checkouts leak HELD dates forever) happening in practice, and it will bite real Stripe-test demos too, any time a checkout is abandoned or fails.
name | date | status
-------------------+------------+-----------
The Velvet Kings | 2026-08-01 | HELD ← leaked by the failed submit
FRICTION Booking details typed before sign-in are discarded
Fill the booking form signed out and the banner says "Your details and price are kept exactly as shown". They are not: the sign-in round-trip returns you to the form with venue name, postcode and guest count blank (the redirect only preserves act and date). Retype and it works. Either preserve the fields or soften the banner.
COSMETIC Raw genre enums on the act page
The act page header shows SOUL_MOTOWN, FUNK_DISCO where the search cards show
"Soul / Motown". Ten-minute fix, worth doing before anyone screenshots the act page.
For the call
- The demo claim stands. Say it with confidence: fresh machine to working marketplace in a quarter of a minute, and the differentiator (Venue Intelligence catching an 85 dB limiter against a five-piece) demonstrably fires, end to end, at the reviewed commit.
- One-line fix before anyone else clones it. Blank the Stripe placeholders in
.env.example(or placeholder-guardpaymentsProvider()). Right now the README's happy path fails at the exact moment a first-time viewer clicks Book. - Demo-script tips. Use the seeded Saturday (1 August 2026) so the availability filtering shows; give the booking a venue postcode that is not SW1A 1AA or GL54 1AA so the tokenised outreach link appears; keep the intake form to one problem (the 85 dB limiter) so the RED flag reads clean.
- F7 moved from theory to observed. The HELD-date leak happened on this run's first failed booking. Worth pulling forward in the fix queue since any real Stripe checkout that gets abandoned does the same thing.