Deploy process (paste into Divi)

The core fact

The website is not continuously deployed. The repo is the staging copy; the live site is updated by manually pasting HTML into Divi Code Modules in WordPress admin. A commit to the repo changes nothing live until someone pastes it.

Why it works this way

It is a deliberate trade: direct control over exactly what is on each page, no git-to-prod pipeline to maintain, at the cost of a manual paste step. It is intentional, not a gap to “fix.”

The paste workflow

1. Edit the relevant file in pages/ or global/ and commit it.
2. Open WordPress admin, edit the page, open the Divi Code Module that holds that section.
3. Replace its contents with the new HTML. Save.
4. Clear the LiteSpeed cache if the change does not appear.
5. Verify on the live page (and on mobile for layout-affecting changes).

For multi-file changes, the source notes use a documented paste order in a session-handoff file so a multi-commit round is applied to the live site in the right sequence. When a round is shipped, the handoff/audit note is moved to notes/archive/.

Things that have bitten before (carry these forward)

• HTML Minify was not stripping instruction comments on the live site; saved page dumps still contained <!-- TILT HEADER - Paste this into Divi ... -->. Confirm comment-scrub behavior after big changes.
• Global CSS lives in global/tilt-divi-global.css and global JS in global/tilt-divi-scripts.html; these are included in Divi modules, so a global change affects every page. Test broadly.
• CLS/font issues have moved PageSpeed scores; layout-affecting CSS changes need a before/after PSI check. History in notes/current/audits/.

Rollback

There is no automated rollback. To revert, paste the previous known-good HTML back into the Divi Code Module.

NEEDS JUSTIN

Document the safety net: does the WordPress host take automatic backups, on what schedule, and how is a restore triggered? Is there a staging site, or is production the only environment? Record answers here and in the Runbook.