/plan/public-home
Public home
Company, services, promotions, outlets, social proof, and the phone + OTP entry point.
- Marketing content is admin-controlled in three locales
- No wellness claim beyond recovery and comfort
HQMP001 · HANQING mini program
Role-based review pack
One focused page per role and workflow, so each audience reviews only its own screen. Every page states the business rules it is meant to prove and lets you flip between the states those rules produce.
Scope boundary
Static review artefact. No backend, no accounts, no SMS, no payment processing, no database, no external integration. Buttons change what is on the screen and nothing else; a page reload restores the authored state. Every name, phone number, amount and wellness value is fabricated for review.
1 · Public and customer
Mobile-first. Trilingual demo toggle: EN / 中文 / BM.
/plan/customer-login
Customer login & OTP
Phone-first login and registration with every OTP state.
- OTP is simulated — no SMS is sent
- New customer completes name and preferred language
/plan/customer-home
Customer home
Wallet, points, coupons and wellness shown as four separate systems — never merged.
- Each balance keeps its own unit and its own ledger
/plan/customer-order
Customer order
Table service, takeaway and delivery; product availability; tender eligibility; Pay at Counter.
- Published but not available stays visible and is not selectable
- Draft products never reach the customer
- Points earned differ by tender
/plan/customer-booking
Customer booking
Session and table booking, separate from ordering.
- Table list comes from the branch table register
/plan/customer-wallet
Customer wallet
Three separate ledgers: wallet money, points, coupons — plus cash top-up at the counter.
- Top-up credit appears only after the counter captures the cash
- Top-ups earn no points
/plan/customer-reports
Customer reports
Own spend history, points split by tender, and the member's own wellness summary.
- Wellness indicators are not a medical diagnosis
2 · Store operations
Task-dense, landscape tablet first. English only in this pack.
/plan/pos
POS counter
Order inbox with Accept / Reject / Edit, counter tender capture, cash top-up, refunds.
- Only an accepted order creates a kitchen ticket
- Pay at Counter is captured only once the kitchen marks the order ready
- No customer health data on this surface
/plan/kitchen
Kitchen display
Queued tickets, Start and Mark ready, and the counter-tender handback.
- No prices, no tender detail, no customer identity, no health data
3 · Wellness
Desktop. The only staff surface with wellness visibility.
/plan/coach
Coach workspace
Member wellness profile, indicator trend, session notes and recovery plan.
- Coach and the member's own report are the only places wellness detail appears
- Safety and recovery language only — no diagnosis, treatment or outcome claim
4 · HQ administration
Desktop. Configuration comes first — it governs every surface above.
/plan/admin
Admin overview
Sample KPIs by ledger, section navigation, and the immutable audit log.
- Wallet float and points liability are reported as separate ledgers
/plan/admin/catalog
Catalog
Draft / Published / Unpublished, availability, per-product tender and earn rules.
- Publication and availability are independent switches
- Wallet / cash / points eligibility is set per product
/plan/admin/commerce-settings
Commerce settings
Branch payment methods, earn rates by tender, order review gate, tables and delivery.
- Cash and wallet / e-wallet can earn at different rates
- Cash top-up policy lives here
/plan/admin/content-settings
Content settings
Public home content, promotions, social links and FAQ in EN / 中文 / BM.
- Missing translations fall back to English, and say so
/plan/admin/organization
Organization & access
Branches, tables, staff roles — plus customer wallet and points adjustment.
- An adjustment is blocked until a reason is given
- Every adjustment previews before / after and writes an audit entry
Evidence map
Which page demonstrates which rule
Use this as the review checklist. Each page repeats its rules inline as a callout.
| Rule | Shown on |
|---|---|
| A published product that is not available stays visible to the customer but cannot be added | customer-order, admin/catalog |
| Draft and unpublished products never appear to a customer | admin/catalog, customer-order |
| With the review gate on, only an order the counter accepts becomes a kitchen ticket | pos, kitchen |
| A rejected order never produces a ticket; an edited order shows a before / after diff | pos, customer-order |
| Pay at Counter: the kitchen prepares first, and the actual tender is captured at the counter once the order is ready | customer-order, kitchen, pos |
| Wallet cash top-up credits only after the counter captures the cash, and earns no points | customer-wallet, pos, admin/commerce-settings |
| Cash and wallet / e-wallet may earn points at different rates; paying with points earns none | admin/commerce-settings, customer-order, customer-reports |
| Wallet money, points, coupons and wellness are four separate systems with their own units | customer-home, customer-wallet, admin |
| A wallet or points adjustment needs a reason, previews before / after, and writes an immutable audit entry | admin/organization, admin |
| Wellness indicators are visible to the coach and to the member only, and are never a diagnosis | coach, customer-reports; excluded on pos, kitchen, admin/catalog |
| Branch configuration governs tender types, order modes, tables and delivery channels | admin/commerce-settings, admin/organization, pos |
Guided review
Walkable flows
Each handoff is a real link on the page, labelled with the role that picks the work up.
A · First order, review gate on, Pay at Counter
public-home → customer-login → customer-home → customer-order → pos (Accept) → kitchen (Mark ready) → pos (capture tender) → customer-wallet (points at the cash rate).
B · Review gate off
customer-order → kitchen directly; the counter only handles handover. Toggle the gate on admin/commerce-settings.
C · Counter edits or rejects the order
pos (Edit → diff → confirm, or Reject with a reason) → customer-order shows the outcome; a rejected order never reaches kitchen.
D · Wallet cash top-up
customer-wallet (request, pending reference) → pos (capture cash) → customer-wallet (credited, no points).
E–H · Configuration reaching the customer
admin/catalog and admin/commerce-settings set publication, availability, tender eligibility, earn rates and the review gate; customer-order and pos show the result.
J–K · Adjustment audit and the wellness boundary
admin/organization (adjust with a reason) → admin (audit entry) → customer-wallet (read-only reason). coach and customer-reports hold all wellness detail.
How to read these pages
Rule callouts
Gold-edged panels state the rule the screen is proving. If a callout is wrong, the rule is wrong — say so before the build starts.
State switchers
Dashed strips near the top of each page flip it between authored states — empty, blocked, accepted, rejected, and so on. No backend is involved.
Sample data
Names, phone numbers, amounts and wellness values are invented. Phone numbers are shown masked. Amounts use RM with round sample figures.
Reviewed on a phone, a tablet and a desktop: public and customer pages are mobile-first, POS and kitchen are built for landscape tablet, admin and coach for desktop.
Reminder. This pack is for design review only. It is not a live service, it
contains no real or personal data, it performs no processing, and it makes no medical claim.
Wellness recovery support only — not diagnosis, treatment or an outcome guarantee.
Superseded planning mock-ups remain at
docs/planning/ui-layouts.html in the repository.