# Open Questions & To-Do Backlog

[← Product docs home](../index.md)

From `whatsInYourMind.txt` — things to build, research, or decide. Some are now resolved in the
refined data model; marked below.

---

## Build / surface backlog

- **Ticket page** — the admin-readable messaging surface; modeled in
  [Messaging (ticket system)](../data-model/09-messaging.md) and required by
  [Messaging & On-Site Emergencies](../business/12-messaging-and-emergencies.md).
- **Backoffice / admin** — see [Notifications & Admin / Backoffice](../business/14-notifications-and-admin.md).
- **Verify the registration code** — OTP confirmation step in onboarding.
- **Rate limiting** — abuse protection on auth/OTP and API.
- **Workbox for cache** (maybe) — PWA/offline caching, client-side.

## Needs research

- **Terms of Service page** — *(needs research)*.
- **Privacy & Policy page** — *(needs research)*.

---

## Resolved questions (kept for the record)

These were the two hardest open questions; both are now **answered** against verified payment
research and built into the model.

- ~~اگر پرداخت قسطی داشته باشیم و طرف اون وسط بخواد کنسل کنه چی میشه؟~~
  **(BNPL booking cancelled mid-plan — what happens?)** → Resolved. Money always flows
  `customer ↔ provider ↔ Balinyaar`; Balinyaar calls the provider's revert/cancel/update API and the
  provider unwinds the customer's installments. See
  [Q1 — cancellation/refund](../payments/cancellation-and-payout.md) and
  [the two questions](../data-model/index.md).
- ~~BNPL اگر باشه خب پول پرستار رو کی میده؟~~
  **(Under BNPL, who pays the nurse?)** → Resolved. **Balinyaar** pays the nurse, on its own weekly
  schedule, from `gross − balinyaar_commission` — identical to a card booking; the BNPL commission is
  a platform expense, never the nurse's. See [Q2 — who pays the nurse & when](../payments/cancellation-and-payout.md).

---

See also the launch-blocking items to confirm with counsel / providers:
[research open questions](../research/go-to-market.md) and
[data-model open items](../data-model/index.md).

---

## Decided — public guest-browse depth (ui-phase-13, 2026-07-19)

**Question:** how deep should the anonymous (logged-out) web experience go, now that the entire
public surface is a bare `/login`?

Three tiers were framed:
- **(a) Landing only** — a marketing page at `/`; zero data, zero new endpoints.
- **(b) Landing + static public pages** — (a) plus category/how-it-works/trust content; still zero
  data (a static i18n category grid, not the live catalog).
- **(c) Guest search + public nurse profiles** — read-only anonymous variants of the search-results
  and nurse-profile screens. Requires **public read endpoints that don't exist today** (search and
  profile reads sit behind the auth middleware + cookie-bearing `clientFetch`) plus a privacy review
  of which nurse fields may be shown logged-out (never phone, exact address, or document data).

**Decision: ship (a)+(b) now; tier (c) is deferred as a REQ-gated follow-up**, not built against
placeholder endpoints. Rationale:
- (a)+(b) already close the biggest gap — a family can see the brand, the trust story (identity/
  license/INO/bank verification), the escrow guarantee, and the service categories before creating
  an account, all with **zero new backend surface**.
- (c) is a materially bigger commitment: a new anonymous, rate-limited search read and a
  privacy-reviewed public nurse-profile shape are backend work with real abuse/PII exposure
  considerations (scraping, competitor intel, nurse safety) — the kind of decision that shouldn't be
  made by inferring it from a frontend phase.
- What (c) would need, if approved later: an anonymous `nurse_search` read (verified-only invariant
  preserved, rate-limited, no customer-context fields) and a privacy-reviewed public nurse-profile
  read (display name, photo, verified-badge state, rating aggregate, service/price rows only — never
  phone, exact coverage area, or document data). Filed as REQ-066/REQ-067 in
  [for-backend.md](../../dev/shared-working-context/frontend/requests/for-backend.md); guest-search
  routes and the guest→login handoff at the booking CTA stay unbuilt until those land.

Implemented as: a public landing rewritten in at `/` (middleware rewrite, not a redirect, so the URL/
canonical stays `/`) with hero, static category grid, how-it-works, a trust/verification explainer,
a nurse-recruitment CTA, and a footer — see
[ui-phase-13-report.md](../../dev/shared-working-context/reports/ui-phase-13-report.md) for the
full build record.