It checks the site before it ships

Twelve rules that block a publish rather than warn about it, then a check that the live URL really answers.

What the log looks like

Publishing /pricing/ — passed all 12 checks

Checking the site answers over the wire.

Verifying https://cadence-clinic.firstemployee.app/ — 200 OK

Verifying https://cadence-clinic.firstemployee.app/about/ — 200 OK

Verifying https://cadence-clinic.firstemployee.app/pricing/ — 200 OK

And when something is wrong:

Couldn't get /faq/ past my own checks — shipping without it, fixing tonight.

/resources/ answered 502 — leaving it on my list for tonight.

1 of 5 pages did not verify — not calling the site live yet.

Every line above is one the employee actually prints. The company in it is an illustration so the log reads as a whole; it is not a customer.

ទិដ្ឋភាពទូទៅ

ពេលវេលារត់	Instant per page, then a few seconds per URL
ល្បឿន	Every publish, every build, every night
លទ្ធផល	A pass or a blocked publish, plus a status code per page
កិច្ចខិតខំប្រឹងប្រែងរបស់អ្នក	None. Read the rules if you are curious.

នរណាដែលវាសម្រាប់: Anyone who has been handed AI-written pages and had no way to tell whether they were any good — and anyone who has watched a site quietly lose traffic to a fixable mistake.

របៀបដែលវាធ្វើការ

The rules are code, not advice. A rule that lives only in an instruction gets followed most of the time and quietly skipped the rest, and you find out in a traffic report three months later. These run after the page is written and before it goes anywhere.
Eight of the twelve block. One subject per page. A description written for a human. No shared body text. An absolute canonical paired with hreflang. Markup that only claims what the page shows. Real utility rather than a wrapper. Nothing indexable until it is finished. No orphan pages.
A failure goes back to the writer. The reasons are handed to the employee and the page is rewritten against them. Failing twice means the page does not ship and the fix is queued, which is a worse outcome than a good page and a better one than a bad page.
Then it checks the site over the wire. Each published page is fetched at its public URL, the way a stranger would, and the status code is recorded. A page that answers anything but 200 is retried once and then listed as a failure.
It refuses to overstate the result. If pages fail the check, the site is not marked live and the report says how many did not verify. If the serving layer cannot be reached at all, it says that instead of either claiming success or crying failure.

អ្វីដែលអ្នកទទួល

Twelve rules applied to every page, eight of which stop a publish outright.
The full check result stored on the page and on its receipt.
A fetch of each published URL from outside, looking for a 200.
An honest status: the site is not called live until its pages answer.
The rules themselves published and explained, so you can read what your employee is held to.

សំណួរអំពីនេះ

What are the twelve rules?

They are published in full, with the reason each one exists and whether it blocks or warns. Every one of them was paid for by an incident on a site we run rather than copied out of a best-practice list.

Why block a publish instead of warning?

Because a warning nobody reads is indistinguishable from no rule at all. Blocking costs one rewrite; a bad page published costs however long it takes somebody to notice.

What does "verified over the wire" mean?

The employee requests your live URL from outside and reads the status code, rather than trusting its own database row that says the page was saved. A page that exists in a table and 404s on the internet is not a published page.

Does the check cover accessibility or performance?

Not today. It covers structure, uniqueness, markup honesty, canonicals, links, images and indexability, plus a live status code. We would rather list what it genuinely checks than imply an audit it does not run.