Can a prompt replace Zencal?

Build a booking system where a meeting type can require payment before it is confirmed.

Calendar: connect one Google Calendar over OAuth with encrypted refresh tokens. Availability from working hours minus busy events, with buffers, minimum notice and a booking horizon. All arithmetic in UTC, rendered in the visitor's time zone with the zone named on screen.

Meeting types: name, duration, location, buffers, questions asked at booking, and an optional price with a currency.

The paid booking flow, which is the point of this build. A reservation moves through explicit states and every transition must be handled:

1. **Held** — created when the visitor chooses a slot and proceeds to checkout, with an expiry a few minutes out. A held slot is unavailable to everyone else. Create it in a transaction with a uniqueness constraint on the meeting type and start time, so two simultaneous visitors cannot both hold it; the loser is told the slot just went and is offered the next one.
2. **Pending payment** — a Stripe Checkout session created server-side against the held reservation, with the reservation id in the metadata and an idempotency key.
3. **Confirmed** — on `checkout.session.completed`, verified by signature and checked for prior processing, the reservation is confirmed, the calendar event created, and confirmation emails sent. Never confirm on the success redirect; the visitor may close the tab and the redirect may never fire.
4. **Expired** — a scheduled job releases holds past their expiry. Before releasing, re-check Stripe for a completed session against that reservation, because a webhook can arrive late and releasing a paid slot is the worst outcome in the system.

Also handle: a payment completed for a reservation that already expired and was released — refund automatically and email the visitor an explanation rather than silently keeping the money; and `checkout.session.expired`, which releases the hold immediately rather than waiting for the timer.

Write a test for each of those six paths. This is the whole reason the entry exists and it is where a homegrown booking-with-payment system goes wrong.

Refunds and cancellation: a cancellation policy per meeting type (a window within which a refund is automatic), a signed cancel link in the confirmation email needing no account, and refunds issued through Stripe with the calendar event deleted and the slot returned to availability.

Unpaid meeting types use the same reservation flow without the payment states, so there is one code path rather than two.

Also build: reminder emails at a configurable interval with the send recorded so a restart cannot double-send, an admin booking list showing state and payment status, and an audit log of every state transition.

Out of scope: Microsoft and Apple calendars, team round-robin, routing forms, CRM integration, and any hosted multi-tenant deployment.