# Build Specification ## 1. Brief Verdict PATCH — confidence HIGH. The business outcome and four primary capabilities are clear enough to shape a first slice, but roles, payment/refund rules, notification consent, document policy, migration, and measurable acceptance need owner decisions. ## 2. Outcome and Boundaries Outcome: let customers complete appointment and deposit tasks without staff email coordination while giving staff a controlled operations view. Confirmed in scope: appointment requests, document upload, reminders, Stripe deposit collection, staff admin view, mobile importance. UNKNOWN or not approved: automatic appointment confirmation, calendar provider, refund automation, document retention, legacy-user migration, WordPress replacement, exact launch date feasibility. ## 3. Requirement Ledger | ID | Requirement | State | Source | Owner | |---|---|---|---|---| | R1 | Customer submits appointment request | CONFIRMED | owner notes | product owner | | R2 | Customer uploads documents | CONFIRMED | owner notes | product owner/security | | R3 | System sends reminders | CONFIRMED outcome; channel UNKNOWN | owner notes | product owner | | R4 | Customer pays deposit via Stripe | CONFIRMED outcome; flow PROPOSED | owner notes | finance/product | | R5 | Staff manages requests in admin view | CONFIRMED; roles UNKNOWN | owner notes | operations | ## 4. Workflow Map Customer: sign in or verified link (DECISION) → request slot → receive pending state → staff confirms/declines → reminder is sent with consent → customer uploads required files → customer pays deposit under approved timing/refund policy. Failure states must cover unavailable slot, payment decline, oversized/unsafe file, reminder failure, and duplicate submission. ## 5. Data and Integration Contract Entities: customer, appointment request, file metadata, reminder consent/status, deposit/payment reference, staff action audit. Stripe is confirmed as a current invoicing provider but API capability and account access are UNKNOWN. Store payment references, not card data. Document storage, type/size limits, malware handling, retention, and deletion owner require decisions. ## 6. Proposed Acceptance Criteria - PROPOSED: Given a supported mobile viewport, when a customer submits a valid request, then a visible pending confirmation and unique reference appear without horizontal overflow. - PROPOSED: Given a failed Stripe deposit, the appointment is not marked paid and the customer receives a recoverable error without duplicate charge. - PROPOSED: Staff actions record actor, time, prior state, and new state. ## 7. Minimum Decision Set 1. Define customer/staff roles and access path. 2. Choose request versus real-time booking behavior. 3. Approve deposit timing, refund/cancellation rules, and payment owner. 4. Approve reminder channels, consent, timing, and failure escalation. 5. Approve document limits, storage, retention, and privacy owner. 6. Decide whether WordPress users/content migrate. ## 8. Delivery Slices A: roles plus appointment-request workflow. B: staff state management and audit. C: Stripe deposit flow. D: reminders and document controls. Each slice exits only with approved acceptance evidence; no duration is invented. ## 9. Approval Checklist Resolve decisions 1–6, name integration owners, approve proposed acceptance criteria, and confirm the authoritative November target before implementation.