BookSyr testing & module usage guide

Serious customers. Confirmed bookings.

How to use this guide

Start with PART 0 for the UI map, then PART 0B for location, fast onboarding, Explore, and SEO. QA testers execute Parts 3–5 and 14–17. Vendors and admins use Parts 0, 0B, 2, 15, and 20 as operating manuals.

PART 0 — UI & Navigation (2026 polish)

BookSyr uses a shared design system (PageHeader, StatCard, ChartCard, AttentionItem). Charts support hover tooltips with exact values on bars and line dots.

Vendor dashboard — /dashboard

Always visible (brief operational view):

• Greeting + date context
• One-line Syr highlight (Pro) when something needs action
• Today at a glance — 4 KPIs: revenue today, bookings today, outstanding, wallet
• Needs attention — up to 3 actionable items
• Today's schedule + Orders due soon (side by side)
• Booking link + WhatsApp share

Expandable sections (tap + to open):

• Trends & analytics — 7-day revenue/booking charts (hover for values), secondary KPIs, link to full Analytics
• Syr intelligence (Pro) — briefing, finance, customers, ops, growth, Ask Syr

Sidebar nav: Home · Analytics (Pro) · Schedule (Pro) · Orders (Pro) · Offerings · Customers (Pro) · Availability · Billing · Wallet · Marketing · Profile

Vendor analytics — /dashboard/analytics (Pro)

Vendor wallet — /dashboard/wallet

• Balance cards: Available, Pending, Total earned, Paid out
• Transaction history with friendly types (Deposit received, Balance received, Platform fee, Payout, Refund)
• Mobile: card layout · Desktop: table with sticky header
• Filters: All · Income · Fees · Refunds · Payouts · Pending · CSV export
• Historical payment backfill runs after the page renders, in batches of 20, and skips already-posted rows

Vendor marketing kit — /dashboard/marketing

• Live preview with vendor logo (from Profile → Edit profile), branded QR (BookSyr mark centred — still scannable), print-safe URL booksyr.online/v/{slug}
• What to post sidebar — channel, format, timing, tips, ready caption
• Download PNG · Print · Copy caption · WhatsApp share
• (Pro) Syr campaign draft → Open in Marketing Kit pre-selects template + caption

Guest events — /events and /e/{token}

• Hub /events — plan new or paste existing /e/… link; recent events saved on device
• Create /events/new → owner email with dashboard link (SMTP/Resend)
• Manage — role slots, link full /o/{publicToken} receipt URLs, budget vs committed vs outstanding
• Resend — email me my event link at /events
• Vendor view — signed-in linked vendor sees only their slot, not full planner budget
• Syr suggestions only — does not auto-book or charge

Other vendor screens

• Schedule (/dashboard/calendar) — status color bars (confirmed, completed, no-show) + badges
• Availability — weekly hours + blocked dates that feed public slots
• Profile (/dashboard/settings) — read-only overview (logo, public page, location, bank summary, team). Edit profile is /dashboard/settings/edit (logo/favicon, brand colour, location / Places, payout bank, WhatsApp, Team)
• Offerings — up to 8 photos; first is cover; extra count badge on the list
• Customers — trust scores, spend totals, Analytics link (Pro)
• Orders pipeline — made-to-order kanban columns

Customer booking flow — /v/{slug}/book/{offeringId}

Storefront /v/{slug} — tap the vendor logo to enlarge it; offering cards show duration (services), deposit amount, and a primary CTA like Pay ₦X to book. Location (address / city / state) appears when the vendor saved it. Trust panel, deposit policy, WhatsApp CTA.

Booking card: full-width photo gallery (tap for slideshow) → compact title, price, deposit → description clamped to two lines with More details (full copy + notice/cancellation rules).

Service stepper (shorter): Date & time → Your details → Confirm & pay (deposit shown before Monipay). Made-to-order keeps event date, quantity, and notes. If payment is cancelled or unpaid, return resumes Confirm & pay — it does not show a false receipt.

