Treat time selection, request intake, confirmation, change, and cancellation as one intake structure

You are Codex. Build a production-shaped prototype called “予約受付魔法 / Booking Intake Spell” on Cloudflare.

Your job is not to write a concept page. Your job is to implement a working reservation intake system prototype that treats booking, confirmation, rescheduling, and cancellation as one unified intake flow.

Do not ask clarifying questions. Make sensible decisions and implement the full prototype end-to-end with clear code, comments, type safety, validation, and deployability.

Important execution constraints:
- Do not stop at scaffolding
- Do not output only plans
- Do not leave core routes unimplemented
- Do not replace real logic with mock JSON for the main booking flow
- Do not skip D1 migrations
- Do not skip tests
- Do not ask me for requirements already specified above
- If tradeoffs appear, choose the simplest path that still satisfies the acceptance criteria
- When finished, provide a short summary of architecture, routes, env vars, and local run/deploy steps

Project goal

Build a reusable booking intake system for reservations, interviews, visits, consultations, lessons, treatments, and similar appointment-based workflows.

The system must support:
1. public intake page
2. date/time selection
3. input form
4. availability check
5. provisional acceptance or confirmation
6. modification flow
7. cancellation flow
8. notification abstraction
9. optional waitlist-ready architecture
10. staff-only admin view

Core product concept

Treat booking, interview scheduling, treatment booking, lesson booking, visit booking, and consultation intake as the same parent structure:
- choose a date/time
- enter intake details
- validate against rules
- create booking record
- allow later reschedule/cancel
- keep all actions in one history thread
- do not separate notification from record history conceptually

Use the following framing in code comments and naming where helpful:
- Intake Familiar = validates input and intake rules
- Schedule Familiar = checks time, duration, staff/resource constraints
- Notification Familiar = sends confirmation, reschedule, cancellation messages

Fixed stack

Use this exact stack unless absolutely impossible:
- Frontend: React + Vite + TypeScript
- Styling: simple clean CSS or CSS Modules, no UI library required
- Backend API: Cloudflare Workers
- Database: Cloudflare D1
- Async jobs: Cloudflare Queues-ready abstraction, but for this prototype you may implement synchronous fallback and structure code so async delivery can be plugged in later
- Auth for admin: simple Cloudflare Access compatible header-based stub or lightweight password gate abstraction, so the admin route is clearly staff-only ready
- Email delivery abstraction: implement a provider interface and a development log provider by default
- Calendar integration abstraction: implement provider interface and a no-op/mock provider by default
- Validation: Zod
- Testing: Vitest for logic and validation at minimum
- Dates/times: use a robust approach and store timestamps in UTC, while displaying with local timezone support

Architecture

Use a monorepo or clean two-app structure inside one repository:
- apps/web = React public UI and admin UI
- apps/api = Cloudflare Worker API
- packages/shared = shared types, validation schemas, utilities

If you prefer a simpler layout, that is acceptable, but maintain clear separation between UI, API, and shared domain logic.

Functional requirements

1. Public booking flow

Build a public page where the user can:
- choose service type or intake category
- choose date
- see available time slots
- choose time slot
- enter required fields
- optionally enter attendee count
- optionally enter duration if service allows variable duration
- submit booking

The intake form should support these fields:
- name
- email
- phone optional
- booking type/category
- date
- start time
- duration minutes
- party size or attendee count
- note/message
- optional staff preference
- optional location or mode field such as in-person / phone / online
- consent checkbox if needed

2. Unified booking lifecycle

Every booking must have a lifecycle status such as:
- pending
- confirmed
- cancelled

Every booking must also keep an event history such as:
- created
- availability_checked
- confirmed
- rescheduled
- cancelled
- notification_sent
- notification_failed

Reschedule and cancel must operate on the same booking identity/history chain, not by silently replacing rows.

3. Availability model

Implement an availability model that can support:
- opening hours or bookable windows
- slot duration
- buffer before/after
- max concurrent bookings
- optional staff/resource constraint
- blackout/unavailable times
- lead time rules
- cutoff rules for same-day or late bookings

