ui phase 13

2026-07-20 01:35:15 +03:30
parent d33568bf31
commit 12ce7fa7de
21 changed files with 868 additions and 80 deletions
@@ -1076,3 +1076,40 @@ delivers fixes in its own change. **Frontend never edits backend code to "fix" a
 - **Proposed shape:** see **Need** above; masked phone follows the existing `maskIranMobile` convention
  (`"0912•••1234"`, first-4/last-4) — never the full number.
 - **Status:** open
+
+## REQ-066 — Public (anonymous), rate-limited nurse-search read for guest browse (tier c) — filed by ui-phase-13 — 2026-07-19
+- **Need:** An **unauthenticated** variant of the f6 nurse-search read — proposed
+  `GET api/v1/public/nurse_search?category_id=&province_id=&city_id=&district_id=&gender=&page=&pageSize=`
+  (no auth header required) → the same shape `search/nurses` already returns
+  (`NurseSearchResultDto[]` + pagination), preserving every existing invariant: **verified-only**
+  results (the `is_searchable` gate f7 already enforces), no customer-context fields (no distance-
+  from-my-address, no "your last booking with"), and **rate-limited per IP** (this is the one read in
+  the whole app reachable with zero login, so it is also the one most exposed to scraping/abuse).
+- **Why:** ui-phase-13 framed three guest-browse tiers (§3.1 of the phase file) and the product
+  decision (recorded in `product/notes/open-questions.md`) was to ship (a) landing + (b) static public
+  pages **now** and defer (c) guest search + public nurse profiles as a REQ-gated follow-up — this
+  route is what a future phase would need to build a real (not placeholder) guest search results
+  screen. Nothing in this phase calls it; it is filed so the decision and its cost are on record, not
+  guessed at when someone picks tier (c) up later.
+- **Proposed shape:** identical response shape to the existing (authenticated) `search/nurses`, served
+  from a route that bypasses the auth middleware entirely (a new, explicitly public controller/route —
+  not a "make search/nurses optionally-authenticated" flag, which would risk quietly widening what an
+  authenticated call can already see).
+- **Status:** open
+
+## REQ-067 — Public (anonymous), privacy-reviewed nurse-profile read for guest browse (tier c) — filed by ui-phase-13 — 2026-07-19
+- **Need:** An **unauthenticated** nurse-profile read, deliberately narrower than the authenticated
+  `GET nurses/{id}/profile` (REQ-012): `{ nurseId, displayName, avatarUrl, bio, yearsExperience,
+  averageRating, totalReviews, isVerified, credentialTypes: string[], services: [{ variantId,
+  displayName, priceIrr, priceUnit, sessionCount? }] }`. **Never** phone, exact coverage
+  area/district, document/credential numbers, or patient-identifying data from any linked booking —
+  this is the field set a logged-out stranger may see, which is why it needs an explicit privacy
+  review before it's built, not an assumption that "the authenticated shape minus a filter" is safe.
+- **Why:** same tier-(c) framing as REQ-066 — a guest who found a nurse via public search needs a
+  profile to land on before the "درخواست رزرو" CTA hands them to `/login`. Filed as a proposal only;
+  the phase explicitly defers building any guest-facing profile screen against it (§3.4 of
+  `dev/post-phase/ui/ui-phase-13-public-front-door.md`).
+- **Proposed shape:** as above. A privacy sign-off on the exact field list (not just an engineering
+  guess) should happen before this is implemented — flagging here so it isn't skipped when tier (c)
+  is picked up.
+- **Status:** open