Scope
Revision 1 · Author: AYCD owner · Integrity label: req-rev1-demo-label (non-cryptographic demo label)
Goal
Let a prospective customer request a catering quote, correct mistakes safely, and follow their inquiry status — while AYCD shows the client exactly what was built, approved, and tested.
Audience: Prospective catering customers (demo) and the AYCD owner.
Customer journeys (3)
1. Request a catering quote
A valid inquiry submitted on mobile returns a unique reference and an honest confirmation that the system accepted it.
2. Correct mistakes and recover safely
Validation errors preserve valid work, and a lost response can be retried without creating duplicates.
3. Follow an inquiry through its status
The customer sees their inquiry's honest status and next step while another tenant's scope cannot access it.
Acceptance criteria
- [c1 · j1] The request-quote action opens an accessible form at desktop and mobile sizes.
- [c2 · j1] Valid synthetic data creates exactly one inquiry with the expected fields and a unique reference.
- [c3 · j1] The controlled demo outbox captures the confirmation payload with the matching reference.
- [c4 · j1] The confirmation screen states the inquiry is awaiting review and is not a confirmed booking, price quote, or real email delivery.
- [c5 · j2] Invalid email, unsupported guest count, or past date is rejected with clear field errors; valid values are preserved.
- [c6 · j2] A retry with the same operation id creates no duplicate inquiry or confirmation; the server enforces idempotency.
- [c7 · j2] An unknown outcome is never reported as definitely received or not received; safe recovery is offered.
- [c8 · j3] The customer can retrieve their inquiry by reference and see its current status and next step; refreshing preserves it in the demo store.
- [c9 · j3] Staff transitions follow allowed paths; invalid transitions are rejected; history preserves actor, time, and previous and new states.
- [c10 · j3] Another tenant's scope cannot read this tenant's inquiry (simulated in the demo; enforced server-side at the pilot gate).
- [c11 · policy] Evidence is current only when its build, manifest, and requirement revision match the release candidate; otherwise it is stale.
- [c12 · access] Only synthetic, clearly labeled demo data is collected; no real customer data is used.
Exclusions
- Real bookings, payments, or inventory commitments
- Real email delivery — the demo outbox only
- Dietary or allergy data (excluded from the demo form entirely)
- Browser-automation runs (Playwright/Chromium/Firefox/WebKit) — outstanding for the pilot
- Real client onboarding, tenant isolation at rest, and durable legal approvals (pilot gate)
- Live calendar booking integration
- AI agents acting in production, AI proof scores, or chatbots
Documented demo rules
- Contact name: 2–80 characters, trimmed
- Email: valid structure; example.com addresses only in demo fixtures
- Event date: not in the past and within 12 months, judged in the business timezone (America/Los_Angeles)
- Guest count: whole number between 10 and 150
- Event type: office_lunch, small_event, or other
- Notes: 500 characters maximum
- An inquiry is a quote request — not a confirmed booking, availability guarantee, or payment commitment
Business timezone: America/Los_Angeles. These are configurable fictional rules, not researched facts about a real caterer.