Prufy notes
Orientation ยท 10 min

Life of a claim

Follow one domain from the first keystroke to verified, starting as a visitor who has never been here. Watch which layer is active, and how the database fills up.

This is the best chapter to come back to. Each later chapter zooms into one of these moves. Step through it once quickly, then again slowly, reading the file names.

Claiming mail.example.comClick any row to jump back
Browser
Route
Service
core
dns
db
Internet
Step 1 of 21
You type mail.example.com
Each keystroke runs normalizeDomain right in the browser. A green tick appears once the input is a usable domain, and leaving the field tidies a pasted URL or email address down to the domain. It's a pure function, so the same code can run on both sides.
components/landing/domain-form.tsx
In the database now
accounts0
sessions0
domain_claims0
challenges0
checks0
observations0
claim_events0
No claim yet
Predict it first
At the moment the engine is asking DNS, how many database transactions are open for this claim?
Predict it first
A visitor opens the landing page, reads it, and leaves without typing a domain. How many rows were written?

What happens when nobody is watching

Most checks aren't triggered by a person. Every 15 seconds the worker picks up claims whose next_check_at has passed and runs the same steps from startCheck onward. In your real run with joycabinet.com, the first four checks were all the worker's.

The shape of the code

Notice the pattern in the diagram: the Service lane talks to everything, and core, dns and db never talk to each other at run time. The service is the only place that knows the order of operations. Each package only knows how to do its own job.