Preserve captured inner-page type leading and padded container geometry

[chubes4]

Reproduction

Import https://ward-behavior-path.base44.app/ through Studio trunk from URL using published DLA v0.8.4 and SSI v1.20.7 (Blocks Engine pinned by SSI). The importer reports 10/10 pages, no fallback blocks and quality_pass=true, but released DLA compare fails on About, Why Choose Us and Referral Partners at 1600px/1728px.

Real Chromium computed-style/geometry evidence at 1600px:

• About We Lead with GRACE: source 48px font and 48px line-height; imported WordPress 48px font and 36px line-height on h2.wp-block-heading.blocks-engine-responsive-typography-*.
• About We are committed to continuous growth: source 14px font / 22.75px line-height, imported paragraph 14px / 20px. Same line-height loss appears in Why Choose Us body copy.
• About section text container source x=192 width=1216, imported x=180 width=1240. The first portrait source x=832, width=576, height=432; imported x=832, width=588, height=429. These are visible layout differences, not merely a comparator mismatch.
• Referral Partners Who We Work With: source 48px line-height, imported 36px. Form label styling is a separate owner-facing concern on the multi-step wizard tracked at Capture client-side multi-step forms before portable import data-liberation-agent#474.

Acceptance

Preserve source-computed heading/body leading and padded max-width container geometry through editable block output, with browser-backed neutral regressions at desktop and mobile widths. A fresh Studio URL import should match the source measurements without fallback blocks or width overflow. Diagnose whether the owning loss is authored CSS transfer, block defaults, or the synthetic figure/container topology before patching.

AI assistance: OpenAI GPT-6 Sol via OpenCode ran the published-release import and DLA compare, measured source and WordPress computed styles/rectangles in Chromium, and drafted this issue under Chris Huber direction.

[chubes4]

Owner finding from the tracked PHP transformer investigation: the imported /about/ already contains the authored heading classes text-4xl md:text-5xl leading-tight, paragraph leading-relaxed, and padded max-width container classes. PHP block markup therefore preserved the source styling signals; the observed 48→36px heading leading, 22.75→20px paragraph leading, and 1216→1240px inner-width differences arise in generated theme CSS / stylesheet cascade or WordPress rendering integration. No PHP transformer patch was made. Next investigate source and generated CSS rules, specificity, box sizing, and retained utility declarations in the browser at 1600px, then test a neutral native-block theme regression.

AI assistance: OpenAI GPT-6 Sol via OpenCode measured computed styles in source and WordPress Chromium and reviewed the Homeboy PHP-transformer investigation; Chris directed the work.

[chubes4]

Browser cascade localization at 1600px narrows the actual owner further. The source carries .lg\:text-5xl { line-height: 1 } and .md\:px-8 { padding-inline: 2rem }, yielding heading 48px leading and 32px container padding. The WordPress theme also carries these authored rules, but its generated page CSS later emits a more specific .text-3xl:not(:where(...)) { line-height: 2.25rem } and .px-5:not(:where(...)) { padding-inline: 1.25rem }. The result is heading 36px leading and 20px padding; image width grows 12px. This is inflated specificity / responsive cascade precedence in transformed CSS, not missing PHP markup or missing utility declarations.

An attempted low-precedence compatibility layer was measured in Chromium and rejected: when prepended as proposed, heading stays 36px and padding20px; when appended, heading becomes 60px (source48) despite padding32. Correct the generated selector order/specificity, then measure rendered 48px/22.75px leading and 32px padding in a fresh import.

AI assistance: OpenAI GPT-6 Sol via OpenCode measured matching CSSOM rules and injected the proposed rules before/after the author stylesheet in Chromium, then reviewed the Homeboy candidate under Chris Huber direction.

[chubes4]

Further localization: the ArtifactCompiler split explicitly says page-projected CSS must load before its source site-wide stylesheet to keep equal-specificity source cascade. In the generated WordPress functions.php from the published Ward import, assets/website/assets/index-OBL_jfPu.css is enqueued first and index-OBL_jfPu.page-53de97adeb14.css much later. CSSOM confirms the latter overrides authored responsive .lg\:text-5xl and .md\:px-8 with base .text-3xl:not(:where()) and .px-5:not(:where()).

WordPressSitePlan::orderAssetsByDocumentStylesheetOrder currently reorders only linked asset tokens; generated page CSS is unlinked and retains its inventory slot. Investigate honoring the page_stylesheet_of relation through plan/enqueue ordering, so the page delta precedes the exact shared stylesheet it came from at runtime. Preserve other authored linked CSS ordering. A browser regression must prove computed 48px heading leading, 22.75px paragraph leading, 32px desktop padding and 576px portrait on a fresh import.

AI assistance: OpenAI GPT-6 Sol via OpenCode compared the WordPress generated enqueue bootstrap with the compiler and site-plan ordering contracts and measured the CSS cascade in Chromium under Chris Huber direction.