For this prototype:
- define one or more bookable services
- define weekly availability rules
- define blackout support
- define capacity support
- implement real slot generation
- reject invalid or conflicting bookings at API level

4. Modification and cancellation

Each booking must receive:
- a public booking reference
- a secure management token

Use the management token to allow a guest to:
- view booking details
- reschedule booking
- cancel booking

Build pages for:
- /manage/:reference?token=...
or similar

Reschedule flow must:
- re-check availability
- preserve history
- send notification through abstraction

Cancellation flow must:
- mark booking cancelled
- preserve history
- send notification through abstraction

5. Notifications

Implement a notification abstraction with provider interface:
- sendBookingCreated
- sendBookingConfirmed
- sendBookingRescheduled
- sendBookingCancelled

For development mode:
- implement a logging provider that writes payloads to console and optionally stores a notification log row in D1

Do not hardcode one email vendor deeply into domain logic.
Keep provider swappable.

6. Calendar integration abstraction

Implement a calendar provider interface with methods like:
- checkConflicts
- createEvent
- updateEvent
- cancelEvent

For this prototype:
- use a mock/no-op provider by default
- structure code so Google Calendar or another provider can be added later without domain rewrite

7. Admin UI

Build a staff-only admin area that can:
- list bookings
- filter by date/status/category
- inspect booking details
- inspect booking history
- manually confirm pending bookings if needed
- view notification log status
- view availability configuration summary

Do not overbuild. Keep it usable and clean.

8. Waitlist-ready design

You do not need to fully implement waitlist behavior, but the schema and domain design must allow future support for:
- no slot available -> waitlist request
- slot opens later -> re-notify candidate

Include TODO markers in appropriate places.

Domain rules

Use sensible default rules:
- bookings must be in the future
- bookings cannot be created inside cutoff window
- duration must match service constraints
- attendee count must be within service constraints
- selected slot must still be available at commit time
- reschedule cannot move cancelled booking
- cancel cannot cancel already cancelled booking
- public manage token must be required for guest self-service actions

Create at least 2 example services:
1. interview
2. consultation

Example defaults:
- interview: fixed 30 minutes, attendee count 1, weekdays only, morning-heavy slots
- consultation: fixed 60 minutes, attendee count 1 to 4, broader availability

You may include a third example such as visit or lesson if helpful.

Data model

Design and implement D1 schema for at least these tables:

services
- id
- slug
- name
- description
- duration_minutes_default
- duration_minutes_min nullable
- duration_minutes_max nullable
- attendee_min
- attendee_max
- requires_manual_confirmation boolean
- is_active
- created_at
- updated_at

availability_rules
- id
- service_id nullable if global
- weekday
- start_minute
- end_minute
- slot_interval_minutes
- buffer_before_minutes
- buffer_after_minutes
- capacity
- timezone
- is_active
- created_at
- updated_at

blackouts
- id
- service_id nullable
- starts_at
- ends_at
- reason
- created_at

bookings
- id
- reference_code
- manage_token_hash
- service_id
- status
- customer_name
- customer_email
- customer_phone nullable
- attendee_count
- requested_timezone
- starts_at
- ends_at
- note nullable
- preferred_staff nullable
- mode nullable
- created_at
- updated_at
- cancelled_at nullable

booking_events
- id
- booking_id
- event_type
- actor_type
- payload_json
- created_at

notification_logs
- id
- booking_id nullable
- notification_type
- provider
- recipient
- status
- payload_json
- error_message nullable
- created_at

If needed, add supporting tables for staff/resources later, but do not bloat the first prototype unnecessarily.

Security

Implement safe practices:
- validate all input with Zod
- never expose raw internal IDs publicly if avoidable
- store only hash of manage token, not plaintext token
- verify manage token securely
- protect admin API/routes with a clear auth middleware stub
- sanitize and bound all string inputs
- return clear but not oversharing error messages

API design

Implement JSON API endpoints roughly like:

Public:
GET /api/services
GET /api/availability?service=...&date=YYYY-MM-DD&timezone=...
POST /api/bookings
GET /api/bookings/manage/:reference?token=...
POST /api/bookings/manage/:reference/reschedule
POST /api/bookings/manage/:reference/cancel

