# Clarifying Questions and Assumptions

## Clarifying Questions Register

| ID | Question | Default Assumption | Risk if Wrong | Affects |
| --- | --- | --- | --- | --- |
| Q1 | Is onboarding only for enquiries, or also early booking requests? | MVP handles enquiries only, with optional free-text mention of booking interest. | Data model or UI may need booking-specific fields later. | Data model, UI, backlog |
| Q2 | Are the only current roles public visitor and admin? | Yes, only public visitor and admin are in MVP. | Later role expansion may require auth redesign. | Data model, backlog |
| Q3 | Should enquiries capture pottery, knitting, or both? | Include an `interest_area` field with options: pottery, knitting, both, not sure. | If categories differ, reporting and form fields may change. | Data model, UI |
| Q4 | Do admins only review messages, or also reply in-system? | Admins review/manage status only; replying happens outside the system in MVP. | If in-system replies are required, more entities and UI are needed. | Data model, UI, backlog |
| Q5 | Is one admin account enough, or should multiple admins be supported? | Support multiple admin users in the data model, even if only one exists initially. | Single-admin-only design would constrain future use. | Data model, backlog |
| Q6 | What exact fields are required in the contact form? | Name, email, optional phone, interest area, subject, message, consent checkbox, CAPTCHA. | Missing required business fields may block usable enquiries. | Data model, UI |
| Q7 | Is CAPTCHA provider fixed or flexible? | Keep provider flexible; choose provider during implementation. | Provider-specific work may need redesign later. | UI, backlog |
| Q8 | Are attachments needed? | No attachments in MVP. | Adding attachments later affects storage, validation, and security. | Data model, UI, backlog |
| Q9 | Does admin need search, filter, and status tracking in MVP? | Yes for status filtering; text search is recommended but secondary. | Inbox may become hard to use if volume rises. | UI, backlog |
| Q10 | Are mobile-specific wireframes required? | Desktop-first wireframes with responsive/mobile notes are sufficient. | A later design pass may still be required for mobile specifics. | UI |
| Q11 | Should enquiries store consent to contact? | Yes, record a consent flag. | Missing consent tracking may create process or compliance issues. | Data model, UI |
| Q12 | Should spam attempts or CAPTCHA metadata be stored? | No, treat CAPTCHA as request-time validation only. | If abuse occurs, additional telemetry may be needed. | Backlog |
| Q13 | Should admin be able to mark messages as unread, in progress, resolved, or spam? | Yes, use a simple status lifecycle: `new`, `in_progress`, `resolved`, `spam`. | Limited status options may reduce dashboard usefulness. | Data model, UI |
| Q14 | Should the landing page be marketing-heavy or minimal? | Keep it simple: hero, trust/value, offerings summary, CTA to contact. | Over-designing may waste time in a two-week MVP. | UI, backlog |

## Working Assumptions

1. The onboarding MVP is an enquiry funnel, not a full booking system.
2. The public user journey ends at successful enquiry submission.
3. Only admin users log into the secure area.
4. Multiple admin users should be supportable even if the owner is the only initial user.
5. CAPTCHA is required on the public contact form.
6. Admins manage message status and notes, but do not send replies in-system.
7. Attachments are out of scope for MVP.
8. The business needs to distinguish interest in pottery, knitting, or both.
9. Desktop-first design with responsive behavior is acceptable for initial delivery.
10. The current repository has no implementation and these artefacts define the baseline.
