Divi remediation — high-level pointers (local fallback)

timburr’s audit tells you what is wrong. The detailed, current fix procedures — exact menu paths, caching config, version-specific steps — live in the team wiki (set OUTLINE + OUTLINE_API_URL and the report links them directly). This file is the minimal high-level fallback for when the wiki isn’t configured: direction only, deliberately not step-by-step, so there’s no detailed content to drift out of sync with the wiki.

Heavy inline CSS — Divi is inlining its dynamic CSS per request instead of serving a cached file. Turn on Divi’s static/critical-CSS generation and pair it with a page cache.
Google Fonts from Google — host the fonts locally or switch to system fonts (performance + GDPR).
Very high module count — check whether a mega-menu / global header inflates the count before acting; otherwise split the page or lazy-load below-the-fold sections.
jQuery on Divi 5 — a plugin or theme is still pulling jQuery in; identify and update/replace it. Expected and fine on Divi 4.

Editing safely

The pointers above cover what the audit flagged. These cover how to change a Divi page without breaking it — stable workflow principles rather than version-specific procedures, so they belong here rather than in the wiki (nothing to drift).

Match the neighbours before you design. Inspect the page and a comparable sibling first, and carry over its fonts, colours, spacing, button treatment, heading levels, image treatment and global presets. A section that ignores the page’s own conventions reads as broken even when every automated check passes.
Global headers and footers are protected scope. Do not enter, select, edit or duplicate a Theme Builder header/footer unless the request explicitly names that global template and the owner has explicitly approved changing it. A request about page content is never approval to touch a global template: stop and ask rather than infer permission. Those templates propagate to every page using them. Once approval is explicit, edit the template itself; duplicate only inside the intended page’s own content area.
Verify across breakpoints, then clear the whole cache chain. Preview desktop, tablet and mobile; exercise links, accordions, tabs and forms; then clear Divi’s static CSS, the page-cache plugin, any server cache and the CDN — in that order — and confirm on the live URL. A Divi edit that “didn’t take” is usually a cache layer, not a failed save.
Substantial changes go through a draft. Duplicate the page, keep the copy as Draft, review it there, and let the owner publish. Never publish a draft or apply a live write without explicit approval — the same rule the write lane enforces in docs/write-approval.md.
Every Divi edit is bracketed by a scoped before/after. Not optional, and not “if it looks risky”:
```
snapatu before https://client.com/services
#   … make the edit …
snapatu after  https://client.com/services --scope copy,h1
```
Divi re-renders the whole page on save, so “I only touched one module” is an intention, not a fact. The builder’s own accidents are silent by construction: a module dragged one row up while dismissing a dialog, a link stripped by a paste from Word, an image swapped by a global preset, a form module whose shortcode was lost when a row was duplicated. None of those show up in the editor, and none of them look wrong on the page you were staring at.

--scope is what makes the check mean something. Declare what you set out to change, and:
- anything else that moved FAILs — it is a regression, not a “have a look”;
- anything you declared that did not move REVIEWs — the edit did not land, which on a cached Divi site is the single most common outcome of a save that appeared to work.
The snapshot pair is also the evidence: report.html and report.txt say what changed, in words, and attach to the ticket. “I checked it” is not a record; a before/after is.

If the edit is genuinely large — a rebuilt section, a new template — bracket it with viewvee --save-html as well, so there is a restore reference that is not the host’s backup.

Full playbook → the team wiki’s WordPress & Divi reference (caching setup, agent-safety notes, per-signal procedures). Configure the wiki to have timburr surface the live versions in its report.