Quality gate

What is checked

Every Stage is checked before it can go live. The check always looks at the staged build, exactly what Publish live would ship, never at the live site. There are two kinds of checks:

• Lighthouse rates Performance, Accessibility, Best Practices and SEO on a mobile viewport. The target is 100 in every category.
• Page checks read every page of the staged build on every Stage. Plugins add them. No plugin shipped with Caelo adds one yet, so today the Lighthouse check does the work.

The target is the optimum: 100 in every category and zero findings. A 99 blocks as much as a 60. Whatever cannot be fixed comes to you as a decision.

A separate rule runs before every build: a published page without a meta description stops the Stage, and the message names the pages. How Stage and Publish live fit together is explained in Drafts, staging, publishing.

When Lighthouse runs

Lighthouse runs after a Stage that can change how pages look or perform:

• module HTML, CSS or JavaScript was created or changed;
• a layout, template or the theme changed;
• a new page goes live;
• plugin settings that render on pages changed;
• it is the site's first Stage, or the previous check did not end clean.

A Stage that only changes texts and field values, moves existing modules, or edits SEO texts or redirects gets no Lighthouse run.

Lighthouse covers the homepage plus the changed pages, up to five pages in all. Performance is the median of three runs. The other categories are measured once. The result usually appears in the chat a minute or two after the Stage.

What blocks Publish live

A Stage is blocked when, on any checked page, and no acceptance covers it:

• a Lighthouse category scores below 100;
• a single Lighthouse audit scores below a perfect score (Lighthouse's own report shows scores from 0.9 in green; Caelo does not);
• a page check reports an error.

Warnings and hints are shown, but never block. Findings caused by Caelo itself block too. They are not hidden; the AI reports them as Caelo bugs.

Performance metrics

For every audited page, Caelo also records the numbers behind the Performance score: First Contentful Paint, Largest Contentful Paint, Total Blocking Time, Cumulative Layout Shift and Speed Index, plus the element that loads last and the elements that shift. These numbers never block on their own. They are what the AI fixes against.

How it plays out in the chat

1. You stage, or the AI stages its finished work. The result appears in the same chat.
2. If there are problems, a card asks you first, with findings grouped by rule across pages, for example "Missing alt text (12 pages)". Nothing changes until you decide.
   • Fix all with AI lets the AI fix everything it can, then stage again, which checks again.
   • Per group: Fix all, Accept all… (with a reason), or Pick pages to act on some pages only.
   • Not now leaves everything as it is. Publish live stays blocked.
   • Or type what you want instead.
3. When the AI finds something it cannot fix, it says why and offers one decision per group. It does not call a score below 100 good enough, and it does not recommend accepting.

Accepting findings

Some things cannot or should not be fixed: a third-party embed, a brand colour you want to keep. An editor can accept them, per group of findings, on all affected pages or on selected ones, with a reason.

An acceptance records the value measured at that moment. It blocks again when the page gets worse, and tightens when the page gets better. For Performance only, a measured value may be up to 2 points below the accepted value before it counts as worse, because Performance varies a little between runs. That tolerance never applies against the target of 100.

When the check itself fails

If the check cannot produce a result, for example after a timeout or a browser crash, it never passes silently. Publish live stays blocked, with Retry check in the toolbar. If you must publish without a result, someone who may publish can choose Publish anyway… and give a reason. That decision is recorded with their name. The AI can only propose it.

Automatic redeploys

A direct production build and the automatic redeploy follow the same rules. When only content changed since the last clean check, production is rebuilt directly. Otherwise the change is staged and checked first, and goes out only when the check is clean or every problem was accepted.

The quality view

Quality in the sidebar (/settings/quality) shows the gate of the current staged build and why it is open or blocked, recent checks with findings and metrics per page, all acceptances grouped by decision, and every "publish anyway". The Owner can revoke acceptances there. What was revoked blocks again at once.

Where it runs

The check runs on the admin server, with the Chromium build that ships in the admin image. Lighthouse runs in a separate process that gets no database credentials or secrets. The admin's memory setting (adminMemory) defaults to 2 GiB for this reason.