eb8666ba40207862e35ba2245e488668b0e2978e
feedback_polarity_must_agree_across_surfaces fix (f59c1af) added .my-sea-page[data-polarity="..."] to the shared .sig-overlay, .my-sign-page polarity block at _card-deck.scss:919. Worked for the spread-center sig (.sea-sig-card) but silently bled into the drawn-card stage modal: the stage's element carries BOTH classes .sig-stage-card sea-stage-card (per _sea_stage.html:12), so the shared rule's .sig-stage-card descendant selector matched. Specificity .my-sea-page[data-polarity="levity"] .sig-stage-card = 0,3,0 silently beat the card-specific .sea-stage--gravity .sea-stage-card = 0,2,0 (set by sea.js's _showStage(isLevity) at line 104-108) → every drawn card on my-sea rendered the user's-sig polarity instead of the deck-stack it was actually drawn from. Room.html Sea Select unaffected (no .my-sea-page ancestor on the stage there). User-reported 2026-05-21 — symptom: a gravity card opened in my-sea stage shows the light/cream levity styling even though the card came from the gravity deck. Fix: drop .my-sea-page[data-polarity] from the shared selector list at _card-deck.scss:917-919 + :972-974; add a NEW dedicated rule at the end of the shared block scoped tightly to .sig-stage-card.sea-sig-card (0,4,0 specificity) — the central sig stays page-polarity-driven (yesterday's MySeaPolarityMatchesMySignTest still pins this) but every other .sig-stage-card descendant (drawn-card stages, future spread elements) is free to follow its own polarity. Gravity is the default rendering for .sea-sig-card per the base rule at :1379 so only the levity override needs an explicit block. 6/6 existing polarity + picker ITs green; visual verify deferred to user. Trap captured: [[feedback-page-polarity-scope-trap]] — multi-class elements (.A.B) match both shared (.A) AND scoped (.B) selectors, so any new page wrapper added to a shared block needs an audit of every descendant selector in the block for nested polarity overlap
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
fix: my-sea drawn cards no longer always render levity-coded — yesterday's
feedback_polarity_must_agree_across_surfaces fix (f59c1af) added .my-sea-page[data-polarity="..."] to the shared .sig-overlay, .my-sign-page polarity block at _card-deck.scss:919. Worked for the spread-center sig (.sea-sig-card) but silently bled into the drawn-card stage modal: the stage's element carries BOTH classes .sig-stage-card sea-stage-card (per _sea_stage.html:12), so the shared rule's .sig-stage-card descendant selector matched. Specificity .my-sea-page[data-polarity="levity"] .sig-stage-card = 0,3,0 silently beat the card-specific .sea-stage--gravity .sea-stage-card = 0,2,0 (set by sea.js's _showStage(isLevity) at line 104-108) → every drawn card on my-sea rendered the user's-sig polarity instead of the deck-stack it was actually drawn from. Room.html Sea Select unaffected (no .my-sea-page ancestor on the stage there). User-reported 2026-05-21 — symptom: a gravity card opened in my-sea stage shows the light/cream levity styling even though the card came from the gravity deck. Fix: drop .my-sea-page[data-polarity] from the shared selector list at _card-deck.scss:917-919 + :972-974; add a NEW dedicated rule at the end of the shared block scoped tightly to .sig-stage-card.sea-sig-card (0,4,0 specificity) — the central sig stays page-polarity-driven (yesterday's MySeaPolarityMatchesMySignTest still pins this) but every other .sig-stage-card descendant (drawn-card stages, future spread elements) is free to follow its own polarity. Gravity is the default rendering for .sea-sig-card per the base rule at :1379 so only the levity override needs an explicit block. 6/6 existing polarity + picker ITs green; visual verify deferred to user. Trap captured: [[feedback-page-polarity-scope-trap]] — multi-class elements (.A.B) match both shared (.A) AND scoped (.B) selectors, so any new page wrapper added to a shared block needs an audit of every descendant selector in the block for nested polarity overlap
Description
No description provided
Languages
Python
45%
JavaScript
37.6%
HTML
9%
SCSS
8.2%
Jinja
0.1%