Admin:
GET /api/admin/bookings
GET /api/admin/bookings/:reference
POST /api/admin/bookings/:reference/confirm
GET /api/admin/availability-summary

You may adjust naming, but preserve these capabilities.

Frontend pages

Build at least these pages:
- / = concise landing page for the prototype
- /book = intake entry
- /book/:serviceSlug optional deep-link service booking page
- /manage = management entry page where user pastes reference + token, or redirect helper
- /manage/:reference = booking detail/manage page
- /admin = admin bookings page
- /admin/bookings/:reference = admin booking detail page

UX requirements

The UI must be:
- clean
- responsive
- minimal
- professional
- legible on mobile
- not visually bloated

The booking flow should feel like:
Step 1. Choose service
Step 2. Choose date/time
Step 3. Enter details
Step 4. Review and submit
Step 5. Confirmation with management link

Reschedule/cancel screens should be simple and calm.

Copy can be bilingual-ready, but implementing English only is acceptable for the prototype as long as strings are centralized for later localization.
If you can support Japanese labels cleanly without slowing development, do so.

Seed/demo data

Seed D1 with:
- at least 2 services
- weekly availability rules
- 1 blackout example
- a few example bookings for admin testing

Developer experience

Provide:
- clear README
- local setup instructions
- D1 migration instructions
- Wrangler configuration
- sample .dev.vars or environment variable documentation
- scripts for dev, test, build, and deploy

Environment variables

Define and document environment variables for things like:
- BOOKING_BASE_URL
- ADMIN_SHARED_SECRET or equivalent stub
- NOTIFICATION_PROVIDER
- CALENDAR_PROVIDER
- DEFAULT_TIMEZONE

If needed for provider abstraction, include placeholders for:
- RESEND_API_KEY
- GOOGLE_CLIENT_EMAIL
- GOOGLE_PRIVATE_KEY
- GOOGLE_CALENDAR_ID

But keep the prototype runnable without external providers.

Implementation guidance

Prioritize correctness of booking logic over visual flourish.
Generate slot availability on the server, not only the client.
On booking creation, perform final conflict check inside the API write path.
Keep domain logic in reusable modules, not embedded directly in route handlers.
Write readable code. Avoid cleverness.

Tests

Add tests for at least:
- slot generation
- blackout exclusion
- capacity/conflict rejection
- booking creation validation
- reschedule validation
- cancellation rules
- manage token verification

Acceptance criteria

The prototype is considered complete only if all of the following are true:
1. A guest can open the public booking page
2. A guest can choose a valid slot
3. A guest can submit a booking
4. A booking record is stored in D1
5. A booking history trail is stored
6. A guest receives a management link/token in the response flow
7. A guest can use the management route to reschedule
8. A guest can use the management route to cancel
9. Availability is revalidated server-side during create/reschedule
10. Admin can list and inspect bookings
11. Notification abstraction exists and logs delivery attempts
12. Codebase is deployable to Cloudflare with documented steps
13. Tests run successfully

Output expectations

Produce the full codebase, not just snippets.

Also include:
- D1 schema/migrations
- seed script or seed SQL
- README
- example screenshots not required
- no placeholder “TODO app” skeletons for core flows

Tone and naming

Internally, you may use practical English naming in code.
In the README and landing page, describe the system as:
“予約受付魔法 / Booking Intake Spell”

On the landing page, reflect this product meaning:
- booking, interview, treatment, visit, lesson, and consultation intake handled in one structure
- date selection, input, confirmation, reschedule, and cancellation treated as one reception flow
- can later connect waitlist, reminder, prefill form, and notification extensions

Landing page content guideline

Create a concise landing page section structure inspired by the following ideas:
- What spell it is
- What it can do
- Why it is useful
- Spell structure
- Familiars
- Grimoires
- Reproduction conditions
- Verification status

Do not make this merely decorative. The actual working booking flow must exist and be linked from the landing page.

Final instruction

Implement this as if it is a reusable parent spell for future vertical-specific booking systems.
Favor extensibility, clarity, and operational realism over hype.
Ship a working Cloudflare-native prototype.