Diagnosed the recurring full-width rendering problem shown in the mobile screenshot for https://aguiarinjurylawyers.com/abogado-lexington/.
Confirmed from live rendered DOM and CSS that Kadence wraps page content in .content-container.site-container with 24px left and right padding. The immediate entry content column is therefore 342px wide on a 390px mobile viewport and 1232px wide on a 1280px desktop viewport. Raw HTML sections such as section.hero, section.section-reviews, section.section-office, section.section-final-cta, and div.stats-bar need a viewport breakout rule to make their background span the window.
The issue is not the blue background itself. The background is applied to section elements that live inside .entry-content. Kadence's wrapper creates the white gutters. If a section does not have width: 100vw, max-width: 100vw, and margin-left/right: calc(50% - 50vw), it renders inside the padded content column.
This became sitewide because earlier fixes focused on individual components such as #au-form-v4 or .sa-hero. Other dark or orange direct-child sections were left without the same fullbleed escape.
Rendered source now contains a Custom CSS block titled 2026-05-28: SA-template section fullbleed. It applies the fullbleed pattern to direct children of .entry-content: section.hero, section.section-differentiators, section.section-reviews, section.section-clients, section.section-comparison, section.section-process, section.section-office, section.section-final-cta, and div.stats-bar.
Live desktop diagnostic after cache-busting showed section.hero, section.section-reviews, section.section-office, and section.section-final-cta at left: 0, rightGap: 0, and width equal to the viewport. Live mobile diagnostic at 390px showed the same: affected sections measured width 390, left 0, rightGap 0, with no horizontal scroll.
Local screenshot evidence saved: /Users/samaguiar/Documents/Codex/runs/2026-05-28-abogado-lexington/screens/live-mobile-width-diagnostic-20260528.png.
Update future QA rules so agents check all dark, orange, or image-backed direct children of .entry-content, not only heroes and CTA banners. This should be added to Skills/playwright-visual-qa/SKILL.md and Skills/website-rules-new/SKILL.md, or to the canonical design-system skill that drives Spanish landing pages.
A sitewide follow-up crawl should sample pages using raw HTML SA-template sections and flag any direct child with a non-white background whose computed left or right gap is greater than 1px.
A future agent can resume by running a Playwright computed-width audit against pages using SA-template raw HTML. Query the live page at desktop 1280px and mobile 390px, then inspect direct children of .entry-content where background-color is not white or background-image is set. Any matching block with left > 1 or rightGap > 1 should be treated as a fullbleed failure.
Should we update the reusable skills so this does not recur?
A. Update playwright-visual-qa and website-rules-new with a dark-section fullbleed check, recommended. This turns the lesson into a recurring QA gate.
B. Leave the skills unchanged and rely on the current Custom CSS block. Faster now, but future raw-HTML sections can reintroduce the problem.
C. Build a small recurring crawler for direct-child dark section width drift. Stronger protection, but more infrastructure than a skill update.