Clarity 2's design review is reachable at the clinic's own address, behind a login

Before the dentist and his attendant could try Clarity 2 on made-up patients, the app needed to live at the clinic's own subdomain over HTTPS, and nowhere else, unguarded.

What it does

Every request to every address the Pages project answers to, the custom subdomain and every branch preview, first hits a login gate. With no valid session it always gets a sign-in page, never the app: a username and password field posting to /_auth, with no design of its own. A correct sign-in from either the dentist's or the attendant's credentials sets a signed, 30-day cookie that records which of the two signed in, so a reload does not ask again and the app can open a different shell per person. A wrong username and a wrong password answer identically, and neither is echoed back.

What the gate added next

The second work order gave the gate two new jobs. It answers a GET /_session with the role the signed-in cookie carries, dentist or front-desk, or 401 when the cookie is missing, expired or forged. The cookie stays HttpOnly, so the page cannot read it directly; this endpoint is how the app learns which shell to open. See the role decision.

It also refuses a front-desk cookie the money addresses /insights, /expenses and /settings with a 403, before any of the app's bytes are served, so the attendant's phone never downloads the desk's screens. A dentist's cookie is served as normal, since the clinic makes him the admin of everything. See the money wall.

How

The check is one Pages Function that runs ahead of the static files and every other route. Its own logic lives in a tested package, not inside the Function file, so test files never land in the directory Cloudflare would serve as routes. Five settings, the two username and password pairs and a signing secret, are created directly on the host as encrypted values by the PM; the credentials are never in the repository, and the maker who built the gate never saw them. If any of the five is absent, the gate answers with an outage rather than serve anything, and the host's own fail-open/closed setting is explicitly set to fail closed, so an exhausted free daily allowance cannot quietly turn into an unguarded static site.

Reaching the clinic's own subdomain needed one CNAME record added at the existing domain registrar, pointed at the address Cloudflare assigned the project, with the registrar's nameservers left untouched so the clinic's mail and existing site keep working.

Why it is built this way

The custom address and every preview address are the same Cloudflare Pages project, so a single Function is the only way to close every door with one mechanism, rather than trusting each address to be checked separately. See the login gate decision for the rejected alternatives.

Verified

A fresh checker context, handed only the criteria, the diff and the test output, probed the live subdomain directly: no cookie always returned the sign-in page and never the app's own bytes on any path or method it tried, both real credentials signed in and eight wrong combinations were all refused identically, a signed session let the app load without asking again, and a search of every commit in the repository's full history found neither password. It also read Cloudflare's own free-tier terms from source and found no restriction on commercial use, while flagging a separate clause on health information as a decision still owed before cutover.

See Clarity 2, the product overview and independent verification.