https://github.com/ohansemmanuel/matcha-flowers
https://github.com/ohansemmanuel/matcha-flowers
Last synced: 8 days ago
JSON representation
- Host: GitHub
- URL: https://github.com/ohansemmanuel/matcha-flowers
- Owner: ohansemmanuel
- Created: 2026-07-29T05:52:06.000Z (9 days ago)
- Default Branch: main
- Last Pushed: 2026-07-29T08:36:52.000Z (9 days ago)
- Last Synced: 2026-07-29T09:12:42.622Z (9 days ago)
- Language: TypeScript
- Homepage: https://matcha-flowers.vercel.app
- Size: 5.69 MB
- Stars: 0
- Watchers: 0
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# Matcha Flowers
A fictional flower shop, built to be tested.
Matcha Flowers exists so that Coldtea's agentic QA has a realistic target: a
storefront with a catalog, a cart, accounts and a real checkout, that can be
deliberately broken in a pull request so an agent has something true to find.
It is a demo product, not a Coldtea product, and it deliberately does not use
Coldtea's design system.
## Running it
```bash
nvm use # 22.19.0
npm install
npm run dev # http://localhost:3010
```
## Scripts
| Script | What it does |
| ------------------- | -------------------------- |
| `npm run dev` | Dev server on port 3010 |
| `npm run build` | Production build |
| `npm run start` | Serve the production build |
| `npm run lint` | ESLint |
| `npm run typecheck` | `tsc --noEmit` |
| `npm run format` | Prettier write |
## Stack
Next.js 16 (App Router), React 19, TypeScript, Tailwind v4. Upstash Redis backs
accounts, carts and orders; Stripe test mode backs payment. Photography is from
Unsplash and committed to `public/images` rather than hotlinked, so a QA run can
never fail on a third-party CDN. See `public/images/CREDITS.md`.
## Build phases
1. ~~Repo, scaffold, landing hero~~
2. ~~Storefront: catalog, filtering, product detail, cart~~
3. ~~Auth and checkout: accounts, delivery, Stripe, orders~~
4. ~~QA affordances: defect registry, reset endpoint, seeded account~~
5. Regression branches: one planted defect per PR
## Testing against it
**Seeded account.** `qa@matchaflowers.test` / `matcha-secret-1`. Signing up is
worth testing on its own, but most tests are about something else and should
not have to create an account to get there.
**Reset.** `npm run qa:reset` wipes accounts, baskets and orders and puts the
seeded account back. Pass a URL to target a deployment:
```bash
npm run qa:reset
npm run qa:reset -- https://matcha-flowers.vercel.app
```
It is a `POST /api/qa/reset` guarded by `DEMO_RESET_TOKEN`. The token is
required, never optional: the endpoint is destructive and ships to every
preview, so an unset token fails closed.
**What this deployment is.** `GET /api/qa/status` reports the payment provider,
commit and branch, so a result can be traced back to what produced it.
## Planted regressions
`main` is the control: correct, with no flags and no trace of the defects. A QA
run against it should find nothing.
Each defect lives on its own branch as a real code change, one per pull
request, so the preview deployment for that PR carries exactly one bug and the
diff an agent reports against is the actual cause. `docs/regressions.md` lists
the six, what the customer sees, where the change goes and how to reproduce it.
## Payment providers
`PAYMENT_PROVIDER` selects how the payment step behaves. It defaults to
`stripe` when `STRIPE_SECRET_KEY` is set, and `mock` otherwise.
- `stripe` renders real Stripe Elements. Card fields live in a cross-origin
iframe, which is the hardest surface in the app for a browser agent.
- `mock` renders an in-app card form with the same accept and decline
behaviour: `4242 4242 4242 4242` succeeds, `4000 0000 0000 0002` is declined.
Payment-focused tests should run against `stripe`. Tests that merely need to
reach an order confirmation should run against `mock`, so a flake in the iframe
cannot fail every one of them.
No webhook is involved. The PaymentIntent is created server-side from the
server's own recomputation of the basket, and verified by retrieving it on the
confirmation page, so each preview deployment needs no webhook registration.