Admin platform dashboard — /admin

• Platform KPIs: GMV, platform revenue, active vendors, customers, bookings today, payment health
• Needs attention queue (pending vendors, failed payments, integration health)
• Platform health strip (Monipay, DB, AI providers) → full report at /admin/health
• Revenue & growth charts (hover for values)
• Top vendors table with revenue and ratings
• Desktop shell: persistent sidebar + sticky header (search on Vendors, Customers, Bookings, Payments)
• Admin login left panel is operations copy — not the vendor booking pitch

Charts — interaction

Hover or drag across any dashboard chart bar or line point to see: day label, exact value, vertical guide line, and value label on the chart. Works on vendor home (expandable Trends), Analytics, and admin dashboard.

Local setup note

npm run setup falls back to SQLite if Supabase is unreachable. Dev uses .env.local flag BOOKSYR_LOCAL_SQLITE=1 automatically. Demo login: demo@booksyr.app / demo1234 · storefront /v/aduke.

PART 0B — Location, onboarding, Explore & SEO

These flows land vendors on a public page faster and help customers find nearby businesses on /explore.

Vendor location — Places picker

• Where: Onboarding (business step) and Profile → Edit (/dashboard/settings/edit)
• Fields: address, city (LGA/area), state, country (default Nigeria), optional lat/lng + Google Maps URL
• Search: type an address → Places Autocomplete (/api/places/autocomplete) → pick a result → details fill the form (/api/places/details)
• Manual: Nigeria state + LGA lists from the in-app catalog (states-lgas); city is required for new vendors going live
• Shown on: storefront, booking, receipt, WhatsApp share text, settlement/reminder emails
• Dashboard: home prompts when location is missing
• Admin: vendor detail shows location; vendor list + analytics can filter/group by city/state (admin does not edit location)
• Env: GOOGLE_MAPS_API_KEY (server-only). Enable Places API and restrict the key. Without the key, manual state/city still works

Fast onboarding — Google → live page

1. Signup / login — email+password or Continue with Google (/api/auth/google → callback). Google users may have hasPassword=false until they set one
2. Business — name, slug, category, WhatsApp, state + city required, optional Places address
3. First offering — service or made-to-order so the storefront is bookable
4. Hours — weekly availability; Skip for now is allowed (slots empty until hours are set)
5. Live — public /v/{slug}. Bank/payout details can be completed later in Profile

Onboarding progress is stored as onboardingStep. Returning vendors resume the wizard until complete.

Explore — /explore

• Listings first — filters do not bury results under a long form
• Mobile: Filters open as a bottom sheet
• Desktop: sticky filter sidebar
• Filters: Nigeria state → LGA/area (city), category, search (vendor + offering names), sort
• Ranking: exact location match → nearby → other, when a state/city is selected
• URL sync: query params so links are shareable

SEO / discovery

• /sitemap.xml — static routes + each live vendor /v/{slug}
• /robots.txt — generated by the app (do not host a conflicting static public/robots.txt)
• JSON-LD: Organization / WebSite on home; LocalBusiness + breadcrumbs on vendor and explore
• Open Graph / canonicals via shared metadata helpers
• Search Console: submit only https://booksyr.online/sitemap.xml — never submit robots.txt as a sitemap

PART 1 — Application Overview

What BookSyr does

BookSyr is a deposit-first bookings and orders platform for Nigerian vendors (beauty, food, fashion, events, and related categories). Customers open a public vendor page, choose a service or made-to-order offering, and pay a deposit before work is confirmed. Vendors run their business from a dashboard. Platform operators supervise the marketplace from a separate Admin portal.

Problem it solves

Vendors lose money when customers book and never show up or never pay the balance. BookSyr creates financial commitment up front, then helps vendors manage the rest of the job (pipeline, reminders, wallet, marketing, and Syr intelligence on Pro).

Main modules

Primary roles

Role relationships

