Separate required HTML validation outcomes from detailed reports - #1627
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Continue #1360 by separating required HTML validation facts from detailed report maps at the diagnostics-consumer boundary.
HtmlCompilationevaluates the existing validators once and constructsHtmlValidationOutcomein the producer-ownedBlockCompilationOutput.DiagnosticsCollectorconsumes the compact outcome rather than full block-validity, semantic-parity and content-round-trip reports.not_evaluated, notpass. Successfully parsed empty documents still evaluate validators normally.There is no reduced-evidence mode, skipped validator or performance claim in this bite. Detailed reports are still computed; this establishes the consumer boundary needed before a later evidence policy. The internal outcome is not added to the public serialized result.
The required/detail consumer inventory is documented in
php-transformer/docs/html-validation-outcome-consumer-inventory.md.Verification
Baseline:
c302eaaa26681462a784c0d341f2702ce7d464e7.Candidate:
b36079ffb337b3518a93fc3d6b8a54cb27907ac8.transform_duration_ms. PHP serialization preserves binary bytes and array ordering.a3a2c5c327cace26a2a69aaa52d9e81fbf7e2fef9134259678700c8517d28d56.composer testpassed end-to-end in one PHP 8.4 container with a 512 MB PHP configuration inherited by child processes: canonical/unit tests, 303 parity fixtures, dist shape and package-install proof.WP_TESTS_DIRwas unavailable. Actual CI integration and solved-site gates remain required.Reproduce
From
php-transformer, with dependencies installed and PHP memory configured for child processes:composer test REQUIRE_WP_TESTS=1 WP_TESTS_DIR=/path/to/wordpress-tests composer test:wordpress-integrationFor corpus comparison, run this from both repository roots with matching dependencies and compare the resulting output:
AI Assistance
OpenAI GPT-5.6 Terra via direct OpenCode mapped consumers, implemented the boundary and ran lab verification. GPT-6 Astra via OpenCode coordinated and reviewed the work, identified unevaluated-status and diagnostic-normalization problems, requested behavioral corrections and full-suite verification, independently checked comparison evidence, and prepared this PR under Chris Huber's direction. No release or deployment was performed.