CSS Phase D: twin folds, 760-rule legacy dead sweep, css-winners gate, roadmap revision#379
Conversation
The FL export left contradictory display sequences (gform_title block->block->none, form-description none->block) in BOTH critical and pages; their cross-file interleaving decided the compiled winners, which is why C5's plain dedup regressed the apply form. Fold: each contradiction collapsed to the LIVE compiled winner (title none, form-title block, form-description none, span.gform_description none) in both files; then the 18 pages-side twins deleted. Gate: per-selector winner map vs clean-room master build identical except the known var(--font-system-ui) equivalence; careers_ruby screenshot test green. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GYRU9wGepomJo5hSuqtu7V
…les) clients (45), single-service (49), single-use-cases (53) twins deleted from the pages side. Two hard-won findings baked into the source: - The clients 'flip' C5 reported was a winner-parser artifact (comma split inside :not(b, strong)); with a paren-aware splitter the dedup is provably winner-identical. - The .clearfix table/block pair is TRIPLY position-load-bearing: critical's Bootstrap-style block rule must stay byte-identical to vendors/base-4.min.css's copy (so production dedup eats base-4's later copy) AND the pages-side table twin must stay (its post-critical position makes table the final winner). Both kept, with an in-file warning comment. Folding either breaks the apply chain - verified empirically via compiled-order forensics. Gate: per-selector paren-aware winner maps identical vs clean-room master builds for all three bundles; scoped screenshot gate green. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GYRU9wGepomJo5hSuqtu7V
…s deleted (~89KB source) Per-bundle PurgeCSS-survival audit (agent-produced dead lists with cssnano-normalization false-positive controls) across the 5 legacy shared files: 586 (-122), style (-2), theme-main (-227), component-bundle (-180), legacy-theme-skin (-229). Every deleted rule verified absent from all 19 compiled bundles. One audit false positive caught by the byte-gate and restored: the fl-node-ntfp1iza9jy8 :not(...)-chain white-text enforcer (alive via the /^fl-node/ greedy safelist; the long :not chain defeated fragment matching). Postponed jt-reviews-box/pp-swiper/pp-review rules excluded from the sweep per Paul. Gate: all bundle fingerprints byte-identical except the two component-bundle consumers, which differ only by cssnano de-grouping of the restored rule - paren-aware per-selector winner maps identical. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GYRU9wGepomJo5hSuqtu7V
…e promoted Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GYRU9wGepomJo5hSuqtu7V
|
Warning Review limit reached
Next review available in: 36 seconds Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (12)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
1 participant
What this is
Phase D — the last planned phase of the CSS migration project. After this PR the project's goal is achieved by its own five criteria and the tracker moves to maintenance mode, with the remaining risky items parked as trigger-conditioned work.
D1 — fold-then-dedup, the 4 position-sensitive twin sets (165 rules)
careers_rubyscreenshot green.:not(b, strong)); paren-aware winner maps prove the dedup exact..clearfixpair is triply position-load-bearing — critical's Bootstrap-style copy must stay byte-identical tovendors/base-4.min.css's (so production dedup eats the vendor copy) and the pages-sidetabletwin must stay positioned to win. Both kept with in-file warnings; folding either link breaks the chain (verified by compiled-order forensics).D2 — legacy dead-rule sweep (760 rules, ~89KB source)
Agent-audited per-bundle PurgeCSS survival across the 5 legacy shared files: 586 (−122), style (−2), theme-main (−227), component-bundle (−180), legacy-theme-skin (−229). Every deleted rule verified absent from all 19 compiled bundles; the postponed
jt-reviews-box/pp-swiper/pp-reviewrules excluded per Paul. One audit false positive caught by the byte-gate (a:not()-chain white-text enforcer alive via the/^fl-node/greedy safelist) and restored — final state: all fingerprints byte-identical except cssnano de-grouping of the restored rule, winner-maps exact.Tooling + roadmap
bin/css-winners: the per-selector last-wins comparison gate promoted to a first-class tool — it caught both real regressions this phase that declaration-set comparison missed.Verification
bin/dtest-all) on the branch head🤖 Generated with Claude Code
https://claude.ai/code/session_01GYRU9wGepomJo5hSuqtu7V