CUSTOMER (guest)  ↔  BOOKSYR PLATFORM  ↔  VENDOR
ADMIN             ↔  BOOKSYR PLATFORM  ↔  VENDOR
ADMIN             ↔  BOOKSYR PLATFORM  ↔  CUSTOMER RECORD (CRM, not a login)

Booking / order lifecycle (happy path)

1. Guest discovers vendor → selects offering → submits contact + slot/date.
2. Platform creates Order (pending_payment) + pending Payment + slot hold.
3. Guest pays via live gateway or simulator.
4. Settlement marks payment success, advances order, emails both parties, posts vendor wallet ledger, creates vendor in-app notification.
5. Vendor fulfills (status transitions) → optional balance payment → completion.
6. Vendor earnings remain in wallet until a manual payout request is processed by admin/finance.

How administrators supervise

Admins use /admin for KPIs, vendors, bookings, payments, wallets, marketplace, support, audit, and Health (including Syr Platform Health: Monipay, Database, Email, AI Groq/Gemini/OpenAI). Sensitive actions require confirmation and write AuditLog rows.

PART 2 — User Roles & Permissions

CUSTOMER (guest) — reality matrix

Customer identity: upserted as per-vendor Customer on @@unique([vendorId, phone]).

VENDOR — capability matrix

Plans: Free (10 paid bookings/month) · Pro (₦5,000 / 30 days) · business / enterprise (admin-granted).

Pro feature flags (src/lib/plans.ts): calendar, orders_pipeline, customers, reminders, whatsapp_templates, ai_assistant, in_app_notifications, analytics.

ADMIN — roles & permissions

