Skip to content

Add live-WP candidate entry to static-parity runner (deterministic, real WP DOM)#348

Merged
chubes4 merged 1 commit into
trunkfrom
cook/live-wp-parity-candidate
Jun 29, 2026
Merged

Add live-WP candidate entry to static-parity runner (deterministic, real WP DOM)#348
chubes4 merged 1 commit into
trunkfrom
cook/live-wp-parity-candidate

Conversation

@chubes4

@chubes4 chubes4 commented Jun 29, 2026

Copy link
Copy Markdown
Contributor

What

Adds a deterministic LIVE-WP variant of the static-parity gate (blocks-engine half) so the same comparator can run against REAL WordPress-rendered DOM (fetched as HTML, not screenshots), closing the gap where the render-free proxy never exercises WP block render + global-styles.

Change

  • New StaticStyleParityRunner::compareSourceToCandidate() — takes an external candidate HTML string + separate source/candidate CSS, runs the existing probe + comparator unchanged. compareSourceToTransform() delegates to it. Separate source/candidate CSS so the live-WP candidate is judged solely on WordPress-emitted styling.
  • tools/live-wp-parity/run.php + composer live-wp-parity (--with-proxy emits proxy score + live-vs-proxy delta, --json, --fail-under).
  • Unit test wired into composer test:unit.

Verification

  • Wiring proof: feeding the transform's own candidate reproduces the proxy score exactly (delta 0) — the external-candidate path drives the identical comparator.
  • Determinism: two JSON runs byte-identical (sha256 match).
  • composer test + composer parity green (182 fixtures).
  • Honest limit: comparator internals untouched (coverage PR owns those); a real live-vs-proxy number on WP DOM awaits an offloaded run.

AI assistance

  • AI assistance: Yes
  • Tool(s): Claude Code (Claude Opus 4.8, 1M context)
  • Used for: Design, implementation, determinism/wiring verification under human review.

The render-free static-parity gate builds its candidate from serialized
blocks and never exercises WordPress's own block rendering + global-styles
layer (where the base64 styling regression lived). Add a deterministic
variant that compares the source against a candidate produced by a real WP
render — the rendered DOM HTML fetched headless — using the EXISTING probe
+ comparator unchanged.

- StaticStyleParityRunner::compareSourceToCandidate(): new entry accepting an
  external candidate HTML string plus separate source/candidate CSS, running
  the same StaticStyleParityProbe + StaticStyleParityComparator so the report
  contract, score, and per-property diff are identical to the render-free
  gate. compareSourceToTransform() now delegates to it (same-CSS-both-sides).
  Source and candidate take separate CSS so the live-WP candidate is judged
  solely on the styling WordPress emitted; the source's author CSS is never
  leaked onto the candidate.
- tools/live-wp-parity/run.php + composer "live-wp-parity": thin CLI taking
  --source/--candidate (+ optional --source-css/--candidate-css), emitting the
  same report contract under live_wp; --with-proxy also reports the render-free
  proxy score and the live-WP-vs-proxy delta for side-by-side gating.
- tests/unit/live-wp-parity-runner.php: determinism (byte-identical reports),
  wiring proof (external entry reproduces the proxy when fed the proxy
  candidate + same CSS), regression detection naming the exact diverged
  property, and a no-CSS-leak guard.

Pure PHP, no browser/network/screenshots: same inputs -> byte-identical
report. Verified on 15-saas: external path reproduces the proxy score 0.7328
exactly and is byte-identical across runs.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@chubes4 chubes4 merged commit eb8b88f into trunk Jun 29, 2026
1 check passed
@chubes4 chubes4 deleted the cook/live-wp-parity-candidate branch June 29, 2026 13:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant