docs: scope login UX to demo

This commit is contained in:
2026-08-20 17:14:40 +03:30
parent a3a8b0c05d
commit 2574fa4309
2 changed files with 3 additions and 1 deletions

View File

@@ -1,7 +1,7 @@
# Design System — ZarinPal Merchant Analytics # Design System — ZarinPal Merchant Analytics
- Status: Draft baseline for approval - Status: Draft baseline for approval
- Version: 0.2.2 - Version: 0.2.3
- Last updated: 2026-08-20 - Last updated: 2026-08-20
- Direction: Persian-first RTL - Direction: Persian-first RTL
@@ -146,6 +146,7 @@ Navigation labels should describe merchant tasks, not internal database concepts
| Version | Date | Decision | | Version | Date | Decision |
|---|---|---| |---|---|---|
| 0.2.3 | 2026-08-20 | Kept authentication UX intentionally demo-sized: generic and throttled username/password login now, with a clean replacement boundary for ZarinPal SSO after acceptance. |
| 0.2.2 | 2026-08-20 | Defined backend-owned session UX: authentication tokens remain inaccessible to the frontend, and expiry/revocation returns the user to login with a generic, accessible message. | | 0.2.2 | 2026-08-20 | Defined backend-owned session UX: authentication tokens remain inaccessible to the frontend, and expiry/revocation returns the user to login with a generic, accessible message. |
| 0.2.1 | 2026-08-20 | Defined same-category peer cards as an equal-per-merchant median plus direction-aware percentile. This prevents the dataset's largest merchants from dominating what should represent a typical peer. | | 0.2.1 | 2026-08-20 | Defined same-category peer cards as an equal-per-merchant median plus direction-aware percentile. This prevents the dataset's largest merchants from dominating what should represent a typical peer. |
| 0.2.0 | 2026-08-20 | Corrected payment lifecycle semantics from CTO guidance: `Paid` and `Verified` are bank-payment successes, `Paid` remains unverified, and session-level fees are real Rial amounts. | | 0.2.0 | 2026-08-20 | Corrected payment lifecycle semantics from CTO guidance: `Paid` and `Verified` are bank-payment successes, `Paid` remains unverified, and session-level fees are real Rial amounts. |

View File

@@ -39,6 +39,7 @@ Give a non-technical merchant a fast, trustworthy Persian RTL view of payment pe
21. Retry recovery may finish in either `Paid` or `Verified`. Timing cards show p50, p95, sample size, and non-null coverage. 21. Retry recovery may finish in either `Paid` or `Verified`. Timing cards show p50, p95, sample size, and non-null coverage.
22. Authentication uses a backend-owned server-side session. The frontend receives only a `Secure`, `HttpOnly`, `SameSite=Lax` cookie and never reads or stores an authentication token. 22. Authentication uses a backend-owned server-side session. The frontend receives only a `Secure`, `HttpOnly`, `SameSite=Lax` cookie and never reads or stores an authentication token.
23. Expired, revoked, logged-out, or disabled-account sessions stop dashboard and SSE access immediately and return the user to login without exposing internal authentication details. 23. Expired, revoked, logged-out, or disabled-account sessions stop dashboard and SSE access immediately and return the user to login without exposing internal authentication details.
24. The demo login handles typed throttling with `Retry-After`, never reveals whether a username exists, and does not implement password recovery, registration, or SSO. ZarinPal SSO replaces the demo credential screen after product acceptance.
## Frontend architecture baseline ## Frontend architecture baseline