v1: run release-candidate compatibility validation

[jenil]

Objective

Run a defined three-business-day release-candidate validation window and turn feedback into explicit release decisions.

Prerequisites

• v1: prepare release candidate package #143 has approved a specific RC commit and owner has authorized RC publication.
• A public or private feedback route, test instructions, and issue-labeling convention are ready.
• The support policy and known limitations are published accurately.

Validation scope

Ask representative users to validate WordPress coexistence, narrow mobile grid behavior, dark-mode variable overrides, third-party CSS coexistence, normal install/use, and any selected v1 fixes. Run the manual Safari 15.4+ pass against the actual RC. Firefox/WebKit automated checks remain smoke coverage, not pixel baseline sign-off.

Do not

• Claim community validation happened without named evidence or a logged zero-feedback window.
• Accept new feature requests into the RC without an owner decision.
• Extend the window indefinitely because of untriaged feedback.
• Merge to main or publish final 1.0.0 on this card.

Procedure

1. Announce the exact RC version, candidate commit, feedback deadline, known limitations, and reproduction template.
2. Log each report with environment, reproduction, severity, and disposition.
3. Run the Safari checklist manually and record device/OS/browser version and result.
4. At the deadline, classify feedback as release blocker, follow-up, duplicate, or not reproducible.
5. If a blocker is fixed, cut a new candidate and repeat only the affected validation evidence plus required full gates.

Done checklist

• The window lasted three business days or the owner explicitly approved a different documented duration.
• Feedback and no-feedback results are recorded with decisions.
• Manual Safari 15.4+ validation is documented against the published RC.
• Release blockers are resolved and revalidated, or final release is explicitly stopped.
• Final go/no-go recommendation is owner-reviewable.

Required handoff

Provide RC version/SHA, announcement and deadline, feedback log/dispositions, Safari checklist, revalidation evidence for any RC fix, remaining known limitations, and go/no-go recommendation.