hamid/baya-monorepo
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

ui phase 13

Browse Source
This commit is contained in:
hamid
2026-07-20 01:35:15 +03:30
parent d33568bf31
commit 12ce7fa7de
21 changed files with 868 additions and 80 deletions
Download Patch File Download Diff File Expand all files Collapse all files
product/notes/open-questions.html
+27
View File
@@ -48,6 +48,33 @@
<p> <strong>(Under BNPL, who pays the nurse?)</strong> → Resolved. <strong>Balinyaar</strong> pays the nurse, on its own weekly schedule, from <code>gross − balinyaar_commission</code> — identical to a card booking; the BNPL commission is a platform expense, never the nurse's. See <a href="../payments/cancellation-and-payout.html">Q2 — who pays the nurse &amp; when</a>.</p>
<hr>
<p>See also the launch-blocking items to confirm with counsel / providers: <a href="../research/go-to-market.html">research open questions</a> and <a href="../data-model/index.html">data-model open items</a>.</p>
<hr>
<h2 id="decided-public-guest-browse-depth-ui-phase-13-2026-07-19">Decided — public guest-browse depth (ui-phase-13, 2026-07-19) <a class="anchor" href="#decided-public-guest-browse-depth-ui-phase-13-2026-07-19" aria-hidden="true">#</a></h2>
<p><strong>Question:</strong> how deep should the anonymous (logged-out) web experience go, now that the entire public surface is a bare <code>/login</code>?</p>
<p>Three tiers were framed:</p>
<ul>
<li><strong>(a) Landing only</strong> — a marketing page at <code>/</code>; zero data, zero new endpoints.</li>
<li><strong>(b) Landing + static public pages</strong> — (a) plus category/how-it-works/trust content; still zero</li>
</ul>
<p> data (a static i18n category grid, not the live catalog).</p>
<ul>
<li><strong>(c) Guest search + public nurse profiles</strong> — read-only anonymous variants of the search-results</li>
</ul>
<p> and nurse-profile screens. Requires <strong>public read endpoints that don't exist today</strong> (search and profile reads sit behind the auth middleware + cookie-bearing <code>clientFetch</code>) plus a privacy review of which nurse fields may be shown logged-out (never phone, exact address, or document data).</p>
<p><strong>Decision: ship (a)+(b) now; tier (c) is deferred as a REQ-gated follow-up</strong>, not built against placeholder endpoints. Rationale:</p>
<ul>
<li>(a)+(b) already close the biggest gap — a family can see the brand, the trust story (identity/</li>
</ul>
<p> license/INO/bank verification), the escrow guarantee, and the service categories before creating an account, all with <strong>zero new backend surface</strong>.</p>
<ul>
<li>(c) is a materially bigger commitment: a new anonymous, rate-limited search read and a</li>
</ul>
<p> 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.</p>
<ul>
<li>What (c) would need, if approved later: an anonymous <code>nurse_search</code> read (verified-only invariant</li>
</ul>
<p> 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 <a href="../../dev/shared-working-context/frontend/requests/for-backend.html">for-backend.md</a>; guest-search routes and the guest→login handoff at the booking CTA stay unbuilt until those land.</p>
<p>Implemented as: a public landing rewritten in at <code>/</code> (middleware rewrite, not a redirect, so the URL/ canonical stays <code>/</code>) with hero, static category grid, how-it-works, a trust/verification explainer, a nurse-recruitment CTA, and a footer — see <a href="../../dev/shared-working-context/reports/ui-phase-13-report.html">ui-phase-13-report.md</a> for the full build record.</p>
<a class="back-to-top" href="#">↑ Back to top</a>
</div></main>
</div>
product/notes/open-questions.md
+38
View File
@@ -45,3 +45,41 @@ research and built into the model.
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.