Permissions are enforced in src/lib/admin-rbac.ts on /admin pages and /api/admin/*.

PART 3 — Complete Customer Journey (test cases)

Test data (local seed)

CUST-001 — Discover vendors on Explore

Objective: Guest can search/filter vendors by location and category.

Preconditions: App running; marketplace flag on; at least one approved vendor with city/state when testing location rank.

Steps:

1. Open /explore — listings should appear first.
2. Mobile: open Filters bottom sheet. Desktop: use sticky sidebar.
3. Pick state → LGA/area; optionally category; search by vendor or offering name; change sort.
4. Open a vendor card.

Expected: URL query updates; results prefer exact location matches. Storefront /v/{slug} loads with offerings, deposit CTA, and location when set. Logo is clickable (lightbox).

Verification: URL and business name match; BookSyr Verified badge only when trust rules pass (not fake response rates).

CUST-002 — Book a service (appointment)

Objective: Guest books a timed service with deposit.

Preconditions: Vendor has service offering + availability. Simulator or live gateway configured.

Steps:

1. Open /v/aduke → choose a service → Book.
2. On the booking card: tap photos to open the slideshow (if uploaded); More details expands a long description without crowding the header.
3. Pick slot → enter name, phone, email → continue.
4. Pay deposit (simulator Pay success or live test card).

Expected: Redirect to receipt /o/{publicToken}; order leaves pending_payment.

Verification: Vendor Orders (Pro) shows booking; customer + vendor emails if email configured; wallet ledger gains DEPOSIT (and PLATFORM_FEE as designed).

CUST-003 — Book made-to-order

Objective: Guest places MTO order with deposit.

Steps: Storefront → MTO offering → date/details → pay deposit.

Expected: Order status moves toward deposit_paid after settlement.

Verification: Vendor pipeline shows MTO statuses (deposit_paid → in_progress → ready → completed).

CUST-004 — View receipt and share

Objective: Guest can reopen confirmation.

Steps: Open /o/{publicToken} → Save as image/PDF if offered.

Expected: Order summary, amounts, vendor contact.

Verification: Token is opaque; no login required.

CUST-005 — Pay remaining balance

Objective: Guest pays balance via magic link.

Preconditions: Order with outstanding balance and balanceToken.

Steps: Open /pay/{token} → pay.

Expected: Balance payment settles; order balance cleared.

Verification: Payment type balance success; wallet BALANCE_PAYMENT posted.

CUST-006 — Payment failure (simulator)

Objective: Failed pay leaves order unpaid.

Preconditions: No live gateway keys (simulator mode).

Steps: Reach /pay/simulate/{reference} → choose fail (if available) or abandon.

Expected: Order remains pending_payment / unpaid; no success ledger credit.

Verification: Refresh receipt/vendor order — still awaiting payment.

CUST-007 — Free vendor monthly cap

Objective: Free vendor at 10 paid bookings blocks new paid checkout.

Preconditions: Free vendor with 10 paid bookings this calendar month.

Steps: Attempt guest checkout.

Expected: Friendly block; suggest contacting vendor (e.g. WhatsApp).

Verification: No new successful paid order created.

CUST-008 — Guest event planner

Objective: Guest creates and manages an event board end-to-end.

Preconditions: SMTP/Resend configured for email tests (optional locally).

Steps:

1. Open /events → Plan an event → /events/new → create with owner email.
2. Check owner email for dashboard link (if mail configured).
3. Open /e/{token} → add role slots.
4. Complete guest booking → paste full /o/{publicToken} URL on event board → budget updates.
5. Return to /events → paste link or use Email me my event link.

Expected: Budget / committed / outstanding summary; order link accepts full URLs; recent events on device.

Verification: Admin /admin/events lists event. Syr does not auto-book or charge.

CUST-008b — Vendor-scoped event view

Objective: Linked vendor sees only their slot when signed in.

Steps: Open /e/{token} as vendor linked to a slot.

Expected: Vendor view banner; not full budget or other vendors.

CUST-009 — Customer review submission

Status: Not implemented NOT IMPLEMENTED

Do not test a customer “leave a review” UI. Admin can moderate existing Review rows (e.g. seed data).

CUST-010 — Customer registration / wallet

Status: Not implemented NOT IMPLEMENTED

There is no customer signup, login, or customer wallet.

PART 4 — Complete Vendor Journey

VEND-001 — Vendor registration

Objective: New vendor can sign up with email or Google.

Steps: /signup → business name, email, password → submit or Continue with Google.

Expected: Session created; redirect to /onboarding if not onboarded. Google requires GOOGLE_CLIENT_ID + GOOGLE_CLIENT_SECRET.

Failure: Duplicate email → error; weak/empty fields rejected; Google misconfigured → friendly error.

VEND-002 — Onboarding

Objective: Vendor becomes bookable with location and a first offering.

Steps:

1. Business step — name, slug, category, WhatsApp, state + city (Places search optional).
2. Create first offering (service or made-to-order).
3. Set weekly hours — or Skip for now.
4. Finish → public page live. Add bank details later in Profile if needed.

Expected: onboarded=true; /v/{slug} reachable; dashboard home may prompt if location still missing on older accounts.

VEND-003 — Login / logout / remember email

Steps: /login with credentials; optional Remember email; logout via confirm modal.

Expected: Dashboard access; email remembered in localStorage without password; logout clears session cookie.

Failure: Wrong password → 401; suspended → 403; rate limit after many attempts → 429.

VEND-004 — Offerings & availability

Steps: Dashboard → Offerings → create service + MTO; upload up to 8 photos (first is cover; tap another to make it cover); Availability → weekly hours + blocked date.

Expected: Appear on /v/{slug} with photo count badge when extras exist; booking page gallery + slideshow; slots from /api/public/slots.

Verification: Edit/delete offering; extra photos persist after save; blocked date removes slots.

VEND-005 — Receive and manage booking

Preconditions: Pro for Orders/Schedule UX (or use admin impersonation / upgrade).

Steps: Complete CUST-002 → Vendor Orders → open order → advance status → optional staff assign.

Expected: Status transitions allowed by kind; staff assign only among vendor’s StaffMember rows.

Failure: Cannot change status while pending refund (must confirm refund first).

VEND-006 — Confirm refund (admin-requested)

Preconditions: Admin created pending RefundRequest.

Steps: Orders → Confirm refund after paying customer outside BookSyr.

Expected: Refund closes; wallet REFUND posted; order constraints cleared.

Verification: Admin booking shows refund resolved.

VEND-007 — Wallet earnings & payout request

Steps: After successful payments → /dashboard/wallet → review available → request payout → export CSV.

Expected: Available decreases (HOLD/pending); payout appears for admin.

Failure: Amount > available → rejected.

Note: Money is not auto-sent to bank.

VEND-008 — Upgrade to Pro

Steps: Billing → upgrade → pay (simulator or live).

Expected: plan=pro, planExpiresAt ~+30 days; Pro nav unlocks; Syr cards appear.

Verification: /api/vendor/me shows isPro: true.

VEND-009 — Syr Ask + proposal approve

Preconditions: Pro + AI key(s) optional (FAQ fallback without keys).

Steps: Dashboard Ask Syr → ask operational question → if proposal created, Review → Approve/Reject.

Expected: Grounded answers; prepare tools create SyrActionProposal; high-risk (refund/payout/cancel) denied; campaign drafts never auto-send.

Failure: Free plan → 402 upgrade.

VEND-010 — Marketing kit & settings

Objective: Vendor downloads print/social materials and configures profile.

Steps:

1. Profile (/dashboard/settings) → Edit profile → logo, brand colour, bank, WhatsApp.
2. Edit profile → Team → add a staff member.
3. Marketing → browse Print, Stickers, Social groups → preview QR card with vendor photo.
4. Copy caption from posting guide → Download PNG or Print → scan QR lands on /v/{slug}.
5. (Pro) Syr → Open in Marketing Kit → template + caption pre-filled.

Expected: Branded QR scans; vendor-specific captions; profile overview shows the saved logo and public link without opening the form; admin template changes need Templates → Sync.

VEND-011 — Password reset

Steps: Forgot password → email link (if mail configured) → reset.

Expected: New password works; old fails.

PART 5 — Complete Admin Journey

ADMIN-001 — Admin login

Steps: /admin/login with seeded admin.

Expected: /admin dashboard; separate cookie from vendor session.

Failure: Invalid creds; inactive admin; rate limit 429.

ADMIN-002 — Dashboard KPIs

Steps: Open /admin.

Expected: Overview / attention items (including refunds where applicable).

ADMIN-003 — Vendor approval & controls

Steps: Vendors → open vendor → Approve / Suspend / Verify / Feature / Plan / Soft-delete / Reset password / Impersonate (each confirms).

Expected: Vendor status/plan updates; impersonation opens vendor dashboard with exit banner; actions audited.

ADMIN-004 — Customers CRM

Steps: Customers → open → trust override / suspend / blacklist / merge (as UI offers).

Expected: Per-vendor customer record updates. Not a platform user account.

ADMIN-005 — Bookings & refund request

Steps: Bookings → open → cancel / force complete / reschedule / refund request / withdraw / notes.

Expected: Refund request notifies vendor path; withdraw clears pending request.

ADMIN-006 — Payments & wallets

Steps: Payments list/export; Wallets → view ledger → adjust (credit/debit + reason + confirm) → advance payout status.

Expected: Adjustments audited; payout successful only after external transfer (ops SOP). Never treat pending as paid out.

ADMIN-007 — Marketplace, events, promos, reviews

Steps: Feature/pin vendors; manage banners/categories; list events; promo ads; hide/restore/remove reviews.

Expected: Explore/dashboard reflect marketplace changes.

ADMIN-008 — Support & broadcasts

Steps: Create support ticket (admin-originated); send email broadcast; note WA/SMS/push queue-only.

Expected: Email sends when provider configured; non-email channels not delivered.

ADMIN-009 — Marketing Studio / CMS / analytics / fraud / flags

Steps: Create marketing asset; edit CMS help page → /help/{slug}; view analytics; fraud signals; toggle flags.

Expected: Permission-gated; confirms on destructive toggles.

ADMIN-010 — Syr Platform Health

Steps: /admin/health.

Expected: Card lists Monipay, Database, Email, AI — Groq / Gemini / OpenAI with healthy/degraded/down/unconfigured; narrative about latency/fallbacks; history table. No secrets shown.

ADMIN-011 — Admins invite

Steps: Admins → invite/create → accept via /admin/accept-invite?token=….

Expected: New admin can log in with role permissions.

PART 6 — Customer ↔ Vendor complete interaction

Discover vendor → View storefront → Select offering → Checkout
→ Pay deposit → Settlement → Vendor notified
→ Vendor fulfills → (Optional) balance pay → Complete
→ Vendor wallet credited → (Optional) payout request

PART 7 — Customer ↔ Admin interaction

Honest map — customers have no admin-facing portal.

CUSTOMER ACTION → PLATFORM → ADMIN only exists indirectly (payment webhooks, shared email, admin lookup of Customer/Order/Payment).

PART 8 — Vendor ↔ Admin interaction

PART 9 — Admin oversight of customer + vendor

Customer visibility

Admin can see per-vendor customers: identity fields, orders, trust, suspension/blacklist flags.

Vendor visibility

Business profile, plan, status, offerings, bookings, payments, wallet, bank fields, marketplace flags.

Transaction visibility

Payments list/export; wallet ledger; fees; payouts; billing payments for Pro.

Booking visibility

Full order detail, payments, refund requests, admin notes, invoice page.

Account controls

Approve/reject/suspend/reactivate/soft-delete vendors; reset passwords; impersonate; customer trust/suspend/merge; plan changes.

Auditability

Implemented AuditLog for admin (and Syr/vendor proposal) sensitive actions. Health checks persist SystemHealthCheck.

PART 10 — Wallet & financial flow testing

Implementation facts

• Wallet is vendor-only, created on first ledger need (ensureWallet).
• Balances: availableKobo, pendingKobo, totalEarnedKobo, totalPaidOutKobo.
• Types: DEPOSIT, BALANCE_PAYMENT, PLATFORM_FEE, REFUND, PAYOUT, ADJUSTMENT, HOLD.
• Platform fee percent: PLATFORM_FEE_PERCENT (default 2).
• Subaccount/split settlements may avoid double-crediting platform-held wallet (see settlement/ledger).
• Payouts: request holds funds; admin advances status; no automated bank API transfer.

WALLET-001 — Deposit credits available

Example (illustrative): Customer pays ₦10,000 deposit (1,000,000 kobo).

Expected: Success payment; ledger DEPOSIT; PLATFORM_FEE row per fee rules; vendor available increases by net credit logic in creditSuccessfulPayment.

Verify: /dashboard/wallet + /admin/wallet. Opening the vendor wallet may backfill missing historical ledger rows in the background (max 20 per visit; already-posted payments are skipped).

WALLET-002 — Balance payment

Pay outstanding balance → BALANCE_PAYMENT posted similarly.

WALLET-003 — Payout request

Start: available ≥ request.

Action: Vendor requests payout ₦X.

Expected: HOLD moves available → pending; PayoutRequest created (manual channel).

Admin: processing → successful (after real transfer) posts PAYOUT and increases totalPaidOut; failed restores per payout rules.

WALLET-004 — Insufficient available

Request more than available → error; balances unchanged.

WALLET-005 — Admin adjustment

Admin credit/debit with reason + confirm → ADJUSTMENT + audit.

WALLET-006 — Refund ledger

After vendor confirms refund → REFUND debit path; available reduced appropriately; no double refund.

WALLET-007 — Simulator disabled when live gateway present

With Monipay secrets set, /api/simulate returns 403 and simulate page redirects away.

PART 11 — AI / Syr functionality

AI FEATURE STATUS: Implemented Implemented for Pro vendors (intelligence + safe copilot). FAQ/assistant fallback without keys.

PART 12 — Notifications

Read/unread: vendor notifications API marks read; toasts dismissible.

PART 13 — Error & edge-case testing

PART 14 — End-to-End scenario tests

Scenario 1 — Customer books vendor (complete)

New guest → /v/aduke → book → pay → receipt → vendor Pro orders → complete → wallet shows earnings → optional payout request.

Scenario 2 — Payment fails

Checkout → simulator fail/abandon → order unpaid → no wallet credit → retry pay works.

Scenario 3 — Cancel after pay

Admin or vendor cancel path (per UI rules) → if refund needed, ADMIN refund_request → vendor confirms after external refund.

Scenario 4 — Dispute

Not implemented NOT IMPLEMENTED as a disputes module.

Substitute UAT: Admin support ticket + refund request workflow.

Scenario 5 — Vendor withdrawal

Wallet available → request payout → admin /admin/wallet advances status after offline transfer → vendor sees PAYOUT / reduced pending.

Scenario 6 — Admin manages vendor

Signup → admin approve/verify → feature on explore → suspend → vendor login blocked → reactivate.

Scenario 7 — Events (full flow)

/events hub → create → email → /e/{token} → link /o/… → resend → vendor-scoped view → admin list.

Scenario 8 — Marketing kit + Syr

Profile → Edit profile (logo) → Marketing kit QR card → print → (Pro) Syr draft → Open in Marketing Kit → social template with caption.

Scenario 9 — Syr proposal

Pro vendor Ask Syr to prepare reminders → proposal → Approve → draft prepared, not silently emailed as blast without review rules.

PART 15 — Module-by-module usage guide

Explore

Who: Guests · Path: /explore · Browse/search vendors · Data: public vendor fields, trust.

Storefront & booking

Who: Guests · Path: /v/{slug}, /v/{slug}/book/{offeringId} · Book + pay · Data: Order, Payment, Customer.

Receipt & balance pay

Paths: /o/{publicToken}, /pay/{token} · Related: settlement, wallet.

Payment simulator

Path: /pay/simulate/{reference} · Only when no live gateway configured.

Vendor dashboard modules

See PART 0 for dashboard hierarchy and chart hover behavior.

Events

/events hub · /events/new · /e/{token} — guests; link /o/… confirmations; resend access; vendor-scoped view. No auto charges.

Marketing kit (vendor)

/dashboard/marketing — print, stickers, social templates, vendor logo, branded QR, captions. See MARKETING-STUDIO.md.

Admin modules

Operate: Dashboard, Vendors, Customers, Bookings, Support

Money: Payments, Wallets, Subscriptions

Growth: Marketplace, Events, Promos, Reviews, Broadcasts, Email templates, Marketing, Analytics

System: Fraud, CMS, Audit, Flags, Health, Admins

PART 16 — Test data requirements

TEST DATA (local)

npm install
npm run setup    # db push + seed
npm run dev

PRODUCTION DATA

• Set AUTH_SECRET, DATABASE_URL, CRON_SECRET, NEXT_PUBLIC_APP_URL
• Set ADMIN_EMAIL + ADMIN_PASSWORD before seeding (default admin not created on Vercel without them)
• Prefer not seeding demo passwords into production
• Use Monipay test keys before live keys
• Never commit .env secrets

PART 17 — Test execution checklist

• Read PART 0 UI map + PART 0B location / Explore / SEO
• Env + npm run setup + npm run dev
• Vendor dashboard KPIs + expand Trends (hover charts)
• Vendor Analytics /dashboard/analytics (Pro)
• Explore filters (mobile sheet / desktop sidebar) + location ranking
• Explore + /v/aduke storefront (logo lightbox + deposit CTA + location)
• Guest service booking + simulator pay success
• Cancelled/unpaid payment return resumes Confirm & pay
• Booking gallery slideshow + More details on a long description
• Receipt /o/... + balance pay path
• Simulator fail/abandon leaves unpaid order
• Vendor signup (email or Google) → onboarding (location → offering → hours)
• Vendor login / logout / remember email only
• Offerings + availability (including extra photos)
• Profile overview + Edit profile (logo, bank, Team, location)
• Pro upgrade (or use seeded Pro aduke)
• Orders status + staff assign
• Customers list (Pro)
• Wallet ledger + payout request
• Marketing kit — groups, QR scan, Syr draft (Pro)
• Syr Ask + proposal approve/reject
• Events hub + link /o/… + resend + vendor view
• Admin login + dashboard
• Vendor approve/suspend/impersonate
• Booking refund request → vendor confirm
• Admin wallet adjust + payout status
• Payments export
• Broadcast email (if mail configured)
• Health / Syr Platform Health
• Audit log entry after admin action
• Free plan booking cap
• Live-gateway disables simulator
• Suspended vendor cannot login
• Offline shell (PWA) smoke
• Confirm Not implemented items stay unimplemented (customer login, SMS, push, disputes UI, review submit)

PART 18 — Feature status matrix

PART 19 — Documentation accuracy audit

Corrections versus older BookAm materials:

1. Demo public slug is /v/aduke, not /v/abc.
2. Payments are Monipay + simulator — not a multi-gateway picker.
3. AI is Syr with Groq primary (+ Gemini/OpenAI fallback), not a single hard-coded provider UI.
4. Vendor wallet / payouts / events / Syr proposals / admin wallets / Syr Platform Health are implemented and must be in QA scope.
5. Customers are guest CRM rows, not users.
6. Guest events include /events hub, create email, access resend, /o/… linking, vendor-scoped view.
7. Vendor marketing kit — grouped templates, posting guides, branded QR, Syr handoff.
8. Do not claim SMS, web push, customer reviews UI, disputes, or auto payouts as live.
9. Wallet historical sync is batched (max 20 per visit) and skips already-posted payments so the wallet page does not lock the database.
10. Schedule is the product name for /dashboard/calendar (route unchanged). Availability feeds slots; Profile → Edit profile → Team manages staff. Brand colour is #7107E7.
11. Offerings support up to 8 photos; the booking page uses a full-width gallery and slideshow. Long copy is behind More details.
12. Profile is /dashboard/settings (overview). Edits are /dashboard/settings/edit.

PART 20 — Final testing summary

Customer capabilities

Discover vendors, book service/MTO (photo gallery + More details), pay deposit/balance, view receipt, plan events via /events hub, link confirmations to event boards.

Vendor capabilities

Signup→onboard→catalog→availability→receive jobs→manage statuses→wallet/payout request→billing/Pro→marketing kit→profile→Syr (Pro).

Admin capabilities

Full ops/money/growth/system portal with RBAC, impersonation, refunds, wallet adjustments, payout status, health, audit.

Customer ↔ Vendor workflows

Guest book/pay → vendor fulfill → balance → wallet credit.

Customer ↔ Admin workflows

Indirect only (CRM, refunds, support tickets, email broadcasts).

Vendor ↔ Admin workflows

Approval, plans, impersonation, payouts, refunds, suspension, marketplace.

Financial workflows

Checkout settlement, fees, wallet ledger, manual payouts, refunds, Pro billing.

AI workflows

Pro Syr intelligence, Ask Syr, safe proposals, campaign drafts, platform health.

Notification workflows

Email + vendor in-app; cron reminders (Pro); WA links; SMS/push not delivered.

Critical blockers for “full marketplace app” expectations

• No customer accounts
• Manual payouts only
• No disputes UI
• No customer review capture UI

Partially implemented

Staff (assign only), reviews (moderate/seed), broadcasts (email yes / WA·SMS·push queue), support (admin-only).

Not implemented

Customer login/wallet, SMS/push delivery, auto bank transfers, disputes module, staff CRUD, public admin signup.

Recommended testing order

1. Local setup + seed
2. Guest book + simulator pay + receipt
3. Vendor Pro orders/wallet
4. Admin refund + wallet payout status
5. Explore/marketplace + events (hub, link orders, resend)
6. Marketing kit + Syr draft handoff
7. Syr Ask + proposals
8. Health + auth edge cases
9. Regression checklist (Part 17)

*End of BookSyr End-to-End Testing & Module Usage Guide.*